Dans ce billet de blog, nous allons aborder la contrainte numéro 1 dans mon HomeLab : la consommation énergétique. Pour la petite histoire, j’ai eu beaucoup de fournisseurs avant de créer mon HomeLab : OneProvider, Kimsufi, Dyjix, Dedimax, Scaleway, Pulseheberge et le dernier en date Hetzner. Hors, depuis quelques temps, nous vivons une période trouble qui impact directement les entreprises que j’ai mentionnées précédement. Pour vous donner un ordre d’idée, avant la crise des semi-conduteurs, la guerre en Ukraine et la hausse des tarifs de l’énergie, je louais mon serveur 27€. A l’heure où j’écris ces lignes, celui-ci est en location chez Hetzner pour 37€ et rien ne garanti que le prix ne continuera pas d’augmenter.

Donc vous l’aurez compris, l’une des premières motivations était l’aspect financier. Mais il est aussi important de mentionner la conscience écologique et tous les avantages du HomeLabing (créer son HomeLab) comparé à l’hébergement externe. En voici quelques-uns importants selon moi :

Le reconditionnement d’ordinateur portable

Une solution astucieuse consiste à reconditionner des ordinateurs portables pour bénéficier de leurs performances énergétiques remarquables. Contrairement aux serveurs traditionnels, les ordinateurs portables sont conçus pour être économes en énergie, offrant ainsi une option viable et écologique.

Le reconditionnement ne signifie pas seulement réutiliser un ancien appareil, mais optimiser son utilisation pour des tâches spécifiques. Dans un HomeLab, cela peut impliquer la configuration d’un ordinateur portable pour agir comme un serveur léger, un dispositif de stockage en réseau (NAS) ou même un hôte pour des applications spécifiques. Cette approche n’est pas seulement économique, mais elle contribue également à réduire l’empreinte carbone en prolongeant la durée de vie des appareils existants.

Les C States dans les CPU : Optimisation du Repos

… , il est essentiel de se pencher sur les “C states” des processeurs. Les C states sont des états de repos que le CPU peut adopter pour économiser de l’énergie. Quand un processeur n’est pas en charge complète, il peut passer à un état C (comme C1, C2, etc.), chacun offrant un niveau d’économie d’énergie croissant.

En pratique, ces états permettent au CPU de réduire sa consommation d’énergie lorsqu’il n’est pas nécessaire de fonctionner à pleine capacité. Cela est particulièrement utile dans les configurations de homelab, où les charges de travail peuvent varier et ne nécessitent pas toujours la puissance maximale du processeur.

Malheureusement, les C states ne sont pas présents sur toutes les marques de CPU et sur toutes les générations. J’ai donc décidé de ne pas approfondir cette solution car elle aurait limité mon principe de reconditionnement des ordinateurs portables. Si vous souhaitez approfondir, je vous recommande la chaine youtube @WolfgangsChannel et notemment la vidéo suivante :

Pour aller plus loin, vous pouvez consulter la documentation de intel sur la gestion de l’alimentation : Package C-States - 12th Generation Intel® Core™ Processors Datasheet

Le WoL à la rescousse

Jusque là, nous avons vu que mon HomeLab permet d’économiser la hausse du prix de l’éléctricité professionel et d’utiliser le bouclier tarifaire accordé aux particuliers. De plus, une électricité non carbonée car principalement produite par le nucléaire en France. Nous avons aussi vu que l’utilisation d’ordinateurs portables permet de tirer le maximum (ou le minimum dans notre cas) de leurs CPU à faible consommation tout en offrant une seconde vie.

Mais malheureusement, les C states ne sont pas une technologie accessible dans notre cas. Ce qui laisse nos serveurs constament allumés alors qu’ils ne sont peut être pas utilisés. Et c’est là que j’ai la reflexion suivante : pourquoi ne pas juste les éteindre lorsqu’ils sont inutilisés ?

Et c’est bien là le point de départ de tout ce projet. L’idée est très simple : les services que j’hébèrge sont répartis sur différentes couches suivant leurs besoin de disponibilité.

Le Niveau 1 (T1) regroupe toutes les applications qui doivent être constament en fonctionnement. On y retrouve dedans la domotique avec HomeAssistant, les endpoints de CloudFlare Tunel ou encore les reverse proxy avec Caddy. Tous les éléments qui sont ainsi indispensable au fonctionnement du HomeLab ou qui ne peuvent se permettre quelques secondes de délais (exemple : les lampes en domotique). On utilisera donc de préférence un CPU avec une faible consommation (cf. partie sur le reconditionnement d’ordinateurs portables) voir ARM si possible (exemple : raspberry pi).

Le Niveau 2 (T2) est semblable à T1 avec la particularité de ne pas posséder d’alimentation de secour. En effet, celui-ci ne possède pas d’UPS (Uninterruptible power supply) qui prend le relais en cas de coupure de courant. Par exemple, mon cloud de fichiers (Owncloud) est un service intensement utilisé qui serait contre productif de placer en veille. Le service ne ferait que s’éteindre et s’allumer constament, consommant au passage plus d’énergie. Le T2 se justifie ici par une absence de besoin de résiliance. En cas de panne de courant ou d’une coupure volontaire, il n’est pas nécessaire pour moi de garder ce service allumé, je peux m’en passer quelques heures sans problème.

Et enfin le Niveau 3 (T3) correspondant à tous les autres services qui peuvent être mis en veille tant qu’ils ne sont pas utilisés. On y retrouve par exemple Jellyfin stockant ma médiatèque et qui ne necessite pas une disponibilité constante (souvent utilisé le soir et le week-end).

Vous pouvez retrouver ci-dessous une représentation schématique de mon architecture ainsi que les différentes couches de disponibilité :

Mais à ce point, vous pouvez légitimement vous demander : “Si le serveur est en veille, comment fait-on pour l’allumer lorsque nous avons besoin des ses services ?”

Pour celà, je vous présente le WoL : Wake on LAN qui permet depuis les années 1995 d’envoyer un “Magic Packet” afin de réveiller un serveur et lui demander de s’allumer. La carte réseau reçoit ainsi une trame spécifique qui déclanche l’allumage de tous les autres composants.

La mise en place de ce WoL est plutôt simple. Dans un premier temps, vous devez vérifier que votre serveur est compatible puis activer cette fonctionnalité dans le BIOS. Vous devez ensuite indiquer à votre distribution d’activer cette fonctionnalité. Vous trouverez ici un tuto pour Ubuntu 20 mais vous trouverez surement des alternatives si vous utilisez une autre distribution. Nous avons maintenant un serveur en capacité de s’allumer à la récéption de ce Magic Packet. Nous allons donc maintenant passer à la configuration du serveur qui va être en charge d’envoyer le Magic Packet.

Vous l’aurez compris avec le schéma présenté ci-dessus, c’est le serveur de niveau 1 qui va être en charge d’allumer le serveur de niveau 3 lors de l’arrivée d’une requête. Vous pouvez retrouver ci-dessous un exemple de configuration de Caddy pour envoyer un Magic Packet lors de la récéption d’une requête sur le domaine netflix.com :

{
  order wake_on_lan before respond
}

netflix.com {
      reverse_proxy 192.168.0.100:8096
      handle_errors {
              @502 expression {err.status_code} == 502
              handle @502 {
                      wake_on_lan 00:11:22:33:44:55
                      reverse_proxy 192.168.0.100:8096 {
                              lb_try_duration 120s
                      }
              }
      }
}

Dusk pour éteindre le serveur

Maintenant que nous avons réussi à allumer notre serveur, il est temps de s’occuper de l’éteindre. Pour celà, j’ai développé Dusk, un outil open-source Rust qui permet d’éteindre un serveur à la suite d’une periode d’inactivité.

Dusk est un outil qui s’installe sur le serveur que vous souhaitez éteindre. Il va surveiller l’activité du serveur selon différents critères (CPU & réseau) et éteindre le serveur si les valeurs d’idle sont atteintes pendant une période prolongée. Comme vous avez pu le faire pour le WoL, vous devez créer un service systemd pour lancer Dusk au démarrage de votre serveur.

Avec Dusk maintenant installé celui-ci va s’éteindre automatiquement lorsqu’il n’est plus utilisé et vous faire économiser de l’énergie.

Conclusion

Nous avons vu dans cet article comment mettre en place un système de veille pour nos serveurs. Nous avons vu comment utiliser le WoL pour allumer un serveur et comment utiliser Dusk pour l’éteindre. Nous avons également vu comment configurer Caddy pour envoyer un Magic Packet lors de la récéption d’une requête. Dans un projet article, nous ferrons une étude des économies d’énergie réalisées grâce à ce système de veille.