« LINUX:Pacemaker - Configuration de base » : différence entre les versions

De WIKI sur Linux (ADB)
Aller à la navigation Aller à la recherche
Aucun résumé des modifications
Aucun résumé des modifications
 
(19 versions intermédiaires par le même utilisateur non affichées)
Ligne 6 : Ligne 6 :




=Matériel=
=Matériel et adressage IP=
Pour ces exercices, nous avons besoin de deux machines, chacune avec deux interfaces réseaux. Le schéma ci-dessous reprend la connectique et l'adressage IP.
Pour ces exercices, nous avons besoin de deux machines, chacune avec deux interfaces réseaux. Le schéma ci-dessous reprend la connectique, le nom des machines Linux et leur adressage IP.


[[FILE:LINUX:Pacemaker.base.pdf|center|800px]]


[[FILE:LINUX:Pacemaker.base.pdf|center|800px]]
=Configuration de Pcs sur toutes les machines du cluster=
Toute la configuration va se passer à l'aide du programme en ligne de commande "pcs". En premier lieu, il faut initier ce cadre de travail sur toutes les machines du cluster afin qu'elles puissent communiquer.




=Prérequis=
==Initialisation du mot de passe==
Sur les deux machines du cluster, un utilisateur "hacluster" est créé. Il va servir au transfert d'informations sécurisé. Son utilisation est désactivé. Pour le rendre utilisable, il faut initialiser le mot de passe par la commande suivante:
passwd hacluster
Il demande le nouveau mot de passe et sa confirmation. Nous attribuerons le mot de passe: "Chasse4321Eau" (A adapter à votre convenance. Cette tâche est à effectuer sur chaque machine du cluster.




==Uniformisation des noms des interfaces réseaux==
==Service "pcsd.service"==
Il est conseillé et dans une situation future, que les noms des interfaces réseaux soient uniformisés sur les différentes machines du cluster.
Pour effectuer la configuration, on utilisera la commande de ligne "pcs" qui va transmettre nos ordres au service local "pcsd.service". Il va le transmettre aux services équivalent "pcsd.service" s'exécutant également sur les autres machines du cluster. Ce qui nous permettra de faire ces manipulation qu'à partir d'une seule machine.
* Du côté du réseau "192.168.1.0/24", nous avons opté pour le nom "eth1".
* Du côté du réseau "192.168.2.0/24", nous avons opté pour le nom "eth2".
Pour effectuer cette tâche, voyez l'article traitant du [[LINUX:Renommage du nom de l'interface réseau|Renommage du nom de l'interface réseau]].




==Selinux==
Mais en premier lieu, nous désirons restreindre ce trafic à la couche IPV4. Dans le fichier de configuration de ce service "'''/etc/sysconfig/pcsd''''", on ajoute la ligne:
Pour une question de facilité, nous désactivons la couche Selinux. Pour y arriver, on change la ligne suivante dans le fichier "/etc/selinux/config":
----
----
  SELINUX=enforcing
  PCSD_BIND_ADDR='0.0.0.0'
----
----
par:
On remarque au passage, dans ce fichier, que le port d'écoute TCP de ce service est par défaut le 2224 ("PCSD_PORT=2224").
 
 
On peut maintenant lancer ce service:
systemctl start pcsd.service
 
 
Ces opérations sont à faire sur toutes les machines du cluster.
 
 
A ce stade, on peut constater qu'un nouveau port est à l'écoute. La commande suivante:
netstat -nltp | grep 2224
donne:
----
----
  SELINUX=disabled
  tcp        0      0 0.0.0.0:2224            0.0.0.0:*              LISTEN      14864/python3     
----
----




==Fichier "hosts"==
=Configuration centralisée grâce à Pcs=
Sur chaque machine du cluster, on ajoute un nom aux différentes adresses réseaux. On le fait en local dans le fichier "/etc/hosts" suivant le schéma ci-dessus. Son contenu devient:
Maintenant nous pouvons commencer la configuration de Pacemaker et de Corosync.
 
 
==Définir les machines faisant partie du cluster==
La commande suivante permet d'ajouter les machines qui vont converser ensemble:
pcs host auth fo1.home.dom fo2.home.dom -u hacluster -p Chasse4321Eau
Nous y trouvons le nom de nos deux machines.
On y constate également notre utilisateur Unix "hacluster" et son mot de passe "Chasse4321Eau". Ces deux paramètres additionnels nous évitent que la commande ne nous les demande interactivement.
Elle s'échange une clé sécurisée comme le protocole Ssh, pour pouvoir s'abstenir à l'avenir de devoir s'authentifier par le couple nom d'utilisateur/mot de passe.
 
 
==Création du cluster==
La commande suivante crée le cluster auquel nous avons donné de nom de "fo_cluster" et qui va inclure nos deux machines.
Par la même occasion, Corosync va être configuré. Il utilisera le protocole crypté "knet" en utilisant le port UDP multicast 5420 sous IPV4.
pcs cluster setup fo_cluster fo1.home.dom addr=192.168.1.71 fo2.home.dom addr=192.168.1.72 transport knet ip_version=ipv4 link transport=udp mcastport=5420
Si vous avez plusieurs clusters qui cohabitent, donnez un n° de port différent. Le n° de port par défaut est 5405.
 
 
==Fichier de configuration de Corosync==
Notre action précédente a créé le fichier de configuration de Corosync "/etc/corosync/corosync.conf" dont voici le contenu:
----
----
  127.0.0.1  localhost localhost.localdomain localhost4 localhost4.localdomain4
  totem {
::1        localhost localhost.localdomain localhost6 localhost6.localdomain6
    version: 2
    '''cluster_name: fo_cluster'''
    '''transport: knet'''
    '''ip_version: ipv4'''
    crypto_cipher: aes256
    crypto_hash: sha256
    cluster_uuid: b7c29a052377490da9c146c33d671672
   
   
'''192.168.1.71 fo1.home.dom'''
    interface {
'''192.168.1.72 fo2.home.dom'''
        '''knet_transport: udp'''
        linknumber: 0
      ''' mcastport: 5420'''
    }
}
   
   
  192.168.2.71 fd1.data.dom  
  nodelist {
192.168.2.72 fd2.data.dom
    node {
        '''ring0_addr: 192.168.1.71'''
        '''name: fo1.home.dom'''
        nodeid: 1
    }
   
   
# serveur mail
    node {
192.168.1.110 servermail.home.dom home.dom
        '''ring0_addr: 192.168.1.72'''
        '''name: fo2.home.dom'''
        nodeid: 2
    }
}
 
quorum {
    provider: corosync_votequorum
    '''two_node: 1'''
}
 
logging {
    to_logfile: yes
    logfile: /var/log/cluster/corosync.log
    to_syslog: yes
    timestamp: on
}
----
----
Pour nos exemples, les lignes 4 et 5 sont nécessaires.
Vous y retrouvez les paramètres introduits par la commande "pcs" précédente (en gras).
 
Remarquez au passage le paramètre spécial "two_node: 1". Il est propre au cas d'un cluster composé de seulement deux machines. Normalement pour qu'un cluster puisse démarrer, il faut 50% des machines '''+ 1''', c'est à dire '''2''' ou 100% dans ce cas pour que le cluster démarre, si cette option n'est pas définie. Cette notion est connue sous le nom de "quorum". Ce paramètre permet d'outrepasser cette règle pour la ramener à 50% pour deux machines. Par défaut, chaque machine a une voie (ou vote). C'est ce nombre de voies actives qui est à comparer au nombre total de voies possible, et qui équivaut par défaut au nombre de machines du cluster, pour en définir le pourcentage actif.




==Postfix==
==Activation et lancement du cluster==
Dans tous les applications futures, on demandera à Pacemaker de nous avertit de l'état du cluster par mail. Il nous faut donc configurer Postfix au minimum pour transférer ce message à notre serveur de messagerie central "192.168.1.110" ayant le nom de domaine "home.dom". Voyez l'article [[LINUX:Postfix-Configuration des serveurs de messagerie latérale|Postfix-Configuration des serveurs de messagerie latérale]] et parents.
Maintenant nous sommes fin prêts pour activer et démarrer le cluster par les deux commandes qui suivent:
pcs cluster enable --all
pcs cluster start --all
Ces commandes lancent en fait sur toutes les machines du cluster les services "corosync.service" et "pacemaker.service" en plus du service "pcsd.service".


Voici le contenu du fichier "/etc/postfix/main.cf":
Maintenant que Corosync est lancé, la commande suivante sur la machine "fo1.home.dom":
----
netstat -nlup | grep 5420
  # nouveaux paramètres
donne:
  '''relayhost = [192.168.1.110]'''
  udp        0      0 192.168.3.71:5420      0.0.0.0:*                          28367/corosync
inet_protocols = ipv4
Et sur l'autre machine:
# paramètres par défaut
  udp        0      0 192.168.3.72:5420      0.0.0.0:*                          23585/corosync
compatibility_level = 3.7
On y remarque l'apparition du port UDF 5420 comme mis dans le fichier de configuration de Corosync.
  queue_directory = /var/spool/postfix
 
  command_directory = /usr/sbin
 
daemon_directory = /usr/libexec/postfix
==Finalisation==
data_directory = /var/lib/postfix
Nous sommes avec une configuration limitée. Nous désactivons deux fonctions: une action en cas de "quorum" non atteint et une détection de déficience par une ressource tierce.
mail_owner = postfix
  pcs property set no-quorum-policy=ignore
inet_interfaces = localhost
  pcs property set stonith-enabled=false
mydestination = $myhostname, localhost.$mydomain, localhost
 
  unknown_local_recipient_reject_code = 550
=Emplacement des fichiers=
alias_maps = hash:/etc/aliases
Tout un ensemble de fichiers sont générés:
  alias_database = hash:/etc/aliases
* les fichiers de configuration dans les répertoires suivants:
  debug_peer_level = 2
  /etc/corosync
  debugger_command =
  /etc/pacemaker
    PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin
* les journaux dans les répertoires suivants:
    ddd $daemon_directory/$process_name $process_id & sleep 5
  /var/log/pcsd
  sendmail_path = /usr/sbin/sendmail.postfix
  /var/log/cluster
  newaliases_path = /usr/bin/newaliases.postfix
/var/log/pacemaker
  mailq_path = /usr/bin/mailq.postfix
* les autres fichiers de configuration dans les répertoires suivants:
setgid_group = postdrop
/var/lib/corosync
meta_directory = /etc/postfix
  /var/lib/pcsd
shlib_directory = /usr/lib64/postfix
  /var/lib/pacemaker/cib
----
  /var/lib/pacemaker/pengine
Sur base de la configuration de base, on change deux paramètres.
 
 
Un fichier est particulier. Le fichier "/var/lib/pacemaker/cib/cib.xml" contient la configuration de Pacemaker mais ne vous avisez pas de le modifier manuellement. Il est protégé par une signature. Son contenu est instructif.
 
 
Pour repartir de zéro, il faut arrêter les trois services cités ci-dessus et effacer tous les fichiers de ces répertoires




Voici le contenu du fichier "/etc/postfix/main.cf":
=Statut=
On peut visionner l'état du cluster avec la commande suivante:
crm_mon -1
Cette commande peut être exécutée à partir de toute machine du cluster. Elle donne:
----
----
  # ==========================================================================
  Status of pacemakerd: 'Pacemaker is running' (last updated 2023-02-08 11:24:39 +01:00)
# service type  private unpriv  chroot  wakeup  maxproc command + args
  Cluster Summary:
#              (yes)  (yes)  (no)    (never) (100)
   * Stack: corosync
  # ==========================================================================
   * Current DC: fo1.home.dom (version 2.1.5-3.fc37-a3f44794f94) - partition with quorum
pickup   unix  n      -      n      60      1      pickup
   * Last updated: Wed Feb 8 11:24:39 2023
cleanup  unix  n      -      n      -      0      cleanup
  * Last change: Wed Feb 8 11:24:34 2023 by root via cibadmin on fo1.home.dom
qmgr      unix  n      -      n      300    1      qmgr
  * 2 nodes configured
tlsmgr   unix  -      -      n      1000?  1       tlsmgr
   * 0 resource instances configured
rewrite  unix  -       -       n      -       -      trivial-rewrite
   
bounce   unix -      -      n      -      0      bounce
  Node List:
  defer    unix -      -      n      -      0      bounce
  * Online: [ fo1.home.dom fo2.home.dom ]
trace    unix  -      -      n      -      0      bounce
   
verify   unix  -      -      n      -      1      verify
  Active Resources:
flush    unix  n      -      n      1000?  0       flush
   * No active resources
  proxymap  unix  -      -      n      -      -      proxymap
  proxywrite unix -      -      n      -      1      proxymap
smtp      unix  -      -      n      -      -      smtp
  showq    unix  n      -      n      -      -      showq
error    unix  -      -      n      -      -      error
  retry    unix  -      -      n      -      -      error
discard  unix  -      -      n      -      -      discard
local    unix  -      n      n      -      -      local
lmtp      unix  -      -      n      -      -      lmtp
anvil    unix  -      -      n      -      1      anvil
scache   unix  -      -      n      -      1      scache
postlog  unix-dgram n  -      n      -      1      postlogd
----
----
La configuration par défaut est suffisante; nous avons éliminé tous les processus à l'écoute.
Le paramètre "-1" permet d'avoir un affichage unique. S'il n'est pas spécifié, l'affichage est perpétuel et se rafraichit régulièrement de façon similaire à la commande "top".


Enfin nous ajoutons à la fin du fichier "/etc/aliases", la ligne suivante:
La commande:
pcs status
donne un résultat très proche:
----
----
  root: root@home.dom
  Cluster name: fo_cluster
Status of pacemakerd: 'Pacemaker is running' (last updated 2023-02-08 21:23:37 +01:00)
Cluster Summary:
  * Stack: corosync
  * Current DC: fo1.home.dom (version 2.1.5-3.fc37-a3f44794f94) - partition WITHOUT quorum
  * Last updated: Wed Feb  8 21:23:37 2023
  * Last change:  Wed Feb  8 21:22:50 2023 by root via cibadmin on fo1.home.dom
  * 2 nodes configured
  * 0 resource instances configured
 
  * Online: [ fo1.home.dom fo2.home.dom ]
 
Full List of Resources:
  * No resources
 
Daemon Status:
  corosync: active/enabled
  pacemaker: active/disabled
  pcsd: active/enabled
----
----
Tout message à destination de l'utilisateur "root" local sera redirigé vers l'utilisateur "root@home.dom".
Il reste à activer et lancer ce service:
systemctl enable postfix
newaliases
systemctl start postfix




Ligne 138 : Ligne 212 :
''→ [[LINUX:Haute disponibilité|retour au menu de la Haute disponibilité]]''
''→ [[LINUX:Haute disponibilité|retour au menu de la Haute disponibilité]]''
----
----
__FORCETOC__
__NOEDITSECTION__
__NOEDITSECTION__
[[Category:LINUX]]
[[Category:LINUX]]

Dernière version du 10 juin 2023 à 13:01


retour au menu de la Haute disponibilité


But

Avant d'aborder des cas spécifiques de clusters, on passe d'office par une étape de configuration de base commune à tous les cas. Par la suite, quand on abordera notre cas spécifique de Loadbalancing, deux paramètres seront changés.


Matériel et adressage IP

Pour ces exercices, nous avons besoin de deux machines, chacune avec deux interfaces réseaux. Le schéma ci-dessous reprend la connectique, le nom des machines Linux et leur adressage IP.

LINUX:Pacemaker.base.pdf

Configuration de Pcs sur toutes les machines du cluster

Toute la configuration va se passer à l'aide du programme en ligne de commande "pcs". En premier lieu, il faut initier ce cadre de travail sur toutes les machines du cluster afin qu'elles puissent communiquer.


Initialisation du mot de passe

Sur les deux machines du cluster, un utilisateur "hacluster" est créé. Il va servir au transfert d'informations sécurisé. Son utilisation est désactivé. Pour le rendre utilisable, il faut initialiser le mot de passe par la commande suivante:

passwd hacluster

Il demande le nouveau mot de passe et sa confirmation. Nous attribuerons le mot de passe: "Chasse4321Eau" (A adapter à votre convenance. Cette tâche est à effectuer sur chaque machine du cluster.


Service "pcsd.service"

Pour effectuer la configuration, on utilisera la commande de ligne "pcs" qui va transmettre nos ordres au service local "pcsd.service". Il va le transmettre aux services équivalent "pcsd.service" s'exécutant également sur les autres machines du cluster. Ce qui nous permettra de faire ces manipulation qu'à partir d'une seule machine.


Mais en premier lieu, nous désirons restreindre ce trafic à la couche IPV4. Dans le fichier de configuration de ce service "/etc/sysconfig/pcsd'", on ajoute la ligne:


PCSD_BIND_ADDR='0.0.0.0'

On remarque au passage, dans ce fichier, que le port d'écoute TCP de ce service est par défaut le 2224 ("PCSD_PORT=2224").


On peut maintenant lancer ce service:

systemctl start pcsd.service


Ces opérations sont à faire sur toutes les machines du cluster.


A ce stade, on peut constater qu'un nouveau port est à l'écoute. La commande suivante:

netstat -nltp | grep 2224

donne:


tcp        0      0 0.0.0.0:2224            0.0.0.0:*               LISTEN      14864/python3       


Configuration centralisée grâce à Pcs

Maintenant nous pouvons commencer la configuration de Pacemaker et de Corosync.


Définir les machines faisant partie du cluster

La commande suivante permet d'ajouter les machines qui vont converser ensemble:

pcs host auth fo1.home.dom fo2.home.dom -u hacluster -p Chasse4321Eau

Nous y trouvons le nom de nos deux machines. On y constate également notre utilisateur Unix "hacluster" et son mot de passe "Chasse4321Eau". Ces deux paramètres additionnels nous évitent que la commande ne nous les demande interactivement. Elle s'échange une clé sécurisée comme le protocole Ssh, pour pouvoir s'abstenir à l'avenir de devoir s'authentifier par le couple nom d'utilisateur/mot de passe.


Création du cluster

La commande suivante crée le cluster auquel nous avons donné de nom de "fo_cluster" et qui va inclure nos deux machines. Par la même occasion, Corosync va être configuré. Il utilisera le protocole crypté "knet" en utilisant le port UDP multicast 5420 sous IPV4.

pcs cluster setup fo_cluster fo1.home.dom addr=192.168.1.71 fo2.home.dom addr=192.168.1.72 transport knet ip_version=ipv4 link transport=udp mcastport=5420

Si vous avez plusieurs clusters qui cohabitent, donnez un n° de port différent. Le n° de port par défaut est 5405.


Fichier de configuration de Corosync

Notre action précédente a créé le fichier de configuration de Corosync "/etc/corosync/corosync.conf" dont voici le contenu:


totem {
   version: 2
   cluster_name: fo_cluster
   transport: knet
   ip_version: ipv4
   crypto_cipher: aes256
   crypto_hash: sha256
   cluster_uuid: b7c29a052377490da9c146c33d671672
 
   interface {
       knet_transport: udp
       linknumber: 0
       mcastport: 5420
   }
}
 
nodelist {
   node {
       ring0_addr: 192.168.1.71
       name: fo1.home.dom
       nodeid: 1
   }
 
   node {
       ring0_addr: 192.168.1.72
       name: fo2.home.dom
       nodeid: 2
   }
}
 
quorum {
   provider: corosync_votequorum
   two_node: 1
}
 
logging {
   to_logfile: yes
   logfile: /var/log/cluster/corosync.log
   to_syslog: yes
   timestamp: on
}

Vous y retrouvez les paramètres introduits par la commande "pcs" précédente (en gras).

Remarquez au passage le paramètre spécial "two_node: 1". Il est propre au cas d'un cluster composé de seulement deux machines. Normalement pour qu'un cluster puisse démarrer, il faut 50% des machines + 1, c'est à dire 2 ou 100% dans ce cas pour que le cluster démarre, si cette option n'est pas définie. Cette notion est connue sous le nom de "quorum". Ce paramètre permet d'outrepasser cette règle pour la ramener à 50% pour deux machines. Par défaut, chaque machine a une voie (ou vote). C'est ce nombre de voies actives qui est à comparer au nombre total de voies possible, et qui équivaut par défaut au nombre de machines du cluster, pour en définir le pourcentage actif.


Activation et lancement du cluster

Maintenant nous sommes fin prêts pour activer et démarrer le cluster par les deux commandes qui suivent:

pcs cluster enable --all
pcs cluster start --all

Ces commandes lancent en fait sur toutes les machines du cluster les services "corosync.service" et "pacemaker.service" en plus du service "pcsd.service".

Maintenant que Corosync est lancé, la commande suivante sur la machine "fo1.home.dom":

netstat -nlup | grep 5420

donne:

udp        0      0 192.168.3.71:5420       0.0.0.0:*                           28367/corosync

Et sur l'autre machine:

udp        0      0 192.168.3.72:5420       0.0.0.0:*                           23585/corosync

On y remarque l'apparition du port UDF 5420 comme mis dans le fichier de configuration de Corosync.


Finalisation

Nous sommes avec une configuration limitée. Nous désactivons deux fonctions: une action en cas de "quorum" non atteint et une détection de déficience par une ressource tierce.

pcs property set no-quorum-policy=ignore
pcs property set stonith-enabled=false

Emplacement des fichiers

Tout un ensemble de fichiers sont générés:

  • les fichiers de configuration dans les répertoires suivants:
/etc/corosync
/etc/pacemaker
  • les journaux dans les répertoires suivants:
/var/log/pcsd
/var/log/cluster
/var/log/pacemaker
  • les autres fichiers de configuration dans les répertoires suivants:
/var/lib/corosync
/var/lib/pcsd
/var/lib/pacemaker/cib
/var/lib/pacemaker/pengine


Un fichier est particulier. Le fichier "/var/lib/pacemaker/cib/cib.xml" contient la configuration de Pacemaker mais ne vous avisez pas de le modifier manuellement. Il est protégé par une signature. Son contenu est instructif.


Pour repartir de zéro, il faut arrêter les trois services cités ci-dessus et effacer tous les fichiers de ces répertoires


Statut

On peut visionner l'état du cluster avec la commande suivante:

crm_mon -1

Cette commande peut être exécutée à partir de toute machine du cluster. Elle donne:


Status of pacemakerd: 'Pacemaker is running' (last updated 2023-02-08 11:24:39 +01:00)
Cluster Summary:
  * Stack: corosync
  * Current DC: fo1.home.dom (version 2.1.5-3.fc37-a3f44794f94) - partition with quorum
  * Last updated: Wed Feb  8 11:24:39 2023
  * Last change:  Wed Feb  8 11:24:34 2023 by root via cibadmin on fo1.home.dom
  * 2 nodes configured
  * 0 resource instances configured
 
Node List:
  * Online: [ fo1.home.dom fo2.home.dom ]
 
Active Resources:
  * No active resources

Le paramètre "-1" permet d'avoir un affichage unique. S'il n'est pas spécifié, l'affichage est perpétuel et se rafraichit régulièrement de façon similaire à la commande "top".

La commande:

pcs status

donne un résultat très proche:


Cluster name: fo_cluster
Status of pacemakerd: 'Pacemaker is running' (last updated 2023-02-08 21:23:37 +01:00)
Cluster Summary:
  * Stack: corosync
  * Current DC: fo1.home.dom (version 2.1.5-3.fc37-a3f44794f94) - partition WITHOUT quorum
  * Last updated: Wed Feb  8 21:23:37 2023
  * Last change:  Wed Feb  8 21:22:50 2023 by root via cibadmin on fo1.home.dom
  * 2 nodes configured
  * 0 resource instances configured
 
  * Online: [ fo1.home.dom fo2.home.dom ]
 
Full List of Resources:
  * No resources
 
Daemon Status:
  corosync: active/enabled
  pacemaker: active/disabled
  pcsd: active/enabled




retour au menu de la Haute disponibilité