Redémarrer des dizaines de milliers de serveurs sans l'accord de leurs clients, en gardant le silence pour éviter que certains ne testent l'exploit : OVHcloud assume ses choix face à Januscape, et les documente jusqu'aux ratés.
Il y a deux semaines, la faille Januscape révélait qu'une simple machine virtuelle louée pouvait faire planter le serveur physique qui l'héberge. Restait à savoir comment un hébergeur encaisse ce genre de nouvelle quand son parc compte des dizaines de milliers d'hôtes et environ un million de machines virtuelles. OVHcloud vient de répondre en détail. Dans un retour d'expérience publié le 20 juillet sur son blog et signé de son RSSI Julien Levrard, le groupe français déroule son opération d'urgence, décisions assumées et bugs compris.
Un feu vert le soir même, Sydney en éclaireur le lendemain
L'alerte tombe le mardi 7 juillet en début d'après-midi. Le correctif est adapté aux noyaux Debian maison dans la journée, validé en laboratoire le soir (lors d'un test interne, l'exploit fait planter un hôte non corrigé en deux minutes environ), et le comité exécutif donne son feu vert dans la foulée : la première région sera traitée dès le lendemain. Cinq options étaient sur la table, d'attendre les noyaux officiels au correctif à chaud en passant par la migration généralisée des machines virtuelles. Toutes ont été écartées au profit de la plus radicale : corriger puis redémarrer l'intégralité des hôtes.
- money_offRemboursement 30 jours
- securityCertificat SSL inclus
- install_desktopCompatible WordPress
Le déploiement démarre mercredi depuis Sydney, un choix moins exotique qu'il n'y paraît : la région est petite, et sa nuit locale correspond aux heures de bureau des équipes européennes. Une fois la procédure validée en conditions réelles, le « follow the sun » s'enclenche, chaque région prenant le relais sur sa matinée locale, en continu. Des seuils d'arrêt encadrent le rythme : au-delà de 15 hôtes en panne simultanée dans les régions les plus denses (5 ailleurs), la vague est suspendue le temps que les techniciens de datacenter interviennent. Sur la première nuit, 20 à 30 hôtes sur 6 000 ne sont pas revenus seuls, barrettes mémoire ou configuration en cause. L'opération se boucle à J+11, les dernières régions étant traitées le 19 juillet.
Redémarrer sans prévenir, un choix qu'OVHcloud défend
La décision la plus lourde tient en une formule du billet : un « patching unilatéral à impact contrôlé ». Comprendre : pas de fenêtre de maintenance négociée client par client, des redémarrages appliqués sans accord individuel, et un impact jugé inévitable qu'il s'agissait de diluer plutôt que d'espérer éviter. Pour limiter la casse, les orchestrateurs ont calculé un graphe de colocalisation afin de ne jamais redémarrer en même temps deux hôtes portant des instances d'un même projet client (le principe du pilote et du copilote qui ne mangent jamais le même plat, appliqué aux serveurs). Une anti-affinité revendiquée en « best effort », donc sans garantie absolue. Les charges les plus sensibles, dont plus de 4 300 machines virtuelles de bases de données managées, ont été migrées à chaud, une par une.
Côté communication, l'entreprise assume jusqu'à ses silences, et c'est sans doute la partie la plus sensible du billet. Pas de page d'état publique au départ, pour ne pas exposer la séquence de déploiement, et une information volontairement mesurée tant que le parc restait vulnérable. Détailler davantage aurait, selon le billet, poussé certains clients à tester l'exploit sur leur propre machine. Le document ne masque pas les ratés pour autant. Des machines virtuelles ne redémarraient pas après l'opération, un conflit de services identifié et corrigé au deuxième jour. Des données ont été corrompues sur trois clusters, probablement des redémarrages tombés en pleine écriture disque, et des API de la région de Paris sont restées bloquées environ deux heures. Enfin, près de 90 000 clients de la seule région GRA6 n'ont jamais été contactés par e-mail, l'envoi massif ayant été écarté. Une bannière d'information dans l'espace client a fini par être développée en urgence, déployée au troisième jour.
Ce niveau de détail, rare chez un hébergeur de cette taille, tombe à un moment où le groupe affiche par ailleurs une santé solide, cloud public en tête. OVHcloud prévient d'ailleurs que l'exercice se répétera au gré des prochaines failles noyau, avec l'ambition de faire mieux sur l'information des clients. Si votre VPS redémarre un matin sans explication, vous saurez désormais à quoi ressemble l'autre bout du fil.
