Cluster Proxmox chez OVH

Tech Infrastructure
1

Bonjour,
Nouvellement débarqué sur le forum chatons, (bien que pas nouveau sur le libre), je fais partie de la petite équipe des CEMEA qui supporte le nouveau zourit.net.

Mais je viens surtout demander de l’aide technique pour créer un cluster Proxmox chez OVH qui hébergera notre instance Peertube et quelques services « open-bar » que nous hébergeons actuellement dans une VM (Peertube, Mattermost, Jirafeau, framadate, pad…). Nous voudrions isoler chaque service dans un CT ou une VM à part pour des snapshots et backups propres.
Notre besoin est de créer un cluster entre nos 2 serveurs pour partager correctement notre plage d’IP.

Nous louons 2 serveurs correct chez OVH (avec des applis en prod sur l’un d’eux, l’autre est vierge) compatibles V-rack pour une liaison entre eux mais nous n’arrivons pas les connecter pour créer le cluster via le V-rack d’OVH.
Les deux sont en promox v5 - ZFS-raid1 (pas de CEPH) avec leur IP propre et sont aussi connectés via le V-rack d’OVH en monopolisant 4 IP en passant. Tout le monde se ping bien en passant par le V-rack qui fonctionne (testé).

Nous avons bien créé le cluster sur notre « Patate » (serveur de prod), mais « courgette » (le serveur vierge) n’arrive pas à rejoindre le cluster en passant par l’IP dédié au V-rack. La demande de jonction de courgette vers Patate échoue sans que nous ayons d’explications claire sur ce qu’il se passe.

La commande depuis courgette :

pvecm add IP_v-rack_patate

n’aboutit pas et tourne sans aboutir.

Au bout d’un temps certain, notre proxmox « courgette » n’est plus d’interface web accessible.
Proxmox conseille en cas d’échec d’utiliser l’unicast si le multicast ne fonctionne pas.
Mais ça ne change rien pour nous non plus (ou bien on ne le fait pas correctement, ce qui est possible).

Nous avons épluché les forums d’OVH et de proxmox sans plus de résultats.

Donc si quelqu’un peut partager un peu de retour d’expérience dans ce genre de config (cluster proxmox sur un V-rackd’OVH ou cluster sur des plages d’IP distantes), il·elle en serait grandement remercié. Nous utiliserons le cluster sans HA. Le but est de partager notre plage d’IP pour le V-rack et de pouvoir déplacer des CT/VM facilement dans le cluster.

Merci encore et bon courage à vous.

1 « J'aime »
2

Bonjour,

est-ce que à partir du serveur patate, un ssh courgette est fonctionnel ?
avez vous fait un pvecm status sur le serveur courgette ?
Un reboot du serveur ?

Cordialement,

3

Merci @Bschalck de te pencher sur notre problème, c’est sympa.
Oui le ssh fonctionne dans les deux sens (sans clef, avec password en clair), donc ça marche.
Mais on va retester en le faisant le ssh via le V-rack. C’est une piste…
On va aussi ajouter le host avec l’IP du v-rack avant de relancer le pvecm add patate.
Pour le pvecm status il était normal sur patate. Sur courgette, c’est une install de base avec le template OVH Proxmox5-ZFS. Donc pas de raison, on repart d’une install vierge à chaque fois, donc ça devrait être bon.
On va refaire des tests à partir de ces données.

Tu parles d’un reboot du serveur courgette avant ou après la tentative de jonction ou avant de rejoindre « patate » ?

On va relancer toute la config v-rack et se remettre dans un état juste avant la jonction. Comme ça on pourra faire des tests/retours avant de lancer la création.
Comme on en est à notre 3e tentative, on commence à maitriser le process. :wink:

4

Actuellement, nos 2 proxmox sont en v5. On doit les faire passer en v6 d’ici quelques jours/semaines.

Est-ce qu’il serait plus pertinent de créer le cluster avant ou après la mise à niveau ?

5

je conseillerai de monter en v6 puis de faire le cluster

Ainsi ton problème de cluster , si il y a problème , sera uniquement un problème cluster.

Ma migration V5 → V6 est pratiquement transparente.
La mise en place d’un cluster l’est moins :smiley:

6

Entièrement d’accord avec Bschalck.
D’abord en v6 puis le cluster.

De mémoire, pour avoir tester l’ajout d’un cluster (mais en local) avec Proxmox V6, aucun souci rencontré à l’ajout. J’espère qu’il en sera de même pour vous :wink:

7

Oui @OpenSRD, on a déjà aussi créé un cluster en local sans souci. Le problème se pose là avec des serveurs distants, sur des réseaux différents avec des IP publiques et un réseau virtuel (v-rack chez OVH) pour avoir un lien privé sur un réseau local virtuel en plus des IP publiques. Et là, ça coince.

Mais merci pour le conseil. On va d’abord passer en V6 et tenter le cluster ensuite.

8

Passez en V6, la V5 n’a plus que quelques semaines de maintenance devant elle (jusque fin juillet).

La v6 fonctionnera aussi bien mieux en cluster, car elle utilise corosync v3 qui n’a plus besoin d’IP multicast pour fonctionner (un truc un peu galère avec les vRack qui bloque sûrement ton pvecm add).

Pour OpenStreetMap France, on a un cluster proxmox chez OVH de 3 noeuds. Ils sont encore en v5 (installés à l’origine en v4), mais le passage v6 va se faire ces jours-ci. Ces 3 noeuds sont dans le même DC.

J’ai aussi aidé à mettre en place un cluster de 2 noeuds, en v6, sur 2 datacenters différents. Pas de problème particulier.

Attention avec les noeuds d’un cluster, tu ne peux les ajouter au cluster que si il sont vides de toute VM/CT… donc si tu commence à les utiliser ça coince.

Bon choix que ZFS :wink:

https://forum.chatons.org/t/zfs-vous-connaissez/579

Par contre, la config de base faite par le template n’est peut-être pas optimale mais ça dépend du type de serveur et de stockage que vous avez dessus… je préfère une install où l’essentiel de l’espace disque n’est pas partitionné à l’install (juste ce qu’il faut pour l’OS), puis je configure le pool ZFS…

9

Oui, pour la V6, on est prêt. On a déjà testé 3 fois la migration avec la précaution que le montage du ZFS est tellement lent qu’il faut retarder légèrement la conf de montage ZFS par défaut sur notre serveur pour que le boot se fasse correctement.
Dans /etc/default/zfs, changer la valeur ZFS_INITRD_PRE_MOUNTROOT_SLEEP='4 ’ par 5 minimum.
Cf note sur la doc proxmox.

Merci pour ces conseils précieux.

10

Salut @FrancoisA

De mémoire il faut utiliser des adresses Privée (RFC 1918) sur le V-rack pour que le cluster puisse fonctionner, les IP failover étant toujours sur l’interface publique (Internet).
Modification à faire dans le fichier host pour que le nom de la machine résolve en l’adresse privé puis l’adresse publique (l’ordre à t’il une importance ?) pour que la communication du cluster se fasse via le réseau privée plutôt que public.

Pour que le cluster puisse fonctionner il faut idéalement que les machine puisse se connecter en SSH avec le compte root.
Idéalement avec une clé pour plus de sécurité, Proxmox ajoute normalement automatiquement la clé publique du compte root à tout les neuds du cluster).

11

Merci à tout pour vos réponses.
Actuellement, au vu de nos nombreux échecs et de la difficulté à utiliser le cluster sur OVH (problème du reboot lors de la migration v5 à v6 en ZFS, difficulté de créer le cluster simplement avec le v-rack…), nous sommes incertain sur l’intérêt de créer ce cluster.
Si on conserve les 2 serveurs avec le V-rack, on garde la possibilité de déplacer rapidement nos VM de l’un vers l’autre (backup / scp / restore) avec un environnement plus fiable.
A part le fait de pouvoir déplacer des VM de l’un vers l’autre sans trop de downtime, et de pouvoir administrer les 2 noeuds depuis la même interface, si on n’utilise pas de CPEH ou de HA, on s’interroge sur les bénéfices à passer en cluster, au vu des risques possibles.
Est-ce vraiment intéressant ? Mon admin-sys préféré est frileux à tenter la manip.

12

Personnellement je suis plutôt partisan la simplicité. De la même façon que les « gros » (google il me semble) semble arrêter de faire du RAID parce que ça apporte plus de problème que de bénéfice (google avait sortie une étude intéressante là dessus mais j’ai plus la source) est-ce qu’une fonctionnalité de cluster est pertinente si elle te cause plus de problème potentiel que de bénéfice.
Donc si le « retour à la normal » est acceptable en quelques heures dans le cas d’un crash matériel (pas hyper fréquent non plus) tu peux effectivement avoir uniquement une copie de VM sur un autre serveur, prêt à prendre la suite si tu veux (ça implique ip failover). En cas de crash tu perds quelques heures de données (ça dépend de ce que tu héberge) et tu peux repartir en : le temps que tu arrive devant ta machine + le temps du clique droit restauré. De cette façon c’est simple mettre en œuvre et a maintenir dans le temps (les upgrade dans un cluster moi ça me fait toujours serrer les fesses)

Mes 3cts

1 « J'aime »
13

C’est typiquement l’intérêt d’un cluster proxmox. Il ne s’agit que de mettre ensemble au moins 2 serveurs physiques pour la réplication et 3 pour la haute disponibilité.

Je co-administre un cluster de 3 noeuds pour OpenStreetMap France et hier un des serveurs a planté, OVH nous a fait un hard reboot, le service critique tournant dessus a été migré automatiquement dès l’indisponibilité détectée par les 2 autres noeuds. Merci la haute-dispo !
La réplication ZFS se faisant toutes les 5mn (en quelques secondes), on a perdu au pire 5mn d’activité.

Proxmox simplifie énormément tout ça, ZFS fluidifie toute la partie réplication.

2 « J'aime »