Ce que j’avais en tête avant de commencer !

Photo par Manuel Geissinger , publiée sur Pexels

Travaillant à mon compte, j’utilise depuis quelques années la solution ouverte Dolibarr pour la gestion des devis, commandes clients, factures…

J’ai commencé par héberger ce logiciel sur un petit NAS Synology à la maison. Dolibarr était utilisable sur cette plateforme, mais avec des temps de réponses exécrables. Les temps de réponse se sont aggravés quand j’ai activé la gestion des calendriers et des contacts sur ce NAS, en remplacement des services du géant américain.

Et est arrivé le premier confinement. J’ai mis à profit ces nouveaux temps libres pour regarder si je ne pouvais pas mettre en place une infrastructure d’hébergement plus adaptée et surtout qui puisse être utilisée pour tester et héberger d’autres services.

C’est une aventure qui m’a amené à découvrir Ansible, Docker et sa solution de clustering Swarm, Traefik… et pleins d’autres outils.

J’ai envie de vous partager tout cela au travers d’une série d’articles, en commençant par ce premier article qui expliquera de manière macro les choix pris et l’architecture définitive.

Le matériel

Pour cet hébergement à la maison, je me suis demandé si un micro-serveur ou un groupe de nano-ordinateurs pouvaient faire l’affaire. J’ai même hésité à utilisé un « vrai » serveur .

Mais j’ai vite été ramené à la réalité par le bruit et consommation annoncés des serveurs, versus les nano-ordinateurs. J’ai donc décidé de partir sur une infrastructure basée sur de petits éléments. Raspberry Pi m’a paru être un bon choix et comme j’en avais déjà un : GO !

Je dispose dans le sous-sol d’un petit rack mural dans lequel arrivent les câbles des prises RJ45 présentes dans les différentes pièces de la maison. Ces câbles sont connectés sur un petit hub, lui-même relié à la boîte du fournisseur Internet.

C’est un emplacement idéal pour y héberger cette petite infrastructure d’hébergement.

Je ne vous ferais pas l’affront de vous détailler les recherches et comparatifs de caractéristiques et de prix.

Je souhaitais pourvoir alimenter électriquement les Raspberry Pi au travers de leur interface réseau, (via PoE ) pour éviter la multiplication des câbles.

Voici au final, la liste des matériels qui compose donc cette infrastructure :

• 1 x switch POE DIGITUS Switch - Gigabit - 8 ports - PoE+ Noir
• 3 x Raspberry Pi 4 Modèle B - 2GB
• 1 x Raspberry Pi 4 Modèle B - 4GB
• 4 x Raspberry Pi PoE HAT
• 4 x SD Cards Samsung MB-MC32GA/EU Carte mémoire MicroSD Evo Plus 32G
• 6 x câbles RJ45 Cat 6a 25cm
• 1 x Boitier pour Cluster Raspberry Pi

Tout ce beau monde a été placé dans cette petite armoire murale de 6U. Et voilà le résultat !

Un cluster

L’idée de départ pour cette infrastructure d’hébergement était de disposer d’un cluster de serveurs, sur lesquels tournent des containers d’applications, base de données…

Sur le papier, ces containers devaient pouvoir basculer d’un nœud à l’autre suivant le besoin (défaut d’un nœud, besoin de plus de ressources…), mais je me suis heurté aux limites des Pi.

Pour que les containers puissent basculer d’un nœud à l’autre, il faut que les ressources de ces containers soient disponibles sur tous les nœuds. Ces ressources qui doivent être partagées sont le réseau et les données.

le réseau

Pour le réseau, la solution de cluster de Docker, Swarm , fait très bien le travail et fait en sorte qu’un réseau déclaré comme faisant partie du cluster est disponible sur l’ensemble des nœuds de ce cluster.

le stockage

Pour les données, c’est beaucoup plus délicat. Dans le monde Docker pour que les données d’un container survivent à l’arrêt et relance du container, il faut qu’un volume soit associé au container. Il y avait dans mon cas, plusieurs possibilités techniques :

1. utiliser un stockage externe aux nœuds du cluster
2. répliquer un espace de stockage entre les nœuds du cluster

J’ai testé la première solution en configurant un partage NFS sur le NAS Synology et en montant ce partage sur chacun des nœuds. J’ai dû renoncer cette solution pour 2 raisons :

• les temps de réponses étaient trop longs.
• dans une période d’inactivité, le NAS se met en sommeil, du coup quand un container essaye d’accéder à son volume (en lecture ou en écriture), il doit attendre que celui-ci s réveille, et cela génère des erreurs applicatives.

Pour la deuxième solution, j’ai me suis orienté vers Gluster , solution open-source pour des systèmes de fichier distribués. Pour faire simple cet outil permet de créer un espace de stockage commun à plusieurs serveurs à partir du stockage de ces mêmes serveurs. C’est la solution idéale pour avoir un espace commun à plusieurs nœuds d’un cluster. Chaque nœud présente à Gluster une partie de son stockage, et Gluster se charge d’en faire un seul stockage sur lequel est présent l’ensemble des données écrites par chacun des nœuds du cluster.

J’ai testé cette solution avec succès sur des VM avec Vagrant.. Par contre lors de la mise en pratique sur les Raspberry Pi, le succès a été beaucoup plus mitigé, en effet, les Raspberry Pi restent des nano-ordinateurs dont les ressources CPU ne sont pas faites pour les lourdes charges. Pourtant les recommandations de Gluster en termes des ressources pour un serveur physique ne sont pas énormes :2 CPUs, 2GB of RAM, 1GBE. Mais une fois installés sur les Pi, les volumes Gluster ont commencé à se désynchroniser les uns des autres. À tel point que j’ai dû renoncer à son utilisation, et par la même occasion à disposer d’une garantie de redondance en cas de défaillance d’un nœud du cluster.

J’ai donc décidé de fixer l’emplacement des containers en les répartissant sur l’ensemble des nœuds.

la sauvegarde

Comme les données de chaque container est maintenu présent que sur le nœud qui héberge le container, j’ai mis en place de la sauvegarde pour avoir des copies des données (et pouvoir les restaurer en cas de besoin), et j’ai « externalisé » ces sauvegardes hors des Pi, et de chez moi.

Pour faire simple, chaque nuit, les données de chaque application sont rassemblés au sein d’une archive par application. Ces archives portent le nom de l’application concernée, son niveau de version et la date et heure de création de l’archive.

Plus tard dans la nuit, le NAS Synology se connecte sur chacun des PI et récupère les archives générées. Une partie des données présentes sur le NAS Synology, dont ces sauvegardes) est copiée vers un stockage dédié, loué chez un hébergeur, une fois par semaine.

Le dernier travail de la nuit est fait par les Pi qui suppriment les sauvegardes aillant une ancienneté supérieure à la rétention fixée. Suivant les applications, je garde entre 3 et 5 jours de sauvegardes sur le Pi. Cette différence a été mise en place pour avoir un espace de stockage utilisé toujours inférieur à 70 % sur chaque Pi.

la supervision

La supervision de ce type d’infrastructure devrait faire séparer de ladite infrastructure, afin d’assurer une indépendance et une détection des incidents.

Mais comme je suis le seul utilisateur et que je ne voulais pas trop augmenter les coûts, j’ai pris le parti d’héberger l’infrastructure de supervision sur le cluster. bah oui

J’ai mis en place le couple très souvent utilisé Prometheus/Grafana. Prometheus me permet de collecter des informations sur les Raspberry Pi et sur les containers, et de m’alerter en cas de défaillance; et Grafana m’offre une visualisation de ces métriques.

Sur chaque Pi, est installé et configuré <code>node_exporter</code> et cAdvisor .. node_exporter récupère et expose les métriques des Pi (matériel et O/S), tandis que cAdvisor s’occupe des métriques Docker.

Pour être honnête je n’ai pas encore eu à fouiller ces métriques pour identifier la source d’un souci. Les incidents rencontrés sur ce cluster ont toujours été très francs : UP ou DOWN !

les noms de serveurs

Et arriver une étape essentielle et ô combien critique, le choix de noms pour ces serveurs. J’ai dû passer 2 bonnes semaines à chercher, choisir, changer, rechercher, choisir… Pour finalement arrêter mon choix sur Jupiter et ces satellites , pour nommer les serveurs qui composeront l’infrastructure d’hébergement.

Image provenant de Wikipedia.org

Jupiter sera le serveur central hébergeant les services d’infrastructures et ces satellites hébergeront les services applicatifs.

Pour ma station de travail, j’ai choisi de la nommer Terre, tout simplement.

Conclusion

J’espère que cet article vous a plus. Mon idée initiale était de ne pas rentrer trop dans les détails techniques mais de vous proposer une vision macro de que j’ai mis en place. Dans les prochaines semaines je rentrais plus en détails sur des parties spécifiques comme la sauvegarde et la supervision. Puis je commencerais à détailler les services qui tournent sur ce cluster.

N’hésitez pas à me faire des retours !