Voici diverses étapes pour la mise en place d’un cluster Proxmox, du plus protégé mais plus complexe au plus simple. Les tests ont été fait avec Proxmox 6

  • Source https://www.guillaume-leduc.fr/mise-en-place-dun-cluster-proxmox-ve.html

Description

Le gestionnaire de cluster de ProxmoxVE « pvecm » est un utilitaire qui permet de créer un groupe de serveur physique. Ce groupe s’appelle un « cluster » contenant un certain nombre de nœuds (nodes) correspondants à vos machines physiques.

Les avantages de créer un cluster de machines sont :

  • Une gestion centralisée via l’interface web ;
  • Un cluster multi-maitre : chaque nœud peut réaliser les taches d’administration ;
  • Migration simplifiée des machines virtuelles ou des conteneurs entre les machines physiques ;
  • Des services étendus au cluster tels que la haute disponibilité et le pare-feu.

Étape 1 : Noeud Proxmox + backup

Étape 2 : Multi noeud et migration a chaud

Source : https://memo-linux.com/proxmox-migration-a-chaud-dune-machine-virtuelle/

ATTENTION : La contrepartie de cette méthode c’est qu’il est difficile de retirer un nœud une fois le cluster créé ( Voir annexe ci-dessous )

Étape 3 : Réplication de VM (ZFS)

Source :

  • https://memo-linux.com/proxmox-5-cluster-2-noeuds-avec-un-stockage-replique/
  • https://computerz.solutions/proxmox-stockage-zfs-cache-ssd/

Avantages

  • Pas besoin de stockage externe (NAS ou SAN)

Désavantages

  • Ne fonctionne qu’avec des volumes ZFS

Vous négligez le fait que votre système ext4-qcow2 utilisera aussi autant de RAM qu’il peut en obtenir. La plupart des gens ne s’en rendent pas compte car c’est le comportement par défaut de tous les systèmes d’exploitation modernes. Pour les « vrais » benchmarks, on utilise toujours des chemins d’entrée/sortie directs ou on laisse tomber les caches pour obtenir des chiffres corrects. Le fait est que ZFS n’utilise au maximum que 50% de RAM sous Linux

compression transparente (cela donne un débit de lecture/écriture encore plus élevé qu’ext4 en fonction de vos données – également sur du matériel bas de gamme)

  • résilience au lieu d’une stupide copie/parité 1:1 à la reconstruction (ou création d’un pool de 100 To qui est au début déjà disponible en grande quantité)
  • en plus des lectures de gommage / patrouille – auto-guérison transparente sur chaque lecture.
  • support du découpage (non pas vers le matériel, mais vers le disque virtuel)
  • Détection de données valides à 100% dans un miroir à deux disques. Dans un stupide miroir mdadm à deux disques, vous ne pouvez pas dire quelles données sont correctes si un bloc ne correspond pas sur les deux disques.
  • des snapshots et la possibilité de les transférer très, très efficacement (également répliquer)

ZFS d’un facteur de presque 100 par rapport aux rsyncs, car nous pouvons transférer de manière incrémentale et nous n’avons pas à copier les sauvegardes elles-mêmes sur le disque externe, seulement les modifications. Cela permet également de réduire considérablement l’encombrement et donc d’avoir un historique plus long ou des disques plus petits. Ce fait nous a totalement convaincus de ZFS, car il est tout simplement impossible de faire cela sur un système non basé sur CoW.

Est-il plus lent qu’ext4 sur certains matériels de test ? Oui, bien sûr

J’ai maintenant compris que ZFS est lent sur du matériel bas de gamme (disques sata 7200 rpm, pas de cache SSD). Je comprends aussi qu’il a ses avantages (beaucoup de fonctionnalités intéressantes, qui viennent au prix de la vitesse, probablement).

Ce que je ne comprends pas, c’est pourquoi il est si sujet aux situations d’OOM et aux redémarrages. Ou, peut-être plus précisément, pourquoi le PVE avec ZFS est si sujet à ces problèmes.

Si ZFS veut vraiment du matériel haut de gamme (64 Go de RAM ou plus, plusieurs disques sas 15k, etc), je pense que cela devrait être clairement indiqué dans la documentation de PVE

Conf possible :

/etc/sysctl.d j’ai un fichier de conf avec
Le code :

vm.swappiness = 0
vm.min_free_kbytes = 524288

Essayez de définir les vm.min_free_kbytes , afin qu’il y ait toujours de la mémoire libre pour proxmox. Je l’ai défini dans chaque serveur proxmox et comme je l’ai dit, je n’ai pas de problèmes de plantage ou de redémarrage.

e mettrais ZFS ARC max à un tiers de la RAM, pas plus, pour que vous n’ayez pas trop de pression sur la mémoire. Essayez de ne jamais atteindre 75% de la RAM utilisée

Visualiser la taille de l’ARC : arcstat 1

D’où mon conseil : ne jamais atteindre 75% de RAM utilisée (total ARC + RAM assignée aux VMs + un peu de RAM supplémentaire pour chaque VM + un peu de RAM pour proxmox) et régler vm.min_free_kbytes

Traduit avec www.DeepL.com/Translator (version gratuite)

Traduit avec www.DeepL.com/Translator (version gratuite)

Etape 4 : Création de cluster HA avec SAN

Avantages

  • Pas de perte de donnée -> Stockage déporté

Désavantages

  • Nécessite un switch 10 GB

Dans le plan ci-dessus :

  • Partage de stockage en réseau NFS avec le SAN
  • J’ai abandonné iSCSI au profit de NFS

Étape 5 : Création de cluster HA (Ceph)

Avec des tests : https://indico.math.cnrs.fr/event/800/session/2/contribution/15/material/slides/0.pdf

Tuto : https://memo-linux.com/proxmox-5-mise-en-place-dun-cluster-ha-avec-ceph/

Avantages

  • Pas besoin de stockage externe (NAS ou SAN)

Désavantages

  • Necessite un switch 10 GB

Info

1 OSD :

  • Object Storage Devices
  • un disque + CPU/RAM/réseau

Besoin

  • OSD : démon pour chaque disque
  • MON : démon Monitor
  • MGR : démon Manager
  • MDS : démon pour les metadatas CephFS
  • RGW : démon pour accés en HTTP REST

Autre commande utile

1 – Retirer un noeud du cluster

Dans le cas d’un cluster TEST1 et TEST2 ou on supprime TEST2

  1. On enlève les VM de TEST2
  2. On éteint TEST2
  3. On se connecte sur TEST1
  4. On supprime la node via TEST1 : pvecm delnode srvphy-test2

ATTENTION : Il ne faut pas rallumer le node TEST2

  1. Vérification sur TEST1 : pvecm status
  2. Formatage/Réinstallation du TEST2

2 – Création de cluster avec une VM dessus

  1. Installation vierge
  2. Création d’une VM
  3. Création du cluster : OK

3 – Création d’un backup manuel

Shell

Step 3: Bouger les fichiers par scp

Shell

Step 4: Restaurer un backup

Shell

KVM : utilisé par Red Hat Virtualization et proxmox ( Faire un petit résumé )

Autre info proxmox : https://neverendingsecurity.wordpress.com/tag/proxmox-ve/