Disponibilité des hyperviseurs

La virtualisation et par voie de conséquence sa disponibilité, est devenue un enjeu majeur ces dernières années pour faire face à tout type de défaillances des systèmes réels. Elle permet de réduire les coûts de fonctionnement des systèmes informatiques et augmente la disponibilité des systèmes et des services critiques[11].

Pour utiliser la virtualisation il faut déployer des VMs[note 3] sur un serveur physique. Celles-ci ont besoin d'être contrôlées automatiquement ou manuellement, il faut donc mettre en place un SLO[note 4]. Le composant majeur de ce SLO est la haute disponibilité des systèmes virtualisés[12].

Un certain nombre de procédés ont permis de déterminer des modèles de disponibilité que l'on peut classer en trois groupes[13] :

• Les modèles combinatoires[14].
• Les modèles État-espace[15].
• Les modèles Hybride/hiérarchique[16].

Les solutions de haute disponibilité permettent, en cas de défaillance, de maintenir en état de fonctionnement un système virtualisé quel que soit le problème rencontré : système ou applicatif[6].

La recherche de la disponibilité dans la virtualisation évolue en permanence et s'avère être très difficile à mettre en œuvre. La disponibilité peut être perturbée voire arrêtée à la suite de nombreux événements en particulier sur le système hôte lorsqu'il est défaillant[17].

Un système virtualisé peut être interconnecté avec un nombre important de réseaux hétérogènes[18]. Ce genre de configuration provoque des échanges d'informations et de communications de tout type avec de nombreuses possibilités d'accès malveillants. Dans cette hypothèse, la prévention face aux intrusions est plus difficile à assurer et la tolérance aux pannes face aux intrusions malveillantes est donc fragilisée.

La disponibilité est donc un dispositif perfectible et exposé à de nombreux paramètres de perturbation.

La disponibilité des hyperviseurs concerne aussi bien les hyperviseurs eux-mêmes que les machines virtuelles qu’ils contrôlent. L'organisation DMTF[note 5] a défini des états sémantiques pour les machines virtuelles. La spécification de ces états est[19] :

L'état « Définie »

Il indique que la machine virtuelle est seulement déclarée dans le système. Elle est inactive et ne consomme pas de ressources systèmes.

L'état « Active »

La machine virtuelle fonctionne normalement.

L'état « Pause »

Cet état indique que la machine virtuelle reste instanciée mais ne permet pas d'exécuter de tâches.

L'état « Suspendue »

La machine virtuelle et ses ressources sont stockées dans une mémoire non volatile. Cet état ne permet pas d'exécuter des opérations.

L'équipe de l'entreprise IBM dirigée par Erin M. Farr a mis en place des niveaux de disponibilité en s'appuyant sur les états sémantiques des machines virtuelles et l'IDC[note 6]. En effet l'IDC a établi des niveaux de disponibilité nommés AL1 à AL4 basés sur les expériences passées lors de pannes qui ont alors été définis de manière appropriée pour traiter les défaillances[20]. L'équipe d'IBM a donc généralisé ce concept aux environnements virtuels en mettant en place quatre niveaux de disponibilité nommés de HAVEN1 à HAVEN4 qui correspondent aux niveaux de disponibilité établis par IDC[21].

Parmi les différents modèles de la disponibilité, plusieurs études se sont appuyées sur le modèle de Markov (en). Ce modèle peut être considéré comme un diagramme d'état avec quelques restrictions mathématiques. La représentation d'un système peut être modélisée par la définition de tous les états que le système peut prendre. Ces états sont reliés par des arcs qui servent à représenter la transition d'un état à l'autre. L'arc peut représenter la probabilité pour passer à l'état suivant, ou la vitesse à laquelle le système se déplace dans l'état suivant[22]. L'équipe du professeur Kim s'est appuyée sur le modèle de Markov pour établir un modèle de la disponibilité des machines virtuelles[23].

La haute disponibilité est aujourd'hui un élément essentiel à prendre en compte. Pour permettre de maintenir en état de fonctionnement le système à virtualiser ou les applications en cas de défaillance, un certain nombre de solutions sont mises en place[6]: Deux domaines d'actions sont représentés :

• La redondance des matériels et la mise en cluster : Failover clustering, Mémorisation d'état, Migration à chaud.
• La sécurisation des données : Mirroring, Réplication, RAID, Snapshot.

Cluster de basculement

Cluster de basculement(failover clustering)

En français cluster de basculement, est une technologie permettant d'automatiser la reprise d'une application ou d'un service sur un autre serveur (nœud)[24]. Un cluster est un terme informatique qui désigne une grappe de serveurs. Cela regroupe une ou plusieurs machines physiques capables de supporter le même ensemble de machines virtuelles.

Failover signifie en langage informatique un basculement qui s'opère lorsque le composant principal est en défaut et que ce dernier ne peut pas fonctionner correctement. Alors le service ou l'application bascule d'une machine en défaut vers une machine en fonctionnement nominal[25].

En référence au schéma ci-contre :

Le niveau Application correspond à un service rendu aux utilisateurs. À ce niveau l'utilisateur ne voit que l'hôte virtuel. Le service de cluster est une application distribuée sur les deux nœuds du cluster et dirige les requêtes vers le serveur (nœud) actif.

Le niveau données abrite les applications et les données associées (BD, messagerie, etc.). La redondance des matériels, des applications et des données y est assurée. Le mécanisme de pulsation est un mécanisme par lequel les nœuds restent en contact permanent afin de détecter les défaillances du nœud actif.

Les données partagées représentent le support physique (indépendant des nœuds) utilisé par le service de cluster pour gérer le basculement (volume SAN[note 7]).

La mémorisation d’état

Un autre moyen utilisé dans la disponibilité est de s’appuyer sur la sauvegarde d’état. Dans ce cadre-là, le système SMP-ReVirt permet de revenir à l’état antérieur à la survenue d’une défaillance, d’un incident de sécurité ou de bug[26]. Ce système nécessite de conserver les états par sauvegarde et de détection du problème à l’aide de la page de protection hardware de la machine virtuelle. L’utilisation en mode multi processeurs permet en fait de disposer en parallèle de l’état et de la configuration d’une même machine virtuelle.

La migration à chaud

Fonctionnement migration à chaud

Les machines virtuelles sont dotées de plus en plus d'applications qui sont critiques pour les entreprises. Les différents acteurs du marché ont alors développé des services de haute disponibilité permettant aux applications de toujours fonctionner car le crash d'un élément est en principe transparent[1]. Les solutions qui ont été mises en place par les acteurs se nomment :

• Citrix XenMotion[27].
• Microsoft Hyper-V[28].
• VMware H.A[29].
• ....

Le principe de fonctionnement qui est illustré par le schéma ci-contre est le suivant :

En haut à gauche de l'illustration, deux machines hôtes sont actives et exécutent des applications(APP1 et APP2) au-dessus, respectivement, de deux machines virtuelles(VM1 et VM2). Elles sont managées par les hyperviseurs (VMM1 et VMM2). Un SAN est utilisé pour garantir la disponibilité des données pour les deux applications.

Quand une panne est détectée, la machine virtuelle (VM1) redémarre instantanément sur le second hôte(VMM2). Cet hôte exécute les deux machines virtuelles(VM1 et VM2) jusqu'à que le premier hôte soit réparé. Une fois que l'hôte(VMM1) est réparé, le système reprend son état initial sans qu'aucun arrêt de fonctionnement ne soit initialisé. La migration de la machine virtuelle se fait à chaud, c'est ce que l'on appelle la migration à chaud[1].

Les 4 solutions présentées ci-dessous ont toutes l'objectif de disposer d'un double de l'équipement virtuel à secourir en cas de défaillance. Seul le mécanisme change mais son automatisation est tout le temps recherchée.

Le Mirroring

Cette technique consiste à mettre en place un serveur dit principal puis de créer un serveur dit miroir. Ce dernier sera identique au serveur principal et sera à jour par rapport à lui. En cas de défaillance sur le serveur principal, le serveur miroir assurera la continuité de service sans interruption de services ni perte de données[6].

Réplication

La réplication est définie, techniquement, par un serveur primaire qui publie les données et le détail des transactions à un ou plusieurs autres serveurs[6]. C'est un aspect de la disponibilité qui est très étudié.

Habituellement la réplication s’opère sur la partie logicielle d’une machine virtuelle. En essayant de l’étendre à la partie physique, la disponibilité s’en trouve complétée et donc améliorée. L’architecture proposée par ReNIC (en)[note 8] s’appuie sur ce modèle[30].

Il existe un système basé sur la réplication qui offre une tolérance aux pannes pour n'importe quel type de service centralisé. Dans cet exemple, le système fait fonctionner chaque instance de service dans une machine virtuelle et reproduit dynamiquement l'intégralité de la machine virtuelle. Le service offert à l'utilisateur n'est pas affecté lors de cette opération[31].

Le RAID

La perte d'un serveur physique supportant de nombreuses machines virtuelles aurait un impact significatif, affectant notamment les applications qui fonctionnent sur les machines virtuelles. En conséquence, dans un environnement de serveurs virtuels, il faut mettre en place une stratégie de protection particulièrement importante[32]. La mise en place d'une solution RAID[note 9] est un bon complément au mirroring et à la réplication. Il protège d'une manière efficace contre la perte d'un disque dur[33]. L'étude du professeur Joshi, a démontré que dans un système virtualisé, la solution RAID5 apportait une meilleure sécurisation que les solutions RAID0, RAID1, RAID2, RAID3 ou RAID4[34].

Le snapshot

Agent Snapshot / hyperviseur

Le principe de cette solution est de prendre périodiquement des photos des états des serveurs. Les utilitaires nécessaires à cette solution sont habituellement intégrés dans les infrastructures de machines virtuelles.

Ils correspondent à des outils standards virtuels qui aident au contrôle de l'infrastructure globale. Sa mise en œuvre est simple, flexible, peu couteuse et efficace[35]. Le snapshot s’appuie sur le mécanisme déjà utilisé classiquement sur tout type de virtualisation consistant à disposer d'une réplique du dispositif à assurer. L’adaptation est ici de la rendre la plus automatique possible.

Les différents acteurs ont intégré cette fonction dans leurs produits. Par exemple les snapshots de VMware permettent de capturer l'intégralité de l'état de la machine virtuelle. Cela comprend la mémoire, les paramètres de configuration et les disques virtuels. Ainsi cette fonction permet de revenir à un état antérieur de la machine virtuelle lorsque c'est nécessaire[36].

La disponibilité vise à améliorer les critères de continuité de fonctionnement quelles que soient les circonstances. Elle présente des avantages d'autant plus importants qu'elle est efficace.

La disponibilité permet d'assurer la continuité de fonctionnement en particulier lors d'incidents de fonctionnement. Les moyens d’agir sont d’améliorer la tolérance de fonctionnement face aux pannes par actions proactives, ou par amélioration de la robustesse du système.

Par exemple, la technologie VFT[note 10] utilisée pour le cloud computing en particulier s’appuie sur la détection d’erreurs et le recouvrement vers une situation normalisée en cas d’incident. Un module de cloud management et un autre décisionnel sont utilisés dans ce dispositif de management de la virtualisation[37] - [38].

L’approche traditionnelle pour la tolérance aux pannes inclut des systèmes de vérifications, de redémarrages ou de la duplication. Dans la structure de tolérance aux pannes proactives, l’application est périodiquement contrôlée et lors d’apparitions d’erreurs, elle est totalement ou partiellement relancée[39].

Les hyperviseurs qui s’appuient sur un système de rétablissement proactif offrent des perspectives prometteuses de disponibilité selon l’auteur[18]. En utilisant l’hyperviseur pour initialiser une nouvelle réplique en parallèle au système actif, le temps de perturbation des applications se réduit en cas de reboot.

La mise en place de la disponibilité sur les machines virtuelles, permet aux utilisateurs de faire des économies d'infrastructures ou de coût énergétique dans les datacenters. L'équipe de M. Liu a démontré que l'on pouvait diminuer de manière significative les coûts de consommation énergétique dans le cas de la migration à chaud[40].

La disponibilité dépend de plusieurs facteurs. Celui sur la sécurité est un élément important surtout ces derniers temps avec le retour en force de la virtualisation. Un certain nombre de projets ont vu le jour afin d'améliorer la disponibilité tout en assurant une protection optimale du système. C'est par exemple le cas du projet HyperShield de l'équipe japonaise de M. Nomoto. En effet ce système permet de migrer vers un autre système d'exploitation tout en assurant la sécurité des machines virtuelles[41].

Virtualiser la sécurité

La nouvelle tendance dans l’industrie est de virtualiser les fonctions de sécurité réseau au sein d’applications de sécurité virtuelles[42]. Ces applications sont placées sur des hôtes qui distribuent alors les fonctions de sécurités nécessaires au travers de clusters.

Garantir qu’un Hyperviseur soit disponible en cas de défaillance revient à garantir la disponibilité d’une plateforme de virtualisation dont le rôle est de permettre à plusieurs systèmes d’exploitation de travailler sur une même machine physique en même temps. Le procédé pour y parvenir diffère selon le type d’hyperviseurs[43]:

Les hyperviseurs de type 1 et 2

Hyperviseur de type 1 ou natif

Dans ce type d’hyperviseur utilisant la paravirtualisation, rechercher la disponibilité revient à garantir la continuité de la fonction de contrôle du système d’exploitation et d’obtenir de bonnes performances de fonctionnement tout en isolant les ressources[44]. Les performances de ces hyperviseurs sont pratiquement équivalentes aux performances d'une machine physique[45].

Hyperviseur de type 2 ou hébergé

La disponibilité consiste ici à assurer la continuité de la virtualisation complète qui est définie dans ce type d’ hyperviseur. Il est représenté par un logiciel s’exécutant à l’intérieur d’un autre système d’exploitation. En termes de disponibilité, ce n’est cependant que sur un troisième niveau qu’un système d’exploitation invité s’exécutera en utilisant les services fournis par le système d’exploitation hôte pour gérer la mémoire et l’ordonnancement dans les systèmes d'exploitation des machines virtuelles[46].

À l'image des types de disponibilité pour les machines virtuelles, nous retrouvons les critères de classifications identiques. Cette partie est détaillée sur les machines virtuelles[47].

Beaucoup de recherches et d'études ont été faites sur les moyens de garantir la disponibilité grâce aux hyperviseurs. En parallèle, les dispositifs améliorant la disponibilité sur les hyperviseurs commencent à apparaître. Ceux-ci reprennent des principes déjà éprouvés sur les machines virtuelles comme la réplication ou la solution à plusieurs hyperviseurs.

3 techniques essentielles existent:

Les solutions multi-hyperviseurs

Dans la solution MultiHype, l’architecture proposée se compose de plusieurs hyperviseurs sur une unique plateforme physique. Chaque machine virtuelle de ce dispositif fonctionne en concurrence et indépendamment les unes des autres.

Solution à hyperviseur multiple

Ce système permet de confiner toute anomalie sur son propre périmètre sans perturber les autres. Grâce à ce type de protection, l’ensemble est plus résistant et moins sensible aux attaques et défaillances de tout type. La disponibilité de cette virtualisation s’en trouve améliorée. La configuration comporte un contrôle de la mémoire et un système d’isolement pour faire face aux défaillances des machines virtuelles[48].

Les solutions à base de réplication

Le dispositif Remus[49] permet ainsi d'offrir une haute tolérance aux pannes sans avoir à modifier la partie logicielle où se trouve l'hyperviseur. Il s'agit d'encapsuler ici la partie logicielle à protéger au sein même d'une machine virtuelle et de diffuser les changements d'état vers un hôte de secours à une fréquence supérieure à 40 fois par seconde. En parallèle, il s'agit d'utiliser aussi discrètement que possible une machine virtuelle active dans le but de répliquer l'état de fonctionnement et la configuration mise en œuvre. Le but recherché est de répliquer des snapshots d'instances complètes de systèmes à une période maximale de 25ms entre 2 machines physiques.

Le dispositif Romulus basé sur la technologie type KVM. Il s’agit d’un prototype de réplication de machines virtuelles utilisant la technologie Kernel (que l’on compare ici avec la technologie XEN). L’implémentation est entièrement faite dans l’espace utilisateur en ne relayant seulement au niveau du noyau de type Kernel, que les fonctionnalités qui sont incluses dans le noyau Linux original[note 11].

Comparaison des hyperviseurs Romulus / Remus

Une étude comparative a été réalisée entre les 2 technologies bien distinctes que sont a) Xen et b) Kernel. Dans cette étude, la technologie Xen est mise en œuvre dans l'hyperviseur Remus alors que la technologie Kernel est utilisée pour l'hyperviseur Romulus. La technologie Xen est bien plus éprouvée que la technologie Kernel[50]. Cette comparaison, jugée inhabituelle par son auteur D. Petrovic, vise à rechercher lequel de ces 2 types d'hyperviseurs basés sur la réplication est le plus efficace en termes de disponibilité. Le résultat est nettement à l’avantage de l’architecture KVM grâce en particulier au coût bien moindre du protocole nécessaire à la réplication[51].

L'architecture permettant une tolérance aux défaillances d'intrusion dans les machines virtuelles repose sur le principe de la réplication de services de réseaux s'appuyant sur les hyperviseurs de type Xen.

composition interne de l'architecture VM-FIT

Cette solution s'appuyant sur la technologie des hyperviseurs permet de fournir des communications et de la réplication dans un domaine dédié pendant que le service répliqué est exécuté dans un autre domaine hôte et isolé. Les 2 parties étant isolées grâce en particulier à l'hyperviseur, le recouvrement est plus facile et plus efficace en cas de défaillance ou d'intrusion malveillante.

Chaque élément de l'infrastructure peut être répété. il peut ainsi constituer un ensemble répliqué de toute part pour créer l'architecture complète de réplication[52]. Au moindre problème, la réplique créée prend alors la relève du système principal pour éviter les défaillances et les indisponibilités éventuelles des fonctionnalités mises en œuvre.

La disponibilité peut être améliorée à l’aide d’un algorithme de réplication[53]. Celui-ci adapte le contexte de fonctionnement au comportement du service souhaité et de la bande passante disponible entre les éléments principaux et les éléments de secours. Cet algorithme est perçu comme une extension des hyperviseurs de type Xen. Dans cette configuration, il s’agit de créer des reproductions de services et de les faire fonctionner ensemble dans une distribution centralisée[54]. Cet algorithme calcule chaque phase de durée de réplication. Elles sont basées sur la caractérisation des échanges mémoires locaux du service protégé et du nombre de paquets réseaux en sortie générés pendant cette phase de calcul. Il prend aussi en compte la disponibilité de la bande passante entre les nœuds primaires et de secours[53].

Les solutions intégrées

Dans le domaine de la disponibilité des hyperviseurs, la technique de renouvellement de la haute disponibilité dans les systèmes virtualisés s’exécute aussi bien pour les machines virtuelles que pour les hyperviseurs sans nécessité de faire de modification des applications. Cette technique améliore la disponibilité des 2 éléments avec des temps d'arrêts moins longs en cas de nécessité[55].

La solution d'infrastructure logicielle CIVIC, de par sa configuration, offre un environnement indépendant à chaque utilisateur et permet un contrôle centralisé tant sur la partie hardware que logicielle. Cette configuration améliore ainsi la disponibilité des ressources et facilite grandement toute la partie mise en œuvre du système virtualisé[56].

La disponibilité est encore plus importante pour les hyperviseurs car ils sont chargés du contrôle des machines virtuelles. Les hyperviseurs présentent cependant plusieurs avantages dont la disponibilité ou la continuité de service des systèmes virtualisés, la résistance aux attaques malveillantes, la réduction des coûts de fonctionnement et la facilité de mise en œuvre[57].

La continuité de service

Lors d'un incident d'hyperviseur de quelques secondes, la continuité de service consiste à maintenir le fonctionnement des programmes en cours sans interruption. La solution Remus fournit en ce sens une excellente tolérance aux pannes. Lors d'une défaillance de quelques secondes, ce dispositif permet la continuité d'exécution des programmes en cours[49]. Les hyperviseurs qui s’appuient sur un système de rétablissement proactif offrent des perspectives prometteuses de disponibilité selon l’auteur[18]. Si l'on utilise l’hyperviseur pour initialiser une réplique de secours en parallèle au système actif, le temps de perturbation des applications se réduit en cas de redémarrage.

La sécurité

Le second attrait de la disponibilité des hyperviseurs est de type sécuritaire. De nombreux développements ont été réalisés sur ce sujet. La solution de type multi-hyperviseur offre ainsi une excellente garantie de sécurité informatique en confinant l'hyperviseur malveillant du reste de la structure[48]. Un autre dispositif sécuritaire s'appuie sur les systèmes à base de réplication alliés au critère de tolérance aux erreurs d'intrusions. C'est à partir de la surveillance de ce critère que la réplication s'active[18].

Économique

Il est moins couteux de mettre en place des dispositifs de protection sur des systèmes virtuels que sur des systèmes réels. Une comparaison du coût de 3 types de solutions d'hyperviseur pour obtenir un certain niveau de disponibilité a été réalisée en tenant compte des coûts des processeurs, des mémoires et des communications. Il en résulte que pour un même coût, la résistance de fonctionnement optimal diffère grandement selon les types d'infrastructures choisies. L'étude est réalisée pour comparer les performances de fonctionnement et de disponibilité en se basant sur un même coût pour les 3 types de solutions d'hyperviseur[58].