====== Pacemaker ====== ===== Installation ===== Il est tout d'abord très important que les machines puissent communiquer entre elle avec leur nom (court ou //fqdn//). Si la résolution DNS ne le permet pas, ajouter les lignes nécessaires dans le fichier ///etc/hosts//. * Installation sur les deux machines : apt-get install pacemaker crmsh * Sur la machine 1 : * Création de la clé partagér (**Astuce :** Pour la génération d'entropy si vous être connecté à distance vous pouvez utiliser [[informatique:outils:rng-tools]]) : corosync-keygen * Éditer le fichier ///etc/corosync/corosync.conf// : * ajuster le paramètre //cluster_name// * modifier le paramètre //crypto_cipher// : //aes256// * modifier le paramètre //crypto_hash// : //sha512// * modifier la partie configurant l'interface d'écoute : interface { # The following values need to be set based on your environment ringnumber: 0 bindnetaddr: 192.168.3.0 mcastaddr: 239.255.1.1 mcastport: 5405 ttl: 1 } * Si votre cluster n'est composé que de deux noeuds, ajouter le paramètre //two_node// à //1// dans la section //quorum// * Ajouter une section //nodelist// comme suit et en ajuster l'IP d'écoute des noeuds : nodelist { node { ring0_addr: 192.168.3.207 } node { ring0_addr: 192.168.3.208 } } * Si vous souhaitez utiliser une deuxième interfaces réseaux simultanément pour les dialogues entre les nodes corosync, il suffit ajouter un deuxième bloques //interface// en incrémentant //ringnumber//, en modifiant //bindnetaddr// et en veillant à se que //mcastaddr// et //mcasport// soient différents que pour l'autre interface. Il faudra également passer mettre //rrp_mode// à //active//. Si vous utilisez OCFS2 entre autre, il est nécesaire d'activer le service //cktp// fournis par //openais// (le paquet du même nom doit être installé). Pour cela, créer le fichier ///etc/corosync/service.d/cktp// et ajouter y les lignes suivantes :service { name: openais_ckpt ver: 0 } * Sur la machine 2, faite un rsync de l'ensemble du dossier ///etc/corosync// * Sur les deux machines, redémarrer le service //corosync// puis //pacemaker// L'installation est prête a être configurée. La commande //crm status// devrait retourné quelque chose comme : Stack: corosync Current DC: ldap1 (version 1.1.16-94ff4df) - partition with quorum Last updated: Mon Mar 11 15:54:50 2019 Last change: Mon Mar 11 15:54:25 2019 by hacluster via crmd on ldap1 2 nodes configured 0 resources configured Online: [ ldap1 ldap2 ] No resources ===== Communication Unicast ===== Par défaut, le dialogue entre les nodes se fait en multicast. Il peut être utile dans certain cas de configurer celui-ci en unicast. Pour cela, //**Corosync**// support l'//**UDP Unicast**// (ou //**UDPU**//) depuis sa version //1.3.0// (pour **Debian**, il faut au moins la version disponible dans //squeeze-backports//). La configuration du mode Unicast ce fait comme expliquer ci dessus aux exceptions décrite ci-dessous : totem { [...] interface { ringnumber: 0 bindnetaddr: 10.32.0. member { memberaddr: 10.32.0.10 } member { memberaddr: 10.32.1.11 } mcastaddr: 226.94.1.6 mcastport: 5605 } transport: udpu } ===== Configuration de base pour un cluster à deux nœuds ===== Nous allons entre autre mettre en place un //ping// régulier pour s'assurer de la bonne connectivité réseaux des machines. Cette //primitive// pourra être utilisé pour établir les règles de localisation des ressources. * Pour accéder à la configuration du cluster pacemaker, entrer dans //crm//, passer en mode //configure// et utilisez la commande //edit// pour éditer la configuration : root@ldap1:~# crm crm(live)# configure crm(live)configure# edit * Un éditeur vous ouvrira alors la configuration du cluster. Modifier la comme dans l'exemple suivant : node 1084754508: ldap1 node 1084754509: ldap2 primitive pinggw ocf:pacemaker:ping \ params host_list="192.168.3.1 192.168.3.2" multiplier=100 dampen=5s name=pinggwval \ op monitor interval=10s timeout=100s \ op start interval=0 timeout=100s \ op stop interval=0 timeout=100s clone clonepinggw pinggw property cib-bootstrap-options: \ have-watchdog=false \ dc-version=1.1.16-94ff4df \ cluster-infrastructure=corosync \ cluster-name=ldap \ stonith-enabled=false \ no-quorum-policy=ignore * Si vous ne souhaitez pas que vos ressources migrent après un //recovery// ajouter : rsc_defaults rsc-options: \ resource-stickiness=100 * Quitter l'éditeur en enregistrant * Appliquer la nouvelle configuration en exécutant la commande //commit// * Vous pouvez constater le nouveau status en remontant d'un niveau avec la commande //cd// puis en exécutant la commande //status// ===== Exemple de mise en place d'une VIP ===== Nous allons mettre en place dans cette exemple : * Une primitive //vip-ldap// correspondant à la VIP * Une règle de location //vip-ldap-on-connected-host-only// définissant que la VIP ne doit tourner que sur un noeud connecté au réseau (sur la base de l'état de la valeur de la variable //pinggwval// défini par la primitive //pinggw// cloné sur les deux machines sous le nom //clonepinggw//). * Une règle de location //vip-ldap-on-ldap1// indiquant une préférence pour faire tourner la VIP sur la machine //ldap1// Pour cela : * Éditer la configuration du cluster et ajouter les lignes suivantes en ajustant de paramètre de configuration de la VIP : primitive vip-ldap IPaddr2 \ params ip=192.168.3.79 nic=ens192 cidr_netmask=24 \ meta migration-threshold=2 \ op monitor interval=20 timeout=60 on-fail=restart location vip-ldap-on-connected-host-only vip-ldap \ rule -inf: not_defined pinggwval or pinggwval lt 100 location vip-ldap-on-ldap1 vip-ldap 50: ldap1 ===== Trucs et astuces ===== ==== Eviter que l'arrêt de ressources clonés au redémarrage d'un node ==== - Lorsque des ressources clonés sont ordonnés, au redémarrage d'un node, pour respecter l'ordre, les ressources du node déjà actif sont arrêtées puis relancer en même temps que le node arrivant. Pour éviter cela définissez vos clones comme cela : clone cl_res res \ params interleave="true" - Si une node a par exemple monté une ressource drbd suite à la défaillance du master et que vous voulez le repasser sur la machine de nouveau opérationnelle : On liste les ressources crm_resource -l Puis on migre la resource crm_resource --resource --move --node