====== 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 ===== {{:faq:materiel:schema_raccordement.png?2000|}} ===== 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 ===== Aller sur la page ''http://ip_server/web/system/ezmonitor''  {{cluster_Image_1.png}} ===== 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__'' {{cluster_Image_2.png}} 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''. {{cluster_Image_3.png}} La commande renvoie la configuration et l’état du cluster : {{cluster_Image_4.png}} ====== 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__ : {{cluster_Image_5.png}} ===== 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|