Zu argumentieren, dass die Site immer zugänglich sein sollte, ist schlechtes Benehmen und Banalität, aber eine 100% ige Zugänglichkeit ist, obwohl dies eine Voraussetzung ist, meistens immer noch ein unzugängliches Ideal. Mittlerweile gibt es viele Lösungen auf dem Markt, die eine maximale Verfügbarkeit versprechen oder Lösungen zur Erhöhung der Verfügbarkeit anbieten. Ihre Anwendung ist jedoch nicht nur nicht immer hilfreich, sondern kann in einigen Fällen sogar zu erhöhten Risiken und einer verringerten Projektzugänglichkeit führen. In diesem Artikel gehen wir auf die klassischen Fehler ein, auf die wir ständig stoßen. Die meisten Probleme sind elementar, aber die Leute erlauben sie immer wieder.
Notwendiges Vorwort: Bevor Sie versuchen, die maximale Verfügbarkeit des Projekts sicherzustellen, sollten Sie die Kosten und die Kosten für Ausfallzeiten in Beziehung setzen. In der Regel ist dies sehr wichtig für Unternehmen, deren Arbeit von der Arbeit anderer Unternehmen abhängt - B2B-Lösungen, API-Services, Lieferservices. Die Unzugänglichkeit von nur wenigen Minuten führt zumindest dazu, dass unzufriedene Kunden das Callcenter belasten. Für Unternehmen eines anderen Typs, z. B. einen kleinen Online-Shop oder ein Unternehmen, dessen Kunden von 9 bis 18 arbeiten, kann die Unzugänglichkeit selbst für mehrere Stunden günstiger sein als eine vollständige Sicherungssite.
1. Lokalisierung des gesamten Projekts in einem Rechenzentrum / einer Zone des Cloud-Hostings
Cloud-Hosting-Marketing hat das falsche Konzept in den Köpfen der Menschen fest verankert: Cloud-Hosting ist nicht an Hardware gebunden, und dies bedeutet, dass die Cloud-Infrastruktur nicht ausfällt. Drei 24-Stunden-Abstürze von Amazon Web Services, der jüngste Absturz von cloud4y und der Datenverlust von cloudmouse haben gezeigt, dass die Lokalisierung der Daten und des Projekts selbst in einem Rechenzentrum eine garantierte Möglichkeit darstellt, viele Stunden Ausfallzeit zu erzielen, ohne das Projekt problemlos auf einen anderen Standort übertragen zu können. Das diesbezügliche Gesetz über personenbezogene Daten schafft zusätzliche Probleme. Wir glauben, dass jedes Cloud-Hosting mehrere schwere Unfälle erleiden sollte, um zu lernen, wie man sie verhindert (Blitzschlag, der Amazon getroffen hat, Netzwerkkonfigurationsprobleme im Zusammenhang mit dem menschlichen Faktor usw.), und wenn das westliche Cloud-Hosting diese Reihe von Katastrophen durchgemacht hat, dann müssen viele russische Standorte dies noch tun, und dies muss berücksichtigt werden.
Bei den „eisernen“ Rechenzentren ist die Situation ungefähr dieselbe. Oft sehen wir die Client-Konfiguration, bei der mehrere Server an einem Standort reserviert sind. Falls einer von ihnen ausfällt, treten nach unserer Erfahrung Netzwerkprobleme auf, wenn auf mehrere Racks in einem Rechenzentrum oder auf das gesamte Rechenzentrum insgesamt nicht mehr zugegriffen werden kann treten viel häufiger auf als Abstürze einzelner Server, und dies muss ebenfalls berücksichtigt werden.
Der von AWS empfohlene Projektworkflow umfasst die Verwendung mehrerer Standardverfügbarkeitszonen, um eine maximale Projektverfügbarkeit zu erzielen.
2. Keine ausreichende Vervielfältigung am Reservestandort
Wir kamen also zu dem banalen Schluss, dass ein Backup-Standort erforderlich ist, um die maximale Verfügbarkeit des Projekts zu erreichen. Um jedoch darauf umsteigen zu können, müssen die Daten dem Produktionsstandort entsprechen. Wichtig ist hier nicht die erstmalige Erstellung der Reserve - dies ist ein recht einfaches und verständliches Verfahren, die Synchronisation und Überwachung der Synchronisation weiterer Änderungen ist viel wichtiger. Zunächst sprechen wir über:
- Clusterkonfiguration / Datensynchronisation im Cluster, wenn es sich um eine komplexe Site handelt
- Dateistruktur-Synchronisation und Überwachung der Synchronisationsverzögerung
- Verfolgen Sie Änderungen in der Serverkonfiguration
- Debugging-Prozesse zum Überwachen und Hinzufügen der Synchronisierung neuer Projekte / Dienste auf der Site.
- Verfolgung des Hinzufügens neuer sekundärer Dienste (neue Warteschlangen, Verarbeitungsmechanismen und Interaktionen usw.).
- Angemessene fortlaufende Überwachung all dieser Prozesse.
3. Fehlen eines Switching-Plans und regelmäßiger Wechsel zu einem Backup-Standort
Selbst die beste Überwachung kann nicht garantieren, dass die Sicherungssite bereit ist, zu wechseln, wenn sie wirklich benötigt wird. Nach unserer Erfahrung wird es beim ersten Wechsel in die Reserve zu einem Unfall kommen, der sich noch mehrmals ereignet. In ihren Berichten sagt Stack Overflow, dass sie ungefähr fünf Umstellungen in die Reserve benötigten, bevor sie davon überzeugt waren, dass sie nun nach dem Unfall vollständig bereit waren, den Verkehr aufzunehmen. Daher ist es im Arbeitsplan zur Erhöhung der Betriebszeit des Projekts erforderlich, Testschalter in die Reserve aufzunehmen und zu berücksichtigen, dass solche Schalter zu einem Unfall führen. Nachdem Sie den Schaltmechanismus in der Dokumentation ausgearbeitet und repariert haben, müssen Sie weiterhin regelmäßig in die Reserve wechseln, um sicherzustellen, dass alles noch funktioniert.
4. Lokalisierung des Reservestandorts auf demselben Kanal / in derselben Region der Cloud
Wenn sich die Produktions- und Reserveseiten innerhalb desselben Hosting-Unternehmens befinden, ist es durchaus möglich, dass im Falle eines Unfalls beide Standorte sofort nicht mehr funktionieren. Mehrere schwere Unfälle in AWS betrafen sofort alle Verfügbarkeitszonen einer Region. Selectel fiel gleichzeitig mit Rechenzentren in St. Petersburg und Moskau. Unternehmen können von einer vollständigen Isolation sprechen. Der Cloud4y-Unfall, der zu einer vollständigen Unzugänglichkeit von Bitrix24 führte, lässt jedoch darauf schließen, dass dies auch in solchen Fällen der Fall ist Es gibt große Risiken. Aus unserer Sicht ist das Ideal eine Konfiguration, bei der sich eine Sicherungskonfiguration in demselben Hosting-Unternehmen befindet (um regelmäßig auf eine Reserve wie VRRP umzuschalten ), und eine sekundäre Sicherungsplattform in einem anderen Hosting-Unternehmen.
5. Platzierung identischer Versionen auf den Haupt- und Reserveseiten.
Selbst die Verwendung eines verifizierten Reservestandorts und die Verwendung eines sekundären Standorts in einem anderen Rechenzentrum garantiert nicht die Bereitschaft des Reservats, die Produktionslast schnell zu übernehmen. Dies ist auf das Wesentliche der Redundanz zurückzuführen: Eine neue Version des Codes, die eine schwerwiegende Last in der Produktionsumgebung verursacht hat, erzeugt genau dieselbe Last auf dem Sicherungsstandort, und auf das Projekt kann nicht mehr zugegriffen werden. Als einfache Lösung sollte es einen Mechanismus für das Zurücksetzen auf die vorherige Version geben. Im Geschäftswettlauf um Releases ist dies jedoch nicht immer möglich, und dann beginnen wir, über eine andere Sicherungssite mit der vorherigen Version nachzudenken. Wir sollten auch über Sicherungen sprechen: Das versehentliche Löschen von Daten auf der Hauptwebsite wirkt sich auch auf die Sicherungswebsite aus. Sie sollten daher über eine verzögerte Replikation (15 Minuten pro Stunde) nachdenken, um zu einer Datenbank wechseln zu können, die noch nicht stattgefunden hat tödliche Operation.
6. Abhängigkeit von externen Diensten, auf die das Projekt zugreift.
Das reicht aber nicht. Eine große Anzahl von Projekten nutzt jetzt externe Dienste, um ihre eigenen Dienste bereitzustellen. Die meisten Benutzer verwenden SMS zur doppelten Authentifizierung, Online-Shops berechnen die Lieferzeiten mithilfe von Lieferservices, Zahlungen werden über Zahlungsgateways von Drittanbietern akzeptiert. Wenn diese Services ausfallen, spielt es keine Rolle, ob eine Reservierung vorliegt oder nicht, das Projekt ist weiterhin nicht verfügbar. Wir sehen selten die Reservierung externer Dienste, aber in der Zwischenzeit sind dies genau dieselben Projekte, die Probleme mit dem Reservestandort haben können, oder es gibt möglicherweise überhaupt keine Reserve. Und wenn der externe Service nicht verfügbar ist, ist auch eine Wartung Ihrer Kunden nicht möglich. Wir empfehlen, dass Sie alle kritischen externen Systeme duplizieren, ihre Verfügbarkeit überwachen und planen, sie im Falle eines Unfalls zu wechseln.
Dies ist bei weitem nicht alles, aber zumindest grundlegende Dinge. Wir besprechen dies ausführlicher auf den Treffen von uptime.community . Das nächste Treffen findet im Oktober statt. Sie können jedoch vorerst in der Telegrammgruppe chatten.