Table des matières

Dernière mise-à-jour : 2021/01/24 12:16

HAR100 - Gestion de la Haute Disponibilité avec Red Hat Cluster Suite-Red Hat High-Availability Cluster

Introduction

Un cluster est ce que l'on appelle une grappe de serveurs. Chaque membre d'une grappe est un noeud ou membre. Il existe quatre types majeurs de cluster :

  • un cluster de stockage - permet une écriture simultanée sur un système de fichiers partagé tel Red Hat GFS (Global File System)
  • un cluster à haute disponibilité ou cluster failover - permet une augmentation de la disponibilité des services,
  • un cluster de répartition - permet une répartition de la charge sur plusieurs noeuds,
  • un cluster à haute performance - permet une utilisation des noeuds du cluster pour effectuer des calculs simultanés.

Red Hat Cluster Suite (RHCS) est un ensemble de logiciels fournissant les composants suivants :

  • Serveur virtuel Linux,
  • Gestionnaire de l'infrastructure du cluster,
  • Gestionnaire des services à haute disponibilité,
  • Outils d'administration du cluster.

De base, RHCS n'inclut pas les composants suivants :

Red Hat GFS

Red Hat GFS est un système de fichiers en cluster qui utilise :

  • des métadonnées distribués,
  • plusieurs fichiers de journaux,
  • un gestionnaire de verrouillage,

Les modifications aux données effectuées par un noeud sur un système de fichiers GFS sont immédiatement visibles aux autres noeuds

Le système de fichiers GFS fournit une image unique du système de fichiers pour tous les noeuds permettant, entre autre :

  • la simplification de l'infrastructure de données,
  • la simplification de l'installation et de l'application de correctifs,
  • l’absence de duplication des données de l'application,
  • l'accès concurrent aux données en lecture/écriture par plusieurs clients,
  • la simplification de la restauration de pertes de données,
  • la maximisation de l'utilisation des ressources de stockage,
  • la réduction des coûts d'administration du stockage,
  • la prise en charge du multipathing,
  • la gestion des volumes via CLVM.

Cluster Logical Volume Manager

CLVM fournit des volumes logique LVM2 au niveau d'un cluster et utilise de daemon clvmd afin ajouter des extensions cluster aux outils LVM classiques. Avec des modifications minimes au fichier de configuration LVM - /etc/lvm/lvm.conf - il est ainsi possible d'utiliser es commandes classiques de LVM2 afin de configurer et gérer des volumes logiques au niveau du cluster. Le daemon clvmd fonctionne sur chaque noeud et distribue les mises-à-jour des métadonnées LVM aux autres noeuds lors d'une modification. Lors d'une modification, l'accès au stockage physique est verrouillé en utilisant le gestionnaire de verrouillage DLM du cluster.

Global Network Block Device

GNBD fournit un accès à Red Hat GFS aux périphériques blocs en utilisant le protocole TCP. GNBD est souvent utilisé quand la mise en place de la technologie fibre channel est trop couteuse.

GNBD consiste en deux composants logiciels :

  • le client GNBD,
  • le serveur GNBD.

Le client GNBD fonctionne sur un noeud et importe un périphérique bloc exporté par le serveur GNBD qui fonctionne sur un autre noeud. Le périphérique bloc exporté par le serveur GNBD peut être soit un périphérique bloc local soit un SAN.

Les Composants de RHCS

Serveur Virtuel Linux

Avec le Serveur Virtuel Linux, connu sous le nom LVS, la répartition de charge est gérée par un directeur (Load Balancer) qui est un routeur LVS actif. En général, un routeur LVS passif est configuré afin de prendre le relais du routeur actif an cas de défaillance. L'ensemble du LVS est vu de l'extérieur comme un seul serveur.

Dans RHCS, le daemon pulse, le Gestionnaire de Ressources, est démarré sur le routeur passif et sur le routeur actif. Le daemon pulse sur le routeur passif envoie un signal Heartbeat à l'interface réseau public du routeur actif afin de s'assurer que ce dernier fonctionne toujours. Le daemon pulse sur le routeur actif démarre le daemon lvs qui répond au Heartbeat du routeur passif.

Le daemon lvs appelle l'utilitaire ipvsadm afin de mettre en place et maintenir à jour une table de routage appelée IPVS ( IP Virtual Server ) puis démarre une instance du service nanny par serveur virtuel, aussi appelé un service, configuré sur chaque serveur physique.

Chaque instance de nanny surveille son serveur virtuel. Dans le cas d'une défaillance, nanny demande à lvs d'appeler ipvsadm afin de supprimer de la table IPVS le serveur physique sur lequel fonctionne le serveur virtuel.

Si le routeur passif ne reçoit pas de réponse du serveur actif, il initialise un processus de Basculement (Failover) en envoyant une instruction d'arrêt du daemon lvs sur le routeur actif et en appelant send_arp afin de configurer ses interfaces réseaux physiques avec les adresses IP virtuelles du serveur actif.

LVS ne contient pas de composant de partage de données. De ce fait, soit les données doivent être synchronisées entre le routeur actif et le routeur passif avec, par exemple, rsync, soit il est nécessaire de mettre en place une mutualisation de stockage.

Gestionnaire de l'Infrastructure du Cluster

Gestionnaire du Cluster

La gestion du cluster est la tâche de CMAN (Cluster MANager). CMAN est un gestionnaire distribué et de ce fait fonctionne sur chaque neoud.

CMAN est responsable du suivi du Quorum. Si le cluster n'a pas Quorum, toute activité est arrêtée. Le Quorum est déterminé par des messages échangés entre les noeuds via Ethernet ou à travers un Disque Quorum. Pour que le Quorum soit obtenu, deux cas sont possibles :

  • dans le cas du Quorum via Ethernet - 50% des noeuds + 1 doivent être actifs,
  • dans le cas du Quorum via le disque Quorum - selon des conditions spécifiées par l'utilisateur.

Par défaut, chaque noeud possède une vote. Par contre il est possible d'augmenter le nombre de votes pour un noeud spécifique.

CMAN assure également le suivi des adhésions au cluster en analysant les messages des autres noeuds et informe ensuite les autres composants de toute modification afin qu'ils prennent les actions adéquates. Par exemple, si un noeud rejoint le cluster et monte un système de fichier GFS déjà monté par d'autres noeuds, un journal supplémentaire est créé et un gestionnaire de verrouillage est démarré.

Si un noeud reste silencieux pendant trop longtemps, les noeuds qui s'entendent forment un groupe. Si ce groupe a plus de 50% des votes attendues, le groupe gagne et le cluster continue à fonctionner. Le groupe va ensuite appellé le composant Fencing qui déconnecte le noeud.

La configuration de cman se trouve dans le fichier /etc/sysconfig/cman :

/etc/sysconfig/cman
# CMAN_CLUSTER_TIMEOUT -- amount of time to wait for joinging a cluster
#     before giving up.  If CMAN_CLUSTER_TIMEOUT is positive, then we will
#     wait CMAN_CLUSTER_TIMEOUT seconds before giving up and failing when
#     a cluster is not joined.  If CMAN_CLUSTER_TIMEOUT is zero, then
#     wait indefinately for a cluster join.  If CMAN_CLUSTER_TIMEOUT is
#     negative, do not check to see that the cluster has been joined
#CMAN_CLUSTER_TIMEOUT=60
 
# CMAN_QUORUM_TIMEOUT -- amount of time to wait for a quorate cluster on
#     startup quorum is needed by many other applications, so we may as
#     well wait here.  If CMAN_QUORUM_TIMEOUT is zero, quorum will
#     be ignored.
#CMAN_QUORUM_TIMEOUT=45
 
# CMAN_SHUTDOWN_TIMEOUT -- amount of time to wait for cman to become a
#     cluster member before calling cman_tool leave during shutdown.
#     The default is 60 seconds
#CMAN_SHUTDOWN_TIMEOUT=60
 
# CMAN_NOTIFYD_START - control the startup behaviour for cmannotifyd
# the variable can take 3 values:
# yes                   | will always start cmannotifyd
# no                    | will never start cmannotifyd
# conditional (default) | will start cmannotifyd only if scriptlets
#                         are found in /etc/cluster/cman-notify.d
#CMAN_NOTIFYD_START=conditional
 
# CMAN_SSHD_START - control sshd startup behaviour
# the variable can take 2 values:
# yes                   | cman will start sshd as early as possible
# no (default)          | cman will not start sshd
#CMAN_SSHD_START=no
 
# DLM_CONTROLD_OPTS -- allow extra options to be passed to dlm_controld daemon.
#DLM_CONTROLD_OPTS=""
 
# Allow tuning of DLM kernel config.
# do NOT change unless instructed to do so.
#DLM_LKBTBL_SIZE=""
#DLM_RSBTBL_SIZE=""
#DLM_DIRTBL_SIZE=""
#DLM_TCP_PORT=""
 
# FENCE_JOIN_TIMEOUT -- seconds to wait for fence domain join to
#     complete.  If the join hasn't completed in this time, fence_tool join
#     exits with an error, and this script exits with an error.  To wait
#     indefinitely set the value to -1.
#FENCE_JOIN_TIMEOUT=20
 
# FENCED_MEMBER_DELAY -- amount of time to delay fence_tool join to allow
#     all nodes in cluster.conf to become cluster members.  In seconds.
#FENCED_MEMBER_DELAY=45
 
# FENCE_JOIN -- boolean value used to control whether or not this node
#     should join the fence domain. If FENCE_JOIN is set to "no", then
#     the script will not attempt to the fence domain. If FENCE_JOIN is
#     set to "yes", then the script will attempt to join the fence domain.
#     If FENCE_JOIN is set to any other value, the default behavior is
#     to join the fence domain (equivalent to "yes").
#     When setting FENCE_JOIN to "no", it is important to also set
#     DLM_CONTROLD_OPTS="-f0" (at least) for correct operation.
#     Please note that clusters without fencing are not 
#     supported by Red Hat except for MRG installations.
#FENCE_JOIN="yes"
 
# FENCED_OPTS -- allow extra options to be passed to fence daemon.
#FENCED_OPTS=""
 
# NETWORK_BRIDGE_SCRIPT -- script to use for xen network bridging.
#     This script must exist in the /etc/xen/scripts directory.
#     The default script is "network-bridge".
#NETWORK_BRIDGE_SCRIPT="network-bridge"
 
# CLUSTERNAME -- override clustername as specified in cluster.conf
#CLUSTERNAME=""
 
# NODENAME -- specify the nodename of this node. Default autodetected
#NODENAME=""
 
# CONFIG_LOADER -- select default config parser.
# This can be:
# xmlconfig       - read directly from cluster.conf and use ricci as default
#                   config propagation method. (default)
#CONFIG_LOADER=xmlconfig
 
# CONFIG_VALIDATION -- select default config validation behaviour
# This can be:
# FAIL - Use a very strict checking. The config will not be loaded if there
#        for any kind of warnings/errors.
# WARN - Same as FAIL, but will allow the config to load (this is temporary
#        the default behaviour)
# NONE - Disable config validation. Highly discouraged.
#CONFIG_VALIDATION=WARN
 
# CMAN_LEAVE_OPTS -- allows extra options to be passed to cman_tool when leave
#     operation is performed.
#CMAN_LEAVE_OPTS=""
 
# INITLOGLEVEL -- select how verbose the init script should be
# possible values:
# quiet           - only one line notification for start/stop operations
# terse (default) - show only required activity
# full            - show everything
#INITLOGLEVEL=terse

Important - La modification des directives CMAN_CLUSTER_TIMEOUT et CMAN_QUORUM_TIMEOUT permettent la configuration du timeout de cman ainsi que le timeout du quorum. Les valeurs par défaut sont indiquées dans le fichier lui-même.

Le Disque Quorum

Le daemon qdiskd fournit des heuristiques supplémentaires pour déterminer la santé des noeuds. Le mécanisme se base sur l'utilisation d'un périphérique de type bloc appelé le Disque Quorum. Les points clefs sont :

  • chaque noeud doit avoir une vote,
  • le nombre de noeuds est limité à 16 par cluster,
  • le timeout de qdiskd doit être la moitié du timeout de cman,
  • la méthode de fencing doit être Power Fencing,
  • le périphérique bloc utilisé doit être partagé en mode lecture/écriture simultané pour tous les noeuds,
  • la taille recommandée est de 10 Mo.

Concrètement, l'utilisation d'un Disque Quorum permet de configurer un quorum atypique, par exemple un quorum où un seul noeud fonctionne.

Pour cette raison le Disque Quorum est utilisé en règle générale dans le cas d'un cluster à peu de nœuds. Considérez le situation où une panne de réseau a lieu entre deux noeuds dans un cluster à deux noeuds. Dans ce cas chaque noeud considère que le cluster lui appartient et essaie de fencé l'autre noeud. Cette situation s'appelle split brain.

La seule solution à ce problème en utilisant un Quorum via Ethernet est de ne pas tenir compte du quorum en indiquant <cman expected_votes=“1” two_node=“1”/> dans le fichier de configuration /etc/cluster/cluster.conf de chaque noeud.

Important - Le fichier /etc/cluster/cluster.conf est étudié dans le détail plus tard dans de ce cours.

L'autre façon de palier à ce problème est d'utiliser un Disque Quorum. Dans notre cas, chaque noeud à une vote de 1 tandis que le Disque Quorum lui-même a aussi une vote de 1.

Important - Dans un cas d'un cluster avec 3 noeuds ayant chacun une vote par exemple, le Disque Quorum aura 2 votes, c'est-à-dire le nombre total des votes des noeuds moins 1. De cette façon, il suffit de 3 votes sur 5 pour que le quorum soit atteint, autrement dit le Disque Quorum et 1 neoud.

Revenons à notre cluster de deux noeuds. Lors de l'utilisation d'un Disque Quorum, le qdiskd sur chaque noeud évalue son état et inscrit les informations d'état dans une partie du Disque Quorum. Le service qdiskd sur l'autre noeud vérifie ensuite les informations du premier noeud et vice-versa. Si, après plusieurs tentatives, un service qdiskd sur un neoud ne peut pas mettre à jour ses informations d'état, ceci est détecté par l'autre service qdiskd qui demande à ce que le noeud problématique soit fenced.

Important - Dans la version 6 de Red Hat et de CentOS, le service qdiskd est géré directement par le service cman. Notez que vous pouvez obtenir plus d'informations sur le Disque Quorum en lisant le manuel qdisk(5).

Gestionnaire du Verrouillage

La gestion du verrouillage est la tâche de DLM (Distributed Lock Manager). Comme son nom indique DLM est un gestionnaire distribué et de ce fait fonctionne sur chaque noeud. GFS utilise des verrous de DLM afin de synchroniser l'accès aux métadonnées sur un stockage partagé. CLVM utilise des verrous de DLM afin de synchroniser des mises à jour aux volumes logiques et groupes de volumes sur un stockage partagé.

Fencing

Fencing est géré par le deamon fenced et consiste en la déconnexion d'un noeud d'un stockage partagé du cluster afin de préserver l'intégrité des données.

Ils existe plusieurs types de Fencing dont :

  • Power Fencing — utilise un contrôleur de courant pour éteindre un noeud,
  • Fibre Channel Switch Fencing — désactive le port Fibre Channel connectant le stockage au noeud,
  • GNBD Fencing — désactive l'accès à un serveur GNBD.

Important - Certains périphériques fence intégrés sont capables d'arrêter un noeud en 4 ou 5 secondes. D'autres se reposent sur un arrêt géré par le système d'exploitation du noeud. Dans ce cas l'arrêt peut durer beaucoup plus longtemps. La liste des périphériques fence intégrés actuellement supportés par Red Hat se trouve à l'adresse : http://www.redhat.com/cluster_suite/hardware/

Un noeud peut être configuré avec plusieurs méthodes de Fencing en cascade. Si la première méthode échoue, la deuxième est appelée et ainsi de suite.

L'utilisation d'un périphérique fence intégré nécessite l'arrêt du service ACPI Soft-Off. L'arrêt de ce service peut être obtenu en utilisant la commande chkconfig :

[root@centos6 ~]# chkconfig --list acpid
acpid          	0:arrêt	1:arrêt	2:marche	3:marche	4:marche	5:marche	6:arrêt
[root@centos6 ~]# chkconfig --del acpid
[root@centos6 ~]# chkconfig --list acpid
le service acpid prend en charge chkconfig, mais il n'est enregistré à aucun niveau (exécutez « chkconfig --add acpid »)

Important - Il existe aussi la possibilité de modifier le BIOS du noeud ou d'ajouter acpi=off à la ligne kernel du fichier /boot/grub/grub.conf afin d'obtenir le même résultat mais l'utilisation de la commande chkconfig reste la méthode conseillée.

Gestionnaire de la Configuration du Cluster

La gestion de la configuration du cluster est la tâche de CSS (Cluster Configuration System). CSS est un gestionnaire distribué et de ce fait fonctionne sur chaque neoud.

CSS assure que le fichier de configuration du cluster sur chaque noeud est à jour. Ce fichier - /etc/cluster/cluster.conf - et au format XML et décrit les caractéristiques suivantes :

  • le nom du cluster,
  • le niveau de révision du fichier de configuration,
  • la ou les méthode(s) de fencing,
  • le nom de chaque noeud du cluster ainsi que son ID,
  • le nombre de votes du Quorum,
  • le périphérique de fencing,
  • les ressources gérées.

Gestionnaire des Services à Haute Disponibilité

La gestion des services à haute disponibilité du cluster est la tâche de rgmanager. Dans un cluster, une application peut être configurée avec d'autres ressources afin de créer un Service à Haute Disponibilité. Un service à haute disponibilité peut passer d'un nœud à un autre sans interruption. Un service à haute disponibilité est configuré dans le fichier de configuration de chaque nœud d'un Domaine de Basculement (Failover Domain), un sous-ensemble de nœuds d'un cluster.

Important - Par défaut, tous les 10 secondes, rgmanager recherche dans l'arbre des ressources celles qui ont dépassé l'intervalle de vérification. Chaque agent de ressource spécifie l'intervalle de vérification pour la ressource concernée. Cette intervalle peut être modifiée en éditant le fichier /etc/cluster/cluster.conf en spécifiant une intervalle pour une ressource spécifique avec la balise <action> : <action name=“status” depth=“*” interval=“10” />. Certains agents fournissent plusieurs profondeurs (depths) de vérification. Plus profonde est la vérification, plus complet est la vérification. Dans l'exemple précédent, l'intervalle concerne tous les profondeurs.

Outils d'administration du cluster

Conga

Conga est un ensemble intégré de composants qui fournit une configuration et une gestion des clusters et du stockage Red Hat. Conga permet :

  • une gestion du cluster et du stockage via une interface Web,
  • un déploiement automatisé des données du cluster et des paquets de support,
  • une intégration avec des clusters existants,
  • l'intégration du statut et des fichiers journaux du cluster,
  • un contrôle des autorisations des utilisateurs.

Les principaux composants de Conga sont :

  • luci - un serveur qui communique avec plusieurs clusters et ordinateurs via ricci,
  • ricci - un agent démarré sur chaque ordinateur géré par Conga.

Important - L'outil system-config-cluster contenant le Cluster Configuration Tool et le Cluster Status Tool, disponible dans RHEL 5, n'est pas disponible dans RHEL6.

En Ligne de Commande

RHCS propose également des outils en ligne de commande :

Commande Description
ccs_tool Outil système de configuration du cluster
cman_tool Outil de gestion du cluster
fence_tool Outil Fencing
clustat Utilitaire de statut du cluster
clusvcadm Utilitaire d'administration des services utilisateur du cluster

Installation du Matériel

Un cluster comprend généralement le matériel suivant :

  • Noeuds - ordinateurs capable d'exécuter RHEL 6 et munis d'au moins 1 Go de RAM,
  • Un commutateur vers le réseau public pour permettre aux clients d'avoir accès au cluster,
  • Un commutateur vers le réseau privé pour permettre aux neouds de se communiquer,
  • Un commutateur d'alimentation pour le fencing,
  • Un commutateur fibre channel pour le fencing,
  • Du stockage partagé.

Installer le Logiciel du Module Red Hat High Availability

L'installation de Red Hat High Availability se fait simplement en utilisant yum :

[root@centos6 ~]# yum -y install rgmanager lvm2-cluster gfs2-utils wget

Démarrer l'Agent ricci

Dans Red Hat 6 , l'agent ricci remplace l'agent ccsd disponible dans les versions précédentes. L'agent ricci doit être démarré sur chaque noeud afin que les mises-à-jour de la configuration du cluster puissent être propagées aux autres noeuds.

Vérifiez si ricci est démarré :

[root@centos6 ~]# service ricci status
ricci est arrêté

Démarrez ricci puis configurez-le pour un démarrage automatique en utilisant la commande chkconfig :

[root@centos6 ~]# service ricci start
Démarrage de oddjobd :                                     [  OK  ]
generating SSL certificates...  done
Generating NSS database...  done
Démarrage de ricci :                                       [  OK  ]
[root@node1 ~]# chkconfig --list ricci
ricci          	0:arrêt	1:arrêt	2:arrêt	3:arrêt	4:arrêt	5:arrêt	6:arrêt
[root@node1 ~]# chkconfig --levels 2345 ricci on
[root@node1 ~]# chkconfig --list ricci
ricci          	0:arrêt	1:arrêt	2:marche	3:marche	4:marche	5:marche	6:arrêt

A partir de Red Hat Enterprise Linux 6.1, lors de la première propagation des modifications de la mise à jour de la configuration du cluster, ricci requiert un mot de passe. Pour fixer le mot de passe de ricci, utilisez la commende passwd :

[root@centos6 ~]# passwd ricci
Changement de mot de passe pour l'utilisateur ricci.
Nouveau mot de passe : ricci
MOT DE PASSE INCORRECT : trop court
MOT DE PASSE INCORRECT : est trop simple
Retapez le nouveau mot de passe : ricci
passwd : mise à jour réussie de tous les jetons d'authentification.

Important - Dans le cas de notre exemple, le mot de passe est ricci. Le mot de passe ci-dessus vous est montré dans le cadre de l'exemple. Dans le cas d'un système en production, le mot de passe ne sera pas visible et doit être autre que ricci !

Pré-Configurer les Noeuds

Considérations Générales

En implémentant une solution de cluster avec Red Hat High Availability, il est important de savoir que :

  • le nombre maximum de noeuds supportés par Red Hat High Availability est de 16,
  • Red Hat ne supporte pas de clusters multi-sites. Seuls les clusters mono-sites sont supportés,
  • Red Hat ne supporte pas l'utilisation du système de fichiers GFS2 sur un seul et unique noeud,
  • afin de maintenir l'intégrité des données, seul un noeud à la fois peut gérer un service donné et accéder aux données y associées,
  • Red Hat High Availability peut être configuré dans des configurations matérielles qui ne sont pas No-single-point-of-failure,
  • Red Hat High Availability est compatible avec les modes 0, 1 et 2 du Ethernet Channel Bonding ( l'agrégation de plusieurs interfaces réseaux ), à savoir les modes Round-Robin, Active-Passive et Balance xor,
  • Red Hat High Availability est compatible IPv4 et IPv6,
  • Les composants utilisés dans le cluster tels les périphériques de fencing et switchs Fibre Channel doivent figurés dans la liste de compatibilité : http://www.redhat.com/cluster_suite/hardware/,
  • Red Hat High Availability est compatible avec SELinux en mode enforcing avec une politique targeted,
  • Les éventuelles machines virtuelles dans un cluster doivent être démarrées et arrêtées en utilisant la commande rgmanager. L'utilisation de la commande virsh pourrait démarrer la machine virtuelle dans plusieurs endroits créant ainsi une corruption de données. Le service libvirt-guests doit être désactivé sur chaque noeud où fonctionne rgmanager,
  • Le service cman ne démarrera pas dans le cas où le service NetworkManager est lancé voire arrêté tout en étant configuré par la commande chkconfig.

Préparation des Machines Virtuelles

A partir de votre machine virtuelle Redhat, créez 3 clones complets et configurez-les ainsi :

Nom de la VM RAM
node1 1 024 Mo
node2 1 024 Mo
node3 1 024 Mo

Instructions Particulières

  • Lors de la création des clones, veillez à réinitialiser l'adresse MAC de la carte réseau,
  • Lors du premier lancement de chaque clone éditez le fichier /etc/udev/rules.d/70-persistent-net.rules et supprimez la première entrée ayant la valeur du champs NAME=“eth0”. Editez ensuite la ligne restante en modifiant la valeur du champs NAME=“eth1” en NAME=“eth0”,
  • Re-démarrez chaque machine virtuelle après avoir effectué les modifications,
  • Vérifiez la configuration réseau à l'aide de la commande ifconfig.

Arrêtez ensuite les machines node1, node2 et node3. Modifiez la configuration réseau des trois machines :

Adaptateur eth0 eth1 eth2
Type de réseau NAT intnet intnet

Démarrez les machines virtuelles node1, node2 et node3.

Ethernet Channel Bonding

Le Channel Bonding est un regroupement d'interfaces réseau sur le même serveur afin de mettre en place la redondance ou d'augmenter les performances.

Le Channel Bonding est géré nativement sous Linux. Aucune application tierce n'est requise.

Configuration du node1

Arrêtez et supprimez le service NetworkManager puis activez le service network :

[root@centos6 ~]# service NetworkManager stop
Arrêt du démon NetworkManager :                            [  OK  ]
[root@centos6 ~]# chkconfig --del NetworkManager
[root@centos6 ~]# chkconfig --list network
network        	0:arrêt	1:arrêt	2:marche	3:marche	4:marche	5:marche	6:arrêt
[root@centos6 ~]# chkconfig --add network
[root@centos6 ~]# chkconfig --list network
network        	0:arrêt	1:arrêt	2:marche	3:marche	4:marche	5:marche	6:arrêt

Créez le fichier /etc/sysconfig/network-scripts/ifcfg-bond0 :

ifcfg-bond0
DEVICE=bond0
USERCTL=no
BOOTPROTO=none
ONBOOT=yes
IPADDR=10.0.3.15
NETMASK=255.255.255.0
NETWORK=10.0.3.0
BONDING_OPTS="miimon=100 mode=balance-xor"
TYPE=Unknown
IPV6INIT=no

Éditez le fichier /etc/sysconfig/network-scripts/ifcfg-eth0 :

ifcfg-eth0
DEVICE="eth0"
NM_CONTROLLED="no"
ONBOOT=yes
TYPE=Ethernet
BOOTPROTO=static
IPV6INIT=no
NETMASK=255.255.255.0
IPADDR=10.0.2.15
GATEWAY=10.0.2.2
USERCTL=yes

Éditez le fichier /etc/sysconfig/network-scripts/ifcfg-eth1 :

ifcfg-eth1
DEVICE=eth1
BOOTPROTO=none
ONBOOT=yes
MASTER=bond0
SLAVE=yes
USERCTL=no

Éditez le fichier /etc/sysconfig/network-scripts/ifcfg-eth2 :

ifcfg-eth2
DEVICE=eth2
BOOTPROTO=none
ONBOOT=yes
MASTER=bond0
SLAVE=yes
USERCTL=no

Créez le fichier /etc/modprobe.d/bonding.conf :

bonding.conf
alias bond0 bonding

Modifiez le fichier /etc/sysconfig/network :

network
NETWORKING=yes
HOSTNAME=node1.fenestros.loc

Modifiez le fichier /etc/resolv.conf :

resolv.conf
nameserver 8.8.8.8
nameserver 8.8.4.4

Modifiez le fichier /etc/hosts :

hosts
127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
::1         localhost localhost.localdomain localhost6 localhost6.localdomain6
10.0.3.15	node1.fenestros.loc 	node1
10.0.3.16	node2.fenestros.loc	node2
10.0.3.17	node3.fenestros.loc	node3

Saisissez les deux commandes suivantes :

[root@centos6 ~]# hostname node1.fenestros.loc
[root@centos6 ~]# service network start
Ouverture des Ports

Les ports indiqués dans le tableau suivant doivent être ouverts sur chaque noeud :

Port Application
5404/udp, 5405/udp corosync/cman
11111/tcp ricci
21064/tcp dlm
16851/tcp modclusterd

Utilisez les commandes suivantes pour ouvrir les ports pour cman dans iptables :

[root@centos6 ~]# iptables -I INPUT -m state --state NEW -m multiport -p udp -s 10.0.3.0/24 -d 10.0.3.0/24 --dports 5404,5405 -j ACCEPT
[root@centos6 ~]# iptables -I INPUT -m addrtype --dst-type MULTICAST -m state --state NEW -m multiport -p udp -s 10.0.3.0/24 --dports 5404,5405 -j ACCEPT

Utilisez la commande suivante pour ouvrir les ports pour ricci dans iptables :

[root@centos6 ~]# iptables -I INPUT -m state --state NEW -p tcp -s 10.0.3.0/24 -d 10.0.3.0/24 --dport 11111 -j ACCEPT

Utilisez la commande suivante pour ouvrir les ports pour dlm dans iptables :

[root@centos6 ~]# iptables -I INPUT -m state --state NEW -p tcp -s 10.0.3.0/24 -d 10.0.3.0/24 --dport 21064 -j ACCEPT 

Utilisez la commande suivante pour ouvrir les ports pour modclusterd dans iptables :

[root@centos6 ~]# iptables -I INPUT -m state --state NEW -p tcp -s 10.0.3.0/24 -d 10.0.3.0/24 --dport 16851 -j ACCEPT

Utilisez la commande suivante pour ouvrir les ports pour igmp ( Internet Group Management Protocol ) dans iptables :

[root@centos6 ~]# iptables -I INPUT -p igmp -j ACCEPT

Utilisez la commande suivante pour ouvrir les ports pour luci dans iptables :

[root@centos6 ~]# iptables -I INPUT -m state --state NEW -p tcp -s 10.0.3.0/24 -d 10.0.3.0/24 --dport 8084 -j ACCEPT

Dernièrement, saisissez les commandes suivantes pour terminer la configuration d'iptables :

[root@centos6 ~]# service iptables save
iptables : Sauvegarde des règles du pare-feu dans /etc/sysc[  OK  ]tables : 
[root@centos6 ~]# service iptables restart
iptables : Suppression des règles du pare-feu :            [  OK  ]
iptables : Configuration des chaînes sur la politique ACCEP[  OK  ]er 
iptables : Déchargement des modules :                      [  OK  ]
iptables : Application des règles du pare-feu :            [  OK  ]

Vérifiez maintenant votre configuration d'iptables :

[root@centos6 ~]# service iptables status
Table : filter
Chain INPUT (policy ACCEPT)
num  target     prot opt source               destination         
1    ACCEPT     tcp  --  10.0.3.0/24          10.0.3.0/24         state NEW tcp dpt:8084 
2    ACCEPT     2    --  0.0.0.0/0            0.0.0.0/0           
3    ACCEPT     tcp  --  10.0.3.0/24          10.0.3.0/24         state NEW tcp dpt:16851 
4    ACCEPT     tcp  --  10.0.3.0/24          10.0.3.0/24         state NEW tcp dpt:21064 
5    ACCEPT     tcp  --  10.0.3.0/24          10.0.3.0/24         state NEW tcp dpt:11111 
6    ACCEPT     udp  --  10.0.3.0/24          0.0.0.0/0           ADDRTYPE match dst-type MULTICAST state NEW multiport dports 5404,5405 
7    ACCEPT     udp  --  10.0.3.0/24          10.0.3.0/24         state NEW multiport dports 5404,5405 
8    ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED 
9    ACCEPT     icmp --  0.0.0.0/0            0.0.0.0/0           
10   ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0           
11   ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           state NEW tcp dpt:22 
12   REJECT     all  --  0.0.0.0/0            0.0.0.0/0           reject-with icmp-host-prohibited 

Chain FORWARD (policy ACCEPT)
num  target     prot opt source               destination         
1    REJECT     all  --  0.0.0.0/0            0.0.0.0/0           reject-with icmp-host-prohibited 

Chain OUTPUT (policy ACCEPT)
num  target     prot opt source               destination         

Arrêtez votre machine virtuelle. Créez deux clones : node10 et node100. Démarrez la machine node1.

Configuration du node2

Arrêtez et supprimez le service NetworkManager puis activez le service network :

[root@centos6 ~]# service NetworkManager stop
Arrêt du démon NetworkManager :                            [  OK  ]
[root@centos6 ~]# chkconfig --del NetworkManager
[root@centos6 ~]# chkconfig --list network
network        	0:arrêt	1:arrêt	2:marche	3:marche	4:marche	5:marche	6:arrêt
[root@centos6 ~]# chkconfig --add network
[root@centos6 ~]# chkconfig --list network
network        	0:arrêt	1:arrêt	2:marche	3:marche	4:marche	5:marche	6:arrêt

Important - Le service cman ne démarrera pas dans le cas où le service NetworkManager est lancé voire arrêté tout en étant configuré par la commande chkconfig.

Créez le fichier /etc/sysconfig/network-scripts/ifcfg-bond0 :

ifcfg-bond0
DEVICE=bond0
USERCTL=no
BOOTPROTO=none
ONBOOT=yes
IPADDR=10.0.3.16
NETMASK=255.255.255.0
NETWORK=10.0.3.0
BONDING_OPTS="miimon=100 mode=balance-xor"
TYPE=Unknown
IPV6INIT=no

Éditez le fichier /etc/sysconfig/network-scripts/ifcfg-eth0 :

ifcfg-eth0
DEVICE="eth0"
NM_CONTROLLED="no"
ONBOOT=yes
TYPE=Ethernet
BOOTPROTO=static
IPV6INIT=no
NETMASK=255.255.255.0
IPADDR=10.0.2.15
GATEWAY=10.0.2.2
USERCTL=yes

Éditez le fichier /etc/sysconfig/network-scripts/ifcfg-eth1 :

ifcfg-eth1
DEVICE=eth1
BOOTPROTO=none
ONBOOT=yes
MASTER=bond0
SLAVE=yes
USERCTL=no

Éditez le fichier /etc/sysconfig/network-scripts/ifcfg-eth2 :

ifcfg-eth2
DEVICE=eth2
BOOTPROTO=none
ONBOOT=yes
MASTER=bond0
SLAVE=yes
USERCTL=no

Créez le fichier /etc/modprobe.d/bonding.conf :

bonding.conf
alias bond0 bonding

Modifiez le fichier /etc/sysconfig/network :

network
NETWORKING=yes
HOSTNAME=node2.fenestros.loc

Modifiez le fichier /etc/resolv.conf :

resolv.conf
nameserver 8.8.8.8
nameserver 8.8.4.4

Modifiez le fichier /etc/hosts :

hosts
127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
::1         localhost localhost.localdomain localhost6 localhost6.localdomain6
10.0.3.15	node1.fenestros.loc 	node1
10.0.3.16	node2.fenestros.loc	node2
10.0.3.17	node3.fenestros.loc	node3

Saisissez les deux commandes suivantes :

[root@centos6 ~]# hostname node2.fenestros.loc
[root@centos6 ~]# service network start
Ouverture des Ports

Les ports indiqués dans le tableau suivant doivent être ouverts sur chaque noeud :

Port Application
5404/udp, 5405/udp corosync/cman
11111/tcp ricci
21064/tcp dlm
16851/tcp modclusterd

Utilisez les commandes suivantes pour ouvrir les ports pour cman dans iptables :

[root@centos6 ~]# iptables -I INPUT -m state --state NEW -m multiport -p udp -s 10.0.3.0/24 -d 10.0.3.0/24 --dports 5404,5405 -j ACCEPT
[root@centos6 ~]# iptables -I INPUT -m addrtype --dst-type MULTICAST -m state --state NEW -m multiport -p udp -s 10.0.3.0/24 --dports 5404,5405 -j ACCEPT

Utilisez la commande suivante pour ouvrir les ports pour ricci dans iptables :

[root@centos6 ~]# iptables -I INPUT -m state --state NEW -p tcp -s 10.0.3.0/24 -d 10.0.3.0/24 --dport 11111 -j ACCEPT

Utilisez la commande suivante pour ouvrir les ports pour dlm dans iptables :

[root@centos6 ~]# iptables -I INPUT -m state --state NEW -p tcp -s 10.0.3.0/24 -d 10.0.3.0/24 --dport 21064 -j ACCEPT 

Utilisez la commande suivante pour ouvrir les ports pour modclusterd dans iptables :

[root@centos6 ~]# iptables -I INPUT -m state --state NEW -p tcp -s 10.0.3.0/24 -d 10.0.3.0/24 --dport 16851 -j ACCEPT

Utilisez la commande suivante pour ouvrir les ports pour igmp ( Internet Group Management Protocol ) dans iptables :

[root@centos6 ~]# iptables -I INPUT -p igmp -j ACCEPT

Dernièrement, saisissez les commandes suivantes pour terminer la configuration d'iptables :

[root@centos6 ~]# service iptables save
iptables : Sauvegarde des règles du pare-feu dans /etc/sysc[  OK  ]tables : 
[root@centos6 ~]# service iptables restart
iptables : Suppression des règles du pare-feu :            [  OK  ]
iptables : Configuration des chaînes sur la politique ACCEP[  OK  ]er 
iptables : Déchargement des modules :                      [  OK  ]
iptables : Application des règles du pare-feu :            [  OK  ]

Vérifiez maintenant votre configuration d'iptables :

[root@centos6 ~]# service iptables status
Table : filter
Chain INPUT (policy ACCEPT)
num  target     prot opt source               destination         
1    ACCEPT     2    --  0.0.0.0/0            0.0.0.0/0           
2    ACCEPT     tcp  --  10.0.3.0/24          10.0.3.0/24         state NEW tcp dpt:16851 
3    ACCEPT     tcp  --  10.0.3.0/24          10.0.3.0/24         state NEW tcp dpt:21064 
4    ACCEPT     tcp  --  10.0.3.0/24          10.0.3.0/24         state NEW tcp dpt:11111 
5    ACCEPT     udp  --  10.0.3.0/24          0.0.0.0/0           ADDRTYPE match dst-type MULTICAST state NEW multiport dports 5404,5405 
6    ACCEPT     udp  --  10.0.3.0/24          10.0.3.0/24         state NEW multiport dports 5404,5405 
7    ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED 
8    ACCEPT     icmp --  0.0.0.0/0            0.0.0.0/0           
9    ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0           
10   ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           state NEW tcp dpt:22 
11   REJECT     all  --  0.0.0.0/0            0.0.0.0/0           reject-with icmp-host-prohibited 

Chain FORWARD (policy ACCEPT)
num  target     prot opt source               destination         
1    REJECT     all  --  0.0.0.0/0            0.0.0.0/0           reject-with icmp-host-prohibited 

Chain OUTPUT (policy ACCEPT)
num  target     prot opt source               destination  

Arrêtez votre machine virtuelle. Créez deux clones : node20 et node200. Démarrez la machine node1.

Configuration du node3

Arrêtez et supprimez le service NetworkManager puis activez le service network :

[root@centos6 ~]# service NetworkManager stop
Arrêt du démon NetworkManager :                            [  OK  ]
[root@centos6 ~]# chkconfig --del NetworkManager
[root@centos6 ~]# chkconfig --list network
network        	0:arrêt	1:arrêt	2:marche	3:marche	4:marche	5:marche	6:arrêt
[root@centos6 ~]# chkconfig --add network
[root@centos6 ~]# chkconfig --list network
network        	0:arrêt	1:arrêt	2:marche	3:marche	4:marche	5:marche	6:arrêt

Créez le fichier /etc/sysconfig/network-scripts/ifcfg-bond0 :

ifcfg-bond0
DEVICE=bond0
USERCTL=no
BOOTPROTO=none
ONBOOT=yes
IPADDR=10.0.3.17
NETMASK=255.255.255.0
NETWORK=10.0.3.0
BONDING_OPTS="miimon=100 mode=balance-xor"
TYPE=Unknown
IPV6INIT=no

Éditez le fichier /etc/sysconfig/network-scripts/ifcfg-eth0 :

ifcfg-eth0
DEVICE="eth0"
NM_CONTROLLED="no"
ONBOOT=yes
TYPE=Ethernet
BOOTPROTO=static
IPV6INIT=no
NETMASK=255.255.255.0
IPADDR=10.0.2.15
GATEWAY=10.0.2.2
USERCTL=yes

Éditez le fichier /etc/sysconfig/network-scripts/ifcfg-eth1 :

ifcfg-eth1
DEVICE=eth1
BOOTPROTO=none
ONBOOT=yes
MASTER=bond0
SLAVE=yes
USERCTL=no

Éditez le fichier /etc/sysconfig/network-scripts/ifcfg-eth2 :

ifcfg-eth2
DEVICE=eth2
BOOTPROTO=none
ONBOOT=yes
MASTER=bond0
SLAVE=yes
USERCTL=no

Créez le fichier /etc/modprobe.d/bonding.conf :

bonding.conf
alias bond0 bonding

Modifiez le fichier /etc/sysconfig/network :

network
NETWORKING=yes
HOSTNAME=node3.fenestros.loc

Modifiez le fichier /etc/resolv.conf :

resolv.conf
nameserver 8.8.8.8
nameserver 8.8.4.4

Modifiez le fichier /etc/hosts :

hosts
127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
::1         localhost localhost.localdomain localhost6 localhost6.localdomain6
10.0.3.15	node1.fenestros.loc 	node1
10.0.3.16	node2.fenestros.loc	node2
10.0.3.17	node3.fenestros.loc	node3

Saisissez les deux commandes suivantes :

[root@centos6 ~]# hostname node3.fenestros.loc
[root@centos6 ~]# service network start
Ouverture des Ports

Les ports indiqués dans le tableau suivant doivent être ouverts sur chaque noeud :

Port Application
5404/udp, 5405/udp corosync/cman
11111/tcp ricci
21064/tcp dlm
16851/tcp modclusterd

Utilisez les commandes suivantes pour ouvrir les ports pour cman dans iptables :

[root@centos6 ~]# iptables -I INPUT -m state --state NEW -m multiport -p udp -s 10.0.3.0/24 -d 10.0.3.0/24 --dports 5404,5405 -j ACCEPT
[root@centos6 ~]# iptables -I INPUT -m addrtype --dst-type MULTICAST -m state --state NEW -m multiport -p udp -s 10.0.3.0/24 --dports 5404,5405 -j ACCEPT

Utilisez la commande suivante pour ouvrir les ports pour ricci dans iptables :

[root@centos6 ~]# iptables -I INPUT -m state --state NEW -p tcp -s 10.0.3.0/24 -d 10.0.3.0/24 --dport 11111 -j ACCEPT

Utilisez la commande suivante pour ouvrir les ports pour dlm dans iptables :

[root@centos6 ~]# iptables -I INPUT -m state --state NEW -p tcp -s 10.0.3.0/24 -d 10.0.3.0/24 --dport 21064 -j ACCEPT 

Utilisez la commande suivante pour ouvrir les ports pour modclusterd dans iptables :

[root@centos6 ~]# iptables -I INPUT -m state --state NEW -p tcp -s 10.0.3.0/24 -d 10.0.3.0/24 --dport 16851 -j ACCEPT

Utilisez la commande suivante pour ouvrir les ports pour igmp ( Internet Group Management Protocol ) dans iptables :

[root@centos6 ~]# iptables -I INPUT -p igmp -j ACCEPT

Dernièrement, saisissez les commandes suivantes pour terminer la configuration d'iptables :

[root@centos6 ~]# service iptables save
iptables : Sauvegarde des règles du pare-feu dans /etc/sysc[  OK  ]tables : 
[root@centos6 ~]# service iptables restart
iptables : Suppression des règles du pare-feu :            [  OK  ]
iptables : Configuration des chaînes sur la politique ACCEP[  OK  ]er 
iptables : Déchargement des modules :                      [  OK  ]
iptables : Application des règles du pare-feu :            [  OK  ]

Vérifiez maintenant votre configuration d'iptables :

[root@centos6 ~]# service iptables status
Table : filter
Chain INPUT (policy ACCEPT)
num  target     prot opt source               destination         
1    ACCEPT     2    --  0.0.0.0/0            0.0.0.0/0           
2    ACCEPT     tcp  --  10.0.3.0/24          10.0.3.0/24         state NEW tcp dpt:16851 
3    ACCEPT     tcp  --  10.0.3.0/24          10.0.3.0/24         state NEW tcp dpt:21064 
4    ACCEPT     tcp  --  10.0.3.0/24          10.0.3.0/24         state NEW tcp dpt:11111 
5    ACCEPT     udp  --  10.0.3.0/24          0.0.0.0/0           ADDRTYPE match dst-type MULTICAST state NEW multiport dports 5404,5405 
6    ACCEPT     udp  --  10.0.3.0/24          10.0.3.0/24         state NEW multiport dports 5404,5405 
7    ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED 
8    ACCEPT     icmp --  0.0.0.0/0            0.0.0.0/0           
9    ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0           
10   ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           state NEW tcp dpt:22 
11   REJECT     all  --  0.0.0.0/0            0.0.0.0/0           reject-with icmp-host-prohibited 

Chain FORWARD (policy ACCEPT)
num  target     prot opt source               destination         
1    REJECT     all  --  0.0.0.0/0            0.0.0.0/0           reject-with icmp-host-prohibited 

Chain OUTPUT (policy ACCEPT)
num  target     prot opt source               destination         

       

Arrêtez votre machine virtuelle. Créez deux clones : node30 et node300. Démarrez la machine node1.

Tester les Serveurs

Lancez node1, node2 et node3. Vérifiez que chaque machine puisse se voir sur le réseau 10.0.3.0. Vérifiez que chaque machine a accès à Internet.

[root@node1 ~]# ping -c1 www.free.fr
PING www.free.fr (212.27.48.10) 56(84) bytes of data.
64 bytes from www.free.fr (212.27.48.10): icmp_seq=1 ttl=63 time=48.8 ms

--- www.free.fr ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 91ms
rtt min/avg/max/mdev = 48.852/48.852/48.852/0.000 ms
[root@node1 ~]# ping -c1 10.0.3.16
PING 10.0.3.16 (10.0.3.16) 56(84) bytes of data.
64 bytes from 10.0.3.16: icmp_seq=1 ttl=64 time=0.884 ms

--- 10.0.3.16 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 1ms
rtt min/avg/max/mdev = 0.884/0.884/0.884/0.000 ms
[root@node1 ~]# ping -c1 10.0.3.17
PING 10.0.3.17 (10.0.3.17) 56(84) bytes of data.
64 bytes from 10.0.3.17: icmp_seq=1 ttl=64 time=0.675 ms

--- 10.0.3.17 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.675/0.675/0.675/0.000 ms
[root@node2 ~]# ping -c1 www.free.fr
PING www.free.fr (212.27.48.10) 56(84) bytes of data.
64 bytes from www.free.fr (212.27.48.10): icmp_seq=1 ttl=63 time=36.6 ms

--- www.free.fr ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 78ms
rtt min/avg/max/mdev = 36.650/36.650/36.650/0.000 ms
[root@node2 ~]# ping -c1 10.0.3.15
PING 10.0.3.15 (10.0.3.15) 56(84) bytes of data.
64 bytes from 10.0.3.15: icmp_seq=1 ttl=64 time=0.359 ms

--- 10.0.3.15 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.359/0.359/0.359/0.000 ms
[root@node2 ~]# ping -c1 10.0.3.17
PING 10.0.3.17 (10.0.3.17) 56(84) bytes of data.
64 bytes from 10.0.3.17: icmp_seq=1 ttl=64 time=1.60 ms

--- 10.0.3.17 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 1ms
rtt min/avg/max/mdev = 1.605/1.605/1.605/0.000 ms
[root@node3 ~]# ping -c1 www.free.fr
PING www.free.fr (212.27.48.10) 56(84) bytes of data.
64 bytes from www.free.fr (212.27.48.10): icmp_seq=1 ttl=63 time=36.4 ms

--- www.free.fr ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 78ms
rtt min/avg/max/mdev = 36.436/36.436/36.436/0.000 ms
[root@node3 ~]# ping -c1 10.0.3.16
PING 10.0.3.16 (10.0.3.16) 56(84) bytes of data.
64 bytes from 10.0.3.16: icmp_seq=1 ttl=64 time=0.649 ms

--- 10.0.3.16 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.649/0.649/0.649/0.000 ms
[root@node3 ~]# ping -c1 10.0.3.15
PING 10.0.3.15 (10.0.3.15) 56(84) bytes of data.
64 bytes from 10.0.3.15: icmp_seq=1 ttl=64 time=0.587 ms

--- 10.0.3.15 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.587/0.587/0.587/0.000 ms

Démarrer le Service ricci si nécessaire

Dernièrement démarrez le service ricci sur chaque noeud :

[root@node1 ~]# service ricci status
ricci est arrêté
[root@node1 ~]# service ricci start
Démarrage de oddjobd :                                     [  OK  ]
generating SSL certificates...  done
Generating NSS database...  done
Démarrage de ricci :                                       [  OK  ]
[root@node2 ~]# service ricci status
ricci est arrêté
[root@node2 ~]# service ricci start
Démarrage de oddjobd :                                     [  OK  ]
generating SSL certificates...  done
Generating NSS database...  done
Démarrage de ricci :                                       [  OK  ]
[root@node3 ~]# service ricci status
ricci est arrêté
[root@node3 ~]# service ricci start
Démarrage de oddjobd :                                     [  OK  ]
generating SSL certificates...  done
Generating NSS database...  done
Démarrage de ricci :                                       [  OK  ]

Configurer un Cluster avec Conga

Introduction

La configuration en utilisant Conga ( l'interface graphique de luci ) consiste en :

  • L'installation et le démarrage de luci sur un noeud,
  • La création d'utilisateurs et des permissions,
  • La création d'un cluster,
  • La configuration des propriétés générales du cluster,
  • La configuration du daemon fenced,
  • La configuration de réseau,
  • La configuration des périphériques fence (Fence Devices),
  • La configuration des domaines de basculement (Failover Domains),
  • La création de ressources globales,
  • La création des services en cluster.

LAB #1 - L'Installation et le Démarrage de luci sur un Noeud

Installer luci sur node1.fenestros.loc

Téléchargez les paquets python-beaker-1.3.1-7.el6.noarch.rpm, python-weberror-0.10.2-2.el6.noarch.rpm et luci-0.26.0-93.el6.centos.x86_64.rpm :

[root@node1 ~]# wget http://ftp.riken.jp/Linux/centos/6/os/x86_64/Packages/python-beaker-1.3.1-7.el6.noarch.rpm
[root@node1 ~]# wget http://ftp.riken.jp/Linux/centos/6/os/x86_64/Packages/python-weberror-0.10.2-2.el6.noarch.rpm
[root@node1 ~]# wget http://ftp.riken.jp/Linux/centos/6/os/x86_64/Packages/luci-0.26.0-93.el6.centos.x86_64.rpm

Installez les paquets :

[root@node1 ~]# yum -y localinstall python-beaker-1.3.1-7.el6.noarch.rpm --nogpgcheck
[root@node1 ~]# yum -y localinstall python-weberror-0.10.2-2.el6.noarch.rpm --nogpgcheck
[root@node1 ~]# yum -y localinstall luci-0.26.0-93.el6.centos.x86_64.rpm --exclude=python-beaker --exclude=python-weberror --disablerepo=epel* --nogpgcheck

Démarrez le service luci :

[root@node1 ~]# service luci start
Adding following auto-detected host IDs (IP addresses/domain names), corresponding to `controller' address, to the configuration of self-managed certificate `/var/lib/luci/etc/cacert.config' (you can change them by editing `/var/lib/luci/etc/cacert.config', removing the generated certificate `/var/lib/luci/certs/host.pem' and restarting luci):
	(none suitable found, you can still do it manually as mentioned above)

Generating a 2048 bit RSA private key
writing new private key to '/var/lib/luci/certs/host.pem'
Démarrage de saslauthd :                                   [  OK  ]
Start luci...                                              [  OK  ]
Point your web browser to https://controller:8084 (or equivalent) to access luci

Si luci ne démarre pas, créez les fichiers /var/lib/luci/etc/luci.ini et /var/lib/luci/data/luci.db :

[root@node1 ~]# touch /var/lib/luci/etc/luci.ini
[root@node1 ~]# touch /var/lib/luci/data/luci.db

Modifiez ensuite le propriétaire et le groupe de chaque fichier :

[root@node1 ~]# chown luci:luci /var/lib/luci/etc/luci.ini
[root@node1 ~]# chown luci:luci /var/lib/luci/data/luci.db

Démarrez le service luci :

[root@node1 ~]# service luci start
Adding following auto-detected host IDs (IP addresses/domain names), corresponding to `controller' address, to the configuration of self-managed certificate `/var/lib/luci/etc/cacert.config' (you can change them by editing `/var/lib/luci/etc/cacert.config', removing the generated certificate `/var/lib/luci/certs/host.pem' and restarting luci):
	(none suitable found, you can still do it manually as mentioned above)

Generating a 2048 bit RSA private key
writing new private key to '/var/lib/luci/certs/host.pem'
Démarrage de saslauthd :                                   [  OK  ]
Start luci...                                              [  OK  ]
Point your web browser to https://controller:8084 (or equivalent) to access luci

La configuration de luci se trouve dans le fichier /etc/sysconfig/luci :

# User serviceable configuration of luci
#
# This configuration file uses a rather uncommon structure because it is
# intended to be parseable by both shell and Python's ConfigParser.  If you
# want to change any configuration item listed (i.e. to explicitly redefine
# luci's defaults for this item), uncomment particular line and set your
# value.  Each configurable item is preceeded with descriptive comment.
#
# Please be aware that changing anything else may render this file defective
# when unexpected content found here!
#
# Remember to restart the luci service for the changes to take effect.


# ===========================================================================
# INITSCRIPT CONFIGURATION
# Shell syntax (i.e. FOO=bar, BAZ="white-spaced string")
# ===========================================================================
[ INITSCRIPT ]

# Change this to set log file; this file either must not exist (so it is
# initially created in ownership of user running initscript, presumably root,
# and then luci becomes its owner) or must be writeable for luci
# directly
#LOG_FILE="path_to/log_file"

# Uncomment this to override default behaviour of removing run time data
# (files maintained by middleware handling cache and sessions) everytime
# the luci service is stopped (and also on service start)
#KEEP_RUNTIME_DATA=1


INIT_CONFIG=`cat -E <<"#END#"

#
# From this point, everything is in Python's ConfigParser syntax
# (i.e. no quoted strings and the syntax is generally more relaxed)
#

# ===========================================================================
# SERVER CONFIGURATION
# ===========================================================================
[server:main]

# Change this to set the host IP (and, in turn, respective network interface)
# running luci binds at;  this is particularly useful when it should be bound
# only at a specific one according to its IP address (0.0.0.0 => any interface)
#host = 127.0.0.1

# Change this to set the port running luci binds at;  please note that you
# cannot use privileged ports (i.e. <1024) because it runs as a non-root user
#port = 4443

# Change this to force luci to use custom SSL certificate (given the path of
# PEM file containing both the certificate itself and respective private key),
# otherwise its self-signed certificate managed automatically by luci
# service is used instead;
# currently, this certificate is used only for https connection with web
# browser, connections with ricci instances still rely on self-managed cert
# Note: If this configuration item is active and no such file can be read,
#       starting luci service will fail
#ssl_pem = "path_to/ssl_cert_pem_file"

use=config:%(base_config)s

# ===========================================================================
# APPLICATION CONFIGURATION
# ===========================================================================
[app:main]

# Change this to override default number of seconds of inactivity after which
# the luci authenticated session will timeout
# (requires repoze.who >= 1.0.14)
#who.auth_tkt_timeout = 600

use=config:%(base_config)s

#END#`

Dernièrement configurez luci pour un démarrage automatique :

[root@node1 ~]# chkconfig --list luci
luci           	0:arrêt	1:arrêt	2:arrêt	3:arrêt	4:arrêt	5:arrêt	6:arrêt
[root@node1 ~]# chkconfig --levels 2345 luci on
[root@node1 ~]# chkconfig --list luci
luci           	0:arrêt	1:arrêt	2:marche	3:marche	4:marche	5:marche	6:arrêt

Lancez une nouvelle fenêtre de votre navigateur et saisissez l'adresse http://localhost:8084. Vous obtiendrez une fenêtre similaire à celle-ci :

LAB #2 - La Création d'Utilisateurs et des Permissions

Connectez-vous à Conga en utilisant le compte root de la machine :

Vous obtiendrez une fenêtre d'avertissement qui indique que cet outil ne doit être utilisé que par des personnes ayant les connaissances appropriées :

Cliquez sur le bouton OK de la fenêtre d'avertissement. Vous apercevrez la fenêtre principale de l'outil Conga :

Important - Notez qu'en cas d'inactivité de plus de 15 minutes, la session est fermée.

Cliquez sur le lien Admin dans le coins supérieur à droite. Vous obtiendrez l'interface pour gérer les utilisateurs et les permissions :

Cliquez sur le bouton Add a user. Vous obtiendrez la fenêtre de création d'un utilisateur :

Saisissez le nom trainee et cliquez sur le bouton Submit :

Vous apercevrez que l'utilisateur trainee a bien été créé :

Dans la partie inférieure de la fenêtre, vous aurez la possibilité d’attribuer des permissions à l'utilisateur trainee :

Dans la liste des permissions vous verrez :

  • Luci Administrator,
    • Ce type d'utilisateur possède les pleins pouvoirs sur tous les clusters ainsi que les droits de modification des permissions de tout utilisateur à l'exception de root,
  • Can Create Clusters,
    • Ce type d'utilisateur peut créer des clusters,
  • Can Import Existing Clusters,
    • Ce type d'utilisateur peut ajouter un cluster existant à luci.

Cochez l'option Luci Administrator et cliquez sur le bouton Submit :

Vous obtiendrez la fenêtre suivante :

Notez qu'il n'est pas possible de modifier le mot de passe d'un utilisateur à partir de l'interface luci. Pour cette raison il est possible de créer un utilisateur, par exemple toto, sans pour autant que cet utilisateur puisse se connecter à luci. Pour comprendre pourquoi, sachez que luci se base sur PAM pour autoriser des connexions. Le fichier de configuration est /etc/pam.d/luci :

/etc/pam.d/luci
#%PAM-1.0
auth       include  password-auth
account    include  password-auth
password   include  password-auth
session    include  password-auth

Notez que ce fichier ne contient que des include vers le fichier /etc/pam.d/password-auth :

/etc/pam.d/password-auth
#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
auth        required      pam_env.so
auth        sufficient    pam_unix.so nullok try_first_pass
auth        requisite     pam_succeed_if.so uid >= 500 quiet
auth        required      pam_deny.so
 
account     required      pam_unix.so
account     sufficient    pam_localuser.so
account     sufficient    pam_succeed_if.so uid < 500 quiet
account     required      pam_permit.so
 
password    requisite     pam_cracklib.so try_first_pass retry=3 type=
password    sufficient    pam_unix.so sha512 shadow nullok try_first_pass use_authtok
password    required      pam_deny.so
 
session     optional      pam_keyinit.so revoke
session     required      pam_limits.so
session     [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
session     required      pam_unix.so

Ce système indique donc que les utilisateurs de luci doivent être des utilisateurs système. La modification du mot de passe se fait donc avec les utilitaires système habituels.

Important - Les utilisateurs luci sont les utilisateurs système à qui vous confiez les autorisations spécifiques à luci.

LAB #3 - La Création d'un Cluster

Cliquez sur le bouton Homebase à gauche. Vous obtiendrez la fenêtre suivante :

Cliquez sur le bouton Manage Clusters. Vous obtiendrez la fenêtre suivante :

Cliquez sur le lien Create. Vous obtiendrez la fenêtre suivante :

Remplissez le formulaire ainsi :

Important - Vous avez appelé votre cluster moncluster. Le nom d'un cluster est limité à 15 caractères. Puisque le mot de passe de l'utilisateur ricci est identique dans chaque noeud, vous avez coché Use the Same Password for All Nodes. Pour ajouter successivement chaque noeud, vous avez cliqué sur le bouton Add Another Node. Afin que chaque noeud contienne les paquets nécessaires, vous avez cochez Download Packages.

Cliquez maintenant sur le bouton Create Cluster. Vous obtiendrez la fenêtre suivante :

Important - Regardez le processus de création du cluster.

A l'issu de la création du cluster, vous obtiendrez la fenêtre suivante :

Important - A partir de cette interface vous pouvez ajouter ou supprimer un noeud du cluster grâce aux boutons Add et Delete. Veuillez noter que la suppression d'un noeud est une action destructive qui ne peut pas être reversée.

La Configuration des Propriétés Générales du Cluster

Cliquez sur le bouton Configure. Vous obtiendrez la fenêtre suivante :

Le premier onglet concerne les propriétés générales du cluster. Vous ne pouvez pas modifier le nom du cluster. La valeur du champs Configuration Version est incrémentée automatiquement après chaque modification du cluster. Vous pouvez cependant modifier manuellement la valeur.

La Configuration du Daemon Fenced

Cliquez maintenant sur l'onglet Fence Daemon. Vous obtiendrez la fenêtre suivante :

La configuration par défaut du daemon fenced est définie ici. Des configurations spécifiques par périphérique peuvent être spécifiées en cliquant sur le bouton Fence Devices. Sur l'onglet, on constate la présence de deux paramètres :

  • Post Fail Delay - Le nombre de secondes qu'attend le daemon fenced avant de réagir quand un noeud dans un Domaine Fence devient défaillant. La valeur par défaut est 0,
  • Post Join Delay - Le nombre de secondes qu'attend le daemon fenced avant de réagir quand un noeud rejoint un Domaine Fence. La valeur par défaut est 6. La valeur conseillée est entre 20 et 30.

La Configuration du Réseau

Cliquez maintenant sur l'onglet Network. Vous obtiendrez la fenêtre suivante :

Important - Les noeuds dans un cluster communiquent entre eux en utilisant des adresses multicast (multidiffusion). De ce fait, tous les périphériques doivent être configurés pour permettre l'utilisation des adresses multicast et être compatibles avec le protocole IGMP (Internet Group Management Protocol). Depuis la version 6.2 de RHEL, la communication entre les noeuds peut se faire en utilisant de l'UDP Unicast. Par contre il est déconseillé d'utiliser l'UDP Unicast avec du GFS2.

Le paramètre Network Transport Type prend une de trois valeurs :

  • UDP Multicast and Let Cluster Choose the Multicast Address,
    • IPv4 - l'adresse commence par 239.192.. Les 16 derniers bits sont générés par le logiciel Red Hat High Availability en fonction de l'ID du cluster,
    • IPv6 - l'adresse commence par FF15::. Les 16 derniers bits sont générés par le logiciel Red Hat High Availability en fonction de l'ID du cluster,
  • UDP Multicast and Specify the Multicast Address Manually,
    • Permet de spécifier une adresse multicast spécifique,
  • UDP Unicast (UDPU),
    • Permet de spécifier une adresse UDP unicast spécifique.

L'ID du cluster peut être visualisé en utilisant la commande cman_tool avec l'option status :

[root@node1 ~]# cman_tool status
Version: 6.2.0
Config Version: 1
Cluster Name: moncluster
Cluster Id: 59006
Cluster Member: Yes
Cluster Generation: 12
Membership state: Cluster-Member
Nodes: 3
Expected votes: 3
Total votes: 3
Node votes: 1
Quorum: 2  
Active subsystems: 9
Flags: 
Ports Bound: 0 11 177  
Node name: node1.fenestros.loc
Node ID: 1
Multicast addresses: 239.192.230.101 
Node addresses: 10.0.3.15

Important - Sauf cas exceptionnel, il est recommandé d'utiliser la valeur par défaut UDP Multicast and Let Cluster Choose the Multicast Address.

LAB #4 - La Configuration des Périphériques Fence

Cliquez maintenant sur le bouton Fence Devices. Vous obtiendrez la fenêtre suivante :

Cliquez sur le bouton Add. Vous obtiendrez la fenêtre suivante :

Dans la liste déroulante –Select a Fence Device– de la boîte de dialogue Add Fence Device (Instance), choisissez APC Power Switch. Vous obtiendrez la fenêtre suivante :

Remplissez le formulaire en indiquant un nom, une adresse IP et les coordonnées de connexion :

Important - La documentation sur la configuration de chaque Périphérique Fence peut être consultée à cette adresse.

Configurez deux autres Périphériques Fence APC Power Switch ayant respectivement les adresses IP 10.0.3.51 et 10.0.3.52. Vous obtiendrez la fenêtre suivante :

Pour supprimer le Périphérique Fence APC3, cochez la case à gauche du nom et cliquez sur le bouton Delete :

Important - Notez que vous ne pouvez pas supprimer un Périphérique Fence si celui-ci est utilisé par un noeud.

Vous obtiendrez la fenêtre suivante :

Cliquez sur le bouton Configure puis sur l'onglet General. Vous noterez que le numéro de la Configuration Version a été incrémenté :

Configurer un Périphérique Fence pour un Noeud

Cliquez sur le bouton Nodes. Vous obtiendrez la fenêtre suivante :

Cliquez ensuite sur le lien node2.fenestros.loc dans la colonne Node Name. Vous obtiendrez la fenêtre suivante :

Descendez en bas de la fenêtre et cliquez sur le bouton Add Fence Method :

Vous verrez la boîte de dialogue Add Fence Method to Node :

Dans le champs Method Name, saisissez APC1 et cliquez sur le bouton Submit :

Retournez à la section Fence Devices du node2.fenestros.loc et cliquez sur le bouton Add Fence Instance :

Dans la liste déroulante –Select a Fence Device– de la boîte de dialogue Add Fence Device (Instance), choisissez APC1 (APC Power Device) :

Vous obtiendrez la fenêtre suivante :

Saisissez le numéro du port et cliquez sur le bouton Submit :

Vous obtiendrez la fenêtre suivante :

A l'aide de toute source, expliquez pourquoi la valeur du port est 1.

Configurer un Périphérique Fence de Secours pour un Noeud

Afin de palier au danger d'une panne du premier Périphérique Fence, il est possible de configurer un Périphérique Fence de Secours. Descendez en bas de la fenêtre et cliquez de nouveau sur le bouton Add Fence Method. Saisissez un Method Name tel Secours et cliquez sur le bouton Submit :

Suivez la procédure expliquée ci-dessus pour ajouter le Périphérique Fence de Secours. A l'issu de la configuration vous obtiendrez la fenêtre suivante :

Consultez le fichier /etc/cluster/cluster.conf :

cluster.conf
<?xml version="1.0"?>
<cluster config_version="15" name="moncluster">
	<clusternodes>
		<clusternode name="node1.fenestros.loc" nodeid="1"/>
		<clusternode name="node2.fenestros.loc" nodeid="2">
			<fence>
				<method name="APC1">
					<device name="APC1" port="1"/>
				</method>
				<method name="Secours">
					<device name="APC2" port="1"/>
				</method>
			</fence>
		</clusternode>
		<clusternode name="node3.fenestros.loc" nodeid="3"/>
	</clusternodes>
	<fencedevices>
		<fencedevice agent="fence_apc" ipaddr="10.0.3.50" login="root" name="APC1" passwd="password" power_wait="5"/>
		<fencedevice agent="fence_apc" ipaddr="10.0.3.51" login="root" name="APC2" passwd="password" power_wait="5"/>
	</fencedevices>
</cluster>

Important - Notez la présence de deux lignes dans la section <fence> de <clusternode name=“node2.fenestros.loc” nodeid=“2”> ainsi que les deux lignes dans la section <fencedevices>.

Configurer un Noeud avec une Alimentation Redondante

Dans le cas d'une alimentation redondante, il est important de comprendre que si les deux Périphériques Fence sont configurés dans deux Fence Method différents, le noeud ne sera pas Fenced. Si le premier Fence Method est utilisé et l’alimention coupée, la deuxième alimentation prendra le relais !

Dans ce cas précis il convient de mettre les deux Pérphériques Fence dans la même Fence Method en tant que deux instances distincts.

LAB #5 - La Configuration des Domaines de Basculement

Un Domaine de Basculement est un sous-ensemble de noeuds d'un cluster où les membres peuvent faire fonctionner un service à haute disponibilité en cas de défaillance du membre sur lequel le service a été originalement démarré. Un domaines de basculement possède plusieurs caractéristiques :

Caractéristique Description
Unrestricted Permet de désigner un sous-ensemble de membres préférés, mais qu'un service rattaché au domaine peut être démarré sur n'importe quel membre disponible.
Restricted Permet de désigner un sous-ensemble de membres obligatoires. Si aucun membre désigné n'est disponible, le service ne peut pas être démarré.
Unordered Un service peut être démarré sur n'importe quel membre du domaine disponible sans aucun ordre pré-défini.
Ordered Un service peut être démarré sur n'importe quel membre du domaine dans un ordre pré-défini par des priorités.
Failback Permet de basculer un service vers le membre sur lequel le service a été originalement démarré. Nécessite le caractéristique Ordered

Important - Par défaut un domaine de basculement possède les caractéristiques Unrestricted et Unordered.

Pour créer un domaine de basculement, cliquez sur le bouton Failover Domains puis sur le bouton Add :

Vous obtiendrez la fenêtre suivante :

Créez un domaine de basculement, appelé Failover1, contenant node1.fenestros.loc et node2.fenestros.loc, sans priorités, en cochant les cases respectives et en cliquant sur le bouton Create :

Vous obtiendrez la fenêtre suivante :

Pour modifier le domaine de basculement vous disposez de deux boutons, Update Properties et Update Settings. Cochez maintenant l'option No Failback et cliquez sur le bouton Update Properties :

Cliquez maintenant sur le bouton Failover Domains. A partir de cette interface vous pouvez ajouter un autre domaine de basculement ou supprimer un domaine existant. Cochez donc la case à gauche du nom Failover1 et cliquez sur le bouton Delete pour le supprimer :

Re-créez le domaine de basculement Failover1 en suivant le processus détaillé ci-dessus.

LAB #6 - La Création de Ressources Globales

Pour créer une ressource globale, cliquez sur le bouton Resources puis sur le bouton Add :

Dans la liste déroulante –Select a Resource Type– de la boîte de dialogue Add Resource to Cluster, choisissez IP Address :

Important - La documentation sur la configuration de chaque ressource peut être consultée à cette adresse.

Saisissez l'adresse IP 10.0.3.100 et 24 pour le nombre de bits dans le masque de sous-réseau puis cliquez sur le bouton Submit :

Vous obtiendrez la fenêtre suivante :

LAB #7 - La Création des Services en Cluster

Pour créer un service en cluster, cliquez sur le bouton Service Groups puis sur le bouton Add :

Vous verrez apparaître la fenêtre Add Service Group to Cluster :

Si cochée, l'option Run Exclusive met en place une politique qui empêche le service en cours de configuration de démarrer sur un noeud où d'autres services sont actifs.

Le menu déroulant Recovery Mode contient quatre choix :

Choix Description
Relocate En cas d'échec, le système essayer de démarrer le service sur un autre noeud.
Restart En cas d'échec, le système essayera de re-démarrer le service sur le même noeud avant de démarrer le service sur un autre noeud.
Restart-Disable En cas d'échec, le service est redémarré mais en cas d'échec du redémarrage le service est désactivé au lieu d'être transférer vers un autre noeud.
Disable En cas d'échec d'un composant d'un groupe de ressources, le système désactive le groupe de ressources.

Saisissez un Service Name, cochez Automatically Start This Service, choisissez le domaine de basculement Failover1 dans la liste déroulante Failover Domain et cliquez sur le bouton Add Resource :

Vous verrez apparaître la boîte de dialogue Add Resource to Service :

Dans la liste déroulante –Select a Resource Type– de la boîte de dialogue Add Resource to Service, choisissez 10.0.3.100/24 :

Vous obtiendrez la fenêtre suivante. Cliquez sur le bouton Submit :

Fournissez la définition des options Independant Subtree et Non-Critical Resource.

Vous noterez que le statut du service est inconnu (Unknown). Cochez la case à gauche du service et cliquez sur le bouton Start :

Vous obtiendrez une fenêtre similaire à celle-ci :

En fonction du noeud sur lequel le service a été démarré, il convient de vérifier sa mise en place :

[root@node1 ~]# /sbin/ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 08:00:27:9b:b3:ce brd ff:ff:ff:ff:ff:ff
    inet 10.0.2.15/24 brd 10.0.2.255 scope global eth0
    inet6 fe80::a00:27ff:fe9b:b3ce/64 scope link 
       valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master bond0 state UP qlen 1000
    link/ether 08:00:27:5d:b9:44 brd ff:ff:ff:ff:ff:ff
4: eth2: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master bond0 state UP qlen 1000
    link/ether 08:00:27:5d:b9:44 brd ff:ff:ff:ff:ff:ff
5: bond0: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP 
    link/ether 08:00:27:5d:b9:44 brd ff:ff:ff:ff:ff:ff
    inet 10.0.3.15/24 brd 10.0.3.255 scope global bond0
    inet 10.0.3.100/24 scope global secondary bond0
    inet6 fe80::a00:27ff:fe5d:b944/64 scope link tentative dadfailed 
       valid_lft forever preferred_lft forever

Important - Notez la présence de la ligne inet 10.0.3.100/24 scope global secondary bond0

Testez maintenant à partir des deux autres noeuds :

[root@node2 ~]# ping -c3 10.0.3.100
PING 10.0.3.100 (10.0.3.100) 56(84) bytes of data.
64 bytes from 10.0.3.100: icmp_seq=1 ttl=64 time=0.645 ms
64 bytes from 10.0.3.100: icmp_seq=2 ttl=64 time=0.569 ms
64 bytes from 10.0.3.100: icmp_seq=3 ttl=64 time=0.634 ms

--- 10.0.3.100 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2001ms
rtt min/avg/max/mdev = 0.569/0.616/0.645/0.033 ms
[root@node3 ~]# ping -c3 10.0.3.100
PING 10.0.3.100 (10.0.3.100) 56(84) bytes of data.
64 bytes from 10.0.3.100: icmp_seq=1 ttl=64 time=1.84 ms
64 bytes from 10.0.3.100: icmp_seq=2 ttl=64 time=0.480 ms
64 bytes from 10.0.3.100: icmp_seq=3 ttl=64 time=0.559 ms

--- 10.0.3.100 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 0.480/0.962/1.847/0.626 ms

LAB #8 - Redémarrer un Noeud

Cliquez sur le bouton Nodes et cochez la case à gauche de node1.fenestros.loc. Cliquez ensuite sur le bouton Reboot :

Lors du redémarrage du noeud, vérifiez que vous pouvez accéder à l'interface High Availability Management. Sinon, vérifiez que tous les services nécessaires fonctionnent.

Gérer un Cluster avec Conga

LAB #9 - Sauvegarder et Restaurer la Configuration de luci

Sauvegarder la Configuration de luci

La configuration de luci est stocké dans une base de données qui se trouve dans le répertoire /var/lib/luci/data :

[root@node1 ~]# ls /var/lib/luci/data
luci.db

Il est à noter que :

  • cette base de données ne contient pas la configuration du cluster qui est stocké dans /etc/cluster/cluster.conf,
  • pour restaurer la base de données sur un autre noeud, il faut aussi sauvegarder et restaurer le certificat SSL, /var/lib/luci/certs/host.pem et le fichier /var/lib/luci/etc/luci.ini.

Pour sauvegarder la base de données de luci, arrêtez le service :

[root@node1 ~]# service luci stop
Stop luci...                                               [  OK  ]

Exécutez ensuite la commande service luci backup-db :

[root@node1 ~]# service luci backup-db

Par défaut les sauvegardes sont stockées dans le même répertoire que la base de données de luci :

[root@node1 ~]# ls /var/lib/luci/data
luci-backup20131012103330.db  luci.db

En utilisant la commande service luci list-backups, vous pouvez visualiser les sauvegardes dans /var/lib/luci/data :

[root@node1 ~]# service luci list-backups
/var/lib/luci/data/luci-backup20131012103330.db

IL est aussi possible de sauvegarder la base de données de luci ailleurs :

[root@node1 ~]# service luci backup-db /root/luci.db.backup
[root@node1 ~]# ls /root | grep luci
luci.db.backup

Par contre cette sauvegarde n'est pas visible à la commande service luci list-backups :

[root@node1 ~]# service luci list-backups
/var/lib/luci/data/luci-backup20131012103330.db

Ayant sauvegardé la base de données luci, démarrez le service :

[root@node1 ~]# service luci start
Start luci...                                              [  OK  ]
Point your web browser to https://node1.fenestros.loc:8084  (or equivalent) to access luci

Restaurer la Configuration de luci sur node2.fenestros.loc

Installez luci sur node2.fenestros.loc. Téléchargez les paquets python-beaker-1.3.1-7.el6.noarch.rpm, python-weberror-0.10.2-2.el6.noarch.rpm et luci-0.26.0-93.el6.centos.x86_64.rpm :

[root@node2 ~]# wget http://ftp.riken.jp/Linux/centos/6/os/x86_64/Packages/python-beaker-1.3.1-7.el6.noarch.rpm
[root@node2 ~]# wget http://ftp.riken.jp/Linux/centos/6/os/x86_64/Packages/python-weberror-0.10.2-2.el6.noarch.rpm
[root@node2 ~]# wget http://ftp.riken.jp/Linux/centos/6/os/x86_64/Packages/luci-0.26.0-93.el6.centos.x86_64.rpm

Installez les paquets :

[root@node2 ~]# yum -y localinstall python-beaker-1.3.1-7.el6.noarch.rpm --nogpgcheck
[root@node2 ~]# yum -y localinstall python-weberror-0.10.2-2.el6.noarch.rpm --nogpgcheck
[root@node2 ~]# yum -y localinstall luci-0.26.0-93.el6.centos.x86_64.rpm --exclude=python-beaker --exclude=python-weberror --disablerepo=epel* --nogpgcheck

Démarrez le service luci :

[root@node2 ~]# service luci start
Adding following auto-detected host IDs (IP addresses/domain names), corresponding to `controller' address, to the configuration of self-managed certificate `/var/lib/luci/etc/cacert.config' (you can change them by editing `/var/lib/luci/etc/cacert.config', removing the generated certificate `/var/lib/luci/certs/host.pem' and restarting luci):
	(none suitable found, you can still do it manually as mentioned above)

Generating a 2048 bit RSA private key
writing new private key to '/var/lib/luci/certs/host.pem'
Démarrage de saslauthd :                                   [  OK  ]
Start luci...                                              [  OK  ]
Point your web browser to https://controller:8084 (or equivalent) to access luci

Si luci ne démarre pas, créez les fichiers /var/lib/luci/etc/luci.ini et /var/lib/luci/data/luci.db :

[root@node2 ~]# touch /var/lib/luci/etc/luci.ini
[root@node2 ~]# touch /var/lib/luci/data/luci.db

Modifiez ensuite le propriétaire et le groupe de chaque fichier :

[root@node2 ~]# chown luci:luci /var/lib/luci/etc/luci.ini
[root@node2 ~]# chown luci:luci /var/lib/luci/data/luci.db

Démarrez le service luci :

[root@node2 ~]# service luci start
Adding following auto-detected host IDs (IP addresses/domain names), corresponding to `controller' address, to the configuration of self-managed certificate `/var/lib/luci/etc/cacert.config' (you can change them by editing `/var/lib/luci/etc/cacert.config', removing the generated certificate `/var/lib/luci/certs/host.pem' and restarting luci):
	(none suitable found, you can still do it manually as mentioned above)

Generating a 2048 bit RSA private key
writing new private key to '/var/lib/luci/certs/host.pem'
Démarrage de saslauthd :                                   [  OK  ]
Start luci...                                              [  OK  ]
Point your web browser to https://controller:8084 (or equivalent) to access luci

A partir de node1.fenestros.loc, transférez le certificat SSL, le fichier /var/lib/luci/etc/luci.ini ainsi que la sauvegarde vers node2.fenestros.loc :

[root@node1 ~]# scp /var/lib/luci/certs/host.pem /var/lib/luci/etc/luci.ini $(service luci list-backups) root@node2:
The authenticity of host 'node2 (10.0.3.16)' can't be established.
RSA key fingerprint is 63:cf:95:55:ac:8e:d1:f8:aa:c4:44:46:da:aa:b7:2f.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'node2,10.0.3.16' (RSA) to the list of known hosts.
root@node2's password: 
host.pem                                                                                                                              100% 2868     2.8KB/s   00:00    
luci.ini                                                                                                                              100% 8554     8.4KB/s   00:00    
luci-backup20131012103330.db                                                                                                          100% 4854     4.7KB/s   00:00

Restaurer le certificat et la sauvegarde :

[root@node2 ~]# ls
anaconda-ks.cfg  Desktop  host.pem  install.log  install.log.syslog  luci-backup20131012103330.db
[root@node2 ~]# cp host.pem /var/lib/luci/certs/
[root@node2 ~]# chown luci: /var/lib/luci/certs/host.pem 
[root@node2 ~]# cp luci.ini /var/lib/luci/etc/
[root@node2 ~]# chown luci:luci /var/lib/luci/etc/luci.ini
[root@node2 ~]# service luci restore-db ~/luci-backup20131012103330.db 
[root@node2 ~]# service luci start
Start luci...                                              [  OK  ]
Point your web browser to https://node2.fenestros.loc:8084 (or equivalent) to access luci

Lancez une nouvelle fenêtre de votre navigateur et saisissez l'adresse http://localhost:8084. Vous obtiendrez une fenêtre similaire à celle-ci :

Fermez le navigateur et arrêtez le service luci :

[root@node2 ~]# service luci stop
Stop luci...                                               [  OK  ]

Gérer les Services de Haute Disponibilité

Retournez à l'interface luci sur node1.fenestros.loc. Cliquez sur le bouton Service Groups :

Important - Notez que le service AdresseIP a été basculé vers node2.fenestros.loc.

En cochant la case à gauche du service, vous pouvez utiliser cette interface pour Démarrer (Start), Redémarrer (Restart), Désactiver (Disable) ou Supprimer (Delete) le service :

En cliquant sur le nom du service, vous accédez à une interface qui vous permet de basculer manuellement le service vers un autre noeud et/ou de Démarrer (Start), Redémarrer (Restart), Désactiver (Disable) ou Supprimer (Delete) le service grâce aux boutons d'action dans le coins supérieur droite :

LAB #10 - Gérer les Noeuds d'un Cluster

Causer un Noeud de Quitter ou de Joindre un Cluster

Cliquez sur le bouton Nodes :

Cochez la case à côté de node2.fenestros.loc et cliquez sur le bouton Leave Cluster :

Important - Si vous sélectionnez tous les noeuds d'un cluster et vous cliquez sur Leave Cluster, le cluster s'arrête.

Dans la boîte de dialogue Confirm Action, cliquez sur le bouton Proceed :

Vous obtiendrez la fenêtre suivante :

Cliquez sur le bouton Nodes pour rafraîchir la page :

Important - Notez que node2.fenestros.loc est en rouge et que le statut est devenu Not a cluster member.

Pour joindre le noeud au cluster, sélectionnez-le et cliquez sur le bouton Join Cluster :

Important - Si vous sélectionnez tous les noeuds d'un cluster arrêté et vous cliquez sur Join Cluster, le cluster redémarre.

Vous obtiendrez la fenêtre suivante :

Important - Notez la présence du message en haut à droite de la fenêtre.

Cliquez sur le bouton Nodes pour rafraîchir la page :

Cliquez maintenant sur le bouton Service Groups :

Important - Notez que le service a été basculé vers node1.fenestros.loc du fait du départ de node2.fenestros.loc du cluster.

Basculez manuellement le service AdresseIP vers node2.fenestros.loc

Supprimer un Membre d'un Cluster

Pour supprimer un membre d'un cluster, il faut d'abord l'arrêter. Cliquez sur la case à côté de node3.fenestros.loc puis cliquez sur Leave Cluster :

Dans la boîte de dialogue Confirm Action, cliquez sur le bouton Proceed :

Cliquez sur le bouton Nodes pour rafraîchir la page :

Important - Notez que node2.fenestros.loc est en rouge et que le statut est devenu Not a cluster member.

Cliquez sur la case à côté de node3.fenestros.loc puis cliquez sur Delete :

Dans la boîte de dialogue Confirm Action, cliquez sur le bouton Proceed :

La fenêtre se rafraîchit automatiquement :

Important - Pour supprimer un cluster, il convient de supprimer tous les noeuds faisant partie du cluster.

Ajouter un Membre à un Cluster en Cours d’Exécution

Pour rajouter node3.fenestros.loc au cluster en cours d'exécution, cliquez sur le bouton Add. Vous obtiendrez la fenêtre suivante :

Remplissez le formulaire ainsi et cliquez sur le bouton Add Nodes :

Observez le rajout du noeud :

Important - Notez que les noeuds du cluster sont arrêtés pendant le processus.

A l'issu du processus, vous obtiendrez la fenêtre suivante :

Ajouter un Cluster Existant à luci

Pour ajouter un cluster existant à l'interface de luci, cliquez sur le bouton Manage Clusters puis sur le bouton Add :

Dans la fenêtre Add Existing Cluster, il suffit de saisir le nom d'un noeud faisant partie du cluster :

Configurer et Gérer un Cluster avec La Commande ccs

Introduction

La configuration en utilisant la commande ccs consiste en :

  • La préparation de tous les nœuds,
  • La création d'un cluster,
  • La configuration du daemon fenced,
  • La configuration des périphériques fence (Fence Devices),
  • La configuration des domaines de basculement (Failover Domains),
  • La création de ressources globales,
  • La création des services en cluster,
  • La configuration du disque quorum,
  • La configuration des propriétés générales du cluster,
  • Propagation du fichier de configuration du cluster à tous les nœuds du cluster.

LAB #11 - Préparation de tous les nœuds

node1.fenestros.loc

Installer et Configurer ricci

Lancez la machine virtuelle node10. Celle-ci étant un clone de la machine node1, ricci est déjà installé.

Démarrez puis configurez ricci :

[root@node1 ~]# service ricci status
ricci est arrêté
[root@node1 ~]# service ricci start
Démarrage de oddjobd :                                     [  OK  ]
generating SSL certificates...  done
Generating NSS database...  done
Démarrage de ricci :                                       [  OK  ]
[root@node1 ~]# chkconfig --list ricci
ricci          	0:arrêt	1:arrêt	2:arrêt	3:arrêt	4:arrêt	5:arrêt	6:arrêt
[root@node1 ~]# chkconfig --level 345 ricci on
[root@node1 ~]# chkconfig --list ricci
ricci          	0:arrêt	1:arrêt	2:arrêt	3:marche	4:marche	5:marche6:arrêt

Créez maintenant un mot de passe pour l'utilisateur ricci :

[root@node1 ~]# passwd ricci
Changement de mot de passe pour l'utilisateur ricci.
Nouveau mot de passe : 
MOT DE PASSE INCORRECT : trop court
MOT DE PASSE INCORRECT : est trop simple
Retapez le nouveau mot de passe : 
passwd : mise à jour réussie de tous les jetons d'authentification.
Installer Cluster Configuration System

Installez le paquet ccs sur node1.fenestros.loc :

[root@node1 ~]# yum install ccs
Loaded plugins: fastestmirror, refresh-packagekit, security
Loading mirror speeds from cached hostfile
 * atomic: www2.atomicorp.com
 * base: holmes.umflint.edu
 * epel: fedora-epel.mirror.lstn.net
 * extras: mirror.cs.vt.edu
 * rpmforge: repoforge.spinellicreations.com
 * updates: centos.someimage.com
Setting up Install Process
Resolving Dependencies
--> Running transaction check
---> Package ccs.i686 0:0.16.2-69.el6_5.1 will be installed
--> Finished Dependency Resolution

Dependencies Resolved

================================================================================
 Package      Arch          Version                      Repository        Size
================================================================================
Installing:
 ccs          i686          0.16.2-69.el6_5.1            updates           49 k

Transaction Summary
================================================================================
Install       1 Package(s)

Total download size: 49 k
Installed size: 287 k
Is this ok [y/N]: y
Modifiez /etc/hosts

Créez une entrée pour chaque nœud dans le fichier /etc/hosts :

hosts
127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
::1         localhost localhost.localdomain localhost6 localhost6.localdomain6
10.0.3.15	node1.fenestros.loc
10.0.3.16	node2.fenestros.loc
10.0.3.17	node3.fenestros.loc

node2.fenestros.loc

Installer et Configurer ricci

Lancez la machine virtuelle node20. Celle-ci étant un clone de la machine node2, ricci est déjà installé.

Démarrez puis configurez ricci :

[root@node2 ~]# service ricci status
ricci est arrêté
[root@node2 ~]# service ricci start
Démarrage de oddjobd :                                     [  OK  ]
generating SSL certificates...  done
Generating NSS database...  done
Démarrage de ricci :                                       [  OK  ]
[root@node2 ~]# chkconfig --level 345 ricci on
[root@node2 ~]# chkconfig --list ricci
ricci          	0:arrêt	1:arrêt	2:arrêt	3:marche	4:marche	5:marche6:arrêt

Créez maintenant un mot de passe pour l'utilisateur ricci :

[root@node2 ~]# passwd ricci
Changement de mot de passe pour l'utilisateur ricci.
Nouveau mot de passe : 
MOT DE PASSE INCORRECT : trop court
MOT DE PASSE INCORRECT : est trop simple
Retapez le nouveau mot de passe : 
passwd : mise à jour réussie de tous les jetons d'authentification.
Modifiez /etc/hosts

Créez une entrée pour chaque nœud dans le fichier /etc/hosts :

hosts
127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
::1         localhost localhost.localdomain localhost6 localhost6.localdomain6
10.0.3.15	node1.fenestros.loc
10.0.3.16	node2.fenestros.loc
10.0.3.17	node3.fenestros.loc

node3.fenestros.loc

Installer et Configurer ricci

Lancez la machine virtuelle node30. Celle-ci étant un clone de la machine node3, ricci est déjà installé.

Démarrez puis configurez ricci :

[root@node3 ~]# service ricci status
ricci est arrêté
[root@node3 ~]# service ricci start
Démarrage de oddjobd :                                     [  OK  ]
generating SSL certificates...  done
Generating NSS database...  done
Démarrage de ricci :                                       [  OK  ]
[root@node3 ~]# chkconfig --level 345 ricci on
[root@node3 ~]# chkconfig --list ricci
ricci          	0:arrêt	1:arrêt	2:arrêt	3:marche	4:marche	5:marche6:arrêt

Créez maintenant un mot de passe pour l'utilisateur ricci :

[root@node3 ~]# passwd ricci
Changement de mot de passe pour l'utilisateur ricci.
Nouveau mot de passe : 
MOT DE PASSE INCORRECT : trop court
MOT DE PASSE INCORRECT : est trop simple
Retapez le nouveau mot de passe : 
passwd : mise à jour réussie de tous les jetons d'authentification.
Modifiez /etc/hosts

Créez une entrée pour chaque nœud dans le fichier /etc/hosts :

hosts
127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
::1         localhost localhost.localdomain localhost6 localhost6.localdomain6
10.0.3.15	node1.fenestros.loc
10.0.3.16	node2.fenestros.loc
10.0.3.17	node3.fenestros.loc

LAB #12 - Création d'un Cluster

Sur node1.fenestros.loc saisissez la commande suivante pour créer un cluster dénommé moncluster :

[root@node1 ~]# ccs -h node1.fenestros.loc --createcluster moncluster
node1.fenestros.loc password: ricci

Important - Vous avez appelé votre cluster moncluster. Le nom d'un cluster est limité à 15 caractères. Le mot de passe ne sera pas visible en clair. Si le fiochier cluster.conf existe déjà, il sera écrasé.

Ajoutez maintenant chaque nœud, numéroté de 1 à 3, au cluster précedemment créé, chacun ayant une vote :

[root@node1 ~]# ccs -h node1.fenestros.loc --addnode node1.fenestros.loc --votes 1 --nodeid 1
Node node1.fenestros.loc added.
[root@node1 ~]# ccs -h node1.fenestros.loc --addnode node2.fenestros.loc --votes 1 --nodeid 2
Node node2.fenestros.loc added.
[root@node1 ~]# ccs -h node1.fenestros.loc --addnode node3.fenestros.loc --votes 1 --nodeid 3
Node node3.fenestros.loc added.

Le commandes ci-dessus crée le fichier /etc/cluster/cluster.conf sur node1.fenestros.loc :

cluster.conf
<?xml version="1.0"?>
<cluster config_version="4" name="moncluster">
	<fence_daemon/>
	<clusternodes>
		<clusternode name="node1.fenestros.loc" nodeid="1" votes="1"/>
		<clusternode name="node2.fenestros.loc" nodeid="2" votes="1"/>
		<clusternode name="node3.fenestros.loc" nodeid="3" votes="1"/>
	</clusternodes>
	<cman/>
	<fencedevices/>
	<rm>
		<failoverdomains/>
		<resources/>
	</rm>
</cluster>

Pour vérifier la configuration des nœuds dans le cluster, utilisez la commande suivante :

[root@node1 ~]# ccs -h node1.fenestros.loc --lsnodes
node1.fenestros.loc: votes=1, nodeid=1
node2.fenestros.loc: votes=1, nodeid=2
node3.fenestros.loc: votes=1, nodeid=3

Vous devez maintenant propagé le fichier cluster.conf aux autres nœuds :

[root@node1 ~]# ccs -f /etc/cluster/cluster.conf -h node2.fenestros.loc --setconf
node2.fenestros.loc password: ricci
[root@node1 ~]# ccs -f /etc/cluster/cluster.conf -h node3.fenestros.loc --setconf
node3.fenestros.loc password: ricci

Important - Le mot de passe ne sera pas visible en clair.

Pour vérifier si tous les nœuds sont synchroniser, utilisez la commande suivante :

[root@node1 ~]# ccs -f /etc/cluster/cluster.conf --checkconf
All nodes in sync.

Vous pouvez aussi synchroniser et activer le fichier cluster.conf en utilisant les commandes suivantes :

[root@node1 ~]# ccs -h node1.fenestros.loc --sync --activate
[root@node1 ~]# ccs -h node2.fenestros.loc --sync --activate
[root@node1 ~]# ccs -h node3.fenestros.loc --sync --activate

Dans ce cas, utilisez la comande suivante pour vérifier la configuration :

[root@node1 ~]# ccs -h node2.fenestros.loc --checkconf
All nodes in sync.

Configurez les Services Cluster

Démarrez les cluster sur chaque machine virtuelle :

[root@node1 ~]# chkconfig --level 345 cman on
[root@node1 ~]# chkconfig --level 345 rgmanager on
[root@node1 ~]# reboot
[root@node2 ~]# chkconfig --level 345 cman on
[root@node1 ~]# chkconfig --level 345 rgmanager on
[root@node2 ~]# reboot
[root@node3 ~]# chkconfig --level 345 cman on
[root@node1 ~]# chkconfig --level 345 rgmanager on
[root@node3 ~]# reboot

Qaund les machines virtuelles ont redémarrés, vérifiez l'existance du cluster :

[root@node1 ~]# cman_tool nodes
Node  Sts   Inc   Joined               Name
   1   M     12   2013-12-14 21:35:54  node1.fenestros.loc
   2   M     16   2013-12-14 21:36:34  node2.fenestros.loc
   3   M     20   2013-12-14 21:36:51  node3.fenestros.loc
   

LAB #13 - Configuration du Daemon Fenced

Pour configurer le daemon Fenced, il convient d'utiliser la commande suivante :

[root@node1 ~]# ccs -h node1.fenestros.loc --setfencedaemon post_fail_delay=5 post_join_delay=25

Rappelez-vous que les deux paramètres du daemon sont :

  • Post Fail Delay - Le nombre de secondes qu'attend le daemon fenced avant de réagir quand un nœud dans un Domaine Fence devient défaillant. La valeur par défaut est 0,
  • Post Join Delay - Le nombre de secondes qu'attend le daemon fenced avant de réagir quand un nœud rejoint un Domaine Fence. La valeur par défaut est 6. La valeur conseillée est entre 20 et 30.

LAB #14 - Configuration des Périphériques Fence

Pour ajouter le périphérique fence APC1, utilisez la commande suivante :

[root@node1 ~]# ccs -h node1.fenestros.loc --addfencedev APC1 agent=fence_apc ipaddr=10.0.3.50 login=root passwd=password

Configurez deux autres Périphériques Fence APC Power Switch ayant respectivement les adresses IP 10.0.3.51 et 10.0.3.52 :

[root@node1 ~]# ccs -h node1.fenestros.loc --addfencedev APC2 agent=fence_apc ipaddr=10.0.3.51 login=root passwd=password
[root@node1 ~]# ccs -h node1.fenestros.loc --addfencedev APC3 agent=fence_apc ipaddr=10.0.3.52 login=root passwd=password

Pour supprimer le Périphérique Fence APC3, utilisez la commande suivante :

[root@node1 ~]# ccs -h node1.fenestros.loc --rmfencedev APC3

Contrôlez ensuite votre fichier /etc/cluster/cluster.conf :

[root@node1 ~]# cat /etc/cluster/cluster.conf 
<?xml version="1.0"?>
<cluster config_version="12" name="moncluster">
	<fence_daemon post_fail_delay="5" post_join_delay="25"/>
	<clusternodes>
		<clusternode name="node1.fenestros.loc" nodeid="1" votes="1"/>
		<clusternode name="node2.fenestros.loc" nodeid="2" votes="1"/>
		<clusternode name="node3.fenestros.loc" nodeid="3" votes="1"/>
	</clusternodes>
	<cman/>
	<fencedevices>
		<fencedevice agent="fence_apc" ipaddr="10.0.3.50" login="root" name="APC1" passwd="password"/>
		<fencedevice agent="fence_apc" ipaddr="10.0.3.51" login="root" name="APC2" passwd="password"/>
	</fencedevices>
	<rm>
		<failoverdomains/>
		<resources/>
	</rm>
</cluster>

Important - Notez que ce fichier ne fait pas référence à l'APC3.

Une autre façon de voir le périphériques fence configurés pour le cluster est d'utiliser la command ccs :

[root@node1 ~]# ccs -h node1.fenestros.loc --lsfencedev
APC1: passwd=password, login=root, ipaddr=10.0.3.50, agent=fence_apc
APC2: passwd=password, login=root, ipaddr=10.0.3.51, agent=fence_apc

Pour voir la liste des agents fence disponibles pour le cluster, utilisez la commande suivante :

[root@node1 ~]# ccs -h node1.fenestros.loc --lsfenceopts
fence_apc - Fence agent for APC over telnet/ssh
fence_apc_snmp - Fence agent for APC over SNMP
fence_bladecenter - Fence agent for IBM BladeCenter
fence_bladecenter_snmp - Fence agent for IBM BladeCenter over SNMP
fence_brocade - Fence agent for Brocade over telnet
fence_cisco_mds - Fence agent for Cisco MDS
fence_cisco_ucs - Fence agent for Cisco UCS
fence_drac - fencing agent for Dell Remote Access Card
fence_drac5 - Fence agent for Dell DRAC CMC/5
fence_eaton_snmp - Fence agent for Eaton over SNMP
fence_egenera - I/O Fencing agent for the Egenera BladeFrame
fence_eps - Fence agent for ePowerSwitch
fence_hpblade - Fence agent for HP BladeSystem
fence_ibmblade - Fence agent for IBM BladeCenter over SNMP
fence_idrac - Fence agent for IPMI over LAN
fence_ifmib - Fence agent for IF MIB
fence_ilo - Fence agent for HP iLO
fence_ilo2 - Fence agent for HP iLO
fence_ilo3 - Fence agent for IPMI over LAN
fence_ilo4 - Fence agent for IPMI over LAN
fence_ilo_mp - Fence agent for HP iLO MP
fence_imm - Fence agent for IPMI over LAN
fence_intelmodular - Fence agent for Intel Modular
fence_ipdu - Fence agent for iPDU over SNMP
fence_ipmilan - Fence agent for IPMI over LAN
fence_kdump - Fence agent for use with kdump
fence_pcmk - Helper that presents a RHCS-style interface to stonith-ng for CMAN based clusters
fence_rhevm - Fence agent for RHEV-M REST API
fence_rsa - Fence agent for IBM RSA
fence_rsb - I/O Fencing agent for Fujitsu-Siemens RSB
fence_sanbox2 - Fence agent for QLogic SANBox2 FC switches
fence_sanlock - Fence agent for watchdog and shared storage
fence_scsi - fence agent for SCSI-3 persistent reservations
fence_virsh - Fence agent for virsh
fence_virt - Fence agent for virtual machines
fence_vmware - Fence agent for VMWare
fence_vmware_soap - Fence agent for VMWare over SOAP API
fence_wti - Fence agent for WTI
fence_xvm - Fence agent for virtual machines

Pour voir les options fence pour un agent fence donné, utilisez la commande suivante :

[root@node1 ~]# ccs -h node1.fenestros.loc --lsfenceopts fence_apc
fence_apc - Fence agent for APC over telnet/ssh
  Required Options:
  Optional Options:
    option: No description available
    action: Fencing Action
    ipaddr: IP Address or Hostname
    login: Login Name
    passwd: Login password or passphrase
    passwd_script: Script to retrieve password
    secure: SSH connection
    port: Physical plug number or name of virtual machine
    identity_file: Identity file for ssh
    switch: Physical switch number on device
    inet4_only: Forces agent to use IPv4 addresses only
    inet6_only: Forces agent to use IPv6 addresses only
    ipport: TCP port to use for connection with device
    cmd_prompt: Force command prompt
    verbose: Verbose mode
    debug: Write debug information to given file
    version: Display version information and exit
    help: Display help and exit
    separator: Separator for CSV created by operation list
    power_timeout: Test X seconds for status change after ON/OFF
    shell_timeout: Wait X seconds for cmd prompt after issuing command
    login_timeout: Wait X seconds for cmd prompt after login
    power_wait: Wait X seconds after issuing ON/OFF
    delay: Wait X seconds before fencing is started
    retry_on: Count of attempts to retry power on

Important - La documentation sur la configuration de chaque Périphérique Fence peut être consultée à cette adresse.

Pour configurer une Méthode Fence appelé APC1 à node2.fenetros.loc, la commande est la suivante :

[root@node1 ~]# ccs -h node1.fenestros.loc --addmethod APC1 node2.fenestros.loc
Method APC1 added to node2.fenestros.loc.

Pour ajouter une Instance Fence à la Méthode fence, utilisez la commande suivante :

ccs -h node1.fenestros.loc --addfenceinst APC1 node2.fenestros.loc APC1 port=2

Synchronisez maintenant les nœuds :

[root@node1 ~]# ccs -h node1.fenestros.loc --sync --activate
[root@node1 ~]# ccs -h node2.fenestros.loc --sync --activate
[root@node1 ~]# ccs -h node3.fenestros.loc --sync --activate
[root@node1 ~]# ccs -h node2.fenestros.loc --checkconf

Pour supprimer une méthode fence, la commande ccs est utilisée avec l'option –rmmethod :

[root@node1 ~]# ccs -h node1.fenestros.loc  --rmmethod APC1 node2.fenestros.loc
Method APC1 removed from node2.fenestros.loc.

LAB #15 - La Configuration des Domaines de Basculement

Pour créer un domaine de basculement identique à l'exemple précédement configuré en utilisant Conga, la commande est la suivante :

[root@node1 ~]# ccs -h node1.fenestros.loc --addfailoverdomain Failover1 ordered

Pour inclure node1.fenestros.loc et node2.fenestros.loc dans Failover1, les commandes sont :

[root@node1 ~]# ccs -h node1.fenestros.loc --addfailoverdomainnode Failover1 node1.fenestros.loc 1
[root@node1 ~]# ccs -h node1.fenestros.loc --addfailoverdomainnode Failover1 node2.fenestros.loc 2

Important - Le chiffre à la fin de chaque ligne est la priorité du mode ordered.

Pour voir les domaines de basculement configurés, utilisez la commande suivante :

[root@node1 ~]# ccs -h node1.fenestros.loc --lsfailoverdomain
Failover1: restricted=0, ordered=1, nofailback=0
  node1.fenestros.loc: priority=1
  node2.fenestros.loc: priority=2

Important - Pour supprimer un domaine de basculement, la commande ccs peur être utilisée avec l'option –rmfailoverdomain.

LAB #16 - La Création de Ressources Globales

Pour voir la liste des ressources globales disponibles dans le cluster, utilisez la commande suivante :

[root@node1 ~]# ccs -h node1.fenestros.loc --lsresourceopts
service - Defines a service (resource group).
ASEHAagent - Sybase ASE Failover Instance
SAPDatabase - Manages any SAP database (based on Oracle, MaxDB, or DB2)
SAPInstance - SAP instance resource agent
apache - Defines an Apache web server
clusterfs - Defines a cluster file system mount.
fs - Defines a file system mount.
ip - This is an IP address.
lvm - LVM Failover script
mysql - Defines a MySQL database server
named - Defines an instance of named server
netfs - Defines an NFS/CIFS file system mount.
nfsclient - Defines an NFS client.
nfsexport - This defines an NFS export.
nfsserver - This defines an NFS server resource.
openldap - Defines an Open LDAP server
oracledb - Oracle 10g/11g Failover Instance
orainstance - Oracle 10g Failover Instance
oralistener - Oracle 10g Listener Instance
postgres-8 - Defines a PostgreSQL server
samba - Dynamic smbd/nmbd resource agent
script - LSB-compliant init script as a clustered resource.
tomcat-6 - Defines a Tomcat server
vm - Defines a Virtual Machine

Pour mettre en place une adresse IP en tant que resource globale, il convient d'utiliser la commande suivante :

[root@node1 ~]# ccs -h node1.fenestros.loc --addresource ip address=10.0.3.100/24

Pour voir la liste des resources actuellement configurées, la commande ccs est utilisée avec l'opton –lsservices :

[root@node1 ~]# ccs -h node1.fenestros.loc --lsservices
resources: 
  ip: address=10.0.3.100/24

LAB #17 - La Création des Services en Cluster

Pour voir la liste des services disponibles dans le cluster, utilisez la commande suivante :

[root@node1 ~]# ccs -h node1.fenestros.loc --lsserviceopts
service - Defines a service (resource group).
ASEHAagent - Sybase ASE Failover Instance
SAPDatabase - Manages any SAP database (based on Oracle, MaxDB, or DB2)
SAPInstance - SAP instance resource agent
apache - Defines an Apache web server
clusterfs - Defines a cluster file system mount.
fs - Defines a file system mount.
ip - This is an IP address.
lvm - LVM Failover script
mysql - Defines a MySQL database server
named - Defines an instance of named server
netfs - Defines an NFS/CIFS file system mount.
nfsclient - Defines an NFS client.
nfsexport - This defines an NFS export.
nfsserver - This defines an NFS server resource.
openldap - Defines an Open LDAP server
oracledb - Oracle 10g/11g Failover Instance
orainstance - Oracle 10g Failover Instance
oralistener - Oracle 10g Listener Instance
postgres-8 - Defines a PostgreSQL server
samba - Dynamic smbd/nmbd resource agent
script - LSB-compliant init script as a clustered resource.
tomcat-6 - Defines a Tomcat server
vm - Defines a Virtual Machine

Pour créer un service en cluster appelé ip_address utilisant le domaine de basculement Failover1 avec un Recovery Mode de relocate, utilisez la commande suivante :

[root@node1 ~]# ccs -h node1.fenestros.loc --addservice ip_address domain=Failover1 recovery=relocate

Il existe quatre types de Recovery Mode :

Choix Description
Relocate En cas d'échec, le système essaie de démarrer le service sur un autre nœud.
Restart En cas d'échec, le système essayera de re-démarrer le service sur le même nœud avant de démarrer le service sur un autre nœud.
Restart-Disable En cas d'échec, le service est redémarré mais en cas d'échec du redémarrage le service est désactivé au lieu d'être transférer vers un autre nœud.
Disable En cas d'échec d'un composant d'un groupe de ressources, le système désactive le groupe de ressources.

Pour ajouter la ressource ip à ce service, il convient maintenant d'utiliser l'option –addsubservice :

[root@node1 ~]# ccs -h node1.fenestros.loc --addsubservice ip_address ip address=10.0.3.100/24

Vérifiez la mise en place :

[root@node1 ~]# ccs -h node1.fenestros.loc --lsservices
service: name=ip_address, domain=Failover1, recovery=relocate
  ip: address=10.0.3.100/24
resources: 
  ip: address=10.0.3.100/24

Les options utilisées dans cette commande peuvent être consultées avec la commande suivante :

[root@node1 ~]# ccs -f node1.fenestros.loc --lsserviceopts ip
ip - This is an IP address.
  Required Options:
    address: IP Address
  Optional Options:
    family: Family
    monitor_link: Monitor NIC Link
    nfslock: Enable NFS lock workarounds
    sleeptime: Amount of time (seconds) to sleep.
    disable_rdisc: Disable updating of routing using RDISC protocol
    prefer_interface: Network interface
    __independent_subtree: Treat this and all children as an independent subtree.
    __enforce_timeouts: Consider a timeout for operations as fatal.
    __max_failures: Maximum number of failures before returning a failure to a status check.
    __failure_expire_time: Amount of time before a failure is forgotten.
    __max_restarts: Maximum number restarts for an independent subtree before giving up.
    __restart_expire_time: Amount of time before a failure is forgotten for an independent subtree.

Supprimer des Services et Ressources en Cluster

Pour supprimer un service, utilisez l'option –rmservice de la commande ccs :

[root@node1 ~]# ccs -h node1.fenestros.loc --lsservices
service: name=ip_address, domain=Failover1, recovery=relocate
  ip: address=10.0.3.100/24
resources: 
  ip: address=10.0.3.100/24
[root@node1 ~]# ccs -h node1.fenestros.loc --rmservice ip_address
[root@node1 ~]# ccs -h node1.fenestros.loc --lsservices
resources: 
  ip: address=10.0.3.100/24

Pour supprimer une ressource, utilisez l'option –rmresource de la commande ccs :

[root@node1 ~]# ccs -h node1.fenestros.loc --rmresource ip
Unable to find matching resource: ip, []
[root@node1 ~]# ccs -h node1.fenestros.loc --rmresource ip address=10.0.3.100/24
[root@node1 ~]# ccs -h node1.fenestros.loc --lsservices
resources:

Important - N'oubliez pas de spécifier les options de la ressource que vous souhiatez supprimer, sinon la commande échoue.

LAB #18 - Configuration des Propriétés Générales du Cluster

Version de la Configuration du Cluster

La version de la configuration du cluster peut être gérer grâce à la commande ccs :

[root@node1 ~]# ccs -h node1.fenestros.loc --getversion
29
[root@node1 ~]# ccs -h node1.fenestros.loc --setversion 30
[root@node1 ~]# ccs -h node1.fenestros.loc --getversion
30

Adresse de la multidiffusion

L'adresse de multidiffusion peut être spécifiée avec la commande ccs, Par exemple :

ccs -h node1.fenestros.loc --setmulticast multicastaddress

Cluster à Deux Nœuds

Afin d'éviter un problème de quorum dans le cas d'un cluster à deux nœuds, utilisez la commande suivante :

ccs -h node1.fenestros.loc --setcman two_node=1 expected_votes=1

Journalisation

Pour activer le déboggage du cluster, utilisez la commande suivante :

ccs -h node1.fenestros.loc --setlogging debug=on

Les journaux se trouyvent par défaut dans le répertoire /var/log/cluster :

[root@node1 ~]# ls /var/log/cluster
corosync.log  dlm_controld.log  fenced.log  gfs_controld.log  rgmanager.log

Dernièrement, propagez maintenant le fichier de configuration du cluster vers les deux autres nœuds :

[root@node1 ~]# ccs -h node2.fenestros.loc --sync --activate
[root@node1 ~]# ccs -h node3.fenestros.loc --sync --activate
[root@node1 ~]# ccs -h node2.fenestros.loc --checkconf
All nodes in sync.

LAB #19 - Gérer un Cluster avec La Commande ccs

Causer à un Nœud de Quitter un Cluster

Pour enlever un nœud d'un cluster, il convient d'utiliser la commande suivante :

[root@node1 ~]# ccs -h node2.fenestros.loc --stop
[root@node1 ~]# cman_tool nodes
Node  Sts   Inc   Joined               Name
   1   M     40   2013-12-15 17:42:50  node1.fenestros.loc
   2   X     44                        node2.fenestros.loc
   3   M     44   2013-12-15 17:42:50  node3.fenestros.loc

Important - Pour supprimer un complètement nœud, il convient d'utiliser l'option –rmnode de la commande ccs.

Causer à un Nœud de Joindre un Cluster

Pour enlever un nœud d'un cluster, il convient d'utiliser la commande suivante :

[root@node1 ~]# ccs -h node2.fenestros.loc --start
[root@node1 ~]# cman_tool nodes
Node  Sts   Inc   Joined               Name
   1   M     40   2013-12-15 17:42:50  node1.fenestros.loc
   2   M     52   2013-12-15 17:44:58  node2.fenestros.loc
   3   M     44   2013-12-15 17:42:50  node3.fenestros.loc

Arrêter un cluster

Pour arrêter un cluster, utilisez la commande suivante :

[root@node1 ~]# ccs -h node1.fenestros.loc --stopall
Stopped node2.fenestros.loc
Stopped node3.fenestros.loc
Stopped node1.fenestros.loc

Démarrer un cluster

Pour démarrer un cluster, utilisez la commande suivante :

[root@node1 ~]# ccs -h node1.fenestros.loc --startall
Started node2.fenestros.loc
Started node3.fenestros.loc
Started node1.fenestros.loc

Diagnostiquer des Problèmes de Configuration

Pour diagnostiquer des problèmes au niveau de la configuration, utilisez la commande suivante :

[root@node1 ~]# ccs -h node1.fenestros.loc --checkconf
All nodes in sync.

ou la commande suivante :

[root@node1 ~]# ccs -f /etc/cluster/cluster.conf --checkconf
All nodes in sync.

Configurer et Gérer un Cluster avec des Outils de Ligne de Commande

Introduction

La configuration en utilisant la ligne de commande consiste en :

  • La préparation de tous les nœuds,
  • La création d'un cluster,
  • La configuration du daemon fenced,
  • La configuration des périphériques fence (Fence Devices),
  • La configuration des domaines de basculement (Failover Domains),
  • La création de ressources globales,
  • La création des services en cluster,
  • Propagation du fichier de configuration du cluster à tous les nœuds du cluster.

LAB #20 - Préparation de tous les nœuds

node1.fenestros.loc

Installer et Configurer ricci

Lancez la machine virtuelle node100. Celle-ci étant un clone de la machine node1, ricci est déjà installé.

Démarrez puis configurez ricci :

[root@node1 ~]# service ricci status
ricci est arrêté
[root@node1 ~]# service ricci start
Démarrage de oddjobd :                                     [  OK  ]
generating SSL certificates...  done
Generating NSS database...  done
Démarrage de ricci :                                       [  OK  ]
[root@node1 ~]# chkconfig --list ricci
ricci          	0:arrêt	1:arrêt	2:arrêt	3:arrêt	4:arrêt	5:arrêt	6:arrêt
[root@node1 ~]# chkconfig --level 345 ricci on
[root@node1 ~]# chkconfig --list ricci
ricci          	0:arrêt	1:arrêt	2:arrêt	3:marche	4:marche	5:marche6:arrêt

Créez maintenant un mot de passe pour l'utilisateur ricci :

[root@node1 ~]# passwd ricci
Changement de mot de passe pour l'utilisateur ricci.
Nouveau mot de passe : 
MOT DE PASSE INCORRECT : trop court
MOT DE PASSE INCORRECT : est trop simple
Retapez le nouveau mot de passe : 
passwd : mise à jour réussie de tous les jetons d'authentification.
Modifiez /etc/hosts

Créez une entrée pour chaque nœud dans le fichier /etc/hosts :

hosts
127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
::1         localhost localhost.localdomain localhost6 localhost6.localdomain6
10.0.3.15	node1.fenestros.loc
10.0.3.16	node2.fenestros.loc
10.0.3.17	node3.fenestros.loc

node2.fenestros.loc

Installer et Configurer ricci

Lancez la machine virtuelle node200. Celle-ci étant un clone de la machine node2, ricci est déjà installé.

Démarrez puis configurez ricci :

[root@node2 ~]# service ricci status
ricci est arrêté
[root@node2 ~]# service ricci start
Démarrage de oddjobd :                                     [  OK  ]
generating SSL certificates...  done
Generating NSS database...  done
Démarrage de ricci :                                       [  OK  ]
[root@node2 ~]# chkconfig --level 345 ricci on
[root@node2 ~]# chkconfig --list ricci
ricci          	0:arrêt	1:arrêt	2:arrêt	3:marche	4:marche	5:marche6:arrêt

Créez maintenant un mot de passe pour l'utilisateur ricci :

[root@node2 ~]# passwd ricci
Changement de mot de passe pour l'utilisateur ricci.
Nouveau mot de passe : 
MOT DE PASSE INCORRECT : trop court
MOT DE PASSE INCORRECT : est trop simple
Retapez le nouveau mot de passe : 
passwd : mise à jour réussie de tous les jetons d'authentification.
Modifiez /etc/hosts

Créez une entrée pour chaque nœud dans le fichier /etc/hosts :

hosts
127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
::1         localhost localhost.localdomain localhost6 localhost6.localdomain6
10.0.3.15	node1.fenestros.loc
10.0.3.16	node2.fenestros.loc
10.0.3.17	node3.fenestros.loc

node3.fenestros.loc

Installer et Configurer ricci

Lancez la machine virtuelle node300. Celle-ci étant un clone de la machine node3, ricci est déjà installé.

Démarrez puis configurez ricci :

[root@node3 ~]# service ricci status
ricci est arrêté
[root@node3 ~]# service ricci start
Démarrage de oddjobd :                                     [  OK  ]
generating SSL certificates...  done
Generating NSS database...  done
Démarrage de ricci :                                       [  OK  ]
[root@node3 ~]# chkconfig --level 345 ricci on
[root@node3 ~]# chkconfig --list ricci
ricci          	0:arrêt	1:arrêt	2:arrêt	3:marche	4:marche	5:marche6:arrêt

Créez maintenant un mot de passe pour l'utilisateur ricci :

[root@node3 ~]# passwd ricci
Changement de mot de passe pour l'utilisateur ricci.
Nouveau mot de passe : 
MOT DE PASSE INCORRECT : trop court
MOT DE PASSE INCORRECT : est trop simple
Retapez le nouveau mot de passe : 
passwd : mise à jour réussie de tous les jetons d'authentification.
Modifiez /etc/hosts

Créez une entrée pour chaque nœud dans le fichier /etc/hosts :

hosts
127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
::1         localhost localhost.localdomain localhost6 localhost6.localdomain6
10.0.3.15	node1.fenestros.loc
10.0.3.16	node2.fenestros.loc
10.0.3.17	node3.fenestros.loc

LAB #21 - Création d'un Cluster

Sur chaque noeud utilisez le fichier suivant pour créer /etc/cluster/cluster.conf :

cluster.conf
<?xml version="1.0"?>
<cluster config_version="1" name="moncluster">
   <clusternodes>
     <clusternode name="node1.fenestros.loc" nodeid="1" votes="1"/>
     <clusternode name="node2.fenestros.loc" nodeid="2" votes="1"/>
     <clusternode name="node3.fenestros.loc" nodeid="3" votes="1"/>
   </clusternodes>
   <fencedevices>
   </fencedevices>
   <rm>
   </rm>
</cluster>

Configurez les Services Cluster

Configurez les services cluster sur chaque machine virtuelle :

[root@node1 ~]# chkconfig --level 2345 cman on
[root@node1 ~]# reboot
[root@node2 ~]# chkconfig --level 2345 cman on
[root@node2 ~]# reboot
[root@node3 ~]# chkconfig --level 2345 cman on
[root@node3 ~]# reboot

Quand les machines virtuelles ont redémarrés, vérifiez l'existance du cluster :

[root@node1 ~]# cman_tool nodes
Node  Sts   Inc   Joined               Name
   1   M     16   2013-12-15 19:26:19  node1.fenestros.loc
   2   M     20   2013-12-15 19:26:19  node2.fenestros.loc
   3   M     24   2013-12-15 19:26:27  node3.fenestros.loc

LAB #22 - Configuration du Daemon Fenced

La configuration Daemon Fenced se fait par l'édition du fichier /etc/cluster/cluster.conf :

cluster.conf
<?xml version="1.0"?>
<cluster config_version="1" name="moncluster">
   <clusternodes>
     <clusternode name="node1.fenestros.loc" nodeid="1" votes="1"/>
     <clusternode name="node2.fenestros.loc" nodeid="2" votes="1"/>
     <clusternode name="node3.fenestros.loc" nodeid="3" votes="1"/>
   </clusternodes>
   <fencedevices>
   </fencedevices>
   <rm>
   </rm>
</cluster>

Par exemple :

cluster.conf
<?xml version="1.0"?>
<cluster config_version="2" name="moncluster">
<fence_daemon post_fail_delay="5" post_join_delay="25"/>
   <clusternodes>
     <clusternode name="node1.fenestros.loc" nodeid="1" votes="1"/>
     <clusternode name="node2.fenestros.loc" nodeid="2" votes="1"/>
     <clusternode name="node3.fenestros.loc" nodeid="3" votes="1"/>
   </clusternodes>
   <fencedevices>
   </fencedevices>
   <rm>
   </rm>
</cluster>

Rappelez-vous que les deux paramètres du daemon sont :

  • Post Fail Delay - Le nombre de secondes qu'attend le daemon fenced avant de réagir quand un nœud dans un Domaine Fence devient défaillant. La valeur par défaut est 0,
  • Post Join Delay - Le nombre de secondes qu'attend le daemon fenced avant de réagir quand un nœud rejoint un Domaine Fence. La valeur par défaut est 6. La valeur conseillée est entre 20 et 30.

Validez le fichier sur le schéma du cluster (/usr/share/cluster/cluster.rng) :

[root@node1 ~]# ccs_config_validate 
Configuration validates

LAB #23 - Configuration des Périphériques Fence

La configuration d'un périphérique fence se fait par l'édition du fichier /etc/cluster/cluster.conf :

cluster.conf
<?xml version="1.0"?>
<cluster config_version="2" name="moncluster">
<fence_daemon post_fail_delay="5" post_join_delay="25"/>
   <clusternodes>
     <clusternode name="node1.fenestros.loc" nodeid="1" votes="1"/>
     <clusternode name="node2.fenestros.loc" nodeid="2" votes="1"/>
     <clusternode name="node3.fenestros.loc" nodeid="3" votes="1"/>
   </clusternodes>
   <fencedevices>
   </fencedevices>
   <rm>
   </rm>
</cluster>

Par exemple :

cluster.conf
<?xml version="1.0"?>
<cluster config_version="3" name="moncluster">
<fence_daemon post_fail_delay="5" post_join_delay="25"/>
   <clusternodes>
     <clusternode name="node1.fenestros.loc" nodeid="1" votes="1"/>
     <clusternode name="node2.fenestros.loc" nodeid="2" votes="1"/>
     <clusternode name="node3.fenestros.loc" nodeid="3" votes="1"/>
   </clusternodes>
   <fencedevices>
		<fencedevice agent="fence_apc" ipaddr="10.0.3.50" login="root" name="APC1" passwd="password"/>
		<fencedevice agent="fence_apc" ipaddr="10.0.3.51" login="root" name="APC2" passwd="password"/>
   </fencedevices>
   <rm>
   </rm>
</cluster>

Validez le fichier sur le schéma du cluster (/usr/share/cluster/cluster.rng) :

[root@node1 ~]# ccs_config_validate 
Configuration validates

Une méthode est configurée de la même manière :

cluster.conf
<?xml version="1.0"?>
<cluster config_version="4" name="moncluster">
<fence_daemon post_fail_delay="5" post_join_delay="25"/>
   <clusternodes>
     <clusternode name="node1.fenestros.loc" nodeid="1" votes="1">
         <fence>
            <method name="APC1">
              <device name="APC1" port="1"/>
             </method>
         </fence>
     </clusternode>
     <clusternode name="node2.fenestros.loc" nodeid="2" votes="1"/>
     <clusternode name="node3.fenestros.loc" nodeid="3" votes="1"/>
   </clusternodes>
   <fencedevices>
		<fencedevice agent="fence_apc" ipaddr="10.0.3.50" login="root" name="APC1" passwd="password"/>
		<fencedevice agent="fence_apc" ipaddr="10.0.3.51" login="root" name="APC2" passwd="password"/>
   </fencedevices>
   <rm>
   </rm>
</cluster>

Validez le fichier sur le schéma du cluster (/usr/share/cluster/cluster.rng) :

[root@node1 ~]# ccs_config_validate 
Configuration validates

LAB #23 - La Configuration des Domaines de Basculement

Pour créer un domaine de basculement identique à l'exemple précédement configuré en utilisant la commande css, éditez de nouveau le fichier /etc/cluster/cluster.conf :

cluster.conf
<?xml version="1.0"?>
<cluster config_version="5" name="moncluster">
<fence_daemon post_fail_delay="5" post_join_delay="25"/>
   <clusternodes>
     <clusternode name="node1.fenestros.loc" nodeid="1" votes="1">
         <fence>
            <method name="APC1">
              <device name="APC1" port="1"/>
             </method>
         </fence>
     </clusternode>
     <clusternode name="node2.fenestros.loc" nodeid="2" votes="1"/>
     <clusternode name="node3.fenestros.loc" nodeid="3" votes="1"/>
   </clusternodes>
   <fencedevices>
		<fencedevice agent="fence_apc" ipaddr="10.0.3.50" login="root" name="APC1" passwd="password"/>
		<fencedevice agent="fence_apc" ipaddr="10.0.3.51" login="root" name="APC2" passwd="password"/>
   </fencedevices>
   <rm>
		<failoverdomains>
			<failoverdomain name="Failover1" nofailback="0" ordered="1" restricted="0">
				<failoverdomainnode name="node1.fenestros.loc" priority="1"/>
				<failoverdomainnode name="node2.fenestros.loc" priority="2"/>
			</failoverdomain>
		</failoverdomains>
   </rm>
</cluster>

Validez le fichier sur le schéma du cluster (/usr/share/cluster/cluster.rng) :

[root@node1 ~]# ccs_config_validate 
Configuration validates

LAB #24 - La Création de Ressources Globales

La création d'une ressource globale s'effectue en éditant la section <rm> du fichier /etc/cluster/cluster.conf :

cluster.conf
<?xml version="1.0"?>
<cluster config_version="6" name="moncluster">
<fence_daemon post_fail_delay="5" post_join_delay="25"/>
   <clusternodes>
     <clusternode name="node1.fenestros.loc" nodeid="1" votes="1">
         <fence>
            <method name="APC1">
              <device name="APC1" port="1"/>
             </method>
         </fence>
     </clusternode>
     <clusternode name="node2.fenestros.loc" nodeid="2" votes="1"/>
     <clusternode name="node3.fenestros.loc" nodeid="3" votes="1"/>
   </clusternodes>
   <fencedevices>
		<fencedevice agent="fence_apc" ipaddr="10.0.3.50" login="root" name="APC1" passwd="password"/>
		<fencedevice agent="fence_apc" ipaddr="10.0.3.51" login="root" name="APC2" passwd="password"/>
   </fencedevices>
   <rm>
		<failoverdomains>
			<failoverdomain name="Failover1" nofailback="0" ordered="1" restricted="0">
				<failoverdomainnode name="node1.fenestros.loc" priority="1"/>
				<failoverdomainnode name="node2.fenestros.loc" priority="2"/>
			</failoverdomain>
		</failoverdomains>
		<resources>
			<ip address="10.0.3.100/24" monitor_link="yes" sleeptime="10"/>
		</resources>
   </rm>
</cluster>

Validez le fichier sur le schéma du cluster (/usr/share/cluster/cluster.rng) :

[root@node1 ~]# ccs_config_validate 
Configuration validates

Important - Par défaut, tous les 10 secondes, rgmanager recherche dans l'arbre des ressources celles qui ont dépassé l'intervalle de vérification. Chaque agent de ressource spécifie l'intervalle de vérification pour la ressource concernée. Cette intervalle peut être modifiée en éditant le fichier /etc/cluster/cluster.conf en spécifiant une intervalle pour une ressource spécifique avec la balise <action> : <action name=“status” depth=“*” interval=“10” />. Certains agents fournissent plusieurs profondeurs (depths) de vérification. Plus profonde est la vérification, plus complet est la vérification. Dans l'exemple précédent, l'intervalle concerne tous les profondeurs.

LAB #25 - La Création des Services en Cluster

La création d'un service globale s'effectue en éditant la section <rm> du fichier /etc/cluster/cluster.conf :

cluster.conf
<?xml version="1.0"?>
<cluster config_version="7" name="moncluster">
<fence_daemon post_fail_delay="5" post_join_delay="25"/>
   <clusternodes>
     <clusternode name="node1.fenestros.loc" nodeid="1" votes="1">
         <fence>
            <method name="APC1">
              <device name="APC1" port="1"/>
             </method>
         </fence>
     </clusternode>
     <clusternode name="node2.fenestros.loc" nodeid="2" votes="1"/>
     <clusternode name="node3.fenestros.loc" nodeid="3" votes="1"/>
   </clusternodes>
   <fencedevices>
		<fencedevice agent="fence_apc" ipaddr="10.0.3.50" login="root" name="APC1" passwd="password"/>
		<fencedevice agent="fence_apc" ipaddr="10.0.3.51" login="root" name="APC2" passwd="password"/>
   </fencedevices>
   <rm>
		<failoverdomains>
			<failoverdomain name="Failover1" nofailback="0" ordered="1" restricted="0">
				<failoverdomainnode name="node1.fenestros.loc" priority="1"/>
				<failoverdomainnode name="node2.fenestros.loc" priority="2"/>
			</failoverdomain>
		</failoverdomains>
		<resources>
			<ip address="10.0.3.100/24" monitor_link="yes" sleeptime="10"/>
		</resources>
		<service autostart="0" domain="Failover1" exclusive="0" name="ip_address" recovery="relocate">
			<ip address="10.0.3.100/24" monitor_link="yes" sleeptime="10"/>
		</service>
   </rm>
</cluster>

Validez le fichier sur le schéma du cluster (/usr/share/cluster/cluster.rng) :

[root@node1 ~]# ccs_config_validate 
Configuration validates

Rappelez-vous qu'il existe quatre types de Recovery Mode :

Choix Description
Relocate En cas d'échec, le système essaie de démarrer le service sur un autre nœud.
Restart En cas d'échec, le système essayera de re-démarrer le service sur le même nœud avant de démarrer le service sur un autre nœud.
Restart-Disable En cas d'échec, le service est redémarré mais en cas d'échec du redémarrage le service est désactivé au lieu d'être transférer vers un autre nœud.
Disable En cas d'échec d'un composant d'un groupe de ressources, le système désactive le groupe de ressources.

LAB #26 - Propagation du Fichier de Configuration

Utilisez la commande cman_tool version -r pour propager le fichier de configuration :

[root@node1 ~]# cman_tool version -r 
You have not authenticated to the ricci daemon on node1.fenestros.loc
Password: ricci
You have not authenticated to the ricci daemon on node2.fenestros.loc
Password: ricci
You have not authenticated to the ricci daemon on node3.fenestros.loc
Password: ricci

Arrêter et Démarrer le Cluster

Lors de l'arrêt du cluster, les services doivent être arrêtés dans un ordre précis :

  • rgmanager - si vous utilisez les services high-availability,
  • gfs2 - si vous utilisez Red Hat GFS2,
  • clvmd - si CLVM a été utilisé pour créer des volumes clusterisés,
  • cman.

Bien évidement lors du démarrage, les services doivent être démarrés dans l'ordre inverse :

  • cman,
  • clvmd - si CLVM a été utilisé pour créer des volumes clusterisés,
  • gfs2 - si vous utilisez Red Hat GFS2,
  • rgmanager - si vous utilisez les services high-availability.

LAB #27 - Supprimer un Noeud

Pour supprimer un noeud, éditez le fichier /etc/cluster/cluster.conf :

cluster.conf
<?xml version="1.0"?>
<cluster config_version="7" name="moncluster">
   <cman two_node="1" expected_votes="1"/>
	<fence_daemon post_fail_delay="5" post_join_delay="25"/>
	<clusternodes>
		<clusternode name="node1.fenestros.loc" nodeid="1" votes="1">
			<fence>
				<method name="APC1">
					<device name="APC1" port="1"/>
				</method>
			</fence>
		</clusternode>
		<clusternode name="node2.fenestros.loc" nodeid="2" votes="1"/>
	</clusternodes>
	<fencedevices>
		<fencedevice agent="fence_apc" ipaddr="10.0.3.50" login="root" name="APC1" passwd="password"/>
		<fencedevice agent="fence_apc" ipaddr="10.0.3.51" login="root" name="APC2" passwd="password"/>
	</fencedevices>
	<rm>
		<failoverdomains>
			<failoverdomain name="Failover1" nofailback="0" ordered="1" restricted="0">
				<failoverdomainnode name="node1.fenestros.loc" priority="1"/>
				<failoverdomainnode name="node2.fenestros.loc" priority="2"/>
			</failoverdomain>
		</failoverdomains>
		<resources>
			<ip address="10.0.3.100/24" monitor_link="yes" sleeptime="10"/>
		</resources>
		<service autostart="0" domain="Failover1" exclusive="0" name="ip_address" recovery="relocate">
			<ip address="10.0.3.100/24" monitor_link="yes" sleeptime="10"/>
		</service>
	</rm>
</cluster>

Validez le fichier sur le schéma du cluster (/usr/share/cluster/cluster.rng) :

[root@node1 ~]# ccs_config_validate 
Configuration validates

Utilisez la commande cman_tool version -r pour propager le fichier de configuration :

[root@node1 ~]# cman_tool version -r 

Utilisez la commande clustat pour visualiser le statut du cluster :

[root@node1 ~]# clustat
Cluster Status for moncluster @ Tue Dec 17 18:14:05 2013
Member Status: Quorate

 Member Name                                                     ID   Status
 ------ ----                                                     ---- ------
 node1.fenestros.loc                                                 1 Online, Local
 node2.fenestros.loc                                                 2 Online
 node3.fenestros.loc                                                 3 Online, Estranged

Éteignez node3 puis utilisez la commande clustat de nouveau :

[root@node1 ~]# clustat
Cluster Status for moncluster @ Tue Dec 17 18:15:03 2013
Member Status: Quorate

 Member Name                                                     ID   Status
 ------ ----                                                     ---- ------
 node1.fenestros.loc                                                 1 Online, Local
 node2.fenestros.loc                                                 2 Online

Utilisez maintenant la commande cman_tool :

[root@node1 ~]# cman_tool nodes
Node  Sts   Inc   Joined               Name
   1   M    136   2013-12-17 16:59:41  node1.fenestros.loc
   2   M    140   2013-12-17 16:59:42  node2.fenestros.loc
   3   X    144                        node3.fenestros.loc

La colonne Sts peut contenir une de trois valeurs :

  • M Le noeud est un membre du cluster,
  • X Le noeud n'est pas un membre du cluster,
  • d Accès au cluster est interdit pour ce noeud.
Puisque le compte des neouds est passé de deux à trois, vous devez redémarrez les noeuds un et deux.

Une fois les machines redémarrées, la commande clustat démontre un quorum à deux noeuds :

[root@node1 ~]# clustat
Cluster Status for moncluster @ Tue Dec 17 18:30:37 2013
Member Status: Quorate

 Member Name                             ID   Status
 ------ ----                             ---- ------
 node1.fenestros.loc                         1 Online, Local
 node2.fenestros.loc                         2 Online

LAB #28 - Ajouter un Noeud

Pour rajouter node3 de nouveau, rétablissez le fichier /etc/cluster/cluster.conf dans son état d'origine :

cluster.conf
<?xml version="1.0"?>
<cluster config_version="8" name="moncluster">
<fence_daemon post_fail_delay="5" post_join_delay="25"/>
   <clusternodes>
     <clusternode name="node1.fenestros.loc" nodeid="1" votes="1">
         <fence>
            <method name="APC1">
              <device name="APC1" port="1"/>
             </method>
         </fence>
     </clusternode>
     <clusternode name="node2.fenestros.loc" nodeid="2" votes="1"/>
     <clusternode name="node3.fenestros.loc" nodeid="3" votes="1"/>
   </clusternodes>
   <fencedevices>
		<fencedevice agent="fence_apc" ipaddr="10.0.3.50" login="root" name="APC1" passwd="password"/>
		<fencedevice agent="fence_apc" ipaddr="10.0.3.51" login="root" name="APC2" passwd="password"/>
   </fencedevices>
   <rm>
		<failoverdomains>
			<failoverdomain name="Failover1" nofailback="0" ordered="1" restricted="0">
				<failoverdomainnode name="node1.fenestros.loc" priority="1"/>
				<failoverdomainnode name="node2.fenestros.loc" priority="2"/>
			</failoverdomain>
		</failoverdomains>
		<resources>
			<ip address="10.0.3.100/24" monitor_link="yes" sleeptime="10"/>
		</resources>
		<service autostart="0" domain="Failover1" exclusive="0" name="ip_address" recovery="relocate">
			<ip address="10.0.3.100/24" monitor_link="yes" sleeptime="10"/>
		</service>
   </rm>
</cluster>

Démarrez node3 puis utilisez la commande cman_tool version -r pour propager le fichier de configuration :

[root@node1 ~]# cman_tool version -r 

Démarrez maintenant le Cluster Service Manager :

[root@node1 ~]# service rgmanager start
Starting Cluster Service Manager:                          [  OK  ]

Activez rgmanager sur les trois neouds et redémarrez les machines virtuelles :

[root@node1 ~]# chkconfig --level 2345 rgmanager on
[root@node1 ~]# reboot
[root@node2 ~]# chkconfig --level 2345 rgmanager on
[root@node1 ~]# reboot
[root@node3 ~]# chkconfig --level 2345 rgmanager on
[root@node1 ~]# reboot

Une fois les machines redémarrées, utilisez la commande clustat pour visualiser le statut du cluster :

[root@node1 ~]# clustat
Cluster Status for moncluster @ Tue Dec 17 19:26:46 2013
Member Status: Quorate

 Member Name                             ID   Status
 ------ ----                             ---- ------
 node1.fenestros.loc                         1 Online, Local, rgmanager
 node2.fenestros.loc                         2 Online, rgmanager
 node3.fenestros.loc                         3 Online, rgmanager

 Service Name                   Owner (Last)                   State         
 ------- ----                   ----- ------                   -----         
 service:ip_address             node1.fenestros.loc            started  

L'état du service peut être un des états suivants :

Etat Description
Started Le service est disponible.
Recovering Le service est en attente de démarrage sur un autre nœud.
Disabled Le service a été désactivé.
Stopped Un état temporaire généralement visible juste avant la transition du service vers un autre noeud.
Failed Le service est mort.
Uninitialized Cet état peut apparaître dans certains cas lors du démarrage.

LAB #29 - Gérer les Services avec la Commande clusvcadm

La commande clusvcadm permet de :

  • Activer un service,
  • Désactiver un service,
  • Arrêter un service,
  • Geler un service,
  • Dégeler un service,
  • Migrer un service de machines virtuelle,
  • Déplacer un service,
  • Redémarrer un service.

Lancez la commande clustat :

[root@node1 ~]# clustat
Cluster Status for moncluster @ Tue Dec 17 21:57:24 2013
Member Status: Quorate

 Member Name                             ID   Status
 ------ ----                             ---- ------
 node1.fenestros.loc                         1 Online, Local, rgmanager
 node2.fenestros.loc                         2 Online, rgmanager
 node3.fenestros.loc                         3 Online, rgmanager

 Service Name                   Owner (Last)                   State         
 ------- ----                   ----- ------                   -----         
 service:ip_address             node1.fenestros.loc            started       

Utilisez la commande clusvcadm pour arrêter le service ip_address :

[root@node1 ~]# clusvcadm -s ip_address
Local machine stopping service:ip_address...Success
[root@node1 ~]# clustat
Cluster Status for moncluster @ Tue Dec 17 22:00:11 2013
Member Status: Quorate

 Member Name                             ID   Status
 ------ ----                             ---- ------
 node1.fenestros.loc                         1 Online, Local, rgmanager
 node2.fenestros.loc                         2 Online, rgmanager
 node3.fenestros.loc                         3 Online, rgmanager

 Service Name                   Owner (Last)                   State         
 ------- ----                   ----- ------                   -----         
 service:ip_address             (node1.fenestros.loc)          stopped    

Utilisez la commande clusvcadm pour démarrer le service ip_address :

[root@node1 ~]# clusvcadm -e ip_address
Local machine trying to enable service:ip_address...Success
service:ip_address is now running on node1.fenestros.loc

Utilisez la commande clusvcadm pour déplacer le service ip_address vers node2 :

[root@node1 ~]# clusvcadm -r ip_address
Trying to relocate service:ip_address...Success
service:ip_address is now running on node2.fenestros.loc
[root@node1 ~]# clustat
Cluster Status for moncluster @ Tue Dec 17 22:04:29 2013
Member Status: Quorate

 Member Name                             ID   Status
 ------ ----                             ---- ------
 node1.fenestros.loc                         1 Online, Local, rgmanager
 node2.fenestros.loc                         2 Online, rgmanager
 node3.fenestros.loc                         3 Online, rgmanager

 Service Name                   Owner (Last)                   State         
 ------- ----                   ----- ------                   -----         
 service:ip_address             node2.fenestros.loc            started  

LAB #30 - CLVM et GFS2

La mutualisation du stockage s'obtient en utilisant un SAN (Storage Area Network) ou un NAS (Network Attached Storage). La différence entre les deux réside dans la façon que le client voit le stockage :

  • le SAN est vu par le client comme un disque interne. Les ressources d'un SAN sont mutualisées permettant ainsi une gestion centralisée du stockage, une évolution du stockage ainsi que des fonctions de réplication,
  • le NAS est partagé sur le réseau en utilisant un protocole tel CIFS, NFS et/ou AppleShare.

Le SAN utilise un réseau en fibre optique et un des protocoles suivants :

Le vocabulaire du SAN est résumé dans le tableau suivant :

Terme Description
Fabric L'ensemble d'un SAN
Director Un switch fibre channel
GLM (Global Link Module) Le raccordement entre le réseau fibre et le réseau ethernet dans le cas de l'utilisation du FCoE
HBA (Host Bus Adaptors) Les adaptateurs fibre dans les clients
FA (Fibre Adaptors) Les ports fibres d'un baie de stockage
Zoning Le découpage du SAN en sous-réseaux, uniquement accessible à certains clients
mapping La présentation de certains volumes logiques de la baie sur un ou plusieurs FA spécifiques
masking La restriction d'accès à certains volumes logiques
multipathing Le regroupement de plusieurs chemins vers le même SAN

Vous allez simuler un SAN avec iSCSI en utilisant une machine virtuelle. Arrêtez les machines virtuelles node100, node200 et node300. Créez un clône de node300, appelé san. Attachez un disque supplémentaire, appelé sdb d'une taille de 512 Mo au controleur SATA de la nouvelle machine virtuelle san.

Démarrez la machine virtuelle san. Supprimez les services inutiles :

[root@node3 ~]# chkconfig --del iptables
[root@node3 ~]# chkconfig --del rgmanager
[root@node3 ~]# chkconfig --del ricci
[root@node3 ~]# chkconfig --del modclusterd
[root@node3 ~]# chkconfig --del clvmd
[root@node3 ~]# chkconfig --del cman

Modifiez le fichier /etc/sysconfig/network-scripts/ifcfg-bond0 :

ifcfg-bond0
DEVICE=bond0
USERCTL=no
BOOTPROTO=none
ONBOOT=yes
IPADDR=10.0.3.18
NETMASK=255.255.255.0
NETWORK=10.0.3.0
BONDING_OPTS="miimon=100 mode=balance-xor"
TYPE=Unknown
IPV6INIT=no

Modifiez le fichier /etc/sysconfig/network :

network
NETWORKING=yes
HOSTNAME=san.fenestros.loc

Modifiez le fichier /etc/hosts :

hosts
127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
::1         localhost localhost.localdomain localhost6 localhost6.localdomain6
10.0.3.15	node1.fenestros.loc 	node1
10.0.3.16	node2.fenestros.loc	node2
10.0.3.17	node3.fenestros.loc	node3
10.0.3.18	san.fenestros.loc	san

Installez maintenant le paquet scsi-target-utils :

[root@node3 ~]# yum install scsi-target-utils
Loaded plugins: fastestmirror, refresh-packagekit, security
Loading mirror speeds from cached hostfile
 * atomic: mir01.syntis.net
 * base: mirrors.atosworldline.com
 * epel: epel.mirrors.ovh.net
 * extras: mirrors.atosworldline.com
 * rpmforge: repoforge.cu.be
 * updates: centos.mirror.crcrepairs.com
Setting up Install Process
Resolving Dependencies
--> Running transaction check
---> Package scsi-target-utils.i686 0:1.0.24-12.el6_5 will be installed
--> Processing Dependency: perl(Config::General) for package: scsi-target-utils-1.0.24-12.el6_5.i686
--> Running transaction check
---> Package perl-Config-General.noarch 0:2.52-1.el6 will be installed
--> Finished Dependency Resolution

Dependencies Resolved

========================================================================================================================================================================
 Package                                        Arch                              Version                                      Repository                          Size
========================================================================================================================================================================
Installing:
 scsi-target-utils                              i686                              1.0.24-12.el6_5                              updates                            172 k
Installing for dependencies:
 perl-Config-General                            noarch                            2.52-1.el6                                   base                                72 k

Transaction Summary
========================================================================================================================================================================
Install       2 Package(s)

Total download size: 244 k
Installed size: 581 k
Is this ok [y/N]: y

Le paquet contient la commande tgtd et la commande tgtadm.

Les options de la commande tgtd sont :

[root@node3 ~]# tgtd --help
Usage: tgtd [OPTION]
Target framework daemon, version 1.0.24
  -f, --foreground        make the program run in the foreground
  -C, --control-port NNNN use port NNNN for the mgmt channel
  -t, --nr_iothreads NNNN specify the number of I/O threads
  -d, --debug debuglevel  print debugging information
  -V, --version           print version and exit
  -h, --help              display this help and exit

Les options de la commande tgtadm sont :

[root@node3 ~]# tgtadm --help
Usage: tgtadm [OPTION]
Linux SCSI Target Framework Administration Utility, version 1.0.24

  --lld <driver> --mode target --op new --tid <id> --targetname <name>
                        add a new target with <id> and <name>. <id> must not be zero.
  --lld <driver> --mode target --op delete [--force] --tid <id>
			delete the specific target with <id>.
			With force option, the specific target is deleted 
			even if there is an activity.
  --lld <driver> --mode target --op show
                        show all the targets.
  --lld <driver> --mode target --op show --tid <id>
                        show the specific target's parameters.
  --lld <driver> --mode target --op update --tid <id> --name <param> --value <value>
                        change the target parameters of the specific
                        target with <id>.
  --lld <driver> --mode target --op bind --tid <id> --initiator-address <address>
  --lld <driver> --mode target --op bind --tid <id> --initiator-name <name>
                        enable the target to accept the specific initiators.
  --lld <driver> --mode target --op unbind --tid <id> --initiator-address <address>
  --lld <driver> --mode target --op unbind --tid <id> --initiator-name <name>
                        disable the specific permitted initiators.
  --lld <driver> --mode logicalunit --op new --tid <id> --lun <lun> \
                        --backing-store <path> --bstype <type> --bsoflags <options>
                        add a new logical unit with <lun> to the specific
                        target with <id>. The logical unit is offered
                        to the initiators. <path> must be block device files
                        (including LVM and RAID devices) or regular files.
                        bstype option is optional.
                        bsoflags supported options are sync and direct
                        (sync:direct for both).
  --lld <driver> --mode logicalunit --op delete --tid <id> --lun <lun>
                        delete the specific logical unit with <lun> that
                        the target with <id> has.
  --lld <driver> --mode account --op new --user <name> --password <pass>
                        add a new account with <name> and <pass>.
  --lld <driver> --mode account --op delete --user <name>
                        delete the specific account having <name>.
  --lld <driver> --mode account --op bind --tid <id> --user <name> [--outgoing]
                        add the specific account having <name> to
                        the specific target with <id>.
                        <user> could be <IncomingUser> or <OutgoingUser>.
                        If you use --outgoing option, the account will
                        be added as an outgoing account.
  --lld <driver> --mode account --op unbind --tid <id> --user <name>
                        delete the specific account having <name> from specific
                        target.
  --control-port <port> use control port <port>
  --help                display this help and exit

Report bugs to <stgt@vger.kernel.org>.

Configurez maintenant le service tgtd avec chkconfig :

[root@node3 ~]# chkconfig tgtd on
[root@node3 ~]# chkconfig --list tgtd
tgtd           	0:arrêt	1:arrêt	2:marche	3:marche	4:marche	5:marche	6:arrêt

Important - Redémarrez la machine virtuelle san.

Créez maintenant une cible à laquelle vous pouvez rajouter le disque :

[root@san ~]# tgtadm --lld iscsi --op new --mode target --tid 1 -T target

Consultez la configuration actuelle :

[root@san ~]# tgtadm --lld iscsi --op show --mode target
Target 1: target
    System information:
        Driver: iscsi
        State: ready
    I_T nexus information:
    LUN information:
        LUN: 0
            Type: controller
            SCSI ID: IET     00010000
            SCSI SN: beaf10
            Size: 0 MB, Block size: 1
            Online: Yes
            Removable media: No
            Prevent removal: No
            Readonly: No
            Backing store type: null
            Backing store path: None
            Backing store flags: 
    Account information:
    ACL information:

Ajoutez maintenant le disque /dev/sdb au premier LUN :

[root@san ~]# tgtadm --lld iscsi --op new --mode logicalunit --tid 1 --lun 1 -b /dev/sdb

Consultez la configuration :

[root@san ~]# tgtadm --lld iscsi --op show --mode target
Target 1: target
    System information:
        Driver: iscsi
        State: ready
    I_T nexus information:
    LUN information:
        LUN: 0
            Type: controller
            SCSI ID: IET     00010000
            SCSI SN: beaf10
            Size: 0 MB, Block size: 1
            Online: Yes
            Removable media: No
            Prevent removal: No
            Readonly: No
            Backing store type: null
            Backing store path: None
            Backing store flags: 
        LUN: 1
            Type: disk
            SCSI ID: IET     00010001
            SCSI SN: beaf11
            Size: 537 MB, Block size: 512
            Online: Yes
            Removable media: No
            Prevent removal: No
            Readonly: No
            Backing store type: rdwr
            Backing store path: /dev/sdb
            Backing store flags: 
    Account information:
    ACL information:

Vérifiez que le port 3260 est bien ouvert et en état d'écoute :

[root@san ~]# netstat -apn | grep 3260
tcp        0      0 0.0.0.0:3260                0.0.0.0:*                   LISTEN      1844/tgtd           
tcp        0      0 :::3260                     :::*                        LISTEN      1844/tgtd

Configurez le serveur pour que tous les clients puissent y avoir accès :

[root@san ~]# tgtadm --lld iscsi --op bind --mode target --tid 1 -I ALL

Constatez la modification de la section ACL :

[root@san ~]# tgtadm --lld iscsi --op show --mode target
Target 1: target
    System information:
        Driver: iscsi
        State: ready
    I_T nexus information:
    LUN information:
        LUN: 0
            Type: controller
            SCSI ID: IET     00010000
            SCSI SN: beaf10
            Size: 0 MB, Block size: 1
            Online: Yes
            Removable media: No
            Prevent removal: No
            Readonly: No
            Backing store type: null
            Backing store path: None
            Backing store flags: 
        LUN: 1
            Type: disk
            SCSI ID: IET     00010001
            SCSI SN: beaf11
            Size: 537 MB, Block size: 512
            Online: Yes
            Removable media: No
            Prevent removal: No
            Readonly: No
            Backing store type: rdwr
            Backing store path: /dev/sdb
            Backing store flags: 
    Account information:
    ACL information:
        ALL

Important - Notez la présence de la ligne ACL information: ALL.

Dernièrement configurez LUN1 en mode r/w :

[root@san ~]# tgtadm --lld iscsi --mode logicalunit --op update --tid 1 --lun 1 --params readonly=0

Vérifiez votre configuration :

[root@san ~]# tgtadm --lld iscsi --op show --mode target
Target 1: target
    System information:
        Driver: iscsi
        State: ready
    I_T nexus information:
    LUN information:
        LUN: 0
            Type: controller
            SCSI ID: IET     00010000
            SCSI SN: beaf10
            Size: 0 MB, Block size: 1
            Online: Yes
            Removable media: No
            Prevent removal: No
            Readonly: No
            Backing store type: null
            Backing store path: None
            Backing store flags: 
        LUN: 1
            Type: disk
            SCSI ID: IET     00010001
            SCSI SN: beaf11
            Size: 537 MB, Block size: 512
            Online: Yes
            Removable media: No
            Prevent removal: No
            Readonly: No
            Backing store type: rdwr
            Backing store path: /dev/sdb
            Backing store flags: 
    Account information:
    ACL information:
        ALL

Important - Notez la présence de la ligne Readonly: No.

Pour rendre la configuration persistante re-créez le fichier /etc/tgt/targets.conf :

[root@san ~]# mv /etc/tgt/targets.conf /etc/tgt/targets.old
[root@san ~]# tgt-admin --dump > /etc/tgt/targets.conf
[root@san ~]# cat /etc/tgt/targets.conf 
default-driver iscsi

<target target>
	backing-store /dev/sdb
</target>

Démarrez les machines virtuelles node100, node200 et node300.

Pour accéder à notre cible ISCSI, le client doit disposer d'un initiateur. Installez donc le paquet iscsi-initiator-utils :

[root@node1 ~]# yum install iscsi-initiator-utils
[root@node2 ~]# yum install iscsi-initiator-utils
[root@node3 ~]# yum install iscsi-initiator-utils

Lancez maintenant la découverte des cibles sur le serveur iscsi san :

[root@node1 ~]# iscsiadm --mode discovery --type sendtargets --portal 10.0.3.18
Démarrage de iscsid :                                      [  OK  ]
10.0.3.18:3260,1 target
[root@node2 ~]# iscsiadm --mode discovery --type sendtargets --portal 10.0.3.18
Démarrage de iscsid :                                      [  OK  ]
10.0.3.18:3260,1 target
[root@node3 ~]# iscsiadm --mode discovery --type sendtargets --portal 10.0.3.18
Démarrage de iscsid :                                      [  OK  ]
10.0.3.18:3260,1 target

Connectez-vous à la cible à partir de chaque noeud :

[root@node1 ~]# iscsiadm --mode node --targetname target --login
Logging in to [iface: default, target: target, portal: 10.0.3.18,3260] (multiple)
Login to [iface: default, target: target, portal: 10.0.3.18,3260] successful.
[root@node2 ~]# iscsiadm --mode node --targetname target --login
Logging in to [iface: default, target: target, portal: 10.0.3.18,3260] (multiple)
Login to [iface: default, target: target, portal: 10.0.3.18,3260] successful.
[root@node3 ~]# iscsiadm --mode node --targetname target --login
Logging in to [iface: default, target: target, portal: 10.0.3.18,3260] (multiple)
Login to [iface: default, target: target, portal: 10.0.3.18,3260] successful.

Modifiez la directive locking_type dans le fichier /etc/lvm/lvm.conf sur chaque noeud :

...
    # Type of locking to use. Defaults to local file-based locking (1).
    # Turn locking off by setting to 0 (dangerous: risks metadata corruption
    # if LVM2 commands get run concurrently).
    # Type 2 uses the external shared library locking_library.
    # Type 3 uses built-in clustered locking.
    # Type 4 uses read-only locking which forbids any operations that might
    # change metadata.
    locking_type = 3
...

A partir de node1, créez un volume logique sur la cible iscsi :

[root@node1 ~]# pvcreate /dev/sdb
  Physical volume "/dev/sdb" successfully created

[root@node1 ~]# vgcreate -cy vg0 /dev/sdb
  Clustered volume group "vg0" successfully created
 
[root@node1 ~]# lvcreate -L 240 -n lv0 vg0
  Logical volume "lv0" created

Vérifiez que le service clvmd sur chaque noeud voit le volume logique :

[root@node1 ~]# service clvmd status
clvmd (pid  4047) en cours d'exécution...
Clustered Volume Groups: vg0
Active clustered Logical Volumes: lv0

[root@node2 ~]# service clvmd status
clvmd (pid  1898) en cours d'exécution...
Clustered Volume Groups: vg0
Active clustered Logical Volumes: lv0

[root@node3 ~]# service clvmd status
clvmd (pid  2003) en cours d'exécution...
Clustered Volume Groups: vg0
Active clustered Logical Volumes: lv0

Vérifiez ensuite que la volume logique est visible à partir de tous les noeuds :

[root@node1 ~]# vgs
  VG   #PV #LV #SN Attr   VSize   VFree  
  vg0    1   2   0 wz--nc 508,00m 256,00m
[root@node1 ~]# lvs
  LV   VG   Attr       LSize   Pool Origin Data%  Move Log Cpy%Sync Convert
  lv0  vg0  -wi-a----- 240,00m                                                                                        
[root@node1 ~]# 

[root@node2 ~]# vgs
  VG   #PV #LV #SN Attr   VSize   VFree  
  vg0    1   2   0 wz--nc 508,00m 256,00m
[root@node2 ~]# lvs
  LV   VG   Attr      LSize   Pool Origin Data%  Move Log Cpy%Sync Convert
  lv0  vg0  -wi-a---- 240,00m                                              
[root@node2 ~]#

[root@node3 ~]# vgs
  VG   #PV #LV #SN Attr   VSize   VFree  
  vg0    1   2   0 wz--nc 508,00m 256,00m
[root@node3 ~]# lvs
  LV   VG   Attr      LSize   Pool Origin Data%  Move Log Cpy%Sync Convert
  lv0  vg0  -wi-a---- 240,00m                                             
[root@node3 ~]#  

Important - Notez l'attribut c dans la sortie de la commande vgs. Ceci implique que la vg est clusterisé.

Notez que lors de la création du système de fichiers gfs2 en utilisant les paramètres par défaut celle-ci renvoie une erreur Not enough space available on device. Cette erreur est causée par le fait que la taille par défaut des trois journaux est supérieur à la taille de pseudo-iscsi :

[root@node1 ~]# mkfs.gfs2 -p lock_dlm -t moncluster:mydata -j 3 /dev/mapper/vg0-lv0
This will destroy any data on /dev/mapper/vg0-lv0.
It appears to contain: symbolic link to `../dm-0'

Are you sure you want to proceed? [y/n] y

Not enough space available on device

Créez donc un système de fichiers gfs2 ayant 3 journaux de 32Mo chacun :

[root@node1 ~]# mkfs.gfs2 -p lock_dlm -t moncluster:mydata -j 3 -J 32 /dev/vg0/lv0
This will destroy any data on /dev/vg0/lv0.
It appears to contain: symbolic link to `../dm-0'

Are you sure you want to proceed? [y/n] y

Device:                    /dev/vg0/lv0
Blocksize:                 4096
Device Size                0,23 GB (61440 blocks)
Filesystem Size:           0,23 GB (61437 blocks)
Journals:                  3
Resource Groups:           1
Locking Protocol:          "lock_dlm"
Lock Table:                "moncluster:mydata"
UUID:                      c0f648d8-66f3-c1bc-d7b6-953693931de8

Montez ensuite le volume logique dans chaque noeud :

[root@node1 ~]# mkdir /mydata
[root@node1 ~]# mount -t gfs2 -o acl,noatime /dev/mapper/vg0-lv0 /mydata

[root@node2 ~]# mkdir /mydata
[root@node2 ~]# mount -t gfs2 -o acl,noatime /dev/mapper/vg0-lv0 /mydata

[root@node3 ~]# mkdir /mydata
[root@node3 ~]# mount -t gfs2 -o acl,noatime /dev/mapper/vg0-lv0 /mydata

Testez maintenant le système de fichiers gfs2 en créant un fichier à partir de node01 :

[root@node1 ~]# touch /mydata/node1_test

Visualisez ce fichier à partir de node2 et node3 :

[root@node2 ~]# ls /mydata
node1_test

[root@node3 ~]# ls /mydata
node1_test

Lancez la commande suivante sur node1 :

[root@node1 ~]# vi /mydata/node1_test

Lancez la même commande sur node2 :

[root@node2 ~]# vi /mydata/node1_test

Notez que vous obtenez un message similaire au massage suivant sur node2 :

E325: ATTENTION
Found a swap file by the name "/mydata/.node1_test.swp"
          owned by: root   dated: Sun May 25 10:11:38 2014
         file name: /mydata/node1_test
          modified: no
         user name: root   host name: node1.fenestros.loc
        process ID: 4587
While opening file "/mydata/node1_test"
             dated: Sun May 25 10:11:05 2014

(1) Another program may be editing the same file.
    If this is the case, be careful not to end up with two
    different instances of the same file when making changes.
    Quit, or continue with caution.

(2) An edit session for this file crashed.
    If this is the case, use ":recover" or "vim -r /mydata/node1_test"
    to recover the changes (see ":help recovery").
    If you did this already, delete the swap file "/mydata/.node1_test.swp"
    to avoid this message.
"/mydata/node1_test" 0L, 0C
Press ENTER or type command to continue

Activez le service gfs2 :

[root@node1 ~]# chkconfig --levels 345 gfs2 on
[root@node1 ~]# chkconfig | grep gfs2
gfs2           	0:arrêt	1:arrêt	2:arrêt	3:marche	4:marche	5:marche	6:arrêt

[root@node2 ~]# chkconfig --levels 345 gfs2 on
[root@node2 ~]# chkconfig | grep gfs2
gfs2           	0:arrêt	1:arrêt	2:arrêt	3:marche	4:marche	5:marche	6:arrêt

[root@node3 ~]# chkconfig --levels 345 gfs2 on
[root@node3 ~]# chkconfig | grep gfs2
gfs2           	0:arrêt	1:arrêt	2:arrêt	3:marche	4:marche	5:marche	6:arrêt

Dernièrement, modifiez le fichier /etc/fstab sur chaque noeud :

/etc/fstab
#
# /etc/fstab
# Created by anaconda on Fri May  3 13:33:42 2013
#
# Accessible filesystems, by reference, are maintained under '/dev/disk'
# See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info
#
UUID=b9f29672-c84e-4d3b-b132-189758a084eb /                       ext4    defaults        1 1
UUID=01baf03d-df0d-479b-b3e4-81ce63b8dec3 /boot                   ext4    defaults        1 2
UUID=2646a33a-65f3-4501-9ced-9459435fd774 swap                    swap    defaults        0 0
tmpfs                   /dev/shm                tmpfs   defaults        0 0
devpts                  /dev/pts                devpts  gid=5,mode=620  0 0
sysfs                   /sys                    sysfs   defaults        0 0
/dev/mapper/vg0-lv0     /mydata                 gfs2    noatime,acl     0 0
proc                    /proc                   proc    defaults        0 0

LAB #31 - Utilisation d'un Disque Quorum

Arrêtez la machine virtuelle san. Attachez un disque supplémentaire appelé sdc d'une taille de 11 Mo au controleur SATA de la nouvelle machine virtuelle san. Démarrez la machine virtuelle san.

Dans la machine virtuelle san ajoutez le disque /dev/sdc au deuxième LUN :

[root@san ~]# tgtadm --lld iscsi --op new --mode logicalunit --tid 1 --lun 2 -b /dev/sdc

Consultez la configuration :

[root@san ~]# tgtadm --lld iscsi --op show --mode target
Target 1: target
    System information:
        Driver: iscsi
        State: ready
    I_T nexus information:
    LUN information:
        LUN: 0
            Type: controller
            SCSI ID: IET     00010000
            SCSI SN: beaf10
            Size: 0 MB, Block size: 1
            Online: Yes
            Removable media: No
            Prevent removal: No
            Readonly: No
            Backing store type: null
            Backing store path: None
            Backing store flags: 
        LUN: 1
            Type: disk
            SCSI ID: IET     00010001
            SCSI SN: beaf11
            Size: 537 MB, Block size: 512
            Online: Yes
            Removable media: No
            Prevent removal: No
            Readonly: No
            Backing store type: rdwr
            Backing store path: /dev/sdb
            Backing store flags: 
        LUN: 2
            Type: disk
            SCSI ID: IET     00010002
            SCSI SN: beaf12
            Size: 12 MB, Block size: 512
            Online: Yes
            Removable media: No
            Prevent removal: No
            Readonly: No
            Backing store type: rdwr
            Backing store path: /dev/sdc
            Backing store flags: 
    Account information:
    ACL information:
        ALL

Vérifiez que le cluster est en état de fonctionnement sur les noeuds :

[root@node1 ~]# clustat
Cluster Status for moncluster @ Mon May 26 11:50:24 2014
Member Status: Quorate

 Member Name                                                     ID   Status
 ------ ----                                                     ---- ------
 node1.fenestros.loc                                                 1 Online, Local, rgmanager
 node2.fenestros.loc                                                 2 Online, rgmanager
 node3.fenestros.loc                                                 3 Online, rgmanager

 Service Name                                                     Owner (Last)                                                     State         
 ------- ----                                                     ----- ------                                                     -----         
 service:ip_address                                               (none)                                                           disabled      

Déconnectez-vous et re-connectez-vous au SAN à partir de chaque noeud :

[root@node1 ~]# iscsiadm --mode node --targetname target --logout
[root@node1 ~]# iscsiadm --mode node --targetname target --login
[root@node2 ~]# iscsiadm --mode node --targetname target --logout
[root@node2 ~]# iscsiadm --mode node --targetname target --login
[root@node3 ~]# iscsiadm --mode node --targetname target --logout
[root@node3 ~]# iscsiadm --mode node --targetname target --login

Vérifiez la présence du disque sdc sur chaque noeud :

[root@node1 ~]# cat /proc/partitions
major minor  #blocks  name

   8        0   20971520 sda
   8        1     102400 sda1
   8        2    5120000 sda2
   8        3    2048000 sda3
   8       16     524288 sdb
   8       32      11264 sdc
 253        0     245760 dm-0
[root@node2 ~]# cat /proc/partitions
major minor  #blocks  name

   8        0   20971520 sda
   8        1     102400 sda1
   8        2    5120000 sda2
   8        3    2048000 sda3
   8       16     524288 sdb
   8       32      11264 sdc
 253        0     245760 dm-0
[root@node3 ~]# cat /proc/partitions
major minor  #blocks  name

   8        0   20971520 sda
   8        1     102400 sda1
   8        2    5120000 sda2
   8        3    2048000 sda3
   8       16     524288 sdb
   8       32      11264 sdc
 253        0     245760 dm-0

Préparez maintenant le Disque Quorum sur /dev/sdc grâce à la commande mkqdisk :

[root@node1 ~]# mkqdisk -c /dev/sdc -l qdisk
mkqdisk v3.0.12.1

Writing new quorum disk label 'qdisk' to /dev/sdc.
WARNING: About to destroy all data on /dev/sdc; proceed [N/y] ? y
Initializing status block for node 1...
Initializing status block for node 2...
Initializing status block for node 3...
Initializing status block for node 4...
Initializing status block for node 5...
Initializing status block for node 6...
Initializing status block for node 7...
Initializing status block for node 8...
Initializing status block for node 9...
Initializing status block for node 10...
Initializing status block for node 11...
Initializing status block for node 12...
Initializing status block for node 13...
Initializing status block for node 14...
Initializing status block for node 15...
Initializing status block for node 16...

Important - Notez la présence de status blocks pour les 16 neouds. L'option -l indique le label (étiquette) associé au disque.

Il n'y a pas de filesystem classique sur le Disque Quorum :

[root@node1 ~]# file -sL /dev/sda
/dev/sda: x86 boot sector; GRand Unified Bootloader, stage1 version 0x3, boot drive 0x80, 1st sector stage2 0x76ea, GRUB version 0.94; partition 1: ID=0x83, active, starthead 32, startsector 2048, 204800 sectors; partition 2: ID=0x83, starthead 223, startsector 206848, 10240000 sectors; partition 3: ID=0x82, starthead 72, startsector 10446848, 4096000 sectors, code offset 0x48
[root@node1 ~]# file -sL /dev/sda1
/dev/sda1: Linux rev 1.0 ext4 filesystem data (needs journal recovery) (extents) (huge files)
[root@node1 ~]# file -sL /dev/sdc
/dev/sdc: data
[root@node1 ~]# file -sL /dev/sdc1
/dev/sdc1: cannot open `/dev/sdc1' (No such file or directory)

Visualisez le Disque Quorum sur les trois noeuds :

[root@node1 ~]# mkqdisk -L
mkqdisk v3.0.12.1

/dev/block/8:32:
/dev/disk/by-id/scsi-1IET_00010002:
/dev/disk/by-path/ip-10.0.3.18:3260-iscsi-target-lun-2:
/dev/sdc:
	Magic:                eb7a62c2
	Label:                qdisk
	Created:              Mon May 26 11:54:21 2014
	Host:                 node1.fenestros.loc
	Kernel Sector Size:   512
	Recorded Sector Size: 512
[root@node2 ~]# mkqdisk -L
mkqdisk v3.0.12.1

/dev/block/8:32:
/dev/disk/by-id/scsi-1IET_00010002:
/dev/disk/by-path/ip-10.0.3.18:3260-iscsi-target-lun-2:
/dev/sdc:
	Magic:                eb7a62c2
	Label:                qdisk
	Created:              Mon May 26 11:54:21 2014
	Host:                 node1.fenestros.loc
	Kernel Sector Size:   512
	Recorded Sector Size: 512
[root@node3 ~]# mkqdisk -L
mkqdisk v3.0.12.1

/dev/block/8:32:
/dev/disk/by-id/scsi-1IET_00010002:
/dev/disk/by-path/ip-10.0.3.18:3260-iscsi-target-lun-2:
/dev/sdc:
	Magic:                eb7a62c2
	Label:                qdisk
	Created:              Mon May 26 11:54:21 2014
	Host:                 node1.fenestros.loc
	Kernel Sector Size:   512
	Recorded Sector Size: 512

Il est déconseillé d'utiliser un volume logique clusterisé pour le Disque Quorum. La raison est simple : pour qur le quorum soit effectif, le Disque Quorum doit être visible. Or pour que le Disque Quorum soit visible, le service clvmd doit démarrer. Sachant que le service clvmd dépende du service cman ce dernier s'arrête.

Modifiez maintenant le fichier /etc/cluster/cluster.conf sur node1.fenestros.loc en ajoutant les deux lignes suivantes :

...
        <totem token="135000"/>
	<cman expected_votes="5"/>
        <quorumd interval="3" label="qdisk" tko="23" votes="2"/>
...

La première ligne indique le timeout pour cman est de 135 seconds :

  • soit 1,5 fois le timeout de qdisk,
  • ceci implique que si le qdisk défaillant se trouve sur le maître, dans ce cas node1.fenestros.loc, cman donnera une instruction au démon fenced de redémarrer le noeud.

La deuxième ligne porte à la connaissance de cman le nombre de votes attendues, soit 5 - 1 pour chaque noeud et 2 pour le Disque Quorum.

La troisième ligne configure le Disque Quorum :

  • interval indique que qdiskd va vérifier tous les 3 secondes,
  • tko (Technical Knock Out) indique que qdiskd permettra 23 tentatives en échec avant de réagir, soit 3*23=69 secondes,
  • label identifie le Disque Quorum,
  • votes fixe le nombre de votes pour le Disque Quorum lui-même.

Important - Dans cette configuration, si le service qdiskd sur un noeud n'a pas mis à jour ses informations d'état à l'issu de 69 secondes, un autre qdiskd va demander qu'il soit fenced.

Vous obtiendrez donc :

/etc/cluster/cluster.conf
<?xml version="1.0"?>
<cluster config_version="12" name="moncluster">
        <totem token="135000"/>
	<cman expected_votes="5"/>
        <quorumd interval="3" label="qdisk" tko="23" votes="2"/>
	<fence_daemon post_fail_delay="5" post_join_delay="25"/>
	<clusternodes>
		<clusternode name="node1.fenestros.loc" nodeid="1" votes="1">
			<fence>
				<method name="APC1">
					<device name="APC1" port="1"/>
				</method>
			</fence>
		</clusternode>
		<clusternode name="node2.fenestros.loc" nodeid="2" votes="1"/>
		<clusternode name="node3.fenestros.loc" nodeid="3" votes="1"/>
	</clusternodes>
	<fencedevices>
		<fencedevice agent="fence_apc" ipaddr="10.0.3.50" login="root" name="APC1" passwd="password"/>
		<fencedevice agent="fence_apc" ipaddr="10.0.3.51" login="root" name="APC2" passwd="password"/>
	</fencedevices>
	<rm>
		<failoverdomains>
			<failoverdomain name="Failover1" nofailback="0" ordered="1" restricted="0">
				<failoverdomainnode name="node1.fenestros.loc" priority="1"/>
				<failoverdomainnode name="node2.fenestros.loc" priority="2"/>
			</failoverdomain>
		</failoverdomains>
		<resources>
			<ip address="10.0.3.100/24" monitor_link="yes" sleeptime="10"/>
		</resources>
		<service autostart="0" domain="Failover1" exclusive="0" name="ip_address" recovery="relocate">
			<ip address="10.0.3.100/24" monitor_link="yes" sleeptime="10"/>
		</service>
	</rm>
</cluster>

Validez le fichier sur le schéma du cluster (/usr/share/cluster/cluster.rng) :

[root@node1 ~]# ccs_config_validate 
Configuration validates

Utilisez la commande cman_tool version -r pour propager le fichier de configuration :

[root@node1 ~]# cman_tool version -r 

Constatez maintenant l'état du cluster :

[root@node1 ~]# cman_tool status
Version: 6.2.0
Config Version: 12
Cluster Name: moncluster
Cluster Id: 59006
Cluster Member: Yes
Cluster Generation: 688
Membership state: Cluster-Member
Nodes: 3
Expected votes: 3
Total votes: 3
Node votes: 1
Quorum: 2  
Active subsystems: 9
Flags: 
Ports Bound: 0 11 177  
Node name: node1.fenestros.loc
Node ID: 1
Multicast addresses: 239.192.230.101 
Node addresses: 10.0.3.15 

Créez le script /root/cluster.sh sur chaque noeud :

/root/cluster.sh
#!/bin/sh
for i in ricci rgmanager gfs2 clvmd cman ; do
      service $i stop
done
for i in cman clvmd gfs2 rgmanager ricci ; do
      service $i start
done
[root@node1 ~]# vi /root/cluster.sh
[root@node1 ~]# chmod u+x /root/cluster.sh 

[root@node2 ~]# vi /root/cluster.sh
[root@node2 ~]# chmod u+x /root/cluster.sh 

[root@node3 ~]# vi /root/cluster.sh
[root@node3 ~]# chmod u+x /root/cluster.sh 

Exécutez le script sur chaque neoud en même temps :

<coe> [root@node1 ~]# ./cluster.sh

[root@node2 ~]# ./cluster.sh

[root@node3 ~]# ./cluster.sh </code>

Sur chaque noeud, vous devez voir une sortie similaire à celle-ci :

[root@node1 ~]# ./cluster.sh
Shutting down ricci:                                       [  OK  ]
Stopping Cluster Service Manager:                          [  OK  ]
Unmounting GFS2 filesystem (/mydata):                      [  OK  ]
Deactivating clustered VG(s):   0 logical volume(s) in volume group "vg0" now active
  clvmd not running on node node3.fenestros.loc
                                                           [  OK  ]
Signaling clvmd to exit                                    [  OK  ]
clvmd terminated                                           [  OK  ]
Stopping cluster: 
   Leaving fence domain...                                 [  OK  ]
   Stopping gfs_controld...                                [  OK  ]
   Stopping dlm_controld...                                [  OK  ]
   Stopping fenced...                                      [  OK  ]
   Stopping qdiskd...                                      [  OK  ]
   Stopping cman...                                        [  OK  ]
   Waiting for corosync to shutdown:                       [  OK  ]
   Unloading kernel modules...                             [  OK  ]
   Unmounting configfs...                                  [  OK  ]
Starting cluster: 
   Checking if cluster has been disabled at boot...        [  OK  ]
   Checking Network Manager...                             [  OK  ]
   Global setup...                                         [  OK  ]
   Loading kernel modules...                               [  OK  ]
   Mounting configfs...                                    [  OK  ]
   Starting cman...                                        [  OK  ]
   Starting qdiskd...                                      [  OK  ]
   Waiting for quorum...                                   [  OK  ]
   Starting fenced...                                      [  OK  ]
   Starting dlm_controld...                                [  OK  ]
   Tuning DLM kernel config...                             [  OK  ]
   Starting gfs_controld...                                [  OK  ]
   Unfencing self...                                       [  OK  ]
   Joining fence domain...                                 [  OK  ]
Starting clvmd: 
Activating VG(s):   1 logical volume(s) in volume group "vg0" now active
                                                           [  OK  ]
Mounting GFS2 filesystem (/mydata):                        [  OK  ]
Starting Cluster Service Manager:                          [  OK  ]
Démarrage de ricci :                                       [  OK  ]
[root@node2 ~]# ./cluster.sh
Shutting down ricci:                                       [  OK  ]
Stopping Cluster Service Manager:                          [  OK  ]
Unmounting GFS2 filesystem (/mydata):                      [  OK  ]
Deactivating clustered VG(s):   0 logical volume(s) in volume group "vg0" now active
  clvmd not running on node node3.fenestros.loc
                                                           [  OK  ]
Signaling clvmd to exit                                    [  OK  ]
clvmd terminated                                           [  OK  ]
Stopping cluster: 
   Leaving fence domain...                                 [  OK  ]
   Stopping gfs_controld...                                [  OK  ]
   Stopping dlm_controld...                                [  OK  ]
   Stopping fenced...                                      [  OK  ]
   Stopping qdiskd...                                      [  OK  ]
   Stopping cman...                                        [  OK  ]
   Waiting for corosync to shutdown:                       [  OK  ]
   Unloading kernel modules...                             [  OK  ]
   Unmounting configfs...                                  [  OK  ]
Starting cluster: 
   Checking if cluster has been disabled at boot...        [  OK  ]
   Checking Network Manager...                             [  OK  ]
   Global setup...                                         [  OK  ]
   Loading kernel modules...                               [  OK  ]
   Mounting configfs...                                    [  OK  ]
   Starting cman...                                        [  OK  ]
   Starting qdiskd...                                      [  OK  ]
   Waiting for quorum...                                   [  OK  ]
   Starting fenced...                                      [  OK  ]
   Starting dlm_controld...                                [  OK  ]
   Tuning DLM kernel config...                             [  OK  ]
   Starting gfs_controld...                                [  OK  ]
   Unfencing self...                                       [  OK  ]
   Joining fence domain...                                 [  OK  ]
Starting clvmd: 
Activating VG(s):   1 logical volume(s) in volume group "vg0" now active
                                                           [  OK  ]
Mounting GFS2 filesystem (/mydata):                        [  OK  ]
Starting Cluster Service Manager:                          [  OK  ]
Démarrage de ricci :                                       [  OK  ]
[root@node3 ~]# ./cluster.sh
Shutting down ricci:                                       [  OK  ]
Stopping Cluster Service Manager:                          [  OK  ]
Unmounting GFS2 filesystem (/mydata):                      [  OK  ]
Deactivating clustered VG(s):   0 logical volume(s) in volume group "vg0" now active
                                                           [  OK  ]
Signaling clvmd to exit                                    [  OK  ]
clvmd terminated                                           [  OK  ]
Stopping cluster: 
   Leaving fence domain...                                 [  OK  ]
   Stopping gfs_controld...                                [  OK  ]
   Stopping dlm_controld...                                [  OK  ]
   Stopping fenced...                                      [  OK  ]
   Stopping qdiskd...                                      [  OK  ]
   Stopping cman...                                        [  OK  ]
   Waiting for corosync to shutdown:                       [  OK  ]
   Unloading kernel modules...                             [  OK  ]
   Unmounting configfs...                                  [  OK  ]
Starting cluster: 
   Checking if cluster has been disabled at boot...        [  OK  ]
   Checking Network Manager...                             [  OK  ]
   Global setup...                                         [  OK  ]
   Loading kernel modules...                               [  OK  ]
   Mounting configfs...                                    [  OK  ]
   Starting cman...                                        [  OK  ]
   Starting qdiskd...                                      [  OK  ]
   Waiting for quorum...                                   [  OK  ]
   Starting fenced...                                      [  OK  ]
   Starting dlm_controld...                                [  OK  ]
   Tuning DLM kernel config...                             [  OK  ]
   Starting gfs_controld...                                [  OK  ]
   Unfencing self...                                       [  OK  ]
   Joining fence domain...                                 [  OK  ]
Starting clvmd: 
Activating VG(s):   1 logical volume(s) in volume group "vg0" now active
                                                           [  OK  ]
Mounting GFS2 filesystem (/mydata):                        [  OK  ]
Starting Cluster Service Manager:                          [  OK  ]
Démarrage de ricci :                                       [  OK  ]

Constatez maintenant l'état du cluster :

[root@node1 ~]# cman_tool status
Version: 6.2.0
Config Version: 12
Cluster Name: moncluster
Cluster Id: 59006
Cluster Member: Yes
Cluster Generation: 752
Membership state: Cluster-Member
Nodes: 3
Expected votes: 5
Quorum device votes: 2
Total votes: 5
Node votes: 1
Quorum: 3  
Active subsystems: 11
Flags: 
Ports Bound: 0 11 177 178  
Node name: node1.fenestros.loc
Node ID: 1
Multicast addresses: 239.192.230.101 
Node addresses: 10.0.3.15 

Important - Notez la présence de la ligne Quorum device votes: 2.

Remettez en place le service ip_address et basculez-le sur node2.fenestros.loc :

[root@node1 ~]# clusvcadm -e ip_address
[root@node1 ~]# clusvcadm -r ip_address

Mettez en place maintenant une heuristique.

Important - Une heuristique est une règle qui définisse des conditions dans lesquelles le nœud doit être considéré comme n’appartenant plus au cluster.

Dans notre cas nous allons mettre en place une heuristique qui vérifie la connectivité du noeud au réseau. Cette règle prend la forme d'un ping à la passerelle.

Pour faire ceci, il convient de changer la ligne :

...
        <quorumd interval="3" label="qdisk" tko="23" votes="2"/>
...

en

...
	<quorumd interval="3" label="qdisk" tko="23" votes="2">
		<heuristic program="ping -c3 -t2 10.0.2.2"/>
	</quorumd>
...

Editez donc votre fichier /etc/cluster/cluster.conf :

/etc/cluster/cluster.conf
<?xml version="1.0"?>
<cluster config_version="13" name="moncluster">
	<totem token="135000"/>
	<cman expected_votes="5"/>
	<quorumd interval="3" label="qdisk" tko="23" votes="2">
		<heuristic program="ping -c3 -t2 10.0.2.2"/>
	</quorumd>
	<fence_daemon post_fail_delay="5" post_join_delay="25"/>
	<clusternodes>
		<clusternode name="node1.fenestros.loc" nodeid="1">
			<fence>
				<method name="APC1">
					<device name="APC1" port="1"/>
				</method>
			</fence>
		</clusternode>
		<clusternode name="node2.fenestros.loc" nodeid="2"/>
		<clusternode name="node3.fenestros.loc" nodeid="3"/>
	</clusternodes>
	<fencedevices>
		<fencedevice agent="fence_apc" ipaddr="10.0.3.50" login="root" name="APC1" passwd="password"/>
		<fencedevice agent="fence_apc" ipaddr="10.0.3.51" login="root" name="APC2" passwd="password"/>
	</fencedevices>
	<rm>
		<failoverdomains>
			<failoverdomain name="Failover1" ordered="1">
				<failoverdomainnode name="node1.fenestros.loc" priority="1"/>
				<failoverdomainnode name="node2.fenestros.loc" priority="2"/>
			</failoverdomain>
		</failoverdomains>
		<resources>
			<ip address="10.0.3.100/24" monitor_link="yes" sleeptime="10"/>
		</resources>
		<service autostart="0" domain="Failover1" name="ip_address" recovery="relocate">
			<ip address="10.0.3.100/24" monitor_link="yes" sleeptime="10"/>
		</service>
	</rm>
</cluster>

Important - Cette modification peut également être faite en utilisant luci via les onglets Configure puis qdisk.

Propagez votre fichier de configuration aux autres neouds et ré-exécutez le script /root/cluster.sh sur chaque neoud.

Sur la machine virtuelle node2.fenestros.loc, arrêtez le réseau :

[root@node2 ~]# service network stop
Arrêt de l'interface bond0 :                               [  OK  ]
Arrêt de l'interface eth0 :                                [  OK  ]
Arrêt de l'interface loopback :                            [  OK  ]

Consultez le journal /var/log/messages sur la machine virtuelle node1.fenestros.loc :

...
May 26 15:10:49 node1 qdiskd[15144]: Writing eviction notice for node 2
May 26 15:10:52 node1 qdiskd[15144]: Node 2 evicted
May 26 15:14:00 node1 corosync[15094]:   [QUORUM] Members[2]: 1 3
May 26 15:14:00 node1 rgmanager[15608]: State change: node2.fenestros.loc DOWN
May 26 15:14:00 node1 corosync[15094]:   [TOTEM ] A processor joined or left the membership and a new membership was formed.
May 26 15:14:00 node1 corosync[15094]:   [CPG   ] chosen downlist: sender r(0) ip(10.0.3.15) ; members(old:3 left:1)
May 26 15:14:00 node1 corosync[15094]:   [MAIN  ] Completed service synchronization, ready to provide service.
May 26 15:14:01 node1 kernel: dlm: closing connection to node 2
May 26 15:14:01 node1 rgmanager[15608]: Taking over service service:ip_address from down member node2.fenestros.loc
May 26 15:14:01 node1 kernel: GFS2: fsid=moncluster:mydata.1: jid=0: Trying to acquire journal lock...
May 26 15:14:06 node1 fenced[15360]: fencing node node2.fenestros.loc
May 26 15:14:06 node1 fenced[15360]: fence node2.fenestros.loc dev 0.0 agent none result: error no method
May 26 15:14:06 node1 fenced[15360]: fence node2.fenestros.loc failed
May 26 15:14:09 node1 fenced[15360]: fencing node node2.fenestros.loc
May 26 15:14:09 node1 fenced[15360]: fence node2.fenestros.loc dev 0.0 agent none result: error no method
May 26 15:14:09 node1 fenced[15360]: fence node2.fenestros.loc failed
May 26 15:14:12 node1 fenced[15360]: fencing node node2.fenestros.loc
May 26 15:14:12 node1 fenced[15360]: fence node2.fenestros.loc dev 0.0 agent none result: error no method
May 26 15:14:12 node1 fenced[15360]: fence node2.fenestros.loc failed
...

Important - Notez que qdiskd enlève node2.fenestros.loc du cluster. Le service rgmanager prend possession du service ip_address. Constatez la tentative de fencing qui n'aboutit pas parce que le périphérique fence n'existe pas réellement. Notez donc que le service ip_address ne bascule pas sur node1.fenestros.loc car un pré-requis du basculement est que node2.fenestros.loc soit fenced.

Arrêtez maintenant le service réseau sur node3.fenestros.loc :

[root@node3 ~]# service network stop
Arrêt de l'interface bond0 :                               [  OK  ]
Arrêt de l'interface eth0 :                                [  OK  ]
Arrêt de l'interface loopback :                            [  OK  ]

Consultez ensuite l'état du cluster à partir du node1.fenestros.loc :

[root@node1 ~]# clustat
Service states unavailable: Temporary failure; try again
Cluster Status for moncluster @ Mon May 26 15:31:52 2014
Member Status: Quorate

 Member Name                                                     ID   Status
 ------ ----                                                     ---- ------
 node1.fenestros.loc                                                 1 Online, Local
 node2.fenestros.loc                                                 2 Offline
 node3.fenestros.loc                                                 3 Offline
 /dev/block/8:32                                                     0 Online, Quorum Disk 

Important - Notez que le cluster est toujours actif grâce au Disque Quorum.

Red Hat High Availability Cluster sous CentOS 7

Red Hat High Availability Cluster versus Red Hat Cluster Suite

Dans la version Red Hat High Availability Cluster :

  • pcs remplace luci,
  • keepalivedremplace Pirahna. Keepalived est configuré dans le fichier /etc/keepalived/keepalived.conf - voir man keepalived.conf,
  • rgmanager et cman sont remplacés par pacemaker et corosync. Cette modification introduit des agents de ressource qui fonctionnent avec le gestionnaire de ressources Pacemaker,
  • votequorum remplace qdiskd - voir man 5 votequorum.

Installer le Logiciel du Module Red Hat High Availability

L'installation de Red Hat High Availability se fait simplement en utilisant yum :

[root@centos7 ~]# yum install pcs pacemaker fence-agents-all

Firewalld

RHEL/CentOS 7 utilisent firewalld :

[root@centos7 ~]# firewall-cmd --state
running

De ce fait, il convient de créer les règles adéquates pour la haute disponibilité :

[root@centos7 ~]# firewall-cmd --permanent --add-service=high-availability
success
[root@centos7 ~]# firewall-cmd --add-service=high-availability
success

hacluster

L'utilisateur hacluster est utilisé par pcs afin de configurer et communiquer avec chaque noeud dans le cluster. Cet utilisateur doit avoir un mot de passe :

[root@centos7 ~]# passwd hacluster
Changing password for user hacluster.
New password: fenestros
BAD PASSWORD: The password fails the dictionary check - it is based on a dictionary word
Retype new password: fenestros
passwd: all authentication tokens updated successfully.

Important - Il est recommendé à ce que le mot de passe de l'utilisateur hacluster soit identique sur chaque noeud. Dans le cas de notre exemple, le mot de passe est fenestros. Le mot de passe ci-dessus vous est montré dans le cadre de l'exemple. Dans le cas d'un système en production, le mot de passe ne sera pas visible et doit être autre que fenestros !

Démarrer le daemon pcsd

Sous RHEL/CentOS 7 , le daemon pcsd doit être démarré sur chaque noeud afin que les mises-à-jour de la configuration du cluster puissent être propagées aux autres noeuds.

Vérifiez si pcsd est démarré :

[root@centos7 ~]# systemctl status pcsd
● pcsd.service - PCS GUI and remote configuration interface
   Loaded: loaded (/usr/lib/systemd/system/pcsd.service; disabled; vendor preset: disabled)
   Active: inactive (dead)
     Docs: man:pcsd(8)
           man:pcs(8)
You have new mail in /var/spool/mail/root

Démarrez pcsd puis configurez-le pour un démarrage automatique :

[root@centos7 ~]# systemctl start pcsd.service
[root@centos7 ~]# systemctl enable pcsd.service
Created symlink from /etc/systemd/system/multi-user.target.wants/pcsd.service to /usr/lib/systemd/system/pcsd.service.
[root@centos7 ~]# systemctl status pcsd
● pcsd.service - PCS GUI and remote configuration interface
   Loaded: loaded (/usr/lib/systemd/system/pcsd.service; enabled; vendor preset: disabled)
   Active: active (running) since Tue 2018-08-28 09:39:29 CEST; 11s ago
     Docs: man:pcsd(8)
           man:pcs(8)
 Main PID: 2520 (pcsd)
   CGroup: /system.slice/pcsd.service
           └─2520 /usr/bin/ruby /usr/lib/pcsd/pcsd > /dev/null &

Aug 28 09:39:22 centos7.fenestros.loc systemd[1]: Starting PCS GUI and remote configuration interface...
Aug 28 09:39:29 centos7.fenestros.loc systemd[1]: Started PCS GUI and remote configuration interface.

La configuration de pcsd se trouve dans le fichier /etc/sysconfig/pcsd :

[root@centos7 ~]# cat /etc/sysconfig/pcsd
# pcsd configuration file

# Set PCSD_DEBUG to true for advanced pcsd debugging information
PCSD_DEBUG=false
# Set DISABLE_GUI to true to disable GUI frontend in pcsd
PCSD_DISABLE_GUI=false
# Set web UI sesions lifetime in seconds
PCSD_SESSION_LIFETIME=3600
# List of IP addresses pcsd should bind to delimited by ',' character
#PCSD_BIND_ADDR='::'
# Set port on which pcsd should be available
#PCSD_PORT=2224

# SSL settings
# set SSL options delimited by ',' character
# list of valid options can be obtained by running
# ruby -e 'require "openssl"; puts OpenSSL::SSL.constants.grep /^OP_/'
#PCSD_SSL_OPTIONS='OP_NO_SSLv2,OP_NO_SSLv3,OP_NO_TLSv1,OP_NO_TLSv1_1'
# set SSL ciphers
#PCSD_SSL_CIPHERS='DEFAULT:!RC4:!3DES:@STRENGTH'

# Proxy settings for pcsd node to node communication
# See ENVIRONMENT section in curl(1) man page for more details.
# Proxy address
#HTTPS_PROXY=
# Do not use proxy for specified hostnames
#NO_PROXY=

# Do not change
RACK_ENV=production

Préparation des Machines Virtuelles

A partir de votre machine virtuelle CentOS, créez 2 clones complets et configurez-les ainsi :

Nom de la VM RAM
node1.i2tch.loc 512 Mo
node2.i2tch.loc 512 Mo

Important - Lors de la création des clones, veillez à réinitialiser l'adresse MAC de la carte réseau.

Modifiez la configuration réseau des deux clones :

Adaptateur Carte 1 Carte 2 Carte 3
Type de réseau NAT intnet intnet

Important - Dans Virtual Box > Paramètres de node2.i2tch.loc > Réseau > Carte 1 > Redirection de ports, Modifiez le port hôte ssh en 4022.

Démarrez les machines virtuelles node1.i2tch.loc et node2.i2tch.loc et modifiez les noms d'hôtes ainsi :

[root@centos7 ~]# nmcli general hostname node1.i2tch.loc
[root@centos7 ~]# hostname
node1.i2tch.loc
[root@centos7 ~]# nmcli general hostname node2.i2tch.loc
[root@centos7 ~]# hostname
node2.i2tch.loc

Important - Déconnectez-vous de et re-connectez-vous à chaque VM.

Vérifiez la configuration réseau sur chaque noeud :

[root@node1 ~]# ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: enp0s3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 08:00:27:69:d2:e8 brd ff:ff:ff:ff:ff:ff
    inet 10.0.2.15/24 brd 10.0.2.255 scope global dynamic enp0s3
       valid_lft 84419sec preferred_lft 84419sec
    inet6 fe80::c031:adb3:2f96:1705/64 scope link 
       valid_lft forever preferred_lft forever
3: enp0s8: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 08:00:27:69:b7:6f brd ff:ff:ff:ff:ff:ff
    inet6 fe80::9e75:d62:334c:162/64 scope link 
       valid_lft forever preferred_lft forever
4: enp0s9: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 08:00:27:1c:5d:3d brd ff:ff:ff:ff:ff:ff
    inet6 fe80::d7e2:3ad3:ef04:636d/64 scope link 
       valid_lft forever preferred_lft forever
[root@node2 ~]# ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: enp0s3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 08:00:27:10:90:fc brd ff:ff:ff:ff:ff:ff
    inet 10.0.2.15/24 brd 10.0.2.255 scope global dynamic enp0s3
       valid_lft 86366sec preferred_lft 86366sec
    inet6 fe80::2d4d:e50a:4f0e:65d3/64 scope link 
       valid_lft forever preferred_lft forever
3: enp0s8: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 08:00:27:16:89:9f brd ff:ff:ff:ff:ff:ff
    inet6 fe80::ecac:ad95:803e:976/64 scope link 
       valid_lft forever preferred_lft forever
4: enp0s9: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 08:00:27:73:0e:e6 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::a716:721e:e633:9598/64 scope link 
       valid_lft forever preferred_lft forever

Ethernet Channel Bonding

Le Channel Bonding est un regroupement d'interfaces réseau sur le même serveur afin de mettre en place la redondance ou d'augmenter les performances.

Le Channel Bonding est géré nativement sous Linux. Aucune application tierce n'est requise.

Configuration du node1.i2tch.loc

Assurez-vous que le module bonding soit chargé :

[root@node1 ~]# lsmod | grep bonding
[root@node1 ~]# modprobe bonding
[root@node1 ~]# lsmod | grep bonding
bonding               145728  0 

Consultez la configuration des interfaces réseaux :

[root@node1 ~]# nmcli c show
NAME                UUID                                  TYPE            DEVICE 
Wired connection 1  79fe874b-fef7-3522-aedb-98ec2da7c789  802-3-ethernet  enp0s3 
Wired connection 2  d5779aae-201a-30d2-9a15-cca7eccb07bc  802-3-ethernet  --     
Wired connection 3  600a91aa-0b32-3d0c-a4b5-29563e9f31ad  802-3-ethernet  -- 

Créez le fichier /etc/sysconfig/network-scripts/ifcfg-bond0 :

[root@node1 ~]# vi /etc/sysconfig/network-scripts/ifcfg-bond0
[root@node1 ~]# cat /etc/sysconfig/network-scripts/ifcfg-bond0
DEVICE=bond0
USERCTL=no
BOOTPROTO=none
ONBOOT=yes
IPADDR=10.0.3.15
NETMASK=255.255.255.0
NETWORK=10.0.3.0
BONDING_OPTS="miimon=100 mode=balance-xor"
TYPE=Unknown
IPV6INIT=no

Créez le fichier /etc/sysconfig/network-scripts/ifcfg-enp0s8 :

[root@node1 ~]# vi /etc/sysconfig/network-scripts/ifcfg-enp0s8
[root@node1 ~]# cat /etc/sysconfig/network-scripts/ifcfg-enp0s8
DEVICE=enp0s8
BOOTPROTO=none
ONBOOT=yes
MASTER=bond0
SLAVE=yes
USERCTL=no

Créez le fichier /etc/sysconfig/network-scripts/ifcfg-enp0s9 :

[root@node1 ~]# vi /etc/sysconfig/network-scripts/ifcfg-enp0s9
[root@node1 ~]# cat /etc/sysconfig/network-scripts/ifcfg-enp0s9
DEVICE=enp0s9
BOOTPROTO=none
ONBOOT=yes
MASTER=bond0
SLAVE=yes
USERCTL=no

Créez le fichier /etc/modprobe.d/bonding.conf :

[root@node1 ~]# vi /etc/modprobe.d/bonding.conf
[root@node1 ~]# cat /etc/modprobe.d/bonding.conf
alias bond0 bonding

Modifiez le fichier /etc/hosts :

[root@node1 ~]# vi /etc/hosts
[root@node1 ~]# cat /etc/hosts
127.0.0.1		localhost.localdomain localhost
::1		localhost6.localdomain6 localhost6
10.0.3.15	node1.i2tch.loc 	node1
10.0.3.16	node2.i2tch.loc		node2

Re-démarrez le service network :

[root@node1 ~]# systemctl restart network
[root@node1 ~]# nmcli c show
NAME                UUID                                  TYPE            DEVICE 
System enp0s8       00cb8299-feb9-55b6-a378-3fdc720e0bc6  802-3-ethernet  enp0s8 
System enp0s9       93d13955-e9e2-a6bd-df73-12e3c747f122  802-3-ethernet  enp0s9 
Wired connection 1  79fe874b-fef7-3522-aedb-98ec2da7c789  802-3-ethernet  enp0s3 
bond0               234cf049-1b53-43eb-9377-7113c0fa363e  bond            bond0  

Vérifiez la configuration du réseau :

[root@node1 ~]# ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: enp0s3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 08:00:27:69:d2:e8 brd ff:ff:ff:ff:ff:ff
    inet 10.0.2.15/24 brd 10.0.2.255 scope global dynamic enp0s3
       valid_lft 86251sec preferred_lft 86251sec
    inet6 fe80::c031:adb3:2f96:1705/64 scope link 
       valid_lft forever preferred_lft forever
3: enp0s8: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master bond0 state UP qlen 1000
    link/ether 08:00:27:69:b7:6f brd ff:ff:ff:ff:ff:ff
4: enp0s9: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master bond0 state UP qlen 1000
    link/ether 08:00:27:69:b7:6f brd ff:ff:ff:ff:ff:ff
5: bond0: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP qlen 1000
    link/ether 08:00:27:69:b7:6f brd ff:ff:ff:ff:ff:ff
    inet 10.0.3.15/24 brd 10.0.3.255 scope global bond0
       valid_lft forever preferred_lft forever
    inet6 fe80::a00:27ff:fe69:b76f/64 scope link tentative dadfailed 
       valid_lft forever preferred_lft forever

Consultez la configuration de l'interface bond0 :

[root@node1 ~]# cat /proc/net/bonding/bond0
Ethernet Channel Bonding Driver: v3.7.1 (April 27, 2011)

Bonding Mode: load balancing (xor)
Transmit Hash Policy: layer2 (0)
MII Status: up
MII Polling Interval (ms): 100
Up Delay (ms): 0
Down Delay (ms): 0

Slave Interface: enp0s8
MII Status: up
Speed: 1000 Mbps
Duplex: full
Link Failure Count: 0
Permanent HW addr: 08:00:27:69:b7:6f
Slave queue ID: 0

Slave Interface: enp0s9
MII Status: up
Speed: 1000 Mbps
Duplex: full
Link Failure Count: 0
Permanent HW addr: 08:00:27:1c:5d:3d
Slave queue ID: 0

Attention - Avant de poursuivre, arrêtez votre machine virtuelle. Créez deux clones : node10.i2tch.loc et node100i2tch.loc. Démarrez la machine node1.i2tch.loc.

Configuration du node2.i2tch.loc

Assurez-vous que le module bonding soit chargé :

[root@node2 ~]# lsmod | grep bonding
[root@node2 ~]# modprobe bonding
[root@node2 ~]# lsmod | grep bonding
bonding               145728  0 

Consultez la configuration des interfaces réseaux :

[root@node2 ~]# nmcli c show
NAME                UUID                                  TYPE            DEVICE 
Wired connection 1  69caf9d4-3497-3c22-ad5a-b462c1d4a213  802-3-ethernet  enp0s3 
Wired connection 2  e04d1654-d23e-3244-a970-8429b06c96ad  802-3-ethernet  enp0s8 
Wired connection 3  982d3b86-e2ee-3a9b-be22-b3ecc9e8be13  802-3-ethernet  enp0s9 

Créez le fichier /etc/sysconfig/network-scripts/ifcfg-bond0 :

[root@node2 ~]# vi /etc/sysconfig/network-scripts/ifcfg-bond0
[root@node2 ~]# cat /etc/sysconfig/network-scripts/ifcfg-bond0
DEVICE=bond0
USERCTL=no
BOOTPROTO=none
ONBOOT=yes
IPADDR=10.0.3.16
NETMASK=255.255.255.0
NETWORK=10.0.3.0
BONDING_OPTS="miimon=100 mode=balance-xor"
TYPE=Unknown
IPV6INIT=no

Créez le fichier /etc/sysconfig/network-scripts/ifcfg-enp0s8 :

[root@node2 ~]# vi /etc/sysconfig/network-scripts/ifcfg-enp0s8
[root@node2 ~]# cat /etc/sysconfig/network-scripts/ifcfg-enp0s8
DEVICE=enp0s8
BOOTPROTO=none
ONBOOT=yes
MASTER=bond0
SLAVE=yes
USERCTL=no

Créez le fichier /etc/sysconfig/network-scripts/ifcfg-enp0s9 :

[root@node2 ~]# vi /etc/sysconfig/network-scripts/ifcfg-enp0s9
[root@node2 ~]# cat /etc/sysconfig/network-scripts/ifcfg-enp0s9
DEVICE=enp0s9
BOOTPROTO=none
ONBOOT=yes
MASTER=bond0
SLAVE=yes
USERCTL=no

Créez le fichier /etc/modprobe.d/bonding.conf :

[root@node2 ~]# vi /etc/modprobe.d/bonding.conf
[root@node2 ~]# cat /etc/modprobe.d/bonding.conf
alias bond0 bonding

Modifiez le fichier /etc/hosts :

[root@node2 ~]# vi /etc/hosts
[root@node2 ~]# cat /etc/hosts
127.0.0.1		localhost.localdomain localhost
::1		localhost6.localdomain6 localhost6
10.0.3.15	node1.i2tch.loc 	node1
10.0.3.16	node2.i2tch.loc		node2

Re-démarrez le service network :

[root@node2 ~]# systemctl restart network
[root@node2 ~]# nmcli c show
NAME                UUID                                  TYPE            DEVICE 
System enp0s8       00cb8299-feb9-55b6-a378-3fdc720e0bc6  802-3-ethernet  enp0s8 
System enp0s9       93d13955-e9e2-a6bd-df73-12e3c747f122  802-3-ethernet  enp0s9 
Wired connection 1  69caf9d4-3497-3c22-ad5a-b462c1d4a213  802-3-ethernet  enp0s3 
bond0               44e713ff-ba22-44bb-9cb8-603fe130431f  bond            bond0  
Wired connection 2  e04d1654-d23e-3244-a970-8429b06c96ad  802-3-ethernet  --     
Wired connection 3  982d3b86-e2ee-3a9b-be22-b3ecc9e8be13  802-3-ethernet  -- 

Vérifiez la configuration du réseau :

[root@node2 ~]# ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: enp0s3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 08:00:27:10:90:fc brd ff:ff:ff:ff:ff:ff
    inet 10.0.2.15/24 brd 10.0.2.255 scope global dynamic enp0s3
       valid_lft 86157sec preferred_lft 86157sec
    inet6 fe80::2d4d:e50a:4f0e:65d3/64 scope link 
       valid_lft forever preferred_lft forever
3: enp0s8: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master bond0 state UP qlen 1000
    link/ether 08:00:27:16:89:9f brd ff:ff:ff:ff:ff:ff
4: enp0s9: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master bond0 state UP qlen 1000
    link/ether 08:00:27:16:89:9f brd ff:ff:ff:ff:ff:ff
5: bond0: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP qlen 1000
    link/ether 08:00:27:16:89:9f brd ff:ff:ff:ff:ff:ff
    inet 10.0.3.16/24 brd 10.0.3.255 scope global bond0
       valid_lft forever preferred_lft forever
    inet6 fe80::a00:27ff:fe16:899f/64 scope link tentative dadfailed 
       valid_lft forever preferred_lft forever

Consultez la configuration de l'interface bond0 :

[root@node2 ~]# cat /proc/net/bonding/bond0
Ethernet Channel Bonding Driver: v3.7.1 (April 27, 2011)

Bonding Mode: load balancing (xor)
Transmit Hash Policy: layer2 (0)
MII Status: up
MII Polling Interval (ms): 100
Up Delay (ms): 0
Down Delay (ms): 0

Slave Interface: enp0s8
MII Status: up
Speed: 1000 Mbps
Duplex: full
Link Failure Count: 0
Permanent HW addr: 08:00:27:16:89:9f
Slave queue ID: 0

Slave Interface: enp0s9
MII Status: up
Speed: 1000 Mbps
Duplex: full
Link Failure Count: 0
Permanent HW addr: 08:00:27:73:0e:e6
Slave queue ID: 0

Tester les Serveurs

Vérifiez que chaque machine puisse se voir sur le réseau 10.0.3.0. Vérifiez que chaque machine a accès à Internet.

[root@node1 ~]# ping -c1 www.free.fr
PING www.free.fr (212.27.48.10) 56(84) bytes of data.
64 bytes from www.free.fr (212.27.48.10): icmp_seq=1 ttl=63 time=36.7 ms

--- www.free.fr ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 36.751/36.751/36.751/0.000 ms
[root@node1 ~]# ping -c1 10.0.3.16
PING 10.0.3.16 (10.0.3.16) 56(84) bytes of data.
64 bytes from 10.0.3.16: icmp_seq=1 ttl=64 time=3.41 ms

--- 10.0.3.16 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 3.419/3.419/3.419/0.000 ms
[root@node2 ~]# ping -c1 www.free.fr
PING www.free.fr (212.27.48.10) 56(84) bytes of data.
64 bytes from www.free.fr (212.27.48.10): icmp_seq=1 ttl=63 time=17.0 ms

--- www.free.fr ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 17.080/17.080/17.080/0.000 ms
[root@node2 ~]# ping -c1 10.0.3.15
PING 10.0.3.15 (10.0.3.15) 56(84) bytes of data.
64 bytes from 10.0.3.15: icmp_seq=1 ttl=64 time=1.01 ms

--- 10.0.3.15 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 1.013/1.013/1.013/0.000 ms

Démarrer le Service pcsd si nécessaire

Dernièrement démarrez le service pcsd sur chaque noeud si necessaire :

[root@node1 ~]# systemctl status pcsd
● pcsd.service - PCS GUI and remote configuration interface
   Loaded: loaded (/usr/lib/systemd/system/pcsd.service; enabled; vendor preset: disabled)
   Active: active (running) since Wed 2018-08-29 11:22:01 CEST; 13min ago
     Docs: man:pcsd(8)
           man:pcs(8)
 Main PID: 552 (pcsd)
   CGroup: /system.slice/pcsd.service
           └─552 /usr/bin/ruby /usr/lib/pcsd/pcsd > /dev/null &

Aug 29 11:21:33 node1.i2tch.loc systemd[1]: Starting PCS GUI and remote conf....
Aug 29 11:22:01 node1.i2tch.loc systemd[1]: Started PCS GUI and remote confi....
Hint: Some lines were ellipsized, use -l to show in full.
[root@node2 ~]# systemctl status pcsd
● pcsd.service - PCS GUI and remote configuration interface
   Loaded: loaded (/usr/lib/systemd/system/pcsd.service; enabled; vendor preset: disabled)
   Active: active (running) since Wed 2018-08-29 11:22:02 CEST; 12min ago
     Docs: man:pcsd(8)
           man:pcs(8)
 Main PID: 538 (pcsd)
   CGroup: /system.slice/pcsd.service
           └─538 /usr/bin/ruby /usr/lib/pcsd/pcsd > /dev/null &

Aug 29 11:21:30 node2.i2tch.loc systemd[1]: Starting PCS GUI and remote conf....
Aug 29 11:22:02 node2.i2tch.loc systemd[1]: Started PCS GUI and remote confi....
Hint: Some lines were ellipsized, use -l to show in full.

LAB #32 - L'Authentification de l'utilisateur pcs hacluster

La commande suivante authentifie l'utilisateur hacluster sur node1.i2tch.loc pour les deux neouds node1.i2tch.loc et node2.i2tch.loc :

[root@node1 ~]# pcs cluster auth node1.i2tch.loc node2.i2tch.loc
Username: hacluster
Password: fenestros
node2.i2tch.loc: Authorized
node1.i2tch.loc: Authorized

Les options de la commande pcs sont :

[root@node1 ~]# pcs --help

Usage: pcs [-f file] [-h] [commands]...
Control and configure pacemaker and corosync.

Options:
    -h, --help         Display usage and exit.
    -f file            Perform actions on file instead of active CIB.
    --debug            Print all network traffic and external commands run.
    --version          Print pcs version information. List pcs capabilities if
                       --full is specified.
    --request-timeout  Timeout for each outgoing request to another node in
                       seconds. Default is 60s.
    --force            Override checks and errors, the exact behavior depends on
                       the command. WARNING: Using the --force option is
                       strongly discouraged unless you know what you are doing.

Commands:
    cluster     Configure cluster options and nodes.
    resource    Manage cluster resources.
    stonith     Manage fence devices.
    constraint  Manage resource constraints.
    property    Manage pacemaker properties.
    acl         Manage pacemaker access control lists.
    qdevice     Manage quorum device provider on the local host.
    quorum      Manage cluster quorum settings.
    booth       Manage booth (cluster ticket manager).
    status      View cluster status.
    config      View and manage cluster configuration.
    pcsd        Manage pcs daemon.
    node        Manage cluster nodes.
    alert       Manage pacemaker alerts.

LAB #33 - Création du cluster my_cluster

Créez le cluster my_cluster en propageant les fichiers de configuration à chaque noeud et en démarrant les services avec l'option –start :

[root@node1 ~]# pcs cluster setup --start --name my_cluster node1.i2tch.loc node2.i2tch.loc
Destroying cluster on nodes: node1.i2tch.loc, node2.i2tch.loc...
node1.i2tch.loc: Stopping Cluster (pacemaker)...
node2.i2tch.loc: Stopping Cluster (pacemaker)...
node2.i2tch.loc: Successfully destroyed cluster
node1.i2tch.loc: Successfully destroyed cluster

Sending 'pacemaker_remote authkey' to 'node1.i2tch.loc', 'node2.i2tch.loc'
node1.i2tch.loc: successful distribution of the file 'pacemaker_remote authkey'
node2.i2tch.loc: successful distribution of the file 'pacemaker_remote authkey'
Sending cluster config files to the nodes...
node1.i2tch.loc: Succeeded
node2.i2tch.loc: Succeeded

Starting cluster on nodes: node1.i2tch.loc, node2.i2tch.loc...
node1.i2tch.loc: Starting Cluster...
node2.i2tch.loc: Starting Cluster...

Synchronizing pcsd certificates on nodes node1.i2tch.loc, node2.i2tch.loc...
node2.i2tch.loc: Success
node1.i2tch.loc: Success
Restarting pcsd on the nodes in order to reload the certificates...
node2.i2tch.loc: Success
node1.i2tch.loc: Success

Pour consulter le statut du cluster, utilisez la commande pcs cluster status :

[root@node1 ~]# pcs cluster status
Cluster Status:
 Stack: corosync
 Current DC: node1.i2tch.loc (version 1.1.18-11.el7_5.3-2b07d5c5a9) - partition with quorum
 Last updated: Wed Aug 29 11:59:03 2018
 Last change: Wed Aug 29 11:53:23 2018 by hacluster via crmd on node1.i2tch.loc
 2 nodes configured
 0 resources configured

PCSD Status:
  node1.i2tch.loc: Online
  node2.i2tch.loc: Online

LAB #34 - Activer les services cluster sur chaque noeud

Activer les services cluster sur chaque noeud dans le cluster quand le noeud est démarré :

[root@node1 ~]# pcs cluster enable --all
node1.i2tch.loc: Cluster Enabled
node2.i2tch.loc: Cluster Enabled
[root@node1 ~]#
[root@node1 ~]# pcs cluster status
Cluster Status:
 Stack: corosync
 Current DC: node1.i2tch.loc (version 1.1.18-11.el7_5.3-2b07d5c5a9) - partition with quorum
 Last updated: Wed Aug 29 12:00:38 2018
 Last change: Wed Aug 29 11:53:23 2018 by hacluster via crmd on node1.i2tch.loc
 2 nodes configured
 0 resources configured

PCSD Status:
  node2.i2tch.loc: Online
  node1.i2tch.loc: Online

LAB #35 - Mise en place d'une clôture

Commencez par modifier le fichier /etc/hosts sur les deux noeuds :

[root@node1 ~]# vi /etc/hosts
[root@node1 ~]# cat /etc/hosts
127.0.0.1		localhost.localdomain localhost
::1		localhost6.localdomain6 localhost6
10.0.3.15	node1.i2tch.loc 	node1
10.0.3.16	node2.i2tch.loc		node2
10.0.3.17   apc.i2tch.loc       apc
[root@node2 ~]# vi /etc/hosts
[root@node2 ~]# cat /etc/hosts
127.0.0.1		localhost.localdomain localhost
::1		localhost6.localdomain6 localhost6
10.0.3.15	node1.i2tch.loc 	node1
10.0.3.16	node2.i2tch.loc		node2
10.0.3.17	apc.i2tch.loc		apc

Créez maintenant la ressource STONITH :

[root@node1 ~]# pcs stonith create myapc fence_apc_snmp --force ipaddr="apc.i2tch.loc" pcmk_host_map="node1.i2tch.loc:1;node2.i2tch.loc:2" pcmk_host_check="static-list" pcmk_host_list="node1.i2tch.loc,node2.i2tch.loc" login="trainee" passwd="trainee"

Vérifiez que la ressource soit active :

[root@node1 ~]# pcs cluster status
Cluster Status:
 Stack: corosync
 Current DC: node1.i2tch.loc (version 1.1.18-11.el7_5.3-2b07d5c5a9) - partition with quorum
 Last updated: Thu Aug 30 08:12:26 2018
 Last change: Wed Aug 29 13:55:22 2018 by root via cibadmin on node1.i2tch.loc
 2 nodes configured
 1 resource configured

PCSD Status:
  node1.i2tch.loc: Online
  node2.i2tch.loc: Online

Il est possible de voir la liste de tous les agents STONITH en utilisant la commande suivante :

[root@node1 ~]# pcs stonith list
fence_amt_ws - Fence agent for AMT (WS)
fence_apc - Fence agent for APC over telnet/ssh
fence_apc_snmp - Fence agent for APC, Tripplite PDU over SNMP
fence_bladecenter - Fence agent for IBM BladeCenter
fence_brocade - Fence agent for HP Brocade over telnet/ssh
fence_cisco_mds - Fence agent for Cisco MDS
fence_cisco_ucs - Fence agent for Cisco UCS
fence_compute - Fence agent for the automatic resurrection of OpenStack compute
                instances
fence_drac5 - Fence agent for Dell DRAC CMC/5
fence_eaton_snmp - Fence agent for Eaton over SNMP
fence_emerson - Fence agent for Emerson over SNMP
fence_eps - Fence agent for ePowerSwitch
fence_evacuate - Fence agent for the automatic resurrection of OpenStack compute
                 instances
fence_heuristics_ping - Fence agent for ping-heuristic based fencing
fence_hpblade - Fence agent for HP BladeSystem
fence_ibmblade - Fence agent for IBM BladeCenter over SNMP
fence_idrac - Fence agent for IPMI
fence_ifmib - Fence agent for IF MIB
fence_ilo - Fence agent for HP iLO
fence_ilo2 - Fence agent for HP iLO
fence_ilo3 - Fence agent for IPMI
fence_ilo3_ssh - Fence agent for HP iLO over SSH
fence_ilo4 - Fence agent for IPMI
fence_ilo4_ssh - Fence agent for HP iLO over SSH
fence_ilo_moonshot - Fence agent for HP Moonshot iLO
fence_ilo_mp - Fence agent for HP iLO MP
fence_ilo_ssh - Fence agent for HP iLO over SSH
fence_imm - Fence agent for IPMI
fence_intelmodular - Fence agent for Intel Modular
fence_ipdu - Fence agent for iPDU over SNMP
fence_ipmilan - Fence agent for IPMI
fence_kdump - Fence agent for use with kdump
fence_mpath - Fence agent for multipath persistent reservation
fence_rhevm - Fence agent for RHEV-M REST API
fence_rsa - Fence agent for IBM RSA
fence_rsb - I/O Fencing agent for Fujitsu-Siemens RSB
fence_sbd - Fence agent for sbd
fence_scsi - Fence agent for SCSI persistent reservation
fence_virt - Fence agent for virtual machines
fence_vmware_rest - Fence agent for VMware REST API
fence_vmware_soap - Fence agent for VMWare over SOAP API
fence_wti - Fence agent for WTI
fence_xvm - Fence agent for virtual machines

ainsi que de consulter les détails de chaque agent :

[root@node1 ~]# pcs stonith describe fence_apc_snmp
fence_apc_snmp - Fence agent for APC, Tripplite PDU over SNMP

fence_apc_snmp is an I/O Fencing agent which can be used with the APC network power switch or Tripplite PDU devices.It logs into a device via SNMP and reboots a specified outlet. It supports SNMP v1, v2c, v3 with all combinations of  authenticity/privacy settings.

Stonith options:
  ipport: TCP/UDP port to use for connection with device
  snmp_version: Specifies SNMP version to use (1,2c,3)
  community: Set the community string
  snmp_priv_prot: Set privacy protocol (DES|AES)
  port: Physical plug number, name of virtual machine or UUID
  inet6_only: Forces agent to use IPv6 addresses only
  ipaddr (required): IP Address or Hostname
  snmp_priv_passwd: Set privacy protocol password
  snmp_priv_passwd_script: Script to run to retrieve privacy password
  snmp_auth_prot: Set authentication protocol (MD5|SHA)
  inet4_only: Forces agent to use IPv4 addresses only
  passwd_script: Script to retrieve password
  snmp_sec_level: Set security level (noAuthNoPriv|authNoPriv|authPriv)
  passwd: Login password or passphrase
  login: Login Name
  verbose: Verbose mode
  debug: Write debug information to given file
  separator: Separator for CSV created by operation list
  power_wait: Wait X seconds after issuing ON/OFF
  login_timeout: Wait X seconds for cmd prompt after login
  power_timeout: Test X seconds for status change after ON/OFF
  delay: Wait X seconds before fencing is started
  shell_timeout: Wait X seconds for cmd prompt after issuing command
  retry_on: Count of attempts to retry power on
  priority: The priority of the stonith resource. Devices are tried in order of
            highest priority to lowest.
  pcmk_host_map: A mapping of host names to ports numbers for devices that do
                 not support host names. Eg. node1:1;node2:2,3 would tell the
                 cluster to use port 1 for node1 and ports 2 and 3 for node2
  pcmk_host_list: A list of machines controlled by this device (Optional unless
                  pcmk_host_check=static-list).
  pcmk_host_check: How to determine which machines are controlled by the device.
                   Allowed values: dynamic-list (query the device), static-list
                   (check the pcmk_host_list attribute), none (assume every
                   device can fence every machine)
  pcmk_delay_max: Enable a random delay for stonith actions and specify the
                  maximum of random delay. This prevents double fencing when
                  using slow devices such as sbd. Use this to enable a random
                  delay for stonith actions. The overall delay is derived from
                  this random delay value adding a static delay so that the sum
                  is kept below the maximum delay.
  pcmk_delay_base: Enable a base delay for stonith actions and specify base
                   delay value. This prevents double fencing when different
                   delays are configured on the nodes. Use this to enable a
                   static delay for stonith actions. The overall delay is
                   derived from a random delay value adding this static delay so
                   that the sum is kept below the maximum delay.
  pcmk_action_limit: The maximum number of actions can be performed in parallel
                     on this device Pengine property concurrent-fencing=true
                     needs to be configured first. Then use this to specify the
                     maximum number of actions can be performed in parallel on
                     this device. -1 is unlimited.

Default operations:
  monitor: interval=60s

En utilisant la commande suivante, il est possible de consulter le statut des ressources STONITH :

[root@node1 ~]# pcs stonith show
 myapc	(stonith:fence_apc_snmp):	Stopped

L'ensemble des sous-commandes de la commande pcs stonith peuvent être visualisées grâce à la commande suivante :

[root@node1 ~]# pcs stonith --help

Usage: pcs stonith [commands]...
Configure fence devices for use with pacemaker

Commands:
    [show [stonith id]] [--full]
        Show all currently configured stonith devices or if a stonith id is
        specified show the options for the configured stonith device.  If
        --full is specified all configured stonith options will be displayed.

    list [filter] [--nodesc]
        Show list of all available stonith agents (if filter is provided then
        only stonith agents matching the filter will be shown). If --nodesc is
        used then descriptions of stonith agents are not printed.

    describe <stonith agent> [--full]
        Show options for specified stonith agent. If --full is specified, all
        options including advanced ones are shown.

    create <stonith id> <stonith device type> [stonith device options]
           [op <operation action> <operation options> [<operation action>
           <operation options>]...] [meta <meta options>...]
           [--group <group id> [--before <stonith id> | --after <stonith id>]]
           [--disabled] [--wait[=n]]
        Create stonith device with specified type and options.
        If --group is specified the stonith device is added to the group named.
        You can use --before or --after to specify the position of the added
        stonith device relatively to some stonith device already existing in the
        group.
        If --disabled is specified the stonith device is not used.
        If --wait is specified, pcs will wait up to 'n' seconds for the stonith
        device to start and then return 0 if the stonith device is started, or 1
        if the stonith device has not yet started.  If 'n' is not specified it
        defaults to 60 minutes.

    update <stonith id> [stonith device options]
        Add/Change options to specified stonith id.

    delete <stonith id>
        Remove stonith id from configuration.

    enable <stonith id> [--wait[=n]]
        Allow the cluster to use the stonith device. If --wait is specified, pcs
        will wait up to 'n' seconds for the stonith device to start and then
        return 0 if the stonith device is started, or 1 if the stonith device
        has not yet started. If 'n' is not specified it defaults to 60 minutes.

    disable <stonith id> [--wait[=n]]
        Attempt to stop the stonith device if it is running and disallow the
        cluster to use it. If --wait is specified, pcs will wait up to 'n'
        seconds for the stonith device to stop and then return 0 if the stonith
        device is stopped or 1 if the stonith device has not stopped.  If 'n' is
        not specified it defaults to 60 minutes.

    cleanup [<stonith id>] [--node <node>]
        Make the cluster forget failed operations from history of the stonith
        device and re-detect its current state. This can be useful to purge
        knowledge of past failures that have since been resolved. If a stonith
        id is not specified then all resources / stonith devices will be cleaned
        up. If a node is not specified then resources / stonith devices on all
        nodes will be cleaned up.

    refresh [<stonith id>] [--node <node>] [--full]
        Make the cluster forget the complete operation history (including
        failures) of the stonith device and re-detect its current state. If you
        are interested in forgetting failed operations only, use the 'pcs
        stonith cleanup' command. If a stonith id is not specified then all
        resources / stonith devices will be refreshed. If a node is not
        specified then resources / stonith devices on all nodes will be
        refreshed. Use --full to refresh a stonith device on all nodes,
        otherwise only nodes where the stonith device's state is known will be
        considered.

    level [config]
        Lists all of the fencing levels currently configured.

    level add <level> <target> <stonith id> [stonith id]...
        Add the fencing level for the specified target with the list of stonith
        devices to attempt for that target at that level. Fence levels are
        attempted in numerical order (starting with 1). If a level succeeds
        (meaning all devices are successfully fenced in that level) then no
        other levels are tried, and the target is considered fenced.
        Target may be a node name <node_name> or %<node_name> or
        node%<node_name>, a node name regular expression regexp%<node_pattern>
        or a node attribute value attrib%<name>=<value>.

    level remove <level> [target] [stonith id]...
        Removes the fence level for the level, target and/or devices specified.
        If no target or devices are specified then the fence level is removed.
        Target may be a node name <node_name> or %<node_name> or
        node%<node_name>, a node name regular expression regexp%<node_pattern>
        or a node attribute value attrib%<name>=<value>.

    level clear [target|stonith id(s)]
        Clears the fence levels on the target (or stonith id) specified or
        clears all fence levels if a target/stonith id is not specified. If
        more than one stonith id is specified they must be separated by a comma
        and no spaces.
        Target may be a node name <node_name> or %<node_name> or
        node%<node_name>, a node name regular expression regexp%<node_pattern>
        or a node attribute value attrib%<name>=<value>.
        Example: pcs stonith level clear dev_a,dev_b

    level verify
        Verifies all fence devices and nodes specified in fence levels exist.

    fence <node> [--off]
        Fence the node specified (if --off is specified, use the 'off' API
        call to stonith which will turn the node off instead of rebooting it).

    confirm <node> [--force]
        Confirm to the cluster that the specified node is powered off. This
        allows the cluster to recover from a situation where no stonith device
        is able to fence the node. This command should ONLY be used after
        manually ensuring that the node is powered off and has no access to
        shared resources.

        WARNING: If this node is not actually powered off or it does have
        access to shared resources, data corruption/cluster failure can occur.
        To prevent accidental running of this command, --force or interactive
        user response is required in order to proceed.

        NOTE: It is not checked if the specified node exists in the cluster
        in order to be able to work with nodes not visible from the local
        cluster partition.

    sbd enable [--watchdog=<path>[@<node>]] ... [--device=<path>[@<node>]] ...
               [<SBD_OPTION>=<value>] ...
        Enable SBD in cluster. Default path for watchdog device is
        /dev/watchdog. Allowed SBD options: SBD_WATCHDOG_TIMEOUT (default: 5),
        SBD_DELAY_START (default: no) and SBD_STARTMODE (default: always). It is
        possible to specify up to 3 devices per node.

        WARNING: Cluster has to be restarted in order to apply these changes.

        Example of enabling SBD in cluster with watchdogs on node1 will be
        /dev/watchdog2, on node2 /dev/watchdog1, /dev/watchdog0 on all other
        nodes, device /dev/sdb on node1, device /dev/sda on all other nodes and
        watchdog timeout will bet set to 10 seconds:
        pcs stonith sbd enable \
            --watchdog=/dev/watchdog2@node1 \
            --watchdog=/dev/watchdog1@node2 \
            --watchdog=/dev/watchdog0 \
            --device=/dev/sdb@node1 \
            --device=/dev/sda \
            SBD_WATCHDOG_TIMEOUT=10

    sbd disable
        Disable SBD in cluster.

        WARNING: Cluster has to be restarted in order to apply these changes.

    sbd device setup --device=<path> [--device=<path>]...
                     [watchdog-timeout=<integer>] [allocate-timeout=<integer>]
                     [loop-timeout=<integer>] [msgwait-timeout=<integer>]
        Initialize SBD structures on device(s) with specified timeouts.

        WARNING: All content on device(s) will be overwritten.

    sbd device message <device-path> <node> <message-type>
        Manually set a message of the specified type on the device for the node.
        Possible message types (they are documented in sbd(8) man page): test,
        reset, off, crashdump, exit, clear

    sbd status [--full]
        Show status of SBD services in cluster and local device(s) configured.
        If --full is specified, also dump of SBD headers on device(s)
        will be shown.

    sbd config
        Show SBD configuration in cluster.

Examples:
    pcs stonith create MyStonith fence_virt pcmk_host_list=f1

LAB #36 - Mise en place d'un Serveur Apache Actif/Passif

Création du Stockage Partagé

Vous allez simuler un SAN avec iSCSI. Importez la machine virtuelle iscsi.

Ajoutez un disque supplémentaire de type vdi et d'une taille de 8Go au contrôleur SATA.

Démarrez la machine virtuelle.

Connectez-vous à la VM via putty sur localhost:6022.

Commencez par installer le paquet scsi-target-utils :

[root@iscsi ~]# yum install -y epel-release
[root@iscsi ~]# yum install -y scsi-target-utils

Le paquet contient la commande tgtd et la commande tgtadm.

Les options de la commande tgtd sont :

[root@iscsi ~]# tgtd --help
Linux SCSI Target framework daemon, version 1.0.55

Usage: tgtd [OPTION]
-f, --foreground        make the program run in the foreground
-C, --control-port NNNN use port NNNN for the mgmt channel
-t, --nr_iothreads NNNN specify the number of I/O threads
-d, --debug debuglevel  print debugging information
-V, --version           print version and exit
-h, --help              display this help and exit

Les options de la commande tgtadm sont :

[root@iscsi ~]# tgtadm --help
Linux SCSI Target administration utility, version 1.0.55

Usage: tgtadm [OPTION]
--lld <driver> --mode target --op new --tid <id> --targetname <name>
	add a new target with <id> and <name>. <id> must not be zero.
--lld <driver> --mode target --op delete [--force] --tid <id>
	delete the specific target with <id>.
	With force option, the specific target is deleted
	even if there is an activity.
--lld <driver> --mode target --op show
	show all the targets.
--lld <driver> --mode target --op show --tid <id>
	show the specific target's parameters.
--lld <driver> --mode target --op update --tid <id> --name <param> --value <value>
	change the target parameters of the target with <id>.
--lld <driver> --mode target --op bind --tid <id> --initiator-address <address>
--lld <driver> --mode target --op bind --tid <id> --initiator-name <name>
	enable the target to accept the specific initiators.
--lld <driver> --mode target --op unbind --tid <id> --initiator-address <address>
--lld <driver> --mode target --op unbind --tid <id> --initiator-name <name>
	disable the specific permitted initiators.
--lld <driver> --mode logicalunit --op new --tid <id> --lun <lun>
  --backing-store <path> --bstype <type> --bsopts <bs options> --bsoflags <options>
	add a new logical unit with <lun> to the specific
	target with <id>. The logical unit is offered
	to the initiators. <path> must be block device files
	(including LVM and RAID devices) or regular files.
	bstype option is optional.
	bsopts are specific to the bstype.
	bsoflags supported options are sync and direct
	(sync:direct for both).
--lld <driver> --mode logicalunit --op delete --tid <id> --lun <lun>
	delete the specific logical unit with <lun> that
	the target with <id> has.
--lld <driver> --mode account --op new --user <name> --password <pass>
	add a new account with <name> and <pass>.
--lld <driver> --mode account --op delete --user <name>
	delete the specific account having <name>.
--lld <driver> --mode account --op bind --tid <id> --user <name> [--outgoing]
	add the specific account having <name> to
	the specific target with <id>.
	<user> could be <IncomingUser> or <OutgoingUser>.
	If you use --outgoing option, the account will
	be added as an outgoing account.
--lld <driver> --mode account --op unbind --tid <id> --user <name> [--outgoing]
	delete the specific account having <name> from specific
	target. The --outgoing option must be added if you
	delete an outgoing account.
--lld <driver> --mode lld --op start
	Start the specified lld without restarting the tgtd process.
--control-port <port> use control port <port>
--help
	display this help and exit

Report bugs to <stgt@vger.kernel.org>.

Activez et démarrez le service tgtd :

[root@iscsi ~]# systemctl enable tgtd
[root@iscsi ~]# systemctl restart tgtd

Configurez firewalld pour le service :

[root@iscsi ~]# firewall-cmd --add-service=iscsi-target --permanent
[root@iscsi ~]# firewall-cmd --reload

Créez d'abord une cible à laquelle vous pouvez rajouter le disque :

[root@iscsi ~]# tgtadm --lld iscsi --op new --mode target --tid 1 -T target

Consultez la configuration actuelle :

[root@iscsi ~]# tgtadm --lld iscsi --op show --mode target
Target 1: target
    System information:
        Driver: iscsi
        State: ready
    I_T nexus information:
    LUN information:
        LUN: 0
            Type: controller
            SCSI ID: IET     00010000
            SCSI SN: beaf10
            Size: 0 MB, Block size: 1
            Online: Yes
            Removable media: No
            Prevent removal: No
            Readonly: No
            SWP: No
            Thin-provisioning: No
            Backing store type: null
            Backing store path: None
            Backing store flags: 
    Account information:
    ACL information:

Ajoutez maintenant le disque au premier LUN :

[root@iscsi ~]# tgtadm --lld iscsi --op new --mode logicalunit --tid 1 --lun 1 -b /dev/sdb

Consultez la configuration :

[root@iscsi ~]# tgtadm --lld iscsi --op show --mode target
Target 1: target
    System information:
        Driver: iscsi
        State: ready
    I_T nexus information:
    LUN information:
        LUN: 0
            Type: controller
            SCSI ID: IET     00010000
            SCSI SN: beaf10
            Size: 0 MB, Block size: 1
            Online: Yes
            Removable media: No
            Prevent removal: No
            Readonly: No
            SWP: No
            Thin-provisioning: No
            Backing store type: null
            Backing store path: None
            Backing store flags: 
        LUN: 1
            Type: disk
            SCSI ID: IET     00010001
            SCSI SN: beaf11
            Size: 1074 MB, Block size: 512
            Online: Yes
            Removable media: No
            Prevent removal: No
            Readonly: Yes
            SWP: No
            Thin-provisioning: No
            Backing store type: rdwr
            Backing store path: /dev/sdb
            Backing store flags: 
    Account information:
    ACL information:

Configurez maintenant le deuxième LUN :

[root@iscsi ~]# tgtadm --lld iscsi --op new --mode logicalunit --tid 1 --lun 2 -b /dev/sdb

Configurez le serveur pour que tous les clients puissent y avoir accès :

[root@iscsi ~]# tgtadm --lld iscsi --op bind --mode target --tid 1 -I ALL

Dernièrement configurez LUN1 et LUN2 en mode r/w :

[root@iscsi ~]# tgtadm --lld iscsi --mode logicalunit --op update --tid 1 --lun 1 --params readonly=0
[root@iscsi ~]# tgtadm --lld iscsi --mode logicalunit --op update --tid 1 --lun 2 --params readonly=0

Consultez la configuration :

[root@iscsi ~]# tgtadm --lld iscsi --op show --mode target
Target 1: target
    System information:
        Driver: iscsi
        State: ready
    I_T nexus information:
    LUN information:
        LUN: 0
            Type: controller
            SCSI ID: IET     00010000
            SCSI SN: beaf10
            Size: 0 MB, Block size: 1
            Online: Yes
            Removable media: No
            Prevent removal: No
            Readonly: No
            SWP: No
            Thin-provisioning: No
            Backing store type: null
            Backing store path: None
            Backing store flags: 
        LUN: 1
            Type: disk
            SCSI ID: IET     00010001
            SCSI SN: beaf11
            Size: 1074 MB, Block size: 512
            Online: Yes
            Removable media: No
            Prevent removal: No
            Readonly: No
            SWP: No
            Thin-provisioning: No
            Backing store type: rdwr
            Backing store path: /dev/sdb
            Backing store flags: 
        LUN: 2
            Type: disk
            SCSI ID: IET     00010002
            SCSI SN: beaf12
            Size: 1074 MB, Block size: 512
            Online: Yes
            Removable media: No
            Prevent removal: No
            Readonly: No
            SWP: No
            Thin-provisioning: No
            Backing store type: rdwr
            Backing store path: /dev/sdb
            Backing store flags: 
    Account information:
    ACL information:
        ALL

Important - Notez que les SCSI ID et les SCSI SN des deux LUNs ne sont pas identiques. Dans l'état donc, le multipathing ne fonctionera pas car celui-ci necéssite à ce que les deux enregistrements soient identiques.

L'option –params de la commande tgtadm permet de modifier les paramètres de la configuration :

[root@iscsi ~]# tgtadm --lld iscsi --op update --mode logicalunit --tid 1 --lun 1 --params vendor_id="I2TCH",product_id="MyISCSIDisk",product_rev="1.0",scsi_id="scsi001",scsi_sn="0123456789"
[root@iscsi ~]# tgtadm --lld iscsi --op update --mode logicalunit --tid 1 --lun 2 --params vendor_id="I2TCH",product_id="MyISCSIDisk",product_rev="1.0",scsi_id="scsi001",scsi_sn="0123456789"

Consultez maintenant la configuration :

[root@iscsi ~]# tgtadm --lld iscsi --op show --mode target
Target 1: target
    System information:
        Driver: iscsi
        State: ready
    I_T nexus information:
    LUN information:
        LUN: 0
            Type: controller
            SCSI ID: IET     00010000
            SCSI SN: beaf10
            Size: 0 MB, Block size: 1
            Online: Yes
            Removable media: No
            Prevent removal: No
            Readonly: No
            SWP: No
            Thin-provisioning: No
            Backing store type: null
            Backing store path: None
            Backing store flags: 
        LUN: 1
            Type: disk
            SCSI ID: scsi001
            SCSI SN: 0123456789
            Size: 1074 MB, Block size: 512
            Online: Yes
            Removable media: No
            Prevent removal: No
            Readonly: No
            SWP: No
            Thin-provisioning: No
            Backing store type: rdwr
            Backing store path: /dev/sdb
            Backing store flags: 
        LUN: 2
            Type: disk
            SCSI ID: scsi001
            SCSI SN: 0123456789
            Size: 1074 MB, Block size: 512
            Online: Yes
            Removable media: No
            Prevent removal: No
            Readonly: No
            SWP: No
            Thin-provisioning: No
            Backing store type: rdwr
            Backing store path: /dev/sdb
            Backing store flags: 
    Account information:
    ACL information:
        ALL

Vérifiez que le port 3260 est bien ouvert et en état d'écoute :

[root@iscsi ~]# netstat -apn | grep 3260
tcp        0      0 0.0.0.0:3260            0.0.0.0:*               LISTEN      4169/tgtd           
tcp6       0      0 :::3260                 :::*                    LISTEN      4169/tgtd  

Pour accéder à notre cible ISCSI, le client doit disposer d'un initiateur. Installez donc le paquet iscsi-initiator-utils :

[root@node1 ~]# yum -y install iscsi-initiator-utils
[root@node2 ~]# yum -y install iscsi-initiator-utils

Lancez maintenant la découverte des cibles sur le serveur iscsi :

[root@node1 ~]# iscsiadm --mode discovery --type sendtargets --portal 10.0.3.18
192.168.121.3:3260,1 target
[root@node2 ~]# iscsiadm --mode discovery --type sendtargets --portal 10.0.3.18
192.168.121.3:3260,1 target

Connectez-vous à la cible à partir de chaque noeud :

[root@node1 ~]# iscsiadm --mode node --targetname target --login
Logging in to [iface: default, target: target, portal: 10.0.3.18,3260] (multiple)
Login to [iface: default, target: target, portal: 10.0.3.18,3260] successful.
[root@node2 ~]# iscsiadm --mode node --targetname target --login
Logging in to [iface: default, target: target, portal: 10.0.3.18,3260] (multiple)
Login to [iface: default, target: target, portal: 10.0.3.18,3260] successful.

Consultez le journal /var/log/messages de chaque noeud :

[root@node1 ~]# tail /var/log/messages
Sep 16 17:15:54 node1 kernel: sd 3:0:0:1: [sdb] 16777216 512-byte logical blocks: (8.58 GB/8.00 GiB)
Sep 16 17:15:54 node1 kernel: sd 3:0:0:2: Attached scsi generic sg4 type 0
Sep 16 17:15:54 node1 kernel: sd 3:0:0:1: [sdb] Write Protect is off
Sep 16 17:15:54 node1 kernel: sd 3:0:0:2: [sdc] 16777216 512-byte logical blocks: (8.58 GB/8.00 GiB)
Sep 16 17:15:54 node1 kernel: sd 3:0:0:1: [sdb] Write cache: enabled, read cache: enabled, supports DPO and FUA
Sep 16 17:15:54 node1 kernel: sd 3:0:0:2: [sdc] Write Protect is off
Sep 16 17:15:54 node1 kernel: sd 3:0:0:2: [sdc] Write cache: enabled, read cache: enabled, supports DPO and FUA
Sep 16 17:15:54 node1 kernel: sd 3:0:0:1: [sdb] Attached SCSI disk
Sep 16 17:15:54 node1 kernel: sd 3:0:0:2: [sdc] Attached SCSI disk
Sep 16 17:15:55 node1 iscsid: Connection1:0 to [target: target, portal: 10.0.3.18,3260] through [iface: default] is operational now
[root@node2 ~]# tail /var/log/messages
Aug 31 10:18:24 node2 kernel: sd 3:0:0:2: [sdc] 16777216 512-byte logical blocks: (8.58 GB/8.00 GiB)
Aug 31 10:18:24 node2 kernel: sd 3:0:0:1: [sdb] Write cache: enabled, read cache: enabled, supports DPO and FUA
Aug 31 10:18:24 node2 kernel: sd 3:0:0:2: [sdc] Write Protect is off
Aug 31 10:18:24 node2 kernel: sd 3:0:0:2: [sdc] Write cache: enabled, read cache: enabled, supports DPO and FUA
Aug 31 10:18:24 node2 kernel: sd 3:0:0:1: [sdb] Attached SCSI disk
Aug 31 10:18:24 node2 kernel: sd 3:0:0:2: [sdc] Attached SCSI disk
Aug 31 10:18:25 node2 iscsid: Connection1:0 to [target: target, portal: 10.0.3.18,3260] through [iface: default] is operational now
Aug 31 10:19:03 node2 systemd: Starting Cleanup of Temporary Directories...
Aug 31 10:19:05 node2 systemd: Started Cleanup of Temporary Directories.
Aug 31 10:19:21 node2 sh: Sleeping '' ''

Important - Notez que les deux disques SCSI sont vus comme /dev/sdb et /dev/sdc.

A partir de node1.i2tch.loc, créez la partition sdb1 :

[root@node1 ~]# fdisk /dev/sdb
Welcome to fdisk (util-linux 2.23.2).

Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.

Device does not contain a recognized partition table
Building a new DOS disklabel with disk identifier 0x6f284e72.

Command (m for help): n
Partition type:
   p   primary (0 primary, 0 extended, 4 free)
   e   extended
Select (default p): p
Partition number (1-4, default 1): 
First sector (2048-16777215, default 2048): 
Using default value 2048
Last sector, +sectors or +size{K,M,G} (2048-16777215, default 16777215): 
Using default value 16777215
Partition 1 of type Linux and of size 8 GiB is set

Command (m for help): p

Disk /dev/sdb: 8589 MB, 8589934592 bytes, 16777216 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk label type: dos
Disk identifier: 0x6f284e72

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1            2048    16777215     8387584   83  Linux

Command (m for help): w
The partition table has been altered!

Calling ioctl() to re-read partition table.
Syncing disks.
[root@node1 ~]# partprobe
[root@node1 ~]# fdisk -l

Disk /dev/sda: 21.5 GB, 21474836480 bytes, 41943040 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk label type: dos
Disk identifier: 0x000c5a90

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *        2048      411647      204800   83  Linux
/dev/sda2          411648    20891647    10240000   83  Linux
/dev/sda3        20891648    25083903     2096128   82  Linux swap / Solaris
/dev/sda4        25083904    41943039     8429568    5  Extended
/dev/sda5        25085952    26109951      512000   83  Linux
/dev/sda6        26112000    27135999      512000   83  Linux

Disk /dev/sdb: 8589 MB, 8589934592 bytes, 16777216 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk label type: dos
Disk identifier: 0x6f284e72

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1            2048    16777215     8387584   83  Linux

Disk /dev/sdc: 8589 MB, 8589934592 bytes, 16777216 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk label type: dos
Disk identifier: 0x6f284e72

   Device Boot      Start         End      Blocks   Id  System
/dev/sdc1            2048    16777215     8387584   83  Linux

Créez ensuite un PV sur sdb1 :

[root@node1 ~]# pvcreate /dev/sdb1
  Physical volume "/dev/sdb1" successfully created.

Créez maintenant un VG :

[root@node1 ~]# vgcreate my_vg /dev/sdb1
  Volume group "my_vg" successfully created

Dernièrement créez le LV my_lv :

[root@node1 ~]# lvcreate -L450 -n my_lv my_vg
  Rounding up size to full physical extent 452.00 MiB
  Logical volume "my_lv" created.

Constatez la présence du volume logique :

[root@node1 ~]# lvs
  LV    VG    Attr       LSize   Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert
  my_lv my_vg -wi-a----- 452.00m  

Créez maintenant un système de fichiers ext4 sur le volume logique my_lv :

[root@node1 ~]# mkfs.ext4 /dev/my_vg/my_lv
mke2fs 1.42.9 (28-Dec-2013)
Filesystem label=
OS type: Linux
Block size=1024 (log=0)
Fragment size=1024 (log=0)
Stride=0 blocks, Stripe width=0 blocks
115824 inodes, 462848 blocks
23142 blocks (5.00%) reserved for the super user
First data block=1
Maximum filesystem blocks=34078720
57 block groups
8192 blocks per group, 8192 fragments per group
2032 inodes per group
Superblock backups stored on blocks: 
	8193, 24577, 40961, 57345, 73729, 204801, 221185, 401409

Allocating group tables: done                            
Writing inode tables: done                            
Creating journal (8192 blocks): done
Writing superblocks and filesystem accounting information: done 

Installez Apache sur chaque noeud :

[root@node1 ~]# yum install -y httpd wget
[root@node2 ~]# yum install -y httpd wget

Afin que l'agent de la ressource Apache puisse obtenir le statut de chaque Apache, ajoutez les lignes suivantes à la fin du fichier /etc/httpd/conf/httod.conf de chaque noeud :

[root@node1 ~]# vi /etc/httpd/conf/httod.conf
[root@node1 ~]# cat /etc/httpd/conf/httod.conf
...
<Location /server-status>
    SetHandler server-status
    Require local
</Location> 
[root@node2 ~]# vi /etc/httpd/conf/httod.conf
[root@node2 ~]# cat /etc/httpd/conf/httod.conf
...
<Location /server-status>
    SetHandler server-status
    Require local
</Location> 

L'agent de la ressource Apache n'utilise pas systemd. Pour cette raison vous devez éditer le script de logrotate afin que celui-ci n'utilise pas la commande systemctl pour recharger Apache :

[root@node1 ~]# vi /etc/logrotate.d/httpd
[root@node1 ~]# cat /etc/logrotate.d/httpd
/var/log/httpd/*log {
    missingok
    notifempty
    sharedscripts
    delaycompress
    postrotate
    #    /bin/systemctl reload httpd.service > /dev/null 2>/dev/null || true
    /usr/sbin/httpd -f /etc/httpd/conf/httpd.conf -c "PidFile /var/run/httpd.pid" -k graceful > /dev/null 2>/dev/null || true
    endscript
}
[root@node2 ~]# vi /etc/logrotate.d/httpd
[root@node2 ~]# cat /etc/logrotate.d/httpd
/var/log/httpd/*log {
    missingok
    notifempty
    sharedscripts
    delaycompress
    postrotate
    #    /bin/systemctl reload httpd.service > /dev/null 2>/dev/null || true
    /usr/sbin/httpd -f /etc/httpd/conf/httpd.conf -c "PidFile /var/run/httpd.pid" -k graceful > /dev/null 2>/dev/null || true
    endscript
}

Créez le fichier index.html sur le volume logique my_lv :

[root@node1 ~]# mount /dev/my_vg/my_lv /var/www/
You have new mail in /var/spool/mail/root
[root@node1 ~]# mkdir /var/www/html
[root@node1 ~]# mkdir /var/www/cgi-bin
[root@node1 ~]# mkdir /var/www/error
[root@node1 ~]# restorecon -R /var/www
[root@node1 ~]# cat <<-END >/var/www/html/index.html
> <html>
> <body>Hello</body>
> </html>
> END
[root@node1 ~]# umount /var/www

Afin d'accorder le contrôle de l'activation du groupe de volumes my_vg au cluster et non au système d'exploitation, afin d'éviter toute possibilité de corruption des méta-données, il convient de modifier la directive volume_list du fichier /etc/lvm/lvm.conf de chaque noeud.

Premièrement, modifiez la valeur de la directive use_lvmetad dans le fichier /etc/lvm/lvm.conf de chaque noeud :

[root@node1 ~]# vi /etc/lvm/lvm.conf
[root@node1 ~]# cat /etc/lvm/lvm.conf | grep "use_lvmetad ="
	use_lvmetad = 0 
[root@node2 ~]# vi /etc/lvm/lvm.conf
[root@node2 ~]# cat /etc/lvm/lvm.conf | grep "use_lvmetad ="
	use_lvmetad = 0 

Arrêtez et désactivez tous les processus éventuels de use_lvmetad sur chaque noeud :

[root@node1 ~]# lvmconf --enable-halvm --services --startstopservices
Warning: Stopping lvm2-lvmetad.service, but it can still be activated by:
  lvm2-lvmetad.socket
Removed symlink /etc/systemd/system/sysinit.target.wants/lvm2-lvmetad.socket.
[root@node2 ~]# lvmconf --enable-halvm --services --startstopservices
Warning: Stopping lvm2-lvmetad.service, but it can still be activated by:
  lvm2-lvmetad.socket
Removed symlink /etc/systemd/system/sysinit.target.wants/lvm2-lvmetad.socket.

Modifiez la directive volume_list dans le fichier /etc/lvm/lvm.conf de chaque neoud :

[root@node1 ~]# vi /etc/lvm/lvm.conf
[root@node1 ~]# cat /etc/lvm/lvm.conf | grep my_vg
	volume_list = [ ]
[root@node1 ~]# vi /etc/lvm/lvm.conf
[root@node1 ~]# cat /etc/lvm/lvm.conf | grep my_vg
	volume_list = [ ]
<code>

Regénérez un initramfs sur chaque noeud afin de prendre en compte ces modifications :

<code>
[root@node1 ~]# dracut -H -f /boot/initramfs-$(uname -r).img $(uname -r)
[root@node2 ~]# dracut -H -f /boot/initramfs-$(uname -r).img $(uname -r)

Re-démarrez chaque noeud :

[root@node1 ~]# shutdown -r now
[root@node2 ~]# shutdown -r now

Création des Ressources du Cluster

Créez la ressource cluster my_lvm :

[root@node1 ~]# pcs resource create my_lvm LVM volgrpname=my_vg exclusive=true --group apachegroup
Assumed agent name 'ocf:heartbeat:LVM' (deduced from 'LVM')

Contrôlez le statut du cluster :

[root@node1 ~]# pcs status
Cluster name: my_cluster
Stack: corosync
Current DC: node1.i2tch.loc (version 1.1.18-11.el7_5.3-2b07d5c5a9) - partition with quorum
Last updated: Tue Sep 18 06:56:44 2018
Last change: Tue Sep 18 06:56:10 2018 by root via cibadmin on node1.i2tch.loc

2 nodes configured
2 resources configured

Online: [ node1.i2tch.loc node2.i2tch.loc ]

Full list of resources:

 myapc	(stonith:fence_apc_snmp):	Stopped
 Resource Group: apachegroup
     my_lvm	(ocf::heartbeat:LVM):	Started node1.i2tch.loc

Failed Actions:
* myapc_start_0 on node1.i2tch.loc 'unknown error' (1): call=14, status=Error, exitreason='',
    last-rc-change='Tue Sep 18 06:48:02 2018', queued=0ms, exec=14307ms
* myapc_start_0 on node2.i2tch.loc 'unknown error' (1): call=6, status=Error, exitreason='',
    last-rc-change='Tue Sep 18 06:48:14 2018', queued=2ms, exec=16999ms


Daemon Status:
  corosync: active/enabled
  pacemaker: active/enabled
  pcsd: active/enabled

Créez ensuite les ressources my_fs ainsi que VirtualIP :

[root@node1 ~]# pcs resource create my_fs Filesystem device="/dev/my_vg/my_lv" directory="/var/www" fstype="ext4" --group apachegroup
Assumed agent name 'ocf:heartbeat:Filesystem' (deduced from 'Filesystem')
[root@node1 ~]#
[root@node1 ~]# pcs resource create VirtualIP IPaddr2 ip=10.0.3.100 cidr_netmask=24 --group apachegroup
Assumed agent name 'ocf:heartbeat:IPaddr2' (deduced from 'IPaddr2')

Dernièrement, créez la ressource Website :

[root@node1 ~]# pcs resource create Website apache configfile="/etc/httpd/conf/httpd.conf" statusurl="http://127.0.0.1/server-status" --group apachegroup
Assumed agent name 'ocf:heartbeat:apache' (deduced from 'apache')

Contrôlez de nouveau le statut du cluster et noter le neoud sur lequel ont été démarrés les services ( dans ce cas node1.i2tch.loc ) :

[root@node1 ~]# pcs status
Cluster name: my_cluster
Stack: corosync
Current DC: node1.i2tch.loc (version 1.1.18-11.el7_5.3-2b07d5c5a9) - partition with quorum
Last updated: Tue Sep 18 07:34:49 2018
Last change: Tue Sep 18 07:34:44 2018 by root via cibadmin on node1.i2tch.loc

2 nodes configured
5 resources configured

Online: [ node1.i2tch.loc node2.i2tch.loc ]

Full list of resources:

 myapc	(stonith:fence_apc_snmp):	Stopped
 Resource Group: apachegroup
     my_lvm	(ocf::heartbeat:LVM):	Started node1.i2tch.loc
     my_fs	(ocf::heartbeat:Filesystem):	Started node1.i2tch.loc
     VirtualIP	(ocf::heartbeat:IPaddr2):	Started node1.i2tch.loc
     Website	(ocf::heartbeat:apache):	Started node1.i2tch.loc

Failed Actions:
* myapc_start_0 on node2.i2tch.loc 'unknown error' (1): call=22, status=Error, exitreason='',
    last-rc-change='Tue Sep 18 07:24:17 2018', queued=0ms, exec=13456ms
* myapc_start_0 on node1.i2tch.loc 'unknown error' (1): call=6, status=Error, exitreason='',
    last-rc-change='Tue Sep 18 07:24:03 2018', queued=0ms, exec=13600ms


Daemon Status:
  corosync: active/enabled
  pacemaker: active/enabled
  pcsd: active/enabled

Contrôlez la présence de l'adresse IP 10.0.3.100 sur le noeud concerné :

[root@node1 ~]# ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: enp0s3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 08:00:27:10:90:fc brd ff:ff:ff:ff:ff:ff
    inet 10.0.2.15/24 brd 10.0.2.255 scope global dynamic enp0s3
       valid_lft 85984sec preferred_lft 85984sec
    inet6 fe80::2d4d:e50a:4f0e:65d3/64 scope link 
       valid_lft forever preferred_lft forever
3: enp0s8: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master bond0 state UP qlen 1000
    link/ether 08:00:27:16:89:9f brd ff:ff:ff:ff:ff:ff
4: enp0s9: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master bond0 state UP qlen 1000
    link/ether 08:00:27:16:89:9f brd ff:ff:ff:ff:ff:ff
5: bond0: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP qlen 1000
    link/ether 08:00:27:16:89:9f brd ff:ff:ff:ff:ff:ff
    inet 10.0.3.15/24 brd 10.0.3.255 scope global bond0
       valid_lft forever preferred_lft forever
    inet 10.0.3.200/24 brd 10.0.3.255 scope global secondary bond0
       valid_lft forever preferred_lft forever
    inet6 fe80::aadb:c074:fbc7:5e94/64 scope link tentative dadfailed 
       valid_lft forever preferred_lft forever
    inet6 fe80::5915:b321:a5ae:321e/64 scope link tentative dadfailed 
       valid_lft forever preferred_lft forever
    inet6 fe80::138a:5c7a:1284:aa3d/64 scope link tentative dadfailed 
       valid_lft forever preferred_lft forever

Arrêtez le noeud hébergeant les services :

[root@node1 ~]# shutdown - h now

Consultez le statut du cluster et notez le basculement des services :

[root@node2 ~]# pcs status
Cluster name: my_cluster
Stack: corosync
Current DC: node1.i2tch.loc (version 1.1.18-11.el7_5.3-2b07d5c5a9) - partition with quorum
Last updated: Tue Sep 18 07:50:18 2018
Last change: Tue Sep 18 07:34:44 2018 by root via cibadmin on node1.i2tch.loc

2 nodes configured
5 resources configured

Online: [ node1.i2tch.loc node2.i2tch.loc ]

Full list of resources:

 myapc	(stonith:fence_apc_snmp):	Stopped
 Resource Group: apachegroup
     my_lvm	(ocf::heartbeat:LVM):	Started node2.i2tch.loc
     my_fs	(ocf::heartbeat:Filesystem):	Started node2.i2tch.loc
     VirtualIP	(ocf::heartbeat:IPaddr2):	Started node2.i2tch.loc
     Website	(ocf::heartbeat:apache):	Starting node2.i2tch.loc

Failed Actions:
* myapc_start_0 on node2.i2tch.loc 'unknown error' (1): call=22, status=Error, exitreason='',
    last-rc-change='Tue Sep 18 07:38:00 2018', queued=1ms, exec=15975ms
* myapc_start_0 on node1.i2tch.loc 'unknown error' (1): call=6, status=Error, exitreason='',
    last-rc-change='Tue Sep 18 07:37:47 2018', queued=0ms, exec=13536ms


Daemon Status:
  corosync: active/enabled
  pacemaker: active/enabled
  pcsd: active/enabled

Démarrez node1. Passez la machine virtuelle en mode graphique avec les commandes suivantes :

[root@node1 ~]# rm -rf /etc/systemd/system/default.target
[root@node1 ~]# ln -s /lib/systemd/system/graphical.target /etc/systemd/system/default.target
[root@node1 ~]# shutdown -r now

Ouvrez un navigateur Internet et ouvrez l'URL https://node1.i2tch.loc:2224. Connectez-vous avec l'utilisateur hacluster.

Pour plus d'information concernant l'interface HTML, consultez ce lien.


<html> <DIV ALIGN=“CENTER”> Copyright © 2020 Hugh Norris. </DIV> </html>

Menu