Frage:
Wie wenden Dienste mit hoher Verfügbarkeit Patches an, ohne neu zu starten?
secureninja
2018-10-24 11:24:40 UTC
view on stackexchange narkive permalink

Wie werden wichtige Sicherheitsupdates auf Systemen installiert, deren Neustart Sie sich nicht leisten können, für die jedoch ein Neustart erforderlich ist? Beispielsweise können Dienste / Unternehmen, die rund um die Uhr ohne Ausfallzeiten ausgeführt werden müssen, z. Amazon.com oder Google.

Was lässt Sie denken, dass Google es sich nicht leisten kann, seine Server neu zu starten?Sie müssen nicht alle auf einmal neu starten, wie Sie wissen.
Heutzutage wird eine Verfügbarkeit der Hardware über 95% als teuer und veraltet angesehen.Die meisten Webdienste verteilen ihre Dienste einfach im Cluster, um eine nahezu 100% ige Verfügbarkeit zu ermöglichen, die kostengünstiger ist als die Anforderungen an das Betriebssystem und die Hardware.
@DmitryGrigoryev Richtig, sie müssen nicht neu gestartet werden, und das ist der Kern der Frage hier.Redundante Systeme sind ein gängiger Ansatz für Systeme mit hoher Verfügbarkeit oder "Null Ausfallzeit" (um eine Beschreibung aus OP zu stehlen).
Redundanz und Load Balancing sind hier Schlüsselkonzepte
Ich empfehle, https://landing.google.com/sre/books/ (kostenlos) zu lesen, wenn Sie besonders daran interessiert sind, wie Google Zuverlässigkeits-Engineering durchführt.Während sich ein Großteil davon mit konzeptionellen und kulturellen Komponenten im Zusammenhang mit der Standortzuverlässigkeit befasst, gibt es dort auch einiges an technologischen Informationen.
Angesichts der Tatsache, dass jede einzelne Festplatte nach etwa einem Jahrzehnt ausfällt, sollten die großen Player * ständig * defekte Festplatten wechseln.Ähnliches gilt für andere Hardwarekomponenten.Schon unter diesem Aspekt ist klar, dass massive Redundanz eine große Rolle spielt.
Verfügbarkeit = Redundanz.Abhängig von Ihrem Anwendungsfall verfügen Sie möglicherweise über redundante Discs, redundante Stromleitungen, redundante Kühlung, kalte Ersatzteile, heiße Ersatzteile und / oder ein Notfallteam, falls Ihr erstes Team aufgrund eines großen physischen Angriffs (z. B. ein Flugzeug fliegt in Ihr Gebäude) ausfällt).
Google und Amazon veröffentlichen auch kanarische Veröffentlichungen - sie veröffentlichen zuerst ein Update in einem weniger wichtigen Markt (Asien), um zu beweisen, dass es keine Fehler gibt, und nach einiger Zeit (24 Stunden) werden sie auf anderen Märkten veröffentlicht.Die weniger wichtigen Märkte fungieren effektiv als Kanarienvogel in ihrer Goldmine
Fünf antworten:
forest
2018-10-24 11:31:16 UTC
view on stackexchange narkive permalink

Es gibt verschiedene Dienstprogramme in verschiedenen Betriebssystemen, die das Hot-Patching von laufendem Code ermöglichen. Ein Beispiel hierfür wären die Funktionen kpatch und livepatch von Linux, mit denen der laufende Kernel gepatcht werden kann, ohne den Betrieb zu unterbrechen. Die Funktionen sind begrenzt und können nur geringfügige Änderungen am Kernel vornehmen. Dies reicht jedoch häufig aus, um eine Reihe kritischer Sicherheitsprobleme zu beheben, bis Zeit für eine ordnungsgemäße Behebung gefunden werden kann. Diese Art von Technik wird im Allgemeinen als dynamische Softwareaktualisierung bezeichnet.

Ich sollte jedoch darauf hinweisen, dass die Websites praktisch keine Ausfallzeiten aufweisen ( Hochverfügbarkeit). sind wegen Live-Patches nicht so zuverlässig, sondern wegen Redundanz. Immer wenn ein System ausfällt, sind mehrere Sicherungen vorhanden, mit denen der Datenverkehr oder die Verarbeitung von Anforderungen sofort und ohne Verzögerung weitergeleitet werden können. Es gibt eine große Anzahl verschiedener Techniken, um dies zu erreichen. Der Redundanzgrad bietet eine signifikante Verfügbarkeit, gemessen in Neunen. Eine Verfügbarkeit von drei bis neun beträgt 99,9%. Vier neun Betriebszeit beträgt 99,99% usw. Der "Heilige Gral" ist fünf Neun oder 99,999% Betriebszeit. Viele der von Ihnen aufgelisteten Dienste sind aufgrund ihrer redundanten Backup-Systeme, die auf der ganzen Welt verteilt sind, fünf bis neun verfügbar.

Sobald Sie die gesamte HA-Infrastruktur eingerichtet haben, ist es besser, Live-Patches zu vermeiden.Live-Patches gefährden Ihre Zuverlässigkeit.** 1. ** Der Fehler könnte bereits zu einer Beeinträchtigung Ihrer Datenstrukturen im Speicher geführt haben, und obwohl Sie den Live-Patch angewendet haben, sind Sie aufgrund der zuvor eingeführten Beeinträchtigung immer noch betroffen.** 2. ** Es kann subtile Unterschiede zwischen dem Anwenden des Live-Patches und dem Booten eines echten gepatchten Kernels geben, was dazu führt, dass Ihre Anwendung nur auf dem ersteren funktioniert.Beim nächsten Neustart werden Sie von einem Fehler betroffen sein, der bis dahin nur schwer zu beheben ist.
@kasperd Außerdem ist ** 3. ** Live-Patching viel eingeschränkter und erfordert sorgfältige Überlegungen und Tests und fügt zur Laufzeit zusätzliche Indirektion hinzu.Warum sich die Mühe machen, wenn Sie Systeme einzeln neu starten können?Was Sie wahrscheinlich sowieso schon in regelmäßigen Abständen tun, denn wenn Sie einen solchen Cluster haben, warum sollten Sie das nicht tun?
Der Vollständigkeit halber sollte in der Antwort erwähnt werden, dass "fünf Neunen" oder eine Verfügbarkeit von 99,999% einer Ausfallzeit von etwas mehr als 5 Minuten und 15 Sekunden pro Jahr entsprechen.Sechs Neunen (99,9999%) würden eine Ausfallzeit von knapp 32 Sekunden pro Jahr bedeuten.
Gibt es Websites mit einer Verfügbarkeit von 5 Neunen?Dies entspricht nur einer Stunde Ausfallzeit alle 11 Jahre.
@BlueRaja-DannyPflughoeft Es gibt viele, viele Dienste, die danach streben, obwohl ich keine Ahnung habe, wie hoch ihre tatsächlichen Prozentsätze sind.Was ist Ihrer Meinung nach die Verfügbarkeit von Amazon EC2?Oder auch nur Stack Exchange?
@immibis: Stack Exchange hatte in den letzten Jahren mehr als eine Stunde Ausfallzeit, also definitiv nicht annähernd 99,999%
@BlueRaja-DannyPflughoeft Trotzdem scheint es mindestens 3,5 und vielleicht 4 Neunen zu schaffen. Es ist nicht schwer, sich etwas Wichtigeres vorzustellen, mit viel mehr Ressourcen dahinter, das noch zuverlässiger ist.
@immibis Ich persönlich kann mir das nur schwer vorstellen, zumindest für öffentlich zugängliche Websites.Alle Regierungswebsites, die mich betreffen, hatten längere Ausfallzeiten.Unsere Polizei-Website ist ausgefallen.Die Website mit den Wahlergebnissen war während der Wahlzählung mehrere Stunden lang nicht erreichbar.Einmal konnte ich meine Bankkontoinformationen nicht sehen, da das Backend einige Stunden lang nicht verfügbar war.Wenn es diese geheimen magischen versteckten Server mit 6 Neun-Betriebszeiten gibt, sind sie zumindest nicht öffentlich konfrontiert!
@pipe Wollen Sie damit sagen, dass Regierungswebsites wichtig sind?Kommerzielle Websites legen mehr Wert auf Zuverlässigkeit, da die Benutzer bei einem Ausfall der Website zu einem Konkurrenten wechseln können.Regierungswebsites haben nicht die gleiche Konkurrenz und verlieren unter dem Strich kein Geld, wenn Benutzer ihre Website nicht mehr nutzen.Das kann bedeuten, dass Sie als Benutzer der Meinung sind, dass diese Websites wichtiger sind.Gleichzeitig bedeutet dies jedoch, dass die Regierung keinen Anreiz hat, die Zuverlässigkeit als hoch zu priorisieren.
@kasperd Das ist ein sehr guter Punkt.Ich glaube, ich habe in 20 Jahren noch nie gesehen, dass die Startseite von Google ein einziges Mal ausgefallen ist.
@pipe 2009 gab es einen Vorfall, bei dem ein Fehler dazu führte, dass Google-Suchanfragen jedes einzelne Suchergebnis eine Stunde lang als schädlich auflisteten.Ich denke, das ist der größte Ausfall, den die Google-Suche seit mehr als einem Jahrzehnt hatte.
Warten Sie, bis Sie mit Bankensystemen interagieren müssen und jemand versucht, 6 Neunen zu fordern.Das sind ungefähr 31 Sekunden pro Jahr.
Junge, manchmal gibt es eine sehr allgemeine (und etwas naive) Ansicht darüber, was eine Regierungswebsite tun könnte.Denken die Leute sofort nur, dass DMV-Informationen das Ausmaß sind, weil das alles ist, mit dem sie interagieren?Bedenken Sie, dass es wahrscheinlich Standorte gibt, die sich auf die militärische Bereitschaft, die Koordinierung des Terrorismus, die Stabilität des Stromnetzes usw. auswirken. Das einzige, was Sie verlieren, wenn die meisten zivilen Standorte ausfallen, ist Geld.
@pipe Es gibt einen Grund, warum "go to google.com" im Grunde die Standardmethode für den technischen Support ist, um zu überprüfen, ob eine Verbindung zum Internet besteht.
@BillK Das sind nicht die, mit denen die Leute interagieren und sehen, wie sie untergehen.
Ich bin nicht sicher, ob mehrere Server in einer Serverfarm als redundant oder als "Lastverteilung" bezeichnet werden sollen, mit genügend Spielraum, um einige der Server zu behandeln, die aufgrund von Updates oder Problemen heruntergefahren werden.
@rcgldr Google führt eine Vielzahl verschiedener Dienste aus.Es gibt einen großen Unterschied zwischen der Frage, ob einer von ihnen einen Ausfall hatte, oder der Frage, ob google.com/search einen Ausfall hatte.Ein Ausfall kann von einer kleinen Anzahl von Benutzern bis hin zur ganzen Welt reichen.Wenn Sie also fragen, ob Google kürzlich einen Ausfall hatte, welchen Service haben Sie im Sinn?
@kasperd - Ich denke, es war Google und / oder Youtube, die um den 16. Oktober 2018 einen Ausfall hatten.
@rcgldr Ja, ich habe damals von einem YouTube-Ausfall gehört.Ich habe es selbst nicht bemerkt.Die Aussage @ pipe bezog sich jedoch auf die Google-Startseite und nicht auf jeden einzelnen Google-Dienst.
Nicht einmal Google bekommt 5 Neunen für einige ihrer Dienste.Youtube war diesen Monat für ein paar Stunden außer Betrieb.
@Qwertie wie viele Stunden im letzten Jahrzehnt?
mcgyver5
2018-10-24 13:22:59 UTC
view on stackexchange narkive permalink

Ich habe eine Präsentation eines Netflix-Mitarbeiters auf einer Sicherheitskonferenz gesehen. Sie patchen überhaupt nicht. Wenn ein Patch erforderlich ist, stellen sie stattdessen neue Instanzen bereit und blasen die nicht gepatchten weg. Sie machen das fast ständig. Sie nennen es Rot-Schwarz-Bereitstellung.

Interessant.Das sieht aus wie eine Variation einer rollierenden Bereitstellung - vielleicht könnten wir es "Bulldozer-Bereitstellung" nennen - raze und neu erstellen :-).
Ich denke, es heißt rot-grüne Bereitstellung, aber bei Netflix wird es rot-schwarz genannt.
Zumindest meiner Erfahrung nach ist eine rot-grüne Bereitstellung, wenn Sie zwei redundante, vollständige Servercluster haben, zwischen denen Sie wechseln (auf einmal), während Sie bei einer fortlaufenden Bereitstellung einen einzelnen Cluster haben, der Stück für Stück aktualisiert wird.Aber ich bin mir nicht sicher, ob jeder diese Begriffe verwendet.
Es ist "blaugrün", nicht "rot-grün", aber die Erklärung von @sleske's ist korrekt.(Ich denke, "blau-grün" wird verwendet, weil "rot-grün" wie der TDD-Ansatz "rot-grün-refaktor" klingt.) Aber ja, Netflix nennt es "rot-schwarz", weil dies ihre Firmenfarben sind.
Imo ist dies der einzig vernünftige Weg, dies zu tun, wenn Sie eine Microservice-Architektur ausführen.
Vielleicht sollten sie es in "orange- (ist-das-neu-) schwarz" umbenennen?
@DoktorJ Erst im nächsten Jahr müssen sie den Namen ändern.
sleske
2018-10-24 13:22:01 UTC
view on stackexchange narkive permalink

Die kurze Antwort lautet:

Sie werden neu gestartet.

Sie scheinen davon auszugehen, dass Amazon und Google auf einem einzigen Server ausgeführt werden, und wenn ja neu gestartet wird, ist die gesamte Site / der gesamte Dienst ausgefallen. Dies ist sehr weit von der Wahrheit entfernt - große Dienste werden normalerweise auf vielen Servern ausgeführt, die parallel arbeiten. Weitere Informationen finden Sie in Techniken wie Clustering, Lastausgleich und Failover.

Google verfügt beispielsweise über über ein Dutzend Rechenzentren auf der ganzen Welt und jedes verfügt über eine große Anzahl von Servern (Schätzungen gehen von 100.000 bis 400.000 Servern pro Zentrum aus).

In solchen In Umgebungen werden Updates (sowohl Feature- als auch Sicherheitsupdates) normalerweise als fortlaufende Bereitstellungen installiert:

  • Wählen Sie eine Teilmenge von Servern aus.
  • installieren Sie Updates auf dem Teilmenge
  • Starten Sie die Teilmenge neu. In der Zwischenzeit übernehmen die anderen Server die
  • Wiederholung mit der nächsten Teilmenge :-)

Es gibt andere Optionen, wie z. B. Hot Patching, aber sie werden nicht so häufig verwendet Nach meiner Erfahrung zumindest nicht auf typischen großen Websites. Einzelheiten finden Sie in der Antwort des Waldes.

Heck Netflix-Server werden unerklärlicherweise neu gestartet und stürzen ab, nur um Sie auf Trab zu halten.Sie nennen es Chaos Monkey.
@kasperd Neulich habe ich herausgefunden, dass es ein Chaos Kong gibt.Er nimmt ganze Verfügbarkeitszonen heraus.Nur ein roter Knopf kann den gleichen Effekt erzielen.
Sie könnten 3.5 hinzufügen: Überprüfen Sie, ob nichts kaputt ist.Gilt eher für andere Arten von Updates, aber die Möglichkeit, den Rollout frühzeitig zurückzusetzen, ist ein wichtiger Grund, ihn langsam zu machen.Tolle Antwort, IMO sollte es die akzeptierte sein.
@Aron Google hat [DiRT] (https://queue.acm.org/detail.cfm?id=2371516), eine Art Chaos Monkey im Maßstab - bei simulierten Ausfällen geht es normalerweise darum, ganze Cluster oder sogar Rechenzentren und Büros zu verlieren.
Klingt auch so, als ob das OP davon ausgeht, dass Windows 10 ausgeführt wird ...
@Mazura,, ein Freund eines Freundes, hatte seinen Windows 10-Laptop während einer Live-Konferenzpräsentation heruntergefahren ... und das Update hat den Laptop gemauert.Großartige PR für Windows.(Nicht.) Auch https://worldbuilding.stackexchange.com/a/31419/16689
So aktualisiere ich meine Microservices.Da das Netzwerk skalierbar ist und über einen Lastausgleich verfügt, wird ein Teil des Netzwerks vom Balancer getrennt und das Update angewendet.Nach diesem Schritt wird der Load Balancer auf den aktualisierten Dienststapel umgeschaltet.Dann wird der veraltete Teil aktualisiert.Für die Leute sieht es nach einem Update ohne Ausfallzeiten aus.In der Tat ist es.Nur merkt es niemand.
papajony
2018-10-24 13:37:28 UTC
view on stackexchange narkive permalink

Sie können " Bereitstellungsaktivitäten" unter "Softwarebereitstellung" überprüfen. Eine übliche Methode besteht darin, einen Load Balancer vor Ihren Diensten zu verwenden und den Datenverkehr entsprechend umzuleiten. Bei einer Technik namens "blaugrüne Bereitstellung" leiten Sie den Datenverkehr von "blauen" zu "grünen" Servern um. Dies hat keine benutzerseitige Ausfallzeit, vorausgesetzt natürlich, dass die Anwendung dies richtig handhaben kann, z.

Angenommen, Ihre Anwendung führt Version 1 auf dem blauen Server aus und Ihr Load Balancer leitet den Datenverkehr dorthin. Sie können den grünen Server (der keinen Datenverkehr empfängt) auf Version 2 aktualisieren. Anschließend konfigurieren Sie den Load Balancer neu, um den Datenverkehr an den grünen Server weiterzuleiten. Sie haben also ohne Ausfallzeit ein Upgrade von Version 1 auf Version 2 durchgeführt.

Sie können die Blaugrün-Technik auch als Teil des Tests verwenden. Beispielsweise konfigurieren Sie den Load Balancer so, dass 95% des Datenverkehrs an den blauen Server (v1) und 5% an den grünen Server (v2) geleitet werden. Auf diese Weise können Sie Ihre neue Version unter weniger Verkehr testen und weniger Auswirkungen auf Benutzer haben, falls sie Fehler aufweist.

Harper - Reinstate Monica
2018-10-27 05:44:30 UTC
view on stackexchange narkive permalink

Es ist ziemlich einfach, wenn Dinge gruppiert und Proxy sind. Weil Sie viele Knoten haben, die denselben Job ausführen können (oder mehrere bei Datenrepositorys wie Suchmaschinen, Hadoop-Dateisystemen usw.)

Führen Sie eine Websuche durch. Sie schlagen www.altavista.com. Der DNS-Eintrag listet ein halbes Dutzend IP-Adressen auf und Ihr Client trifft zufällig eine. Jede IP ist ein Cisco-Router, der Fans auf einen zufälligen von 8 physischen Front-End Servern (insgesamt 48) mit internen IP-Adressen überträgt. Dieser Server normalisiert Ihre Abfrage (entfernt Leerzeichen usw.) und verwendet dann einen MD5-Hash davon. Der MD5 entscheidet, an welchen von 300 Proxyservern diese Abfrage gesendet wird. Diese Abfrage wird über ein Standardprotokoll wie SOAP an den Proxy weitergeleitet.

Die Front-End-Server sind austauschbar, da sie nur vorübergehende Anforderungen einer einzelnen Abfrage verarbeiten. Außerhalb des schlimmsten Falls wird die Anfrage eines Kunden gelöscht. Sie verwenden RRD-Daten oder andere Datenerfassungen, um zu überwachen, wann ein Front-End-Server ausfällt, und leiten seinen Datenverkehr an einen Standby-Server um. Gleiches gilt für die Cisco-Router.

Der Proxy überprüft zunächst seinen Cache . Bei einem Cache-Treffer wird die Lokalisierung gemischt und die Antwort zurückgesendet. erledigt. Wenn es sich um einen "Cache-Fehler" handelt, fächert der Proxy die Abfrage an die Suchcluster auf.

Wenn ein Proxy ausfällt, kann erneut ein anderer physischer Computer gegen diesen Proxy ausgetauscht werden. Es ist jetzt etwas kritischer, da die Proxys nicht austauschbar sind. Jeder "besitzt" einen kleinen Ausschnitt aus dem Suchergebnisspektrum. Wenn also die 0x0000-0x00d9-Maschine ausfällt, muss der Ersatz wissen, dass er für diesen Bereich eingreifen muss. Schlimmer noch, dieser Ersatzcomputer hat einen leeren Cache, sodass jede Suchabfrage ein Cache-Miss ist. Dadurch wird die Belastung der Suchcluster richtig um ein winziges Bit pro ausgefallenem Proxy erhöht. Das heißt, wenn Sie alle Proxys gleichzeitig bouncen, tun Sie dies nicht während der Hauptsuchzeiten !

Die Suchcluster weisen eine ähnliche Schichtung auf und Redundanz natürlich, und jedes Segment der Suchdatenbank befindet sich auf mehreren Knoten. Wenn also ein Knoten ausfällt, können andere Knoten diesen Teil der Ergebnisse bedienen.

Ich konzentriere mich auf den Proxy als Beispiel. Die Kommunikation erfolgt über SOAP, die Kommunikation über SOAP erfolgt über ein ähnliches Protokoll auf hoher Ebene. Daten, die ein- und ausgehen, sind vorübergehend, mit Ausnahme des Caches, der für den Ausgleich der Suchmaschinenclusterlast wichtig ist. Der Punkt ist, dass es jederzeit sofort ausgetauscht werden kann, mit dem schlimmsten Fall, dass einige Suchvorgänge abgelaufen sind. Dies würde der Front-End-Server bemerken und könnte seine Abfrage einfach erneut senden. Zu diesem Zeitpunkt wäre der neue Proxy aktiv.

Wenn Sie also 300 Proxys haben, dauert dies eine halbe Stunde Wenn ein Proxy seinen Cache wiederherstellt und die Suchmaschinenlast um 20% erhöht werden kann, können Sie alle 30 Sekunden einen Proxy austauschen. In einem gleitenden Zeitraum von 30 Minuten erstellen 60 Proxys (20%) Caches neu. Vorausgesetzt, es besteht sogar die dringende Notwendigkeit, so schnell zu gehen.

Die Einführung dieses Beispiels dauert 2 1/2 Stunden. Wenn für eine aufkommende Bedrohung eine schnellere Reaktion erforderlich ist, müssen Sie entweder mehr Cache-Fehler hinnehmen oder Ihren Dienst lange genug herunterfahren, um Patches zu erstellen (jedoch bei der Suche) Beispiel für eine Engine: Die Cache-Fehler sind immer noch ein Problem, wenn Sie wieder hochfahren. Ich habe die RRD-Diagramme nach einem Notfall-DB-Neuladen und dem erforderlichen Cache-Flush gesehen. Es ist etwas zu sehen.)

Natürlich normalerweise Der Prozess kann ohne vollständigen Neustart gepatcht, gestoppt und neu gestartet werden. Ich habe eine Betriebszeit von 2 Jahren auf Produktionsknoten gesehen.



ⓘ
Diese Fragen und Antworten wurden automatisch aus der englischen Sprache übersetzt.Der ursprüngliche Inhalt ist auf stackexchange verfügbar. Wir danken ihm für die cc by-sa 4.0-Lizenz, unter der er vertrieben wird.
Loading...