Procédure de tests et remise en service du Cluster

Version	1.0
Date	Aug, 2018
Approved by

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 disposer les serveurs 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’une des 2 salles.

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

L’ensemble des services Linux est piloté par Corosync.Il ne faut en aucun cas utiliser les services standards des démons Linux. Il ne faut pas utiliser les commandes « services » ou « systemctl » ou les scripts automatiques comme « samba ».

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

Goto 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