Connaissez-vous le temps de reboot de vos machines ?

Il y a pas mal de raisons pour lesquelles la maîtrise du temps de reboot est importante. Parmi celles-ci : la disponibilité, la sécurité, la réponse aux incidents et la détection de problèmes sous-jacents.

La disponibilité est probablement la première raison qui vient à l’esprit : quand on reboote un équipement, il n’est pas disponible. Et il y a des “SLA” à respecter. Le reboot étant en général un événement contrôlé et à fréquence prévisible, il est incontournable de s’assurer qu’il ne provoque pas de coupure de service plus longue que ce à quoi l’hébergeur s’est engagé.

La sécurité est une raison moins intuitive, mais certains correctifs de sécurité ne sont applicables qu’après un reboot d’un système : les mises à jour du noyau, bien évidemment, mais aussi souvent les mises à jour de bibliothèques tellement fondamentales qu’elles reviennent à redémarrer la majorité des services (ex : glibc, OpenSSL). Dans ce dernier cas, il est souvent plus simple et plus rapide de rebooter le système entier, car identifier correctement les bons services à redémarrer est une heuristique sans garantie et parfois piégeuse (par ex. le fameux checkrestart de debian-goodies fait un lsof exhaustif qui peut être coûteux sur un système encombré).

La réponse aux incidents fait référence au cas le plus radical : perte d’alimentation électrique partielle ou totale au datacenter. D’après notre expérience sur trois datacenters/opérateurs distincts, comptez sur une occurrence tous les quatre ans d’un tel incident. À ce moment-là, tous les reboots vont être mis à l’épreuve : switches, routeurs, hyperviseurs, interdépendances pour le netboot PXE, puis les VMs et leurs propres interactions, etc. Lors du dernier incident, nous avons ainsi vu cinq baies rebooter (la maintenance de l’onduleur du DC ayant décidé que couper les deux voies redondantes serait plus probant…), et tous nos services étaient opérationnels en 30 minutes, car requérant très peu d’intervention manuelle. Nous avons vu de nombreux voisins y passer la journée.

Ce qui nous mène à la détection de problèmes sous-jacents : amener un système dans un état fonctionnel ne vous garantit pas que vous saurez le ramener dans le même état après un reboot, même avec une approche DevOps rigoureuse. Le reboot échappe au contrôle de votre ordonnanceur favori et vous met dans des situations que vous n’aviez pas prévues, et pour lesquelles “tout redéployer” n’est probablement pas la solution la plus élégante et la plus rapide.

Comment améliorons-nous les temps de reboot

Chez Bearstech, nous traitons tout problème de reboot comme un incident à gérer, même un simple délai inattendu, car par expérience, cela peut révéler un problème susceptible de devenir critique au pire moment.

Par ailleurs, nous rebootons souvent, aussi souvent que possible. Les uptimes glorieux de deux ou trois ans ne le sont plus : c’est peut-être remarquable pour la stabilité du système, mais c’est un mauvais signe pour sa sécurité. Un noyau Linux sur sa branche stable, c’est environ une à quatre nouvelles versions par semaine. Si vous avez des systèmes avec juste ce qu’il faut d’installé, en ne considérant que les problèmes de sécurité qui vous concernent et qui ne sont pas contournables autrement qu’avec une mise à jour, vous devriez constater un rythme de mise à jour d’environ un nouveau noyau tous les un à trois mois. Multiplié par des centaines de serveurs et encore plus de VMs, cela fait du reboot une routine banale.

Idéalement, le moment du reboot est arbitraire, permettant de ne pas attendre une mise à jour de sécurité urgente (telle qu’une 0-day). Pour les architectures en haute disponibilité, on a clairement cette possibilité. Pour les autres, l’idéal est :

1. d’être aussi bref et discret que possible (ceci étant formalisé par le SLA),
2. d’avoir convenu avec le client d’une plage d’intervention récurrente (par ex. “tous les mardis et jeudis entre 23h00 et 23h30”).

Toutes les techniques pour rebooter plus vite sont bonnes à prendre, en plus des astuces organisationnelles. En particulier, nous n’avons pas la main sur les BIOS des fabricants de serveurs, et ils sont particulièrement lents (de nos jours, un cold boot de trois minutes est le minimum pour un gros hyperviseur). Nous utilisons, partout où cela est possible, le mécanisme kexec pour rebooter nos systèmes en contournant le BIOS. Par ailleurs, les mises à jour de BIOS servent souvent à mettre à jour le microcode des CPU, mais Linux s’en charge très bien lui-même, rendant de moins en moins obligatoire de passer par le cycle mise à jour BIOS / cold reboot.

Quand nous arrivons sur une infrastructure virtualisée, le premier benchmark que nous faisons souvent est de rebooter et de noter combien de pings sont perdus : cela nous donne tout de suite le downtime minimum, il sera impossible de faire mieux. Pour vous situer, nous obtenons en moyenne cinq secondes à ce test sur notre propre infrastructure, car nous avons optimisé ce processus jusqu’au bootloader (côté hyperviseur et côté VM). Un indice : GRUB est inadapté au monde des VMs.

Enfin, il est utile de savoir que, d’après notre expérience, le temps de reboot est en général dominé par la phase de shutdown. Il y a plusieurs raisons possibles :

• Beaucoup de données dans des caches qu’on souhaite persister (ex. Redis RDB)
• Des utilisateurs avec des connexions “lentes” dont on attend la fin de la dernière transaction HTTP
• Un cronjob long qui maintient un service occupé
• Etc.

Évidemment, il faut aussi une bonne vue d’ensemble du cycle de vie de son infrastructure : il vaut mieux éviter de rebooter pendant un backup, un snapshot ou un long calcul qui en était à 90 % de complétion :). Le métier n’est pas que de la technique.

Conclusion

Faites l’expérience : “débranchez la prise”, rebootez tous vos équipements en même temps et voyez ce que vous ne voyiez pas jusqu’ici. Corrigez, itérez, et regardez votre phobie du reboot s’éloigner avec satisfaction.