Redhat Cluster Suite on Zwindler's Reflection

Partage de VMDK entre plusieurs VMs

Wed, 07 Jan 2015 16:05:17 +0000

Si vous déjà voulu faire un POC de cluster Linux sur des machines virtuelles VMware, vous vous êtes déjà demandé comment vous alliez faire pour partager entre deux serveurs un espace de stockage commun à ces deux machines.

Une façon de faire consiste à rajouter une couche d’abstraction du stockage au dessus de l’OS (via GlusterFS ou DRBD par exemple), mais dans le cas d’un POC pour valider un cluster connecté au SAN, ce n’est pas forcément la première solution qui vient à l’esprit. Personnellement, la plupart des clusters que je construis sont encore dans un schéma plus simple à base de LUNs iSCSI ou FC partagés sur un SAN en actif/actif ou actif/passif.

Cependant, pour simuler ce fonctionnement sur vos VMs, il va falloir bidouiller un peu.

En effet, pour éviter toute erreur malencontreuse (et même désastreuse), VMware interdit par défaut le démarrage de toute machine virtuelle qui aurait un disque en cours d’utilisation par une autre machine virtuelle. Aïe…

Voici un petit mode opératoire pour s’en sortir ;-)

Dans ce mode opératoire, les disques qu’on souhaite partager entre les deux serveurs sont des disques LVM en miroir, hébergés sur les baies de disques qui sont accessibles depuis les deux serveurs ESXi.

Cet exemple permet de valider la fiabilité de la méthode dans le cadre d’un cluster Linux virtuel de type RedHat Cluster Suite. Le principe reste tout de même valide pour une utilisation en dehors de RedHat Cluster Suite, certaines opérations ne seront juste pas nécessaires (qui peut le plus peut le moins).

Prérequis

Pour les besoins de la documentation, deux machines virtuelles test_partage_vmdk_1 et test_partage_vmdk_2 ont été créés. Elles disposent des caractéristiques techniques suivantes :

test_partage_vmdk_1
- hébergée sur ESXi1
- RedHat Entreprise Linux 5.8
- 2 vCPU, 1 Go de RAM
- 50 Go de disque interne sur un espace partagé
- IP 192.168.111.1/24 sur un réseau virtuel
test_partage_vmdk_2
- hébergée sur ESXi2
- RedHat Entreprise Linux 5.8
- 2 vCPU, 1 Go de RAM
- 50 Go de disque interne sur un espace partagé
- IP 192.168.111.2/24 sur un réseau virtuel

Création des disques virtuels

Les machines test_partage_vmdk_1 et test_partage_vmdk_2 doivent être éteintes avant de réaliser les modifications.

Ouvrir les paramètres de la machine virtuelle test_partage_vmdk_1, et ajouter un nouveau périphérique (Disque dur).

Le provisionnement du disque doit impérativement être « statique immédiatement mis à zéro ». De plus, il doit aussi être hébergé sur un datastore commun aux deux machines physiques ESXi.

Créer le disque et l’affecter à un Nœud périphérique virtuel qui n’est pas encore utilisé.

Ici, le disque interne est stocké sur l’adresse SCSI (0:0). Par défaut VMware propose de créer le disque à la suite en SCSI (**0:**1).

Il faut impérativement dérouler la liste pour affecter le disque à l’adresse SCSI (**1:**0) qui représente un nouveau contrôleur SCSI.

De plus, pour permettre l’usage des snapshots sur la partie disque dur interne, les disques doivent être créés en Mode Indépendant/Persistant. Dans le cas contraire, les snapshots seront impossibles sur la machine virtuelle.

Une fois le disque créé, un nouveau contrôleur SCSI est également créé. Avant de valider la création du disque et du contrôleur SCSI, il faut modifier le paramètre de Partage de bus de SCSI en mode « Physique ».

[4]Le second disque dur devra être créé de la même manière, et affecté au même contrôleur SCSI (on prendra l’adresse 1:1).

Remettre test_partage_vmdk_1 sous tension.

Ajout des disques virtuels sur la deuxième machine virtuelle

Ouvrir les paramètres de la machine virtuelle test_partage_vmdk_2, ajouter un nouveau périphérique (Disque dur) puis sélectionner « Utiliser un disque virtuel déjà configuré ».

Sélectionner le premier disque créé précédemment.

De la même manière que précédemment, on doit créer un disque dur virtuel sur un nouveau contrôleur SCSI et en mode Indépendant-Persistant.

Modifier le nouveau contrôleur SCSI comme précédemment :

Ajouter enfin le second disque de la même manière à l’adresse SCSI (1:1).

Valider et mettre la machine virtuelle sous tension. Si elle boot correctement c’est que le partage fonctionne.

Créer le miroir LVM partagé

Sur les deux serveurs, exécuter les commandes suivantes :

chkconfig acpid off #seulement pour RHCS
service acpid stop #seulement pour RHCS
vi /etc/lvm/lvm.conf
     filter = [ "a/.*/" ]
   #filter = [ "a|/dev/cciss/.*|", "a|/dev/mpath.*|", "r|.*|" ] #utiliser cette ligne en cas d’utilisation de multipath et de disques locaux présentés en tant que /dev/cciss. A adapter au contexte
[…]
volume_list = [ "vg01" , "@[TAG]" ]

Dans le cas de RedHat Cluster Suite, remplacer [TAG] par le nom de la machine tel qu’il est définit dans le fichier /etc/cluster/cluster.conf.

En dehors du cas d’un traitement automatisé par cluster, n’importe quel tag convient du moment qu’il est unique à la machine. Dans le cas présent, les tags choisis sont respectivement tag_vm1 et tag_vm2.

Quelques précisions :

filter permet de traiter les cas où on doit ignorer certains disques. C’est typiquement nécessaire lorsque l’on utilise LVM avec multipath ou powerpath, car l’OS voit plusieurs « disques » sda ,sdb, … pour un même disque mpath (1 sdX pour chaque chemin vers mpathY).
volume_list indique à LVM que seul le vg01 (interne) et les VG explicitement taggués avec le nom de la machine qui peuvent être utilisés. Cela permet de s’assurer qu’il n’y a qu’une seule machine qui peut activer le VG du moment qu’on n’ajoute jamais plus d’un tag au VG.

Même si les modifications du fichier lvm.conf sont prises en compte immédiatement, RedHat Cluster Suite impose une recompilation de l’initrd. Dans le cas d’un cluster RHCS, il faut donc lancer la commande suivante :

mkinitrd -f /boot/initrd-$(uname -r).img $(uname -r)

Sur un seul nœud (le premier) :

pvcreate /dev/sdb
pvcreate /dev/sdc
vgcreate -c n vg_mirror /dev/sdb /dev/sdc

Tagger le VG pour pouvoir travailler dessus sur ce nœud.

vgchange --addtag tag_vm1 -ay vg_mirror
lvcreate -n lv_mirror -m1 -l 5116 /dev/vg_mirror
Logical volume "lv_mirror" created

Le journal des écritures doit lui aussi être en miroir

lvconvert --mirrorlog mirrored /dev/vg_mirror/lv_mirror
Logical volume lv_mirror converted.

Il est enfin possible de formater le disque, et de le monter sur le test_partage_vmdk_1

mkfs.ext3 /dev/vg_mirror/lv_mirror
mount /dev/vg_mirror/lv_mirror /mnt

Tester la bascule

Scanner les VGs pour vérifier que le nouveau VG est bien disponible sur le test_partage_vmdk_2

vgscan
vgs

Même s’il le VG est visible, il n’est pas possible de le monter car il n’a pas le bon tag (tel que spécifié dans le lvm.conf). Cela permet de vérifier que l’on ne pourra pas écrire sur les disques sur les deux nœuds en même temps.

Not activating vg_mirror/lv_mirror since it does not pass activation filter.
0 logical volume(s) in volume group “vg_mirror” now active

On peut démonter le FS, désactiver le vg et enlever le tag sur le serveur test_partage_vmdk_1 et vérifier qu’on peut bien le monter et écrire dessus sur le test_partage_vmdk_2.

Ce comportement est automatique sous RedHat Cluster Suite, qui gère lui même les tags lors de la bascule d’un VG/LV.

Sur test_partage_vmdk_1

umount /mnt
vgchange --deltag tag_vm1 -an vg_mirror

Sur test_partage_vmdk_2

vgchange --addtag tag_vm1 -ay vg_mirror
mount /dev/vg_mirror/lv_mirror /mnt

Have fun

Best Practices pour Quorum Redhat Cluster Suite

Mon, 31 Mar 2014 13:51:11 +0000

Si vous avez déjà installé un cluster RHCS, vous saurez sûrement qu’il y a un certain nombre de paramètres qui semblent un peu arbitraires, et qui sont surtout assez mal définis chez Redhat. Je parle du totem token, du quorum_dev_poll et surtout de comment ils dépendent les uns avec les autres. Ces différentes valeurs correspondent à des durées de timeout sur les différents composants qui régissent le cluster.

C’est pourtant d’autant plus important à comprendre que, si vous laissez les valeurs initiales, vous pourrez avoir de vilaines surprises en cas de bascule multipath d’un chemin.

Personnellement, j’ai eu le cas sur un cluster hébergé chez un prestataire. Celui ci a réalisé des opérations sur son SAN, normalement transparentes, qui ont eu la fâcheuse conséquence de mettre en carafe toute l’infrastructure.

Ce qui s’est réellement passé, c’est que le timeout de multipath étant autour des 45 secondes en dur, les valeurs par défaut de perte du quorum était trop courte et le serveur se sabordait, pensant avoir perdu la cohérence du cluster.

Pour s’y retrouver, Redhat a publié un papier qui, à défaut d’expliquer ce à quoi correspond exactement chaque variable, détaille les best practices pour les fixer.

Les règles définies ci-dessous permettent de positionner les différentes variables qui réglementent les différents timeout d’un cluster Redhat Cluster Suite. Ces règles sont tirées du pdf du support Redhat « rhel_cluster_qdisk.pdf »

Règles à respecter

Les valeurs mises en gras sont celles qui sont dépendantes les unes des autres

Variable token du composant Totem

La variable token du composant totem doit respecter la formule suivante

<totem token > 2 * quorumd tko * interval

Donc pour la configuration du quorumd suivante (interval en secondes)

<quorumd label="myQDisk" interval="1" tko="10" min_score="1" votes="1">

On devra avoir totem token (en millisecondes) à

<totem token="21000"/>

Variable quorum_dev_poll de CMAN

La variable quorum_dev_poll de CMAN doit être égale à la variable totem token

cman quorum_dev_poll = totem token

Dans une configuration de base on aura

<cman expected_votes="3" quorum_dev_poll="21000"/>
[…]
<totem token="21000"/>

Variables tko et interval des heuristiques

Le produit de l’interval et du tko d’une heuristique doit être inférieur ou égal au produit de l’interval et du tko-1 du quorumd.

heuristics tko*interval <= quorumd interval*(tko-1)

Dans une configuration de base on aura

<quorumd label="myQDisk" interval="1" tko="10" min_score="1" votes="1">
[…]
<heuristic program="ping -c1 -w1 192.168.2.1" score="1" interval="2" tko="4" />

De plus, une heuristique doit avoir un tko > 1

Variables expected_votes de CMAN

La variable expected_votes de CMAN doit être égale à la formule suivante

Nombre de nœuds du cluster * 2 - 1

Quand on a 2 nœuds, c’est donc 3 votes, quand on a 3 nœuds c’est 5, etc.

Variable votes de quorumd

La valeur de la variable votes du quorumd doit être égale à la formule suivante

Nombre de nœuds du cluster - 1

Quand on a 2 nœuds, c’est donc 1 votes, quand on a 3 nœuds c’est 2, etc.

Règle sur les nœuds

Tous les nœuds du cluster doivent avoir un vote

<clusternode name="node1.example.org" votes="1" nodeid="1">
[…]

Variable two_node de CMAN

Seul cas de doute pour moi, il existe une variable two_nodes de CMAN. Je ne sais pas dire si la Best Practices indique que cette valeur doit valoir 0 ou ne pas être présente…

Configurations fonctionnelles IRL

Exemple de la configuration d’origine pour un cluster à 2 nœuds

<clusternode name="node1.example.org" votes="1" nodeid="1">
[…]
<clusternode name="node2.example.org" votes="1" nodeid="2">
[…]
<quorumd label="myQDisk" interval="1" tko="10" min_score="1" votes="1">
[…]
<heuristic program="ping -c1 -w1 192.168.2.1" score="1" interval="2" tko="4" />
<cman expected_votes="3" quorum_dev_poll="21000"/>
[…]
<totem token="21000"/>

Configuration modifiée pour PowerPath sur un cluster à 2 nœuds

Lorsqu’on utilise du multipathing ou powerpath pour réduire le nombre de SPOF du cluster, il est nécessaire de s’assurer que la perte et le basculement d’un lien se fait plus rapidement que le temps fixé par le cluster pour déterminer un échec.

Le produit des attributs interval * tko de quorumd doit donc être supérieur au temps nécessaire pour une bascule complète du lien multipath.

Les autres valeurs doivent être ensuite calculées à partir de ces deux attributs et des règles définies plus haut. A priori, on trouve sur les sites de la communauté d’EMC que les chemins peuvent prendre 45 secondes pour basculer. Ces valeurs se vérifient sur mes clusters en production.

Il Je préfère donc donner 50 secondes de battement au quorum disk avant de considérer le quorum comme perdu!

<clusternode name="node1.example.org" votes="1" nodeid="1">
[…]
<clusternode name="node2.example.org" votes="1" nodeid="2">
[…]
<cman expected_votes="3" quorum_dev_poll="101000"/>
[…]
<totem consensus="4800" join="60" token="101000" token_retransmits_before_loss_const="20"/>
<quorumd label="myQDisk" interval="5" tko="10" min_score="1" votes="1">
<heuristic program="ping -c1 -w1 192.168.2.1" score="1" interval="5" tko="9" />
<quorumd>

Démarrage forcé avec moins de la moitié des votes sur Redhat Cluster Suite (split brain my love)

Sun, 07 Jul 2013 21:01:27 +0000

Dans le cas où vous avez mis en place un cluster Redhat Cluster Suite sur votre infrastructure et que vous avez plusieurs salles distantes, vous êtes certainement tombé sur l’expression « split brain » (cf Split Brain sur Wikipedia). Généralement, il est intéressant de pouvoir empêcher deux serveurs en clusters qui ne se voient plus de fonctionner en même temps, c’est pourquoi avec RHCS il est possible sur des clusters 2 nœuds d’ajouter un disque SAN appelé Quorum Disk qui sert d’arbitre.

Cependant, il arrive des fois où les protections du cluster vous empêche de redémarrer, typiquement lorsque vous n’avez qu’une seule salle serveur disponible!

Revenons en arrière et imaginons que comme moi, vous disposez de :

une salle primaire composée d’un nœud du cluster et d’un SAN avec une moitié de miroir et un quorum disk
une salle secondaire composée d’un nœud du cluster et d’un SAN avec une moitié de miroir

Cela vous fait donc 3 votes (2 nœuds, 1 quorum sur le SAN), vous êtes relativement contents. Si l’interconnexion tombe totalement (SAN + LAN), les deux salles seront isolées l’une de l’autre, et la salle secondaire n’ayant pas accès au quorum sera donc coupée par le cluster par manque de votes. La salle primaire fonctionnera toujours avec sa partie du miroir. Si c’est uniquement un des deux serveurs qui tombe en panne, le second et le quorum feront toujours 2 votes, ce qui sera là aussi suffisant.

Imaginons maintenant que la salle primaire a été victime d’une attaque à la batte de baseball (risque relativement courant dans les salles serveurs), il est fort à parier que votre boss sera en train de vous crier dessus pour vous motiver à redémarrer votre infrastructure dans les plus brefs délais sur la salle secondaire.

Pourtant, en l’absence d’un second vote (on se rappelle, le quorum a été ratatiné par une batte), le cluster refusera de démarrer. Et pas la peine d’essayer de tricher en modifier le poids du nœud restant, la commande « ccs_tool update » refusera de mettre à jour un cluster qui a été dissolu et pas proprement reformé (ce qui s’annonce difficile).

La commande suivante vous sauvera la vie en vous permettant de modifier arbitrairement la quantités de votes « attendus » (comprenez nécessaires) par le cluster pour accepter de démarrer. Vous pourrez repartir sur votre salle secondaire. Elle est pas belle la vie ;-) ?

cman_tool expected -e 1

Attention tout de même, si jamais vous veniez à reconstruire le cluster (rétablissement de la liaison entre les deux salles) et que les deux salles ont toutes les deux été actives sur le SAN, votre miroir sera bien évidemment bon à jeter à la poubelle. A utiliser avec parcimonie et connaissance de cause…

Plus d’infos sur cman_tool sur la page man (ou sur le net)

man cman_tool

[Édit]La dernière fois que je l’ai utilisée j’ai du redémarrer d’abord le clusters via lucide PUIS lancer la commande pendant l’initialisation. A ce moment là, il cherche pendant un moment le reste du clusters puis abandonne, ce qui empêche rgmanager de fonctionner correctement. [/Édit]

[Tutoriel] Cluster Oracle 11gR2 avec Redhat Cluster Suite sur CentOS 5.4 (offline)

Sun, 15 Apr 2012 07:54:09 +0000

J’avais pour objectif de proposer une architecture sous Redhat permettant d’héberger en clustering une base de données Oracle en mode actif/passif (sans RAC donc) pour un nouveau client. L’architecture actuelle/connue était à base de serveurs HP-UX fonctionnant avec un cluster HP MCSG qui fonctionnait très bien, mais pour des raisons de support sur l’ERP le passage à Linux était obligatoire.

MCSG sur Redhat n’étant pas encore (est ce que ça va changer?) supporté officiellement par Redhat et HP, et heartbeat étant une solution trop légère pour ce genre d’application critique au business, il a bien fallut que je fasse une maquette basée sur Redhat Cluster suite. Le faible nombre de blogs traitant du sujet et le nombre d’échecs parmi les rares articles que j’ai trouvés auraient du me mettre la puce à l’oreille quant à la difficulté d’installation/configuration de ce produit. Et pour cause : malgré une documentation officielle relativement bien faite, certains passages sont carrément obscur pour ceux qui rentrent dans le sujet sans expérience préalable des clusters.

Ayant galérer pour faire marcher la solution dans les grandes lignes, je pense qu’il est de mon devoir (oui oui, rien que ça :-p) de faire partager la documentation que j’ai tiré de mes diverses expérimentations :

La documentation en elle même zwindler_redhat_cluster_suite
Le fichier doc qui contient les scripts. Oui, c’est affreux mais wordpress n’autorise en upload que quelques extensions et je n’ai pas l’envie de chercher une solution de contournement…

Autre chose : au début, je pensais qu’être coupé d’Internet sur les serveurs d’un admin n’était pas monnaie courante. Avec le peu de recul que j’ai aujourd’hui, je me rend compte que je subis très régulièrement cette contrainte! Ayant été obligé de me passer du net sur ma maquette, j’ai aussi indiqué les solutions de contournement que j’ai trouvé dans la documentation, au cas où certains seraient dans la même configuration.

Cependant, dans tous les cas, je ne conseille pas l’utilisation de RHCS sur une prod si vous débutez et/ou si vous n’avez pas d’accès à Internet pour effectuer des mises à jours du système : les bugs de cette version ainsi que les erreurs de débutant que j’ai pu faire sur ma maquette auraient assez vite corrompu la base de données d’une production.

N’hésitez pas à me faire remonter toute imperfection dans la documentation, que je puisse corriger pour les suivants