Mise à jour du lab

Introduction et design Link to heading

Contrairement à ce que je souhaitais, je n’ai pas écrit ici depuis longtemps. Le temps passe vite lorsqu’on est absorbé par la vie de famille et l’une des tâches que j’ai mis en suspens pendant longtemps est la mise à jour de mon homelab. Mon lab était précédemment composé d’un cluster de machines arm64 : des Odroid C2 et MC1 pour le compute et des Odroid HC1 pour le stockage. Les C2 et MC1 étaient trop limités en ressources, que ce soit CPU et mémoire, ce qui m’a poussé à acheter quelques machines plus puissantes et à virtualiser.

Je me suis donc d’abord retrouvé avec un Minisforum MS-01 qui me servait à tout : aussi bien comme routeur internet que comme hyperviseur grâce à libvirt sur lequel il était installé. J’ai souhaité ensuite m’assurer que les données et les services que j’hébergeais étaient correctement répliqués et sauvegardés et j’ai finalement acquis deux autres MS-01 avec exactement la même configuration dans l’optique de faire un cluster avec libvirt et un stockage partagé. Ne souhaitant pas acheter de nouveau matériel pour le stockage, j’ai décidé d’ajouter dans mon infra un cluster CEPH composé de ces trois MS-01.

Pour m’enfoncer un peu plus dans l’over engineering, j’ai aussi acheté deux routeurs managés MikroTik CRS305-1G-4S+. Ceux-ci seront chacun connectés à un port SFP+ de chaque nœud. L’un de ces routeurs sera dédié aux connexions du cluster CEPH tandis que l’autre permettra la connexion de tous les réseaux virtuels que je créerai. Afin de parfaire l’isolation de ces réseaux, ceux-ci seront tagués et un opnsense virtualisé, connecté à chacun des réseaux virtuels ainsi qu’à mon LAN aura le rôle de routeur et de firewall.

Comme un schéma vaut mieux que de longues explications :

J’utiliserai assez librement dans mes posts le terme de SAN qu’on retrouve par exemple dans le nom que j’ai donné au routeur mikro-san même si je sais que techniquement ça ne l’est pas : j’ai peut-être un réseau dédié et du RBD mais ça reste du RBD over TCP/IP et pas de l’iSCSI ou du FC. Mon but ici est d’utiliser ce stockage pour héberger les disques des VM du cluster ainsi que pour exposer du block device au cluster kubernetes qui sera lui aussi virtualisé.

Contenu virtualisé Link to heading

Mon lab contient déjà quelques machines virtuelles qu’il me faudra à terme migrer. Ce sont à quelques exceptions près des machines me permettant de terminer des connexions VPN avec d’autres réseaux (entreprises, associations, etc.).

Je souhaite y ajouter :

• Une forge logicielle, forgejo, pour remplacer gitolite que j’utilisais avant ;
• Du stockage façon buckets s3, peut-être avec garage ;
• Un stockage de secrets avec vault ou openbao ;
• Un serveur de bases de données postgres ;
• Un cluster kubernetes ;
• Un système de backup (soit par VM, soit par service).

Ces différents services ne seront pas tous hébergés dans kubernetes afin de satisfaire le paradoxe de l’œuf et de la poule. Par exemple, je souhaite installer des services dans mon cluster via l’outil GitOps fluxcd. Celui-ci doit utiliser comme référence un ou plusieurs dépôts git ce qui fait que forgejo sera installé préalablement sur une VM.

Topologie réseau Link to heading

Je considererai dans les prochains articles qui traiteront de ce lab que tous les réseaux créés dans le contexte de ce dernier seront taillés dans 10.43.0.0/16.

Documentation Link to heading

Ces articles, encore une fois, me serviront autant de documentations que d’exercices de rédaction.