Comment Meta applique des correctifs à Linux à très grande échelle

• Appliquer des correctifs à des serveurs Linux est simple, mais le faire sur des dizaines de milliers de serveurs sans temps d’arrêt ne l’est pas
• Pour corriger des millions de serveurs Linux, Meta utilise Kpatch de Red Hat et KLP (Kernel Live Patching)
  • KLP permet d’appliquer les dernières mises à jour de sécurité au noyau Linux sans redémarrage

Correctifs live du noyau

• Les correctifs live du noyau sont fournis sous la forme de paquets contenant le code modifié, distincts du paquet principal du noyau
• Les correctifs live sont cumulatifs : le correctif le plus récent inclut toutes les modifications des correctifs précédents
• Les correctifs live ne s’appliquent pas à tout : ils ne peuvent pas modifier les données ni les structures, et leur création demande un travail d’ingénierie supplémentaire

Kpatch

• Kpatch fonctionne en comparant le noyau d’origine et le noyau corrigé, puis en appliquant le nouveau code au noyau en cours d’exécution à l’aide d’un module de noyau personnalisé
• Le processus Kpatch utilise ensuite ftrace pour surveiller la pile des processus existants afin de vérifier si le correctif peut être appliqué sans effet indésirable
• Si cela est jugé sûr, le code en cours d’exécution est redirigé vers la fonction corrigée, puis l’ancien code devenu obsolète est supprimé
• Le correctif est alors appliqué au serveur, sans provoquer de temps d’arrêt

Dans le cas de Meta

• Bien sûr, dans la réalité, ce n’est pas aussi simple
• Chez Meta, l’application d’un correctif live à un hôte prend généralement 1 à 2 secondes
• 1 à 2 secondes par hôte, c’est extrêmement rapide par rapport à kexec, le mécanisme du noyau Linux permettant de démarrer un nouveau noyau
• Aucun temps d’arrêt ni migration de charge de travail n’est nécessaire : il suffit d’appliquer le correctif live pour qu’il soit immédiatement utilisable

Comment corriger des millions de machines

• Lorsqu’il faut corriger des millions de machines, cela ne s’arrête pas là
• Chez Meta, comme des bugs peuvent être découverts pendant le déploiement du correctif, les administrateurs commencent par appliquer le correctif au niveau release candidate
• Le package roller, qui distribue des correctifs basés sur RPM, vérifie aussi automatiquement l’état de santé des serveurs
• Meta surveille les plantages, les alertes majeures, les problèmes applicatifs et les performances sur le nouveau noyau ; si le taux d’erreur dépasse 1 crash pour 1 000 serveurs, le correctif est interrompu et un retour au noyau précédent est effectué
• Meta utilise Kpatch, mais il existe d’autres alternatives
  • SUSE propose kGraft, Oracle utilise Ksplice et Canonical prend en charge Livepatch
  • Quel que soit le code, tous offrent des résultats similaires

L’avis de GN⁺

Le point le plus important de cet article est que Meta a mis en place une méthode de correction efficace et sans temps d’arrêt pour des millions de serveurs dans le monde. C’est aussi un sujet intéressant pour les ingénieurs logiciels débutants, car il souligne l’importance de la maintenance et de la sécurité des systèmes Linux. Cet article peut également aider à comprendre la complexité et la nécessité des technologies de correctifs live.

[GN⁺]

Commentaires sur Hacker News

• Ksplice est la technologie originale de patching à chaud qui a ensuite été étendue aux programmes en espace utilisateur pendant que j’y travaillais, après son rachat par Oracle. C’est une technologie très cool qui ne devient pas obsolète, car elle évite de devoir redémarrer l’ensemble du système à grande échelle, malgré la migration vers le cloud.
• Le fait que Meta ne mentionne pas combien de temps cette méthode prend pour être déployée sur l’ensemble de l’infrastructure semble omettre un détail important. Le patching à chaud permet d’opérer sans temps d’arrêt des serveurs, des centres de données ou du cloud.
• Si l’on travaille à l’échelle de Meta, le patching à chaud peut avoir du sens, mais la plupart des services et applications bien conçus devraient pouvoir très bien supporter un redémarrage complet des serveurs. Il est difficile d’imaginer la complexité que représente la gestion de plusieurs millions de serveurs.
• KernelCare est un service de patching à chaud du kernel qui prend en charge la plupart des distributions Linux.
• J’ai utilisé Kpatch sur de nombreuses machines virtuelles, et cela fonctionne plutôt bien.
• Ils exploitent actuellement environ 13 millions de serveurs, ont dépensé 20 milliards de dollars en 2023 pour de nouveaux équipements de centres de données, et prévoient de dépenser 20 milliards de dollars supplémentaires en 2024. Ils utilisent actuellement CentOS 8 Stream et prévoient de passer bientôt à la version 9.
• Le drainage et le rétablissement des hôtes seraient difficiles. Cela signifie en pratique qu’il n’est pas simple de retirer un hôte du service puis de le remettre en état, ce qui veut dire que le kernel Linux n’a pas été conçu pour le patching à chaud, que tenter de le faire reste toujours une source d’incertitude, que cela coûte cher en travail d’ingénierie et qu’une catastrophe semble toujours imminente. À l’inverse, modifier le système de drainage et de remise en service des hôtes afin qu’il devienne très robuste et fiable apporterait un gain majeur en fiabilité. Cette approche semble masquer les dysfonctionnements de l’organisation. Une équipe peut patcher tous les kernels, mais rendre tous les hôtes compatibles avec le drainage et la restauration du service est impossible, et comme il n’existe aucune véritable incitation à corriger cela, personne ne s’y attaque. Seuls les hacks impressionnants et les nouveaux projets sont correctement récompensés.
• La plupart des organisations ne tireraient aucun bénéfice à imiter Meta, et n’en ont pas besoin.
• C’est la première fois que j’entends le concept de « hyperscale ». Je me demande en quoi cela diffère d’un simple passage à l’échelle.