PRA on Zwindler's Reflection

Votre PRA pas cher avec un cluster ProxmoxVE et ZFS

Mon, 15 Mar 2021 07:30:34 +0000

OneProvider, le retour de la vengeance

Ça fait un moment que je monte régulièrement des cluster Proxmox VE avec du ZFS, de manière à avoir un PRA sur mes infras perso.

Pour ne pas exploser les coûts, j’utilise depuis longtemps des machines dédiées (les moins chères possibles) et j’utilise la fonctionnalité réplication asynchrone des machines virtuelles via des pools ZFS dans Proxmox VE. ZFS est donc le prérequis.

Vous l’avez compris, je suis re-re-retourné chez OneProvider. Je ne suis pas plus satisfait de la relation client qu’avant, mais… ils sont vraiment imbattables, en prix sur du dédié et il va m’en falloir 3.

Pourquoi un cluster, tu n’héberges rien de pro !

Ben d’abord parce que j’ai envie.

Mais si vous voulez une explication plus rationnelle que ça :

J’aime bien que mon blog (qui est ma vitrine) ne soit pas down quand je donne une conférence ou passe un entretien d’embauche (certes c’est pas souvent en ce moment)
Je n’ai pas envie de tout perdre à la mode SBG2

Belotte

Alors, pourquoi pas un PCA ? Pourquoi pas du synchrone ?

La réplication synchrone du stockage, c’est vraiment chouette. Avoir un cluster Ceph sur Proxmox VE ça permet d’avoir de la vraie haute disponibilité, avec 0 (quasiment) perte de données en cas de crash d’un nœud et des clusters capable de migrer les machines automatiquement en cas de souci.

La première limitation c’est que Ceph, pour bien fonctionner demande d’avoir des disques de type SSD plutôt cher et plutôt véloces. Ça colle pas avec mon budget.

Mais le plus gros souci, c’est que le synchrone à un gros défaut, il faut une latence très faible entre toutes les machines. Beaucoup plus faible que ce que nécessite Corosync pour la mise en cluster de Proxmox lui même puisqu’on est sur des latences de l’ordre de la milliseconde.

Corollaire de cette limitation, les machines doivent être sur des distances très courtes, notamment à cause de la vitesse de la lumière… Sauf à avoir la possibilité d’avoir des machines physiques dans des DCs proches (<100 km) chez votre provider, on se retrouve donc à monter un cluster qui va probablement se trouver dans le même DC (voire la même salle).

Rebelotte

OK. Et c’est plus facile de faire un PRA / de l’asynchrone ?

Oui !

L’avantage de la réplication asynchrone par rapport à un cluster de stockage synchrone (comme Ceph) est qu’on peut le faire sur une distance beaucoup plus importante puisque ce n’est synchrone (thank you captain obvious).

On a pas besoin d’avoir une latence <1-2 ms et ça nous autorise à faire des clusters Paris-Amsterdam-Bordeaux sans problème (exemple totalement au hasard).

Et comme cette réplication est totalement intégrée à Proxmox VE, on va pouvoir choisir simplement (dans la GUI) que des VMs sont à répliquer sur un serveur du cluster situé loin et Proxmox se chargera tout seul de synchroniser régulièrement les disques puis le delta des modifs (pour soulager le réseau).

Ça me permet d’avoir un « PRA du pauvre » avec des bascules manuelles de VMs :

RPO à 15 minutes (arbitraire, dépend totalement de la fréquence de la synchro delta, mais c’est la valeur par défaut)
RTO en quelques minutes dans le meilleur des cas (en gros, quand j’ai le temps de basculer les VMs et les records DNS)

Le plus important dans tout ça c’est que je peux le faire sans me fatiguer puisque c’est géré par Proxmox (et vous savez à quel point je déteste me fatiguer).

Note : avoir toutes mes VMs en réplication asynchrone ne me dispense pas d’avoir des sauvegardes (offsite) de toutes les machines virtuelles. Ça me permet juste de remonter l’infra plus rapidement et de perdre moins de données. Mais n’oubliez pas que sans backup, vous ne le savez pas encore, mais vous êtes déjà morts.

Ok, comment on fait ?

Mais si c’était si facile que ça à faire (chez OneProvider), je n’en aurais pas fait un article. Comme vous allez le voir, on va en baver un peu pour y arriver ;-).

Le besoin est donc :

Un cluster Proxmox VE 6 avec quorum (donc 3 machines minimum)
2 DCs distinct minimum, avec des localisations relativement proches (pas trop de latence quand même, pas plus de 20 ms / 1000 km entre les serveurs)
Avoir du ZFS pour pouvoir faire de la réplication asynchrone des machines
Contrainte perso : du QEMU (donc VT-x) sur au moins un des nœuds
Contrainte perso : le moins cher possible

SNCF, c’est possible

Pour 30 euros par mois (qu’on peut optimiser à ~25€ selon les promos et la durée d’engagement), chez OneProvider et avec quelques concessions, c’est possible.

J’ai sélectionné 2 types d’instances, disponibles sur Paris et Amsterdam :

un serveur principal avec 16 Go de RAM et un quadcore Xeon L3426 (une antiquité de 2009, mais à 18€ / mois voire 15€ en promo, c’est cadeau), avec 2 disques de 2 To
deux serveurs secondaires / de secours avec 4 Go de RAM et un Atom C2350 (pas de virtualisation, que des containers LXC)

Un poil plus cher (39€ / mois), vous pouvez aussi avoir une variante pour que vos 3 machines soient capables de faire de la virtualisation complète (VT-x) en prenant 3 Atom C2750, qui sont des octocores avec « seulement » 8 Go de RAM chacun.

On installe Proxmox avec OneProvider

Oui, OneProvider propose (maintenant depuis quelques années) d’installer Proxmox directement sur les machines.

En vrai, ça doit dater de Proxmox VE 5 puisque c’est la seule version qu’on a. On passera donc par la case upgrade, mais on y reviendra car il y a « plus grave ».

On ne peut pas partitionner et changer des options comme on veut (contrairement à ce tuto de mon test de Proxmox chez Hetzner par exemple) et comme je dois avoir du ZFS, je suis couané (comme on dit chez moi).

Et on ne peut pas utiliser la console IPMI (on peut la demander sur simple ticket au support) car dans le cas du L3426, le firmware est si vieux qu’aucun navigateur / version de java que j’ai testé ne supporte la console JNDI…

Ahhhh, ça me rappelle cette bonne époque où je gardais une version de java pour chaque switch SAN !

On va devoir faire avec l’install de OneProvider donc…

Encore une fois, pas de bol. Le L3426 est livré de base en RAID0 avec tout l’espace disque utilisé…

Oui oui… j’ai bien dis RAID0, donc les deux disques sont strippés et 2 fois plus de chances que votre RAID array casse. Bref… c’est useless.

Il faut changer la conf du RAID dans l’interface web et refaire une install. Si vous ne voulez pas de ZFS, vous pouvez choisir l’option RAID1 qui vous permettra d’avoir un miroir géré côté hardware (pas forcément une super idée vu qu’on est sur une config premier prix).

Dans mon cas, comme je veux du ZFS, utiliser le contrôleur RAID est un non-sens et j’ai donc choisi NORAID

Bon du coup, une fois réinstallé, Proxmox installé sans utiliser le RAID hardware… mais… il n’y a plus de place pour ajouter un pool ZFS. Et pour continuer la blague : en utilisant NORAID, je m’attendais à ce que Proxmox ne soit installé que sur un disque et je me suis retrouvé avec un RAID 1 logiciel MDADM.

Super…

Qu’à cela ne tienne !

On va donc s’amuser à retailler les disques en ligne de commande, à l’aide de l’image de rescue via SSH.

Fun fun fun fun –Rebecca Black - Friday

Grosso modo, l’idée c’est de réduire le FS porté par le device mdadm (/dev/md126 dans mon cas en rescue) à 100G (par exemple), puis de réduire le volume mdadm lui même (un poil plus grand, genre 110G), puis de terminer en retaillant (encore à la hausse) les deux partitions disques.

NOTE ATTENTION DANGER : Comme d’habitude à chaque fois que j’écris un tuto avec des opérations dangereuses il y a toujours des gens pour venir râler que j’ai cassé un truc chez eux. Donc comme d’habitude, je mets un pavé pour expliquer que ce genre de commandes n’est à réaliser que si vous êtes sûr de ce que vous faites, que vous avez des sauvegardes ou que vous vous en fichez de tout perdre. Nous ne sommes jamais à l’abri d’une typo, d’un comportement différent chez vous par rapport à chez moi ou d’un rayonnement cosmique aléatoire. Si vous voulez avoir plus d’info sur ce genre d’opérations, j’ai mis des liens en fin d’article.

resize2fs /dev/md126 100G
# Il demandera préalablement un e2fsck, faites lui plaisir
mdadm --grow /dev/md126 --size=115343360 # ça fait 110G
cat /proc/mdstat # vérifiez que la modification est bien prise en compte
parted
(parted) select /dev/sda
(parted) resizepart
Partition number? 2
End? 120G
# Et faire pareil avec sdb

Pour la partie avec parted, n’hésitez pas à BIEN prendre de la marge par rapport à l’opération avec mdadm, car j’ai eu des soucis à quelques Go près à cause d’une sombre histoire d’arrondis et de base 1000 versus base 1024…

Et sinon pour les Atoms ?

Les Atoms eux n’ont qu’un disque. L’avantage c’est donc qu’on ne risque pas d’avoir des soucis de RAID à la noix. bon… On a pas de RAID ni de MDADM mais… on a du LVM.

Le layout est relativement classique, on a un partitionnement standard LVM avec une partition 3 étendue et une partition 5 pour le PV…

Il va falloir donc réduire le FS (qui prend tout le PV/VG/LV), puis le LV, puis le PV, puis la partition, avec une marge de sécurité là aussi. Et en mode rescue aussi, bien sûr ;)

# Le FS
e2fsck -f /dev/system-lyqmb/root
resize2fs /dev/system-lyqmb/root 100G
# Le LV/PV
lvreduce /dev/system-lyqmb/root -L 105G
pvresize /dev/sda5 --setphysicalvolumesize 110g
# La partition
parted
[...]
(parted) resizepart
Partition number? 5
End? [1000GB]? 120G
Warning: Shrinking a partition can cause data loss, are you sure you want to continue?
Yes/No? yes

Upgrade

Une fois rebooté, on a maintenant des machines Proxmox propre, bien qu’obsolètes, avec de la place sur les disques. On peut maintenant passer à la mise à jour de PVE 5 à PVE 6, qu’il vaut mieux réaliser avant la mise en cluster (plus simple).

On commence par mettre à jour et faire le ménage, car c’est le bazar ici :

apt update
apt upgrade
apt autoremove

Pour passer à PVE 6, la première étape est d’installer corosync 3, prérequis à la migration.

echo "deb http://download.proxmox.com/debian/corosync-3/ stretch main" > /etc/apt/sources.list.d/corosync3.list
apt update
apt dist-upgrade --download-only
apt dist-upgrade

Le second prérequis est le passage de Debian Strech à Buster comme OS de base

sed -i 's/stretch/buster/g' /etc/apt/sources.list
sed -i -e 's/stretch/buster/g' /etc/apt/sources.list.d/pve-install-repo.list
apt update
apt dist-upgrade

Un petit reboot pour prise en compte du changement de kernel et de nouveau un peu de ménage

reboot
# Après reboot
apt autoremove

Maintenant, on est à jour !

Install ZFS et préparation des partitions

AT LAST !!!

On a des OS fraichement installés, à jour et avec de la place sur les disques. On peut donc préparer notre install de ZFS ainsi que la création des pools. Pas de surprise ici, on est sur Linux donc l’implémentation zfs est ZFSonLinux

apt-get install zfsutils-linux

Bon, on a fait de la place sur nos Atom et notre Xeon, mais on a pas encore fait de partition avec la place en plus. Maintenant que j’y pense, on aurait surement dû le faire en même temps que le redimensionnement mais bon c’est pas grave car comme c’est de l’espace libre on peut le faire à chaud avec fdisk cette fois-ci (sans rescue).

Le principe est le même sur les 3 serveurs, seul le numéro de partition change (sda4 et sdb4 pour le L3426, sda6 pour les Atoms).

fdisk /dev/sda
[...]
Command (m for help): n
All space for primary partitions is in use.
Adding logical partition 6
First sector (234377049-1953523711, default 234377216):
Last sector, +/-sectors or +/-size{K,M,G,T,P} (234377216-1953523711, default 1953523711):
Created a new partition 6 of type 'Linux' and of size 819.8 GiB.
Command (m for help): w
The partition table has been altered.
Syncing disks.

Note performance : il est déconseillé par les concepteurs de ZFS de faire des pools avec des bouts de disques comme ça… Mais en vrai, on s’en fiche un peu. Vous êtes sur des machines antédiluviennes, sur une install où vous bidouillez de partout, sur un OS patché et vous venez d’installer une réécriture de ZFS pour qu’il soit compatible GPL… autant dire que ces points de tuning de perf ZFS seront le cadet de nos soucis.

Préparation du pool ZFS

Normalement, zfs est installé et fonctionne. La commande zpool list doit renvoyer qu’il n’y a pas encore de pool

zpool list
no pools available

Sur la machine avec 2 disques, on va créer un pool en miroir sur sda4 et sdb4

zpool create -o ashift=12 rpool mirror /dev/sda4 /dev/sdb4
zpool list
NAME SIZE ALLOC FREE CKPOINT EXPANDSZ FRAG CAP DEDUP HEALTH ALTROOT
rpool 1.70T 480K 1.70T - - 0% 0% 1.00x ONLINE -

Le ashift=12 est un paramètre de perf, qui indique que les disques utilisent des blocs de 4096 (Advanced Format) et non plus de 512 comme « avant ».

Quand j'étais jeune

Je ne suis pas complètement sûr que ce soit nécessaire de l’indiquer, mais j’ai eu des problèmes par le passé avec les premières implémentations de ZFSonLinux, donc je préfère le mettre.

Et pour les Atoms :

zpool create -o ashift=12 rpool /dev/sda6

Et mon histoire elle est … FI-NIE :D

Comment ça « FI-NIE » ?

Oui bon, pour la mise en cluster, j’ai déjà traité le sujet plusieurs fois… vous pouvez continuer sur mes autres tutos qui en parle déjà, inutile de faire une redite.

Le but de cet article était de montrer la marche à suivre pour réussir à faire un « PRA du pauvre » avec un cluster de machines à bas coût chez OneProvider en tirant parti de Proxmox VE et de la réplication asynchrone avec ZFS.

Et ça, c’est maintenant c’est bon ;)

(La suite ici, du coup)

Cluster Proxmox VE, v6 cette fois ci !

(ou là)

Proxmox VE 6 + pfsense sur un serveur dédié (1/2)

Sources

[Tutoriel] Installation et configuration de VMware vSphere Replication 6.1.0

Sat, 02 Jan 2016 09:00:34 +0000

Présentation de VMware vSphere Replication

Une fonctionnalité sympathique (au moins sur le papier) lorsqu’on achète une licence VMware à partir de la très agressive Essential Plus est la possibilité de se créer un PRA automatisé via l’appliance VMware vSphere Replication.

L’idée est simple. Vous déployez l’appliance sur un ou plusieurs vCenter, puis vous sélectionnez les machines virtuelles que vous souhaitez synchroniser entre vos sites (ou sur un même site, cela créera une copie de sauvegarde) et régulièrement votre cluster VMware se charge d’en avoir une copie complète (mais en envoyant que le delta) à moins de X minutes de retard (Recovery Point Objective).

En réalité, le produit n’est ni plus ni moins qu’un équivalent de ce que font vos produits de sauvegarde de VM et qui tirent eux même partie des API de sauvegarde à chaud de VM mis à disposition par VMware (sauvegarde via snapshot, change block tracking, …). Je pense que ce produit se positionne comme concurrent des produits des grands éditeurs de la sauvegarde de VM (VEEAM pour n’en citer qu’un) et qui proposent pratiquement tous cette fonctionnalité.

Déploiement

Les captures d’écrans proviennent en partie d’un déploiement de vSphere Replication 5.8.1 mais il faut savoir que la procédure est strictement identique pour vSphere Replication 6.1.0. Je n’ai remonté aucune différence notable entre les deux outre le fait que l’une est pour un vCenter en version 5.X lorsque l’autre fonctionne avec un vCenter 6.X.

Récupérez le fichier zip contenant les sources de l’OVF de l’appliance vSphere Replication sur le site de VMware.

Pour la version 5.8.1 (vSphere 5.X)

VMware-vSphere_Replication-5.8.1.10254-2915556.zip (lien mort)
Administration de vSphere Replication 5.8 (lien mort, comme tout chez VMware)

Pour la version 6.1.0 (vSphere 6.X)

VMware-vSphere_Replication-6.1.0.10819-3051487.zip (lien mort)
Administration de vSphere Replication 6.1 (lien mort, comme tout chez VMware)

Connectez vous ensuite sur la console (client lourd ou web) et déployez l’OVF.

Pendant la phase de déploiement, renseignez le DNS, la passerelle, le netmask, puis l’adresse IP et le mot de passe root.

/!\ ACHTUNG : Avant de démarrer la VM, renseignez le hostname de la machine dans votre DNS et assurez vous bien que la machine y accède. C’est particulièrement vrai à partir de vSphere 6 où le problème s’est clairement amplifié et où aucuns de vos produits ne marcheront si votre DNS n’est pas correctement configuré (vCenter, Update Manager, vSphere Replication).

Bootez la machine virtuelle une fois que le déploiement est terminé. S’il y a eu une autre appliance précédemment enregistrée sur le vCenter, vous devrez valider en arrivant sur l’écran suivant :

Si tout se passe bien, on doit obtenir ceci dans la console.

Ouvrez un navigateur web pour finaliser la configuration de l’appliance via l’URL indiquée dans la console https://@IP_configurée:5480/

Vérifiez que les paramètres sont bons sur la console (les paramètres sont basiques).

Il faut ensuite vérifier que le serveur de réplication est bien connecté au serveur vCenter dans l’onglet VR/Configuration. Si ce n’est pas le cas, renseignez les logins/mdp du vCenter pour que l’appairage se fasse, puis cliquez sur « Save and Restart Service ».

Si tout fonctionne, la console doit afficher « VRM Service is running ».

De même, sur le client web vSphere, un nouveau module « vSphere Replication » apparait sur la page d’accueil.

Si vous souhaitez simplement disposer de la réplication sur un seul et même site, vous pouvez vous contenter de cette appliance.

Par contre, dans le cas où vous voudriez plutôt exporter les machines virtuelles sur un site de secours piloté par un autre vCenter, il faudra déployer une seconde appliance sur le deuxième site en suivant la même procédure.

Attention : les deux appliances doivent avoir la même version sinon elles ne communiqueront pas correctement. Et c’est donc potentiellement un problème car pour un vCenter 6.X, il vous faut une appliance vSphere Replication 6.1, et pour un vCenter 5.X une vSphere Replication 5.8. On en déduit donc que vos deux clusters doivent être de même version (5.X ou 6.X).

Configurer la réplication

Ouvrez maintenant la liste des machines virtuelles « Hôtes et clusters », puis faites un [clic droit] sur une machine virtuelle à répliquer.

Sélectionnez « Répliquer vers un système vCenter Server » dans tous les cas (c’est à dire, que le vCenter soit distinct sur un site de secours ou que vous souhaitiez rester au sein du même cluster).

Vous aurez donc le choix du site cible. Soit vous sélectionnez le vCenter local, soit vous ajoutez un site (vCenter) distant.

La première fois, seul le vCenter local apparaît. Si vous voulez en ajouter un autre, cliquez sur « Ajouter un site distant ». Remplissez les informations de connexion et un nouveau vCenter devrait apparaître dans la liste.

Cet écran est particulièrement intéressant puisqu’il nous permet de régler le RPO (Perte de données maximale admissible) ce qui aura bien entendu un impact sur la quantité de données qu’on va perdre en cas de bascule sur le PRA mais aussi la fréquence à laquelle les données entre sites seront synchronisées.

Une fois que c’est terminé, on peut observer l’état de santé de la réplication dans la page « Surveiller » du vCenter.

Et pour finir, les paramètres de la réplication peuvent être modifiés en ouvrant la page « Gérer » du vCenter.

Troubleshooting

La plupart des erreurs que vous pouvez avoir lors du déploiement des appliances VMware (que ce soit le vCenter VCSA ou le vSphere Replication) sont liés à des problèmes de résolution DNS. Comme les déploiements sont relativement longs donc je vous conseille vivement de bien vérifier que vos DNS sont bien à jour et que toutes les machines résolvent bien tous les noms, sinon vous devrez probablement tout recommencer.

Erreur « Invalid URI : The format of the URI could not be determined ».

Dans mon cas, le hostname du vCenter ne correspondait pas avec l’entrée dans le DNS et l’appliance de réplication n’arrivait pas à résoudre le vCenter.

L’icône refusait d’apparaître dans la console vCenter. Quand j’essayais d’ajouter manuellement le plugin à la main dans la console vSphere Client, le message suivant pouvait être lu dans le log de débug.

Heureusement que nous avons toujours le client lourd, car aucune erreur n’était visible dans le client web !

[       :startup :W: 1] 2015-11-26 16:03:05.159 Log for vSphere Client Launcher, pid=8744, version=6.0.0, build=build-3016447, option=release
[       :Failed t:P: 3] 2015-11-26 16:03:31.993 System.Net.WebException: Le nom distant n'a pas pu être résolu: 'vcenter'

Voir le KB de VMware (lien mort comme tout chez VMware) pour plus d’informations.

Limitations

Rétrocompatibilité

La première limitation que j’ai rencontré au produit est l’absence de rétro compatibilité entre les instances de vSphere Replication. Et donc comme on doit installer la version qui correspond à la version de son vCenter, cela vous oblige à avoir des clusters à des niveau de vSphere identiques, ce qui n’est pas toujours facile à réaliser selon les contextes.

Dans le fond, on ne peut pas trop leur en vouloir, c’est leur outil après tout. Ce qui est plus agaçant et qui est assez courant chez VMware, c’est l’absence de garde fou ou même de message d’erreur. Pour vous donner une idée, j’ai essayé de le faire lorsque je ne savais pas encore que les appliances 5.8 et 6.1 n’étaient pas compatibles. Que j’essaye d’initier la connexion depuis l’une ou l’autre, un message d’erreur pas du tout explicite s’affichait dans un sens, et il ne se passait rien du tout dans l’autre.

Il aurait été tellement simplement pourtant d’ajouter une petite vérification pour dire « Ah non ça ce n’est pas possible, pas la bonne version ! ». Mais bon ;-).

Bande passante

Le deuxième point est assumé par VMware et je ne comprend vraiment pas leur position.

Lorsque vous faite du vSphere Replication, il faut que les deux clusters aient entre eux un lien dédié à cela, que vous devrez estimer vous même en fonction de la taille estimée du delta à faire passer dans ce lien en fonction du RPO défini (voir le KB VMware (lien mort comme tout chez VMware)).

Pourquoi ? Tout simplement parce que lorsque vous allez lancer la synchronisation, votre liaison inter-site sera totalement saturée par vSphere Replication.

Does the vSphere Replication feature incorporate WAN bandwidth management?
No. vSphere Replication does not incorporate WAN bandwidth management. Use WAN optimizers to throttle and prioritize vSphere Replication traffic. To make it easier, vSphere Replication separates the initial replication from the ongoing replication using different ports so that you can assign different traffic shaping rules to the initial replication and ongoing replication.

Pas de gestion type QOS/traffic shaping pour restreindre la bande passante. A vous de le gérer vous même, soit via des équipements réseaux capable de gérer du trafic sur les ports utilisés par vSphere Replication, soit via des distributed vSwitchs et leur fonctionnalité Network IO Control (NIOC), disponibles si vous avez la version … Enterprise Plus (!!!).

Alors d’accord, une partie du problème peut être contourné en envoyant un disque dur avec les VMDK des machines à synchroniser sur le second site. Vous pouvez ainsi vous économiser l’envoi d’une grosse quantité d’information pour la première synchronisation et c’est seulement les deltas qui transiteront périodiquement sur votre réseau.

Pour autant, pour peu que vous ayez de grosses écritures sur les machines virtuelles que vous synchronisez, le problème reste entier. Le delta important entre deux synchronisations provoquera une saturation du réseau entre les deux sites.

En résumé, de la façon dont je vois les choses : vSphere Replication vers un site distant, disponible pour pratiquement tous les professionnels car accessible à partir de la très peu coûteuse Essential Plus, est donc totalement inutilisable sauf si :

Vous pouvez faire du traffic shaping sur votre infrastructure réseau
Vous disposez d’une liaison dédiée à cela (ou vous vous fichez de saturer votre réseau)
Vous avez la licence vSphere Entreprise Plus

Merci VMware. Trop sympa.

Documentation diverse

La documentation officielle sur le site de VMware (lien mort, comme tout chez VMware)
FAQ avec plusieurs points techniques intéressants sur vSphere Replication (lien mort, comme tout chez VMware)
La page wikipedia sur les PRA, relativement claire et permet d’appréhender les concepts
Le tutoriel de Yellow-Bricks pour la version 5.1 en mode réplication locale
La solution de VM Guy en utilisant le NIOC des VDS (lien mort, j’utilise Internet Archive)

[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.