Pourquoi l’uptime de nos serveurs ne dépasse pas 70 jours?

L’uptime est probablement la mesure de fiabilité et de stabilité la plus facile à comparer entre admins. Nos conseils pour prendre soin des serveurs!

Billet de Grégoire Doumergue – Administrateur système

 

Le fameux concours d’uptime

En tant qu’administrateur système il m’est souvent arrivé de lire cette conversation:

< Admin1> Bouh je dois rebooter ce serveur sous FreeBSD 5.2, il a 1102 jours d’uptime 🙁
< Admin2> Pouhaha pov’ n00b ma debian 2.0 est up depuis 1302 jours !
< Admin3> …

L’uptime est probablement la mesure de fiabilité et de stabilité la plus facile à comparer entre admins. Cela paraît presque fascinant de lire qu’un serveur tourne depuis des milliers de jours, quand on sait à quel point il est difficile de fonctionner une chose aussi complexe .(Il y a aussi cette légende qui raconte la triste vie d’un serveur Novell retrouvé emmuré après des années de fonctionnement … bien joué les marketeux de Novell).
Mais malgré cela nous savons tous que l’uptime ne veut rien dire. Qu’est-ce qui tourne effectivement sur cet OS ? Un simple forwarder DNS, ou un gros serveur d’application J2EE ? Quelle est la charge moyenne, est-ce que le serveur est vraiment utilisé, et par combien de personnes ? Enfin la question la plus critique qui me pousse à écrire ce billet: combien de trous de sécurité peut-on trouver dans ce vieux kernel linux 2.2 qui tourne depuis des années ? Regardez juste combien de vulnérabilités sont trouvées dans les sources du kernel Linux chaque année: Les vieux kernels sont les terrains de jeu préférés des hackers malicieux.

 

Allez, reboot !

Alors, pour moi, il est très important que le noyau d’un système d’exploitation – ainsi que toutes les autres logiciels critiques, comme OpenSSH, Apache etc – soit mis à jour aussi souvent que possible. Et pour cela, pas d’alternative: il faut rebooter le système. Uptime, 0min. Bouh.
Mais maintenant que j’ai l’habitude de régulièrement mettre à jour mes serveurs, je ne suis plus triste. Je suis au contraire plutôt fier.
Allez, on reboote, et on les reboote tous. N’oubliez pas l’un des principes premiers de la sécurité informatique: une chaîne est aussi faible que le plus faible de ses maillons. Donc si un système reste avec une vulnérabilité “300day”, ça ne sert à rien de garder tous les autres à jour.
A part cette raison évidente de sécurité, il y a bien d’autres raisons de planifier des reboots:

– J’ai vécu cette situation bien trop souvent: je devais rebooter un serveur, c’était une question d’urgence sans alternative. Et au moment ou la commande “reboot” attend mon ultime approbation, je me demandais: “ce système n’a pas rebooté depuis plus d’un an. Est-ce qu’il redémarrera correctement ?” Ajoutez à cette pression celle d’un client mécontent, et de l’heure tardive … ça ne pouvait se reproduire. Rebooter vos serveurs le plus souvent possible vous rend plus sûr que tous leurs services reviendront après un crash.

– Arrêter un serveur, même pour une paire de minutes, est par définition une perte de service. Cela nous amène donc à réfléchir sur une meilleure disponibilté: solutions de failover manuelles, voire automatiques, partage des sessions des applications web, etc. Voilà comment une simple question opérationelle devient une grande et enrichissante question d’architecture.

– A propos de disponibilité: tester le failover est aussi important que tester les backups (vous testez bien régulièrement vos backups, hein ?). Un bon reboot permet de vérifier que le mécanisme de failover que vous avez mis en place fonctionne.

– Vous pouvez aussi vérifier la supervision. Il se peut qu’un système qui fonctionne trop bien ne soit plus correctement supervisé, justement parce qu’il n’envoie jamais d’alertes. Faites le tomber manuellement et vous pourrez voir si votre système de supervision s’en rend compte.

 

Pourquoi 70 jours ? Pourquoi pas 20 ou 90 ?

Personnellement, ma règle à propos des mises à jour de kernel est de les lancer au moins tous les deux mois. Cette fréquence peut bien sûr varier pour vous selon le nombre de serveurs que vous avez, votre charge de travail, et à quel point vous avez besoin de ces upgrades.
A chaque début de mois pair, je m’y mets. Facile de s’en rappeller. Par contre, si une grosse alerte CVE pointe le bout de son nez, je n’attends pas.

 

Quelque conseils:

Si je vous ai convaincu, ou si vous étiez déjà d’accord avec moi, voici quelque bonnes habitudes à prendre que j’ai apprises pendant mes premières sessions de mise-a-jour-et-reboot:

D’abord, documentez vos procédures: Même si vous configurez correctement vos systèmes d’init et votre supervision, écrivez noir sur blanc ce que vous devez réinstaller, recompiler, vérifier et démarrer manuellement. Par exemple, j’ai un couple de serveurs sur lesquels je dois recompiler les modules noyau de VirtualBox et AOE à chaque fois que je remplace leur kernel. Documentez quels serveurs peuvent rebooter en journée, et quels serveurs doivent rebooter la nuit. Documentez aussi dans quel ordre ils doivent rebooter.

Ensuite, tracez l’état de chaque serveur: utilisez par exemple une simple feuille de tableur pour noter quel serveur a besoin d’être mis à jour, puis redémarré. Voici un exemple:

serveur

Ici le serveur server4 a été installé entre septembre et novembre 2012. En janvier je n’ai pas le droit de mettre à jour server1 pour une quelconque raison (le marketing, c’est toujours de la faute du marketing), et je n’ai toujours pas mis à jour server2 et server3.

Enfin, communiquez. Envoyez un petit mail à vos collègues et vos clients, même si vous êtes sûrs à 100% que l’opération est transparente. Le message caché est le suivant: même si vous arrêtez intentionnellement un serveur, le service est toujours disponible. Et surtout, vous leur montrez que vous prenez soin de vos serveurs, même s’ils vont bien.

C’est comme cela que nous nous attaquons au problème de la sécurité chez SquidSolutions: plus nous sommes proactifs, mieux c’est. Et cela concerne le plus bas niveau de nos OS: leur kernel. Profitons autant que possible de la qualité de travail et de la réactivité des développeurs Linux.