Außer um Malware unbemerkter einzuschleusen und der Schwanzlängenvergleich mit der Uptime des Servers, was sind da wirkliche Anwendungsgebiete, die so etwas rechtfertigen würden? Für ein paar Updates lässt sich jeder Server runterfahren, in kritischen Umgebungen gibt es sowieso redundante Server.
Kannst nicht jeden Furtz redundant machen. Hat was mir SLAs zu tun, und in der Summe: Überleg mal, nach wieviel Booten eine vertraglich gewährleistete Verfügbarkeit von 99,9 % dann aufgebraucht ist
Natürlich kann man Enterprise-Systeme im Cluster aufbauen. Aber das kostet den Kunden dann das Doppelte. In heutigen virtualisierten Umgebungen, wo einzelne VMs "FT" installiert werden, kann so ein Patch durchaus dazu beitragen, weniger Reboots zu verursachen. Und das kommt bei einer Verfügbarkeit von > 99,999% dem Hoster zu Gute...
Also... erst nachdenken, dann posten. Und wenn man nur Zweiteres kann, sollte man sich vorher zumindest bei Anderen erkundigen.
Ein Kernelpatch zur Laufzeit mit einem NSA-Trojaner zu versehen, schafft wohl nur ein Admin mit root Zugang... und das regelt man arbeitsrechtlich.
Der Service ergibt die Uptime, nicht die Hardware/Cluster. Wird witzig wenn du bei einem Hochbelasteten Cluster ein Node zum patchen rausnimmst...dann den zweiten den dritten....und schon hast du kaskadierende Workloads und dein Cluster serbelt ab oder die latenz geht zur sau...es gibt gruende weshalb bei banksystemen AIX/Solaris die Uptime meist ueber 1 Jahr anzeigt, fuer spielereinen wie patchen (mit anschliessendem Funktionscheck) bist dann 2 Tage drann.
Dort wo Reboot nicht möglich oder teuer ist. Könnte mir z.B. Updates für Industrieanlagen damit vorstellen. Oder auch für Fahrzeuge direkt im Betrieb. Auch für End-User-Systeme kann ein Kernel-Update ohne Reboot die User-Experience steigern. Und für was es noch nützlich sein kann ist zum Entwickeln bzw. Testen von Kernels.
Solche Systeme, bei denen ein Herunterfahren eben nicht so einfach ist, werden als "Carrier Grade"bezeichnet. Das sind Systeme mit einer Verfügbarkeit von 99,999 %.
Dies sind oftmals Systeme, welche nur schwer Redundant gemacht werden können. Nicht, das sie es nicht oftmals sind, doch erledigen sie Aufgaben, bei denen ein Ausfall - auch für kurze Zeit - zu Störungen führt.
Beispiele sind Systeme von Börsen, aber eben auch Telekommunikationsanbietern. Vor allem überall dort, wo eine stehende Verbindung gehalten werden muss, ist Redundanz oftmals zwar hilfreich, verhindert aber eben keinen Verbindungsabbruch.
Moderne, große Architekturen setzen tatsächlich oftmals eher auf eine verteilte Architektur, aber auch heute ist das nicht überall möglich. Speziell dort, wo alte Strukturen unterstützt werden müssen, sind solche Live-Patchsysteme sehr gerne genommen.
eingebrachte Patches ...der NSA oder what?
Und keiner merkt´s!
Grüßle
ichichich
da ich gut programmieren kann freue ich mich bald endlich die server meines miesen arbeitgebers kompromittieren zu können, ohne das einer etwas merkt.
is schon ganz kuhl dieses linux.
Zum Impfen des Kernels brauchst du root-Rechte und wenn du root bist, brauchst du den Kernel nicht mehr über eine Impfung zu kompromittieren.
.... schon "esch" wenn man nur Ahnung vom Blasen und nicht vom Tuten hat he? ... dann mach x (<-mal Zeichen) ...
Außer um Malware unbemerkter einzuschleusen und der Schwanzlängenvergleich mit der Uptime des Servers, was sind da wirkliche Anwendungsgebiete, die so etwas rechtfertigen würden? Für ein paar Updates lässt sich jeder Server runterfahren, in kritischen Umgebungen gibt es sowieso redundante Server.
Kannst nicht jeden Furtz redundant machen.
Hat was mir SLAs zu tun, und in der Summe:
Überleg mal, nach wieviel Booten eine vertraglich gewährleistete Verfügbarkeit von 99,9 % dann aufgebraucht ist
Natürlich kann man Enterprise-Systeme im Cluster aufbauen. Aber das kostet den Kunden dann das Doppelte. In heutigen virtualisierten Umgebungen, wo einzelne VMs "FT" installiert werden, kann so ein Patch durchaus dazu beitragen, weniger Reboots zu verursachen. Und das kommt bei einer Verfügbarkeit von > 99,999% dem Hoster zu Gute...
Also... erst nachdenken, dann posten.
Und wenn man nur Zweiteres kann, sollte man sich vorher zumindest bei Anderen erkundigen.
Ein Kernelpatch zur Laufzeit mit einem NSA-Trojaner zu versehen, schafft wohl nur ein Admin mit root Zugang... und das regelt man arbeitsrechtlich.
OSler
mehr als 99,999% heisst nicht dass das 24/7 hochverfügbar sein muss. Und wenn doch, dann ist das ein Cluster.
In beiden Fällen sind reboots möglich und 5 Neunen hängen nicht an der Uptime vom Einzelsystem sondern vom Gesamtcluster ab.
Der Service ergibt die Uptime, nicht die Hardware/Cluster. Wird witzig wenn du bei einem Hochbelasteten Cluster ein Node zum patchen rausnimmst...dann den zweiten den dritten....und schon hast du kaskadierende Workloads und dein Cluster serbelt ab oder die latenz geht zur sau...es gibt gruende weshalb bei banksystemen AIX/Solaris die Uptime meist ueber 1 Jahr anzeigt, fuer spielereinen wie patchen (mit anschliessendem Funktionscheck) bist dann 2 Tage drann.
Dort wo Reboot nicht möglich oder teuer ist. Könnte mir z.B. Updates für Industrieanlagen damit vorstellen. Oder auch für Fahrzeuge direkt im Betrieb. Auch für End-User-Systeme kann ein Kernel-Update ohne Reboot die User-Experience steigern. Und für was es noch nützlich sein kann ist zum Entwickeln bzw. Testen von Kernels.
Überall dort, wo der Admin kein Wartungsfenster beantragen will, damit er dann vielleicht mitten in der Nacht oder am WE arbeiten darf.
Übrigens: Auch bei HA-Cluster hast du eine Downtime des Dienstes, wenn du ihn von einer Maschine auf die andere verschiebst.
Absolut! Meist zwar im ms-bereich aber fuer ein Aktiensystem viel zu viel, ist das System hochbelastet auch mal >10 Sekunden
Bei entsprechend komplexem Storage und RDBMS kommen da auch schon mal einige Minuten zusammen.
Solche Systeme, bei denen ein Herunterfahren eben nicht so einfach ist, werden als "Carrier Grade"bezeichnet. Das sind Systeme mit einer Verfügbarkeit von 99,999 %.
Dies sind oftmals Systeme, welche nur schwer Redundant gemacht werden können. Nicht, das sie es nicht oftmals sind, doch erledigen sie Aufgaben, bei denen ein Ausfall - auch für kurze Zeit - zu Störungen führt.
Beispiele sind Systeme von Börsen, aber eben auch Telekommunikationsanbietern.
Vor allem überall dort, wo eine stehende Verbindung gehalten werden muss, ist Redundanz oftmals zwar hilfreich, verhindert aber eben keinen Verbindungsabbruch.
Moderne, große Architekturen setzen tatsächlich oftmals eher auf eine verteilte Architektur, aber auch heute ist das nicht überall möglich.
Speziell dort, wo alte Strukturen unterstützt werden müssen, sind solche Live-Patchsysteme sehr gerne genommen.