Préparation du cluster

Vous avez déjà un serveur que vous avez nommé pve1. Corriger les fichiers :

/etc/network/interfaces pour affecter les bonnes adresses IP ;
/etc/hosts pour une bonne résolution mutuelle du nom local de chaque hôte ;
/etc/hostname pour corriger, entre autres, le prompt.

ATTENTION : les serveurs doivent être référencés dans /etc/hosts avec leurs adresses du réseau privé des hôtes. Voir plus bas…

Cloner pve1 en pve2 et pve3, et corriger les fichiers sur ces derniers.

Penser à modifier les certificats SSL des clones.

Installation du réseau privé des hôtes

Il faut ensuite configurer le réseau privé des hôtes qui servira pour NTP, Corosync et CephFS ((PVE conseille des mettre en place des réseaux différents, mais ça fonctionne très bien avec un seul réseau pour les trois services, y compris en 1Gbt.

Dans cet exemple, ce sera un réseau en 10.10.10.0/24. Attention que ce réseau ne soit pas en conflit avec vos autres réseaux (administration et production).

Il existe deux méthodes :

avec un switch rapide entre les 3 machines, mais ce n'est pas redondant ;
ou en créant directement un réseau mesh, comme décrit dans la documentation d'installation de CephFS, en utilisant, par exemple, des cartes réseau 10Gbt dotées de deux ports chacunes ;
ou en créant un triangle de bridges …

il faut documenter le multicast et omping omping -c 10000 -i 0.001 -F -q 192.168.200.3 192.168.200.2

# Réseau privé
iface enp3s1 inet manual
 
iface enp3s2 inet manual
 
auto vmbr9
iface vmbr9 inet static
	address 192.168.200.3
	netmask 255.255.255.0
	bridge_ports enp3s1 enp3s2
	bridge_stp on
 
#Réseau de prod
iface ens33 inet manual
 
auto vmbr0
iface vmbr0 inet static
	address  10.44.255.3
	netmask  255.255.0.0
	gateway  10.44.255.254
	bridge_ports ens33
	bridge_stp off
	bridge_fd 0

Intallation de NTP

Cette section est à reprendre en rappel de la description de NTP à venir ! Pour installer un cluster PVE, il est indispensable d'installer une synchonisation des horloges des hôtes entre elles..

Il faut d'abord arrêter le service TimeSync de systemd qui est activé par défaut sur une débian :

# systemctl stop systemd-timesyncd.service 
# systemctl disable systemd-timesyncd.servic

Ensuite, installer le démon ntp, et corriger le fichier /etc/ntp.conf comme suit :

un serveur de référence (de strate 2, à 172.16.255.254) ;
deux pairs, les autres PVE du futur cluster, si vous voulez un cluster ;
l'horloge RTC de la machine locale, qui sera comprise comme un serveur de strate 10.

Bien sur, il faut autoriser nos pairs NTP à dialoguer, via le réseau privé en 10.10.10.0/24. Ci dessous l'exemple sur le membre 3 du cluster.

# la référence
server 172.16.255.254

# les pairs
peer 10.10.10.1
peer 10.10.10.2
#peer 10.10.10.3

# la RTC comprise comme strate 10
server  127.127.1.0     # local clock
fudge   127.127.1.0 stratum 10

# Autoriser les requêtes des autres PVE
restrict 10.10.10.0 netmask 255.255.255.0

Un controle rapide permet de vérifier la bonne synchronisation, ici sur pve3 :

# ntpq -p

     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
+172.16.255.254  145.238.203.14   2 u   45  128  377    0.115   31.877   5.254
*10.10.10.1      172.16.255.254   3 s   78  128  377    0.073   15.575   9.960
+10.10.10.3      10.10.10.1       4 s   13  128  377    0.028    5.774   1.166
 LOCAL(0)        .LOCL.          10 l  49m   64    0    0.000    0.000   0.000

Nous sommes bien synchronisés sur le serveur et proche d'une convergence entre les pairs.

Le status du service de temps nous confirme que nous ne sommes pas synchro par le réseau (c'est pas systemd qui fait le taff) mais bien sous le controle d'un service NTP :

# timedatectl
      Local time: mer. 2017-11-08 13:16:49 CET
  Universal time: mer. 2017-11-08 12:16:49 UTC
        RTC time: mer. 2017-11-08 12:16:49
       Time zone: Europe/Paris (CET, +0100)
 Network time on: no
NTP synchronized: yes
 RTC in local TZ: no

Forçage de la RTC

L'horloge hardware (RTC) peut être décalée par rapport au temps système, ici de 29ms.

# date -Ins && hwclock
2021-06-30T09:17:10,950590651+02:00
2021-06-30 09:17:10.921348+02:00

On peut rectifier ça à la main. Dans cet exemple, on constate un écart de 8s entre avant et après la mise à jour.

 
# hwclock && hwclock --systohc && hwclock 
2021-02-26 23:11:04.155197+01:00
2021-02-26 23:11:12.717703+01:00

Il est possible d'automatiser ça, en rajoutant un fichier dans /etc/cron.daily.

# cat /etc/cron.daily/mfa-systohc 
#!/bin/sh

# Tous les jours, on force la maj de l'horloge RTC
/usr/sbin/hwclock --systohc

Cluster

La mise en place du cluster est décrite ici. Elle est reprise pas à pas, conformément à notre exemple.

Création

root@pve51:~# pvecm create LeCluster
Corosync Cluster Engine Authentication key generator.
Gathering 1024 bits for key from /dev/urandom.
Writing corosync key to /etc/corosync/authkey.

root@pve51:~# pvecm status
Quorum information
------------------
Date:             Thu May 18 01:27:13 2017
Quorum provider:  corosync_votequorum
Nodes:            1
Node ID:          0x00000001
Ring ID:          1/4
Quorate:          Yes

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

Membership information
----------------------
    Nodeid      Votes Name
0x00000001          1 10.10.10.1 (local)

Ajout du 2ème membre

root@pve52:~# pvecm add 10.10.10.1
root@10.10.10.1's password: 
copy corosync auth key
stopping pve-cluster service
backup old database
waiting for quorum...OK
generating node certificates
merge known_hosts file
restart services
successfully added node 'pve52' to cluster.
root@pve52:~# pvecm status
Quorum information
------------------
Date:             Thu May 18 01:29:39 2017
Quorum provider:  corosync_votequorum
Nodes:            2
Node ID:          0x00000002
Ring ID:          1/8
Quorate:          Yes

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

Membership information
----------------------
    Nodeid      Votes Name
0x00000001          1 10.10.10.1
0x00000002          1 10.10.10.2 (local)

Ajout du 3ème membre

Ce membre n'a jamais ouver de session SSH avec pve1 avant, d'où l'avertissement classique que l'on acquitte par yes.

root@pve53:~# pvecm add 10.10.10.1
The authenticity of host '10.10.10.1 (10.10.10.1)' can't be established.
ECDSA key fingerprint is SHA256:1IIiN+hYK9OUBlmRznE6PKDyBgeVikGqdJWscZcVBmc.
Are you sure you want to continue connecting (yes/no)? yes
root@10.10.10.1's password: 
copy corosync auth key
stopping pve-cluster service
backup old database
waiting for quorum...OK
generating node certificates
merge known_hosts file
restart services
successfully added node 'pve53' to cluster.
root@pve53:~# pvecm status
Quorum information
------------------
Date:             Thu May 18 01:32:15 2017
Quorum provider:  corosync_votequorum
Nodes:            3
Node ID:          0x00000003
Ring ID:          1/12
Quorate:          Yes

Votequorum information
----------------------
Expected votes:   3
Highest expected: 3
Total votes:      3
Quorum:           2  
Flags:            Quorate 

Membership information
----------------------
    Nodeid      Votes Name
0x00000001          1 10.10.10.1
0x00000002          1 10.10.10.2
0x00000003          1 10.10.10.3 (local)

Changement du réseau Corosync

:!:FACULTATIF : Si vous n'avez pas pensé à utiliser le réseau privé entre les hôtes aussi pour créer le cluster, on peut reprendre à la main la configuration de Corosync.

Il suffit de suivre la procédureprocédure indiquée ici, principalement la section “Separate After Cluster Creation”.

Le fichier à éditer est /etc/pve/corosync.conf car il est répliqué grâce à pveFS sur toutes les machines. Par contre, il faut redémarrer Corosync sur CHAQUE machine, pour que l'hôte membre rejoigne le nouveau cluster.