Im Sommer sinken traditionell sowohl die KundenaktivitĂ€t als auch die IntensitĂ€t der VerĂ€nderungen in der Infrastruktur von Webprojekten, sagt uns KapitĂ€n Offensichtlich. Das liegt einfach daran, dass selbst ITler gelegentlich in Urlaub gehen. Und CTOs ebenfalls. Das macht die Situation fĂŒr diejenigen, die an ihrem Posten bleiben, schwieriger, aber darum geht es hier nicht: Vielleicht ist genau deshalb der Sommer die beste Zeit, um in Ruhe ĂŒber das bestehende Backup-System nachzudenken und einen Plan zur Verbesserung aufzustellen. Dabei kann Ihnen die Erfahrung von Egor Andreev aus , die er auf der Konferenz erzĂ€hlt hat, hilfreich sein. .
Beim Bau von Backup-Standorten und der Implementierung von Reservesystemen gibt es verschiedene Fallen, in die man tappen kann. Und es ist absolut unerlĂ€sslich, diese zu meiden. Perfektionismus und⊠Faulheit verderben uns dabei, wie in vielen anderen Bereichen auch. Wir versuchen, alles perfekt zu machen, aber das ist nicht notwendig! Es genĂŒgt, bestimmte Dinge gut zu machen und sie bis zur Vollendung zu bringen, damit sie ordnungsgemÀà funktionieren.
Failover ist kein SpaĂ oder ein Gimmick; es ist ein ernstes Werkzeug, das eine einzige Aufgabe hat â die Ausfallzeiten zu minimieren, damit der Service und das Unternehmen weniger Geld verlieren. Bei allen Backup-Methoden sollten wir im folgenden Kontext denken: Wo stecken die Kosten?
Die erste Falle: Wenn wir groĂe, zuverlĂ€ssige Systeme aufbauen und Backups implementieren, verringern wir die Zahl der AusfĂ€lle. Das ist ein gefĂ€hrlicher Irrglaube. TatsĂ€chlich erhöht sich wahrscheinlich die Anzahl der AusfĂ€lle, wenn wir Backup-Strategien implementieren. Wenn wir alles richtig machen, reduzieren wir insgesamt die Ausfallzeiten. Es wird zwar mehr AusfĂ€lle geben, aber sie treten mit geringeren Kosten auf. Was bedeutet Backup? â Es ist eine KomplexitĂ€tssteigerung des Systems. Jede KomplexitĂ€t ist problematisch: Wir haben mehr Schrauben, mehr ZahnrĂ€der, einfach mehr Bestandteile â und damit steigt die Wahrscheinlichkeit eines Ausfalls. Und sie werden tatsĂ€chlich ausfallen. Und die AusfĂ€lle werden hĂ€ufiger vorkommen. Ein einfaches Beispiel: Angenommen, wir haben eine Website mit PHP und MySQL. Und wir mĂŒssen sie dringend absichern.
Nun, wir nehmen die zweite Plattform und bauen ein identisches System auf. Die KomplexitĂ€t verdoppelt sich â wir haben nun zwei EntitĂ€ten. DarĂŒber hinaus fĂŒgen wir eine bestimmte Logik fĂŒr den Datentransfer von einer Plattform zur anderen hinzu â das heiĂt, Datenreplikation, Kopieren von statischen Inhalten und so weiter. Diese Replikationslogik ist in der Regel sehr komplex, sodass die GesamtsystemkomplexitĂ€t nicht nur das Zwei- sondern sogar das Drei-, FĂŒnf- oder Zehnfache betragen kann.
Die zweite Falle: Wenn wir wirklich groĂe, komplexe Systeme bauen, trĂ€umen wir davon, was wir am Ende haben wollen. VoilĂ : Wir streben nach einem superzuverlĂ€ssigen System, das ohne Ausfallzeiten arbeitet, innerhalb von einer halben Sekunde (oder besser noch instantan) umschaltet, und beginnen, diese TrĂ€ume in die RealitĂ€t umzusetzen. Aber hier gibt es einen Haken: Je geringer die gewĂŒnschte Umschaltzeit, desto komplizierter wird die Logik des Systems. Je komplexer wir diese Logik gestalten mĂŒssen, desto hĂ€ufiger wird das System ausfallen. Und man könnte in eine sehr unangenehme Situation geraten: Wir versuchen mit aller Macht, die Ausfallzeiten zu reduzieren, wĂ€hrend wir tatsĂ€chlich alles komplizierter machen, und wenn etwas schiefgeht, sind die Ausfallzeiten am Ende lĂ€nger. Oft kommt man dann zu dem Gedanken: Ach... es wĂ€re besser gewesen, keinen redundanten Aufbau zu haben. Es wĂ€re besser, wenn eins funktionierte und mit bekannten Ausfallzeiten.
Wie kann man dem begegnen? Man muss aufhören, sich selbst zu belĂŒgen, aufhören, sich einzureden, dass wir hier ein Raumschiff bauen werden, und stattdessen realistisch einschĂ€tzen, wie lange das Projekt in Anspruch nehmen kann. Und fĂŒr diese maximale Zeit werden wir bestimmen, welche Methoden wir tatsĂ€chlich nutzen, um die ZuverlĂ€ssigkeit unseres Systems zu erhöhen.
Es ist höchste Zeit fĂŒr Geschichten aus dem Leben...
Beispiel Nummer eins
Stellen Sie sich eine Visitenkarte fĂŒr das Rohrleitungswerk Nr. 1 in der Stadt N vor. Dort steht in groĂen Buchstaben â ROHRLEITUNGSWERK Nr. 1. Darunter ein Slogan: âUnsere Rohre sind die rundesten Rohre in Nâ. Und darunter die Telefonnummer des GeschĂ€ftsfĂŒhrers und sein Name. Wir verstehen, dass wir reservieren mĂŒssen â das ist eine sehr wichtige Angelegenheit! Wir beginnen herauszufinden, aus was es besteht. HTML-Static â das heiĂt, ein paar Bilder, wo der GeschĂ€ftsfĂŒhrer am Tisch in der Sauna mit seinem Partner irgendein GeschĂ€ft bespricht. Wir beginnen ĂŒber die Ausfallzeit nachzudenken. Mir kommt in den Sinn: Man braucht nicht lĂ€nger als fĂŒnf Minuten dort zu liegen. Und hier stellt sich die Frage: Wie viele VerkĂ€ufe gab es ĂŒberhaupt ĂŒber unsere Website? Wie viele? Was heiĂt ânullâ? Es bedeutet vielleicht: denn alle vier GeschĂ€fte im letzten Jahr hat der GeschĂ€ftsfĂŒhrer am gleichen Tisch, mit denselben Menschen gemacht, mit denen sie in die Sauna gehen und am Tisch sitzen. Und wir verstehen, dass es nichts Schlimmes sein wird, selbst wenn die Website einen Tag lang ruhig bleibt.
Basierend auf den Vorgaben haben wir einen Tag Zeit, um diese Geschichte umzusetzen. Wir fangen an, ĂŒber das Sicherungssystem nachzudenken. Dabei wĂ€hlen wir das ideale Backup-Schema fĂŒr dieses Beispiel aus: In unserem Fall verwenden wir keine Sicherung. Ein erfahrener Administrator kann dieses ganze System in einer halben Stunde mit ein paar Pausen aufsetzen. Einen Webserver installieren, Dateien bereitstellen â das ist alles. Es wird funktionieren. Es gibt nichts, was ĂŒberwacht werden muss, und nichts, dem besondere Aufmerksamkeit geschenkt werden muss. Die Schlussfolgerung aus dem ersten Beispiel ist daher recht offensichtlich: Dienste, fĂŒr die keine Sicherung erforderlich ist, brauchen auch keine Backup-Lösungen.
Beispiel Nummer zwei
Unternehmensblog: Professionell geschulte Redakteure veröffentlichen dort Neuigkeiten, zum Beispiel haben wir an einer bestimmten Messe teilgenommen und wir haben ein weiteres neues Produkt herausgebracht, und so weiter. Angenommen, das ist ein Standard-PHP mit WordPress, einer kleinen Datenbank und etwas Statik. NatĂŒrlich kommt einem sofort der Gedanke, dass es unbedingt nicht ausfallen darf â "nicht lĂ€nger als fĂŒnf Minuten!", all das. Doch lassen Sie uns weiterdenken. Was macht dieser Blog? Es kommen Besucher ĂŒber Yandex, Google mit verschiedenen Anfragen, organisch. GroĂartig. Aber wie stehen die VerkĂ€ufe dazu? Erleuchtung: nicht wirklich. Der Wertraffic geht auf die Hauptseite, die auf einem anderen Server lĂ€uft. Wir fangen an, ĂŒber ein Backup-Schema fĂŒr den Blog nachzudenken. Ideal wĂ€re es, ihn in ein paar Stunden hochzufahren, und es wĂ€re gut, sich darauf vorzubereiten. Es ist vernĂŒnftig, einen Server in einem anderen Rechenzentrum zu mieten, das Umfeld aufzusetzen, das heiĂt Webserver, PHP, WordPress, MySQL, und ihn im Standby zu lassen. In dem Moment, in dem wir feststellen, dass alles kaputt ist, mĂŒssen wir zwei Dinge tun â ein MySQL-Dump von 50 MB einspielen, das dauert eine Minute, und dann eine bestimmte Anzahl von Bildern aus dem Backup wiederherstellen. Das ist auch keine groĂe Sache. Auf diese Weise lĂ€uft binnen einer halben Stunde alles wieder. Keine Replikationen oder, Gott bewahre, ein automatischer Failover. Fazit: Was wir schnell aus dem Backup wiederherstellen können, muss nicht reserviert werden.
Beispiel Nummer drei, etwas komplexer
Online-Shop. Ein leicht modifiziertes PHP mit Open Heart, MySQL mit einer soliden Datenbasis. Relativ viel Statische (schlieĂlich hat der Online-Shop schöne HD-Bilder und all das), Redis fĂŒr Sessions und Elasticsearch fĂŒr die Suche. Wir beginnen, ĂŒber Ausfallzeiten nachzudenken. Und hier ist es natĂŒrlich klar, dass ein Tag ohne Internet-Shop nicht schmerzlos vergehen kann. Denn je lĂ€nger er offline ist, desto mehr Geld verlieren wir. Wir mĂŒssen uns beeilen. Aber wie viel? Ich denke, wenn wir eine Stunde offline sind, wird es niemand verrĂŒckt machen. Ja, wir verlieren etwas, aber wenn wir uns anstrengen, wird es nur schlimmer. Lassen Sie uns den Zeitrahmen fĂŒr den akzeptablen Ausfall definieren, der pro Stunde zulĂ€ssig ist.
Wie kann man das alles reservieren? Eine Maschine ist in jedem Fall erforderlich: Eine Stunde ist ziemlich wenig. MySQL: Hier ist eine Replikation notwendig, eine Live-Replikation, da 100 GB in einer Stunde wahrscheinlich nicht in den Dump passen. Statische Dateien, Bilder: Auch hier können 500 GB in einer Stunde möglicherweise nicht ĂŒbertragen werden. Daher ist es besser, die Bilder sofort zu kopieren. Redis: Hier wird es interessanter. In Redis liegen die Sitzungen â einfach so löschen können wir ihn nicht. Denn das wĂ€re nicht ideal: Alle Benutzer wĂ€ren abgemeldet, ihre Warenkörbe wĂ€ren leer, und so weiter. Die Leute mĂŒssten ihren Benutzernamen und ihr Passwort erneut eingeben, und viele könnten abspringen und ihren Kauf nicht abschlieĂen. Auch hier wĂŒrde die Conversion sinken. Andererseits ist Redis genau aktuell, mit den zuletzt angemeldeten Benutzern, wahrscheinlich auch nicht erforderlich. Ein guter Kompromiss wĂ€re, Redis zu nehmen und aus einem Backup wiederherzustellen, das von gestern oder, wenn es stĂŒndlich gemacht wird, eine Stunde alt ist. GlĂŒcklicherweise ist die Wiederherstellung aus dem Backup nur das Kopieren einer Datei. Die interessanteste Geschichte ist Elasticsearch. Wer hat jemals die MySQL-Replikation eingerichtet? Wer hat jemals die Elasticsearch-Replikation eingerichtet? Und bei wem hat sie danach normal funktioniert? Ich wollte darauf hinaus: Wir sehen in unserem System eine gewisse EntitĂ€t. Sie scheint nĂŒtzlich zu sein â aber sie ist komplex.
Es ist kompliziert, weil unsere Ingenieure keine Erfahrung damit haben. Entweder haben sie negative Erfahrungen gemacht oder wir erkennen, dass es sich um eine relativ neue Technologie mit ihrer eigenen KomplexitĂ€t handelt. Wir denken nach... Oh Mann, Elasticsearch ist auch groĂ, die Wiederherstellung aus einem Backup dauert lange, was machen wir? Wir verstehen, dass Elasticsearch in diesem Fall fĂŒr die Suche verwendet wird. Aber wie verkauft unser Online-Shop? Wir fragen die Marketingabteilung, woher die Leute kommen. Sie sagen: â90 % kommen direkt ĂŒber Yandex.Marktplatz auf die Produktseite.â Entweder kaufen sie oder sie kaufen nicht. Folglich benötigt nur 10 % der Benutzer die Suche. Die Replikation von Elasticsearch zu halten, insbesondere zwischen verschiedenen Rechenzentren in unterschiedlichen Regionen, bringt viele Herausforderungen mit sich. Was bleibt uns also ĂŒbrig? Wir setzen Elasticsearch auf einer reservierten Plattform ein und lassen es erstmal in Ruhe. Wenn es sich zieht, werden wir es irgendwann vielleicht hochfahren, aber das ist nicht sicher. Insgesamt bleibt die Erkenntnis: Dienste, die sich nicht auf die Finanzen auswirken, reservieren wir erneut nicht. Damit die Struktur einfacher bleibt.
Beispiel Nummer vier, noch komplexer.
Integrator: Blumenverkauf, Taxi-Bestellungen, Warenverkauf â kurz gesagt, alles Mögliche. Eine ernsthafte Angelegenheit, die 24/7 fĂŒr eine groĂe Anzahl von Nutzern verfĂŒgbar ist. Mit einem vollstĂ€ndigen und interessanten Technologie-Stack, der spannende Datenbanken, Lösungen und hohe Belastungen umfasst. Und vor allem sollte es nicht lĂ€nger als fĂŒnf Minuten liegen, denn das ist problematisch. Es liegt nicht nur daran, dass die Leute nicht kaufen, sondern weil sie sehen, dass das System nicht funktioniert, frustriert sind und möglicherweise beim nĂ€chsten Mal nicht zurĂŒckkommen.
Okay. FĂŒnf Minuten. Was machen wir damit? In diesem Fall bauen wir ernsthaft, mit vollem Einsatz, eine echte Backup-Plattform auf, mit der Replikation von allem und jedem, und vielleicht automatisieren wir auch so viel wie möglich, um auf diese Plattform zu wechseln. Und zusĂ€tzlich dazu dĂŒrfen wir eine wichtige Sache nicht vergessen: tatsĂ€chlich ein Regelwerk fĂŒr den Wechsel zu schreiben. Das Regelwerk kann sehr einfach sein, auch wenn alles automatisiert ist. Etwas in der Art von: âDieses Ansible-Szenario ausfĂŒhrenâ, âIn Route 53 die entsprechende Option aktivierenâ und so weiter â es sollte jedoch eine prĂ€zise Liste von MaĂnahmen sein.
Eigentlich ist alles klar. Die Umstellung der Replikation ist eine triviale Aufgabe, oder sie geschieht automatisch. Das Umstellen des Domainnamens im DNS gehört ebenfalls dazu. Das Problem ist, dass bei einem Ausfall eines solchen Projekts Panik ausbricht, und selbst die erfahrensten Administratoren können davon betroffen sein. Ohne eine klare Anleitung wie "Ăffnen Sie das Terminal, gehen Sie hierher, die Adresse unseres Servers ist nach wie vor so und so" ist es schwierig, innerhalb von fĂŒnf Minuten eine Wiederbelebung durchzufĂŒhren. Zudem ist es einfach, Ănderungen in der Infrastruktur zu dokumentieren, wenn wir diese Richtlinie nutzen, beispielsweise um entsprechende Anpassungen an der Regel vorzunehmen.
Wenn jedoch das Backup-System sehr komplex ist und wir in einem bestimmten Moment einen Fehler gemacht haben, könnten wir auch unsere Backup-Plattform auĂer Betrieb setzen und die Daten auf beiden Plattformen verlieren â das wĂ€re wirklich traurig.
Beispiel Nummer fĂŒnf, völliger Hardcore.
Ein internationaler Service mit Hunderten von Millionen Nutzern weltweit. Alle Zeitzonen, die es gibt, Highload auf maximalem Niveau â Ausfallzeiten sind einfach keine Option. Eine Minute und schon ist die Stimmung im Keller. Was tun? Volle Reservierung ist die Antwort. Wir haben alles umgesetzt, was im vorherigen Beispiel angesprochen wurde, und sogar noch ein bisschen mehr. Eine ideale Welt, und unsere Infrastruktur entspricht in allen Aspekten dem DevOps-Prinzip IaaC. Das bedeutet, alles ist in Git und man muss nur den Knopf drĂŒcken.
Was fehlt? Nur eines â Schulungen. Ohne die geht es nicht. Es scheint, als wĂ€re alles perfekt bei uns, wir haben wirklich alles im Griff. Wir drĂŒcken den Knopf, alles geschieht. Selbst wenn es so wĂ€re â was wir verstehen, dass es so nicht ist â interagiert unser System mit anderen Systemen. Zum Beispiel DNS von Route 53, S3-Speicher, Integration mit verschiedenen APIs. Alles in diesem theoretischen Experiment vorherzusehen, ist unmöglich. Und solange wir den Schalter nicht bewusst umlegen, werden wir nicht wissen, ob es funktioniert oder nicht.
Das wĂ€re es wahrscheinlich. Seien Sie nicht nachlĂ€ssig, aber ĂŒbertreiben Sie es auch nicht. Möge die VerfĂŒgbarkeit mit Ihnen sein!
Quelle: habr.com
