Bien que je dispose d’un serveur dédié loué chez un fournisseur de service ayant pignon sur rue, j’ai tout de même bien souvent eu un serveur à la maison, la plupart du temps un vieil ordinateur que je préfère réutiliser plutôt que de jeter. C’est ainsi que jusqu’à très récemment j’hébergeai certains de mes services sur un laptop qui m’a été donné par mon employeur de l’époque car à la fois d’un modèle trop ancien et dont une touche du clavier était cassée. Cependant, même les meilleurs choses ayant une fin, un ami m’a récemment fait découvrir l’univers des racks 10" et j’ai finalement succombé à la tentation d’acheter neuf.
Le matériel #
Je trouve l’univers des racks 10" est absolument merveilleux car il reprend les caractéristiques d’un centre de données professionnel mais dans un espace extrêmement réduit. C’est donc du matériel particulièrement adapté à un usage personnel et/ou mobile. Mon choix s’est orienté vers une référence en la matière, le DeskPi RackMate T0. Avec ses 4U, il est très compact mais permet tout de même d’y stocker tout le nécessaire pour un homelab respectable.
Au niveau des serveurs, à la base j’ai pensé utiliser des Raspberry Pi comme
beaucoup d’autres l’ont fait avant moi. Cependant, dans la mesure où j’avais
très envie de m’essayer à XCP-ng, j’ai finalement décidé de rester sur une
architecture x86_64 et ai donc opté pour deux mini-pc, en l’occurrence des
GMKtec NucBox G5 dotés du processeur Intel N97.
Partant de cette base, il suffit d’ajouter quelques accessoires et on obtient quelque chose de très correct. Mon ajout principal aura été au niveau de l’alimentation électrique en installant une PDU spéciale pour rack 10" ainsi qu’une alimentation USB-C suffisamment puissante pour supporter les deux serveurs.
Au final j’ai donc, de haut en bas :
- Cache (face avant) + PDU (face arrière) ;
- 2 × NucBox G5 ;
- Convertisseur optique ONU (sur l’avant) + alimentation USB-C (sur l’arrière) ;
- Freebox.
Oui, je sais, c’est encore un peu le fouillis et tout n’est pas parfaitement calé comme il le faudrait. J’envisage dans l’avenir d’imprimer en 3D de jolis éléments de fixation, mais pour l’instant je n’ai pas le matériel nécessaire.
Virtualiser avec XCP-ng #
L’objectif est d’utiliser une machine virtuelle différente pour chaque service. Afin de me simplifier la tâche, j’ai donc décidé d’utiliser XCP-ng. Si vous ne connaissez pas, il s’agit d’une distribution Linux construite autour de l’hyperviseur Xen.
Compte tenu de sa nature (il s’agit d’un hyperviseur de type 1)
l’administration est assez particulière. En effet, si vous y branchez un écran
et un clavier, vous ne serez pas accueilli par un écran de connexion mais par
un logiciel doté d’une TUI, xsconsole, qui est surtout destiné aux opérations
basiques de secours. S’il est possible d’obtenir un shell, soit depuis
xsconsole soit en se connectant directement en SSH, ce n’est clairement pas
le mode d’administration privilégié. À la place, dans XCP-ng on doit définir
une interface réseau qui sera utilisée par une API d’administration. Pour des
évidentes raisons de sécurité, on évitera d’exposer cette interface sur
internet.
Il existe plusieurs moyens d’utiliser l’API d’administration d’XCP-ng. Le plus populaire est d’utiliser Xen Orchestra (XO), une application web dédiée à cette tache. Cette application peut s’installer un peu n’importe où et gérer plusieurs serveurs XCP-ng. Pour ma part j’ai choisi d’utiliser VirtualBox afin de me faire une VM dédiée à XO sur mon laptop en utilisant un script d’installation et de mise à jour.
Il est à noter qu’afin de financer le développement d’XCP-ng et de son environnement, Vates vend des licences Xen Orchestra Appliance (XOA) qui est un XO pré-installé et disposant de prestations de support. Donc à moins que vous n’ayez les moyens financiers d’une entreprise, vous voulez utiliser XO et non XOA.
Enfin, Vates est en train de développer XO Lite, une version simplifiée d’XO qui est directement intégrée à XCP-ng. L’objectif est qu’XCP-ng dispose nativement d’une interface d’administration du serveur lui-même, ce qui simplifiera la vie des particuliers l’utilisant pour un homelab. Cependant, à l’heure où j’écris ce billet, XO Lite est très nouveau et la quasi-totalité des boutons ne sont pas encore fonctionnels. Le seul qui fonctionne vraiment est celui permettant d’installer XOA dans une VM, mais du coup c’est surtout destiné aux entreprises.
Alpine Linux pour les systèmes virtualisés #
Ce n’est pas parce que l’on peut installer à peu près n’importe quel OS sur une VM qu’il faut mettre le premier qui nous tombe sous la main. Bien souvent on opte pour la solution de facilité qui est d’installer un OS générique que l’on connaît déjà, par exemple Debian ou Ubuntu. Après tout, le raisonnement se tient car on est alors dans un environnement familier et donc à la fois opérationnel et rassurant. C’est donc objectivement un bon choix.
Cependant, je vous en propose un autre : Alpine Linux. Mon raisonnement ici est qu’un OS générique intègre pas mal d’outils de base, ce qui le rend à la fois relativement lourd et augmente la surface d’attaque. À l’inverse, Alpine Linux est extrêmement léger et n’intègre que le strict minimum, ce qui réduit la surface d’attaque, le rend extrêmement rapide et surtout simple à utiliser. Sincèrement, essayez cette distribution, elle en vaut vraiment le coup.
D’ailleurs, déployons ensemble une VM sur XCP-ng. Pour commencer, l’image d' Alpine Linux que je vous recommande de prendre est la variante « virtual ». Depuis XO, après avoir importé l’image dans un stockage, nous pouvons ajouter une nouvelle VM. Sélectionnons « Generic Linux UEFI » et mettons plus petit montant de RAM autorisé, donc 1 Go.
Une fois la VM créée, on se rend dans sa console afin de se connecter en tant
que root (il n’y a pas de mot de passe) et de lancer l’installation à l’aide de
la commande setup-alpine. Je ne vous fais pas l’affront de vous expliquer
comment répondre aux question de l’installateur, mais sachez juste que
lorsqu’on vous demande comment vous voulez utiliser le disque, il est
préférable de choisir sys afin d’installer l’OS sur le disque.
Pour ma part, je préfère laisser le réseau être automatiquement configuré via
DHCP puis, une fois l’OS installé, m’y connecter en SSH afin de finaliser la
configuration. Une des premières choses que je configure est donc le
réseau afin d’ajouter des adresses IP fixes. Éditons donc
le fichier /etc/network/interfaces :
auto lo
iface lo inet loopback
auto eth0
iface eth0 inet static
address 203.0.113.42
gateway 203.0.113.1
iface eth0 inet6 static
address 2001:db8::42
Une fois la configuration réseau modifiée, relançons le service correspondant afin de prendre ces modifications en compte :
rc-service networking restart
Maintenant, dé-commentons le dépôt community et rafraîchissons la liste des paquets :
sed -i 's/#http/http/' /etc/apk/repositories
apk update
À présent nous pouvons installer les utilitaires invité Xen Server, les lancer et les activer au démarrage de la machine :
apk add xe-guest-utilities
rc-service xe-guest-utilities start
rc-update add xe-guest-utilities
Et voilà, nous avons une VM fonctionnelle. C’est on ne peut plus simple et je
suis certain que vous avez déjà pris vos marques sur Alpine Linux. Pour gérer
les paquets, lancez donc apk -h pour voir le détail des commandes. Spoiler
alert, pour la mise à jour utilisez apk update et apk upgrade, pour
l’installation et la désinstallation c’est apk <add|del> <nom_du_paquet>.
Niveau gestion des services, regardez du côté de rc-status pour connaître
tout ce qui tourne, utilisez rc-service <nom_du_service> <start|restart|stop>
pour lancer/relancer/stopper un service et rc-update <add|del> <nom_du_service> pour ajouter ou supprimer un service du lancement automatique
au démarrage du système. Compte tenu de ce qu’il est prévu de faire avec les
VM, vous devriez maintenant être en mesure de les administrer correctement.
Provisionner de la mémoire #
Chez moi, une VM Alpine Linux de base consomme dans les 240 Mo de RAM. Avec les utilitaires Xen Server on monte à 380 Mo. Une VM destinée à faire tourner un service peu groumant ne devrait donc pas nécessiter plus de 512 Mo de RAM, mais malheureusement XCP-ng ne nous laisse pas mettre moins de 1 Go. C’est le seul point gênant que j’ai trouvé à XCP-ng car une telle limitation va négativement impacter le nombre de VM que l’on va pouvoir faire tourner sur un même serveur.
Ceci dit, dans XO rendons-nous dans l’onglet « avancé » de la VM et descendons jusqu’à l’option de gestion de la mémoire. On y trouve deux types de limites : statiques et dynamiques.
Les limites statiques indiquent tout simplement les valeurs minimales et maximales de RAM qu’il est possible de définir pour la VM. Toute modification de ces valeurs demandera un redémarrage. Notez que modifier manuellement la RAM (ou définir les limites dynamiques) en dehors de ces valeurs va automatiquement ajuster les limites statiques et donc demander un redémarrage de la VM.
Les limites dynamiques sont celles dans lesquelles l’hyperviseur est libre de lui-même ajuster la RAM. Si par défaut les VM tournent avec le maximum de RAM possible, des modifications automatiques peuvent notamment intervenir s’il n’y a pas assez de mémoire sur l’hôte afin de faire tourner toutes les VM au max. Notez également que lorsqu’une VM est transférée d’un hôte vers un autre, sa RAM est d’abord réduite au minimum puis, une fois le transfert effectué, elle est si possible augmentée à nouveau. Assurez-vous donc que vos VM puissent toujours fonctionner avec le niveau de RAM minimum.
Ce n’est qu’un début #
Ce nouveau homelab m’a beaucoup motivé à tester de nouvelles choses. Je terminerai donc ce billet en promettant simplement d’écrire sur divers expérimentations que je compte lancer dessus.