Bonjour les amis, ce post fait suite à la vidéo de « live admin » que j’ai publiée il y a quelques jours et dans laquelle je vous montrais cet ajout. Pour ceux qui veulent consulter la vidéo, c’est part là :

Le cluster Fermi est actuellement composé de 4 nœuds identiques répartis sur 4 zones géographiques différentes chez OVHcloud (Roubaix, Limburg, ERI et Gravelines) et fonctionne (au moment où j’écris ce post) sous Proxmox VE 7.4-17.

3 nœuds sont utilisés pour la production, et un nœud est conservé pour le spare (noeud de secours), les tests et les upgrades.

Leur configuration hardware, avant l’upgrade est la suivante :

CPU : 2× Intel Xeon Gold 6242R – 20c/40t – 3.1 GHz/4.1 GHz
RAM : 768 Go ECC 2933 MHz
Stockage système d’exploitation : 2×480 Go SSD SATA (configurés en RAID 1)
Stockage VMs : 6 x 3.84 To SSD NVMe (configurés en RAID 10)
Réseau : 4 ports configurés en paires redondantes connectées à des équipements réseaux différents à l’intérieur d’une même paire : une paire est dédiée au vRack et l’autre au réseau public.

Note : cette redondance est assurée via 2 agrégations LACP. Les port virtuel du vRack est ensuite configuré dans un bridge, utilisé pour l’assignation des IPs publiques des VMs (mes plages IP étant routées dans le vRack).

La communication entre les nœuds utilise 2 boucles corosync : une via le vRack dans un réseau privé, et l’autre via le réseau Public (chose possible depuis que corosync est passé de Multicast à Unicast).

Le RAID 10 est une combinaison du RAID 1 (mirroring pour la redondance) et du RAID 0 (striping pour la performance). L’espace réellement utilisable est réduit de 50% dans ce mode.

Elle se fait directement depuis l’interface (Manager) OVH sur le serveur correspondant :

Une fois le règlement effectué, vous allez pouvoir programmer l’intervention depuis cette même interface. Pour être certain du bon déroulement de l’opération, j’ajoute un ticket indiquant la référence de la commande au support OVH du type :

Sujet : Ajout de 6 nvme en conservant les nvme / la configuration actuelle commande N°xxxxxxxx
Message:  Bonjour, suite à ma commande N°xxxxxxxx, l'opération consistera à ajouter les 6 SSD NVMe sans toucher aux SSD NVMes actuels. Merci.

Si je fais cette précision, c’est qu’il n’est pas possible de commander un « ajout de 6 x NVMe » par défaut : on choisit une autre configuration (cf capture plus haut) tel que « 12 x NVMe » qui pourrait alors consister à remplacer l’ensemble des SSD…

Dans la pratique, cela ne serait pas dramatique puisque chaque nœud est vidé en préambule à la demande d’intervention, ceci étant dit, je préfère m’éviter un travail de configuration supplémentaire.

Une fois, la date et l’heure de l’intervention confirmées, cette dernière devrait se dérouler sans anicroche. Vous serez prévenu par la suite du début et de la fin de l’intervention via des messages automatique, puis directement par le support (tout du moins si vous bénéficiez d’un niveau de support de type Business ou supérieur).

Bonjour Monsieur Casalegno, 
L'intervention en datacenter est terminée pour le serveur xxxxxxxx.
Comme demandé, nous avons ajouté 6x 3.84To 32gbit/s 512n disques nvme supplémentaires.
Le serveur a redémarré avec les outils internes :
Journaux SEL OK.
Tous les modules de mémoire DIMM détectés
Tous les lecteurs détectés.
Connectivité réseau OK.
Firewall OK.
Vérification du matériel OK.
Résumé de la demande : Ajout de 6 nvme
Action entreprise : Ajout de 6 nvme
Date création de la demande : 13/11/2023
Résolution de la demande : 18/11/2023
Je me permets de résoudre ce ticket et reste à votre disposition.
Bon week-end, 

Une fois ces opérations effectuées, il est temps de passer à la configuration d’un nouveau RAID.

Une fois connecté sur le serveur, et après avoir effectué un check général (réintégration au cluster, intégrité des RAIDs préexistants, etc.) on vient vérifier l’ajout effectué.

La commande lsblk permet de lister les informations sur tous les périphériques de bloc disponibles sur la machine, tels que les disques durs, les SSD, etc.

Elle affiche des détails tels que le nom du périphérique, le type de périphérique (comme disque ou partition), la taille et le point de montage correspondant.

C’est un outil pratique pour obtenir un aperçu rapide de la structure des périphériques de stockage sur un système GNU / Linux.

Comme vous pouvez le voir dans la vidéo, cela permet de différencier très clairement les disques non attribués tout en vérifiant qu’ils ont bien la bonne spécification (type NVMe et taille notamment).

Exemple: (j’ai coupé pour ne pas que la capture prenne plusieurs pages)

On passe ensuite à la création du raid. Pour ce faire, nous allons utiliser la commande « mdadm ». Sur un système GNU / Linux, mdadm est un peu un couteau suisse du RAID Software : elle permet créer, gérer, et surveiller les arrays RAID.

mdadm --create /dev/md7 --level=10 --raid-devices=6 /dev/nvme6n1 /dev/nvme7n1 /dev/nvme8n1 /dev/nvme9n1 /dev/nvme10n1 /dev/nvme11n1

Explications :

–create /dev/md7: ceci indique à mdadm de créer un nouvel array RAID et de le nommer /dev/md7.

–level=10: on détermine ici le niveau du RAID à créer, qui est RAID 10 dans ce cas comme indiqué plus haut.

–raid-devices=6: on indique à mdadm qu’il y aura aura six périphériques (ici, 6 SSD NVMe) dans l’array RAID que nous lui demandons de créer.

/dev/nvme6n1 /dev/nvme7n1 /dev/nvme8n1 /dev/nvme9n1 /dev/nvme10n1 /dev/nvme11n1: Ce sont les noms des périphériques de stockage qui ont été ajouté par OVHcloud et que nous souhaitons inclure dans notre nouveau RAID.

Une fois cette commandée lancée, la création du RAID va commencer. Bien qu’il soit utilisable immédiatement, ce n’est qu’à son terme qu’il sera réellement et complètement effectif.

On peut utiliser la commande :

cat /proc/mdstat

Dans la vidéo, je débride la vitesse pour une construction plus rapide. On peut vérifier la limitation actuelle via la commande :

cat /proc/sys/dev/raid/speed_limit_max

Je la débride via la commande suivante :

echo 8000000 > /proc/sys/dev/raid/speed_limit_max

Ceci va nous permettre d’atteindre une vitesse de construction plus que respectable ;)

Avec des pointes enregistrées à près de 6 GB/s.

Une fois que l’opération est terminée, vous devriez avoir un résultat « fixe » comme cela :

On procède alors au formatage de la partition, ici en ext4 qui est le système de fichier que j’utilise sur ces nœuds :

mkfs.ext4 /dev/md7

Une fois le formatage terminé, je lance la commande :

update-initramfs -u -k all

Explications :

update-initramfs permet de gérer l’initramfs : un système de fichiers temporaire chargé en mémoire lors du démarrage du système. C’est lui qui contient les modules et outils nécessaires pour monter le système de fichiers racine et démarrer le système d’exploitation.

-u : Cette option signifie « update » (mise à jour). Elle indique que l’initramfs existant pour le ou les noyaux spécifiés doit être mis à jour.

-k all : Cette option spécifie les versions du noyau pour lesquelles l’initramfs doit être mis à jour. L’utilisation de « all » signifie que l’initramfs sera actualisé pour toutes les versions du noyau installées sur le système (dans mon cas, je conserve les anciens noyaux installés et je veux m’assurer qu’ils ont tous un initramfs à jour).

Une fois cette opération effectuée, je reboote le système avec la commande

reboot

Lorsque le système d’exploitation a enfin redémarré, je viens récupérer l’UUID du raid nouvellement crée via la commande :

mdadm --detail /dev/md7 |grep UUID

12:11:43-root@node3:~$ cat /etc/mdadm.conf
ARRAY /dev/md/md2  metadata=1.2 UUID=27c87a5c:bde1fc9f:ba924f41:03efebee name=md2
ARRAY /dev/md/md4  metadata=1.2 UUID=97989221:936a0203:e9397bdf:4f94eeec name=md4
ARRAY /dev/md/6	   metadata=1.2 UUID=03f164d2:75dd0904:106bc607:49d34bd6 name=md6
ARRAY /dev/md/7	   metadata=1.2 UUID=e7a46330:3eda33a5:b9875d8d:e00f072a name=md7

Note : Il peut y avoir des disparités dans le nommage. Ainsi, vous pourrez vous retrouver, dans les mêmes circonstances, avec un ARRAY à indiquer du type : /dev/md7, /dev/md/7 ou encore /dev/md/node4:7

Ce « nommage » des arrays RAID à indiquer peut varier en fonction de la manière dont ils sont configurés, des conventions spécifiques à la distribution ou à la version du système, des mises à jour du système ou de l’outil mdadm, et de l’utilisation de noms personnalisés ou de scripts de gestion spécifiques.

Une fois ces opérations effectuées, il faut créer le point de montage (il existait déjà dans la vidéo), mais s’il n’existe pas, un simple

mkdir /datastore2

Il ne reste plus qu’à renseigner notre fichier fstab : ce fichier est une entrée de configuration indiquant au système d’exploitation comment monter automatiquement un système de fichiers spécifique au démarrage.

Vous pouvez procéder de plusieurs manières. Vous pouvez indiquer le chemin du périphérique RAID correspondant (version « legacy ») ou encore son UUID :

Pour la version legacy :

/dev/md7	/datastore2	ext4	defaults,relatime	0	0

Pour la version UUID, il faut d’abord le récupérer. Pour se faire vous allez utiliser la commande blkid :

Je vous conseille vraiment de l’utiliser avec le grep pour une meilleure lisibilité, voilà ce que cela peut donner sinon :

C’est tout de suite un peu moins lisible.

Une fois l’UUID récupéré, il ne vous reste plus qu’à ajouter à votre fichier fstab la ligne correspondante :

UUID=2a7c6b05-eb0e-406e-9fbf-50236d46d7a9	/datastore2	ext4	defaults,relatime	0      0

Explications:

UUID=2a7c6b05-eb0e-406e-9fbf-50236d46d7a9 : UUID signifie « Universally Unique Identifier ». Il s’agit d’un identifiant unique pour le système de fichiers sur le disque dur ou la partition.

2a7c6b05-eb0e-406e-9fbf-50236d46d7a9 est l’UUID spécifique de la partition concernée, que nous venons de récupérer via la commande blkid. C’est un identifiant unique permettant une identification réputée fiable.

/datastore2 : il s’agit du point de montage que nous venons de créer, c’est-à-dire le répertoire dans l’arborescence du système de fichiers où la partition ou le RAID sera accessible une fois monté.

ext4 : C’est le type du système de fichiers de la partition. Il peut varier en fonction de vos choix.

defaults,relatime : Ce sont les options de montage pour le système de fichiers.

– defaults représente un ensemble d’options par défaut (comme le montage en lecture-écriture, l’exécution de programmes, etc.).

– relatime est une option qui actualise les horodatages d’accès des fichiers seulement dans certaines conditions, ce qui peut améliorer les performances.

0 : Ce premier chiffre (0 dans ce cas) indique la nécessité ou non de faire un dump du système de fichiers. Une valeur de 0 signifie que le dump n’est pas nécessaire pour cette partition.

0 : Ce second chiffre détermine l’ordre de vérification du système de fichiers lors du démarrage. Une valeur de 0 signifie que le système de fichiers ne sera pas vérifié au démarrage. Cette valeur est à adapter en fonction de vos usecases, nécessité de vitesse de redémarrage pour correction manuelle ou automatique, etc.

Il ne reste maintenant plus qu’à tester le montage via la commande :

mount /datastore2

umount /datastore2

La dernière opération consiste à ajouter le stockage dans l’interface de Proxmox pour pouvoir en profiter :

Rendez-vous dans « Datacenter », puis Storage, Add et finalement : Directory
Il ne vous reste plus qu’à indiquer un id de votre choix (pour moi ce sera datastore2) ainsi que le répertoire correspondant dans le champs directory.

« Content » sert à indiquer à proxmox le types de contenus qui peuvent se trouver sur ce stockage (dans mon cas, ce sera seulement « disk image).

Voilà ce que cela donne une fois crée de mon coté :

Enjoy !

Vous pouvez me suivre sur : Telegram | YouTube | Twitter | Facebook | LinkedIn | Twitch