Classes de virtualisation et Cloud Computing

En règle générale, il existe trois types de classes d’architecture de machine virtuelle (VM). Ce sont l’hyperviseur, la virtualisation basée sur l’hôte et la para-virtualisation.

Ces classes sont différenciées par la position de la couche de virtualisation. L’hyperviseur est également appelé moniteur de machine virtuelle (VMM).

Architecture d’hyperviseur

L’hyperviseur prend en charge la virtualisation de niveau matériel sur les périphériques sans OS tels que le processeur, la mémoire, le disque et les interfaces réseau. Le logiciel d’hyperviseur est intercalé directement entre le matériel physique et l’OS, et cette couche de virtualisation est appelée VMM ou hyperviseur.

L’hyperviseur fournit des hyperappels pour les OS invités et les applications. Deux architectures d’hyperviseur sont mises en œuvre : une de type micro-noyau, telle que Microsoft Hyper-V, et l’autre, de type monolithique, par exemple VMware ESX pour la virtualisation de serveurs.

Un hyperviseur à micro-noyau inclut uniquement les fonctions de base et celles qui n’évoluent pas (par exemple la gestion de la mémoire physique et l’ordonnancement du processeur). Les pilotes de périphériques et autres composants modifiables sont placés à l’extérieur. Un hyperviseur monolithique implémente toutes les fonctions précédentes, y compris celles des pilotes de périphériques.

Par conséquent, le code d’un hyperviseur à micro-noyau est plus compact que celui d’un hyperviseur monolithique. Pour l’essentiel, un hyperviseur doit être capable de convertir des périphériques physiques en ressources virtuelles dédiées à la VM déployée.

L’architecture Xen

Xen est un programme d’hyperviseur open source développé par l’Université de Cambridge. Les composants de base d’un système Xen sont l’hyperviseur, le noyau et les applications, et leur organisation est importante.

A l’instar d’autres systèmes de virtualisation, de nombreux OS invités peuvent s’exécuter par-dessus l’hyperviseur. Toutefois, tous les OS invités ne sont pas égaux et un en particulier contrôle les autres. Cet OS invité particulier est appelé Domaine 0 et les autres, Domaine U. Domaine 0 est un OS invité privilégié de Xen. Il est chargé pour la première fois lorsque Xen démarre sans aucun pilote de système de fichiers disponible. Domaine 0 est conçu pour accéder directement au matériel et pour gérer les périphériques. Par conséquent, une de ses tâches est d’allouer et de mapper les ressources matérielles pour les domaines invités (Domaine U).

Xen est un hyperviseur à micro-noyau, qui sépare la stratégie du mécanisme. L’hyperviseur Xen implémente tous les mécanismes et laisse à Domaine 0 le soin de gérer la stratégie. Il n’inclut aucun pilote de périphérique en natif. Il se contente de fournir un mécanisme permettant à un OS invité d’accéder directement à d’autres périphériques physiques.

Par conséquent, l’hyperviseur Xen demeure relativement compact. Xen fournit un environnement virtuel intercalé entre le matériel et l’OS, et un certain nombre d’éditeurs développent actuellement des hyperviseurs Xen commerciaux, parmi lesquels Citrix XenServer et Oracle VM.

Par exemple, Xen est basé sur Linux et bénéficie d’un niveau de sécurité C2. Sa VM de gestion est appelée Domaine 0, laquelle a le privilège de gérer d’autres VM mises en œuvre sur le même hôte. Si Domaine 0 est compromis, le pirate informatique peut contrôler l’ensemble du système. Ainsi sur le système de VM, vous avez besoin de stratégies de sécurité pour améliorer la sécurité de Domaine 0. Puisque Domaine 0 se comporte comme un VMM, il permet aux utilisateurs de créer, de copier, d’enregistrer, de lire, de modifier, de partager, de migrer et d’annuler des VM aussi facilement que pour un fichier. Malheureusement, cela introduit aussi des problèmes de sécurité pendant le cycle de vie du logiciel et pendant la durée de vie des données.

Traditionnellement, vous pouvez considérer la durée de vie d’une machine comme une ligne droite. L’état courant de la machine constitue un point qui progresse de manière monotone au fur et à mesure de l’exécution du logiciel. Pendant ce temps, vous modifiez la configuration, installez des logiciels et appliquez des correctifs.

Dans un tel environnement, l’état de la VM est proche de celui d’un arbre : en n’importe quel point, l’exécution peut aller vers N branches différentes, où de multiples instances d’une VM peuvent exister en n’importe quel point de cet arbre à cet instant donné.

Les VM peuvent revenir à des états précédents (roll back) de leur exécution (par exemple, pour corriger des erreurs de configuration) ou repartir du même point d’exécution de nombreuses fois (par exemple, afin de distribuer du contenu dynamique ou de faire circuler une image de système « live »).