Table des matières
FAQ : Procédure de tests et remise en service du Cluster
Description
Un cluster de serveur est composé de 2 serveurs rigoureusement identiques configurés en haute disponibilité normal / secours.
Le premier serveur en mode normal est appelé « primaire », le serveur de secours est appelé « secondaire ».
Prérequis
Au minimum, chaque serveur utilise 3 cartes réseaux configurées comme suit :
- ETH1 = Interface réseaux principal = IP_Server
- ETH2 = Interface réseaux « bridgé » pour les machines virtuelles = IP_Br0
- ETH3 = Interface réseaux « Privé » de synchronisation des Serveurs, liaison directe entre les nœuds du cluster.
Sur les serveurs HP, l’interface d’administration HP_ILO de monitoring de la machine peut être paramétrée pour bénéficier des informations de l’état Physique du serveur (voir documentation de monitoring ILO).
Les 2 serveurs sont connectés entre eux par un lien permettant de les disposer dans 2 locaux techniques différents et distants. Cela permet d’assurer l’intégrité physique des équipements et la non propagation d’un dégât physique sur l’un des 2 serveurs.
Schéma de Raccordement
Fonctionnement du Cluster
Les services Linux utilisés pour le Cluster sont
- Drbd = Réplication des données entre les espaces disques
- Corosync = Configuration et ordonnancement des services du Cluster
- Peacemaker = Monitoring des services du cluster
Les services configurés et monitorés par le Cluster sont
- Apache = Serveur web
- MySQL = Base de données
- Samba = Partage de fichiers
- Libvirtd = Moteur de Virtualisation KVM
- Libvirtguest = Outils de gestion de la virtualisation
- Cluster IP / cluster Route = Nœud réseaux actif
Tout déclenchement des services par ce type de commande annule la surveillance système par peacemaker et corosync.
Page Web de supervision du serveur
Aller sur la page http://ip_server/web/system/ezmonitor
Vérification de la synchronisation des données du cluster
Dans un terminal, ou par accès ssh sur un des nœuds du cluster, utiliser la commande drbd-overview
Ici les 2 serveurs primaire et secondaire sont parfaitement synchronisés au niveau des données puisque le statut UpToDate est effectif sur les 2 serveurs.
Primary/Secondary Uptodate/Uptodate montre l’état de synchronisation des 2 nœuds du cluster.
Dans le cas où le service DRBD n’est pas démarré correctement (Cluster hors service), il est possible de redémarrer le service de synchronisation des données du serveur via la commande suivante :
# service drbdserv –full-restart
Validation du bon fonctionnement du cluster (COROSYNC)
Les commandes liées au service Corosync et peacemaker sont préfixées par crm .
Pour connaitre l’état des services gérés par le cluster via un terminal ou par accès ssh, utiliser la commande crm status.
La commande renvoie la configuration et l’état du cluster :
Description du fichier de configuration
Le premier bloc indique l’état du cluster
Last updated: Sun Sep 23 08:21:21 2018
Last change: Tue Aug 28 09:42:27 2018 via crm_attribute on dzacupsvr2
Stack: corosync
Current DC: dzacupsvr2 (34212362) - partition with quorum
Version: 1.1.7-2.mga1-ee0730e13d124c3d58f00016c3376a1de5323cff
2 Nodes configured, unknown expected votes
11 Resources configured.
Le deuxième bloc indique quel est le nœud primaire, et où sont les services
Online: [ dzacupsvr dzacupsvr2 ]
Resource Group: services
samba (lsb:smb): Started dzacupsvr
apache (ocf::heartbeat:apache): Started dzacupsvr
mysql (ocf::heartbeat:mysql): Started dzacupsvr
libvirtd (lsb:libvirtd): Started dzacupsvr
libvirt-guests (lsb:libvirt-guests): Started dzacupsvr
Master/Slave Set: drbdservClone [drbdserv]
Masters: [ dzacupsvr ]
Slaves: [ dzacupsvr2 ]
fsserv (ocf::heartbeat:Filesystem): Started dzacupsvr
Resource Group: iphd
clusterip (ocf::heartbeat:IPaddr2): Started dzacupsvr
clusterroute (ocf::heartbeat:Route): Started dzacupsvr
⇒ Les 2 serveurs sont « en ligne », et chaque service est opérationnel sur le primaire.
Vérification du bon fonctionnement du cluster
Pour voir la configuration du cluster, utiliser la commande suivante :
# crm configure show
Exemple de fichier de configuration du cluster d’Abidjan :
Commandes de vérification du bon fonctionnement du cluster
Exemple pour « abjairsvr2 »
| Action souhaitée | Commandes systèmes |
| Vérification de l’état du cluster | service corosync status |
| Voir les nœuds du cluster | crm node |
| Voir la configuration du cluster | crm configure show |
| Editer la configuration du cluster | crm configure edit |
| Mettre un nœud du cluster en standby le temps de modifier une configuration | crm node standby abjairsvr2 |
| Remettre en service un noeud du cluster (ici le secondaire d’abidjan) | crm node online abjairsvr2 |
| Changer un parameter de configuration du cluster | crm configure rsc_defaults resource-stickiness=100 |
| Voir l’état d’un service du cluster | crm resource libvirt-guests status |
| Purger un service du cluster qui ne démarre pas | crm resource cleanup libvirt-guests |
| Vérifier l’existance ou non d’un split brain (service ayant migré vers un nœud non opérationnel) | grep “split-brain” /var/log/syslog |
| Déplacer un service d’un noeud à l’autre (dans le cas d’un split brain) | crm resource move libvirt-guests abjairsvr2 |
| Rattacher un service au cluster | crm resource manage libvirt-guests |
| Vérifier le que les fichiers de configuration sont identiques entre les noeuds d’un serveur | crm cluster diff /etc/samba/smb.conf |
Vérification des outils de gestion du cluster
| Action souhaitée | Commandes systèmes | |
| Indication de l’état de pacemaker | systemctl status pacemaker | |
| Vérification du bon fonctionnement de pacemaker | systemd-analyze verify pacemaker.service | |
| Recharger la configuration du service | systemctl pacemaker.service reload | |
| S’assurer que systemcl prend encharge el service | systemd-delta pacemaker.service | |
| Rechercher les erreurs dans le journal d’évènement | journalctl -u pacemaker | more |