Cet article reprend celui de 2014 où je vous expliquais la mise en place d’un cluster Proxmox chez Online.
Cette fois, nous allons faire un cluster avec la toute dernière version de Proxmox, la v4.3 et en faisant communiquer nos serveurs via le réseau RPN de chez Online.net. C’est un réseau privé connecté sur une seconde interface réseau physique des serveurs.
Le cluster créé fonctionnera en unicast car le multicast est également bloqué sur le RPN.
Pour faire notre cluster Proxmox, nous allons utiliser 3 serveurs de gamme Dedibox® PRO 2016 de chez Online, qui ont pour chacun la configuration suivante :
– Dell DSS 1510
– Processeur : Intel® Xeon® E5 1650 v3
– Mémoire : 96Go DDR4 ECC
– Disques : 3×500 Go SSD
– Réseau RPN : 1 Gbps
Dans le reste de l’article les serveurs seront nommés de cette façon :
sd-xxx est le serveur 1 avec l’ip publique 163.172.x.x et l’ip privée RPN 10.91.x.x
sd-yyy est le serveur 2 avec l’ip publique 163.172.y.y et l’ip privée RPN 10.91.y.y
sd-zzz est le serveur 3 avec l’ip publique 163.172.z.z et l’ip privée RPN 10.91.z.z
1 – Première étape: installation
Nous allons utiliser l’installation fournie par Online et donc nous rendre dans la console d’administration.
Sur chaque serveur, cliquez sur Installer, choisissez Distributions virtualisation puis cliquez sur Proxmox. Sélectionnez ensuite la version proxmox ve-4 64BITS.
Indiquez vos mots de passe pour root et l’utilisateur.
Pour terminer cliquez sur Effacer l’intégralité de mes disques dur et procéder à l’installation !
Cette installation va prendre un peux plus d’1 heure.
2 – Configuration du réseau RPN :
Depuis la console Online.net, cliquez sur « RPN » puis « Groupes RPN ».
Puis en bas de la page, cliquez sur « Créer un groupe ».
Indiquez le nom du groupe et cochez ensuite les 3 serveurs proxmox puis cliquez sur « Créer un groupe ».
Le groupe est ensuite créé et disponible en quelques secondes.
Ce processus permet de pouvoir faire communiquer nos serveurs via leur interface privée RPN.
3 – Configuration système des machines :
Pour cette étape, je vous conseille d’utiliser la commande cssh, fournie par le paquet clusterssh http://sourceforge.net/apps/mediawiki/clusterssh/. Elle vous permet d’exécuter des commandes sur plusieurs machines en même temps tout en pouvant également n’effectuer qu’une commande sur une machine spécifique. Son utilisation est la suivante :
# cssh root@sd-xxx.dedibox.fr root@sd-yyy.dedibox.fr root@sd-zzz.dedibox.fr
Dans notre cas, 3 shells sont affichés ainsi qu’une fenêtre servant à envoyer nos commandes simultanées.
Connectez vous à vos machines puis vérifiez les mises à jours via les célèbres commandes :
# apt-get update # apt-get upgrade
Notre système est maintenant à jour et nous pouvons éditer le fichier /etc/hosts des machines comme ceci (vim n’est pas installé par défaut, un simple apt-get install vim suffit) :
# vim /etc/hosts 127.0.0.1 localhost 163.172.x.x sd-xxx.dedibox.fr 10.91.x.x sd-xxx pve1 10.91.y.y sd-yyy pve2 10.91.z.z sd-zzz pve3 # The following lines are desirable for IPv6 capable hosts ::1 localhost ip6-localhost ip6-loopback ff02::1 ip6-allnodes ff02::2 ip6-allrouters
Ce fichier doit être identique sur nos 3 serveurs.
Pour terminer les préparatifs pour monter notre cluster, il faut configurer l’interface réseau RPN. Connectez vous sur les interfaces des 3 serveurs et faites la chose suivante sur chacun (en adaptant les adresses IP bien sur) :
Rendez vous dans la section « Network » de la configuration puis double cliquez sur l’interface « eth2 », interface sur laquelle le réseau RPN est câblé, et cochez « autostart » (vous pouvez ajouter le commentaire « RPN » pour ne pas vous perdre).
Créez maintenant l’interface « bridgée » en cliquant sur « Create » puis « Linux Bridge » :
Indiquez l’adresse IP du réseau RPN indiqué depuis la console Online.net :
Pour terminer, il faut redémarrer les serveurs avec un simple :
# reboot
4 – Création du cluster
Nous allons utiliser le serveur sd-xxx pour créer notre cluster. Vous devez vous connecter en ssh à ce serveur puis créer le cluster avec la commande pvecm (nous choisissons le nom de cluster « moncluster ») puis nous ajoutons les paramètres pour forcer les communications du cluster à passer par le réseau privé RPN en indiquant :
-bindnet0_addr avec l’adresse IP RPN de notre machine
-ring0_addr avec l’adresse IP RPN ou le nom de notre machine
# pvecm create moncluster -bindnet0_addr 10.91.x.x -ring0_addr sd-xxx
Le cluster est créé sur la première machine. Nous devons maintenant le configurer pour qu’il utilise l’unicast au lieu du multicast. Pour cela nous allons modifier le fichier de configuration comme ceci :
# vim /etc/corosync/corosync.conf
Puis nous ajoutons cette ligne dans la section « totem { } »
transport: udpu
Pour obtenir ce fichier :
# cat /etc/corosync/corosync.conf logging { debug: off to_syslog: yes } nodelist { node { name: sd-xxx nodeid: 1 quorum_votes: 1 ring0_addr: sd-xxx } } quorum { provider: corosync_votequorum } totem { cluster_name: moncluster config_version: 3 ip_version: ipv4 secauth: on transport: udpu version: 2 interface { bindnetaddr: 10.91.x.x ringnumber: 0 } }
Pour appliquer cette configuration, vous devez redémarrer le serveur.
Une dernière opération consiste à établir une première connexion SSH entre chacun des serveurs afin qu’ils échangent leurs certificats. La commande suivante est à lancée sur chacune des machines :
ssh root@sd-xxx ssh root@sd-yyy ssh root@sd-zzz
5 – Ajout des nodes au cluster.
Notre cluster est maintenant créé et nous pouvons y rajouter nos deux autres nodes. En ssh sur chacune des nodes, nous allons lancer la commande :
# pvecm add 10.91.x.x -ring0_addr sd-yyy
Il faut bien indiquer l’adresse IP de la première machine et le nom de la machine que l’on souhaite rajouter avec l’option « -ring0_addr ».
Un petit bug peut se produire et nous voyons un timeout pour le quorum. La solution que j’ai trouvé, est que nous devons redémarrer les serveurs puis sur la node à rajouter, lancer la commande suivante :
# pvecm add 10.91.x.x -ring0_addr sd-yyy -force
Si vous avez gardé l’interface web visible, vous aurez remarqué que les 3 nodes sont en ligne !
La commande pvecm nodes vous indiquera également le bon fonctionnement du cluster :
# pvecm nodes Membership information ---------------------- Nodeid Votes Name 1 1 sd-xxx 2 1 sd-yyy (local) 3 1 sd-zzz
C’est terminé. Votre cluster Proxmox est maintenant opérationnel et ne passe plus par l’interface publique pour son fonctionnement interne !
Références et liens :
Proxmox Unicast : http://pve.proxmox.com/wiki/Multicast_notes#Use_unicast_instead_of_multicast
Proxmox cluster : https://pve.proxmox.com/wiki/Proxmox_VE_4.x_Cluster
Proxmox Separate Cluster Network : https://pve.proxmox.com/wiki/Separate_Cluster_Network
Merci beaucoup pour ce tuto (toujours très bien foutu!) Un retour sur ces nouveaux serveurs Pro 2016 ? Les SSD, CPU… comparés à la 2015 ?
Merci 🙂 Je suis en train de migrer l’ancienne infra qui était sur du Sata vers ces nouveaux serveurs et les perfs sont pas mal. En tout cas, le temps de restauration des vm est très rapide. Je n’ai par contre pas testé de Pro 2015, je ne peux pas dire.
La version de Proxmox que tu avais lorsque tu as migré sur le nouveau serveur était inférieure (sur la précédente infra) ? Pas de problème de migration ? Merci encore pour ton retour! On est en train également de voir pour passer sur Pro 2015 à Pro 2016 ou ENT, les deux choses qui m’embetent sont le RAID soft et l’unique alim sur la PRO.
Oui, nous sommes en version 3.4-12 sur l’ancien cluster. On fait nos backup sur un autre serveur via NFS et je l’ai configuré sur ce nouveau cluster. Du coup, tu « stop » tes vms, tu les « backup » et depuis le nouveau cluster sur les « restore », en pensant bien à indiquer le bon ID de la vm, ça éviter les problèmes. Et à reconfigurer le réseau pour la partie routage.
Où as-tu vu l’unique alimentation ? Pour le RAID soft, avec les SSD ça tourne bien quand même. Ça me gêne beaucoup plus pour des installations Windows qui du coup sont impossible en physique.
Cool, nous aussi on est en 3.4 sur notre serveur actuel.
Pour l’alimentation j’ai posé la question au support, uniquement dispo à partir de la ENT :/ (ce qui était pas le cas sur la gamme 2015)… quand on sait que c’est une chose qui a une chance assez importante de lâcher.
Pour le SSD, j’ai tenté d’avoir des infos sur le modèle et/ou des tests de vitesses écriture/lecture, ils ont pas donné grand chose (rien), si tu as plus d’infos je prends volontiers !
Belle soirée!
Pas top pour l’alimentation, je pensais que ça l’était …
Côté disques SSD, ce sont des SAMSUNG MZ7LN512 sur les trois serveurs.
http://www.samsung.com/semiconductor/products/flash-storage/client-ssd/MZ7LN512HCHP
Et pour les perfs, un petit hdparm :
# hdparm -Tt /dev/sda
/dev/sda:
Timing cached reads: 27110 MB in 2.00 seconds = 13569.03 MB/sec
Timing buffered disk reads: 1524 MB in 3.00 seconds = 507.63 MB/sec
Ça ne vaut pas du NVMe mais c’est ce qui correspond à du classique pour des SSD.
Merci pour ton retour d’infos, c’est exactement ce que nous avions encore besoin de savoir !
Pas de soucis 😉
C’est pour toi :
https://blog.waccabac.com/migration-de-machines-virtuelles-proxmox-v3-vers-v4-avec-ip-failover-online-net/
😉
Yeahhh merci bien c’est cool! Continue comme ça 🙂
Bonjour,
Après 15 jours de galère j’ai réussi à faire fonctionner le cluster avec Proxmox 4.4.
Il a simplement fallu que j’enlève bindnetaddr: 10.91.x.x de totem.interface
Maintenant avec RPN v2, ça fonctionne en multicast, pas besoin d’ajouter transport: udpu.
Pour ceux qui veulent faire fonctionner le cluster avec 2 serveurs seulement il faut ajouter dans quorum :
two_node: 1
wait_for_all: 0
Il a aussi fallu que je copie le certificat du noeud principal sur le second :
cd /etc/pve/nodes
cp sd-XXXX/pve* sd-YYYY/