ÐндÑей ЯланÑкий -
So setzen Sie erfolgreiches Disaster Recovery für Docker um
Eine erfolgreiche Disaster-Recovery-Strategie für Docker muss eine Reihe von Faktoren berücksichtigen, darunter die Host-Infrastruktur, Netzwerke und Redundanz in der Cloud.
Eine der am meisten angepriesenen Funktionen von Docker ist die sofortige Erstellung und Löschung von Containern. Wenn ein Container gelöscht ist, kann ein neuer Container ihn sofort ersetzen.
Dieses einfache „Rein und Raus“ vermittelt jedoch ein falsches Gefühl von Sicherheit, wenn es um die Einrichtung und Verwendung einer Docker-Disaster-Recovery-Umgebung geht.
Docker-Images lassen sich zwar schnell bereitstellen, aber wie bei den meisten anderen Technologien sind die zugrunde liegenden Hosts eng mit anderen Infrastrukturkomponenten verflochten. Es gibt einige Herausforderungen, die Administratoren bei der Verwendung von Docker in einem Disaster-Recovery-Szenario berücksichtigen müssen.
Zu den wichtigsten Überlegungen gehören:
1. Die Host-Infrastruktur
Jeder Docker-Container muss auf einem Host laufen. Die Entwickler müssen sicherstellen, dass sie schnell einen Ersatz-Host aufsetzen können. Diese Hosts müssen sehr spezifische, standardisierte Builds haben, um Konsistenz zu gewährleisten. Ein Disaster-Recovery-Szenario ist nicht ideal für ungetestete Konfigurationen, da diese exakt sein müssen. Die Reduzierung der Ausfallzeit in einem Störfall ist entscheidend, daher ist es nicht der richtige Zeitpunkt, um zu riskieren, dass eine Konfiguration nicht stimmt.
2. Die zustandsfähigen (stateful) Server
Docker-Container sind leicht zu ersetzen, aber die Daten, die sich auf den nicht-Docker-persistenten VM-Servern befinden, müssen bei einem Disaster Recovery verfügbar sein. Die Datenbankserver müssen zusammen mit anderen Elementen wie Load Balancern, Middleware-Systemen und Authentifizierungsservern jederzeit verfügbar sein. Administratoren müssen diese Elemente in einen Notfallwiederherstellungsplan (Disaster-Recovery-Plan, DRP) aufnehmen und berücksichtigen.
3. Netzwerkbetrieb
Netzwerke sind kritisch und können im Katastrophenfall ein Albtraum sein. Unternehmensnetzwerkdiagramme sollten die Abhängigkeiten der organisatorischen Aktivitäten zeigen, aber diese in einem DR-Szenario neu zu erstellen, in dem Zeit Geld ist, ist ein schlechter Prozess. Führen Sie alle Docker-Disaster-Recovery-Konfigurationen und -Tests im Vorfeld durch.
4. Korrekt konfigurierter VPN-Zugang
Selbst wenn die Ersatzinfrastruktur zeitnah hochgefahren werden könnte, könnte der Zugriff auf diese neue Infrastruktur problematisch sein. Wenn ein Unternehmen beispielsweise über ein Site-to-Site-VPN auf seine Anwendung zugreift, müsste es alles neu konfigurieren, um den Zugriff zu ermöglichen und Firewall-Probleme wie das Aussperren der falschen Leute zu vermeiden.
Wie man DR-Fallen bei Docker vermeidet
Docker-Disaster-Recovery-Probleme treten in verschiedenen Formen auf. Eine Methode zur Abschwächung dieser besteht darin, Geo-Redundanz in das gesamte Cloud-Design einzubauen.
Wenn ein Unternehmen am Anfang seiner Docker- und Cloud-Design-Planung steht, sollte es sicherstellen, dass die Anwendung über mehrere Public Cloud-Regionen verteilt ist, unabhängig vom Anbieter.
Auf diese Weise sind die Ressourcen immer noch verfügbar, falls ein Standort unerreichbar wird. Obwohl eine Geo-Replikationsstrategie kostspieliger sein kann, reduziert diese Best Practice die Ausfallzeiten. In einem DR-Plan muss festgehalten werden, wie viel Ausfallzeit das Unternehmen verkraften kann und welche Kunden in ihren Service Level Agreements hohe Strafen für Ausfallzeiten vorsehen.
Für diejenigen, die keine Geo-redundante Cloud haben, können die meisten Anbieter ein In-Cloud-DR-Failover anbieten.
Für Unternehmen und Entwickler, die Docker in einer hybriden oder privaten Cloud verwenden, kann das Problem komplexer sein, ist aber nicht unüberwindbar. Ein gut dokumentiertes Netzwerkdiagramm und ein DR-Plan helfen hier.
Wenn es sich um eine virtuelle Umgebung handelt, können Administratoren die Anwendung, die Docker-Hosts, die Datenbanken, die Auditing-Server und die Authentifizierungssteuerung in einem Gruppen-Failover wiederherstellen beziehungsweise wieder anlaufen lassen. Private und hybride Cloud-Umgebungen erfordern, dass die Organisation alle Failover-Details im Voraus einrichtet. Es mag suboptimal klingen, aber wenn der Administrator ein Failover der Anwendung durchführen muss, sind kritische Daten wie die IP, das virtuelle LAN und Routing-Informationen vorhanden und einsatzbereit.
DR-Administratoren müssen diese Setups konsequent und zeitnah testen, um Folgendes sicherzustellen:
- alle erforderlichen Ressourcen sind in der abzusichernden Gruppe enthalten
- die Anwendung funktioniert wie erwartet und es wurden keine falschen Einstellungen in der Failover-Konfiguration vorgenommen
- der Zugriff der Benutzerbasis auf die Anwendung und der Zugriff der Anwendung auf Drittanbieter funktioniert und ist zugänglich
Halten Sie Entwickler auf dem aktuellen Wissensstand
Viele Entwickler haben mit der Infrastruktur nichts zu tun. Sie werden dafür bezahlt, zu programmieren. Diese Denkweise kann jedoch nach hinten losgehen. Aus diesem Grund ist die Schulung von Entwicklern entscheidend.
Helfen Sie den Entwicklern, die Backend-Infrastruktur zu verstehen, damit sie wissen, wie und wo kritische Probleme auftreten werden. Zeigen Sie ihnen, wie sie mit den Administratoren zusammenarbeiten können, um die Probleme zu minimieren, die im Falle einer Katastrophe auftreten können. Befähigen Sie sie außerdem, Code zu schreiben, um zukünftige Disaster-Recovery-Szenarien zu vereinfachen.
