EDIT : Article et documentations associées actualisées pour prendre en compte Debian 6 sur les systèmes hôtes et la possibilité d’exécuter des machines virtuelles KVM.

Dans ce tutoriel je vais présenter comment mettre en oeuvre une architecture cluster haute disponibilité, à base de serveurs Debian dont le but est de constituer une plate-forme matérielle tolérante aux pannes pour héberger des machines virtuelles OpenVZ ou KVM.

Quel est le but recherché ?

Il s’agit de créer un groupe de serveurs pouvant exécuter des machines virtuelles de type OpenVZ ou KVM, organisés au sein d’une architecture matérielle permettant à ces machines virtuelles d’être exécutées par n’importe lequel de ces serveurs (mais une machine virtuelle ne s’exécute que sur un seul à la fois) et d’être déplacées d’un serveur à un autre aussi rapidement que possible, de manière à ce qu’en cas de panne d’un serveur, les machines virtuelles qu’exécutait le serveur défaillant puissent être instantanément relancées sur les autres serveurs du cluster. La faculté du cluster à permettre de déplacer instantanément les machines virtuelles d’un serveur à un autre constitue par ailleurs un énorme avantage pour l’administrateur système qui a en charge la maintenance des serveurs physiques et virtuels.

Ce type d’architecture est qualifiée de « haute disponibilité » en raison de sa grande tolérance aux pannes. En effet, il n’existe pas de point individuel de défaillance dans cette architecture, car tous les équipements et composants sont redondants.

En complément de la faculté du cluster à permettre la récupération rapide des services d’un serveur défaillant, il est possible d’installer, sur les serveurs physiques, un logiciel de gestion de cluster dont la fonction est de superviser le bon fonctionnement de ces derniers, et d’automatiser les actions de relance des services lorsqu’un serveur est défaillant. Un tel logiciel permet de relancer encore plus rapidement les services tombés en même temps que le serveur défaillant, car il ne nécessite pas d’intervention humaine. Je n’aborderai cependant pas cet aspect dans cet article. En effet, après avoir qualifié architectures matérielles et logicielles différentes et administré plusieurs clusters différents au cours de ces 10 dernières années, il se trouve que la solution qui convient le mieux à mes besoins n’utilise pas un tel logiciel. En outre, les deux logiciels de ce type que j’ai été amené à utiliser, SGI Failsafe et Redhat Cluster m’ont davantage posé de problèmes (déclenchements intempestifs, prises de décisions inadaptées…) qu’apporté une assistance lors de pannes. C’est pourquoi j’ai préféré m’en passer, du moins pour ce cluster.

L’architecture obtenue est décrite dans le schéma ci-dessous :

Architecture haute disponibilité pour l'hébergement de machines virtuelles OpenVZ et KVM

Dans ce schéma, seuls deux liens Fiber Channel et deux liens ethernet sont représentés, mais évidemment, c’est chaque serveur qui doit disposer de deux liens FC et deux liens ethernet.

Quels matériels faut-il ?

Pour mettre en oeuvre un tel cluster, il faut les matériels suivants :

• au moins deux serveurs physiques, comportant chacun deux ports Fiber Channel (sous la forme de 2 cartes x 1 port, ou 1 carte x 2 ports), deux cartes réseau (les serveurs récents ont tous au moins deux ports ethernet). Il est possible de batir la même architecture avec un SAN de type ISCSI au lieu de Fiber Channel, auquel cas les serveurs devront plutôt comporter 4 ports ethernet.
• deux switches Fiber Channel (ou deux switches ethernet configurés pour Jumbo Frames si SAN de type ISCSI)
• au moins une baie de disques Fiber Channel (ou ISCSI)

Les contraintes de mise en oeuvre sont les suivantes :

• Les machines virtuelles doivent être intégralement stockées dans une baie de disques externe aux serveurs, de sorte qu’en panne d’un serveur, un autre puisse immédiatement relancer les services que rendait le premier.
• Les serveurs peuvent être matériellement différents, mais aucun ne doit être particulier, afin qu’ils restent interchangeables. Ils doivent être configurés tous de la même façon, et ne doivent pas fournir un service qui ne soit pas virtualisé ou qui ne soit pas stocké dans une baie de disques.
• Tout ce qui est dans la baie de disques doit être redondant (alimentations, contrôleurs, connectique) et les disques configurés en RAID. Selon vos besoins de sécurité et de performance vous pourrez opter pour le niveau de RAID le plus adapté. Après avoir fonctionné un moment en RAID 5, j’ai rencontré des problèmes de performances j’utilise depuis le RAID 10.
• Je n’utilise pas de système de fichiers permettant des accès concurrents depuis plusieurs serveurs, tel que OCFS ou GFS. Après avoir qualifié ces deux systèmes de fichiers (certes, c’était en 2005 ou 2006), j’en étais arrivé à la conclusion que OCFS était performant mais incomplet (pas de support des ACL dont j’avais besoin) et que GFS était un monstre de lenteur. En outre, pour avoir déjà eu à faire des vérifications de système de fichiers (fsck) je suis un peu réticent à l’idée de mettre « tous mes oeufs dans le même panier », c’est pourquoi je n’ai pas essayé de nouvelles versions depuis. Cela implique que chaque machine virtuelle est stockée dans un volume virtuel de la baie de disque qui lui est dédié, et qui est partitionné et formaté (en ext4).
• L’accès au SAN par les serveurs peut se faire par deux chemins différents, redondants l’un de l’autre. Chaque chemin passe par un switch SAN différent et aboutit sur un contrpoleur différent de la baie de disques. Les volumes sont présentés par la baie de disques sur chaque contrôleur, ce qui implique que les serveurs voient les volumes deux fois, mais avec le même WWNN. La couche logicielle « multipath » permet au système d’exploitation de gérer cette redondance d’accès automatiquement. Suivant le mode de fonctionnement des contrôleurs des baies de disques, les deux ports Fiber Channel peuvent soit fonctionner en mode actif/passif ou actif/actif. Cependant, chaque volume aura un chemin actif et un chemin passif.
• Les cartes réseau des serveurs sont agrégées (bonding) en mode actif/passif et reliées a deux switches ethernet différents, configurés avec le spanning tree activé. Cela autorise la défaillance « transparente » d’un switch ethernet. La configuration des switches n’est pas abordée dans ce tutoriel.

Installation

La documentation d’installation de ce cluster est disponible dans les articles suivants (wiki) :