BrunoWeltmann - stock.adobe.com
Kostenkontrolle für virtuelles Disaster Recovery behalten
Die Einrichtung eines virtuellen Disaster-Recovery-Systems sollte nicht teuer sein, aber die Kosten können sich leicht summieren, wenn Anbieter nicht alle Ausgaben berücksichtigen.
Virtuelles Disaster Recovery ist ohne Zweifel ein großer Fortschritt für die Disaster-Recovery-as-a-Service-Welt (DRaaS). Wenn Anbieter die Disaster-Recovery-Ausgaben verwalten und kontrollieren, wissen Kunden, wie hoch ihre ungefähren Ausgaben sind, und können ein entsprechendes Budget aufstellen. Wenn das Disaster-Recovery-Setup jedoch ad hoc erstellt wird, kann es sehr schnell teuer werden.
Wenn eine virtuelle DRaaS-Infrastruktur zum ersten Mal eingerichtet wird, ist sie nicht nur für die Kunden und Endbenutzer, sondern auch für den Administrator neu. Hier machen die meisten Anbieter den ersten Fehler, wenn es um die Kosten der Disaster-Recovery-Installierung geht. Oftmals wird bei einem Proof-of-Concept-DR-Setup oder einem begrenzten Rollout die Verrechnung der tatsächlichen Kosten für den Service nicht angemessen berücksichtigt.
Während des anfänglichen Disaster-Recovery-Setups neigen die Beteiligten dazu, sich mehr um die Leistung, den Konzeptnachweis und den Nutzen als um den Preis zu kümmern, was keine gute Art ist, einen so kritischen Posten zu betrachten. Sobald ein Kunde eine Rechnung für die anfängliche Testphase hat, erwartet er, dass diese Kosten konsistent sind, da sie das von ihren Dienstleistern erwarten.
Achten Sie auf die Ressourcen
Nachdem ein Anbieter das virtuelle Disaster-Recovery-Setup erfolgreich ausgearbeitet hat, sind die Mitarbeiter, die das System einrichten und testen, oft nicht dieselben, die die Preise und Kosten festlegen. Was viele Administratoren vergessen, ist, dass während der anfänglichen Einrichtung die Elemente, die unter virtuelle DR gestellt werden, einfach umzusetzen sind und keine „normale“ Menge an Ressourcen verbrauchen.
Um ein Beispiel zu nennen: Ein Webserver oder ein einfacher Anwendungsserver verbraucht keine großen Mengen an Ressourcen, da die Änderungsrate relativ gering ist. Wenn jedoch jemand eine neue, komplexe virtuelle Maschine (VM) für einen Datenbankserver erstellt, kann die Änderungsrate potenziell astronomisch sein.
Wenn jeder geänderte Block über das WAN repliziert werden muss, kann dies zu unerwarteten Ressourcenproblemen in Bezug auf die DR-Bandbreite führen, aber auch dazu, dass die DR-Produktivseite nicht über die entsprechenden Ressourcen verfügt. Je mehr Blöcke ein Unternehmen replizieren muss, desto mehr Speicher und CPU wird benötigt, um diese Änderungen aktuell zu halten und zu speichern, bevor sie über das WAN versendet werden.
Dies wirkt sich auch auf eine andere Art und Weise auf das DR-Setup aus. Je mehr Festplattenblöcke sich ändern, desto größer muss der Journalverlauf sein, der alle Änderungen verfolgt. Ein Beispiel ist ein Fall, in dem die Journalgröße größer wird als die Größe der geschützten Produktiv-VM.
Vergessen Sie die Testkosten nicht
Es sind nicht nur die technischen Aspekte einer Disaster-Recovery-Implementierung, die Probleme verursachen können. Natürlich muss das Unternehmen DR regelmäßig testen, um sicherzustellen, dass es wie erwartet funktioniert. Wenn der Anbieter für DR-Tests außerhalb der Geschäftszeiten zahlen muss, ist es wichtig, die Kosten für die Administratoren, die den Failover durchführen, zu ermitteln und in das Gesamtkostenmodell für die Einrichtung einzubeziehen.
Im Folgenden sind drei Schritte aufgeführt, die ein DRaaS-Anbieter befolgen kann, um die Gesamtkosten für die Einrichtung einer virtuellen Notfallwiederherstellung genau zu ermitteln:
- Stellen Sie sicher, dass jede DR-Vereinbarung keine Flatrate-Vereinbarung ist. Irgendjemand muss für die genutzten Ressourcen bezahlen. Das sollte der Kunde sein, nicht Sie, der Anbieter. Dazu gehören nicht nur die Daten, aus denen die VMs bestehen, sondern auch die Journale und Point-in-Time-Kopien.
- Sie müssen alle sich ändernden Daten, die über das WAN gesendet werden, nachverfolgen und komprimieren, mit Empfangsbestätigung. Das bindet Arbeitsspeicher, und wenn der Administrator plötzlich den Arbeitsspeicher aller Replikations-Appliances verdoppeln muss, um massive Änderungsraten zu bewältigen, wird es sehr teuer.
- Arbeiten Sie ein Kostenmodell sowohl für reale als auch für Test-DR-Ereignisse aus. Machen Sie deutlich, was enthalten ist, was nicht enthalten ist und wie hoch die Kosten sind. Auf diese Weise verstehen sowohl der Kunde als auch der Provider die Kosten für die Planung von Failover-Ereignissen.
Provider müssen die Kosten für Disaster Recovery ausarbeiten und testen, bevor sie den Kunden zur Verfügung gestellt werden. Das Team, das den Service bereitstellt, muss sicherstellen, dass es die Kosten versteht, die entstehen können, wenn eine VM nicht in die erwarteten Grenzen des Modells passt.
Wenn es um die Kosten für die Einrichtung eines Disaster Recovery geht, sollte es keine Einheitsgröße geben. Berücksichtigen Sie die Größe, die Änderungsrate, die Bandbreitenkosten für diese Änderungsraten und die Ressourcen, die für die Unterstützung der DR-Einrichtung erforderlich sind.
