Die ständige Verfügbarkeit der bereitgestellten Services ist das oberste Ziel der Unternehmens-IT. In der heutigen Zeit ist es der Konsument gewöhnt, dass die benötigten Dienste ununterbrochen laufen. Aus diesem Grund muss die Infrastruktur redundant ausgelegt sein. Oftmals stehen den IT-Organisationen unabhängige Rechenzentren an zwei unterschiedlichen Standorten zur Verfügung, sodass beim Ausfall eines der Rechenzentren das andere immer noch vorhanden ist. In einem derartigen Fall ist es dann übliche Praxis, dass die Infrastrukturteile in einem Rechenzentrum die Hälfte der Services bereitstellen und die andere Hälfte aus dem anderen RZ kommt.

Weiterhin stehen in jedem der beiden Rechenzentren die Ressourcen bereit, um die Dienste des jeweils anderen bei einem Ausfall übernehmen beziehungsweise starten und betreiben zu können. Konkret bedeutet das, dass von einem Workload aus Rechenzentrum A im RZ 2 eine Kopie existieren muss. Ansonsten wäre es nicht möglich, dass die Workload-Kopie den Service beim Ausfall von RZ 1 aus RZ 2 anbieten könnte. Auf diese Art und Weise eine hohe Verfügbarkeit zu gewährleisten, ist nicht neu. In einer lokalen HCI (Hyper Converged Infrastructure) auf Basis von Nutanix kümmert "Leap" sich darum.

Bevor wir uns ansehen, wie Leap funktioniert und welche Möglichkeiten es Ihnen bietet, um Services hochverfügbar zu machen, werfen wir erst einmal einen genaueren Blick auf die hostende Infrastruktur. Eine On-Premises-HCI von Nutanix im Rechenzentrum besteht immer aus mindestens drei Nodes, die zusammen einen Nutanix-Cluster bilden. Übertragen auf das eingangs beschriebene Szenario würde dies also bedeuten, dass sich in Ihren beiden Rechenzentren jeweils ein Nutanix-AHV-Cluster (AHV ist der Hypervisor von Nutanix) befindet. Wobei jeder dieser Cluster jeweils die Hälfte sämtlicher Ihrer Services beziehungsweise Workloads hostet.

Selbstverständlich können Sie zwei unabhängige Cluster, so wie gerade beschrieben, jeweils separat administrieren. Der entsprechende Service – das Prism-Element – ist integraler Bestandteil eines jeden Nodes im Cluster. Bei einem einzelnen Cluster ist die Administration durch das Prism-Element dann auch eine ausgezeichnete Sache. Doch die Administration ist wesentlich bequemer, wenn alle vorhandenen Cluster mit nur einem einzigen Tool zu administrieren sind. Das Tool, das Ihnen die zentrale Administration einer großen Anzahl an Clustern ermöglicht, nennt sich Prism Central. Es steht im Gegensatz zu Prism-Element nicht als Service der Plattform zur Verfügung, sondern lässt sich als Workload bereitstellen und ist im Produkt auch grundsätzlich immer mit enthalten.

Prism Central ist aber nicht nur ein Managementwerkzeug, das es Ihnen erlaubt, alle Nutanix-Cluster und die darin gehosteten Workloads zentral zu administrieren. Es stellt Ihnen auch noch eine ganze Reihe an Komponenten beziehungsweise Diensten zur Verfügung. Dazu zählen die Microsegmentation der Infrastruktur, automatisierte Bereitstellungen von Workloads und Services basierend auf individuellen Blueprints und Replikation von Workloads. Prism Central bietet Ihnen zentralisiert eine ganze Reihe an optionalen Diensten.

Nutanix Leap ist also eine von vielen Funktionen in Prism Central. Was bedeutet, dass Sie kein separates Interface benötigen, um Ihre Workloads hochverfügbar über zwei Standorte hinweg bereitzustellen. Leap erlaubt es Ihnen, eine Workload-zentrische Hochverfügbarkeit zu konfigurieren. Sie können also für jeden Ihrer Workloads die Art der Replikation mittels Policy festlegen. Die unterschiedlichen Replikationsarten wollen wir im Folgenden betrachten. Dabei sollten Sie wissen, dass sich die asynchronen Replikationsverfahren auch ohne Leap (Prism Central) nutzen lassen.

Async DR (Asynchronous Disaster Recovery) bezeichnet die Workload-zentrische asynchrone Synchronisationsmethode zur Notfallwiederherstellung zwischen Nutanix-AHV-Clustern. In Bild 1 sehen Sie eine vereinfachte schematische Darstellung der Funktionsweise dieser Synchronisationsmethode. Vereinfacht, weil es sich zum besseren Verständnis lediglich um eine unidirektionale Synchronisation handelt. Die Schutzdomäne für die Workloads in Cluster 1 (Site 1) befindet sich in Cluster 2 (Site 2). Aber selbstverständlich können Sie mit dieser Funktion auch die Workloads auf beiden Seiten schützen. Was bedeutet, dass die Schutzdomäne für die Workloads auf dem Cluster 2 (Site 2) sich im Cluster 1 (Site 1) befindet.

Bei Async DR befindet sich ein Workload mit der Bezeichnung "App" im Cluster 1 (Site 1). Wird dieser Workload nun geschützt, erzeugt das System Snapshot A (1) und repliziert ihn dann (2) auf den Cluster 2 (Site 2). Die Replikation der Daten und Work-loads erfolgt über Zeiträume, die größer oder gleich einer Stunde sind. Das bedeutet, dass mindestens 60 Minuten zwischen zwei vollständigen Übertragungen vergehen. Bei der asynchronen Replikation gelten keine Abstandsbeschränkungen und auch keine Vorgaben im Hinblick auf die Latenz. Das RPO (Recovery Point Objec-tive) bei Asynchronous Disaster Recovery ist größer/gleich 60 Minuten.

NearSync DR ist ebenfalls ein asynchrones Replikationsverfahren zwischen Nutanix-AHV-Clustern. Es unterscheidet sich allerdings im Hinblick auf die Replikationsfrequenz deutlich vom Async DR. Hierbei liegt die Replikationsfrequenz zwischen einer und 15 Minuten. Im Hinblick auf RPO müssen Sie mit diesem Verfahren im besten Fall lediglich einen Daten- beziehungsweise Transaktionsverlust im Zeitraum von einer Minute hinnehmen.

Erreicht wir diese sehr schnelle, ebenfalls VM-zentrische Replikationsmethode durch Einsatz von synthetischen Snap-shots, den sogenannten Light-Weight-Snapshots (LWS). Dadurch ist es möglich, Workloads mit einer Replikationsfrequenz zwischen Clustern von einer Minute fast synchron zu halten. Da es sich um ein asynchrones Verfahren handelt, sind weder Abstandsbeschränkungen noch Latenzvorgaben einzuhalten. Allerdings sollten Sie darauf achten, dass Sie hier die entsprechenden zusätzlich benötigten Ressourcen im Cluster berücksichtigen.

Da die LWS im Flash-Tier des Clusters lagern, wäre es natürlich optimal, die beiden Cluster als All-Flash-Cluster auszulegen. Setzen Sie allerdings in Ihrem Cluster Hybrid-Nodes ein, dann müssen in Ihren Nodes auf jeden Fall mindestens ein Paar SSDs mit großer Kapazität eingebaut sein. Der Grund hierfür ist, dass ein direkter Zusammenhang besteht zwischen der Größe des Flash im Cluster, der Replikationsfrequenz und der Menge an Workloads, die an der Replikation beteiligt sind.

Kommen wir aber nun zur Funktionsweise. Das Verfahren arbeitet so, dass zwischen zwei vDisk-Snapshots eine LWS-Abfolge erzeugt wird. Das bedeutet, dass im Zuge der Konfiguration der sogenannte LWS-Store im Flash-Tier der Nodes erstellt wird. Dies ermöglicht dann quasi einen kontinuierlichen LWS-Datenstrom mit einem per Checkpoint gestützten Datenübertragungsverfahren. Sie konfigurieren NearSync DR, indem Sie einfach nur das gewünschte Intervall zwischen einer und 15 Minuten angeben. Aus Sicht der Administration unterscheiden sich die Verfahren Async DR und NearSysnc DR lediglich durch die Angabe der unterschiedlichen Intervalle im UI (User Interface).

Eine synchrone, VM-zentrische Replikation steht Ihnen ebenfalls zur Verfügung. Hierbei können Sie Ihre Workloads von einem Nutanix-AHV-Cluster zu einem zweiten entfernten Nutanix-AHV-Cluster mit einem RPO von nahezu Null (Zero Recovery Point Objective) schützen. Dies repliziert alle Schreibvorgänge eines geschützten Workloads (Cluster 1 in Site 1) synchron auf den Wiederherstellungsstandort (Cluster 2 in Site 2).

Eine optimale Leistung und einwandfreie Funktion der synchronen Replikation erfordert eine Round-Trip-Time (RTT) zwischen zwei Nutanix-AHV-Clustern von weniger als 5 Millisekunden. Die verfügbare Bandbreite auf der Replikationsstrecke muss so ausgelegt sein, dass auch etwaige Peak-Writes keine Engpässe verursachen. In jedem Fall sollte aber die Replikationsstrecke beziehungsweise das physische Netzwerk zwischen den beiden Clustern redundant ausgelegt sein.

Leap (Notfallwiederherstellung) ermöglicht den automatisierten Ablauf von Disaster-Recovery-Runbooks. Wobei es asynchrone und je nach Distanz auch syn- chrone Replikationen von Workloads zwischen eigenständigen, entfernten Nutanix-AHV-Clustern unterstützt. Damit Sie die Arbeitsweise von Leap besser verstehen, ist es wichtig, sich über einige Begrifflichkeiten Klarheit zu verschaffen. Befinden sich beispielsweise die sich replizierenden Nutanix-AHV-Cluster in Ihren eigenen entfernten Rechenzentren, dann sprechen wir von Local-Leap.

Aber fangen wir zunächst mit dem Begriff der Availability Zone (AZ; Verfügbarkeitszone) an. Eine AZ ist eine physisch isolierte Site, in die Sie zu schützende Workloads replizieren. Eine AZ kann sich entweder in Ihrem lokalen Rechenzentrum oder in der Public Cloud (Xi-Cloud) befinden. Jede Prism-Central-Instanz stellt eine AZ dar. Praktisch bedeutet das, dass Sie auf den Nutanix-AHV-Clustern je eine Prism-Central-Instanz deployen. So lassen sich dann alle Konfigurationsdaten automatisch zwischen diesen beiden Instanzen replizieren.

Bei den Disaster-Recovery-Runbooks gibt es aktuell drei unterschiedliche Typen, mit denen folgende Szenarien möglich sind: Der geplante Failover und Failback, der ungeplante Failover und der Failover-Test. Und über die Protection Policies (Schutzrichtlinien) definieren Sie, mit welchem RPO Sie Ihre Workloads schützen. An dieser Stelle können Sie sich dann für eine synchrone oder asynchrone Replikation entscheiden. Weiter stellen Sie das Failure-Handling ein und ordnen das Ganze dann noch einer entsprechenden Kategorie zu. Mit Hilfe der Categories (Kategorien) verknüpfen Sie die einzelnen Workloads dann mit den entsprechenden Protection Policies.

In den Recovery-Plans (Wiederherstellungspläne) befinden sich die Angaben zum Starten von Workloads. Sie enthalten die Startreihenfolgen, die IP-Adressverwaltung und die Zuordnungen der einzelnen Workloads zu den entsprechenden virtuellen Netzwerken.

Sie können Leap aber auch so konfigurieren, dass Sie einen lokalen Nutanix-AHV-Cluster mit einer Off-Premesis-Cloud (Bild 2) verbinden. Dabei befindet sich das Replikationsziel in der Xi-Cloud (Nutanix-Off-Prem-Cloud) in Deutschland. Diese Public Cloud, die Nutanix als Disaster-Recovery-as-a-Service (DRaaS) zur Verfügung stellt, trägt den Namen Xi-Leap. Die Replikationsquelle, also Ihr Nutanix-On-Premesis-AHV-Cluster (Private Cloud), befindet sich in Ihrem eigenen Rechenzentrum als lokale Availability-Zone.

Bei diesem Ansatz kommt ein asynchrones Replikationsverfahren zum Einsatz. Realisiert wird das Ganze dadurch, dass im Xi-Leap-Data-Center ein VPN-Server läuft, der mittels lokalem VPN-Client-Workload eine stabile und gesicherte Verbindung zwischen Ihrer lokalen und der Nutanix-Cloudinfrastruktur herstellt.

Da es sich bei Xi-Leap ebenfalls um einen Nutanix-Cluster in einem Nutanix-Data-Center handelt, lässt sich im Desaster-Fall einfach die Kopie des Workloads anfahren. Dadurch stehen Ihnen sämtliche Services sofort wieder zur Verfügung.

Natürlich können Sie von Ihren gesicherten Workloads auch nur einzelne, ausgewählte neu starten. Sie müssen im Not- oder Bedarfsfall somit nicht immer alle Ihre Workloads starten, um Ihre Services schnellstmöglich wieder an die Konsumenten zu bringen. Was die Konfiguration angeht, bestehen praktisch keine Unterschiede zwischen einer lokalen und einer Xi-Cloud-Workload-Wiederherstellung.

Nutanix bietet mit Leap eine ganze Reihe an unterschiedlichen Möglichkeiten und Verfahren, um Workloads und Services auch standortübergreifend hochverfügbar zu halten. Auch kann der Nutzer hierbei zwischen metro- und georedundanten Replikationsverfahren auswählen. Verfügt der IT-Verantwortliche nur über einen Rechenzentrumsstandort, kann er auch die Public Cloud von Nutanix für DRaaS nutzen, um mit seinen Services im Falle eines Desasters im eigenen RZ weiter online zu bleiben.