Chapitre 01

Architecture, matériel et plan réseau

Les choix de ce chapitre se corrigent mal une fois la plateforme en production. Ils méritent une demi-journée de réflexion avant la première installation.

Lecture 9 min  ·  Prérequis : aucun

01Combien de noeuds, et pourquoi un nombre impair

Proxmox VE forme un cluster autour de corosync, qui a besoin d'un quorum, c'est-à-dire d'une majorité stricte de voix, pour autoriser les opérations. Sans quorum, le cluster se met en lecture seule et la haute disponibilité isole les noeuds concernés. Le nombre de noeuds découle directement de cette règle.

  • Deux noeuds : possible, mais chaque perte d'un noeud fait tomber le quorum. Il faut alors un QDevice, une troisième voix hébergée ailleurs. Acceptable pour une petite plateforme, jamais idéal.
  • Trois noeuds : le minimum sérieux. C'est aussi le minimum pour Ceph avec une réplication en trois exemplaires.
  • Cinq noeuds : le confort. On tolère la perte de deux noeuds, le rééquilibrage Ceph est moins brutal, et la maintenance ne consomme pas toute la marge.
  • Nombre pair : à éviter. Quatre noeuds ne tolèrent pas plus de pannes que trois, tout en coûtant un noeud de plus.
Point d'attention

Un cluster Proxmox VE et un cluster Ceph n'ont pas les mêmes besoins de croissance. Il est parfaitement légitime de faire tourner Ceph sur seulement une partie des noeuds, ou de le sortir du cluster de calcul, si la volumétrie et la charge divergent.

02Matériel : processeurs, mémoire, disques

Processeur et mémoire

  • Des noeuds homogènes autant que possible : la migration à chaud entre générations de processeurs différentes impose de dégrader le type de CPU exposé aux machines virtuelles.
  • Mémoire ECC, sans discussion, dès lors que ZFS ou Ceph est en jeu.
  • Compter environ 4 Go de mémoire par OSD Ceph, en plus de la mémoire des machines virtuelles et de la réserve de l'hyperviseur.
  • Prévoir une réserve d'au moins 10 à 15 % de mémoire par noeud pour l'hyperviseur lui-même.

Disques

  • Système : deux disques en miroir ZFS, installés par l'ISO Proxmox VE. Des SSD d'entrée de gamme suffisent, mais pas des clés USB ni des cartes SD.
  • Données Ceph : des SSD ou NVMe d'entreprise avec protection contre les coupures d'alimentation. C'est le point le plus souvent négligé : un SSD grand public sans cette protection s'effondre en performance sur les écritures synchrones et met en danger la cohérence des données.
  • Pas de RAID matériel sous Ceph ni sous ZFS. Le contrôleur doit exposer les disques directement, en mode HBA ou IT. Une carte RAID avec cache masque les erreurs et empêche Ceph et ZFS de faire leur travail.
  • Un OSD par disque physique. Ne pas découper un disque en plusieurs OSD.
Piège classique

Mélanger des disques de classes différentes dans le même pool Ceph. Le pool prend la performance du plus lent. Si vous avez du NVMe et du SAS, créez deux classes de périphériques et deux pools distincts, avec des règles CRUSH séparées.

03Séparer les réseaux, la décision structurante

C'est la cause numéro un des incidents que nous constatons. Corosync a besoin de latence faible et stable, pas de débit. Ceph a besoin de débit massif. Les deux sur le même lien, et une reconstruction Ceph fera perdre le quorum au cluster, qui isolera des noeuds parfaitement sains.

RéseauRôleDébitMTURemarques
AdministrationInterface web, SSH, API1 Gb/s1500Jamais exposé sur Internet
Corosync lien 0Quorum, état du cluster1 Gb/s1500Physiquement dédié, latence sous 2 ms
Corosync lien 1Redondance du quorum1 Gb/s1500Sur un autre commutateur
Ceph publicClients vers OSD et MON10 à 25 Gb/s9000Peut être mutualisé avec la migration
Ceph clusterRéplication entre OSD10 à 25 Gb/s9000Saturé pendant les reconstructions
MigrationDéplacement à chaud des VM10 Gb/s9000A limiter en débit si mutualisé
ProductionTrafic des VM, VLAN clients10 Gb/s1500Agrégation LACP, VLAN étiquetés

Agrégation et redondance

  • Agrégation LACP 802.3ad pour la production et pour Ceph, sur des commutateurs empilés ou en MLAG.
  • Pas d'agrégation pour corosync. Corosync gère lui-même la redondance par ses liens multiples, avec un basculement plus rapide et plus fiable qu'un bond.
  • Deux commutateurs distincts, chaque noeud raccordé aux deux.

MTU

Un MTU de 9000 apporte un gain réel sur Ceph, mais il doit être cohérent de bout en bout, commutateurs compris. Un MTU incohérent produit des symptômes déroutants : le cluster fonctionne, puis s'effondre dès que les paquets deviennent gros. À vérifier avant la mise en service.

Vérification du MTU de bout en bout
# le drapeau -M do interdit la fragmentation : le test doit passer sans erreur
ping -M do -s 8972 -c 4 10.10.4.12

04Un plan d'adressage type

Écrire ce tableau avant de toucher au premier serveur fait gagner plusieurs heures. Il devient ensuite la référence pour la documentation et pour la supervision.

UsageVLANSous-réseaunoeud 1noeud 2noeud 3
Administration1010.10.0.0/24.11.12.13
Corosync lien 01110.10.1.0/24.11.12.13
Corosync lien 11210.10.2.0/24.11.12.13
Ceph public1310.10.3.0/24.11.12.13
Ceph cluster1410.10.4.0/24.11.12.13
Migration1510.10.5.0/24.11.12.13
Production100+selon clientponts VLAN sur vmbr1

05Dimensionner avec la règle N+1

Un cluster n'est dimensionné correctement que s'il continue à fonctionner sans un noeud. La règle pratique : la charge mémoire totale ne doit jamais dépasser ce que les noeuds restants peuvent absorber après la perte du plus gros d'entre eux.

  • Trois noeuds : ne pas dépasser environ 60 % d'occupation mémoire par noeud.
  • Cinq noeuds : environ 75 % est tenable.
  • Côté Ceph, viser 70 à 75 % maximum de remplissage. Au-delà, la reconstruction après la perte d'un noeud peut remplir les OSD restants et bloquer les écritures, ce qui transforme un incident en panne.
A retenir

Cette marge N+1 n'est pas du gaspillage, c'est la fonction même du cluster. Nous en faisons un indicateur suivi en continu, détaillé au chapitre 06.

06Environnement physique

  • Alimentations redondantes sur deux voies électriques distinctes, onduleur avec arrêt propre piloté par NUT.
  • Répartir les noeuds sur des baies différentes si possible, et adapter le domaine de défaillance Ceph en conséquence (voir chapitre 03).
  • Accès matériel hors bande (iDRAC, iLO, IPMI) sur un réseau isolé. Indispensable le jour ou un noeud ne répond plus.
  • Source de temps commune et fiable : une dérive d'horloge désorganise Ceph et corosync.

Un cluster a batir, a auditer ou a reprendre en main

Nous concevons, deployons et exploitons des clusters Proxmox VE et Ceph en production pour des PME, des structures reglementees et des collectivites. Nous formons aussi vos equipes, notamment dans le cadre des migrations depuis VMware.