IE Paper Template

International Conference Proceedings

ISTI-2016

Virtualization of ANA resources through Linux Containers Besmir ZANAJ1, Arjan XHELAJ2, Taulant NGJELO3 123 Academic Network of Albania {bzanaj, arjanxhelaj, tngjelo}@rash.al Abstract

Linux containers—compartmentalized and isolated application environments—offer utility, scalability, and low development and implementation costs. Such savings and functionality allow organizations to grow and adapt their IT infrastructure. This paper provides a short description on container technology, two of the main approaches LXC and LXD, how it works, and its benefits while being applied in the Academic Network of Albania. Keywords: Containers, LXC, LXD, Docker, Virtualization, Linux, Ubuntu, RASH

1. Introduction The project on the “Creation of an Inter-University Service Center and a Telematic Network” aims at improving and strengthening of the Albanian University System as the teaching source of the highest level in the country and at promoting scientific research. The Inter-University Center will offer software services to both public universities, research institutes, and will manage the Albanian Academic Network [1]. Established for the first time in Albania, the Academic Network of Albania (ANA), is connecting the higher education institutions to the scientific research institutes and to the Transfer Technology Center. Among other objectives, the project will contribute towards strengthening and boosting management capacities of the Albanian public higher education and of the research institutions, thus developing high caliber professionals and guaranteeing participation to different research programs/projects both at the European and International level. To better utilize its resources, ANA has put efforts in developing a new virtualization platform that needed to be lightweight, license free and scriptable through an Application Programming Interface (API). While evaluating products in the market the best solution was to implement an open source solution and well documented such as Linux Containers. After initial testing and deployment of some ANA services over Linux Containers, LXD technology is offering ANA the following benefits:  Full operating system functionality within containers, not just single processes  Maximum density of guests per host, providing a cost benefit when running in a public cloud  Allows easy management and sharing of hardware resources, and easy monitoring of customer processes directly from the host level  REST API, and simple, single command line with proper help and documentation  Support for architectures under‐served by full virtualization  Rapid provisioning, instant guest boot  Tightly integrated with remote image services  Intelligent, extensible storage and networking

1


ISTI-2016

2. What are Linux containers Linux containers offer operating system-level virtualization for running multiple applications on a single host [2]. Each container is a self-contained environment or “sandbox,” where an application uses a dedicated set of network interfaces, routing tables, and entries while sharing the OS kernel with other containers. Key attributes of containers include:  A separate file system namespace provided by a directory subtree from which a container is built. Processes within a container are not allowed to escape outside the subtree.  A separate process ID (PID) namespace. A process created within the container only sees other processes created within the container.  A separate network IP address only visible in the container.  A separate hostname unique to that container.  A separate IPC namespace. Shared resources such as memory, semaphores, and message queues are visible only to processes within the namespace. Containers have their own root, and users and processes are not allowed to perform operations outside of the associated container environment (Figure 1).

Figure 1 – Container environment

The similarity in the use of containers and virtual machines (VMs) (resource and namespace isolation) spawns frequent comparisons between the two. Figure 2 compares the stacks involved in VMs and containers. On a system with VMs, a process running on a hypervisor (or host OS) executes an application that emulates a machine interface for a VM’s guest OS kernel [3], initialization system, library, and application(s). On a system with containers, the OS kernel is shared with other containers, of which there can be different types [4]. An “OS container” may have its own binaries, libraries and system init, while an “Application Container” may only have an application. Because a VM has a static number of virtual CPUs (vCPUs) and a fixed amount of RAM, its resource consumption is naturally bounded. A vCPU cannot use more than one real CPU worth of cycles and each page of vRAM maps to at most one page of physical RAM [5]. Unlike a VM which runs a full operating system, a container can contain as little as a single process. Since an application container does not waste RAM on redundant management processes it

2


ISTI-2016

generally consumes less RAM than an equivalent system container or VM [6].

Figure 2 Two VMs on a single system

Figure 3 Two Linux containers on a single system

Data center considerations Determining the suitability of Linux containers in our environment, will bring to us a number of considerations. These considerations include evaluating our current process and technology models, data protection and security requirements, and software management needs:  

 

Data protection – In a containerized environment, containers are considered “stateless” and data is typically stored in special volumes. Thus, backup and restoration of data requires a change from the usual way backup technologies work. Security – The VM environment provides a hypervisor that offers a barrier for VMs against attack. In addition, with each VM using a separate (and often different) OS, a vulnerability on one VM is less likely to be leveraged to affect adjacent VMs on the same host. With containers, the responsibility of security is more dependent on the applications. Much of the file-system image (binaries and libraries required by the application) is read-only, but it is important that container images be created cleanly using thorough processes and tools to avoid populating OS images with malware and possibly viruses. At the same time, the management of the nodes (container hosts) must include all the required measures to prevent any tampering with malicious software. Increased interest in containers and proliferation of implementation tools may result in a rise of security vulnerabilities that will need addressing. Application migration – Containers were created for native cloud applications where the philosophy of micro-services architecture and application function partitioning is a well-known practice Basic system requirements – The following basic requirements must be met for applications to work in Linux containers: o The application must be Linux-based. o Any Linux OS dependencies must be fulfilled by the underlying OS on the host. For instance, Docker requires the Linux 3.10 (or later) kernel. o The application should be well-behaved using standard interfaces. o The application should not have any dependencies on non-standard kernel mods. o Security and separation requirements can be satisfied with a combination of chroot, cgroups, kernel namespace separation, and SELinux or AppArmor policy profiles.

3


ISTI-2016

Table 1 – Differences between a Virtual Machine and a Container

Tenant management Startup Required components Application compatibility OS management Security

Performance Isolation Resource utilization

VM Hypervisor Requires OS boot

Linux Container None (bare metal) Process started immediately. No boot needed Application, OS, virtual Application container & OS hardware resources container May vary between VMs Must be Linux-based across (Windows, Linux, etc.) the host system 2x booting, OS resources, Single instance OS booting multi-license management and license management. Hypervisor provides attack Needs consideration to avoid barrier security issues from adjacent containers Paravirtualize to approach Bare metal performance bare metal performance Better isolation for misbe- Kernel-invasive applications haved application may be problematic Bulky – impacts memory Skinny – requires less reand network resources, sources and transfer time requires more transfer time

With the most up-to-date Linux distros likely to improve on container-centric features and capabilities, requirements may change, but an application that meets the above requirements will most likely be satisfied with the separation and isolation provided by a container while consuming fewer resources. We are realizing the benefits of much faster initialization and boot time, more containers per machine resource, dynamic resource scaling, and bare metal performance with the required separation and isolation. If the application is already “good-to-go” in a multi-tenancy environment, containers might be a viable alternative. Container patterns (such as provided by Docker) will allow to ANA for degrees of freedom in deploying application stacks. For instance, a properly built container can abstract many dependencies and allow application deployment on many different servers, both physical and virtual, and in many different cloud environments (such as OpenStack and Amazon environments). An application that might disrupt neighboring applications in a particular environment can become a good tenant in isolation by encapsulating it into a container. 3. Setting up the Linux container environment The process of setting up a Linux OS host to support the LXC technology is pretty straightforward. We have chosen the Ubuntu operating v 14.04 to implement the Linux containers technology by installing the two main packages and their respective dependencies. The first package is LXC installed by running this command in the console [7]: root@ubuntu-server:~# apt-get install lxc

Afterwards we have to install the LXD package and its dependencies by running the following command in the console [8]:

4


ISTI-2016

root@ubuntu-server:~# apt-get -t trusty-backports install lxd

The next step is to run the following command to configure the basic minimum configurations for the containers workspace. root@ubuntu-server:~# lxd init

This initial configuration is needed to define the default storage to be used for the new containers, to create a new bridge network adapter and then configuring the DHCP/NAT options for this new network adapter. After successfully running the “lxd init” command we now have a fully working Linux Operating System kernel with Linux containers technology installed and ready to configure and/or start our new containers. In order to reduce the time for system administrators to manage the containers themselves and introduce automation in creating, deleting, modifying, starting and stopping the containers instances. We introduce LXC Web Panel [9] as a modern tool similar to the familiar tools from big companies such as Citrix, VMWare and Microsoft Hyper-V to manage the newly created infrastructure. Users and system administratrs are now presented a web interface for the underlying container management system LXC and LXD. The web panel is accessed as instructed in the final steps of the LXC Web Panel instructions as shown here: Installation complete! Adding /etc/init.d/lwp... Done Starting server...done. Connect you on http://your-ip-address:5000/ root@ubuntu-server:~#

After logging in, creating a new container is as simple as pressing the “Create” button in our new web interface as shown in figure 4.

Figure 4 – Container creation

The initial creation step will take some time since LXC will have to download first the image template for the specific Linux distribution. After getting the template the next containers based off that image will take seconds to be created. The control panel that LXC Web Panel is making available to system administrators is shown in Figure 5.

5


ISTI-2016

Figure 5 - LXC Web Panel

4. LXC/D in the Academic Network of Albania A major Albanian bank was kind enough to donate ANA a complete HP Blade server system that ANA is going to use it primary for research purposes and then contribute in the GEANT working groups. We need to develop, test and implement such tools as Eduroam, EduGain etc in a very short time. By using the newly donated infrastructure we aim to create a very flexible and dynamic implementation model for these research projects to achieve success in very tight deadlines. By comparison, if a research staff member would have to request a new server for his research purposes, ANA system administrators would have to create a new Virtual Machine from our Virtual Machine Hypervisors, set-up the new server, configure and provision storage and networking and then give these credentials to the researcher. Instead by creating dedicated scoped groups in the LXC Web Panel we are giving the researcher to create and clone as many times he needs a new machine and achieve this in seconds instead of hours or even days (Table 2). Table 2 – Provision time for VM and Container model

Create new Machine Install operating system

VM Hypervisor model 30 sec 40 min – 2 hrs

10 min Configure storage 10 min – 20 min Configure network Provide access for the new server 1 hr

Container model 10 sec 20 first time 5 sec afterwards 0 0 0

As we can see the time gain in administering such infrastructure and achieving user satisfaction allows ANA to better utilize the IT resources and deliver IT services in a timely fashion.

6


ISTI-2016

5. Conclusions The container technology has a lot to offer and since it is still in its early stages of development will be changing. The real challenge from the LXD and LXC working teams is to ensure hardware‐assisted security and isolation for the containers, just like virtual machines are today. We need to ensure that the kernel security cross‐section for individual containers can be tightened up for each specific workload. Also a great feature ANA is looking for is the live‐migration of these containers from machine to machine. A great functionality of Linux containers is the ability to bind storage and network interfaces to the containers, just like virtual machines. All of this work from ANA is aimed at giving the system administrators the full experience of virtual machines and the full security of a hypervisor, but much, much faster. Without all that virtualization overhead, we are getting the full underlying performance of your host environment. On bare metal, these containers are just as fast as the native OS. If ANA containers were to be run in the cloud, we are going to get subdivided machines without sub‐par performance. The technical advantages of accessing the Linux kernel directly combined with the ability to leverage such containers in a very short timeframe give ANA a great position in the Albanian research marketplace by helping other organizations use this know-how in their IT environments.

References [1] Rrjeti Akademik Shqiptar, "Academic Network of Albania," [Online]. Available: https://www.rash.al/home-en/. [2] HP, "Linux container technology," HP Technical white paper, 2015. [3] VMWare, "Virtualization Overview," VMWare, 2006. [4] Linux Containers, "What's LXC?," [Online]. Available: https://linuxcontainers.org/lxc/introduction/. [5] Wikipedia, "LXC," Wikimedia, [Online]. Available: https://en.wikipedia.org/wiki/LXC. [6] IBM Research Division, "An Updated Performance Comparison of Virtual Machines," Austin Research Laboratory, Austin, 2014. [7] Linux Containers, "Installing LXD and the command line tool," [Online]. Available: https://linuxcontainers.org/lxd/getting-started-cli/. [8] Ubuntu Linux, "Getting started with LXD – the container lightervisor," [Online]. Available: https://insights.ubuntu.com/2015/04/28/getting-started-with-lxd-thecontainer-lightervisor/. [9] "LXC Web Panel," LXC Web Panel 2013, [Online]. Available: http://lxcwebpanel.github.io/index.html.

Dr. Arjan XHELAJ – PhD in Biophysics & Applied Physics, Dr.Phil.Nat. in Physic in University of Frankfurt am Main. MSc in Engineering in University of Siegen, Germany. Director of Interuniversity Service Center and Telematic Network (Academic Network of Albania). Lead person on establishment of the national Interuniversity Center for ICT services for University Management systems the Telematic Network for Universities, Research Institutes, Academy of Science and the Agencies for Higher Education/ Research/ Innovation. From 2009

7


ISTI-2016

till now Dr. Xhelaj used to exercise leading position at the Education area-Director Higher Education and Research Department (MoES). He also holds teaching positions on Higher Education Institutions. He has a rich research experience in his expertise field. He is Member of Board of Governors in Joint Research Center DC in EU Commission. Besmir ZANAJ – is Head of Infrastructure and Network Department at Academic Network of Albania – ANA. He has a vast experience in system administration and IT management. Experienced in managing complex computer architectures in all OSI layers from physical to advanced distributed applications. He has held position as Senior System Administrator, IT Manager and Information Security Officer working for different companies in Austria, Canada, Italy and Albania. He is an international auditor according the ISO 27001 Information Security Management System Standard. Taulant NGJELO – is one of starters of the Infrastructure and Network Department at Academic Network of Albania – ANA. He has delivered a rich contribute administering the backend of the software used from Albanian Universities. He is also the responsible of implementing and maintaining the Datacenter and Network infrastructure. He owns main network certifications and has a rich background in System Administration.

8