On coupe ou pas ? De la criticité des serveurs
Publié par Clément Bohic le | Mis à jour le
Confronté à une coupure de clim en salle machine, un sysadmin a dû choisir quels serveurs éteindre. Une situation pas si évidente dont des pairs ont témoigné pour l’occasion.
Où placer, au sein des racks, les serveurs les plus critiques ? Des sysadmins en ont discuté en réaction à une mésaventure arrivée à un de leurs pairs de l’université de Toronto.
À l’origine, il y a une panne de clim dans la salle machine principale. Pour éviter que la température monte trop, il a fallu éteindre des serveurs. Mais lesquels choisir pour dégrader le moins possible la qualité de service ?
Certains choix étaient évidents, comme l’extinction des nœuds SLURM. D’autres l’étaient moins : les équipes du département informatique n’avaient pas de documentation explicite à propos du niveau de criticité des machines et des dépendances entre elles.
« Nous pourrions [réaliser cette doc] au moment des déploiements ou des changements de configuration », constate l’intéressé. Et d’ajouter : « Cela nous permettrait aussi de [mieux détecter] les systèmes que nous pouvons décommissionner »…
Pastille verte ou pastille rouge ?
Pourquoi pas utiliser, en parallèle, un code couleur ? Cette suggestion est revenue plusieurs fois dans la discussion. L’un des participants a relaté une expérience vécue : en cas de coupure d’alimentation avec basculement sur les onduleurs, les équipements sur lesquels on avait apposé une pastille verte pouvaient être coupés sans délai. Ceux pourvus d’une pastille orange nécessitaient une notification préalable. Ceux dotés d’une pastille rouge devaient, autant que possible, rester en fonctionnement.
Témoignage de même teneur pour un sysadmin ayant travaillé sur le ResNet de la WWU (Western Washington University). Mais uniquement avec pastilles vertes et rouges, appliquées spécifiquement aux équipements de cœur de réseau. Les switchs LAN redondants et les serveurs de monitoring faisaient partie des premiers éléments déconnectés.
« Depuis des années, nous pensions nos ressources comme complètement virtualisées, explique un autre admin victime d’une mésaventure similaire. Devoir envisager leurs caractéristiques physiques a été un petit choc », poursuit-il. Mettre hors service les équipements les moins importants n’avait pas suffi. Notamment parce que des serveurs critiques non redondés, localisés côte à côte, surchauffaient. Il existait bien une documentation RackTables, mais obsolète. Et le mapping réseau (quelle machine sur quel port physique) était approximatif. Il a fallu, pour prendre des décisions, solliciter les équipes du prestataire (hébergeur en colocation), afin qu’elles envoient des photos de la façade et de l’arrière des racks. Un des serveurs, refroidi en urgence, a pu l’être après avoir retiré celui du dessous et ouvert le boîtier.
Quant à déterminer les services critiques, « allez expliquer aux parties prenantes que leurs apps n’en sont pas », surtout dans les environnements décentralisés, fait remarquer un participant à la discussion. Ce à quoi on lui répond, entre autres, que la criticité « absolue » (vis-à-vis des utilisateurs) est souvent mieux comprise que la criticité « relative » (par rapport aux autres services).
Gérer le problème à plus haut niveau
Toutes ces réflexions valent essentiellement pour les scénarios dans lesquels on a la main sur la gestion physique de l’infrastructure. Pour les autres – mais pas que -, on peut imaginer gérer la problématique sur les couches supérieures : regroupement de VM sur un minimum d’hôtes, migration de workloads Kubernetes, réduction de la quantité de ressources processeur allouées…
« [Nous concernant,] nous n’exploitons pas les machines que nous n’avons pas explicitement assignées à un service », lance un des participants à la discussion. Un autre suggère, d’expérience, de placer les serveurs critiques dans la partie inférieure des racks, l’air chaud ayant tendance à monter. On ne les mettra cependant pas tout en bas, afin de se protéger des inondations.
Solution a priori plus sûre, mais aussi plus chère : avoir une infra multisite. « Aujourd’hui, on prendrait simplement plusieurs datacenters ou de la haute disponibilité cloud […], mais ce n’est pas le même prix », confirme un utilisateur qui met en avant un autre élément : les SSD. S’il y en avait eu dans les installations d’un de ses anciens employeurs, cela aurait pu atténuer un incident consécutif à une coupure d’électricité. C’était lors d’un test de basculement vers les onduleurs. Au moment de revenir sur la source principale, un bug logiciel est survenu. Beaucoup de machines s’étant éteintes récupéraient leur image système sur des serveurs centralisés. Lorsqu’elles ont redémarré, il a fallu définir des priorités, faute de suffisamment d’I/O pour tout charger en parallèle. Et dans ce cadre, « déterminer ce qui était le plus important a pris autant de temps que si nous y étions allés au doigt mouillé ».
« Cela me rappelle une histoire comparable », réagit un sysadmin. Le contexte : des centaines de serveurs Windows en boot réseau. Et, régulièrement, des « brown-outs », là aussi à défaut d’assez d’I/O. « J’ai convaincu le management d’acheter un des premiers SSD ‘entreprise’ du marché [une carte PCIe]. » Deux exemplaires pour une facture à cinq chiffres, mais qui ont suffi à fluidifier les opérations.
Illustration ©