So schalten Sie das Licht in einem kleinen Rechenzentrum aus: eine kostengünstige Möglichkeit für den Notfalleinsatz



    Es gibt ein kleines Rechenzentrum in der Nähe einer Produktionsfirma in einer kleinen Stadt, nicht weit von Moskau entfernt. Er brauchte rund um die Uhr. Es ist also vorgekommen, dass es nur einen Eingang aus dem Netz gibt, aber kein Dieselaggregat. Da es sich bei dem Unternehmen nicht um ein IT-Unternehmen, sondern um ein Produktionsunternehmen handelt, haben sie es einmal nicht richtig entworfen. Denn einst hat alles geklappt.

    Der Leistungsstrahl begann sich schlecht zu benehmen. Jede Woche wurden die Lichter für mehrere Stunden ausgeschaltet, und zwar auf eine Lotterie-Art: Sie hätten eine Stunde und mehr sein können. Es gibt keine Muster.

    Der Admin bot an, Diesel zu kaufen, aber das Geschäft sagte, es sei kein Admin-Fall. Seine Aufgabe ist es, eine einfache nicht mehr als eine Stunde bereitzustellen. Sie haben gerade viel Geld in die Ausrüstung gesteckt, so dass sie nicht in die Cloud gehen können, und es gibt keine kommerziellen Datenzentren in der Nähe, um dort Ausrüstung zu transportieren.

    Und was machen?


    Mit dieser Aufgabe kam der Kunde zu uns. Es gibt kein Budget, Sie müssen nach einer vorhandenen Lösung suchen.

    Der Normalfall (dies zählt nicht das Auftreten des zweiten Eingangs, die Übertragung von Ausrüstung oder das Auftreten eines Dieselgenerators) - setzen Sie den zweiten genau denselben Fall in der Cloud ein und wechseln Sie zu ihm, wenn plötzlich etwas fällt. Disaster Recovery genannt. Einige von ihnen bauen ein zweites Rechenzentrum, es ist kalt und wartet, bis das Hauptgebäude herunterfällt, oder es arbeitet im Aktiv-Aktiv-Modus und nimmt 50% der Last.

    Für das zweite vollständige Rechenzentrum gibt es kein Geld.

    Sie haben das erfunden:



    Im Rechenzentrum des Clients befindet sich ein starker physischer Server mit einer Datenbank. Und es gibt Anwendungen, die mit dieser Datenbank arbeiten, einer Gruppe virtueller Maschinen auf ESXi.

    Für die Replikation der Datenbank in die Cloud wurde Carbonite Availability (früher als Double-Take Availability bekannt) installiert, die auf Betriebssystemebene ausgeführt wird. Und für die Virtualok-Replikation wurde Zerto installiert. Diese Software arbeitet auf Hypervisor-Ebene. Beide Lösungen arbeiten auf dieselbe Weise: Zuerst replizieren sie die gesamte Serverdatenmenge in die Cloud, fangen dann alle Datensätze auf den Festplatten der Hauptplattform ab und duplizieren sie auf den Festplatten in der Cloud. Die Verzögerung beträgt speziell in diesem Fall 10 Sekunden, das heißt, wir haben immer eine frische Kopie von Daten, die 10 Sekunden alt sind.

    Virtuelle Maschinen sind nicht enthalten. Mit der Schaltfläche in der Zerto-Systemsteuerung können wir alle VMs gleichzeitig starten. Es dauert etwa 28 Minuten (die Maschinen starten parallel), die SLA ist 1 Stunde im Leerlauf. Der Start erfolgt durch Aufrufen des diensthabenden Administrators. Der Kunde entscheidet, wann er benötigt wird.

    VM hebt die Basis auf und fängt an zu arbeiten.

    Wenn der Strom in der Anlage eingeschaltet wird, versteht der Kunde seine Infrastruktur selbst. Zerstört Zusammenbrüche und aktiviert dann die umgekehrte Replikation manuell. Die Menge an Änderungen in der Datenbank, die sich während des Betriebs von Anwendungen angesammelt haben, wird zurückgesendet. Repliziert - geschaltet. In diesem speziellen Beispiel sammelt sich für jede Arbeitsstunde der virtuellen Maschinen der Verkehr für etwa 5 Minuten Nachladen an. Je länger die Arbeit der Notfallinstanz dauert, desto geringer ist der Verkehrsanteil, da die Datensätze häufig in denselben Datenbanktabellen gespeichert werden und wir nur den Unterschied senden.

    Nach dem Wechsel zur Cloud werden die virtuellen Maschinen ausgeschaltet. Der Kunde bezahlt nicht für deaktivierte Ressourcen. Wir haben stundenweise Quantisierung.

    Die Zahlung erfolgt nur für die Menge der gespeicherten Daten, den Kanal und die Lizenz für Replikationssoftware (Zerto und Carbonite). Wir arbeiten nach dem Prinzip „Disaster Recovery als Service“ und geben allen eine SLA. Und wir sind finanziell für dieses SLA verantwortlich.

    Der Kunde repliziert im Allgemeinen alles, eine virtuelle Maschine mit denselben Parametern wie ihre Physik, alle Festplatten werden gespiegelt.

    Dies ist, was Zero tut:



    Er verfügt über agentenlose Replikation, hat einen asynchronen Modus, VMs auf dem DR-Standort sind deaktiviert, Journalreplikation, WAN-Optimierung, hypervisorische Replikation, Lizenzierung mit geschützten virtuellen Maschinen.

    Carbonite ist eine Agentenreplikation. Unabhängig vom Hypervisor gibt es einen asynchronen Betriebsmodus, es werden Unterstützung für Momentaufnahmen, Komprimierung der übertragenen Daten und Lizenzierung mit geschützten virtuellen Maschinen unterstützt.

    Bei der Installation wurden beide Lösungen gleichzeitig angewendet. Dies war aufgrund einer Reihe von Funktionen erforderlich. Normalerweise bieten eine Sache.

    Sie können ein ähnliches Problem auch mit der inländischen Lösung Veeam Cloud Connect lösen (normalerweise verwenden wir sie, wenn Sie bereits eine Veeam-Sicherung haben).

    Das Ergebnis


    Wir alle verstehen, dass die Aufgabe anders gelöst werden kann, indem der Server durch die Installation eines Dieselgenerators gepumpt wird. Das Unternehmen hat jedoch die Anforderungen an die Organisation der Reserve gesenkt. Wir haben einen Service bereitgestellt und alles hat funktioniert. Es stellte sich als gutes Beispiel heraus, wie eine DR-Plattform korrekt und kostengünstig eingesetzt werden kann.

    Links



    Jetzt auch beliebt: