Différences

Ci-dessous, les différences entre deux révisions de la page.

--- technique:infrastructure:baremetal:proxmox_cluster [2020/02/06 16:28] – ↷ Page déplacée de infrastructure:baremetal:proxmox_cluster à technique:infrastructure:baremetal:proxmox_cluster qduchemi
+++ technique:infrastructure:hyperviseurs:proxmox_cluster [2020/09/29 16:53] (Version actuelle) – supprimée qduchemi
@@ Ligne 1: / Ligne 1: @@
-**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.**
-====Mise en place d'un cluster Proxmox à 2 noeuds====
-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
-.0.0.1	localhost
-.168.10.1 alice
-.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:
-<code>
-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
-  }
-}
-</code>
-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
-<code>
-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
-x00000001          1 192.168.10.1 (local)
-x00000002          1 192.168.10.2
-</code>
-**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
-<code>
-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
-</code>\\
-\\
-Contacts en cas de questions : \\
-[[antoine@barbare.me|Antoine Picasoft]]\\
-[[gregoire@martinache.net|Grégoire Picasoft]]\\