Cluster on Zwindler's Reflection

MicroStack évolue : compatibilité HP EliteDesk et Lenovo ThinkCentre pour votre homelab

Wed, 17 Sep 2025 12:00:00 +0200

Un update de MicroStack ? 😍

Eh oui ! Il y a quelques mois, je vous présentais MicroStack, mon projet de rack modulaire imprimé en 3D pour Dell Micro. Le projet a eu un succès inattendu sur MakerWorld / Bluesky (et même un peu Reddit) et j’ai reçu plusieurs demandes pour étendre la compatibilité…

Et comme je suis gentil (et que j’aime bien mes side-projects d’impression 3D), j’ai décidé de répondre aux demandes de la communauté !

La promesse tenue : HP EliteDesk et Lenovo ThinkCentre !

Dans l’article original, j’avais mentionné qu’“une version compatible avec les Lenovo ThinkCentre Tiny était envisagée”. Ben… c’est fait ! Et j’ai même fait un bonus avec les HP EliteDesk/ProDesk parce que… pourquoi pas ?

Désormais, le projet MicroStack supporte officiellement trois gammes de mini-PC :

Dell OptiPlex Micro (toutes générations) - le pionnier
Lenovo ThinkCentre Tiny
HP EliteDesk/ProDesk

Un écosystème qui grandit

Le concept reste identique : des modules empilables et modulaires pour organiser proprement votre homelab. Mais maintenant, vous pouvez mixer les marques dans un même rack si vous avez un parc hétérogène (et on sait tous comment ça arrive en homelab… “oh regarde, cette machine d’occaz est à bon prix !”).

La collection complète MicroStack comprend maintenant :

Modules pour PC :

Module Dell Micro - l’original
Module Lenovo ThinkCentre - le demandé (grâce à un prêt de quelqu’un sur LinkedIn ! Merci !)
Module HP EliteDesk/ProDesk - le bonus

Modules communs :

Module de stockage - pour switch, accessoires, etc.
Chapeau - finition propre du rack

Tous ces modules sont inter-compatibles et utilisent le même système d’empilement.

Toujours les mêmes bonnes pratiques

Comme pour l’original, je recommande toujours d’imprimer en PETG (voire ASA ou ABS ?) plutôt qu’en PLA pour une meilleure résistance à la chaleur, même si ces mini-PC restent assez froids. Le design honeycomb du plancher assure une bonne ventilation tout en économisant du filament.

Le retour d’expérience : la modélisation multi-gammes

Adapter le design original aux nouvelles gammes a été plus simple que prévu, grâce à la base solide du projet initial. Une fois le concept établi avec le module Dell, il “suffit” de :

Prendre les mesures (précises !) des nouveaux modèles (encore faut il en trouver…)
Adapter les dimensions du châssis
Faire un (ou plusieurs) test d’impression et valider l’empilement (le stress, à chaque fois, d’avoir crâmé 120g de plastique pour rien si on s’est planté)

Chaque nouveau module m’a pris une petite heure de modélisation, soit beaucoup moins que les 3x2h initiales du projet original. Le prototypage (tester des versions incomplètes pour économiser du plastique) ont pris pas mal de temps, que j’avais oublié de compter dans l’article précédent. Facilement quelques heures de plus.

Le feedback de la communauté

Ce qui me fait le plus plaisir, c’est de voir que le projet a trouvé son public. Les retours sur MakerWorld sont globalement enthousiastes et les demandes d’évolution montrent que le concept répond vraiment à un besoin.

Quelques utilisateurs m’ont déjà envoyé des photos de leurs installations mixtes avec différentes marques dans le même rack. C’est exactement l’esprit modulaire que je voulais insuffler au projet !

J’ai aussi eu un retour négatif, pour lequel je ne peux pas faire grand chose en l’état mais qui était intéressant et m’a permis de rajouter un avertissement. Le fait que l’arrière soit dédié pour le chargeur (PSU) bloque certains ports, en particulier pour le Lenovo. Les solutions :

Vivre avec seulement l’Ethernet (pour un lab, perso je trouve que ça va)
Déporter les alims dans le module de “stockage”

Et maintenant ?

Avec ces trois gammes couvertes, mon projet MicroStack devient vraiment polyvalent. Si vous avez des suggestions d’autres mini-PC à supporter, n’hésitez pas ! Les MinisForum, peut être ?

Si ce projet vous intéresse, n’hésitez pas à commenter, partager, faire des retours, voire booster les trois modèles pour ceux qui ont un compte MakerWorld (c’est gratuit, mais ça fait plaisir :-P).

MicroStack - un projet open source pour imprimer un rack modulable pour mon homelab Dell Micro

Sat, 22 Mar 2025 12:00:00 +0200

ENCORE ? Encore une évolution de ton lab ???

Si vous suivez un peu le lore de mon blog, vous savez que j’ai autant de version de mon homelab que d’années d’expérience XD.

2025 ne fera donc pas exception. Début 2024, je me lançais dans la construction d’un rack à base de profilé aluminium et d’impression 3D, à partir d’un projet envoyé par un copain sur Whatsapp !

Mais à l’usage, je le trouvais massif, pas super pratique, pas très joli… bref, pas adapté à mon besoin.

Sauf que (j’en ai déjà parlé) je me suis depuis mis à l’impression 3D et un peu (par la force des choses) à la modélisation 3D (ça va souvent de pair). Je me suis dis : pourquoi ne pas créer mon propre projet collant à mes besoins ?

J’ai donc voulu explorer une solution maison pour mon homelab, imprimée en 3D, qui serait à la fois modulaire et empilable. L’idée était de proposer un système adaptable selon les besoins, avec un design simple et efficace.

Un design pensé pour l’organisation

Le MicroStack Rack est conçu pour ranger proprement plusieurs Dell OptiPlex Micro tout en maximisant l’espace. Il se compose de trois modules différents pour l’instant :

Le module PC, qui accueille un Dell Micro (toutes générations) et son alimentation externe à l’arrière pour plus de praticité.

Le module de stockage, un compartiment vide pour accessoires, switch réseau ou autres équipements.

Le chapeau, un élément optionnel qui recouvre le rack pour un rendu plus propre.

Tous les modules sont empilables, permettant d’adapter la configuration selon votre nombre de machines.

Même si j’ai imprimé le prototype en PLA je vous conseille plutôt d’utiliser du PETG, qui résiste mieux à la chaleur que le PLA. Cependant, ces machines restent plutôt froides en idle et le plancher en nid d’abeille permet d’améliorer la ventilation (et de réduire la consommation de matière). Peut-être que ça marche aussi.

Combien de temps ça prend de faire ce genre de projet ?

Petit point temps passé.

Je n’ai pas fait beaucoup de conception 3D dans le passé (j’ai fait quelques maps sur Unreal Tournament 2004… oh me..e, ça fait 20 ans !!!). Donc, je me dis que ça peut être intéressant de partager combien de temps ça m’a pris.

La modélisation a été réalisée en trois sessions de 2 heures :

2h pour prendre les mesures, faire un prototype initial et se familiariser avec Blender.
2h pour créer le module dédié au Dell Micro.
2h pour ajouter le module de stockage et le chapeau (ça va plus vite, j’ai déjà fait une partie du boulot et je suis plus efficace dans mon usage de Blender).

On peut rajouter une heure ou deux pour la manutention de l’imprimante 3D (lancer l’impression, vérifier qu’elle ne foire pas quelques minutes, nettoyer la plaque après impression, etc) et 3-4h pour la partie “sociale” (photos, upload sur makerworld, rédaction des descriptions et du blogpost, partage sur les réseaux).

Un bon petit sideproject d’une dizaine d’heures donc.

Fichiers et évolutions

Comme promis sur Bluesky où j’avais teasé le projet, les fichiers sont disponibles sous licence Creative Commons 4.0 BY-SA sur MakerWorld dans les formats 3MF, STL et les sources de blender :

Une version compatible avec les Lenovo ThinkCentre Tiny est envisagée pour la suite (on me l’a demandée sur Bluesky).

Si ce projet vous intéresse, n’hésitez pas à commenter, partager, faire des retours, voire booster les trois modèles pour ceux qui ont un compte MakerWorld (c’est gratuit, mais ça fait plaisir :-P).

MicroRack v1 - un rack compact pour les Dell Micro de mon homelab

Thu, 15 Feb 2024 17:00:00 +0200

Yet another homelab (again)

Il y a quasiment 10 ans (à 1 mois près), je concevais et construisais mon propre “meuble” pour mon homelab de l’époque, composé de plusieurs cartes MicroATX et de matériel récupéré.

Je m’étais inspiré de Ike-hackers (pour ceux qui ne connaissent pas les Ikea-hacks ou Ikeacks, je vous laisse chercher, ça vaut le coup) qui transformaient un meuble “Red helmer” en cluster de rendering 3D.

Depuis, mon homelab a changé 45 fois (à peu près) et récemment, je me suis lancé dans un lab basé sur des dell micro, des tout petits desktops (il y en a aussi chez HP et Lenovo) qui consomment peu (donc peu puissants) et sont assez robustes :

L’article à ce sujet

Crude but effective

On ne va pas se mentir, trimballer ça dans un bac “Trofast” de chez Ikea, c’est quand même un peu bourrin. Mais faute de mieux c’était pas mal.

Quelques mois plus tard, un très bon copain (dont le seul défaut est qu’il vit en Australie et que bon, c’est un peu loin pour les apéros) m’envoie ça :

printables.com - SergeiBuilds - Mini Lab Rack For Dell Optiplex MFF Servers

Un “rack” compact et propre pour ranger des dell micro ??? A faire en DIY ?

Mais c’est trop bien !!

Problème(s)

Bon, sur le papier ça a l’air cool, mais il y a quand même plusieurs problèmes à régler. D’abord, le lien sur printables.com est assez peu détaillé. Les photos sont pas tops (on ne voit pas comment c’est monté), on sait juste qu’il faut imprimer des pièces (dont les modèles sont fournis) et qu’il faut monter ça dans un cadre en aluminium.

The frame is assembled from 4x 200mm, 4x 300mm, 4x 400mm & 2x 360mm 2020 aluminium extrusion and held together with L corner brackets. The overall dimensions are 240mm wide, 400mm high & 340mm deep.

D’abord: je n’ai pas d’imprimante 3D (et je n’y connais rien).

On m’a conseillé plusieurs moyens de contournement. En acheter une (le plus simple xD), demander à un copain, passer dans un fablab, la faire imprimer sur Internet (ça coûte assez cher).

(Finalement, j’ai trouvé une âme charitable pour me les imprimer au boulot, merci Fabien)

Ensuite, comment on l’achète et on le monte ce fichu cadre en aluminium ?

A force de recherches (décembre 2023), j’ai fini par trouver que les “2020 aluminium extrusion” s’appellent en bon français des “profilés aluminium 20x20”.

On peut en trouver sur Amazon pré-coupés (c’est fort cher). Et même si on en prend des grands à recouper soi-même, j’avais un peu peur de la précision de coupe (même si je suis outillé).

Heureusement, on a fini par me donner l’adresse d’un site industriel qui en vend à la découpe (motedis.fr).

Profilé aluminium 20x20 Type B rainure 6

Pour assembler les profilés, il faut des équerres internes (L corner brackets, fallait deviner…). Heureusement on en trouve aussi chez Motedis, je suis tombé dessus par hasard en fouillant les vidéos du site !

Équerre interne 20 B-Type rainure 6 M5 Alternative

Il en faut 20 (ce que ne dit pas ce cher SergeiBuilds, j’ai compté 3 fois pour être bien sûr).

Une fois que vous avez pris ces deux trucs là, vous en avez déjà pour 60€ (dont 20€ de frais de port)…

Il faut aussi des écrous à glisser dans les rails pour fixer nos pièces de PLA, ainsi que des vis M5. J’en ai compté 24 mais je ne les ai pas achetés (on y reviendra dans la section suivante).

Et là, c’est le drame

Je laisse passer décembre (trop occupé) et je commande tout ça (mi-janvier 2024)

Au bout de quelques jours, ma commande Motedis est arrivée et j’étais comme un gosse à Noël. Mais je déchante très très vite…

Les équerres ne rentrent pas dans le profilé. Un peu bourrin (oui je suis pas toujours très fin), je tape dessus au marteau. Sur les extrémités ça marche (bien). Au milieu, j’arrive à mettre le premier. Mais je casse les suivantes.

Pourtant c’est bien du 2020 mon profilé 🤔…

Bon, je ne vous fais pas mariner trop longtemps. La raison c’est que je n’ai pas pris le bon profilé 2020. Il existe 2 sortes, toutes les deux disponibles sur Motedis et j’ai pris la mauvaise :

Grosso modo, j’ai pris par erreur les types I, qui ont une rainure “arrondie” de 5, alors que ceux qu’il fallait, c’était des types B, avec une rainure trapézoïdale de 6…

A partir de là, 2 solutions :

je rachète tout
je m’adapte

Ca m’ennuie de jeter de l’alu parce que j’ai été trop bête… J’ai donc décidé (5 février) de trouver des solutions, quitte à ce que le rendu soit moins “net”. J’ai donc remplacé l’usage des écrous+vis M5 par visser les parties imprimées.

Clairement, le résultat me parait acceptable.

Mais ne faites pas la même erreur que moi, car il sera impossible d’avoir un rendu parfait avec des vis plantées dans un rail alu. L’avantage des équerres et des écrous + vis M5, c’est que c’est repositionnable juste en desserrant / resserrant la vis.

Le 13 février, j’ai reçu de la part de mon collègue les pièces imprimées en PLA.

Premier problème : comme je dois les visser directement dans le rail alu (puisque je ne peux pas insérer d’écrous pour mes vis M5) je ne peux pas les positionner correctement. Même en faisant de mon mieux, j’ai parfois des petits “jours” d’un 1/2 millimètre.

Deuxième problème : je ne peux pas non plus visser la cage pour le switch, car je ne pourrais pas passer un tournevis. Je laisse ce problème de côté dans un premier temps.

Troisième problème, je n’ai pas vérifié, mais mon switch est trop épais. Je découpe donc à la Dremel (content de l’avoir même si elle sert pas souvent) et à la pince perroquet mon bout de PLA. Petite surprise (évidente) : le PLA, ça fond 😅.

J’arrive quand même à tout assembler et à obtenir un résultat correct. C’est fonctionnel, ça reste joli malgré quelques imprécisions, et c’est assez pratique à l’usage.

La suite ?

Après avoir posté ça sur Twitter et à quelques copains, on m’a donné quelques idées d’améliorations, qui serviront pour une V2 :

Ajouter des pieds, en taraudant le tube central des profilés
Remplacer le passe câble Ethernet du haut et la cage pour le switch en dessous par un support caché pour un switch 8 ports. Il n’y a vraiment de raison fonctionnelle à ce que les ports soient visibles et 5 ports c’est trop limité. Pourquoi pas acheter un managé tant qu’à y être.
En profiter pour ajouter un étage de plus (dell micro ? Raspberry pi ?)
Remplacer la multiprise (en prendre une connectée ?) et trouver un moyen de la fixer proprement sur les rails
Trouver un moyen de fixer les alims pour qu’elles ne pendouillent pas
Ajouter un pikvm (cher++ !) pour se passer du mini écran ? A voir
Éventuellement couvrir une partie des côtés avec du plexi ? A voir

Pour l’instant je ne vais rien faire, car je suis content du résultat (et un peu fatigué de tout ces rebondissements !). Mais on verra après un peu d’usage ce que je fais / ne fais pas :)

En attendant, have fun !

Stockage distribué et répliqué avec DRBD

Mon, 11 May 2020 06:35:00 +0000

DRBD

En 2015, j’avais voulu essayer la solution de stockage distribué DRBD. Et oui, 2015. C’est mon plus vieux brouillon sur le blog que je sors enfin. Vous vous en doutez, j’ai du repasser dessus pour ne pas vous donner de versions antédiluvienne ;-)

DRBD (pour Distributed Replicated Block Device) est donc un logiciel disponible sous Linux et Windows qui permet de gérer des périphériques de stockages virtuels utilisables dans des infrastructures.

Ces périphériques ont la particularité de pouvoir être « distribués » sur plusieurs serveurs sur un réseau de façon synchrone ou asynchrone et disposant de plusieurs méthodes de resynchronisation en cas de perte de lien ou d’incohérences.

L’avantage de cette solution est qu’elle est robuste (fiabilité éprouvée) et qu’elle permet de répondre à des problématiques de haute disponibilité et de performance que n’offrent pas forcément toutes les solutions de stockage.

Si cette solution peut paraître de prime abord un peu datée à l’époque des containers et de Kubernetes, sachez que Linbit a fait un effort assez conséquent justement sur cette partie, en essayant de se positionner comme un des acteurs du stockage distribué pour les architectures containerisées et/ou “cloud native” (surtout trusté par Ceph/CephFS, voire Gluster).

Prérequis

Pour tester DRBD, vous l’aurez compris, il va nous falloir au minimum deux serveurs. Pour faire simple, je vais utiliser des machines virtuelles (mais évidemment ça fonctionnera mieux sur un serveur physique) sur lesquelles j’ai installé une image Ubuntu 18.04.

Dans mon cas, j’ai rajouté des disques virtuels de 16Go, pour simuler des disques physiques à synchroniser. De même, j’ai également rajouté des interfaces réseaux supplémentaires pour simuler un réseau dédié « stockage ».

Installation du logiciel

La société LINBIT qui distribue le logiciel DRBD propose des packages précompilés pour la plupart des distributions Linux classiques. L’ensemble des packages des différentes versions de DRBD sont disponibles sur le site de Linbit. Cependant, ces packages « officiels » précompilés nécessitent d’avoir payé le support.

Note : Si les packages officiels sont réservés aux personnes qui payent le support, les sources, elles, sont bien entendu disponibles sur le site.

Heureusement, il est possible d’utiliser tout simplement les packages précompilés de votre distribution.

A la base, quand j’avais écrit le tutoriel en 2015, j’avais des soucis de compatibilité entre la version du kernel et drbd de ma distribution CentOS (6.3 à l’époque…). Ma version, 2.6.32-279 alors que les versions 8.3 et 8.4 de DRBD nécessitent le kernel 2.6.32-431. Mais rien ne vous empêche d’installer le kernel demandé pour résoudre ce problème.

Pour ce tuto, voici les commandes que j’ai dû utiliser pour installer DRBD 9 (la dernière stable même si la 10 arrive bientôt) sur mes Ubuntu 18.04.

sudo apt update
sudo apt upgrade
sudo apt install software-properties-common
sudo add-apt-repository ppa:linbit/linbit-drbd9-stack
sudo apt-get update
sudo apt install drbd-utils python-drbdmanage drbd-dkms

Une fois que c’est installé, testez que tout fonctionne avec la commande suivante :

sudo modprobe drbd

Si tout se passe bien, elle ne devrait remonter aucune erreur. En revanche, si vous n’avez pas un kernel avec une version compatible, vous devriez avoir une erreur du type “file not found”. Dans ce cas-là, il faudra compiler DRBD à la main.

Préparation des machines

Les serveurs doivent évidemment pouvoir se joindre et se résoudre. Le mieux étant bien sûr un DNS correct, on pourra se rabattre dans le cadre d’un test sur a minima un fichier /etc/hosts contenant les informations nécessaires :

192.168.100.11 drbd1 drbd1.example.org
192.168.100.12 drbd2 drbd2.example.org

Ensuite, j’ai créé, sur chaque serveur, deux partitions de 8 Go chacun sur le disque de 16. La première sera de type Linux, la seconde sera de type LVM.

On oublie pas de créer les objets LVM pour pouvoir les utiliser plus tard.

pvcreate /dev/sdb2
vgcreate vg_drbd /dev/sdb2
lvcreate -n lv_drbd -l 2047 vg_drbd

Configuration

Le fichier de configuration global de DRBD est /etc/drbd.conf. Il définit les fichiers unitaires qui doivent être modifiés. Le fichier /etc/drbd.conf en lui-même ne doit donc pas être modifié directement ; sauf dans le cas où on souhaite changer les fichiers de configuration inclus de répertoire.

cat /etc/drbd.conf
# You can find an example in /usr/share/doc/drbd.../drbd.conf.example
include "drbd.d/global_common.conf";
include "drbd.d/*.res";

Le fichier suivant doit contenir les paramètres et les commandes qui sont globaux à toutes les ressources DRBD.

cat /etc/drbd.d/global_common.conf
# DRBD is the result of over a decade of development by LINBIT.
# In case you need professional services for DRBD or have
# feature requests visit http://www.linbit.com
global {
[...]

Template de ressource

Pour rendre la configuration lisible, on sépare les fichiers de configuration de manière à faire un fichier texte par ressource, nommé avec la convention r[nombre].res. Ici on prendra l’exemple le plus simple d’une synchronisation synchrone (protocole C, par défaut) dans un modèle actif/passif. Pour vous aider à créer vos premières ressources, DRBD met à disposition, dans /etc/drbd.d/drbdctrl.res_template un template dans lequel vous n’aurez qu’à modifier les valeurs.

resource .drbdctrl {
net {
cram-hmac-alg sha1;
shared-secret "<your-shared-secret>";
}
volume 0 {
device /dev/drbd0 minor 0;
disk /dev/mapper/<vgname>-.drbdctrl;
meta-disk internal;
}
on <node_1> {
node-id 0;
address <ipaddress>:<port>;
}
on <node_n> {
node-id <n>;
address <ipaddress>:<port>;
}
connection-mesh {
hosts <node_1> <node_2> ... <node_n>;
net {
protocol C;
}
}
}

Ressource pour un disque “simple”

Ici, c’est l’exemple le plus simple. On va indiquer que notre ressource est distribuée sur 2 serveurs sur un bête partition Linux. Les metadata, elles, sont stockées en local (ce qui n’est pas forcément le mieux, mais pour commencer ça suffira).

vi /etc/drbd.d/r0.res
resource r0 {
on drbd1 {
device /dev/drbd1;
disk /dev/sdb1;
address 192.168.100.11:7789;
meta-disk internal;
}
on drbd2 {
device /dev/drbd1;
disk /dev/sdb1;
address 192.168.100.12:7789;
meta-disk internal;
}
}

Note : si le protocole de synchronisation n’est pas spécifié, on est en synchronisation synchrone par défaut.

Attention : chaque ressource déclarée réserve le port TCP pour la communication de la ressource. Il faut donc incrémenter le numéro du device drbd ET incrémenter le numéro de port à chaque nouvelle ressource (et aussi s’assurer que le port est libre…).

Pour mes tests, j’ai également utilisé la possibilité offerte par DRBD d’utiliser des volumes LVM plutôt que des partitions brutes. La configuration est la même à ceci près qu’on pointe sur le LV plutôt que sur une partition.

vi /etc/drbd.d/r1.res
resource r1 {
on drbd1 {
device /dev/drbd2;
disk /dev/vg_drbd/lv_drbd;
address 192.168.100.11:7790;
meta-disk internal;
}
on drbd2 {
device /dev/drbd2;
disk /dev/vg_drbd/lv_drbd;
address 192.168.100.12:7790;
meta-disk internal;
}
}

Initialisation

Maintenant que tout est configuré, on va pouvoir déclencher l’étape d’initialisation des metadata et des ressources nouvellement créées. Lancez les commandes suivantes sur les deux nœuds :

drbdadm create-md r0
drbdadm create-md r1
drbdadm up r0
drbdadm up r1

Une fois que les commandes sont lancées, on peut afficher les informations sur l’initialisation des disques (état normal) avec drbdmon.

Actuellement, les nœuds sont Inconsistants et en Secondaire/Secondaire, car nous n’avons pas encore désigné le nœud principal. Nous allons “forcer” le sens dans lequel le disque doit être synchronisé.

Sélectionner un des nœuds, qu’on va désigner comme “serveur primaire” et exécuter les commandes suivantes (uniquement sur lui) :

root@drbd1:~# drbdadm primary --force r0
root@drbd2:~# drbdadm primary --force r1

ATTENTION : dans le cas d’un disque déjà créé, il faut bien ne pas se tromper de sens, au risque d’écraser le disque qui contiendrait les données.

Une fois la synchronisation terminée, on peut utiliser le disque /dev/drbdX.

C’est fini ?

En fait, pas tout à fait. On ne va pas pouvoir utiliser nos disques exactement comme des disques classiques. Si vous formattez ce disque en ext4/xfs/whatever et que vous essayez de le monter sur vos deux serveurs drbd1 et drbd2, vous allez avoir une drôle de surprise.

En effet, ces filesystems ne savent pas gérer les accès concurrents provenant de deux machines simultanées. On va donc devoir :

soit utiliser un filesystem capable de gérer les accès concurrents (page Wikipedia listant quelques clustered filesystems) comme OCFS2 ou GFS2. Si vous publiez les disques DRBD en iSCSI pour votre cluster VMware, vous n’aurez pas de problème non plus car le VMFS le gère très bien aussi.
soit s’assurer à tout moment que le disque n’est monté que sur un seul serveur à la fois.

Évidemment la 2ème option est à proscrire si vous êtes dans un contexte de production. Cependant, cela reste possible si vous montez un cluster Pacemaker ou RHCS par exemple, qui va s’assurer que les bascules de stockage se font de manière propre.

Enjoy !

Bonus : quelques commandes utiles

Pour une ressource donnée, afficher le rôle du serveur local

root@drbd1:~# drbdadm role r0
Primary
root@drbd1:~# drbdadm role r1
Secondary

Afficher de manière concise l’état d’une ressource sur les nœuds

root@drbd1:~# drbdadm dstate r0
UpToDate/UpToDate
root@drbd1:~# drbdadm dstate r1
Inconsistent/UpToDate

Afficher plus de détails sur une ressource avec drbdadmin pour un résultat simple ou drbdsetup pour avoir plus de détails :

drbdsetup status r1 --verbose --statistics
r1 node-id:1 role:Secondary suspended:no
write-ordering:flush
volume:0 minor:2 disk:Inconsistent quorum:yes
size:8384220 read:0 written:1972628 al-writes:0 bm-writes:0 upper-pending:0 lower-pending:0 al-suspended:no blocked:no
drbd2 node-id:0 connection:Connected role:Primary congested:no ap-in-flight:0 rs-in-flight:0
volume:0 replication:SyncTarget peer-disk:UpToDate done:23.53 resync-suspended:no
received:1972628 sent:0 out-of-sync:6411740 pending:3 unacked:12 dbdt1:92.39 eta:68

En temps normal, toutes les ressources sont actives par défaut. Cependant, on peut les activer ou les désactiver à la main :

drbdadm up r0
drbdadm down r1
# utiliser le mot clé « all » pour désigner toutes les ressources

Si on modifie les fichiers de configuration global ou un fichier de ressource, il est nécessaire de mettre à jour la configuration sur les deux nœuds. Il est possible de reconfigurer les ressources même si elles sont opérationnelles grâce à la méthode suivante :

drdbadm adjust r0

Changer le statut du nœud courant (pour le passer en primary s’il est secondary par exemple)

drbdadm primary r1
drbdadm secondary r0

Sources

User Guide DRBD 9.0 (Anglais)

Changement de provider, mon hyperviseur sur un dédié Hetzner

Tue, 19 Nov 2019 07:30:00 +0000

Au revoir OneProvider, bonjour Hetzner

Certains d’entre vous m’ont peut être vu me plaindre de OneProvider et plus particulièrement le support avec qui j’ai eu plusieurs accrochages (Spoiler, j’ai migré vers Hetzner).

Sans rentrer dans les détails (j’ai échangé avec certains d’entre vous sur le sujet), après cette déconvenue, j’ai donc cherché une alternative pour héberger mes machines.

Les prérequis étaient d’avoir :

une machine physique
avec suffisamment de RAM (minimum 8 Go, 16 c’est mieux)
idéalement, une gestion des réseaux virtuels entre machines du provider (type RPN ou vRack)
si possible pas un ATOM en CPU (le souci de l’ATOM, c’est que c’est tellement faiblard que ça pénalise les IO)
si possible du VT-x (je n’en ai pas besoin d’en l’absolu, je vais surtout du LXC, mais ça peut dépanner)
si possible du SSD parce que c’est quand même cool
si possible 2 disques pour avoir du RAID ou que je puisse me faire un équivalent (ZFS/ZRAID)
un prix pas trop élevé (genre pas OVH) car j’ai été mal habitué avec les prix agressifs de OneProvider (oui je sais, je l’ai payé avec le support)

L’état du marché

Chez OneProvider, j’avais tout ça pour environ 20-25 euros / mois, à l’exception du réseaux privé virtuel entre machine.

Autant dire qu’on est très loin du premier prix de chez OVH (>60€/mois TTC). Si on descend en gamme chez OVH, on perd le réseau privé virtuel entre machines (vRack) en passant chez SoYouStart et pourtant on est toujours à plus de 42€ / mois TTC. Toujours 2 fois plus cher que OneProvider :-/.

Il faut descendre encore de gamme et passer chez Kimsufi pour trouver des prix comparables dans mes critères (et toujours pas de réseau privé virtuel), avec de vieux CPU et surtout un réseau bridé au 100 Mbps (ce qui est pénible pour les transferts de gros fichiers, les réplications de VMs et les sauvegardes).

J’avais aussi jeté un œil côté Online.net, qui eux proposent sur certaines machines identiques à celles que j’avais avec EN PLUS le graal, un réseau privé virtuel entre dédiés (RPN).

Ces deux configs me disaient vraiment quelque chose… et pour cause ! OneProvider les revends en marque blanche.

Donc c’est exactement les mêmes machines que celle que j’ai pu avoir dans le passé, mais avec le RPN en plus, et un peu plus cher (beaucoup plus cher même).

Ce qui est dommage ici, c’est que le RPN ne soit pas disponible sur les machines un peu plus petites (mon PRA n’est pas aussi gros, juste de quoi faire tourner le blog en cas de gros crash).

Vient alors Hetzner

Ça fait pas mal de fois que je voyais circuler le nom. Des bloggeurs et d’autres confrères en disaient beaucoup de bien, et j’ai voulu aller voir. La première chose intéressante est que Hetzner, comme OVH et Online, propose bien un service de type réseau privé virtuel entre vos serveurs !

Plus de puissance chez Hetzner !

Par contre, quand j’ai vu les machines… au début je me suis dis que ça allait pas le faire…

Voilà leur machine “bas de gamme” :

Pour à peine plus que le moins cher des SoYouStart (un vieux Xeon E3 v2 4c/4t avec 16Go de RAM et 2 HDD), vous avez un tout nouveau Ryzen 5 6c/12t, 64 Go de RAM et un RAID de 2 SSD NVMe de 512 Go.

Bon clairement on était hors budget mais ils avaient piqué ma curiosité avec leurs config fofolles.

Et je suis donc tombé en fouillant un peu sur leur “server auction”, qui est ni plus ni moins que les serveurs de leurs anciennes gammes qu’ils louent à nouveau. Et là c’était déjà plus proche de mon besoin.

Pour un peu plus de 30€/mois soit 50% plus que mon serveur précédent, mais comparable au prix Online, j’ai un i7-4770, 32 Go de RAM et 2 disques “Entreprise”. Soit beaucoup mieux que la machine chez Online.

Quitte à changer, j’ai donc tenté Hetzner et commandé un serveur.

C’est puissant mais… qu’est ce que c’est moche

Bon, l’UI n’est pas follement attrayante. C’est… spartiate.

Dans le menu “Servers”, vous avez une bête liste de vos serveurs avec le numéro de commande, un hostname (une fois que vous l’aurez setté) et un ID (peu parlant). Bof pratique, surtout au début ou si vous en avez beaucoup.

Et quand on sélectionne un serveur, ce n’est malheureusement guère mieux. Les informations importantes éclatées dans un nombre incalculable de menus.

Bref, côté expérience utilisateur, on repassera. Cependant, tout ce qu’il faut pour bien administrer son serveur est là. On finira par s’y retrouver avec un peu d’habitude…

Installation de l’hyperviseur

Pour installer notre serveur, on peut utiliser l’interface web pour installer un Debian, ou passer par l’image de rescue.

J’ai préféré utiliser la 2ème solution, car elle est immédiatement disponible à la livraison du serveur, avec votre clé SSH.

On arrive sur un login on ne peut plus classique, avec un résumé des caractéristiques de vos serveurs.

Point intéressant, il existe un binaire installimage sur l’OS rescue de Hetzner. Il permet, comme son nom l’indique, d’installer une image.

Comme j’utilise Proxmox VE comme hyperviseur, j’ai donc installé une Debian 10 :

Une fois l’image de base choisie, vous allez arriver à un éditeur de texte. Il va vous permettre de configurer de manière plus fine votre installation. Je trouve cette méthode assez originale. Ça change des interfaces webs pas toujours stables vous demandant la taille de vos partitions pour finalement planter dès que vous demandez un truc non standard.

Ici tout a très bien marché, j’ai configuré le hostname, ainsi qu’un RAID soft et un partitionnement LVM.

Là encore, je suis navré qu’on tombe dans le cliché, mais si ce n’est pas “joli” ni “user friendly”, au moins c’est efficace.

Passer de Debian 10 à Proxmox VE 6

Une fois validé, l’image Debian 10 a été copié extrêmement rapidement (une ou deux minutes). Forcément, c’est une “minimal”. Mais bon c’est quand même agréable d’avoir son serveur “up and running” en moins d’une demie heure entre la commande et la fin de l’installation.

Reste donc à installer PVE 6 sur notre dédié Hetzner. Sans trop de surprise, j’ai réutilisé mon playbook Ansible qui configure de A à Z la Debian pour en faire un Proxmox. Pour ceux qui l’ont loupé, c’est par ici que ça se passe.

J’ai juste eu un petit souci lors de l’installation. La debian étant minimale, je n’avais même pas python d’installé. C’est gênant quand on fait du Ansible !

cat inventory_hetzner.yml
all:
children:
proxmoxve:
hosts:
<fqdn_hyperviser>:
ansible proxmoxve -i inventory_hetzner.yml -u root -m ping
<fqdn_hyperviser> | FAILED! => {
"changed": false,
"module_stderr": "Shared connection to <fqdn_hyperviser> closed.\r\n",
"module_stdout": "/bin/sh: 1: /usr/bin/python: not found\r\n",
"msg": "MODULE FAILURE",
"rc": 127
}

Heureusement j’avais déjà eu le souci dans un autre contexte. J’ai donc écris un playbook supplémentaire (dispo sur le Github) pour installer les prérequis manquants.

ansible-playbook -i inventory_hetzner.yml -u root proxmox_python_firstinstall.yml
ansible-playbook -i inventory_hetzner.yml -u root proxmox_prerequisites.yml

Et en quelques minutes, mon Proxmox VE était opérationnel sur Hetzner !

Un cluster Proxmox VE avec seulement 2 machines !

Fri, 11 Oct 2019 06:40:55 +0000

Depuis le temps que je vous parle de clusters et de Proxmox (en gros, depuis 2015), ou même de clusters tout court, j’ai pu vous en mettre des tartines sur le fait qu’il ne faut pas faire des clusters avec un nombre pair de machines (ou tout autre cas défavorable dans lequel deux moitiés d’un cluster peuvent se retrouver isolées l’une de l’autre). Le split brain, c’est pas bon pour votre Karma, croyez moi sur parole (ou allez voir vous même).

Ça me rappelle la fois où un “““architecte””” de chez Datacore était venu nous expliquer que sa solution de stockage à 2 pattes ne POUVAIT PAS avoir de split brain (alors que si, les ingés du support ont du repasser par derrière pour nous dire que “oui désolé vous avez évidemment raison c’est un cas possible” #LOL).

Bref, et donc à force d’en parler, il fallait bien quand même que je donne un jour la solution pour le faire quand même, mais proprement. Sans trop de surprise, Corosync, la librairie qui gère les clusters Linux depuis qu’on a arrêté de faire des horreurs avec heartbeat (ou pire : cman+rgmanager, achevez moi), gère évidemment les deux possibilités :

Gérer soit même le membre prioritaire en cas de split brain avec un poids (ça on va pas en parler mais sachez que c’est possible)
Ajouter un vote externe pour obtenir un quorum (comme tous les vrais logiciels qui font du clustering un peu sérieux quoi)

Limitations du “Corosync External Vote” dans PVE

La petite déception du jour viendra surtout du fait que, si la documentation de Proxmox VE indique clairement que l’option est supportée, en réalité, le support se limite aux fonctions natives de corosync, et encore pas toutes.

Pas moyen de voir notre vote externe dans l’interface de Proxmox VE par exemple. A priori, le support des quorum disk n’est plus assuré non plus depuis la version 4 de PVE.

Ensuite, il faut aussi savoir que pour l’instant, seul l’utilisation d’une IP pour renseigner le quorum serveur est possible. On ne peut pas utiliser un FQDN, ce qui me parait dingue comme limitation en 2019, mais bon…

Ces deux points mis de côté, vous allez voir, ce n’est pas sorcier. La procédure est en bonne partie détaillée dans la documentation.

Prérequis

Pour ce tutoriel, vous allez donc avoir besoin de 2 machines (a minima), déjà en cluster. Si vous ne les avez pas déjà, je vous invite à regarder les moults tutoriels précédents, en particulier celui sur la mise en place d’un cluster Proxmox VE 6 (le plus récent).

Vous allez aussi avoir besoin d’un serveur tiers (un bout de VM ou de container quelque part, en dehors de vos 2 (ou tout autres quantité de machines étant localisées dans 2 endroits distincts dont il existe un risque qu’ils puissent subitement “ne plus se voir”, d’un point de vue réseau, induisant le fameux split brain tant redouté).

Fun fact, il y a une page de wiki pour faire la même chose à la main avec un RPi.

Ce serveur tiers n’a pas besoin de faire fonctionner Proxmox (c’est même plutôt mieux d’ailleurs car PVE n’a aucune plus-value ici). Ça doit juste être une distrib linux capable d’installer un démon corosync qnetd. Ce serveur, nous l’appellerons “quorum”, par abus de langage grossier ;-).

Configuration

Sur le serveur quorum, installer corosync qnetd. Sur une Debian like, vous avez de la chance, il existe un package présent dans les dépôts par défaut, et il faut simplement faire un :

sudo apt install corosync-qnetd

Ensuite, sur tous les serveurs Proxmox VE de notre cluster, on va installer le package corosync-qdevice, qui va leur permettre d’interroger le quorum.

sudo apt install corosync-qdevice

Sur le serveur quorum de nouveau, ajouter la clé SSH d’un des serveurs PVE (un seul suffit). Une fois que c’est fait, connecter le cluster au quorum.

Cela va sans dire, mais faire la commande depuis le serveur dont on vient d’ajouter la clé, pas l’autre hein ;-p. Et remplacez par l’IP du serveur quorum !

pvecm qdevice setup <QDEVICE-IP>
/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/root/.ssh/id_rsa.pub"
The authenticity of host 'x.x.x.x' can't be established.
ECDSA key fingerprint is SHA256:LPaaaaaaaaaaaaaaaaaPZjaIg.
Are you sure you want to continue connecting (yes/no)? yes
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
/usr/bin/ssh-copy-id: WARNING: All keys were skipped because they already exist on the remote system.
(if you think this is a mistake, you may want to use -f option)

Je met volontairement une grosse partie de la trace car comme ça on peut parler de ce que fait la commande pvecm qdevice setup x.x.x.x.

Comme vous pouvez le constater, cette commande semble assez similaire à celle pour créer manuellement le cluster. A savoir, elle commence déjà par copier les clés SSH sur le serveur distant, histoire que tout le monde puisse discuter ensemble en SSH.

INFO: initializing qnetd server
Certificate database (/etc/corosync/qnetd/nssdb) already exists. Delete it to initialize new db
INFO: copying CA cert and initializing on all nodes
node 'pve01': Creating /etc/corosync/qdevice/net/nssdb
password file contains no data
node 'pve01': Creating new key and cert db
node 'pve01': Creating new noise file /etc/corosync/qdevice/net/nssdb/noise.txt
node 'pve01': Importing CA
[...]

Ensuite, on initialise, sur tous les nodes du cluster, le qdevice, qui va permet au node de communiquer avec le quorum. Là j’élude un peu car ça parle beaucoup de certificats et de clés qui sont échangées.

INFO: copy and import pk12 cert to all nodes<br>INFO: add QDevice to cluster configuration
INFO: start and enable corosync qdevice daemon on node 'pve01'...
Synchronizing state of corosync-qdevice.service with SysV service script with /lib/systemd/systemd-sysv-install.

Normalement, si tout se passe bien, vous devriez en arriver là, une fois que tout le monde s’est bien échangé ses certificats, clés et autres joyeusetés crytographiques.

Une petite commande pour vérifier l’état du bazar :

$ pvecm status
Quorum information
------------------
Date: Mon Aug 26 14:49:14 2019
Quorum provider: corosync_votequorum
Nodes: 2
Node ID: 0x00000002
Ring ID: 1/1271796
Quorate: Yes
Votequorum information
----------------------
Expected votes: 3
Highest expected: 3
Total votes: 3
Quorum: 2
Flags: Quorate Qdevice
Membership information
----------------------
Nodeid Votes Qdevice Name
0x00000001 1 A,V,NMW 10.0.0.1
0x00000002 1 A,V,NMW 10.0.0.2 (local)
0x00000000 1 Qdevice

Ça, c’est le genre de choses que j’attends d’un logiciel de clustering digne de ce nom. D’une simple commande, on peut avoir

le nombre de nodes
l’ID du node courant
le nombre de votes actuels, attendus, et minimum pour que le cluster soit “QUORATE”
et enfin l’état de tout le cluster.

Ici, avec 2 nodes + le quorum, on a bien 3 votes. Tant qu’on a 2 votes, on a le quorum, CQFD.

Dans ce cas de figure, si on perd un nœud OU le quorum, on a toujours 2 votes et le cluster doit continuer à fonctionner “normalement”.

Et c’est ce qu’on va vérifier !

On casse un nœud, pour voir

Normalement, si on a pas le serveur quorum, tout devrait être brisé (comme dirait Medieval Ops).

En gros les VMs doivent continuer à tourner, mais toute opération (démarrage de VM, modification quelconque) doit être bloquée (pour éviter de démarrer la même VM à 2 endroits et pleurer pour recoller les morceaux).

Or ici dès que l’hôte n’est plus joignable, le nœud survivant le détecte, et comme le quorum ne voit plus lui non plus qu’un seul nœud, indique au dernier qu’il peut continuer sa vie comme si de rien n’était (c’est glauque…).

$ pvecm status
Quorum information
------------------
Date: Thu Aug 29 11:10:31 2019
Quorum provider: corosync_votequorum
Nodes: 2
Node ID: 0x00000002
Ring ID: 1/1271820
Quorate: Yes
Votequorum information
----------------------
Expected votes: 3
Highest expected: 3
Total votes: 2
Quorum: 2
Flags: Quorate Qdevice
Membership information
----------------------
Nodeid Votes Qdevice Name
0x00000002 1 A,V,NMW 10.0.0.2 (local)
0x00000000 1 Qdevice

Le nombre de vote passe bien à 2 (mais comme on est toujours égal à quorum c’est bon) et le node 1 a bien disparu :

Et la petite déception, pas de visualisation en console du vote du quorum, malgré la mention “Quorate”

Mais bon, c’est quand même cool que ça marche, et en vrai c’est bien l’essentiel ;)

Bonus : Erreur insserv: FATAL: service corosync has to be enabled

Si vous rencontrez l’erreur suivante :

insserv: FATAL: service corosync has to be enabled to use service corosync-qdevice

Allez supprimer le fichier d’init SysV corosync sur tous les hôtes

rm /etc/init.d/corosync-qdevice
systemctl enable corosync-qdevice
systemctl start corosync-qdevice

Source : https://forum.proxmox.com/threads/setting-up-qdevice-fails.56061/

Cluster Proxmox VE, v6 cette fois ci !

Tue, 20 Aug 2019 11:45:00 +0000

Proxmox VE

Et oui, avec la sortie de Proxmox VE 6, je vous avais prévenu : il va y avoir pas mal d’articles là dessus, même si quelques articles sur Kubernetes sont en cours d’écriture aussi ;-).

Fin juillet, j’avais écris un article sur des playbooks Ansible que j’ai écris pour faciliter le déploiement de cluster Proxmox VE. Malheureusement, comme cet article traînait dans mes brouillons, les playbooks ne géraient pas la version 6 (qui venait de sortir) de PVE.

C’est aujourd’hui de l’histoire ancienne puisque, pour tester la v6, j’ai forcément du adapter les playbooks ;-).

Point important, je vais partir du principe que vous n’avez pas la possibilité d’installer Proxmox VE directement avec l’ISO. C’est souvent le cas souvent avec les hébergeurs de serveurs dédiés pas chers (OneProvider par exemple) ou de VMs (OVH, Scaleway, etc).

Car si vous avez la main, le plus simple est bien sûr d’installer l’ISO directement ! Cependant, ce tuto reste utile pour toute la partie mise en VPN et configuration du cluster.

Les prérequis

Dans l’article précédent, pour gagner du temps pour ceux qui veulent juste tester, j’avais mis à disposition un playbook permettant de générer des VMs chez le cloud provider Scaleway (et notamment tirer parti de l’inventaire dynamique proposé par le module développé par Scaleway pour Ansible).

Ici, je met volontairement de côté cette partie qui n’apporterait rien de plus. Si vous voulez voir comment ça fonctionne je vous invite à (re)lire l’article précédent, la procédure est la même.

Le seul prérequis pour ce tutoriel sont donc d’avoir idéalement 3 machines* (ou plus) sous Debian 10 (la raison pour laquelle je n’avais pas pu le faire avec Scaleway qui ne propose pas encore Debian Buster) accessibles en depuis votre station de travail.

*Mais si vous voulez juste installer Proxmox, une seule suffit mais vous n’aurez évidemment pas un cluster. A partir de 2, on peut faire un cluster mais il sera instable dès que vous perdrez une seule des 2 machines (ce qui est dommage) à moins d’ajouter un device pour permettre d’avoir le quorum (ce que nous verrons dans un autre article).

Installer Ansible et récupérer les playbooks

Des fois que n’auriez pas Ansible, installez le (pour git, c’est juste plus simple de cloner le dépôt mais vous pouvez le télécharger autrement si vous ne voulez pas installer git)

apt-get install git ansible
git clone https://github.com/zwindler/ansible-proxmoxve
cd

Ensuite, on créé un fichier d’inventaire pour Ansible (ce qui n’étais pas nécessaire avec Scaleway puisque, je le rappelle, il y a un module d’inventaire dynamique). Ici on se contente juste de lister les serveurs qui nous intéressent.

cat pve_inventory.yml
all:
children:
proxmoxve:
hosts:
proxmox1.myexample.org:
proxmox2.myexample.org:
proxmox3.myexample.org:

Vous ne reconnaissez peut être pas le format de cet inventaire Ansible. En effet, l’inventaire est ici stocké au format YAML et non au format plat. Très peu de gens utilisent ce format (qui existait au début, puis a été retiré pour être de nouveau supporté depuis la 2.4 je crois).

Étant habitué aux inventaires parfois un peu hétéroclites, je préfère largement ce format YAML, qui permet de rajouter de manière beaucoup plus lisibles des variables à des groupes ou mêmes des hôtes directement (sans passer par une arborescence complète avec groups_vars et hosts_vars). De plus, je trouve les dépendances entre groupes plus claires que lorsque nous avions à déclarer les :children du groupe père (mais c’est subjectif).

Notez par contre qu’il faut :

que mes hôtes soient résolvables par DNS (sinon il faut ajouter une variable ansible_host avec l’IP pour chacun)
que vous n’oubliez surtout par le “:” à la fin de chaque hostname, sans quoi vous aurez une erreur de syntaxe.

Lancer le playbook d’installation de Proxmox VE 6

Nous y voilà. Normalement vous pouvez accéder en SSH à l’ensemble de vos machines. Pour installer Proxmox VE 6 sur une debian 10, il faut donc simplement lancer la commande suivante :

ansible-playbook -i pve_inventory.yml proxmox_prerequisites.yml -u root

Normalement, le playbook vous promptera pour répondre à quelques questions basiques (votre domaine, est ce que les machines commencent par test plutôt que proxmox dans le hostname, …) et à l’issue, un reboot sera effectué (pour basculer sur le noyau Linux de PVE et pas celui de debian Buster).

Mise en réseau privé virtuel avec Tinc

Cette étape n’est pas forcément nécessaire. Si vous travaillez sur des machines qui sont dans un même réseau local, il vaut mieux s’en passer.

En revanche, dans le cas où comme moi vous louez des serveurs chez un provider et qu’il ne vous met pas à disposition un moyen de simuler un réseau privé (RPN chez Online, Rack quelque chose chez OVH je crois), il sera préférable de monter un VPN entre les différentes machines du cluster.

Je dis préférable et pas nécessaire, car jusqu’à la version 6 de Proxmox (et Corosync v3), il était nécessaire également de faire passer du multicast entre les machines pour faire fonctionner le cluster. Ce n’est aujourd’hui plus le cas et on peut donc très bien imaginer un cluster Proxmox avec des machines sur des LAN distincts. Cependant, pour activer des fonctionnalités comme Ceph (et probablement d’autre), il est toujours nécessaire d’avoir un LAN.

Pour se faire, j’utilise Tinc plutôt qu’OpenVPN, qui a l’avantage d’être simple à configurer et surtout multipoint (pas de notion de serveur maitre et de clients connectés dessus). Ce n’est pas le cas avec OpenVPN, dont la structure client/serveur complexifie beaucoup l’implémentation si on veut éviter un SPOF (en gros il faut un serveur sur toutes les machines, et que l’ensemble des serveurs soient tous clients les uns des autres, en toile d’araignée). Vous pouvez quand même jeter un oeil sur mes premières tentatives ici, si ça vous intéresse.

Comme j’automatise tout avec Ansible, j’ai donc aussi créé un playbook qui permet d’installer et configurer Tinc sur toutes nos machines et de les mettre en réseau sur un VPN dédié.

ansible-playbook -i pve_inventory.yml tinc_installation.yml -u root

A partir de là, vous avez donc 3 machines Proxmox VE 6, connectés ensembles sur un VPN avec l’adresse 10.10.10.0/24

Le réseau c’est compliqué ?

Un point pas forcément évident avec Proxmox est que la configuration du réseau dépend beaucoup de comment vos machines sont connectées en réseau.

Les différentes configurations conseillées sont détaillées dans un article dédié sur le wiki de Proxmox. J’aurais vraiment aimé connaître cette page lorsque M4vr0x et moi avons fait nos premières expériences avec PVE car nous avons beaucoup tâtonné…

Dans mon cas précis, j’ai des machines hostées par un provider. Je n’ai donc aucunement la main sur le réseau et je ne souhaite pas acheter d’IP supplémentaires.

Dans ce cas là, le plus simple est donc de créer un bridge Linux, qui portera un réseau virtuel interne à chaque serveur et dont le trafic externe sera routé.

L’inconvénient de cette solution est qu’on ne peut pas utiliser l’interface graphique pour faire ces modifications, et aussi qu’en cas d’erreur, vous n’aurez plus accès à votre serveur…

Configuration réseau pour des machines dédiées chez un Provider type OneProvider

Nous voilà donc dans les premières bidouilles manuelles. Connectez vous en SSH à votre (vos) serveurs, et modifier le fichier /etc/network/interfaces.

Je me suis basé sur la section “Masquerading (NAT) with iptables”

Le mien ressemble à ça :

source /etc/network/interfaces.d/*
auto lo
iface lo inet loopback
auto eth0
#real IP address
iface eth0 inet static
address x.x.x.x
netmask 24
gateway x.x x.1
auto vmbr0
iface vmbr0 inet static
address 192.168.0.1
netmask 255.255.255.0
bridge-ports none
bridge-stp off
bridge-fd 0
post-up echo 1 > /proc/sys/net/ipv4/ip_forward
post-up iptables -t nat -A POSTROUTING -s '192.168.0.0/24' -o eth0 -j MASQUERADE
post-down iptables -t nat -D POSTROUTING -s '192.168.0.0/24' -o eth0 -j MASQUERADE

Le plus important ici pour que tout fonctionne est que vous ne vous trompiez pas sur le nom de l’interface réseau (eth0 dans mon exemple).

Ensuite, une fois que les modifications sont faites, redémarrez le réseau (systemctl restart networking) ou carrément le serveur (c’est ce que Proxmox conseille, même si je ne vois pas bien l’intérêt).

Ici, la configuration est beaucoup plus simple que ce que nous avions imaginé avec M4vr0x dans la série d’articles détaillés sur PVE 5. Et c’est tant mieux car ça suffira amplement à la plupart d’entre vous ;-).

Configuration du cluster Proxmox VE

Ok ! Maintenant tous les prérequis sont en place, on peut donc construire le cluster. Le wizard de la GUI a assez peu évolué depuis la V5 (même s’il y a quelques petites améliorations)

Vous vous connectez sur une des machines
Dans la vue Datacenter, vous sélectionnez Create Cluster, puis vous copiez les informations de connexion pour les autres serveurs.
Sur les autres serveurs, vous rejoignez le cluster en collant les informations des

(Plus de détails dans l’article précédent)

Suivez le lapin Orange – Intro et bonnes pratiques d’infra RabbitMQ

Tue, 16 Apr 2019 11:45:07 +0000

C’est quoi RabbitMQ ?

RabbitMQ® est un logiciel open source, développé par Pivotal. Il s’agit d’un message broker (bus/agent de messages), très simple à mettre en place, multiplateforme et multiprotocole (AMQP, MQTT, STOMP).

RabbitMQ est donc particulièrement adapté pour monter rapidement une architecture microservice, voire même IoT, nécessitant un bus de message pour garantir les communications entre les différentes briques de cette architecture.

C’est justement dans mon contexte pro : nous disposons d’une architecture logicielle aux composantes très différentes (microservices, machines outils connectées, …). Nous avons donc besoin de cette agilité, qu’on ne retrouve pas forcément dans les autres messages brokers, mais aussi de garanties et des contrôles sur les transports des messages que nous n’aurions pas forcément avec des API REST.

Architecture et bonnes pratiques

Voici à quoi ressemble l’architecture RabbitMQ que nous utilisons :

A première vue, c’est assez simple. Mais si vous vous demandez si nous n’aurions pas pu faire encore plus simple, alors cet article est fait pour vous ;).

AMQPS / WebMQTTS

Les plus observateurs d’entre vous auront peut être remarqués le « S » à la fin des deux protocoles que nous utilisons pour faire communiquer nos services entre eux :

AMQP / AMQPS
WebMQTT / WebMQTTS

Vous l’aurez sûrement deviné, il s’agit de la déclinaison non-sécurisée/sécurisée (chiffrée) de chacun de ces protocoles.

Par défaut dans RabbitMQ, les échanges ne sont pas chiffrés. Bien qu’il n’y ait pas de réponse universelle à la question « dois-je chiffrer l’ensemble de mes flux ? », l’Ops que je suis ne peux pas s’empêcher de répondre un grand OUI.

C’est particulièrement vrai dans notre cas, où une partie des flux transite par Internet, et l’autre transite à l’intérieur du réseau de notre cloud provider. L’ajout du chiffrement est obligatoire. Le risque d’espionnage, de détournement d’information, de Man in the Middle, sont suffisamment sérieux pour qu’on prenne le temps de configurer un chiffrement TLS.
Cependant, l’impact sur les performances globales de la plateforme est réel et devra être pris en compte lors du choix de l’architecture.

Comment activer le chiffrement TLS sur mes interfaces RabbitMQ ?

Tout se passe dans les fichiers de configuration. Il faudra déposer les fichiers de certificats (CA, certificat public et clé privée) et rajouter les lignes suivantes dans votre configuration :

[
{rabbit, [{ssl_options, [{cacertfile, /path/to/testca/cacert.pem"},
{certfile, /path/to/server_certificate.pem"},
{keyfile, /path/to/server_key.pem"},
{verify, verify_peer},
{fail_if_no_peer_cert, true}]}]}
].

Cependant, là aussi par défaut, il n’y a pas de restrictions sur les protocoles disponibles. Or, les failles sur SSL et TLS 1.0 de ces dernières années nous obligent à désactiver ces protocoles obsolètes (voire même TLS 1.1 aussi), ainsi que tous les ciphers non sécurisés, ce qui va nettement complexifier notre configuration :

%% -*- mode: erlang -*-
[
{ssl, [
{versions, ['tlsv1.2']}
]},
{rabbit, [
{ssl_listeners, [5672]},
{ssl_options, [
{cacertfile, /etc/rabbitmq/certs/cacert.pem"},
{certfile, /etc/rabbitmq/certs/cert.pem"},
{keyfile, /etc/rabbitmq/certs/key.pem"},
{versions, ['tlsv1.2']},
{ciphers, [
{ecdhe_ecdsa,aes_256_gcm,null,sha384},
{ecdhe_rsa,aes_256_gcm,null,sha384},
{ecdhe_ecdsa,aes_256_cbc,sha384,sha384},
{ecdhe_rsa,aes_256_cbc,sha384,sha384},
{ecdh_ecdsa,aes_256_gcm,null,sha384},
{ecdh_rsa,aes_256_gcm,null,sha384},
{ecdh_ecdsa,aes_256_cbc,sha384,sha384},
{ecdh_rsa,aes_256_cbc,sha384,sha384},
{dhe_rsa,aes_256_gcm,null,sha384},
{dhe_dss,aes_256_gcm,null,sha384},
{dhe_rsa,aes_256_cbc,sha256},
{dhe_dss,aes_256_cbc,sha256}
]},
{verify, verify_peer},
{fail_if_no_peer_cert, false}]}
]}
].

A noter, depuis la version 3.7 de RabbitMQ (dernière version en date, la 3.8 sort bientôt), le format de la configuration a changé (erlang => sysctl) pour être plus lisible et plus simple à automatiser. Cependant, à ma connaissance, il n’est pas possible de configurer l’ensemble des limitations de ciphers/protocoles.

« While the new config format is more convenient for humans to edit and machines to generate, it is also relatively limited compared to the classic config format used prior to RabbitMQ 3.7.0. »

Et pourquoi 3 nœuds et pas juste un, au milieu ?

Cette question est volontairement provocatrice ;-p.

Comme tout service informatique, les objectifs en terme d’indisponibilités tendent forcément vers 0. Un moyen classique d’approcher cet objectif est de redonder les composants informatiques, pour éviter tout Single Point of Failure.

Ça tombe très bien, puisque RabbitMQ propose nativement un mécanisme de clustering. Et comme dans tout cluster disposant d’un mécanisme de vote/d’élection, il est fortement conseillé d’avoir un nombre impair de nodes pour résoudre les cas de split brain (la majorité l’emporte en cas de partition réseau). D’où les 3 nœuds (mais on peut en avoir 5, 7, …).

Le clustering dans RabbitMQ, comment ça marche ?

Pour simplifier notre vie, le cluster RabbitMQ agit de telle sorte que tous les objets logiques (utilisateurs, queues, …), où qu’ils soient, sont connus et adressables depuis tous les membres (attention, je n’ai pas dis répliqués, on y reviendra).

Ça, c’est super pratique. Quel que soit le nœud qu’on va contacter, si la queue est présente sur un autre serveur RabbitMQ, le message sera redistribué de manière transparente vers le nœud qui possède la queue.

Pour « masquer » la complexité induite par l’ajout de serveurs RabbitMQ supplémentaires, on a donc juste à ajouter un loadbalancer en amont du cluster. Le développeur envoie simplement le message au loadbalancer. Peu importe le nœud sur lequel le message sera réellement envoyé ensuite, il sera transféré instantanément.

Comment démarrer un cluster ?

Sans rentrer dans le détail de toutes les opérations nécessaires pour bootstrapper un cluster, ce qu’il faut savoir c’est que tous les nœuds doivent évidemment pouvoir se contacter et si possible être relativement proches (en terme de latence).

Les serveurs RabbitMQ doivent être configurés de manière à partager une même passphrase dans le fichier /var/lib/rabbitmq/.erlang.cookie, et on doit ensuite joindre un des noeuds depuis les deux autres avec la commande suivante :

#sur le node rabbit2, puis rabbit3
rabbitmqctl stop_app
rabbitmqctl reset
rabbitmqctl join_cluster rabbit@rabbit1

la documentation qui est très bien écrite.

Maintenant, on est hautement disponibles ?

Vous vous dites : « Chouette ! J’ai un cluster ! Je suis hautement disponible ! »

Et bien… non.

Un point pouvant induire une grande confusion dans RabbitMQ est la terminologie « cluster RabbitMQ ». Le fait de monter un cluster laisse penser que tout devient automatiquement hautement disponible.

Or, en réalité, comme je l’ai écris plus haut, il s’agit uniquement de rendre accessible et addressable l’ensemble des objets logiques depuis tous les nœuds. En revanche, les queues, et a fortiori leur contenu, ne sont physiquement présentes que sur un nœud et un seul.

Ainsi, si un nœud du cluster disparaît, toutes les queues qu’il possède seront détruites (si elles sont Transient), ou bloquées jusqu’à ce que le nœud soit de nouveau disponible (si elles sont Durable).

Dans tous les cas, il y aura interruption de service et éventuellement perte de messages, malgré le fait qu’on ait un cluster !

Haute disponibilité des queues

Heureusement, il est également possible de répliquer les queues et leur contenu sur une partie ou la totalité des nœuds disponibles dans le cluster. On dispose alors d’une queue principale et de miroirs qui pourront prendre le relai en cas de défaillance d’un nœud.

Ceci est configurable, par queue ou par policy (applicable à toutes les queues correspondant au pattern), avec les options ha-mode, ha-params et ha-sync-mode.

ha-mode
- all : synchronisera votre queue sur des miroirs présents sur tous les nœuds du cluster
- exactly : permettra d’indiquer, en positionnant également un nombre sur ha-params, le nombre exact de nœuds sur lesquels les queues sont répliquées
- nodes : synchronisera des miroirs sur une liste de nœuds explicitement nommés
ha-sync-mode
- automatic : en cas d’apparition d’un nouveau miroir, tous les messages sont synchronisés immédiatement
- manual : en cas d’ajout d’un nouveau miroir, seul les nouveaux messages sont synchronisés

Attention au mode automatic, surtout en conjugaison avec le ha-mode à all. En effet, si ce mode est plus sécurisé puisqu’il garantie que tous les nœuds ont bien la totalité des messages, il a aussi l’inconvénient de bloquer les queues « à synchroniser » (tant que l’ensemble des messages ne sont pas répliqués partout).
Dernier point d’attention, au même titre que le chiffrement, l’ajout de la haute disponibilité (et du clustering, dans une moindre mesure) a un impact sur les performances globales de la plateforme.

Conclusion

RabbitMQ est un outil puissant et extrêmement simple à mettre en place. On peut le lancer et obtenir un broker de message robuste avec une simple commande « docker run ».

docker run -d --hostname my-rabbit --name some-rabbit rabbitmq:3

Pour autant, dans un environnement de production avec des objectifs en terme de haute disponibilité, il n’est pas si trivial de trouver les bons paramètres. Certains nécessiteront un peu de recherche et de configuration erlang, d’autres nécessiteront un peu de benchmarking et de tuning, si les performances commencent à devenir un problème.

Pour cette seconde catégorie, j’y reviendrai dans un autre article. Cependant, sachez quand même qu’on peut traiter sans trop de difficulté des milliers de messages par secondes, même avec des machines disposant de peu de CPU. Vous aurez surement le temps de voir venir ;).