Xen et l' Art de la Virtualization Computer Laboratory Antoine Nivard Responsable technique Adéquat région Ouest Responsable de Site francophone.

Présentation au sujet: "Xen et l' Art de la Virtualization Computer Laboratory Antoine Nivard Responsable technique Adéquat région Ouest Responsable de Site francophone."— Transcription de la présentation:

1 Xen et l' Art de la Virtualization Computer Laboratory Antoine Nivard Responsable technique Adéquat région Ouest Responsable de http://XENfr.org Site francophone de XEN

2 Sommaire  Aperçu sur la Virtualisation  Xen Aujourd'hui : 3.0  Architecture  Performance  Relocation de VM à chaud  Xen et l'avenir

3 La virtualisation Matériel Logiciel de contrôle Drivers OS invité UserSpace OS hôte Drivers OS invité UserSpace Drivers OS invité UserSpace VM 1VM 2VM 3  Consolidation du matériel  Multualisation des ressources  Contôle des ressources  Gestion avancée des VM => Consolidation de serveurs Mettre des machines logiques (OS) sur des machines physiques

4 La virtualisation Matériel HYPERVISEUR Logiciel de contrôle Drivers OS invité UserSpace Drivers OS invité UserSpace Matériel Machine virtuelle Logiciel de contrôle Drivers OS invité UserSpac e Drivers OS invité UserSpac e OS hôte  VMWARE GSX / Server / Workstation  VirtualPC  Les émulateurs  XEN  VMWARE ESX  HypervisorIBM

5 Virtualisation dans l'Entreprise X Consolider les serveurs sous-utilisés et réduire les coût matériel (achats, maintenance, recyclage) et les coûts d'exploitation (administration, pilotage) Eviter les temps d'interruption lié aux migrations Avoir un load-balancing dynamique pour garantir les SLA sur les services/applications X X Renforcer la politique de sécurité

6 Jargon de la virtualisation  Machine physique:  Machine hôte  Dom0  Hyperviseur  Machine virtuelle  Machine guest  VM / MV  DomU

7 Aperçu sur la Virtualisation  Emulation: QEMU, BOCHS  L'émulation n'est pas la virtualisation  Un seul OS: Ensim, Vservers, CKRM  Groupes de processus utilisateurs dans des conteneurs de ressources  Difficile d'avoir une bonne isolation  Virtualisation complète: VMware, VirtualPC  Plusieurs OS sans modifications  Difficile de bien virtualiser le x86  Para-virtualisation: UML, Xen  Plusieurs OS sur une architecture spéciale  Arch Xen/x86 est très proche x86

8 XEN, une solution  Solution serveur  XEN est une des meilleurs solution pour la consolidation de serveurs  Pas la meilleur pour le « Destop »  Excellentes performances, proche du natif! ~1% d'overhead  5 à 10 VM par core  Pour environnements libres  Fonctionne avec tous les environnements libres  « Fonctionne » avec windows sur VT et AM2/Pacifica  Mature pour la production  Fonctionne en production pour des hébergeurs  Solution de sécurité pré-packagés

9 Xen aujourd'hui : 3.1  Isolation sécurisé entre les VM  Pas d'effet de bord  Sécurisation des ressources  Contrôle des ressources  Allocation matériel de type AGP, PCI, USB possible  Gestion fine du réseaux  Réallocation de mémoire à la volée  Réallocation de CPU virtuelle à la volée  Contrôle de la QoS  Relocalisation à chaud de VM entre noeud XEN

10 Xen aujourd'hui : 3.1  Architecture spécifique: Arch/Xen  Seulement le noyau de la VM a besoin d'être porté  Toutes les applications et librairies fonctionnent sans modification  Linux 2.4/2.6: Debian, FedoraCore, Mandriva, SUSE  FreeBSD, OpenSolaris, NetBSD, Plan9  Solution pré-packagés dans les distributions  Performance des binaires très proche du natif  Supporte le même matériel que Linux

11 Para-Virtualisation de Xen  Ring 0 pour le dom0  Ring 1et 2 pour les domU / Ring 3 pour le user-space  Arch xen/x86 : comme x86, mais remplace les instructions privilégiés par des hypercalls XEN  Evite la réécriture de binaires  Pour Linux 2.6, seulement les fichiers “arch-dep” sont modifiés  Modifications relativement simples et isolées dans le code  Modifier l'OS pour un environnement virtualisé  Wall-clock time vs. virtual processor time Xen fournit les deux types de timer  Accès aux réels ressources Optimisation du comportement de l'OS  Virtualisation de la MMU: direct vs. shadow mode

12 Xen 3.1 - Architecture Event Channel Virtual MMUVirtual CPU Control IF Hardware (SMP, MMU, physical memory, Ethernet, SCSI/IDE) Native Devic e Driver GuestOS (XenLinux) Device Manager & Control s/w VM0 Native Devic e Driver GuestOS (XenLinux) Unmodified User Software VM1 Front-End Device Drivers GuestOS (XenLinux) Unmodified User Software VM2 Front-End Device Drivers Unmodified GuestOS (WinXP)) Unmodified User Software VM3 Safe HW IF Xen Virtual Machine Monitor Back-End VT-x x86_32 x86_64 IA64 PPC AGP ACPI PCI PCI-X SMP

13 SMP des domU  Xen étend son support à de multiple VCPUs  Virtuel IPI’s sont envoyés via « Xen event channels »  Actuellement 32 VCPUs sont supportés pour 1 domU  Simple hotplug/unplug de VCPUs  A partir de la VM ou par les outils de contrôle  Optimisation avec un VCPU (par des patch spinlocks sur les binaires)

14 SMP des domU  Bonnes perfomances SMP tant que la sécurité (contrôle) est assurée  Requis extra TLB syncronisation IPIs  L'approche para-virtualisation a de nombreux avantages  Evites plusieurs IPI virtuel  Permet d'éviter « bad preemption »  plug/unplug à chaud et automatiquement de VCPUs  SMP scheduling est un problème complexe  « Strict gang scheduling leads to wasted cycles »

15 ring 3 X86_32 : mémoire et ring  Xen réserve le haut de l'espace VA  Protection de segmentation sur Xen à partir du kernel  La vitesse du “call” ne change pas  Xen 3 supporte un PAE de plus de >4GB mem Kernel Use r 4G B 3G B 0G B Xen S S U ring 1 ring 0

16 X86_64 : mémoire Plus grand espace VA, facilite la vie mais:  Pas de support sur la limite de segment  Besoin d'utiliser la protection de page-level pour protéger hypervisor Kernel Use r 264264 0 Xen U S U Reserved 247247 2 64 - 2 47

17 Architecture des E/S  Xen délégue aux VM des Espace-E/S et celles-ci gérent les accès aux E/S dédiés  Espace de configuration virtuel pour le PCI  Interruptions Virtuelles  Besoin du IOMMU pour la protection en full DMA  Périphériques sont virtualisés et exportés aux VMs via Device Channels  Asynchronous sûr et transport de la mémoire partagé  « Backend » drivers exporter en « frontend » drivers  Net: utilisation normale du bridging, routing, iptables  Block: exporte n'importe quel blk dev e.g. sda4,loop0,vg3  Fibre Channel / Infiniband/ Smart NICs (iSCSI) en direct pour les E/S d'une VM

18 Virtualisation des E/S  IO virtualization in s/w incurs overhead  Latency vs. overhead tradeoff More of an issue for network than storage  Can burn 10-30% more CPU  Solution is well understood  Direct h/w access from VMs Multiplexing and protection implemented in h/w  Smart NICs / HCAs Infiniband, Level-5, Aaorhi etc Will become commodity before too long

19 MMU Micro-Benchmarks LXVU Page fault (µs) LXVU Process fork (µs) 0.0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1.0 1.1 Résultats de lmbench sur Linux (L), Xen (X), VMWare Workstation (V) et UML (U)

20 Performances Système LXVU SPEC INT2000 (score) LXVU Linux build time (s) LXVU OSDB-OLTP (tup/s) LXVU SPEC WEB99 (score) 0.0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1.0 1.1 Benchmark standard sur Linux (L), Xen (X), VMware Workstation (V) et UML (U)

21 Résultats réseaux : TCP LXVU Tx, MTU 1500 (Mbps) LXVU Rx, MTU 1500 (Mbps) LXVU Tx, MTU 500 (Mbps) LXVU Rx, MTU 500 (Mbps) 0.0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1.0 1.1 Bande passante en TCP sur Linux (L), Xen (X), VMWare Workstation (V) et UML (U)

22 Scalability LX 2 LX 4 LX 8 LX 16 0 200 400 600 800 1000 SPEC WEB99 en simultané sur des services sous Linux (L) et Xen(X)

23 VM Relocation : Motivation La relocation de VM permet:  Haute Disponibilité  Maintenance serveur  Load balancing  Gain de preformances Xen

24 Relocation dynamique des VM  A quoi cela peut servir?  Gestion d'un pool de VMs fonctionnant en cluster  Maintenance et mise à jour facile à mettre en oeuvre  Load balancing des VMs à travers le cluster  Un challenge  Les VMs ont plusieurs états possibles  Certaines VMs ont besoin de hautes disponibilités Ex. serveurs web, bases de données, serveurs de jeux  On peut limiter les ressources lors de la migration  Les évolutions  Phase d'analyse pour une migration plus rapide  Relocation à tranvers un WAN (IPSec) et « CoW mirroring»  FileSystem clusterisé (GFS, DRDB) supportant le cluster de XEN

25 Pré-requis  Stockage en réseau  NAS: NFS, CIFS  SAN: Fibre Channel  iSCSI, network block dev  drdb network RAID  Bonne connectivité  Minimum réseau L2  Conseillé L3 re-routeing  => GIGABIT bien sûr! Xen Storag e

26 Etape 0: pré-migration Etape 1: réservation Etape 2: itérative pré-copy Etape 3: pause-et-copie Etape 4: ré-activation Stratégie de relocation VM active sur l'hôte A, la destination de l'hôte cible sélectionné. Les “block devices” sont mirrorés. Initialisation du conteneur sur la cible Copie des pages mémoires en plusieurs fois Pause de VM sur l'hôte A Redirection du traffic réseaux. Synchronisation sur l'état mémoire Activation sur l'hôte B et arrêt de la VM sur l'hôte A

27 Extensions  Cluster et load balancing  Phase d'analyse pour la pré-migration  Optimisation bruts selon des mesures  Fermeture d'un noeud pour maintenance  Migration rapide pour maintenance  Système de stockage supportant le cluster de VM  Décentralisation, réplication de donnés, copy-on-write  Relocation à travers un WAN  Tunnels sur IPSec et « CoW mirroring » en réseaux

28 Vitesse de migration/perte

29 Iterative Progress: SPECWeb 52s

30 Migration d'un serveur Quake 3

31 Iterative Progress: Quake3

32 Etat actuel de la 3.0 Driver Domains VT >4GB memory Save/Restore/Migrate SMP Guests Domaine U Domaine 0 PowerIA64x86_64x86_32px86_32

33 Feuille de route  Optimisation de support VT (Intel) et de Pacifica (AMD)  Meilleurs outils du contrôles des ressources  VM « forking »  Alléger le service de replication et d'isolation  Tolérance de panne logiciel  Exploitation déterministe « replay »  Algorithmes de load balancing de cluster  Modèle pour des migrations automatisées (CPU/RAM/ES)  Cluster distribué (Mosix?)  Securisation de la virtualisation  Multi-level secure Xen

34 VT-x / (Pacifica)  Permet à des OS Guest de fonctionner sans modification de para-virtualisation  E.g. legacy Linux, Windows XP/2003  CPU fournit certaines instructions privilegiées  Le système “Shadow page” est utilisé pour fournir la virtualisation de la MMU  Xen fournit une plateforme simple d'émulation  BIOS, Ethernet (ne2k), IDE emulation  Install des drivers para-virtualisés après le boot pour de haute-performance en E/S

35

36 Conclusions  Xen est une solution complète et robuste de VMM GPL  Exceptionnel performance et “scalability”  Excellent contrôle de ressource et protection  La relocation/migration en directe permet en temps- réel de réduire les temps d'indisponibilité et de maintenance  http://xenfr.org  http://xensource.com  http://xen.sf.net