• This forum has a zero tolerance policy regarding spam. If you register here to publish advertising, your user account will be deleted without further questions.

Einspielen von Kernel-/Patches ohne Reboot bei kritischen Systemen

webjunky

New Member
Hallo liebe Gemeinde,

ich frage mich schon seit längerem, wie man mit kritischen Systemen und dem Einspielen von Kernel-/Patches optimal verfahren kann, ohne das man großen Aufwand beim Failovern/Loadbalancen hat.

Sollte man in solch einem Szenario auf ein adäquates System failovern sofern dies nicht schon automatisch durch nen LB durchgeführt wird? Oder wird von euch kexec, KSplice und Co. erfolgreich eingesetzt? Oder vollzieht ihr die Reboots zu einem bestimmten Zeitplan? Oder lasst ihr eure Systeme einfach ohne Kernelreboots rennen?

Mich würde es wirklich interessieren, wie ihr das handhabt. Ich spiele die Kernelpatches eigentlich immer einmal im Monat des Nachts ein, sofern alle neuen Patches durchevaluiert worden sind. Außnahmen gibts allerdings immer wieder. Anschließend starte ich die Kisten händisch neu.

Viele Grüße
webjunky
 
Welches OS benutzt du denn konkret, dass du mind. einmal im Monat den Server booten musst? Bei Kernel-Patches sollte man zwischen Security- und Feature-Patches unterscheiden. Meiner Ansicht sind nur Security-Patches zwingend notwendig. Davon sollten aber nicht jeden Monat welche kommen.
 
Wenn es wirklich nötig ist werden alle Kunden entsprechend ihrer SLA mit Vorlauf informiert und dann werden die Systeme durchgestartet. Es kann aus verschiedenen Gründen vorkommen, dass man ein System neustarten muss und das verstehen Kunde im Allgemeinen auch. Wenn es nicht einmal für so dringende Wartungsarbeiten möglich ist, ein System für wenige Minuten offline zu, dann muss man eben auch deutlich mehr Aufwand betreiben und mit HA und Failover kommen.

Relevante Downtime verursachen im Allgemeinen aber eh nicht kurze Reboots, sondern die unvorhergesehenen Ausfälle.
 
Wenn ein System eine so kritische Verfügbarkeit hat, daß schon ein einfacher Reboot problematisch ist, dann sollte man dringend über Failover-Mechanismen nachdenken und diese implementieren, wenn sie noch nicht existieren.
Persönlich bin ich der Meinung, daß ein gelegentlicher Reboot der Stabilität eines Systems eher zuträglich ist (Speicherfragmentierung, Fehler im Code, die zu kleineren Memory-Leaks führen usw. kann man damit am besten bereinigen).
Geplante Reboots kann man außerdem natürlich in eine Zeit legen, wo sie am wenigsten weh tun.
Und wie PapaBaer schon schriebt: Problematisch sind sowieso die unvorhergesehenen Ausfälle (und laut Murphy treten die immer dann auf, wenn es am allerwenigsten paßt)
 
Aus der Praxis gesprochen gibt es zwei sinnvolle Wege:

a) Loadbalancer: Einen Server nach dem anderen durchstarten
b) Anhand der Statistiken prüfen, wann am wenigsten Traffic auf der Seite ist und in diesem Zeitraum durchstarten. Gibt es diesen Zeitraum nicht, kann man eine Downtime auch rechtzeitig ankündigen

Noch eine Möglichkeit wäre den Server mitten am Tag durchzustarten und ggf. für ein paar Stunden offline zu lassen. Das ganze medienwirksam als DDoS verkaufen und du hast gleich ein bisschen Werbung gemacht.

Nachteil: In der Regel funktioniert das nur bei halbwegs bekannten Seiten.
 
Das wird jetzt offtoppic, interessiert mich aber trotzdem. Wie loadbalanced du denn die Loadbalancer?
Gibt's günstig bei jedem Hersteller, der solche Kisten baut - meist in Active-Passive mit Heartbeat und Failover-Schaltung.

F5 (verkauft die Dinger auch) - hat aber auch recht gute Doku zu den Grundprinzipien auf der Seite...
 
Back
Top