Wie Meta Linux in großem Maßstab patcht

• Das Patchen von Linux-Servern ist einfach, aber Zehntausende Server ohne Downtime zu patchen, ist nicht leicht
• Meta nutzt für das Patchen von Millionen Linux-Servern Red Hats Kpatch und KLP (Kernel Live Patching)
  • Mit KLP lassen sich die neuesten Sicherheitsupdates auf den Linux-Kernel anwenden, ohne neu zu booten

Live-Kernel-Patching

• Live-Kernel-Patches werden als Pakete mit geändertem Code bereitgestellt, getrennt vom Haupt-Kernel-Paket
• Live-Patches sind kumulativ, der neueste Patch enthält also alle Korrekturen der vorherigen Patches
• Live-Patches gelten nicht für alles; Daten oder Strukturen lassen sich nicht patchen, und das Erstellen von Live-Patches erfordert zusätzliche Engineering-Arbeit

Kpatch

• Kpatch funktioniert, indem es den ursprünglichen Kernel mit dem gepatchten Kernel vergleicht und dann mithilfe eines benutzerdefinierten Kernel-Moduls neuen Code in den laufenden Kernel patcht
• Anschließend überwacht der Kpatch-Prozess mit ftrace den Stack bestehender Prozesse, um zu prüfen, ob der Patch ohne schädliche Auswirkungen angewendet werden kann
• Wird dies als sicher eingestuft, wird der laufende Code auf die gepatchte Funktion umgeleitet und der nun veraltete Code entfernt
• Der Patch ist dann auf dem Server angewendet, ohne dass Downtime entsteht

Im Fall von Meta

• Natürlich ist es in der Praxis nicht so einfach
• Bei Meta dauert das Anwenden eines Live-Patches auf einen Host normalerweise 1 bis 2 Sekunden
• 1 bis 2 Sekunden pro Host ist im Vergleich zu kexec, dem Linux-Kernel-Mechanismus zum Starten eines neuen Kernels, wirklich schnell
• Es sind weder Downtime noch Workload-Migration nötig; nach dem Anwenden des Live-Patches ist das System sofort einsatzbereit

Wie man Millionen Maschinen patcht

• Beim Patchen von Millionen Maschinen ist das noch nicht alles
• Bei Meta können während des Patch-Rollouts Bugs entdeckt werden, daher patchen Administratoren zuerst die Release-Candidate-Tier
• Der Package Roller, der RPM-basierte Patches ausliefert, prüft automatisch auch den Gesundheitszustand der Server
• Meta überwacht auf dem neuen Kernel Abstürze, wichtige Alerts, Anwendungsprobleme und die Performance; überschreitet die Fehlerrate 1 Absturz pro 1000 Server, wird der Patch gestoppt und auf den vorherigen Kernel zurückgesetzt
• Meta verwendet Kpatch, aber es gibt auch andere Alternativen
  • SUSE bietet kGraft an, Oracle nutzt Ksplice, und Canonical unterstützt Livepatch
  • Unabhängig vom Code liefern alle ähnliche Ergebnisse

Meinung von GN⁺

Das Wichtigste an diesem Artikel ist, dass Meta eine effiziente Patch-Methode ohne Downtime für Millionen Server weltweit eingeführt hat. Das ist selbst für Junior-Software-Ingenieure ein interessantes Thema und unterstreicht die Bedeutung von Wartung und Sicherheit in Linux-Systemen. Außerdem kann der Artikel helfen, die Komplexität und Notwendigkeit von Live-Patching-Technologien zu verstehen.

[GN⁺]

Hacker-News-Kommentare

• Ksplice ist die ursprüngliche Live-Patching-Technologie, die nach der Übernahme durch Oracle, während ich dort arbeitete, auch auf User-Space-Programme ausgeweitet wurde. Trotz des Wechsels in die Cloud ist es eine sehr coole Technologie, die nicht veraltet ist, weil sie es ermöglicht, komplette Systemneustarts auch im großen Maßstab zu vermeiden.
• Dass Meta nicht erwähnt hat, wie lange ein vollständiger Rollout mit dieser Methode dauert, scheint ein wichtiges Detail auszulassen. Mit Live-Patching kann man Server, Rechenzentren und die Cloud ohne Downtime betreiben.
• Wenn man in Metas Größenordnung arbeitet, kann Live-Patching sinnvoll sein, aber die meisten gut konzipierten Services und Anwendungen sollten vollständige Server-Neustarts gut verkraften können. Die Komplexität der Verwaltung von Millionen von Servern ist kaum vorstellbar.
• KernelCare ist ein Service für Kernel-Live-Patching, der die meisten Linux-Distributionen unterstützt.
• Ich habe Kpatch auf vielen virtuellen Maschinen verwendet, und es funktioniert ziemlich gut.
• Derzeit werden etwa 13 Millionen Server betrieben; 2023 sollten 20 Milliarden US-Dollar für neue Rechenzentrums-Hardware ausgegeben werden, und 2024 weitere 20 Milliarden. Aktuell wird CentOS 8 Stream verwendet, ein Wechsel auf 9 steht bald an.
• Das Drainen und Entdrainen von Hosts soll schwierig sein. Das bedeutet im Wesentlichen, dass es nicht leicht ist, Hosts aus dem Service herauszunehmen und anschließend wiederherzustellen; das wiederum bedeutet, dass der Linux-Kernel nicht für Live-Patching ausgelegt ist und jeder Versuch in diese Richtung immer eine Quelle von Unsicherheit bleibt, in Bezug auf den Engineering-Aufwand teuer ist und die Katastrophe stets unmittelbar bevorzustehen scheint. Dagegen würde es in puncto Zuverlässigkeit große Vorteile bringen, die Systeme zum Service-Draining und zur Wiederherstellung von Hosts so anzupassen, dass sie sehr robust und verlässlich werden. Dieser Ansatz wirkt wie ein Überdecken organisatorischer Dysfunktionen. Ein Team kann zwar alle Kernel patchen, aber es ist unmöglich, dafür zu sorgen, dass alle Hosts Service-Draining und Wiederherstellung unterstützen, und weil es keinen echten Anreiz gibt, das zu beheben, versucht es auch niemand. Nur coole Hacks und neue Projekte werden ordentlich belohnt.
• Die meisten Organisationen profitieren nicht davon, Meta zu imitieren, und müssen das auch nicht.
• Ich höre zum ersten Mal den Begriff „Hyperscale“. Ich frage mich, worin der Unterschied zu einfacher Skalierung besteht.