Introduction
Xen est l’une des technologie de virtualisation open-source les plus avancée. Utiliser la virtualisation permet, dans une certaine mesure, de faciliter le déploiement des machines et, ce faisant, d’améliorer la disponibilité des applications. La migration à chaud des machines virtuelles permet, très simplement, de vider une machine physique si, par exemple, on détecte un souci matériel ou si l’on souhaite faire des mises à jour logicielles. Mais, in fine, tout ceci se fait manuellement. N’étant pas à l’abri d’erreurs humaines, il serait plus facile à agréable de faire toutes ces opérations de migration automatiquement. Compliqué ? Pas tellement, suivez le guide…
Principes d’un cluster
D’après Wikipédia, un cluster (ou grappe de serveurs) est un ensemble de techniques consistant à regrouper plusieurs serveurs indépendants, afin de permettre une gestion globale et de dépasser les limitations d’un ordinateur pour :
- augmenter la disponibilité
- faciliter la montée en charge
- permettre une répartition de la charge
- faciliter la gestion des ressources (processeur, mémoire vive, disques dur, bande passante réseau)
Les clusters peuvent être de taille très différentes. En fait, le terme cluster peut s’appliquer à 2 serveurs (ou plus), configurés pour fournir le même service.
Définition du cluster Xen
Dans notre exemple, nous aurons 2 serveurs Xen qui serviront à faire tourner un certain nombre de machines virtuelles. Ces 2 machines physiques se répartiront les machines virtuelles. Il faut donc:
- que les domU soient répartis entre les dom0
- que chacun des dom0 puisse accueillir tous les domU
- que le système de fichier des domU soient disponibles sur les 2 serveurs dom0
- que la migration à chaud des domU soit activée
- que la configuration de Xen et des machines virtuelles (répartition initiale, ressources allouées, …) soit disponible sur les 2 serveurs
Contraintes du cluster Xen
Notre cluster doit être capable de respecter les contraintes suivantes:
- La configuration Xen est centralisée sur un FS cluster
- Le FS cluster est automatiquement monté dans chaque dom0
- La sauvegarde des domU est désactivée (migration à chaud gérée par le cluster)
- Le démarrage automatique des domU est désactivé (géré par le cluster)
- Un domU ne peut démarrer que sur le dom0 où la ressource DRBD associée est master
- Un domU ne peut démarrer que sur un dom0 dont le FS cluster est actif et monté
- Un domU ne peut tourner que sur un dom0 à la fois
Architecture du cluster
Une fois n’est pas coutume, vous aurez droit à un schéma d’architecture 😉
Les 2 machines considérées disposent chacune de 2 interfaces réseau. L’une servira à accéder à l’extérieur, l’autre sera dédiée à DRBD, au management du cluster et à la migration à chaud des domU.
Installation du cluster
Pour notre cluster, nous utiliserons Corosync
et Pacemaker
. Le premier est chargé de la gestion des messages au sein du cluster, le second de la gestion des ressources. Ces 2 logiciels sont disponibles dans un dépôt particulier:
Une fois installé, le cluster doit être configuré. Tout d’abord, nous allons générer et déployer la clef de chiffrement pour les messages du cluster. Cette clef servira notamment à authentifier les nodes.
Ensuite, il faut configurer Corosync pour qu’il utilise la bonne interface réseau.
Enfin, on peut démarrer corosync sur les 2 nodes, après avoir activé Corosync à l’aide de l’option Start=yes
dans le fichier /etc/default/corosync
.
On peut vérifier le bon fonctionnement du cluster à l’aide de la commande suivante crm_mon --one-shot -V
.
Le cluster nous informe qu’aucune ressource STONITH n’est définie et que c’est pourtant super important.
STONITH signifie « Shoot The Other Node In The Head ». Derrière ce charmant acronyme se cache l’une des principale fonctionnalités qu’un cluster doit implémenter: la possibilité de tuer un node ou une ressource de manière à être sûr qu’elle ne tourne plus. C’est particulièrement important, par exemple dans le cas où le cluster gère des IP virtuelles. Pour nos domU, c’est également important pour éviter que le même domU ne tourne sur les 2 dom0 simultanément.
Configuration du cluster
Une fois le cluster installé et configuré, il est temps de configurer les options par défaut. Elle sont au nombre de 3:
- stonith
- Vous le savez maintenant, un système en production ne devrait pas se passer de Stonith. Néanmoins ici, nous ne l’utiliserons pas.
- quorum
- Mécanisme de vote pour permettre au cluster de déterminer s’il peut travailler, il n’est pas nécessaire pour un cluster de 2 nodes.
- ressource default stickiness
- Ceci permettra aux ressources de demeurer sur le node sur lequel elle se trouvent après un fail-over. Notamment, ceci les empêchera de revenir automatiquement sur le node en échec, afin de laisser le temps à l’administrateur de réaliser les tests de bon fonctionnement.
Pour appliquer cette configuration, nous allons utiliser le « shell » particulier de Corosync, invoqué à l’aide de la commande crm
Une fois ces options configurées, il est temps d’installer Xen.
Configuration de LVM
Notre cluster Xen repose sur l’utilisation de LVM
.
Pour la suite, vous devez créer un VG
appelé XenHosting
. Dans ce VG
, vous devez alors créer un LV cluster-ocfs
.
Ces opérations doivent bien entendu être réalisées sur les 2 nodes.
Installation de DRBD
L’installation de DRBD est détaillé dans ce document: Installation de DRBD > 8.3.2 sur Debian GNU/Linux Lenny
Configuration de DRBD
Le résumé de la configuration de DRBD est détaillé dans ce document: DRBD: Distributed Replicated Block Device
En l’occurence, il faut tout d’abord mettre en place la configuration globale, puis la ressource DRBD0 qui servira à la configuration centralisée:
Installation de OCFS2
Il existe plusieurs solution de FS en cluster. Ici, j’ai décidé d’utiliser OCFS2.
Configuration de OCFS2
Une remarque concernant OCFS2. Idéalement, il faudrait gérer OCFS2 via pacemaker. Dans ce cas précis, ce n’est pas le cas (pour l’instant).
Configuration de la resource OCFS2 pour le cluster
Nous n’avons spécifié nulle part de point de montage pour la partition OCFS2 que nous venons de créer. Il y a une bonne raison à celà: c’est pacemaker
qui va se charger de tout.
Réfléchissons 2 minutes. OCFS2 n’est là que pour nous éviter d’avoir à copier la configuration Xen sur chaque nœud. La réplication est assurée par DRBD. Il faut donc d’abord démarrer DRBD et ensuite seulement monter le FS sur le point de montage de notre choix. Si DRBD n’est pas démarré ou pas en état Master, alors il ne faut surtout pas monter le FS.
Nous aurons donc besoin:
- D’une ressource (Master) de type DRBD qui gérera les états de la ressource DRBD sous-jacente (c’est pour cette raison qu’il nous faut DRBD dans une version > 8.3.2)
- D’une ressource (Clone) FileSystem qui contrôlera le montage du FS cluster. Cette ressource sera clônée, c’est à dire qu’elle s’appliquera aux 2 nodes comme si elle était unique.
- D’une contrainte qui garantira que le montage n’interviendra qu’après le démarrage de DRBD
- D’un point de montage. Pour nous, ce sera
/cluster
. Créez donc ce répertoire.
Here we go:
Si le point de montage existe, vous aurez le plaisir, que dis-je la joie, de voir le FS cluster monté « automagiquement ».
Installation de Xen
Je ne détaillerai pas les étapes nécessaires dans ce document. Pour plus d’informations, vous pouvez lire: Xen: Virtualisation sous GNU/Debian Linux
Dans tous les cas, ne créez pas encore de domU. Même si la migration d’un système stand-alone vers un système cluster est faisable, il est plus simple de partir de zéro, surtout si vous découvrez les clusters.
Configuration de Xen
En ce qui concerne la configuration de Xen, la configuration du dom0 restera dans /etc/xen/
. En revanche, la configuration des domU plus quelques bonus sera centralisée dans /cluster
.
Comme vous le voyez, je profite du FS cluster pour stocker des iso de CD d’install (on pourrait ajouter des CD de rescue) ainsi que les paquets debian liés au cluster, comme DRBD. Enfin, la configuration des machines virtuelles est également centralisée.
Afin de ne pas interférer avec le gestionnaire de cluster, il est important de désactiver le démarrage et la sauvegarde automatiques des domU. En effet, même si les domU sont répartis entre les dom0, ceux-ci seront automatiquement migrés d’un dom0 à l’autre lors d’un reboot par exemple.
Pour cela, il faut adapter la configuration de Xen
Enfin, juste avant de redémarrer le node pour que les modifications de la configuration Xen soient prises en compte, il faut:
Un redémarrage plus tard, vous y êtes. il est temps de configurer notre premier domU.
Configuration d’un domU Xen
Notre exemple reposera sur un domU HVM, c’est-à-dire en virtualisation complète. Ceci permet par exemple de pouvoir virtualiser une machine Windows sur un node Linux.
Ceci est le fichier de configuration de notre premier domU. Celui-ci disposera d’un CDRom ainsi que d’une console VNC. Le CD sera monté automatiquement au démarrage. Quant à la console, vous pouvez y accéder grâce à un tunnel SSH:
La console VNC est maintenant disponible sur l’interface locale de votre machine, sur le port 5901.
Vous pouvez installer dès maintenant le domU, ou préférer l’intégrer d’abord au cluster. Dans le premier cas, une fois l’installation du domU terminée, vous devez arrêter le domU avant de paramétrer Pacemaker pour qu’il le gère.
De toute façon, vous devez d’abord configurer la ressource DRBD. Les détails se trouvent là: DRBD: Distributed Replicated Block Device.
Intégration du domU dans le cluster
Nous allons configurer Pacemaker pour qu’il gère le domU. Pour cela, il faut:
- Configurer la ressource DRBD dans le cluster
- Configurer la ressource Master correspondante afin d’autoriser le cluster à avoir 2 ressources Master simultanément
- Configurer la ressource Xen
- Configurer la contrainte qui imposera que la ressource Xen ne puisse tourner sur un node dont la ressource DRBD est Master.
Le dernier point est très important. En effet, les version 8.3.2 de DRBD s’intègrent parfaitement dans le cluster. Mais il reste possible que la ressource DRBD soit en état instable (ou split brain). Et là, seule la réparation manuelle permet de corriger proprement le problème. En attendant, il faut naturellement empêcher qu’un domU ne puisse démarrer sur un node sans DRBD master. Sinon, l’échec du démarrage du domU sera enregistré par le cluster qui bloquera toute tentative ultérieure par la définition d’un contrainte spécifique. Il vous faudra alors résoudre le problème et effacer la contrainte en question. Tant que cela n’aura pas été fait, votre cluster sera lui-même dans un état imparfait puisque qu’une ressource au moins ne pourra pas être migrée en cas de défaillance du node sur lequel elle tourne.
Ceci fait, le domU devrait démarrer. Si vous avez paramétré la ressource DRBD sur le node B, vous devriez être capable de migrer la ressource. Dans le cas contraire, c’est un pré-requis 😉
Dernière précision, mais vous l’aviez sûrement déjà compris, vous n’avez pas besoin de re-déclarer les ressources sur le node B, le cluster s’est chargé de les propager.
Lors de la définition de la ressource Xen, l’attribut meta
allow-migrate="true"
permet la migration à chaud du domU concerné. En son absence, si vous décider de migrer la ressource, elle sera arrêtée sur le node d’origine pour être redémarrée sur le node de destination.
Gestion des ressources du cluster
Ci dessous quelques commandes qui vous permettrons de gérer le cluster, au moins au début 😉
Sources
- //clusterlabs.org/wiki/Debian_Lenny_HowTo
- //clusterlabs.org/wiki/Documentation
- //www.drbd.org/users-guide-emb/ch-pacemaker.html
- //clusterlabs.org/wiki/Dual_Primary_DRBD_%2B_OCFS2
- //www.howtoforge.com/installation-and-setup-guide-for-drbd-openais-pacemaker-xen-on-opensuse-11.1