Wie vermeide ich Ausfallzeiten mit Linux?

Häufig erfordern Software-Updates für Ubuntu einen Neustart (was zu Nebenwirkungen wie Ausfallzeiten führen kann).

Ich sehe, dass Ubuntu https://www.ubuntu.com/livepatch hat, das Kernel-Updates ohne Neustarts ermöglicht. Dies ist jedoch ein kostenpflichtiger Dienst. Es gibt auch ksplice .

Gibt es Linux-Distributionen / -Prozesse, bei denen Upgrades / Patches niemals einen Neustart erfordern?

(Ich weiß, dass das Einrichten von Hochverfügbarkeitsservern (HA-Servern) und das Vorhandensein von Einwegservern bewährte Methoden sind. Daher frage ich nicht nach einem Dienst, sondern nach tatsächlichen Servern.)

Auf Ihre Frage: "Gibt es Linux-Distributionen / -Prozesse, bei denen Upgrades / Patches niemals einen Neustart erfordern?" Sind mir keine bekannt, und ich bin höchst zweifelhaft, ob es jemals solche geben wird, die wirklich keinen Neustart erfordern. Zusätzlich zu Michael Hamptons Kommentar, warum Live-Patches nirgends ein out-of-the-box-Erlebnis sind, erzielt Live-Patches auch nicht das gleiche Ergebnis wie ein Neustart.

Eine Anekdote, um dies zu veranschaulichen: Ich habe kürzlich ein Problem untersucht, bei dem ein bestimmtes Dienstprogramm auf einer großen Anzahl von Maschinen mit einem Seg-Fehler begonnen hatte. Ich habe versucht, in den gemeinsam genutzten Bibliotheken nachzuschauen, um festzustellen, ob ein kürzlich aktualisiertes Update das Problem behoben hat. ldd sagte, es sei keine ausführbare Datei (obwohl ldd die Abhängigkeiten der gemeinsam genutzten Bibliotheken gut erkennen konnte, als ich dieselbe Binärdatei auf meinen Laptop herunter zog). Ich habe versucht, es in gdb durchzugehen. es war fehlerhaft, bevor es überhaupt zur ersten Anweisung kam.

Als ich den Zeitpunkt des Fehlers betrachtete, stellte ich fest, dass kürzlich ein Ksplice-Patch angewendet wurde. Ich habe den Patch zurückgesetzt und die Binärdatei ist nicht fehlerhaft, dann habe ich sie wieder hinzugefügt und es hat wieder angefangen, Fehler zu verursachen. Ein Neustart auf einem gleichwertig gepatchten Kernel hat gut funktioniert. Es stellte sich heraus, dass es sich um einen Patch für die 32-Bit-Unterstützung handelte, den die Ksplice-Leute nicht richtig angewendet hatten. Zu ihrer Ehre haben sie innerhalb weniger Stunden einen festen Patch herausgegeben, und es funktionierte wieder einwandfrei mit unserer Flotte, ohne eingreifen zu müssen.

Ein weiteres Beispiel: Die Meltdown / Spectre-Patches waren so invasiv, dass das Ubuntu-Kernel-Team entschied, dass Live-Patches unpraktisch waren und die Leute ihre Systeme im festen Kernel neu starten mussten, bevor sie wieder Live-Patches erhielten.

Wir betreiben eine große Flotte physischer und virtueller Server bei der Arbeit, mit einer großen Anzahl von Ksplice- und Canonical Livepatch-Systemen. Beide waren weitaus zuverlässiger als viele andere Softwareprodukte, aber ich würde unsere Dienste lieber mit einer reboot-freundlichen Architektur entwickeln, als auf Kernel-Live-Patches zu setzen.

Es gibt einen wichtigen Unterschied zwischen einer hohen Verfügbarkeit eines Dienstes und einer hohen Verfügbarkeit einer einzelnen Maschine.

In den meisten Fällen ist das Ziel, den Service hoch verfügbar zu machen, und die Verfügbarkeit einzelner Maschinen ist nur ein Mittel, um dieses Ziel zu erreichen. Es gibt jedoch Grenzen, wie weit Sie dem Ziel näher kommen, wenn Sie die Verfügbarkeit einzelner Maschinen verbessern.

Selbst wenn Sie die gesamte Ausfallzeit aufgrund eines Softwareupdates einkalkulieren könnten, sind die einzelnen Maschinen immer noch nicht zu 100% verfügbar. Um die Verfügbarkeit des Dienstes über die Verfügbarkeit einzelner Maschinen hinaus zu erhöhen, muss Redundanz auf einer höheren Ebene entworfen werden. Der letzte Satz Ihrer Frage zeigt, dass Sie dies zumindest im Prinzip wissen.

Wenn Sie einen Service so konzipieren, dass er verfügbarer ist, als es einzelne Maschinen leisten können, besteht kein Druck mehr, eine hohe Verfügbarkeit einzelner Maschinen zu erreichen. Für hochverfügbare Dienste müssen daher keine Neustarts vermieden werden. Stattdessen können Sie auf die Zuverlässigkeit einzelner Maschinen verzichten, um Einsparungen zu erzielen, die sich auf andere Bereiche auswirken, in denen Sie erheblich höhere Zuverlässigkeitsgewinne erzielen können.

Sobald das High-Level-System für den Fall, dass einzelne Hardwarekomponenten ausfallen, als zuverlässig ausgelegt ist, ändert sich das Live-Patchen von Kerneln von einem Vorteil zu einem Risiko.

Dies ist ein Risiko, da es geringfügige Unterschiede zwischen dem Verhalten eines Computers mit Live-Patches und eines Computers mit der neuesten Kernelversion geben kann. Dies kann einen latenten Fehler verursachen, der beim nächsten Neustart eines Computers zu einem Ausfall führen kann. Dieses Risiko wird durch einen Neustart verstärkt, damit ein sauberer Zustand als Methode zur Minderung einiger Ausfälle angesehen wird.

Eines Tages könnte es zu einem Ausfall kommen, bei dem ein Neustart der Maschine möglicherweise Abhilfe schafft. Beim Neustart werden Sie jedoch von dem latenten Fehler getroffen, der verhindert, dass die Maschine in den gewünschten Zustand zurückkehrt. Live-Patches sind nicht die einzige Möglichkeit, einen solchen latenten Fehler zu verursachen. Sie können auch darauf zurückzuführen sein, dass ein Dienst manuell aktiviert und nie für den Start während des Startvorgangs konfiguriert wurde oder zu früh gestartet wurde kommt wegen unbefriedigter Abhängigkeiten nicht zustande.

Aus diesen Gründen ist ein hochverfügbarer Dienst möglicherweise einfacher zu erreichen, wenn einzelne Computer regelmäßig so langsam neu gestartet werden, dass Sie Probleme erkennen und die Neustartsequenz anhalten können, sobald Probleme auftreten.