Disaster Recovery vs Backup: VM-Workloads priorisieren
Bevor Administratoren einen Wiederherstellungsplan erstellen, müssen sie planen, welche VM-Workloads eine Disaster-Recovery-Umgebung benötigen und welche Backups.
IT-Administratoren müssen die Wichtigkeit von VM-Workloads priorisieren, um sinnvolle Wiederherstellungsstrategien zu planen. Bevor IT-Verantwortliche eine Entscheidung treffen, sollten sie überlegen, wie die Vor- und Nachteile von Disaster Recovery vs. Backup aussehen.
Die Wiederherstellung ist keine Aufgabe, die Administratoren leicht nehmen sollten. Ausfälle können zwischen zehn und hunderttausend Euros oder mehr kosten, so dass effektive Wiederherstellungsmethoden für das gesamte Unternehmen entscheidend sind. Die Hauptherausforderung besteht darin, dass verschiedene VMs unterschiedliche Bedeutungsebenen haben, und die Verwendung der selben Absicherungsmethoden für alle Workloads teuer sein kann.
Administratoren sollten vor der Erstellung eines umfassenden Disaster-Recovery-Plans festlegen, ob sie Disaster Recovery oder Backup verwenden sollten. Backups wurden entwickelt, um virtuelle Workloads über einen Prozess wiederherzustellen, der Stunden oder Tage in Anspruch nehmen kann und in der Regel am selben Ort stattfindet. Die Notfallwiederherstellung sollte schneller erfolgen und typischerweise an einem anderen Ort als dem primären Standort auf anderer Hardware oder in der Cloud erfolgen.
Neben den technischen und logistischen Aspekten sind die Kosten ein weiteres Thema, das bei der Debatte über Disaster Recovery oder Backup zu berücksichtigen ist. Disaster-Recovery-Services sind oft deutlich teurer als Backups, da sie typischerweise ganze Produktionsumgebungen duplizieren, aber nicht täglich genutzt werden.
Die meisten Unternehmen verfügen sowohl über Disaster-Recovery- als auch über Backup-Strategien. Es ist wichtig zu verstehen, wie Workloads in die einzelnen Methoden passen, damit Administratoren diese Umgebungen optimieren können. Grundsätzlich sollten Backups alle Workloads schützen. Dies ist für das primäre Rechenzentrum sinnvoll, aber was ist mit dem Disaster-Recovery-Standort?
Viele Experten würden argumentieren, dass, wenn Administratoren die Möglichkeit haben, per Failover den primären Standort durch Datenreplikation in eine Disaster-Recovery-Umgebung zu transferieren, sie diese virtuellen Workloads nicht erneut sichern müssen, da sie im Wesentlichen ein Klon des primären Standorts sind. Diese Taktik kann zu Problemen führen, wenn die Workloads am Disaster-Recovery-Standort länger laufen als erwartet. Wenn die Workloads länger als 24 Stunden vorhanden sind, kann es vorkommen, dass die Disaster-Recovery-Site eine beträchtliche Menge an Primärdaten enthält, was ein Problem darstellt, wenn sie nicht geschützt ist.
Die Duplizierung einer Backup-Umgebung wird nicht einfach oder billig sein, aber die meisten Unternehmen können es sich nicht leisten, mit Daten überstürzt zu sein. Es ist wichtig zu verstehen, welche virtuellen Workloads in eine Disaster-Recovery-Umgebung gelangen und welche nicht. Eine Disaster-Recovery-Site benötigt ein gewisses Maß an Backup, und diese Kosten können sich schnell summieren.
Bewerten Sie Abhängigkeiten bei der Diskussion Disaster Recovery vs. Backup
Administratoren müssen priorisieren, welche Workloads einen Disaster-Recovery-Schutz erfordern und welche nicht. Diese Entscheidung ist nicht immer einfach, da moderne Anwendungen viele Abhängigkeiten haben können.
Administratoren müssen priorisieren, welche Workloads einen Disaster-Recovery-Schutz erfordern und welche nicht.
Virtualisierung ermöglicht es Anwendungen, horizontal zu skalieren. Dieser Anwendungs-Stack kann Datenbanken und Webserver umfassen, die die Anwendung und andere Dienste wie Authentifizierungs- und Berichtsserver unterstützen. Alle diese Komponenten, einschließlich des Primärspeichers für sie Komponenten müssen vorhanden sein und an den Disaster Recovery-Standort replizieren.
Infrastrukturserver stellen eine weitere relevante Herausforderung für die Entscheidung zwischen Disaster Recovery oder Backup dar. Infrastrukturserver müssen nicht auf den Disaster-Recovery-Standort repliziert werden, sondern müssen am Disaster-Recovery-Standort existieren und betrieben werden. Zu den meisten davon gehören Domain-Namen- und dynamische Host-Konfigurationsprotokollserver, Active Directory, Single Sign-On und andere Backup-Management-Server, die sich über Rechenzentren erstrecken können. Diese Infrastrukturkomponenten müssen für den ordnungsgemäßen Betrieb der Anwendungsserver verfügbar sein.
Wenn die Host-Ressourcen am Disaster-Recovery-Standort begrenzt sind, ist es möglicherweise besser, diese Workloads der virtuellen Infrastruktur schlank auszuführen. Verwenden Sie Betriebssysteme wie Windows Server Core anstelle einer GUI, um den Ressourcen-Overhead zu reduzieren.
Eine schlanke Denkweise kann Administratoren auch helfen, die Entscheidung zwischen Disaster Recovery oder Backup zu treffen. Es mag zwar schön sein, jede einzelne VM und Anwendung am Disaster-Recovery-Standort zu haben, aber die einfache Tatsache ist, dass einige Anwendungen nicht den Aufwand und die Kosten wert sind. Dies ist eher eine geschäftliche als eine technische Entscheidung.
Beispielsweise müssen Administratoren möglicherweise einige wichtige Server aufgeben, die das Unternehmen für kritisch hält, wenn alle Systeme normal laufen, wie zum Beispiel Druck- oder Dateiserver. Ist es mitten im Ausfall eines Rechenzentrums wirklich wichtig, zu drucken? Drucken ist wichtig, aber wenn Administratoren versuchen, Kernsysteme online zu halten, dann könnten begrenzte Disaster-Recovery-Ressourcen an anderer Stelle nützlicher sein.
Ob Disaster Recovery oder Backup eingesetzt werden soll, ist kein leicht zu lösendes Problem, und es bringt oft zahlreiche Antworten, je nach Interessengruppen. Jeder braucht Backups, und jeder will Disaster Recovery. Die Herausforderung besteht darin, dass Administratoren selten genug Ressourcen für beide haben.
Verwenden Sie eine schlanke Denkweise, wenn es um VMs geht, untersuchen Sie die Kritikalität verschiedener Workloads und testen und optimieren Sie ausgewählte Workloads immer so, dass die Workload-Performance im Notfall den Erwartungen entspricht.
