So minimieren Sie Linux Server-Neustarts

Letzte Woche gab es einige Kommentare zu einem Slashdot-Artikel darüber, ob Unix- (oder Linux-) Computer jemals neu gestartet werden müssen. Nicht wenige der Kommentatoren erwähnten Maschinen mit einer Betriebszeit von mehreren Jahren.

Soweit ich weiß, müssen Linux-Boxen ziemlich oft neu gestartet werden, um Kernel-Patches anzuwenden, insbesondere sicherheitsrelevante (wie den Exploit ac1db1tch3z ). Das Ausführen von uname -r nach einem 'yum update kernel' scheint zu zeigen, dass der alte Kernel erst nach einem Neustart geladen wird.

Meine Frage ist, wie erreichen diese Boxen angesichts dessen mehrere Jahre Betriebszeit? Ein paar mögliche Lösungen, an die ich gedacht habe

1. Die Maschinen werden nicht produziert und / oder sind Benutzern ausgesetzt, sodass die Sicherheitspatches nicht so wichtig sind.
2. Alle Poster verwenden Live-Patching-Dienste wie Ksplice
3. Die Kernel-Sicherheitspatches können durch erneutes Laden von Modulen anstelle des gesamten Kernels angewendet werden.
4. uname -r spiegelt falsche Informationen nach einem Kernel-Patch wider, und der aktualisierte Kernel wird schließlich geladen.

Sind diese Erklärungen vernünftig oder fehlt mir etwas in meinem Verständnis? Gibt es eine andere Möglichkeit, die etwa zwei Dutzend Neustarts der letzten zwei Jahre zu minimieren?

Ich denke, das einzige Mal, dass man einen Linux-Computer neu starten muss, ist das Ersetzen des Kernels. Ich habe mehrere Maschinen, die länger als 2 Jahre laufen, aber ich pflege sie basierend auf dem Prinzip "Wenn es nicht kaputt ist, reparieren Sie es nicht" und auf diese Weise erreiche ich die Verfügbarkeit. Wenn Ihre Server externen Bedrohungen ausgesetzt sind, müssen Sie natürlich regelmäßig Sicherheitsupdates anwenden, und einige von ihnen erfordern einen neuen Kernel. Mir ist keine Möglichkeit bekannt, dies zuverlässig zu tun, ohne den Computer neu zu starten. Möglicherweise gibt es hier einige Tricks, aber es besteht eine gute Chance, dass Sie die Stabilität des Prozesses beeinträchtigen und die Maschine in einen Einzelbenutzermodus versetzen müssen. Sie erreichen technisch die Verfügbarkeit, aber die Maschine steht den Endbenutzern in dieser Zeit nicht zur Verfügung. Worum geht es also?

Wenn die Verfügbarkeit für Sie wirklich kritisch ist, sind Sie möglicherweise an einer HA / Clustering-Lösung interessiert, wenn Sie einen Knoten eines Clusters neu starten können, ohne die Verfügbarkeit des gesamten Systems zu beeinträchtigen. Ansonsten einfach neu starten.

Eine Lösung ist die Verwendung von ksplice.

Wenn Sie Ubuntu- oder CentOS-Kernel verwenden, können Sie den Dienst ksplice.com abonnieren. Gegen eine geringe Gebühr erhalten Sie spezielle Kernel-Images, mit denen Sie einen laufenden Kernel patchen können. Für die meisten Updates sind keine Neustarts erforderlich. Ziemlich einfach zu bedienen und einzurichten.

Wenn Sie besonders erfahren sind, können Sie die ksplice-Patches verwenden, um Ihre eigenen aktivierten Kernel zu erstellen, ohne den Dienst zu abonnieren, oder für nicht standardmäßige Kernel.

Ich hatte Server mit einer Betriebszeit von mehr als 1 Jahr. Nicht die beste Vorgehensweise, da der Server aus Sicherheitsgründen ... einige dieser Server Datenbankmaster waren und wir uns keine Ausfallzeiten leisten konnten.

Ich denke, Sicherheit sollte das Hauptanliegen sein, aber dann gibt es einige Einschränkungen in der realen Welt. Wenn Sie den Luxus-Patch haben, starten Sie ihn bei Bedarf neu. Mach dir keine Sorgen um die Verfügbarkeit, besser sicher als leid.

Ich würde empfehlen, einen Server nach einem größeren Upgrade immer neu zu starten, um sicherzustellen, dass er wieder hochgefahren wird. Sie möchten nach einem unerwarteten Neustart nicht in eine Situation geraten.

Unser Shop hat eine ziemlich gute Richtlinie zum Patchen / Neustarten. Die Wichtigkeit, sicher zu bleiben, überwiegt die Verfügbarkeitsstatistik. Wir haben eine regelmäßige Patch-Routine, die sicherstellt, dass wir nicht in eine Situation geraten, in der schlimme Dinge passieren.

Unser Wechsel zum Cluster-Computing hat dazu beigetragen, dass die wichtigen Dinge auf dem neuesten Stand bleiben und sich die Arbeit zur Einrichtung definitiv gelohnt hat.

Wenn die Verfügbarkeit für die Wartung des Service für Clients von Bedeutung ist, sollten Sie sich mit Lastausgleich und Clustering befassen. Sie können eine sichere und redundante Umgebung sowie Service-Betriebszeiten aufrechterhalten.

Wenn Sie die Sicherheit für das Braging von Rechten opfern, tun Sie Ihren Kunden wahrscheinlich einen schlechten Dienst.

Die Minimierung von Ausfallzeiten ist wichtiger als die Minimierung von Neustarts. Wie Sameer sagte, ist es A Bad Thing ™, nicht mit Ihren Kernel-Patches Schritt zu halten. Ich habe den Luxus, Load Balancer zu haben (hauptsächlich, weil ein Großteil der Dinge, die mein Arbeitgeber tut, in der Cloud ist), also führen wir fortlaufende Updates durch - wodurch ich AppServer-1 aktualisieren, aus dem Load Balancer ziehen, neu starten und erstellen kann Stellen Sie sicher, dass alles in Ordnung ist. Sagen Sie der LB: "OK, Alter AS-1 ist wieder in Betrieb!", und fahren Sie dann mit den restlichen Maschinen fort.

Je weniger Dinge Sie installiert haben, desto unwahrscheinlicher ist es, dass Sie etwas Patches benötigen. Das Minimieren Ihrer Installation (oder wie ich gerne darüber nachdenke: die Angriffsfläche) kann einen langen Weg gehen. Dies gilt nicht nur für Pakete, sondern auch für Kernelkonfigurationen. Heutzutage werden die meisten Distributionen mit jedem möglichen Modul kompiliert, was alles andere als optimal ist. Benutzerdefinierte Kernel können schwierig zu warten sein, aber sie können sich auch auszahlen, da Sie genau wissen, was sich darin befindet, und die Wahrscheinlichkeit, dass sie gepatcht werden müssen, weiter verringern.

(Offenlegung: Ich arbeite für Canonical)

Speziell für Ubuntu bietet Canonical ab 16.04 Live-Kernel-Patches an.

• http://blog.dustinkirkland.com/2016/10/canonical-livepatch.html
• https://www.ubuntu.com/server/livepatch

Dies nutzt die Live-Patching-Technologie im Upstream-Linux-Kernel seit der Veröffentlichung von 4.0.