Basics of Virtualisation Volker Büge Institut für Experimentelle Kernphysik Universität Karlsruhe Die Kooperation von
The x86 Architecture Why do we need virtualisation? x86 based operating systems are designed to run exclusively and directly on the hardware Four different levels of privileges Privileged Ring 0: Privileged access to the hardware resources for the operating system Unprivileged Ring 3: for different user level applications Only one operating system has special privileges for hardware access Need an additional software layer or an extension of the x86 architecture to enable a parallel execution of multiple OS 2 Volker.Buege@cern.ch Institut für Experimentelle Kernphysik 09.09.2008
Concepts of Operating System Virtualisation I Hardware Emulation Emulation of the entire hardware environment for the guest OS Offers large variety of possible system configurations Emulation of the processor, memory and disk space Decreased performance of the guest OS Operating System Container Only one OS kernel is running Guest OS are sub-groups of the host OS Isolation of guest OS by replication of the internal data structure of the kernel Context is defined for each container to offer full runtime environment Only one kernel for all instances possible small performance overhead through tight integration 3 Volker.Buege@cern.ch Institut für Experimentelle Kernphysik 09.09.2008
Concepts of Operating System Virtualisation II Hardware Virtualisation Small number of different virtual hardware components offered Increased performance compared to emulation Guest OS executed in unprivileged program space Hypervisor translates calls of the guest requiring privileges Organises usage of CPU and memory access for the guest No modifications of host and guest OS required Paravirtualisation Hypervisor is running in most privileged and lowest Ring 0 Organises the direct access to the hardware for guest OS No hardware is emulated or virtualised Modifications of the host and guest OS needed Required patches only for Open Source OS available 4 Volker.Buege@cern.ch Institut für Experimentelle Kernphysik 09.09.2008
Virtualisation Products There are plenty of existing products for virtualisation: and many more 5 Volker.Buege@cern.ch Institut für Experimentelle Kernphysik 09.09.2008
Full Virtualisation VMware Workstation Special container for the VM Virtual CPUs, memory, hard disk, network interfaces, USB ports and other common hardware components. Hypervisor is executed as an application of the host OS Limited performance of the VMs VM becomes independent from host configuration Can be used on different host systems VM is stored and runs in files VMs contain native OS and are completely isolated but such hardware emulations cost performance Concept best suited for workstation environments not for server consolidation 6 Volker.Buege@cern.ch Institut für Experimentelle Kernphysik 09.09.2008
Full Virtualisation VMware Workstation WindowsXP host OS with a ScientificLinux VM on this laptop 7 Volker.Buege@cern.ch Institut für Experimentelle Kernphysik 09.09.2008
Full Virtualisation VMware ESX Server Hypervisor kernel directly running on the server hardware Hypervisor does not require large resources Requires supported hardware components Special optimised pass-through drivers for dedicated hardware components Best possible performance Advanced management tools available Near-native performance of the guest OS Optimised for server consolidation 8 Volker.Buege@cern.ch Institut für Experimentelle Kernphysik 09.09.2008
Paravirtualisation (XEN) Different hardware components not fully emulated. It only organises the usages near-native performance Layout of a Xen based system: Privileged host system (Dom0) and unprivileged guest systems (DomUs) DomUs are working cooperatively Guest and host OS has to be adapted to XEN (Kernel-Patch), but not the applications 9 Volker.Buege@cern.ch Institut für Experimentelle Kernphysik 09.09.2008
CPU Support for Virtualisation New processor generations Intel Virtualisation Technology (VT-x, Intel Vanderpool) AMD-V (AMD Pacifica) Offer a new CPU execution mode for a virtual machine monitor (VMM) Privileged calls of the operating system are automatically directed to the VMM Paravirtualisation: Execution of unmodified guest operating systems Hardware Virtualisation: Avoid the step of binary translation VMware products only use this extension to support 64-bit guest systems 10 Volker.Buege@cern.ch Institut für Experimentelle Kernphysik 09.09.2008
Applications - Hardware Consolidation I Typical situation at a grid cluster: for reasons of stability different services like LDAP, the grid portals, should run on different machines varying load on the different machines Resources not fully exploited recycling of older machines leads to a heterogeneous hardware structure high administrative effort for installation and maintenance of the system CE SE MON CE SE MON Single server machine LDAP CUPS Samba LDAP CUPS Samba Virtualisation of these machines leads to few machines to be maintained and to homogenous OS installations 11 Volker.Buege@cern.ch Institut für Experimentelle Kernphysik 09.09.2008
Applications - Hardware Consolidation II but what happens if the host machine dies? Failure of: disks, motherboard, memory, power supply, All services which are hosted on this machine will be down until machine is restored or access to VM images possible Need concepts of high availability and quality of service for such scenarios where several services are hosted on one physical host Which techniques can be used to become independent from hardware failures of the host machines? 12 Volker.Buege@cern.ch Institut für Experimentelle Kernphysik 09.09.2008
High Availability I One approach: Storage of the VM file system in a high available and redundant SAN Use host systems with redundant LAN, SAN and power connections Migration on the fly in case of hardware problems or maintenance of one server If insufficient resources are available on the other server, the service level of less critical services can be reduced for short times. Automated tools for load balancing and migration in case of failures exist, e.g for the VMware ESX server. All services can be offered without or with only short interruption, perhaps at lower service level Server 1 VM Server 2 Server 3 SAN 13 Volker.Buege@cern.ch Institut für Experimentelle Kernphysik 09.09.2008
High Availability II Other possibility, e.g for smaller infrastructures: Combination of spare machine and SAN overkill if only few critical services are hosted Need realisation without too much hardware overhead Possibility: Use two performant host machines with same processor architecture and a Distributed Replicated Block Device (DRBD) to mirror disk space between both machines Server 1 Server 2 Local storage containing VM file systems are mirrored on both servers. Local storage DRBD Local storage In case of hardware problems on one server, the VM can easily be migrated or restarted on the other Restricted to a 2 server architecture 14 Volker.Buege@cern.ch Institut für Experimentelle Kernphysik 09.09.2008