Conseil

Comment faire un cluster KVM haute disponibilité à moindre coût

La plupart des distributions Linux ont tout ce qu’il faut pour construire un cluster KVM haute disponibilité et assurer la sécurité de votre environnement.

Sander van Vugt
par
Publié le: 21 mai 2015

Beaucoup de petites entreprises utilisent la virtualisation KVM ordinaire. Mais trop souvent, aucune mesure en place n'assure la disponibilité en cas de panne de l’hôte. Dans cet article, vous apprendrez à développer une méthode simple pour assurer la disponibilité des machines virtuelles.

Vous pouvez utiliser KVM avec n’importe quelle distribution Linux, à quelques différences près dans la mise en oeuvre des clusters. La pile Pacemaker trouve son origine dans la distribution SUSE, tandis que Red Hat finalise actuellement son approche dans ses dernières versions. Cet article aborde la configuration du clustering pour OpenSUSE 13.1.


Figure 1 : Vue d’ensemble de l’architecture KVM haute disponibilité

Je pars du principe que les noeuds de votre cluster sont déjà connectés au réseau de stockage (SAN). Sinon, notez qu’il est relativement facile de connecter des hôtes de virtualisation à un SAN Linux. Vous pouvez bien évidemment utiliser une appliance SAN si votre environnement en est équipé. Notez que l’approche choisie ici, à savoir la construction du cluster à l’aide du système de fichiers partagé OCFS2, fonctionne uniquement avec un SAN.

Voici les grandes étapes de configuration d’un cluster KVM haute disponibilité :

  1. Créer le cluster de base.
  2. Configurer un système de fichiers de cluster OCFS2 pour créer un stockage partagé sur le SAN.
  3. Installer une machine virtuelle en utilisant le disque SAN comme dispositif de stockage en back-end.
  4. Configurer les ressources de cluster Pacemaker pour la machine virtuelle.
  5. Vérifier la configuration du cluster.

Créer le cluster de base

Pour créer un cluster de base sur OpenSUSE 13.1, commencez par saisir la commande zypper in pacemaker ocfs2-tools lvm2-clvm pour installer tous les packages nécessaires à la construction du cluster. Le cluster se compose de deux couches : celle de bas niveau, Corosync, gère les communications dans le cluster, tandis que celle de haut niveau gère les ressources. Pour configurer la couche de bas niveau, modifiez l’exemple de fichier de configuration ci-dessous : /etc/corosync/corosync.conf.exemple. Copiez ce fichier dans le fichier /etc/corosync/corosync.conf et modifiez les lignes suivantes :

bindnetaddr: 192.168.4.0

quorum {

        # Activer et configurer un sous-système quorum (valeur désactivée par défaut : "off")

        # voir aussi corosync.conf.5 et votequorum.5

        provider: corosync_votequorum

        expected_votes: 2

}

La ligne bindnetaddr doit indiquer l’adresse réseau IP que votre noeud utilise pour communiquer sur le réseau. Les lignes quorum indiquent au cluster le nombre de noeuds à prévoir.

Pour activer et lancer les services Corosync et Pacemaker, utilisez les commandes systemctl start corosync; systemctl start pacemaker; systemctl enable corosync; systemctl enable pacemaker. Saisissez crm_mon. Vous devriez obtenir en sortie une liste semblable à celle-ci, montrant que le cluster est opérationnel.

Last updated: Sun May 11 19:38:24 2014

Last change: Sun May 11 19:38:24 2014 by root via cibadmin on suse1

Stack: corosync

Current DC: suse1 (3232236745) - partition with quorum

Version: 1.1.10-1.2-d9bb763

2 Nodes configured

0 Resources configured

Online: [ suse1 suse2 ]

Configurer le SAN comme un stockage partagé

Pour configurer le système de fichiers partagé OCFS2, vous devez d’abord lancer certains services nécessaires au fonctionnement du cluster. Saisissez crm configure edit et ajoutez les lignes suivantes dans le fichier.

primitive dlm ocf:pacemaker:controld \

        op start interval="0" timeout="90" \

        op stop interval="0" timeout="100" \

        op monitor interval="10" timeout="20" start-delay="0"

primitive o2cb ocf:ocfs2:o2cb \

        op stop interval="0" timeout="100" \

        op start interval="0" timeout="90" \

        op monitor interval="20" timeout="20"

group ocfs2-base-group dlm o2cb

clone ocfs2-base-clone ocfs2-base-group \

        meta ordered="true" clone-max="2" clone-node-max="1"

property $id="cib-bootstrap-options" \

        cluster-infrastructure="corosync" \

        stonith-enabled="false"

Une fois ces services de base lancés, vous pouvez créer le système de fichiers OCFS2. Pour ce faire, saisissez mkfs.ocfs2 /dev/sdb. Ensuite, créez un répertoire nommé /shared sur les deux noeuds et saisissez à nouveau crm configure edit. A présent, ajoutez les lignes suivantes à la configuration du cluster :

primitive ocfs-fs ocf:heartbeat:Filesystem \

                    params fstype="ocfs2" device="/dev/disk/by-path/ip-192.168.1.125:3260-iscsi-iqn.2014-01.com.exemple:kiabi" directory="/shared" \

                    op stop interval="0" timeout="60" \

                    op start interval="0" timeout="60" \

                    op monitor interval="20" timeout="40"

clone ocfs-fs-clone ocfs-fs \

                    meta clone-max="2" clone-node-max=1

order ocfs2-fs-after-ocfs-base 1000: ocfs2-base-clone ocfs-fs

Vous devriez maintenant avoir un système de fichiers partagé disponible sur les deux noeuds et monté sur le répertoire /shared. Les fichiers écrits dans un noeud sont immédiatement visibles et accessibles par l’autre, ce qui est précisément la configuration nécessaire dans un environnement KVM haute disponibilité.

Pour approfondir sur Architectures de Datacenters