Afficher le texte source Anciennes révisions Liens de retour Ajouter au livre. Exporter en PDF Exportation ODT Créateur de livres Ajouter cette page à votre livre Créateur de livres Retirer cette page de votre livre Voir ou modifier le livre (0 pages) Aide 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 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 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éeCommandes systèmes Vérification de l’état du cluster service corosync status Voir les nœuds du clustercrm 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éeCommandes systèmes Indication de l’état de pacemakersystemctl status pacemaker Vérification du bon fonctionnement de pacemakersystemd-analyze verify pacemaker.service Recharger la configuration du servicesystemctl 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 pacemakermore Table des matières FAQ : Procédure de tests et remise en service du Cluster Description Prérequis Schéma de Raccordement Fonctionnement du Cluster Les services Linux utilisés pour le Cluster sont Les services configurés et monitorés par le Cluster sont Page Web de supervision du serveur Vérification de la synchronisation des données du cluster Validation du bon fonctionnement du cluster (COROSYNC) Description du fichier de configuration Le premier bloc indique l’état du cluster Le deuxième bloc indique quel est le nœud primaire, et où sont les services Vérification du bon fonctionnement du cluster Commandes de vérification du bon fonctionnement du cluster Exemple pour « abjairsvr2 » Vérification des outils de gestion du cluster