Hyperviseurs : il n'y a pas que VMware dans l'IT

Red Hat KVM : attention aux migrations

Quel que soit l'hyperviseur, deux facteurs importants sont à prendre en compte en matière de stockage. Primo, les administrateurs doivent passer en revue les types de stockage directement pris en charge par l'hyperviseur pour accueillir les machines virtuelles (VM). Il convient de noter à ce sujet que ce n'est pas parce qu'un type de stockage est reconnu par un hyperviseur donné qu'il conviendra en mode de production. Par exemple, KVM prend en charge l'attachement direct (DAS) pour le stockage des VM, mais n'autorise pas les migrations desdites VM dans ce cas de figure.

Deuxio, il faut prendre en considération les types de stockage accessibles (en toute compatibilité) depuis une VM. Ce critère est important car les VM se connectent souvent à des unités logiques (LUN) externes via iSCSI ou une interface Fibre Channel (FC) virtuelle. Dans ce cas, vous devez vous assurer que l'hyperviseur prend en charge la connectivité des VM au stockage externe.

Comme on peut s'y attendre de la part d'une plateforme open source, Red Hat KVM reconnaît un large éventail d'options de stockage de VM. Cependant, de nombreux experts en stockage considèrent généralement les migrations des VM comme une fonction incontournable, et les options de Red Hat en la matière sont quelque peu limitées.

Pour procéder à une migration, il faut que la VM concernée réside sur un stockage partagé. Ce serveur KVM doit communiquer avec le stockage partagé par le biais de l'un des protocoles suivants :

• FC (Fibre Channel)
• iSCSI
• FCoE (Fibre Channel over Ethernet)
• NFS (Network File System)
• GFS2 (Global File System 2)
• SRP (SCSI Remote Direct Memory Access Protocol), le protocole d'exportation en mode bloc utilisé dans les adaptateurs InfiniBand et iWARP 10 Gigabit Ethernet.

Comme chez VMware et Hyper-V, la fonction de migration d'une VM de Red Hat consiste à copier des pages mémoire sur une liaison réseau entre deux serveurs hôtes. Cependant, chez Red Hat, le procédé est inopérant si la mémoire est mise à jour à un rythme supérieur à celui de la copie. Le processus de migration se solde alors par un échec.

En revanche, VMware propose une fonction qui ralentit la VM jusqu'à ce que la copie de la mémoire soit terminée, permettant ainsi de mener la migration à son terme.

Comme vSphere et Hyper-V, KVM permet aux VM de se connecter à un stockage distant par l'intermédiaire de divers protocoles. Les périphériques et protocoles suivants sont pris en charge pour la connexion d'un stockage distant aux invités KVM :

• Partitions de disque dur locales
• Volumes logiques
• Connectivité FC ou iSCSI au niveau de l'hôte
• Conteneurs de fichiers résidant dans un système de fichiers sur l'hôte
• Système de fichier NFS monté directement par le système d'exploitation (SE) invité
• Stockage iSCSI déclenché par le SE invité
• CFS (Cluster File System, système de fichiers de cluster)

Red Hat offre également son propre produit de stockage à définition logicielle (SDR, software-defined storage), appelé Red Hat Storage Server, qui est bien sûr l'option de stockage privilégiée dans les environnements KVM.

L'idée de base consiste à virtualiser un matériel de stockage générique sous la forme de pools de stockage qui seront ensuite alloués à la demande. C'est un peu ce que fait Microsoft avec sa fonction d'espaces de stockage Windows (Windows Storage Spaces) mise en œuvre dans Windows Server 2012 et dans Windows Server 2012 R2.

Le stockage VMware à base de profils offre des avantages

A l'instar de KVM et d'Hyper-V, VMware prend en charge la migration de VM en cours d'exécution d'un serveur hôte à un autre. VMware a baptisé cette fonction vMotion ; elle n'est pas incluse dans l'hyperviseur principal. En effet, les hôtes VMware doivent disposer de licences vMotion spéciales.

Avant ESXi 5.1, vMotion exigeait l'utilisation d'un stockage partagé. Encore aujourd'hui, cet usage reste recommandé. Dans cette configuration, les hôtes VMware doivent être rattachés au stockage partagé afin que chaque serveur hôte y ait accès. VMware recommande de placer le stockage partagé sur un SAN FC, mais les interfaces iSCSI et NAS sont également prises en charge.

ESXi et les versions ultérieures permettent de faire migrer des VM en cours d'exécution sans nécessiter de stockage partagé. Pour ce faire, les disques des VM doivent fonctionner en mode persistant ou constituer des mappages de périphériques bruts (RDM, Raw Device Mapping). Si vous choisissez d'utiliser des RDM, l'hôte de destination doit avoir accès à la LUN RDM, à moins que vous convertissiez le mappage en fichier de disque de VM.

VMware et Microsoft prennent tous deux en charge la migration de VM d'un emplacement de stockage à un autre. Cette fonction s'appelle Storage vMotion chez VMware et Storage Live Migration chez Microsoft. Avant VMware 5.0, la fonction Storage vMotion ne pouvait être utilisée que sur les VM ne contenant pas d'instantanés. Les versions 5.0 et supérieures de VMware prennent désormais en charge la migration de VM qui en contiennent. Quoi qu'il en soit, les disques des VM doivent être en mode persistant ou prendre en charge le RDM.

vSphere 5.0 et les versions supérieures présentent une fonction unique, le stockage à base de profils. Dans les environnements VMware, les VM sont déployées dans des magasins de données, qui constituent des abstractions du stockage physique. Les administrateurs choisissent généralement un magasin de données en fonction du matériel sous-jacent. Par exemple, une VM qui exécute une application de base de données stratégique serait sans doute placée dans un magasin de données associé à un stockage hautes performances.

Problème : les VM sont tout sauf statiques. C'est pourquoi la fonction de stockage à base de profils permet à un administrateur de vérifier si le stockage qui sous-tend une VM est conforme aux exigences de stockage initialement définies.

Hyper-V marque des points grâce à sa polyvalence

Microsoft Hyper-V a fait son apparition avec Windows Server 2008, mais il lui manquait alors trop de fonctions pour mériter le titre d'hyperviseur professionnel. La fonctionnalité n'est vraiment parvenue à maturité qu'avec Windows Server 2012, avant de s'améliorer encore avec Windows Server 2012 R2. C'est donc sur cette dernière version que je me suis penché pour les besoins de ce comparatif.

En termes de stockage, Hyper-V est considéré comme très polyvalent. Ainsi, la documentation Microsoft indique qu'Hyper-V peut utiliser les composants suivants :

• Le stockage en attachement direct (DAS)
• Le stockage Server Message Block (SMB) 3.0
• Les disques directs iSCSI
• Les disques VM iSCSI
• Le stockage connecté via FC
• Le stockage FC virtuel
• Un fichier VHDX partagé résidant sur un volume partagé de cluster (CSV, Cluster Shared Volume).

Comme VMware, Hyper-V prend en charge les migrations dynamiques avec ou sans recours à un stockage partagé. Microsoft recommande toutefois d'utiliser un stockage partagé dans la mesure du possible. En tout état de cause, les VM doivent être configurées pour utiliser des disques durs virtuels ou des disques FC.

Le recours à des disques physiques intermédiaires (pass-through) n'est pris en charge que dans des cas très particuliers. Pour permettre une migration dynamique de ces types de disques, il faut que les VM s'exécutent sur un cluster de basculement, et que leur fichier de configuration réside sur un volume partagé de cluster (CSV). De plus, le disque physique doit être configuré comme ressource de stockage sous le contrôle du cluster.

Pour ce qui est du stockage partagé, Hyper-V prend en charge le stockage FC, iSCSI et SMB 3.0 (ce dernier n'était pas compatible avant Windows Server 2012).

Les VM Hyper-V peuvent se connecter à des types de stockage très variés. Le seul véritable frein à l'utilisation d'un stockage externe par les VM reste sans doute le processus de sauvegarde. En ligne, les sauvegardes au niveau de l'hôte font appel à l'enregistreur VSS d'Hyper-V. Cet outil assure une prise en charge native des sauvegardes côté VM utilisant les dispositifs suivants :

• Le stockage en attachement direct (DAS)
• Le stockage iSCSI rattaché via le SE hôte (en effet, l'enregistreur VSS d'Hyper-V ne peut sauvegarder aucun stockage iSCSI lancé à partir d'une VM)
• Le stockage FC rattaché via le SE hôte
• Le stockage FC virtuel

En revanche, les sauvegardes au niveau des invités prennent en charge toute ressource de stockage visible par une VM, quel que soit son type.

Outre la migration dynamique, Hyper-V comporte une fonction de migration du stockage semblable à la fonction Storage vMotion de VMware. Microsoft l'appelle Storage Live Migration (migration dynamique du stockage). Microsoft introduit également plusieurs nouvelles fonctions liées aux disques durs virtuels VHDX, telles que le redimensionnement d'un disque dur virtuel pendant l'exécution de la VM.

Bien que les hyperviseurs proposés par Red Hat, VMware et Microsoft affichent des capacités similaires, leur prise en charge du stockage physique présente d'énormes différences. Avant d'investir dans un hyperviseur, assurez-vous donc que le stockage de votre choix sera pris en charge, et renseignez-vous sur les caractéristiques des différents produits en matière de stockage.