Sommaire- Aperçu sur la Virtualisation
- Xen Aujourd'hui : 3.0
- Architecture
- Performance
- Migration de VM en « live »
- Xen et l'avenir
Aperçu sur 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
Xen aujourd'hui : 3.0- Isolation sécurisé entre les VMs
- Contrôle des ressources et du QoS
- 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
- Performance des binaires très proche du natif
- Supporte le même matériel que Linux x86
- Relocalisation en direct de VM entre noeud XEN
Para-Virtualisation de Xen- 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
SMP Guest Kernels- Xen étend son support à de multiple VCPUs
- Virtuel IPI’s sont envoyés via « Xen event channels »
- Actuellement 32 VCPUs sont supportés
- 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.
SMP Guest Kernels- 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 »
x86_32 - 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
x86_64 - 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
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
- Infiniband / Smart NICs en direct pour les E/S d'une VM
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
Migration 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
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!
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
3.1 feuille de route- Amélioration du support virtualisation complète
- Pacifica / VT-x abstraction
- Plus d'outils pour le contrôle du projet
- Tuning et optimisation des performances
- Eviter les problèmes liés à la configuration manuel
- Support de Infiniband / Smart NIC
- NUMA, Virtual framebuffer, etc
Feuille de route “recherche”- Algorithmes de load balancing de cluster
- Modèle pour des migrations automatisées (CPU/RAM/IO)
- Cluster distribué
- Tolérance de panne logiciel
- Exploitation déterministe « replay »
- Système de debugging
- Alléger le “checkpointing” et le “replay”
- VM “forking »
- Alléger le service de replication et d'isolation
- Securisation de la virtualisation
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
Conclusions- Xen est une solution compléte et robuste de VMM GPL
- Exeptionnel 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'indisponabilité et de maintenance
- http://xenfr.org
- http://xensource.com
- http://xen.sf.net