hauban et sabord succèdent à gaillard. Elles sont identiques et hébergent les machines virtuelles des membres à Grenoble-02 avec l'outil Proxmox

IP : 91.216.110.102 / 2001:912:800:200::102

Localisation : Grenoble-02

  1. Matériel
    1. Sécifications matérielles
    2. Consommation électrique
    3. Vérification
  2. Configuration
    1. BIOS
    2. Stockage
    3. Choix de l’utilisation des interfaces réseau
    4. Reservation des ressources
    5. Installation de proxmox
  3. Tests de performance
    1. Tests de performance disques
    2. Tests performance réseau

Matériel

Sécifications matérielles

  • CPU : AMD EPYC 8324P 32C / 64T
  • Memoire : 4 x Samsung 64G ECC DDR5
  • Chassis : Supermicro AS-1115SV-WTNRT
  • Carte réseau : Intel X710 4 SFP+
  • Disques systèmes : 2 x Kingston DC300 480G NVME M.2 sur carte mère.
  • Disque data : 3 x Samsung PM9A3 3.8To en façade.

Consommation électrique

  • idle 80 W
  • pleine charge 245W

Vérification

  • un memtest a été effectué.

Configuration

BIOS

  • Version du BIOS : 1.2
  • Version de la carte BMC : 1.03
  • changements apportés à la configuration par défaut :
    • Advanced -> boot features --> Power button function --> set to "4 seconds Override" (was: "Instant Off")
    • Advanced -> Network Configuration --> IPv{4,6} PXE Support --> disabled (was: enabled)
    • Advanced -> SATA Configuration --> SATA Enable --> disabled (was: auto)

Stockage

  • raid1 mdadm chiffré sur les disques systèmes
  • zfs zpool raiz1 pour les disques des vm en facade

Choix de l’utilisation des interfaces réseau

  • 1 port cuivre pour la BMC
  • 2 interfaces 10G Cuivre non utilisées sur la carte mère (le driver bnxt_en a été blacklisté car il générait des erreurs)
  • 4 interfaces 10G SFP+ (de gauche à droite) sur la carte fille Intel X710 4SFP+ :
    • infra (avec ip publique), ens3f3np3, 1er port en partant de la gauche D
    • collecte, ens3f2np2, 2e port en partant de la gauche C
    • pve storage, ens3f1np1, 3e port en partant de la gauche B
    • pve synchro du cluster, ens3f0np0, 4er port en partant de la gauche A

Reservation des ressources

Cf Réseau.

Installation de proxmox

Installation Debian GNU/Linux

On reproduit ce qui a été fait sur gaillard/vibord dans la mesure du possible.

  • disque système chiffré en raid 1
  • install d'un serveur ssh dans l'initramfs (dropbear). Et vérification que ça marche.
  • configurer le switch (oursin)
  • configurer les interfaces réseau dans debian
  • passer les playbook ansible de base (clés SSH & co)
  • mesure du courant

:warning: si rien n'est branché sur l'interface du bridge, DAD fail et le service netwokring aussi. ref

Configuration du noyau pour le réseau dans l'initramfs dropbear :

GRUB_CMDLINE_LINUX=" ··· ip=91.216.110.102::91.216.110.97:255.255.255.240:hauban:ens3f3np3:"

Configuration du noyau pour bug entre linux et la carte supermicro :

Nous constatons deux problèmes :

  • le support USB fonctionne mal dans linux.

    déc. 28 15:51:56 hauban kernel: xhci_hcd 0000:c6:00.0: init 0000:c6:00.0 fail, -16 déc. 28 15:51:56 hauban kernel: xhci_hcd: probe of 0000:c6:00.0 failed with error -16 déc. 28 15:51:56 hauban kernel: xhci_hcd 0000:c7:00.0: init 0000:c7:00.0 fail, -16 déc. 28 15:51:56 hauban kernel: xhci_hcd: probe of 0000:c7:00.0 failed with error -16 déc. 28 15:51:56 hauban kernel: xhci_hcd 0000:ca:00.4: init 0000:ca:00.4 fail, -16 déc. 28 15:51:56 hauban kernel: xhci_hcd: probe of 0000:ca:00.4 failed with error -16

  • les disques nvme samsung PM9A3 sont visibles sur un lspci mais ne sont pas reconnus par le driver nvme (ils n'apparaissent pas dans /dev)

Après recherches diverses, nous sommes tombés sur ce post. L'option suivante du noyau règle le problème : 

GRUB_CMDLINE_LINUX=" ··· pci=realloc=off"

Installation de proxmox

https://pve.proxmox.com/pve-docs/pve-admin-guide.html#installproxmox_ve_on_debian

  • Installation des dépôts

  • Installation du noyau de proxmox

    apt install proxmox-default-kernel

    :warning: les interfaces réseau changent de nom lorsque l'on passe de linux 6.1 à linux 6.8 (ens3f3→ ens3f3np3, ens3f2 → ens3f2np2, etc). La configuration réseau a été adaptée en conséquence.

    :warning: le driver bnxt_en pour les deux interfaces réseau de la carte mère se prend les pieds dans le tapis. Comme a priori, on n'en a pas besoin, le module a été rajouté à la blacklist pour éviter les problèmes. Les deux interfaces cuivre en question ne sont donc plus dispo.

  • Installation de proxmox

    apt install proxmox-ve

  • réseau corosync séparé : https://pve.proxmox.com/pve-docs/pve-admin-guide.html#separatecluster_network

  • réseau réplication/migration séparé : https://pve.proxmox.com/pve-docs/pve-admin-guide.html#datacenter_configuration_file

    To configure this as the default network for all migrations in the cluster, set the migration property of the /etc/pve/datacenter.cfg file:

    # use dedicated migration network
migration: secure,network=10.1.2.0/24

  • two_nodes mode

    Pour que le quorum fonctionne dans un cluster à deux noeuds, il faut utiliser l'option two_nodes.

    Cf. two_nodes and wait_for_all options in https://manpages.debian.org/unstable/corosync/votequorum.5.en.html

Sécurisation de l'accès à proxmox sur l'IP publique

Nous aons restreint l'interface web via le pare-feu. Pour s'y connecter il faut donc rebondir via SSH.

Via du port forwarding :

ssh -L 8006:hauban.grenode.net:8006 hauban.grenode.net

ou du Proxy Socks (l'extension de firefox FoxyProxy est pas mal) :

ssh -D 1234 hauban.grenode.net

Création du pool zfs sur les disques data

Cf https://pve.proxmox.com/wiki/ZFS_on_Linux

zpool create -f -o ashift=12 <pool> raidz1 <device1> <device2> <device3>

ATTENTION : d'après les logs noyau de sabord. Les disques peuvent changer de nom lors d'un redémarrage. Il y a eu une inversion entre /dev/nvme3n1 et /dev/nvme2n1.

Cela a mis le pool zfs dans un état dégradé au redémarrage. Et, il n'a pas été possible de le réparer à chaud. Cela a été réglé en bougeant toute les vm, puis : 

zfs export zpoolnvme1
zfs import -d /dev/disk/by-id

L'option -d /dev/disk/by-id a été utilisée pour éviter que les disques soit référencés par leur nom logique.

Augmentation MTU sur les interfaces réseau

On passe à 9000 sur les interfaces réseau. Dans /etc/network/interfaces : 

iface ...
  ...
  mtu 9000
  ...

Configuration de etckeeper

Il semble difficile de faire fonctionner etckeeper avec le répertoire /etc géré par Proxmox car c'est un filesystem spécial (pmxcfs) et que ça bouge souvent. Nous avons donc exclu /etc/pve de git.

:warning: On pourait ajouter explicitement les configurations des VMs à terme dans le gitignore, pour les versionner.

Exemple de ce qu'on peut rajouter à la main dans gitignore:

pve/*
!pve/corosync.conf
!pve/storage.cfg
!pve/datacenter.cfg
!pve/user.cfg
!pve/domains.cfg
!pve/status.cfg
!pve/nodes/<node>/config
!pve/nodes/<node>/qemu-server/*.conf
!pve/nodes/<node>/lxc/*.conf
!pve/firewall/cluster.fw
!pve/firewall/*.fw

Gestion des notifications

Pour l'envoi de notification, Proxmox recommande l'installation de Postfix sur les machines.

À Grenode, on utilise nullmailer sur toutes les machines, cela permet uniquement d'envoyer du mail via un relay qui est mail.grenode.net. Proxmox envoie par défaut ses notifications à root@ qui est redirigé automatiquement vers machines@grenode.net (/etc/aliases).

Proxmox permet l'envoi des notifications par d'autres moyens (onglet notifications dans l'interfaces web).

Metrologie & Monitoring

Les machines hauban et sabord ont été ajoutées à librenms et à check_mk.

À cette occasion, les interfaces sont maintenant indexées par leur alias dans check_mk et les interfaces tap sont également ignorées. Les 15 machines de Grenode ont été réinventoriées.

Backups

Le role ansible backups a été passé sur hauban et sabord (après avoir mis à jour le role et géré les changements du role). Les backup sont faits sur nable. Comme /etc/pve n'est pas le même système de fichier, il a fallu rajouter explicitement ce chemin.

Tests de performance

Tests de performance disques

Nous utilisons ZFS car proxmox en recommande l'usage et que nous n'avons sufisament de nœud pour utiliser ceph. Les vm sont donc stockées sur un zpool raidz1 avec les disques "data". Nous avons réalisé des tests de performance dans une VM avec le driver SCSI via l'outil fio.

fio --filename=/root/fiofile --size=1G \
  --rw=$mode --direct=1 --bs=$bs \
  --ioengine=libaio --runtime=10 \
  --numjobs=1 --time_based --group_reporting --name=blou \
  --iodepth=16
mode bs IOPS MiB/s
randread 1k 87.0k 85
randwrite 1k 16.3k 16
read 1k 79.0k 77
write 1k 17.5k 17
randread 4k 79.5k 311
randwrite 4k 64.3k 251
read 4k 85.6k 334
write 4k 64.7k 253
randread 1M 16.4k 16000
randwrite 1M 6463 6464
read 1M 18.9k 18500
write 1M 6367 6367
randread 32M 481 15100
randwrite 32M 195 6270
read 32M 578 18100
write 32M 200 6406

Globalement c'est incroyablement plus performant que les système de stockage actuels (sata + ide) et il ne nous semble pas nécessaire d'aller plus en avant sur ces tests.

Tests performance réseau

L'enjeu pour nous est la quantité de paquets par secondes (pps) supporté par le système. Nous avons effectué des tests entre deux vm (Debian bookworm), une sur sabord, une sur hauban. Ces conditions ne sont pas idéales. Pour faire un test qui se rapproche plus de l'usage que nous en avons, il faudrait sortir le récepteur et l'éméteur du système que l'on test.

Nous avons utilisé trafgen pour generé du trafic avec la configuration suivante : 

trafgen -o ens18 --cpus 6 -n 3 '{ eth(da=bc:24:11:92:a9:85),ipv6(daddr=2001:912:400:100::6666,saddr=dinc()), udp()}' --num 1000000000000000

Le maximum de pps atteint est de 2,8 M (on a pas réussi à générer plus de pps, la machine émétrice était saturée) : c'est probablement la génération elle même qui prend le plus de CPU. Pour info, en 2024, il y a ~300k pps sur l'interface la plus utilisée à Grenoble et 200 kpps à Vénissieux.