EMC² on Zwindler's Reflection

Erreur multipath « Path not correctly configured for failover »

Wed, 24 May 2017 14:15:45 +0000

Path not correctly configured for failover

Il y a quelque temps, nous avons du décommissionner une vieille baie HP EVA (qui nous coutait plus cher en maintenance que d’acquérir une baie neuve) et migrer les LUNs vers une baie EMC VNX, elle encore sous maintenance. Cependant, lorsque la migration a été faite, le consultant qui s’est chargé de reconfigurer multipath pour migrer d’une baie à l’autre l’a un peu fait « rapidement ».

Quelques mois plus tard, lors d’une maintenance classique sur une des baies EMC, de grosses anomalies ont été détectés. Lors de la coupure d’un contrôleur pour mise à jour, certains serveurs hébergeant une partie de nos progiciels, encore sous Redhat 4, se bloquaient au niveau I/O au lieu de basculer sur les chemins encore disponibles. L’occasion rêvée pour refaire un peu de multipath !

Dans cet article, je vais donc passer en revue quelques unes des erreurs que j’ai pu rencontrer, et comment les corriger.

Liloo Dallas Multipath ?

D’abord un bref rappel.

Pour ceux qui ne connaissent pas multipath, il s’agit d’un module de Linux qui permet de gérer les chemins multiples vers une même disque. On l’utilise sur des réseaux de stockage d’entreprises qui disposent de plusieurs niveaux de tolérance aux pannes.

Chacun des chemins SAN menant à un même disque (LUN A sur le schéma ci dessus) sont indexés côté OS par leur propre special device du type /dev/sd[n] (4 chemins : sde, sdf, sdg et sdh dans l’exemple).

On ne peut pas directement les utiliser puisqu’on utiliserait dans ce cas là qu’un seul des chemins disponibles. Et écrire en direct sur 2 chemins menant vers un même disque en même temps serait catastrophique.

Heureusement, Multipath détecte de lui même (via l’UUID du disque) que les chemins sont en fait un même périphérique et créé pour nous un fichier spécial /dev/dm-[n] qui permet de pointer vers le disque via l’ensemble de ses chemins.

Vérifier le plus évident

Initialement, l’anomalie n’était pas visible car les vérifications de l’état de multipath n’avaient été faites qu’avec le niveau de détail standard : les chemins sont bien déclarés, visibles et fonctionnels… RAS de ce côté.

# multipath -l
mpath9 (36006016067302f00e4588d06345ee111)
[size=100 GB][features="1 queue_if_no_path"][hwhandler="1 emc"]
\_ round-robin 0 [active]
\_ 0:0:5:3 sdd 8:48 [active]
\_ 1:0:5:3 sdh 8:112 [active]
\_ round-robin 0 [enabled]
\_ 0:0:4:3 sdc 8:32 [active]
\_ 1:0:4:3 sdg 8:96 [active]
[…]

De même les modules multipath étaient bien chargés dans le kernel :

# lsmod |grep dm
dm_mirror 32585 0
dm_round_robin 5185 1
dm_emc 7745 1
dm_multipath 22865 3 dm_round_robin,dm_emc
dm_mod 76585 7 dm_mirror,dm_multipath

Cependant, le démon multipathd qui permet de gérer les bascules de chemins est lui hors service…

# service multipathd status
multipathd est arrêté

ATTENTION : Le démarrage du démon multipath peut éventuellement provoquer une coupure des chemins, ce qui va planter le serveur et les traitements en cours. Il faut donc bien prendre garde que le serveur ne soit pas utilisé lors de son activation.

chkconfig multipathd on
chkconfig --add multipathd

Doublons dans les user-friendly device names

Une fois les problèmes basiques réglés, nous avons remarqué que le consultant en question ne s’était pas trop embêté avec les user-friendly names. Voici ce que la commande suivante renvoyait :

# multipath -v2
remove: mpath9 (dup of mpath2)
mpath9: map in use
remove: mpath23 (dup of mpath2)
mpath23: map in use

Bien que non bloquant, ceci est clairement peu élégant ;-).

Comme je l’explique plus haut, multipath agrège les /dev/sd[n] en un seul et unique /dev/dm-[n]. Cependant, il est déconseillé d’utiliser directement le fichier /dev/dm-[n]. En effet, tout comme les /dev/sd[n] (que ce soit dans le cadre de multipath ou pas d’ailleurs), les fichiers /dev/dm-[n] sont susceptibles de changer au cours de la vie du serveur ! De quoi avoir une mauvaise surprise après maintenance…

Pour résoudre ce problème, plusieurs solutions sont conseillées. Soit on utilise le WWID du disque qui est garanti unique, soit on utilise le device mapper qui transpose ce dm-[n] un user-friendly name du type /dev/mpath[n].

Dans le cas présent, au gré de la migration, les WWID avaient générés plusieurs mpath pour un même disque et il n’y avait plus de cohérence !

Pour régler le problème, le plus simple est de couper toutes les applications, puis d’effacer la configuration (pas les données, hein, juste les chemins et la table de correspondance) pour repartir de zéro. On récupère les WWID de chaque disques, puis on supprime tous les chemins courants avec les commandes suivantes :

multipath -ll #affiche les chemins et leurs informations
multipath -F #flush de tous les chemins enregistrés

Une fois les chemins supprimés, il faut modifier le fichier de configuration /etc/multipath.conf pour y ajouter en fin de fichier la déclaration des WWID à associer à des friendly_names fixés manuellement :

[...]
multipaths {
multipath {
wwid "360060160da302f009cd38abe2f5ee111"
alias mpath0
}
multipath {
wwid "36006016067302f00e458ad06345ee111"
alias mpath2
}
}

En enfin, on peut les réenregistrer à l’aide de la commande :

multipath -v2

Mode ALUA 4/PNR 1 pour les LUNs

Pour autant, la vraie cause de l’anomalie n’a pu être détectée que lorsque le mode de détails supérieur a été utilisé pour afficher les chemins (option -ll). Plusieurs messages d’erreurs relativement explicites se sont affichés, et notamment :

la mention Path not correctly configured for failover
les chemins en « [active][faulty] »

multipath -ll
Path not correctly configured for failover
Path not correctly configured for failover
Path not correctly configured for failover
Path not correctly configured for failover
mpath9 (36006016067302f00e4588d06345ee111)
[size=100 GB][features="1 queue_if_no_path"][hwhandler="1 emc"]
\_ round-robin 0 [active]
\_ 0:0:5:3 sdd 8:48 [active][faulty]
\_ 1:0:5:3 sdh 8:112 [active][faulty]
\_ round-robin 0 [enabled]
\_ 0:0:4:3 sdc 8:32 [active][faulty]
\_ 1:0:4:3 sdg 8:96 [active][faulty]

Après consultation de ressources en lignes et du « [Host Connectivity Guide for Linux][3] », il apparait que le mode « ALUA 4 actif actif» n’est pas supporté sur les serveurs Redhat Entreprise Linux 4. Il faut utiliser le mode « PNR 1 actif passif» qui lui est bien certifié.

Dans notre cas, c’est pourtant bien ce mode « ALUA 4 » qui avait été déclaré côté baie EMC pour les chemins vers l’hôte. A l’inverse, la configuration qui avait été appliquée côté serveur était bien en mode « PNR 1 ». Il y avait donc une incohérence de ce côté-là.

Changer le mode des LUNs sur une baie VNX

La modification du type de Failover pour un LUN donné peut se faire depuis la console Unisphere mais ce n’est pas évident à trouver !

Une fois connecté, il faut choisir une des baies, ouvrir le menu « Hosts » puis « Host List ». Sélectionner le serveur concerné dans la liste, puis ouvrir l’onglet « Initiators » en bas de page.

Sélectionner un port, puis cliquer sur « Edit », et reconfigurer les 4 chemins.

Valider, et recommencer l’opération autant de fois que nécessaire.

Le mot de la fin

Dans notre cas, beaucoup d’erreurs avaient été faites lors de la configuration des LUNs, de la baie de disques et de multipath. Ça donne donc un bon tour d’horizon des premières choses à vérifier si jamais votre multipath sous Linux fonctionne mal.

Lorsque vous avez comme nous des baies EMC, j’aimerais insister sur le fait que le Host Connectivity Guide for Linux (lien mort, j’utilise Internet Archive) est vraiment un document très important, qui vous aidera à correctement tout configurer. N’hésitez pas à le lire en détail !

[Tutoriel] Récupérer l’espace non réclamé via l’API VAAI de VMware et l’instruction UNMAP

Sat, 19 Mar 2016 11:30:55 +0000

Contexte

La plupart des solutions de stockages estampillés Entreprise sont certifiés pour fonctionner de manière optimisée avec VMware, via l’API VAAI (baies EMC², HP, etc, mais aussi des solutions logicielles comme Datacore et même certains NAS Synology/QNAP/…).

Cette API permet entre autre d’accélérer les performances de certaines opérations d’exploitation, comme par exemple la copie de machines virtuelles ou le déploiement de templates. Elle permet également à VMware d’indiquer au stockage (à la baie de disques par exemple) qu’un Datastore (un ou plusieurs LUN) dispose de blocs qui ont été libérés.

Ceci est particulièrement utile dans le cas où le LUN est en Thin Provisioning, car dans ce cas là, de l’espace précédemment consommé peut être libéré côté baie via l’instruction UNMAP.

Exemple

On dispose d’un LUN de 500 Go en Thin Provisioning, présenté à un serveur VMware. On a créé un Datastore dessus et ajouté un VMDK qui prend 100 Go. Comme le LUN est en Thin provisioning, seul 100 Go (environ) est réellement utilisé sur la baie de disques.

Imaginons maintenant que le VMDK est supprimé du Datastore. Côté VMware, le Datastore sera bien vu comme vide car le VMDK a été détruit. Par contre côté baie de disques, le LUN fait toujours 100 Go car la baie de disques n’est pas « au courant » de la libération de l’espace pris par le VMDK.

On peut se connecter sur le serveur VMware pour réclamer cet espace disque en envoyant à la baie de disques une commande VAAI UNMAP.

Procédure de réclamation de l’espace disque

Pour une baie EMC de type VNX 5X00 et un LUN de 1500 Go. Le LUN fait 1460 Go sur la baie, pourtant beaucoup d’espace a été libéré sur le Datastore.

En se connectant en SSH sur un VMware, on lance la commande suivante :

esxcli storage vmfs unmap -l MONDATASTOREANETTOYER

Au bout que quelques minutes (peut durer longtemps si il y a beaucoup d’espace à réclamer), l’espace commence à se libérer :

Plus d’information sur le site de VMware

kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2057513 (lien mort, comme tout chez VMware)
kb.vmware.com/selfservice/search.do?cmd=displayKC&docType=kc&docTypeID=DT_KB_1_1&externalId=2014849 (lien mort, comme tout chez VMware)
kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2057513 (lien mort, comme tout chez VMware)
lien mort, j’utilise Internet Archive

Configuration multipath ALUA 4 / PNR 1 sur EMC VNX pour RedHat 4

Sat, 07 Nov 2015 11:30:18 +0000

Suite à une migration de baies HP EVA vers des EMC² VNX, une partie de mes vieux serveurs Linux m’ont générés quelques incidents, suite à la modification de la configuration multipath consécutive à cette migration.

Lors d’une coupure d’un chemin (notamment lors de la mise à jour d’un Service Processor par exemple), les E/S sur les disques SAN se bloquaient sur certains serveurs Linux, induisant un empilement des traitements (et donc du load average) jusqu’à bloquer l’accès au serveur et planter les procédures en cours.

Les causes de ces dysfonctionnements étaient multiples. Voilà ce que j’ai repéré sur les serveurs lors de mes investigations.

Symptômes

Doublons dans les friendly_names

Lorsque la migration a été faite, nous nous sommes appuyés sur le fait que nos volumes étaient répartis sur des miroirs LVM pour rendre la migration transparente. Les données ont été copiées sur un 3ème membre de miroir sur la nouvelle baie, puis un membre a été retiré sur l’ancienne baie. Et ainsi de suite jusqu’à ce que le miroir ne soit plus que sur les nouvelles baies.

Cependant, lorsque cette opération a été réalisée, l’OS s’est mélangé les pinceaux. Pour lui, il y avait eu plusieurs devices mpath bien distincts qui ont pourtant le même friendly_name.

Lors de la découverte des chemins multipaths à l’aide de la commande suivante, des messages d’erreur faisant état de doublons dans les noms mpathX s’affichaient :

# multipath -v2
remove: mpath9 (dup of mpath1)
mpath9: map in use
remove: mpath13 (dup of mpath2)
mpath13: map in use

Mode ALUA 4 / PNR 1 pour les LUNs

Plus grave, lorsque le mode de détail supérieur est utilisé pour afficher les chemins (multipath -ll), de nombreux messages d’erreurs s’affichent !

multipath -ll
Path not correctly configured for failoverPath not correctly configured for failoverPath not correctly configured for failoverPath not correctly configured for failovermpath9 (36006016067302f00e4588d06345ee111)
[size=100 GB][features="1 queue_if_no_path"][hwhandler="1 emc"]
\_ round-robin 0 [active]
\_ 0:0:5:3 sdd 8:48 [active][faulty]
\_ 1:0:5:3 sdh 8:112 [active][faulty]
\_ round-robin 0 [enabled]
\_ 0:0:4:3 sdc 8:32 [active][faulty]
\_ 1:0:4:3 sdg 8:96 [active][faulty]

On remarque les erreurs en début de commande Path not correctly configured for failover et surtout le fait que le chemin soit [active][faulty].

Après consultation de ressources en lignes et du « EMC Host Connectivity Guide for Linux » (lien mort, j’utilise Internet Archive), il semblerait que le mode « ALUA 4 actif actif» ne soit pas (totalement) supporté sur les serveurs Redhat Entreprise Linux 4, ce qui est exactement la version de mes serveurs Linux.

Il faut utiliser le mode « PNR 1 actif passif» qui lui est bien certifié.

Après vérification, c’est pourtant bien ce mode « ALUA 4 » qui a été déclaré dans la baie EMC pour les chemins vers l’hôte au niveau du Failover Mode. On a là la première cause du dysfonctionnement.

Démon multipathd

Les chemins étaient bien déclarés, visibles et fonctionnels, les modules multipath étaient bien chargés dans le kernel :

# multipath -l
mpath9 (36006016067302xxxx4588d06345ee111)
[size=100 GB][features="1 queue_if_no_path"][hwhandler="1 emc"]
_ round-robin 0 [active]
_ 0:0:5:3 sdd 8:48 [active]
_ 1:0:5:3 sdh 8:112 [active]
_ round-robin 0 [enabled]
_ 0:0:4:3 sdc 8:32 [active]
_ 1:0:4:3 sdg 8:96 [active]
[...]
# lsmod |grep dm
dm_mirror 32585 0
dm_round_robin 5185 1
dm_emc 7745 1
dm_multipath 22865 3 dm_round_robin,dm_emc
dm_mod 76585 7 dm_mirror,dm_multipath

Cependant, le démon multipathd qui permet de gérer les bascules de chemins était lui hors service, ce qui est la seconde cause du non fonctionnement des bascules.

# service multipathd status
multipathd est arrêté

Modification de la configuration pour correction

Idéalement pour toutes ces corrections, le serveur doit être non sollicités, les applications arrêtées. Les modifications qui sont effectuées peuvent très probablement avoir un impact sur les traitements en cours.

Doublons dans les friendly_names

Pour résoudre le problème des doublons dans les friendly_names, il faut commencer récupérer les WWID de chaque disques, puis supprimer tous les chemins avec les commandes suivante :

multipath -l #affiche les chemins et leurs informations
multipath -F #flush de tous les chemins enregistrés

Une fois les chemins supprimés, il faut modifier le fichier de configuration /etc/multipath.conf pour y ajouter en fin de fichier la déclaration des WWID à associer à des friendly_names fixes :

multipaths {
multipath {
wwid "360060160da302fxxxxd388be2f5ee111"
alias mpath0
}
multipath {
wwid "36006016067302fxxxx588d06345ee111"
alias mpath1
}
}

Réenregistrer les chemins à l’aide de la commande :

# multipath -v2

Mode ALUA pour les LUNs

Pour modifier le mode de configuration des LUNs, il faut se connecter sur la console Unisphere des baies de disques.

Une fois connecté, il faut ouvrir choisir une des baies, ouvrir le menu « Hosts » puis « Host List »

Sélectionner le serveur concerné dans la liste, puis ouvrir l’onglet « Initiators » en bas de page.

Sélectionner un port, puis cliquer sur « Edit », et reconfigurer les 4 chemins.

Valider, et recommencer l’opération sur l’autre baie de disques.

Démon multipathd

ATTENTION : Le démarrage du démon multipath peut éventuellement provoquer une coupure des chemins, ce qui va planter le serveur et les traitements en cours s’il y en a. Il faut donc bien prendre garde que le serveur n’est plus utilisé lors de son activation.

chkconfig multipathd on
chkconfig --add multipathd
reboot #éventuellement

A partir de là, tout devrait revenir à la normale. En cas de coupure d’un chemin, multipathd se chargera de basculer sur un autre chemin (passif) et cela fonctionnera car nous sommes en mode PNR 1, qui est supporté sous RHEL 4.

Retour arrière

Si pour une raison ou pour une autre la correction des anomalies ne se passaient pas comme elle le devrait, je vous laisse également quelques instructions provenant de mon plan de retour arrière.

Doublons dans les friendly_names

Pas de procédure de retour arrière à proprement parlé. Une fois que les chemins ont été détruits puis reconfigurés, il ne devrait pas y avoir de problèmes.

On peut néanmoins revenir sur le fichier de configuration ne prenant pas en compte les nouveaux friendly_names déclarés

Mode ALUA pour les LUNs

Retourner sur les baies de disques, et repasser l’ensemble des chemins en mode « ALUA 4 » avec la même procédure que plus haut.

Démon multipathd

Dans le cas où un retour arrière est nécessaire, il suffit de passer les commandes suivantes pour désactiver multipathd :

chkconfig multipathd off
chkconfig --del multipathd

[IRL] RedHat virtualisé et haute dispo, RHCS+VMDK partagés vs vSphere Replication

Wed, 11 Feb 2015 14:58:49 +0000

Contexte

Dans un contexte professionnel, il arrive que des décisions soient prises et qu’il faille s’y tenir coute que coute. Même si on se rend compte plus tard que ce n’était pas forcément le chemin le plus facile. La facilité, c’est le côté obscur, on le sait bien ;-).

Pour un client, on m’a donc demandé de concevoir une plateforme RedHat 5.X virtualisée hautement disponible, avec une durée d’interruption de service maximale de 30 minutes en toute circonstance (jusque là tout va bien), ET la possibilité de restaurer les disques des OS virtuels avec plusieurs points de restaurations par palliers de 30 minutes (RPO/RTO). Aie!

Tel le Mac Giver des temps modernes, je dispose des outils suivants pour y parvenir :

1 licence vSphere Essential Plus
2 serveurs physiques, installés en ESXi 5.5 et reliés en SAN
2 baies de disques EMC² VNX5200
2 souscriptions RedHat Datacenter - pour disposer d’autant de VMs RHEL qu’on le souhaite sur nos deux nœuds physiques
2 souscriptions RedHat High Availability (anciennement RedHat Cluster Suite) en mode Datacenter - pour disposer d’autant de clusters RedHat qu’on le souhaite sur nos deux nœuds physiques

Clusters RHCS et VMDK partagés ou RDM

Comme vous pouvez le deviner avec la dernière ligne, on m’a demandé d’utiliser les licences qui avaient été achetées. Donc de déployer du cluster RHCS à tour de bras, pour faire des paires de VMs et simuler ce que l’on fait habituellement sur des paires de machines physiques.

Sauf qu’à tenter de faire des clusters RHCS sur des machines virtuelles VMware, on trouve vite toute sortes de petits désagréments.

Note : Je vous demanderai de bien vouloir faire abstraction du fait que c’est vraiment « bourrin » de doubler des VMs lorsqu’on dispose d’un cluster vSphere. En fait, si j’en suis arrivé là, c’est parce qu’un simple cluster VMware HA ne répond pas à l’ensemble des besoins énoncés plus haut. C’est possible, bien sûr, mais il faut aller creuser peu plus loin (cf la fin de l’article).

Prérequis

VMware et RedHat supportent l’utilisation de cluster RHCS dans sur des machines virtuelles avec les obligations suivantes :

Support de vSphere 5.1 uniquement à partir de RHEL 5u9 ou 6u4
Support de vSphere 5.5 uniquement à partir de RHEL 5u11, 6u6 ou 7
Support du partage de disques via RDM à partir RHEL 5u7
Support du partage de VMDK à partir de RHEL 5u9

(Voir ici pour plus d’infos)

Idéalement, il faut donc disposer de machines virtuelles RHEL 5u11 et de vSphere en version 5.5 (version la plus à jour si on met de côté la 6 qui va sortir), mais on peut se « contenter » d’une version RHEL 5u9 en installant une version plus ancienne de vSphere (5.1).

Le cas le plus défavorable est l’utilisation de vSphere 5.0 avec un RHEL 5u7 ou 5u8. Dans ce cas, seul le partage de disques via RDM est possible et un bug connu dans la version 5.0 de vSphere empêche le fonctionnement opérationnel du cluster (au niveau du fencing).

Au-delà, ce n’est pas supporté.

Architecture

Cas de panneS

Les disques OS sont installés en RAID 1 MDADM avec 2 VMDKs situés sur les deux baies.

Si ce n’est pas le cas, en cas de la perte de la baie de disques hébergeant l’OS du nœud maitre, le serveur deviendra instable mais ne pourra pas se saborder d’elle-même correctement, plantant le cluster et l’application.

Pire, s’il s’agit de la baie de disques qui héberge le quorum disk, le cluster ne disposera plus d’assez de votes pour fonctionner et le redémarrage devra être forcé à la main.

En cas de corruption du disque OS du nœud actif, les packages basculeront sur l’autre VM.

En cas de panne de l’ESXi, les packages actifs pourront basculer sur le nœud présent sur l’autre serveur.

En cas de perte de la baie de disques, les données seront toujours accessibles par les deux VMs grâce à l’autre membre du miroir.

Même si la baie hébergeant le quorum tombe en panne, on disposera toujours de deux votes (les deux nœuds du cluster).

Limitations et problématiques de la solution

VMware et Contrôleur Physique

Pour partager des disques durs virtuels (RDM ou VMDK), il faut ajouter à la machine virtuelle un « contrôleur de disques SCSI » en « compatibilité physique ». Ceci a pour conséquence de limiter les fonctionnalités disponibles dans VMware :

Pas de live vMotion (bascule de VM à chaud)
Pas de snapshots
Pas de sauvegarde via l’API VMware (sauvegarde des VMs via l’ESXi « clientless » et sauvegarde granulaire)

RHCS et nombre de votes

La salle primaire héberge le quorum disk qui permet de favoriser la salle primaire en cas de « split brain » (voir mon article sur le démarrage forcé sous RHCS). Ce mécanisme de sécurité permet d’empêcher d’avoir 2 salles autonomes en même temps ce qui aura pour conséquence de corrompre les données du SI.

Le cas défavorable de la perte de la salle primaire complète induit un problème important qui ne peut pas être adressé simplement. Dans ce cas de figure, il n’y a plus assez de votes pour que le cluster fonctionne, et l’application s’éteint.

Il est donc nécessaire de redémarrer manuellement les clusters. Dans l’absolu, ce n’est qu’une commande à passer, mais dans mon cas, j’ai un nombre important de clusters à gérer. La personne d’astreinte ne pourra jamais tenir les SLA de 30 minutes d’indisponibilité.

Il me parait impossible d’automatiser proprement cette relance du cluster, car c’est un mécanisme trop sensible et les risques de corruption de données sont trop important.

LVM vs MDADM

Dans la structure pour laquelle je travaille, l’utilisation du mirroring LVM est un choix technique historique héritée de nos clusters MCSG sous HP-UX.

Sous RHEL 5.X, la gestion des miroirs LVM est complexe et peu adaptée :

l’agrandissement des volumes nécessite une suppression du miroir, rendant les données temporairement non redondée et réduisant les performances.
la perte de l’interconnexion - même temporaire - a des effets de bords qui nécessitent également de tout reconstruire et de tout resynchroniser entièrement (membres de miroirs perdus mais pas tous remontés comme tels).

A l’inverse, l’agrandissement d’un disque via MDADM peut se faire à chaud (on agrandi un VMDK, puis l’autre), et la perte temporaire d’un membre ne nécessite pas de le reconstruire complètement.

Une dernière option - idéale techniquement - est l’utilisation de la réplication de « blocs devices » par DRBD (société LinBIT). Elle a été rejetée pour cause d’absence de support de la part de RedHat mais permet de faire exactement ce que l’on souhaite : répliquer des disques au niveau bloc entre deux VMs.

Réplication des VMDK via vSphere Replication

Et voilà la solution que j’aurai aimé étudier. La facilité. Le côté obscur donc.

Prérequis

Pour utiliser la fonctionnalité vSphere Réplication, il faut disposer d’une licence vSphere Essential Plus (ou mieux), d’un vCenter et de deux datastores distincts.

Architecture

Réplication du disque OS de la VM

Avec la licence vSphere Essential Plus, il est possible de réaliser un « pseudo PRA » à l’aide de la fonctionnalité vSphere Replication.

La machine virtuelle n’est pas doublée comme dans l’architecture précédente. Ici VMware réplique son VMDK en fil de l’eau vers un Datastore secondaire.

En cas de panne quelconque sur la salle primaire, on bascule la VM sur le serveur ESXi secondaire et on la redémarre sur le disque répliqué (opération manuelle).

En cas de corruption des filesystems sur le disque OS, on dispose de plusieurs points de restauration dans le temps nous permettant de revenir à un état précédent fonctionnel.

Limitations et problématiques de la solution

Malheureusement je n’ai pas eu l’occasion de le tester, la solution choisie n’étant pas cette solution. Cependant, au vu des besoins énoncés et des ressources à ma disposition, cette solution me parait être celle qui répond à tous les besoins et toutes les problématiques.