technique:infrastructure:hyperviseurs:proxmox_cluster

Cette documentation ne reflète plus l’infrastructure actuelle de Picasoft. Nous n’utilisons plus un cluster au niveau de Proxmox pour des raisons de robustesse.

La mise en place d’un cluster Proxmox peut poser quelques problèmes si l’on a jamais eu à travailler avec des outils tels que corosync ou heartbeat. Ces outils permettent de détecter les différentes machines et d’effectuer des actions si l’une d’entre elles venait à défaillir.

Je suppose qu’avant d’en arriver à ce stade, vous avez monté deux machines Proxmox indépendantes (voir article)

Une chose à savoir est que lorsque l’on met en place un cluster Proxmox, celui-ci n’est possible que par le biais d’IP de service dans un range privé. Corosync lors de la détection des différents noeuds va lancer des commandes de ping unicast à travers le réseau et il est préférable que cela se fasse sur un réseau privé.

La première chose à faire est de s’assurer que les fichiers etc/hosts sont correctement renseignés avec les différents IP privées des machines. Par exemple:

root@alice:~# cat /etc/hosts
127.0.0.1	localhost
192.168.10.1 alice
192.168.10.2 bob

On peut ensuite vérifier que le unicast fonctionne correctement entre les 2 noeuds sur le hostname Démarrer omping sur les 2 noeuds en inversant les noeuds

Sur le alice : # omping alice bob
Affiche :  alice : waiting for response msg
Sur le bob : # omping bob alice
Affiche sur les 2 noeuds, si tout fonctionne : unicast, seq=4, size=69 bytes, dist=1, time=0.710ms

On peut ensuite créer notre cluster. Sur un noeud, on lance la commande:

pvecm create moncluster

Ensuite, on va modifier le fichier /etc/corosync/corosync.conf pour permettre un cluster à deux noeuds. En effet, en temps normal, les clusters sont composés de trois noeuds afin de permettre l’élection d’un master sans que cela ne pose de problème au niveau des votes (2 votes contre 1). Il faut donc spécifier ici ce type particulier de cluster:

logging {
  debug: off
  to_syslog: yes
}

nodelist {
  node {
    name: alice
    nodeid: 1
    quorum_votes: 1
    ring0_addr: alice
  }
  node {
    name: bob
    nodeid: 2
    quorum_votes: 1
    ring0_addr: bob
  }
}

quorum {
  provider: corosync_votequorum
  two_node: 1
}

totem {
  cluster_name: picasoft
  config_version: 2016120703
  ip_version: ipv4
  secauth: on
  transport: udpu
  version: 2
  interface {
    ringnumber: 0
  }
}

Cette modification est à effectuer sur les deux noeuds. Attention à bien mettre à jour le champ config_version à chaque modification de ce fichier (sur les deux noeuds).

Une fois cette configuration appliquée, on peut relancer le processus corosync et voir l’état du cluster

  
systemctl restart corosync.service
root@alice:~# pvecm status
Quorum information
------------------
Date:             Wed Dec  7 23:12:08 2016
Quorum provider:  corosync_votequorum
Nodes:            2
Node ID:          0x00000001
Ring ID:          1/44
Quorate:          Yes

Votequorum information
----------------------
Expected votes:   2
Highest expected: 2
Total votes:      2
Quorum:           1
Flags:            2Node Quorate WaitForAll

Membership information
----------------------
    Nodeid      Votes Name
0x00000001          1 192.168.10.1 (local)
0x00000002          1 192.168.10.2

Problème rencontré:

Lors de la mise en place de notre cluster, nous avons été confrontés à un problème. Du fait que nous montons les Ip de la machine via le fichier /etc/rc.local, l’interface réseau n’est pas prête (avec une IP) au lancement de corosync au boot. Une manière simple de contourner ce problème est de relancer corosync lorsque celui-ci ne démarre pas. Ainsi dès que l’IP sera monté, le redémarrage de corosync sera fonctionnel et le cluster prêt à être utilisé.

Dans le fichier /etc/systemd/system/multi-user.target.wants/corosync.service, on ajoute deux directives

root@alice:~# cat /etc/systemd/system/multi-user.target.wants/corosync.service
[Unit]
Description=Corosync Cluster Engine
ConditionKernelCommandLine=!nocluster
ConditionPathExists=/etc/corosync/corosync.conf
Requires=network-online.target
After=network-online.target
DefaultDependencies=no
Before=shutdown.target
Conflicts=shutdown.target

[Service]
ExecStart=/usr/share/corosync/corosync start
ExecStop=/usr/share/corosync/corosync stop
Restart=on-failure #À ajouter
RestartSec=5s #À ajouter
Type=forking

[Install]
WantedBy=multi-user.target



Contacts en cas de questions :
Antoine Picasoft
Grégoire Picasoft

  • technique/infrastructure/hyperviseurs/proxmox_cluster.1581002898.txt.gz
  • de qduchemi