Datacenter chezlepro

vue d’ensemble & choix de conception

1) Topologie (simple, solide)

  • Cluster Proxmox VE :chezlepro (PVE 8.4.11, kernel 6.8.12-13-pve) sur 3 nœuds :
    asgard (192.168.11.41), gandalf (192.168.11.43), vishnu (192.168.11.47).

  • Pourquoi 3 nœuds ? Le chiffre “magique” pour le quorum : à 3, un nœud peut tomber sans perdre la haute dispo.

  • Corosync/knet avec secure auth activé : intégrité des messages de cluster et bascule HA fiable.

Bénéfice : disponibilité élevée avec une complexité minimale. Pas de témoin externe requis, maintenance sereine.

2) Réseau (séparer pour régner)

  • Anneau management / cluster :192.168.11.0/24
    Sert à l’admin, à Corosync et à la supervision.

  • Réseau “data lourd” :10.11.7.0/24
    Héberge Ceph (monitors sur .41/.43/.47) et la live-migration PVE.

  • Live-migration sécurisée :migration: secure,network=10.11.7.0/24
    Chiffrement + chemin dédié = pas de bruit sur le réseau d’admin.

Pourquoi ce découpage ?
Il isole les gros flux (Ceph, migrations) du plan de contrôle. Résultat : moins de gigue sur l’admin, migrations plus rapides, et un troubleshooting nettement plus clair.

Évolution possible : ajouter un second anneau Corosync (ring1) si tu veux de la redondance de chemin pour le quorum.

3) Stockage (performance où il faut, capacité où il faut)

  • Ceph RBD avec deux pools logiques :

    • CephNVMe → pour les workloads sensibles à la latence (bases de données, frontaux exigeants).

    • CephHDD → pour les volumes capacitaires (services moins latence-sensibles, archives).

  • CephFS cephfs monté en commun pour ISO, templates, snippets (facilite l’orchestration).
    (Le stockage “backup” y est autorisé mais PBS reste l’autorité des sauvegardes.)

Pourquoi Ceph ?

  • Tolérance aux pannes par réplication des objets.

  • Live-migration fluide (disque partagé logique).

  • Élasticité : on peut étendre la capacité en ajoutant des OSD, sans arrêt de service.

4) Sauvegardes (PBS comme filet principal)

  • Proxmox Backup Server : 10.11.7.88 — datastore Sauvegardes, namespace Chezlepro, fingerprint pinné (zéro MITM).

  • Jobs de sauvegarde (extrait) :

    • 03:00 : pools Chezlepro (notif Daniel) et technoLibre (notif Mathieu).

    • Dimanche 01:00 : RetD (LAB).

    • 04:00 : Projet_KBR.
      Retentions codées par pool (daily/weekly/monthly/yearly ; keep-last pour le LAB).

Pourquoi PBS ?

  • Déduplication + ZSTD ⇒ fenêtres de backup plus courtes, stockage optimisé.

  • Restauration granulaire (VM, disque, fichiers) et hors cluster en cas de pépin Ceph.

Bon réflexe d’exploitation : un test de restore mensuel (rotation des VMs critiques) pour valider la chaîne fin-à-fin.

5) Haute dispo & exploitation (zéro stress en maintenance)

  • HA actif avec shutdown_policy=migrate : lors d’un arrêt planifié d’un nœud, les VMs sont migrées automatiquement avant l’extinction.

  • Rebalance au démarrage (ha-rebalance-on-start=1) : répartit la charge quand un nœud revient, sans babysitting.

  • max_workers=5 : limite la concurrence des tâches PVE pour garder de la marge CPU/IO durant les fenêtres de backup ou de migration.

Pourquoi ces réglages ?
Ils privilégient la continuité de service et évitent les pointes IO/CPU surprises. L’objectif : des maintenances “ennuyeuses” — c’est un compliment.

6) Rôles des stockages PVE (pragmatisme)

  • local / local-lvm : tampon local (ISO temporaires, tests rapides).

  • RBD (CephNVMe/HDD) : par défaut pour les VMs/CT en prod.

  • CephFS : artefacts partagés (ISO, snippets, templates) ; éventuel backup secondaire si besoin ponctuel.

Pourquoi éviter le local en prod ?
Pour garder la mobilité : un volume RBD permet la live-migration en 1 clic ; un disque local force des arrêts plus longs et une gestion au cas par cas.

7) Sécurité & confiance (sans secrets en clair)

  • Authentification Corosync sécurisée + migration chiffrée : pas de trafic cluster en clair.

  • PBS fingerprint renseigné : ancre de confiance lors des connexions de sauvegarde.

  • Séparation réseau management / data : surface d’attaque réduite et blast-radius plus petit.

À compléter dans l’opérationnel : MFA partout où c’est possible, inventaire des host keys (SSH/IPMI) et “comptes break-glass” documentés hors-ligne.

8) Opérations courantes (guidées par la conception)

  • Placement : choisir CephNVMe pour les services “latence-sensibles”, CephHDD pour les volumineux.

  • Backups : tout en PBS ; CephFS reste utilitaire (ISO/snippets) ou copie de courtoisie.

  • Migrations : toujours via 10.11.7.0/24 (rapide, chiffré, sans impacter l’admin).

  • Maintenance : basculer un nœud en maintenance → HA migre, puis patcher/redémarrer.

9) Ce qui a été volontairement écarté

  • Pas de dépendance aux disques locaux pour la prod (mobilité priorisée).

  • Pas de témoins externes (NAS/NFS/san témoin) : simplicité et fiabilité avant tout.

  • Pas de mélange des flux lourds avec l’admin : le réseau reste lisible et serein.

En résumé

La plate-forme chezlepro mise sur des principes sobres : isolation des flux, stockage distribué Ceph, sauvegardes PBS, et HA “sans drame”.
C’est un design prévisible (facile à diagnostiquer), évolutif (ajouter des OSD ou un nœud sans tout repenser) et confortable à opérer au quotidien.