Es gibt ein kleines Rechenzentrum in der Nähe einer Produktionsfirma in einer kleinen Stadt ziemlich weit von Moskau entfernt. Er wird rund um die Uhr gebraucht. Es ist also passiert, dass es nur einen Eingang vom Netz gibt, aber keinen Dieselgenerator. Da es sich bei dem Unternehmen nicht um eine IT-Firma handelt, sondern um eine Produktionsfirma, haben sie einmal nicht richtig entworfen. Denn sobald alles geklappt hat.
Der Power Ray begann Streiche zu spielen. Jede Woche wurde das Licht für mehrere Stunden und in einer Lotterie abgeschaltet: Sie könnten für eine Stunde sein oder sie könnten mehr sein. Es gibt keine Muster.
Der Administrator schlug vor, einen Diesel zu kaufen, aber das Unternehmen sagte, dass dies kein Verwaltungsgeschäft sei. Seine Aufgabe ist es, Ausfallzeiten von nicht mehr als einer Stunde bereitzustellen. Sie haben nur viel Geld in die Geräte gesteckt, sodass Sie nicht in die Cloud wechseln können, und es gibt keine kommerziellen Rechenzentren, in denen die Geräte dorthin transportiert werden können.
Und was machen?
Mit dieser Aufgabe kam der Kunde zu uns. Es gibt nicht viel Budget, Sie müssen nach einer gültigen Lösung suchen.
Der Normalfall (mit Ausnahme des Auftretens des zweiten Eingangs, der Übertragung von Geräten oder des Auftretens eines Dieselgenerators) besteht darin, die zweite genau dieselbe Instanz in der Cloud bereitzustellen und zu ihr zu wechseln, wenn plötzlich etwas herunterfällt. Es heißt Disaster Recovery. Einige Leute bauen ein zweites Rechenzentrum für sich selbst, es ist kalt und wartet darauf, dass das Hauptzentrum fällt, oder es arbeitet im Aktiv-Aktiv-Modus und nimmt 50% der Last auf.
Für ein zweites volles Rechenzentrum gibt es jedoch kein Geld.
Sie kamen mit diesem:
Im Rechenzentrum des Clients befindet sich ein schwerer physischer Server mit einer Datenbank. Und es gibt Anwendungen, die mit dieser Datenbank arbeiten. Dabei handelt es sich um eine Reihe virtueller Maschinen unter ESXi.
Um die Datenbank zu replizieren, installierten sie die Carbonite Availability-Software (früher als Double-Take Availability bekannt) in der Cloud, die auf Betriebssystemebene funktioniert. Für die Replikation der von Zerto installierten virtuellen Maschinen funktioniert diese Software auf Hypervisor-Ebene. Beide Lösungen funktionieren ungefähr auf die gleiche Weise: Zuerst replizieren sie das gesamte Serverdatenvolumen in die Cloud, fangen dann alle Datensätze auf Datenträgern am Hauptstandort ab und duplizieren sie auf Datenträgern in der Cloud. Die Verzögerung beträgt in diesem Fall speziell 10 Sekunden, dh wir haben immer eine neue Kopie der Daten vor 10 Sekunden.
Virtuelle Maschinen sind nicht enthalten. Über die Schaltfläche in der Zerto-Systemsteuerung können wir alle VMs gleichzeitig starten. Dies geschieht innerhalb von ca. 28 Minuten (die Maschinen starten parallel), SLA für 1 Stunde bei uns im Leerlauf. Der Start erfolgt durch Anruf beim Duty Administrator. Der Kunde entscheidet, wann es gebraucht wird.
VMs nehmen die Basis auf und beginnen zu arbeiten.
Wenn die Anlage eingeschaltet wird, versteht der Kunde selbst seine Infrastruktur. Behandelt Ausfälle und aktiviert dann manuell die umgekehrte Replikation. Die Anzahl der Änderungen in der Datenbank, die während des Betriebs der Anwendungen gesammelt wurden, wird zurückgesendet. Repliziert - Schalter. In diesem speziellen Beispiel wird der Datenverkehr für jede Stunde virtueller Maschinen etwa 5 Minuten lang neu geladen. Je länger die Betriebszeit der Notfallinstanz ist, desto geringer ist der Verkehrsanteil, da die Datensätze häufig in dieselben Datenbanktabellen verschoben werden und nur die Differenz gesendet wird.
Nach dem Zurückschalten in die Cloud werden virtuelle Maschinen heruntergefahren. Der Kunde zahlt nicht für ausgeschaltete Ressourcen. Wir quantisieren nach der Uhr.
Die Zahlung erfolgt nur für die Menge der gespeicherten Daten, den Kanal und die Softwarelizenz für die Replikation (Zerto und Carbonite). Wir arbeiten nach dem Prinzip "Disaster Recovery as a Service", geben Sie dafür SLA. Und finanziell verantwortlich für diese SLA.
Der Kunde repliziert alles, eine virtuelle Maschine mit den gleichen Parametern wie ihre Physik, alle Festplatten werden gespiegelt.
Dies macht Zerto:
Es verfügt über eine agentenlose Replikation, einen asynchronen Modus, VMs auf der DR-Plattform, Journalreplikation, WAN-Optimierung, hypervisorübergreifende Replikation und Lizenzierung für geschützte virtuelle Maschinen.
Carbonite ist eine Agentenreplikation. Unabhängig vom Hypervisor gibt es einen asynchronen Betriebsmodus, Unterstützung für Snapshots, Komprimierung der übertragenen Daten und Lizenzierung für geschützte virtuelle Maschinen.
Bei der Installation wurden beide Lösungen gleichzeitig angewendet. Es war also wegen einer Reihe von Funktionen notwendig. Normalerweise bieten sie eine Sache an.
Sie können ein ähnliches Problem auch mit der inländischen Veeam Cloud Connect-Lösung lösen (wir verwenden sie normalerweise, wenn Sie bereits über ein Veeam-Backup verfügen).
Zusammenfassung
Wir alle wissen, dass das Problem anders gelöst werden kann, wenn die serverseitige Installation eines Dieselgenerators gepumpt wird. Das Unternehmen senkte jedoch die Anforderungen an die Organisation der Reserve. Wir haben einen Service angeboten und es hat funktioniert. Es stellte sich als gutes Beispiel dafür heraus, wie Sie eine DR-Plattform korrekt und kostengünstig bereitstellen können.
Referenzen