In diesem Artikel möchte ich zeigen, wie einfach und kostenlos Sie ein Failover-Schema für eine Website (oder jeden anderen Internetdienst) mit einer Kombination aus Überwachung und einem dynamischen DNS-Dienst erstellen können. Das bedeutet, dass im Falle von Problemen mit der Hauptwebsite (von "PHP-Fehler" auf der Seite bis hin zu unzureichendem Speicherplatz oder einem auffällig geringen Bestellvolumen in einem Online-Shop) neue Besucher an einen zweiten (dritten usw.) funktionierenden Server oder auf eine "Entschuldigung"-Seite geleitet werden, auf der ihnen höflich erklärt wird, dass "es ein Problem gibt, wir sind bereits informiert und arbeiten daran, es bald zu beheben" (und Sie werden in der Tat bereits informiert sein und das Problem beheben können).
Mit oder ohne Failover leben?
Bis ein Problem auftritt, gibt es keinen wesentlichen Unterschied. Aber wenn es dazu kommt, passiert ohne Failover oft Folgendes: Sie versuchen schnell herauszufinden, wo das Problem liegt, aber es klappt nicht (Backups lassen sich nicht wiederherstellen, Software funktioniert aus unerfindlichen Gründen nicht wie in der Dokumentation beschrieben usw.), und die Zeit drängt. Server und Websites sind down, Kunden rufen an, alle sind nervös, und Sie versuchen, irgendwie grob und improvisiert „mit dem letzten Notbehelf“ etwas zu reparieren. Irgendwann scheint es mit einer notdürftigen Lösung wieder zu laufen. Sie denken, dass Sie sich irgendwann um eine saubere Lösung kümmern sollten, aber es gibt nichts Dauerhafteres als eine vorübergehende Lösung.
Jetzt sehen wir, wie es elegant mit einem Failover funktioniert:
- Ein Fehler tritt auf
- Der Fehler wird automatisch erkannt
- Es wird eine Benachrichtigung gesendet
- Der Wechsel zu einem der Backup-Server erfolgt
- Das Problem wird ruhig und ohne Panik analysiert, behoben und der Server wird wieder in Betrieb genommen.
In diesem Schema können natürlich auch einige Schwierigkeiten auftreten, dennoch ist die Struktur linear, jeder Schritt ist einfach und vor allem — er kann separat optimiert werden. Daher ist die Wahrscheinlichkeit eines Ausfalls bei diesem Schema viel geringer, und alle Aktionen können automatisiert und schnell ausgeführt werden (im Gegensatz zur Herausforderung, eine unbekannte epische Störung zu finden und zu beheben). Ihr Flugzeug ist in einem fernen Land gelandet, Sie schalten Ihr Telefon ein und sehen in Telegram eine Benachrichtigung, dass der Server ausgefallen ist, aber alles ist gut, der Backup-Server wurde aktiviert, Sie können Ihre Reise fortsetzen, Sie müssen nicht zurückfliegen oder über SSH aus dem nächsten Café mit WLAN reparieren. Sie können sich später darum kümmern, wenn es Ihnen passt.
Die Zukunft ist bereits hier!
Früher war das Hauptproblem, das Failover oft als unakzeptable Lösung erscheinen ließ, die hohen Kosten. Man musste entweder teure Hardware kaufen (und noch teurere Spezialisten anheuern) oder etwas Komplexes anhand von Anleitungen zusammenbasteln. Ich habe sogar eine Variante gesehen, bei der zwei Server mit einem Nullmodemkabel verbunden wurden, um über dieses Kabel einen Heartbeat zu senden, damit der Backup-Server im richtigen Moment das Management übernehmen kann. Heutzutage gibt es einfachere und kostenlose Möglichkeiten. Wenn Sie eine Website mit Katzen haben, gibt es keinen Grund mehr, das Failover noch nicht implementiert zu haben!
Außerdem benötigt man für das Failover-Schema auch einen weiteren Server (oder vielleicht sogar mehrere), was früher hohe Kosten verursachte. Heute kann man jedoch einen VDS zu einem günstigen Preis bekommen.
Die zuverlässigste Website mit Katzen
Zur praktischen Veranschaulichung der Lösung mit okerr + dynamic dns haben wir unsere eigene Website mit Katzen gestartet. . Wir haben eine Abneigung gegen Kätzchen, daher sind sie hier kaum zu finden. Es gibt insgesamt drei Websites, die alle ziemlich ähnlich aussehen (alle basieren auf demselben Template), aber mit verschiedenen Kätzchen, um sie leicht zu unterscheiden. Jede Seite bietet technische Informationen, um zu zeigen, wie der Failover funktioniert. Die Seite aktualisiert sich selbst alle 1 Minute, aber man kann immer im Browser auf 'Neu laden' klicken.
In den technischen Informationen gibt es die Zeile „status=OK“. Manchmal simulieren die Server Probleme und zeigen „status=ERR“ an. Der Hauptserver „fällt“ zur vollen Stunde alle 20 Minuten aus (0:20, 1:20, 2:20, …). Der Backup-Server ist zur vollen Stunde alle 40 Minuten betroffen. Der letzte Server (der „sorry“-Server) ist immer aktiv. Zur vollen Stunde „startet“ der Haupt- und der Backup-Server neu.
Wenn Sie eine Website öffnen und sie im Tab lassen, werden Sie feststellen, dass sie niemals ausfällt (obwohl jeder einzelne Server gelegentlich eine Problematik simuliert). Im Fall eines Serverproblems wechselt die Verbindung einfach zwischen den aktiven Servern. Das Bild, der Name, die Adresse des Servers und die Rolle werden dabei geändert. Manchmal kann man den Moment abpassen, in dem status=ERR (das Problem ist bereits vorhanden, aber das gesamte Failover-Schema hat noch nicht funktioniert), jedoch zeigt Ihnen das nächste Update bereits die Seite von einem funktionierenden Server.
Failover bei okerr + dynamisches DNS
Schauen wir uns an, wie das unter der Haube funktioniert. Die Aufgabe des Failovers besteht darin, dass die Adresse cat.okerr.com immer auf die IP-Adresse des funktionierenden Servers verweist.
Hinter jedem der Server, die unsere Katzenwebsite bei okerr hosten, gibt es einen Indikator, der einmal pro Minute seinen Zustand überprüft.
Auf diesem Screenshot sehen wir, wie die Website cat.okerr.com vom Server alpha.okerr.com überprüft wird. Die Seite sollte den Status = OK enthalten, und wie wir oben sehen, ist der Statusindikator derzeit OK. Wenn der Server ausfällt, zeigt er ERR an. (Dies ist nur ein Beispiel für einen Indikator, Okerer ist ein Monitoring-Tool, daher können verschiedene Indikatortypen verwendet werden, z. B. die Überprüfung des verfügbaren Speicherplatzes auf der Festplatte, die Anzahl neuer Bestellungen in der Datenbank und sogar logische Indikatoren, wie nachts andere Fehlerkriterien als tagsüber).
In den Projekteinstellungen haben wir ein Failover-Schema mit diesen Indikatoren erstellt:
Im Schema sind drei Indikatoren (drei Server) mit unterschiedlichen Prioritäten. Der Hauptserver für die Website ist charlie; wenn dieser nicht funktioniert (kein “status=OK” oder einfach nicht erreichbar ist), wechselt es zu bravo und im letzten Fall zu alpha. Auf der rechten Seite der Seite wird der Status des DNS-Eintrags auf verschiedenen Servern angezeigt.
Für diejenigen, die bemerkt haben, dass der Name cat.he.okerr.com verwendet wird: Wir verwenden ein etwas komplexeres Schema. Anstatt einfach den DNS-Eintrag für cat.okerr.com zu ändern, ändern wir cat.he.okerr.com (bei einem Dynamic DNS-Anbieter) ), cat.okerr.com ist ein CNAME (Alias), der unverändert bleibt und stets auf cat.he.okerr.com verweist. Wir bevorzugen Hurricane als dynamischen DNS, da es Schlüssel zur Verwaltung von einzelnen Einträgen (anstatt der gesamten Zone) hat, was uns sicherer erscheint. Sie können auch keine Passwort-Schlüssel in okerr für die Verwaltung der gesamten Domain angeben, sondern nur für den Subdomain oder Eintrag.
Vom Fall zum Aufstieg
In Schritten, wie dieses Schema funktioniert:
- Ein Problem tritt (wird simuliert) auf dem Server auf.
- Der okerr-Sensor überprüft einmal pro Minute den Zustand jedes Servers und berichtet an den Hauptserver des Projekts in okerr.
- Der Indikator des entsprechenden Servers ändert seinen Status von OK auf ERR.
- Bei einer Statusänderung des Indikators wird das Failover neu berechnet, und es wird ermittelt, welche Adresse festgelegt werden muss (wenn nötig. Zum Beispiel, wenn der Hauptserver läuft und gleichzeitig der Backup-Server ausfällt – es werden keine Änderungen vorgenommen).
- Diese Adresse wird dem dynamischen DNS-Dienst mitgeteilt. Nach Abschluss dieses Schrittes sehen Sie rechts den Status „synced“.
- Sehr bald (in Sekunden) wird der Eintrag die DNS-Server Ihrer Domain erreichen (bei cotosite sind das ns1-ns5.he.net).
- Ab diesem Zeitpunkt werden einige Benutzer bereits auf den neuen Live-Server zugreifen. Allerdings haben noch nicht alle DNS-Server weltweit die Einträge aktualisiert, und in einigen Fällen könnte der alte Eintrag noch im Cache sein. Man kann beobachten, wie die Daten auf öffentlichen DNS-Servern „hüpfen“, indem sie abwechselnd den neuen und den alten Wert anzeigen. Wenn man die Failover-Einstellungsseite aktualisiert, wird der Server selbst neue Daten von den DNS-Servern anfordern.
- Sobald sich die Daten stabilisiert haben und der alte gecachte Eintrag überall abgelaufen ist, gehen 100 % der Anfragen an den neuen Server.
Um Schritt 7 (der oft der längste ist) zu beschleunigen, sollte die TTL des dynamischen DNS-Eintrags so niedrig wie möglich eingestellt werden. In der Regel erlauben Dienste Intervalle von 90 bis 120 Sekunden. Das ist ein durchaus vernünftiger Kompromiss.
Zusätzlich
All dies lässt sich am Abend einrichten (wenn Sie bereits einen Spiegelserver haben). Sowohl okerr als auch die dynamischen DNS-Dienste sind kostenlos. Um mehr Prüfungen und kürzere Prüfintervalle in okerr zu erhalten, ist eine Schulung erforderlich (über die Profilseite). Nach Abschluss wird sofort das Level erhöht (20 Indikatoren pro Stunde + 1 schneller, 10-minütiger). Sollte das nicht ausreichen, schreiben Sie an support@okerr.com, wahrscheinlich kann das erhöht werden (bisher gab es immer die Möglichkeit, und ich habe nie eine Ablehnung erfahren; im Gegenteil, ich habe selbst angeboten). Ich möchte nur nicht versprechen, dass ich alles für alle liefern kann, da ich mir nicht sicher bin, ob die Kapazitäten ausreichen, um es umzusetzen. Aber im Moment gibt es wenig Nutzer, sodass es keine Probleme bei der Erhöhung der Limits gibt.
Was kann okerr überhaupt — schauen Sie auf der Website nach . Es handelt sich um ein Monitoring (zabbix aus der Cloud), und der Fileserver ist eine angenehme Zusatzfunktion. Außerdem kann man ohne Registrierung auf der Website in die Demo eintauchen.
Bei einer Änderung des Statusindikators wird eine Benachrichtigung per E-Mail oder Telegram gesendet. (Wir haben beobachtet, was passiert, und festgestellt, dass Telegram anscheinend der zuverlässigste Messenger ist. Danke, RKN, für den Stresstest!) Bei richtiger Konfiguration von okerr ist jede Benachrichtigung ein Signal: „Alles liegen lassen, wir müssen reparieren!“ oder „Alles in Ordnung!“. Es sollten keine zusätzlichen Alarme von okerr eingehen (wenn doch, muss die Konfiguration anders eingestellt werden). Zum Beispiel simuliert unser Kotosite-Server Alpha nie einen Fehler. Wenn er ausfällt, müssen wir informiert werden. Die restlichen Server simulieren jedoch ständig Fehler, weshalb die Indikatoren mit dem Status „leise“ versehen sind, damit wir nicht mehrere Alarme pro Stunde erhalten.
Es macht auch Sinn, einen Sorry-Server einzurichten (bei einem beliebig günstigen Hosting-Anbieter), der entweder Ihre Entschuldigungseite enthält (für den Fall, dass alle Haupt- und Backup-Server ausfallen) oder auf die Statusseite von okerr umleitet (wie zum Beispiel unsere ) oder statuspage.io.
Quelle: habr.com
