DOCSLIB.ORG

When the Virtual Machine Wins Over the Container: DBMS Performance and Isolation in Virtualized Environments

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
When the Virtual Machine Wins Over the Container: DBMS Performance and Isolation in Virtualized Environments Journal of Information Processing Vol.28 369–377 (July 2020) [DOI: 10.2197/ipsjjip.28.369] Regular Paper When the Virtual Machine Wins over the Container: DBMS Performance and Isolation in Virtualized Environments Asraa Abdulrazak Ali Mardan1,a) Kenji Kono1,b) Received: September 10, 2019, Accepted: April 8, 2020 Abstract: Database management systems (DBMSs) are a common service in the cloud. Cloud providers employ virtualization to consolidate DBMSs for efficient resource utilization and to isolate collocated DBMS workloads. To guarantee the service-level agreement (SLA), the disk I/O performance and its isolation are critical in DBMSs because they are inherently disk I/O intensive. This paper investigates the disk I/O performance and its isolation of MySQL on two major virtualization platforms, KVM and LXC. KVM provides the hypervisor-based virtualization (virtual machines) while LXC provides the operating-system-level virtualization (containers). Containers are widely believed to outperform virtual machines because of negligible virtualization overheads, while virtual machines are to provide stronger performance isolation. Contrary to the general belief, our results show that KVM outperforms LXC by up to 95% in MySQL throughput without compromising the isolation. Furthermore, LXC violates the performance isolation; a container given 30% share of the disk bandwidth consumes the 70% share. Our analysis reveals that the file system journaling, which is mandatory to maintain file system consistency, has negative impact on both the performance and its isolation in the container. Because of the sharing of the journaling module in containers, the journaling activities are serialized and bundled with each other, resulting in poor performance and violation of the performance isolation. Keywords: virtualization, container, DBMS, journaling file system. performance degradation because less cache is allocated for them. 1. Introduction On the other hand, VMs have stronger performance isolation be- Virtualization technologies are the building block of cloud dat- cause no kernel components are shared among VMs. acenters. They are widely used in today’s datacenters to achieve The performance and isolation are important in virtualized en- server consolidation for efficient resource usage, less power vironments, where multiple users’ workloads are consolidated conusumption, and to isolate collocated applications on a single on the same machine. Users expect their workloads run in iso- machine. There are two virtualization approaches: operating sys- lated manner and to get the performance they pay for. Failing to tem (OS)- and hypervisor-based virtualization. Hypervisor-based achieve isolation results in performance degradation. This leads virtualization virtualizes hardware resources to provide the ab- to SLA violation which ultimately results in financial loss for the straction of virtual machines (VMs). This allows multiple OSes cloud providers [1], [2]. to co-exist on a single machine. OS-based virtualization also This work investigates disk I/O performance and isolation in known as containerization creates multiple virtual units in the LXC [3] and KVM [4], which are representatives of OS- and userspace, known as containers in which processes run directly hypervisor-based virtualization, respectively. Disk I/O perfor- on the host OS. Containers share the same host kernel in oppo- mance and isolation are critical in database management sys- site of VMs but are isolated from each other through abstraction tems (DBMSs) which are a common service in the cloud. Many mechanisms of Linux namespaces and Cgroup resource control cloud-based services such as Dropbox [5], Facebook [6] and at the OS level. Saleforce [7] make use of DBMS. Microsoft’s SQL Azure [8] Containers are lightweight and bring the performance advan- and Google Cloud SQL [9] provide DBMS as a cloud service. tage over VMs. However, these advantages have some shortcom- DBMS makes excessive use of disk resource by orchestrating a ings. Since containers share the same kernel components like large number of I/O operations and causing journaling updates “buffer caches” and other the data structures, the performance iso- to ensure consistency. Journaling is indispensable for recovering lation among containers becomes weak and hard to accomplish. from unexpected crashes in file systems, and can not be turned off For example, if one container accesses many files to increase the in DBMS. pressure on a shared buffer cache, other containers suffer from This paper presents an updated and extended DBMS perfor- mance and isolation comparison of LXC and KVM. Our previous 1 Keio University, Yokohama, Kanagawa 223–8522, Japan work [10] examines MySQL performance and isolation under the a) [email protected] Cgroup / b) [email protected] old function of disk I O control [11]. This work adopts c 2020 Information Processing Society of Japan 369 Journal of Information Processing Vol.28 369–377 (July 2020) the newer fuction of Cgroupv2 [12] for disk I/O control, and con- presents the work related to ours. Finally Section 7 concludes siders the up-to-date software version of KVM, LXC, and Linux the paper. kernel. 2. Background We have extended the previous paper by first, examining how the Cgroup in general achieves the disk I/O control in a sepa- Hypervisors and containers have different architectures and rate experiment. Second, invistigating DBMS performance and properties. Section 2.1 overviews the internal design of isolation under Cgroupv2, a newer version of Cgroup with new hypervisor-based and container-based virtualization using KVM I/O controllers, new unified groups, and new implementation that and LXC, with highlighting the I/O performance and perfor- overcome many of Cgroup implemetation problems [13]. One mance isolation. Section 2.2 presents the disk I/O control by of the most important difference between the new and the old cgroup in KVM and LXC, and analyzes the drawbacks with it. Cgroup, is the support of buffered write along side non-buffered disk write when applying I/O control [12]. This new feature sup- 2.1 Virtual machine and Container poses to make the I/O control stronger and may affects the previ- In hypervisor-based virtualization, a hypervisor runs on top of ous results. Regardless of a newer developed linux kernel, KVM, a physical machine and virtualizes the underlying hardware re- and LXC software version, it was important to compare DBMS sources onto which a guest OS is installed, resulting in multiple performance isolation under these new circumstances. Finally, virtual machines running on the same physical machine. On the considering the latency metric in our experiments for a better ex- other hand, containers shift the layer of virtualization from the planation and details of the underlying problem. hardware level to the OS level. Containers rely on mechanisms The key finding of our work is that VMs outperform containers provided by the host OS; namespaces to separate containers log- in both I/O performance and isolation in DBMS. This finding is ically and Cgroup to control resources among containers. contrary to the general belief. The container is widely believed Figure 1 (a) and (b) show the architecture of KVM and LXC, to beat VM in performance because container does not suffer respectively. In KVM, a guest OS runs on top of a host OS. Hard- from virtualization overheads. However, according to our results, ware devices such as disk drives are virtualized with QEMU de- KVM outperforms LXC with up to 94% in MySQL throughput. vice emulator [14]. A disk I/O request is handled in a guest OS, Furthermore, LXC fails to achieve isolation; a container given passed to a device emulator, and then processed by a host OS. 30% share of disk bandwidth consumes 70% share although the In LXC, user processes run directly on a host OS without any resource control mechanism, cgroupv2, enforces disk I/O limits. virtualization overheads. A disk I/O request from a container is Our contributions consist of analyzing DBMS performance handled in the same way as ordinary processes on the host. and performance isolation in the container. The sharing of a In exchange for the performance advantage, LXC provides journaling module among containers degrades I/O performance weaker isolation of performance. Since containers share buffer in DBMS. To guarantee the consistency, existing file systems caches and other data structures at the OS-level, the activity in- typically use journaling with transactions. A journaling module side one container is likely to affect the performance of other batches updates from multiple containers into a transaction and containers through the shared kernel components. Even though commits the transaction to disk periodically or when fsync is the resource controlling mechanism Cgroupv2 enforces resource invoked. DBMS application invokes a lot of fsync() to ensure limits on containers, it can be bypassed as it will be shown in consistency and to write all updates to disk. If a single transaction Section 4.1. contains updates from multiple containers, each container has to wait until the data belonging to other containers is flushed. Jour- 2.2 Disk I/O Control by Cgroup naling also interferes with performance isolation among contain- Both of LXC and KVM rely on Cgroup to enforce disk I/O ers. When an update-intensive container commits a transaction, it control. Cgroup supports two policies for controlling disk I/O: adversely affects the performance of other containers. An update 1) I/O throttling and 2) proportional-weight. I/O throttling caps from the container is likely to be batched together with updates the maximum usage of I/O bandwidth or I/O request rates. In I/O from other containers. Even if each transaction contains updates throttling, a container/VM cannot make use of an idle resource solely from one container, the transactions are serialized in the journaling module and cannot be committed in parallel. In ad- dition, the journaling interferes with disk I/O control of Cgroup.
Load more

Recommended publications
  • Security Assurance Requirements for Linux Application Container Deployments
    NISTIR 8176 Security Assurance Requirements for Linux Application Container Deployments Ramaswamy Chandramouli This publication is available free of charge from: https://doi.org/10.6028/NIST.IR.8176 NISTIR 8176 Security Assurance Requirements for Linux Application Container Deployments Ramaswamy Chandramouli Computer Security Division Information Technology Laboratory This publication is available free of charge from: https://doi.org/10.6028/NIST.IR.8176 October 2017 U.S. Department of Commerce Wilbur L. Ross, Jr., Secretary National Institute of Standards and Technology Walter Copan, NIST Director and Under Secretary of Commerce for Standards and Technology NISTIR 8176 SECURITY ASSURANCE FOR LINUX CONTAINERS National Institute of Standards and Technology Internal Report 8176 37 pages (October 2017) This publication is available free of charge from: https://doi.org/10.6028/NIST.IR.8176 Certain commercial entities, equipment, or materials may be identified in this document in order to describe an experimental procedure or concept adequately. Such identification is not intended to imply recommendation or endorsement by NIST, nor is it intended to imply that the entities, materials, or equipment are necessarily the best available for the purpose. This p There may be references in this publication to other publications currently under development by NIST in accordance with its assigned statutory responsibilities. The information in this publication, including concepts and methodologies, may be used by federal agencies even before the completion of such companion publications. Thus, until each ublication is available free of charge from: http publication is completed, current requirements, guidelines, and procedures, where they exist, remain operative. For planning and transition purposes, federal agencies may wish to closely follow the development of these new publications by NIST.
    [Show full text]
  • Oracle VM Virtualbox Container Domains for SPARC Or X86
    1 <Insert Picture Here> Virtualisierung mit Oracle VirtualBox und Oracle Solaris Containern Detlef Drewanz Principal Sales Consultant SAFE HARBOR STATEMENT The following is intended to outline our general product direction. It is intended for information purposes only, and may not be incorporated into any contract. It is not a commitment to deliver any material, code, or functionality, and should not be relied upon in making purchasing decisions. The development, release, and timing of any features or functionality described for Oracle’s products remains at the sole discretion of Oracle. In addition, the following is intended to provide information for Oracle and Sun as we continue to combine the operations worldwide. Each country will complete its integration in accordance with local laws and requirements. In the EU and other non-EU countries with similar requirements, the combinations of local Oracle and Sun entities as well as other relevant changes during the transition phase will be conducted in accordance with and subject to the information and consultation requirements of applicable local laws, EU Directives and their implementation in the individual members states. Sun customers and partners should continue to engage with their Sun contacts for assistance for Sun products and their Oracle contacts for Oracle products. 3 So .... Server-Virtualization is just reducing the number of boxes ? • Physical systems • Virtual Machines Virtualizationplattform Virtualizationplattform 4 Virtualization Use Workloads and Deployment Platforms
    [Show full text]
  • In Search of the Ideal Storage Configuration for Docker Containers
    In Search of the Ideal Storage Configuration for Docker Containers Vasily Tarasov1, Lukas Rupprecht1, Dimitris Skourtis1, Amit Warke1, Dean Hildebrand1 Mohamed Mohamed1, Nagapramod Mandagere1, Wenji Li2, Raju Rangaswami3, Ming Zhao2 1IBM Research—Almaden 2Arizona State University 3Florida International University Abstract—Containers are a widely successful technology today every running container. This would cause a great burden on popularized by Docker. Containers improve system utilization by the I/O subsystem and make container start time unacceptably increasing workload density. Docker containers enable seamless high for many workloads. As a result, copy-on-write (CoW) deployment of workloads across development, test, and produc- tion environments. Docker’s unique approach to data manage- storage and storage snapshots are popularly used and images ment, which involves frequent snapshot creation and removal, are structured in layers. A layer consists of a set of files and presents a new set of exciting challenges for storage systems. At layers with the same content can be shared across images, the same time, storage management for Docker containers has reducing the amount of storage required to run containers. remained largely unexplored with a dizzying array of solution With Docker, one can choose Aufs [6], Overlay2 [7], choices and configuration options. In this paper we unravel the multi-faceted nature of Docker storage and demonstrate its Btrfs [8], or device-mapper (dm) [9] as storage drivers which impact on system and workload performance. As we uncover provide the required snapshotting and CoW capabilities for new properties of the popular Docker storage drivers, this is a images. None of these solutions, however, were designed with sobering reminder that widespread use of new technologies can Docker in mind and their effectiveness for Docker has not been often precede their careful evaluation.
    [Show full text]
  • ISSN: 1804-0527 (Online) 1804-0519 (Print) Vol.8 (2), PP. 63-69 Introduction During the Latest Years, a Lot of Projects Have Be
    Perspectives of Innovations, Economics & Business, Volume 8, Issue 2, 201 1 EVALUATION OF PERFORMANCE OF SOLARIS TRUSTED EXTENSIONS USING CONTAINERS TECHNOLOGY EVALUATION OF PERFORMANCE OF GENTI DACI SOLARIS TRUSTED EXTENSIONS USING CONTAINERS TECHNOLOGY Faculty of Information Technology Polytechnic University of Tirana, Albania UDC: 004.45 Key words: Solaris Containers. Abstract: Server and system administrators have been concerned about the techniques on how to better utilize their computing resources. Today, there are developed many technologies for this purpose, which consists of running multiple applications and also multiple operating systems on the same hardware, like VMWARE, Linux-VServer, VirtualBox, Xen, etc. These systems try to solve the problem of resource allocation from two main aspects: running multiple operating system instances and virtualizing the operating system environment. Our study presents an evaluation of scalability and performance of an operating system virtualization technology known as Solaris Containers, with the main objective on measuring the influence of a security technology known as Solaris Trusted Extensions. Solaris. We will study its advantages and disadvantages and also the overhead that it introduces to the scalability of the system’s main advantages. ISSN: 1804 -0527 (online) 1804 -0519 (print) Vol.8 (2), PP. 63 -69 Introduction administration because there are no multiple operating system instances in a system. During the latest years, a lot of projects have been looking on virtualizing operating system Operating systems environments, such as FreeBSD Jail, Linux- VServer, Virtuozzo etc. This virtualization technique is based in using only one underlying Solaris/OpenSolaris are Operating Systems operating system kernel. Using this paradigm the performing as the main building blocks of computer user has the possibility to run multiple applications systems; they provide the interface between user in isolation from each other.
    [Show full text]
  • Hypervisors Vs. Lightweight Virtualization: a Performance Comparison
    2015 IEEE International Conference on Cloud Engineering Hypervisors vs. Lightweight Virtualization: a Performance Comparison Roberto Morabito, Jimmy Kjällman, and Miika Komu Ericsson Research, NomadicLab Jorvas, Finland [email protected], [email protected], [email protected] Abstract — Virtualization of operating systems provides a container and alternative solutions. The idea is to quantify the common way to run different services in the cloud. Recently, the level of overhead introduced by these platforms and the lightweight virtualization technologies claim to offer superior existing gap compared to a non-virtualized environment. performance. In this paper, we present a detailed performance The remainder of this paper is structured as follows: in comparison of traditional hypervisor based virtualization and Section II, literature review and a brief description of all the new lightweight solutions. In our measurements, we use several technologies and platforms evaluated is provided. The benchmarks tools in order to understand the strengths, methodology used to realize our performance comparison is weaknesses, and anomalies introduced by these different platforms in terms of processing, storage, memory and network. introduced in Section III. The benchmark results are presented Our results show that containers achieve generally better in Section IV. Finally, some concluding remarks and future performance when compared with traditional virtual machines work are provided in Section V. and other recent solutions. Albeit containers offer clearly more dense deployment of virtual machines, the performance II. BACKGROUND AND RELATED WORK difference with other technologies is in many cases relatively small. In this section, we provide an overview of the different technologies included in the performance comparison.
    [Show full text]
  • The Server Virtualization Landscape, Circa 2007
    ghaff@ illuminata.com Copyright © 2007 Illuminata, Inc. single user license Gordon R Haff Illuminata, Inc. TM The Server Virtualization Bazaar, Circa 2007 Inspired by both industry hype and legitimate customer excitement, many Research Note companies seem to have taken to using the “virtualization” moniker more as the hip phrase of the moment than as something that’s supposed to convey actual meaning. Think of it as “eCommerce” or “Internet-enabled” for the Noughts. The din is loud. It doesn’t help matters that virtualization, in the broad sense of “remapping physical resources to more useful logical ones,” spans a huge swath of Gordon Haff technologies—including some that are so baked-in that most people don’t even 27 July 2007 think of them as virtualization any longer. Personally licensed to Gordon R Haff of Illuminata, Inc. for your personal education and individual work functions. Providing its contents to external parties, including by quotation, violates our copyright and is expressly forbidden. However, one particular group of approaches is capturing an outsized share of the limelight today. That would, of course, be what’s commonly referred to as “server virtualization.” Although server virtualization is in the minds of many inextricably tied to the name of one company—VMware—there are many companies in this space. Their offerings include not only products that let multiple virtual machines (VMs) coexist on a single physical server, but also related approaches such as operating system (OS) virtualization or containers. In the pages that follow, I offer a guide to today’s server virtualization bazaar— which at first glance can perhaps seem just a dreadfully confusing jumble.
    [Show full text]
  • Virtual Containers: Asset Management Best Practices and Licensing Considerations
    Virtual Containers: Asset Management Best Practices and Licensing Considerations Virtual containers have seen tremendous adoption and growth within all industries. However, in terms of IT asset management, cont- ainers are not being managed and are an unknown area of risk for many of our clients. Because it is a newer technology, there is very little information about managing containers and how to address the emerging SAM & ITAM challenges they bring. Due to this lack of public information, Anglepoint has published this whitepaper on navigating the world of containers, with an empha- sis on asset management and licensing. We will cover everything from the history of containers, to what containers are, the benefits of containers, asset management best practices, and some publisher-specific licensing considerations. A BRIEF HISTORY OF VIRTUAL CONTAINERS The first proper containers came from the Linux world as LXC (LinuX Containers) in 2008. However, it wasn’t until 2013 that containers entered the IT public consciousness, when Docker came onto the scene with Enterprise usage in mind. Even then, though, it was more of an enthusiast’s technology. In 2015, Google released and open sourced Kubernetes which manages and ‘orchestrates’ containers. However, it wasn’t until 2017 that Docker and Kubernetes had matured enough to be considered for production use within corporate environments. 2017 also saw VMware, Microsoft, and Amazon beginning to support and offer solutions for Kubernetes and Docker on their top-tier cloud infrastructure. WHAT IS A CONTAINER? Often, people conflate the term ‘container’ with multiple technologies that make up the container ecosystem. Let’s look at what a modern container is at the most fundamental level.
    [Show full text]
  • Systemd As a Container Manager
    systemd as a Container Manager Seth Jennings [email protected] Texas Linux Fest 2015 8/21/2015 Agenda ● Very quick overview of systemd ● What is a Linux Container ● systemd as a Container Manager ● Live Demo! Because I like to punish myself! Disclaimer What is systemd? ● systemd is a suite of system management daemons, libraries, and utilities designed as a central management and configuration platform for the Linux operating system. How Big Is This “Suite” ● systemd - init process, pid 1 ● journald ● logind ● udevd ● hostnamed ● machined ● importd ● networkd ● resolved ● localed ● timedated ● timesyncd ● and more! Don't Leave! ● No deep dive on all of these ● Focus on using systemd for container management – Spoiler alert: many of the systemd commands you already use work on containers managed by systemd too! What is a Linux Container ● What it is not – Magic ● conjured only from the mystical language of Go – Virtualization (hardware emulation) – A completely new concept never before conceived of by man since time began – An image format – An image distribution mechanism – Only usable by modular (microservice) applications at scale What is a Linux Container ● A resource-constrained, namespaced environment, initialized by a container manager and enforced by the kernel, where processes can run – kernel cgroups limits hardware resources ● cpus, memory, i/o ● special cgroup filesystem /sys/fs/cgroup – kernel namespacing limits resource visibility ● mount, PID, user, network, UTS, IPC ● syscalls clone(), setns(), unshare() What is a Linux Container ● The set of processes in the container is rooted in a process that has pid 1 inside the pid namespace of the container ● The filesystem inside the container can be as complex as a docker image or as simple as a subdirectory on the host (think chroot).
    [Show full text]
  • Resource Management: Linux Kernel Namespaces and Cgroups
    Resource management: Linux kernel Namespaces and cgroups Rami Rosen [email protected] Haifux, May 2013 www.haifux.org 1/121 http://ramirose.wix.com/ramirosen TOC Network Namespace PID namespaces UTS namespace Mount namespace user namespaces cgroups Mounting cgroups links Note: All code examples are from for_3_10 branch of cgroup git tree (3.9.0-rc1, April 2013) 2/121 http://ramirose.wix.com/ramirosen General The presentation deals with two Linux process resource management solutions: namespaces and cgroups. We will look at: ● Kernel Implementation details. ●what was added/changed in brief. ● User space interface. ● Some working examples. ● Usage of namespaces and cgroups in other projects. ● Is process virtualization indeed lightweight comparing to Os virtualization ? ●Comparing to VMWare/qemu/scaleMP or even to Xen/KVM. 3/121 http://ramirose.wix.com/ramirosen Namespaces ● Namespaces - lightweight process virtualization. – Isolation: Enable a process (or several processes) to have different views of the system than other processes. – 1992: “The Use of Name Spaces in Plan 9” – http://www.cs.bell-labs.com/sys/doc/names.html ● Rob Pike et al, ACM SIGOPS European Workshop 1992. – Much like Zones in Solaris. – No hypervisor layer (as in OS virtualization like KVM, Xen) – Only one system call was added (setns()) – Used in Checkpoint/Restart ● Developers: Eric W. biederman, Pavel Emelyanov, Al Viro, Cyrill Gorcunov, more. – 4/121 http://ramirose.wix.com/ramirosen Namespaces - contd There are currently 6 namespaces: ● mnt (mount points, filesystems) ● pid (processes) ● net (network stack) ● ipc (System V IPC) ● uts (hostname) ● user (UIDs) 5/121 http://ramirose.wix.com/ramirosen Namespaces - contd It was intended that there will be 10 namespaces: the following 4 namespaces are not implemented (yet): ● security namespace ● security keys namespace ● device namespace ● time namespace.
    [Show full text]
  • Container-Based Virtualization for Byte-Addressable NVM Data Storage
    2016 IEEE International Conference on Big Data (Big Data) Container-Based Virtualization for Byte-Addressable NVM Data Storage Ellis R. Giles Rice University Houston, Texas [email protected] Abstract—Container based virtualization is rapidly growing Storage Class Memory, or SCM, is an exciting new in popularity for cloud deployments and applications as a memory technology with the potential of replacing hard virtualization alternative due to the ease of deployment cou- drives and SSDs as it offers high-speed, byte-addressable pled with high-performance. Emerging byte-addressable, non- volatile memories, commonly called Storage Class Memory or persistence on the main memory bus. Several technologies SCM, technologies are promising both byte-addressability and are currently under research and development, each with dif- persistence near DRAM speeds operating on the main memory ferent performance, durability, and capacity characteristics. bus. These new memory alternatives open up a new realm of These include a ReRAM by Micron and Sony, a slower, but applications that no longer have to rely on slow, block-based very large capacity Phase Change Memory or PCM by Mi- persistence, but can rather operate directly on persistent data using ordinary loads and stores through the cache hierarchy cron and others, and a fast, smaller spin-torque ST-MRAM coupled with transaction techniques. by Everspin. High-speed, byte-addressable persistence will However, SCM presents a new challenge for container-based give rise to new applications that no longer have to rely on applications, which typically access persistent data through slow, block based storage devices and to serialize data for layers of block based file isolation.
    [Show full text]
  • Containerisation Gareth Roy Gridpp 32, Pitlochry 1 Intermodal Containers
    Containerisation Gareth Roy GridPP 32, Pitlochry "1 Intermodal Containers Developed by Malcolm P. McLean & Keith W. Tantlinger. Reaction to slow loading times produced by using “break bulk cargo.” Apparatus for shipping freight (1958): “In 1956, loose cargo cost $5.86 per ton US 2853968 A - Malcolm P McLean to load. Using an ISO shipping container, the cost was reduced to only .16 cents per ton.” IMPERIAL METRIC Length 19’ 10.5” 6.058 m Width 8’ 0” 2.438 m Height 8’ 6” 2.591 m Empty Weight 4,850 lb 2,200 kg Max Weight 66,139 lb 30,400 kg "2 Mærsk Mc-Kinney Møller (18270 TEU) Linux Containers Form of OS Level Virtualisation. Kernel hosts multiple separated user-land instances (Virtual Environment/Engine). Application Low overheads, elastic, multi-tennant. VE Storage can be Copy-on-Write or use UnionFS OS Examples: chroot (1982) Solaris Containers (2005) Physical Hardware FreeBSD Jails (1988) AIX WPARS (2007) Virtuozzo (2001) LXC (2008) OpenVZ (2005) "3 VM’s vs Containers Application Application Application Application Guest OS Guest OS VE VE Virtual HW Virtual HW OS Hypervisor / OS Physical Hardware Physical Hardware Virtual Machine Linux Container "4 VM’s vs Containers (Arguments) Pros: Pros: OS Independent Lightweight / Dense Secure / Isolated Fast Instantiation Flexible Elastic Resource Live Migration Low Memory Consumption Mature Ecosystem Native Performance Cons: Cons: Full System Image Restricted / Linux Only Slow Startup/Shutdown/Build Shared Kernel Memory Consumption Overhead Security Model Opaque to System Young Ecosystem Virtual Machine Linux Container "5 Containers in More Detail Running Application Application Application Instanced Namespace Virtual Environment Virtual Environment Resource Control Group Container CGROUP Container CGROUP Kernel Namespace Layer PID MNT IPC NET UTS USER* Linux Kernel > 2.6.23 OS Physical Hardware "6 Namespaces Application A Namespace wraps a global resource and presents an isolated instance to running process.
    [Show full text]
  • Ubuntu Server Guide Basic Installation Preparing to Install
    Ubuntu Server Guide Welcome to the Ubuntu Server Guide! This site includes information on using Ubuntu Server for the latest LTS release, Ubuntu 20.04 LTS (Focal Fossa). For an offline version as well as versions for previous releases see below. Improving the Documentation If you find any errors or have suggestions for improvements to pages, please use the link at thebottomof each topic titled: “Help improve this document in the forum.” This link will take you to the Server Discourse forum for the specific page you are viewing. There you can share your comments or let us know aboutbugs with any page. PDFs and Previous Releases Below are links to the previous Ubuntu Server release server guides as well as an offline copy of the current version of this site: Ubuntu 20.04 LTS (Focal Fossa): PDF Ubuntu 18.04 LTS (Bionic Beaver): Web and PDF Ubuntu 16.04 LTS (Xenial Xerus): Web and PDF Support There are a couple of different ways that the Ubuntu Server edition is supported: commercial support and community support. The main commercial support (and development funding) is available from Canonical, Ltd. They supply reasonably- priced support contracts on a per desktop or per-server basis. For more information see the Ubuntu Advantage page. Community support is also provided by dedicated individuals and companies that wish to make Ubuntu the best distribution possible. Support is provided through multiple mailing lists, IRC channels, forums, blogs, wikis, etc. The large amount of information available can be overwhelming, but a good search engine query can usually provide an answer to your questions.
    [Show full text]