Dormir au repos, se réveiller à la demande : la recette énergie

Une tour avec deux grosses cartes graphiques consomme bien plus qu'un petit serveur, même au repos. La nôtre dort dès que personne n'en a besoin. Une petite machine allumée de toute façon (le nœud Proxmox du Homelab 1) la réveille à la demande, et la commande de réveil ne rend la main que lorsque la tour est vraiment prête à travailler.

Un peu d'histoire

Le Wake-on-LAN remonte au milieu des années 1990 : le « Magic Packet » d'AMD est une trame réseau qui porte seize fois l'adresse matérielle de la cible. Une carte réseau endormie continue de l'écouter et allume l'ordinateur. Trente ans plus tard, le même paquet permet à un serveur maison de dormir l'essentiel de la journée et de se réveiller dès que vous en avez besoin.

1. Autoriser le réveil

1. Dans le firmware (BIOS) : activez Wake on LAN (parfois Power On By PCI-E), et désactivez les modes d'économie profonds comme ErP, qui coupent l'alimentation de la carte réseau.
2. Utilisez la carte réseau filaire : le Wake on LAN ne fonctionne pas en Wi-Fi sur du matériel ordinaire.
3. Vérifiez, puis rendez-le permanent avec NetworkManager :

   sudo ethtool <interface> | grep Wake-on      # « g » = paquet magique
   nmcli connection modify <connexion> 802-3-ethernet.wake-on-lan magic

4. Notez l'adresse matérielle (MAC) de la carte : ip link show <interface>. Gardez-la dans vos notes, pas dans un fichier public.

2. Envoyer le paquet magique de l'intérieur

Le paquet magique est une diffusion sur le réseau local : il doit partir d'une machine du même réseau. Utilisez la petite machine toujours allumée :

wakeonlan <adresse MAC>    # ou : etherwake, ou un tableau de bord web comme UpSnap

De l'extérieur, rejoignez cette petite machine par votre réseau privé (Tailscale, WireGuard), puis envoyez le paquet de là.

Ne redirigez jamais le Wake on LAN depuis Internet par votre box : n'importe qui pourrait allumer votre machine, et vous n'y gagnez rien face à un réseau privé.

3. « Réveillée » n'est pas « prête »

Une machine qui répond au ping peut encore être en train de démarrer ses services. Notre commande de réveil attend deux vraies réponses avant de rendre la main : une connexion SSH, puis le test de santé de la passerelle des modèles. Alors seulement les agents ont le feu vert. Trois minutes sans réponse, c'est un échec, signalé comme tel.

4. Se rendormir

systemctl suspend endort la tour. La décision se prend sur des signaux réels, pas sur l'inactivité des périphériques : un minuteur à la minute (gamer-idle-watch) vérifie une connexion SSH établie et une partie en cours (la même sonde que le bascule de mode GPU) ; quinze minutes sans l'un ni l'autre, il demande à sleep-gamer de suspendre. sleep-gamer lui-même refuse — minuteur ou pas — tant qu'une tâche attend en file ou qu'un runner est vivant, donc le chemin automatique ne peut pas couper un travail en vol ; il ne fait jamais qu'une suspension, jamais une extinction, qui reste un choix à la main.

Le piège qui nous a longtemps surpris

Notre tour s'endormait en plein travail à distance, exactement quinze minutes après chaque réveil. La cause n'était pas notre session mais l'écran de connexion : ses réglages par défaut mettent en veille après 900 secondes sans activité clavier ou souris locale, et SSH, bureau à distance ou requêtes aux modèles ne remettent jamais ce compteur à zéro. Plus on travaillait à distance, plus elle dormait. La correction : donner à l'écran de connexion son propre réglage (sous GNOME, un profil dconf pour gdm avec sleep-inactive-ac-type='nothing') et garder la décision de dormir entre vos mains. Sa signature est arithmétique : si la tour s'endort toujours exactement 15 minutes après son réveil, ne cherchez pas ailleurs.

Sources

• Wake-on-LAN (overview and history)

Utile ? Dites-nous ce qu'il faut mesurer ensuite.