Storage


[DE] Nutanix – Acropolis Container Services

Heute geht es um ein natürlich nicht völlig neues, aber dennoch für Personen aus dem IT-Infrastruktur Bereich, eher ungewohntes Thema. Container – oder Docker – ist in aller Munde und da wird es Zeit einen Blick darauf zu werfen, wie sich die moderne IT-Infrastruktur und Container zusammenbringen lassen.  Also was tun, wenn aus den Fachabteilungen die Anforderung einer Container Plattform kommt?

Container sind ganz allgemein gesprochen, kleine kurzlebige Dienste, die auf ein Host Betriebssystem aufsetzen und die eigentliche Applikation und all Ihre Abhängigkeiten mitbringt und im Zusammenspiel mit dem Kernel des Host Betriebssystem zur lauffähigen Applikation werden. In der Regel sind diese Stateless und halten die Daten außerhalb der Container. Anders als bei virtuelle Maschinen geht man davon aus, dass Container ausfallen dürfen, da die bereitgestellten Dienste in der Regel nicht von einem Container alleine bereitgestellt wird. Streikt ein Container, so wird dieser einfach gestoppt und eine neue Instanz des Containers neu gestartet und schon steht der den Dienst steht wieder zur Verfügung.

Das erfordert aber nicht nur eine Plattform, welche die Container selbst hosten kann, sondern auch die Orchestrierung übernimmt und Benutzern oder Automatisierungs-Software über Schnittstellen ermöglicht, diese autonom ohne Eingriff der IT –Abteilung zu starten und zu stoppen.

Vielleicht hier ein beeindruckendes Beispiel aus der Google Cloud, denn dort werden viele Dienst bereits als so genannte „Micro Services“ abgebildet. Die Engine dahinter rollt automatisiert rund 7000 Container pro Sekunde aus! Quelle: Kubernetes – Scheduling the Future at Cloud Scale von David K. Rensin

Und hier kommen die Nutanix Enterprise Cloud Plattform mit ihrer neuesten Ergänzung, der Acropolis Container Services (ACS) zum Tragen. ACS erweitert die Nutanix Plattform um eine Lösung zum „IT-freien“ betrieb von Containern.

Zunächst ein kurzer Blick auf den Motor des Ganzen. Dieser besteht im Wesentlichen aus den dockerized Host VMs. Kleine Linux VMs, mit entsprechender Docker Installation, auf denen die eigentlichen Container gestartet werden können. Diese werden automatisiert über ACS ausgerollt, das freut sicherlich die Plattform-Admins, da hierfür kein spezielles Container Knowhow benötigt wird. Diese VMs bilden dann entsprechend zusammen einen so genannten Container Machine Pool.

Jetzt braucht es noch eine Komponente, welche die auszurollenden Container entsprechend auf den Host VMs platziert, also quasi alles orchestriert. Dies übernimmt ein neuer „Container Service“ der jetzt Teil der Nutanix Controller Virtual Machine (CVM) ist. Auf Basis von Docker Swarm, übernimmt dieser Dienst das gesamte Organisation der Container. Der Dienst läuft verteilt über alle CVMs und eine der CVMs agiert dabei immer als Swarm-Master.

Sollen die Daten extern auf persistenten Volumes abgelegt werden, kann hierfür das Nutanix Docker Volume Plugin (DVP) genutzt werden. Welches entsprechen den Storage der Nutanix Plattform innerhalb der Container zur Verfügung stellt. Dies läuft über die Acropolis Block Services (ABS).

Somit können klassische VMs, parallel zu Containern auf einer Plattform betrieben werden. Damit können auch direkt weitere Dienste, wie zum Beispiel eine persistente Datenbank auf der Plattform betreiben werden, die von den Containern genutzt werden soll, mit allen Vorteilen einer virtuellen Infrastruktur.

Näher betrachtet, erkennt man den Zusammenhang zwischen Client und der Docker Host VM.

Was muss die IT, die ja noch immer die Hoheit über die Plattform besitzt tun, um ACS zu aktivieren? Lediglich über den Punkt Upgrade Software in Prism, auf den Tab Container gehen und nach erfolgreichem Download der Software, Install klicken.

Gefolgt vom letzten Schritt, den Haken „Enable Container“ setzen. Über diesen Weg lassen sich die Container Host VMs auch bequem aktualisieren.

 

Soweit zur Backend Infrastruktur, wichtiger aber ist, wie kommen Benutzer jetzt in den Genuss die Container tatsächlich zu benutzen, ohne sich Gedanken um die dahinterliegende Infrastruktur zu machen?

Der Weg führt über das Nutanix Self-Service Portal (SSP), über welches Benutzern entsprechend Zugriff auf die Ressourcen der Nutanix Plattform erhalten. Derzeit in Form von virtuellen Maschinen und eben neuerdings Container. Dort lassen sich spezielle Rollen, mit der Berechtigung für Container Deployments erstellen und diese können dann entsprechenden Projekten mit Ressource Quotas zugewiesen werden. Die Benutzerverwaltung läuft über das in der Regel vorhandene Active Directory, sodass diese direkt den Projekten zugeordnet werden können und nicht zusätzlich Benutzer gepflegt werden müssen. Mehr Details zum Self-Service Portal, folgendem in einem eigenen Blog Artikel.

Loggt sich der Benutzer jetzt ein, ist es ihm möglich Container aus der öffentlichen Docker Registry zu ziehen und auszurollen oder aus einem internen, extra zu hinterlegenden, privaten Repository. In der ersten Version von ACS werden erst einmal Single Container Deployments unterstützt. Multi-Container sollen folgen. Je nachdem, welche Netzwerke (VLANs) der Hypervisor Host konfiguriert hat, werden diese dann im SSP als Option während des Deployment angeboten.

Als Teil der Advanced Settings, lassen sich zum Beispiel Port Mappings bzw. zusätzliche Variablen/Commands hinterlegen oder einfach den persistenten Storage als Mount Point einbinden. Die Besonderheit, der Prozess erlaubt es den Benutzern selbst den Storage zu provisionieren, also neue Volumes anzulegen. Auch lässt sich das Docker Volume Plug-In direkt aus Docker Datacenter heraus ansprechen, was zeigt das dieses universell einsetzbar ist und nicht auf die Verwendung von ACS beschränkt ist.

In Version 1.0 beschränkt sich ACS auf ein UI gestützte Nutzung und ein laufender Container sieht dann wie folgt aus:

Hier ist zukünftig zu erwarten, dass sich nicht nur komplexere Container Deployments durchführen lassen, sondern die Steuerung auch via APIs & CLIs möglich wird. Denn in den meisten Fällen ist es das Ziel, dass dieser Prozess z.B. als Teil eines Continuous Deployment, komplett automatisiert sein sollte.

Der Vollständigkeit halber sei erwähnt, bereits heute schon ist es möglichst, dass Entwickler direkt von ihrem Endgerät aus, dockerized Host VMs auf der Nutanix Plattform erstellen bzw. ansprechen und dort direkt ihre Container nutzen können. Nach einer Installation der entsprechenden Nutanix Client Software, sieht das dann in etwa wie folgt aus:

pschulz-deu-mbp:~ patrick.schulz$ docker-machine create -d nutanix –nutanix-username admin –nutanix-password password –nutanix-endpoint 192.168.100.201:9440 –nutanix-vm-image ContainerHost-20160818 –nutanix-vm-network Default nutanix-docker-vm-10

Running pre-create checks…

Creating machine…

Waiting for machine to be running, this may take a few minutes…

Detecting operating system of created instance…

Waiting for SSH to be available…

Detecting the provisioner…

Provisioning with centos…

Copying certs to the local machine directory…

Copying certs to the remote machine…

Setting Docker configuration on the remote daemon…

Checking connection to Docker…

Docker is up and running!

To see how to connect your Docker Client to the Docker Engine running on this virtual machine, run: docker-machine env nutanix-docker-vm-10

pschulz-deu-mbp:~ patrick.schulz$ docker-machine env nutanix-docker-vm-10

export DOCKER_TLS_VERIFY=”1″

export DOCKER_HOST=”tcp://192.168.100.32:2376″

export DOCKER_CERT_PATH=”/Users/patrick.schulz/.docker/machine/machines/nutanix-docker-vm-10″

export DOCKER_MACHINE_NAME=”nutanix-docker-vm-10″

# Run this command to configure your shell: 

# eval $(docker-machine env nutanix-docker-vm-10)

Hinweis: Das entsprechende dockerized Host VM Image, muss vorher über den Nutanix Image Service hochgeladen werden.


[DE] Nutanix Cluster Erweiterung (Scale-Out)

Hinweis: Cross-Post von invisible-it.de

In diesem Artikel möchte ich etwas näher auf die Erweiterungsmöglichkeiten (Scale-Out) der Nutanix Plattform eingehen. Doch zu Beginn die Frage, warum denn ein unkompliziertes und schnelles Scale-Out ein essentielles Feature der Plattform ist?

Nutanix verfolgt die Philosophie, dass das bisherige Vorgehen, Storage und Compute auf 3, 5 oder gar mehr Jahre „vorausschauend“ zu beschaffen, nicht mehr zeitgemäß ist. Zum einen ist es extrem schwer den genauen Bedarf an Ressourcen über einen längeren Zeitraum wirklich präzise vorauszusagen und so läuft man Gefahr, wohlmöglich zu schnell Anforderungen nach neuen Ressourcen nicht nachkommen zu können, oder schlicht, zu groß zu planen und man so ungenutzte Ressourcen vorhält. Selbst wenn die Einschätzung halbwegs passen sollte, werden die Ressourcen über einen längeren Zeitraum nicht genutzt und schaffen so erst über die Zeit einen reellen Wert für das Unternehmen, wenn diese tatsächlich über den Lebenszyklus hinweg auch tatsächlich genutzt werden.

Wie sieht hierzu jetzt die Antwort der Nutanix Plattform aus?

Nutanix empfiehlt tatsächlich nur die Ressourcen zu beschaffen, die stand heute nötig sind, um die bestehenden Workloads und wirklich kurzfristig anstehenden Projekte zu stemmen. Um dies zu ermöglichen, muss es technisch möglich sein, die Plattform möglichst schnell und unkompliziert zu skalieren.

 

Scale-Out

Möchte man ein bestehendes Nutanix Cluster erweitern, so ist der wohl härteste Job, der Einbau und die Verkabelung der Nodes im Rack. Der restliche Prozess kann dagegen bequem per Prism gesteuert werden. Alles das es dazu braucht, sind die folgende Informationen/Daten:

  • IP Adressen für die neuen Nodes (je 3 Adresse pro Node – Hypervisor, CVM, IPMI)
  • Angabe des gewünschten Hypervisors (Upload der entsprechenden .iso Datei)

Die Nodes werden über ein IPv6 Discovery automatisch erkannt und der Installationsprozess, welcher die neuen Nodes mit allen benötigten Komponenten im Hintergrund betankt, erfolgt über die so genannte Nutanix „Foundation“ Komponente. Hierzu folgt in Kürze ein dedizierter Beitrag, der erklärt was die Foundation genau macht. Die folgenden beiden Screenshots zeigen, wie einfach ein Nutanix Cluster zu erweitern geht:

Da neue Nodes neben CPU und RAM auch zusätzliche Storage Ressourcen mitbringen, müssen diese in die vorhandene Distributed Storage Fabric (DSF) integriert werden. Nach der Integration des neuen Nodes werden die Daten im Cluster neu verteilt, sodass das  Cluster gleichmäßig ausgelastet ist. Dabei bleibt die Data Locality der bereits laufenden virtuellen Maschinen natürlich erhalten. Dieser Prozess ist völlig transparent und wird automatisch als Teil der Clustererweiterung angestoßen. Da durch diesen Prozess auch wieder Freiräume auf den bestehenden Nodes entstehen, kann so auch die Performance verbessert werden. Auch partizipieren die neuen Nodes direkt, indem sie den Replication Traffic anderer Nodes entgegennehmen.

ntnx_storagepool_1

ntnx_storagepool_2

Hypervisor

Im Falle von ESXi und Hyper-V, muss der Host noch in den vorhandene Cluster aufgenommen werden. Im Gegensatz dazu, ist dieser Prozess bei AHV komplett automatisiert und erfordert keine weiteren Schritte. In allen Fällen jedoch, ist es möglich, dass direkt nach der Erweiterung virtuelle Maschinen auf die neuen Nodes migriert werden können.

 

Gemischte Cluster

Ein wichtiger Punkt ist, dass ein Nutanix Cluster nicht homogen ausgestattet sein muss. Verschiedene Workloads haben entsprechend unterschiedliche Anforderungen, denen man mit unterschiedlicher Ausstattung entgegnen kann. So können verschiedene Node Typen in einem Cluster gemischt werden, z.B. NX-3060-G5 Nodes mit je 2 SSDs und 4 HDDs mit NX-8050-G5 Nodes, mit 4 SSD und 20 HDDs kombiniert werden. Über Hypervisor Technologien, wie Affinity-Rules, können die Workloads entsprechend den am besten geeigneten Nodes zugeordnet werden.

 

Storage Only Nodes

Jetzt kann es jedoch auch vorkommen, dass die Anforderungen nach Ressourcen ungleich entwickeln, sprich Storage Anforderungen schneller steigen, als die nach CPU und RAM. Auch hier bietet die Plattform eine einfache Lösung, so genannte Storage Only Nodes. Diese Nodes können dem Cluster hinzugefügt werden, haben jedoch die Besonderheit, dass diese:

  1. Mit reduzierten RAM und CPU Kapazitäten ausgestattet sind.
  2. Keine virtuellen Maschinen hosten und auch nicht Teil des Hypervisor Clusters sind.
  3. Immer mit dem AHV Hypervisor betrieben werden, damit hier keine zusätzlichen Kosten für den Hypervisor anfallen.

Somit kann die DSF des Clusters ohne Probleme um mehrere TB Storage Kapazität erweitert werden. Diese sollten immer im Paar hinzugefügt werden, sofern deren Kapazität die der vorhandenen Nodes deutlich übersteigt, sodass wenn ein Storage Only Node ausfällt, genügend freie Kapazitäten im Cluster vorhanden sind, damit der Rebuild in Gänze abgeschlossen werden kann.

ntnx_storagepool_4


[DE] Das Nutanix Cluster – Die Grundlagen

Hinweis: Cross-Post von invisible-it.de

Im folgenden Post möchte ich den Grundstein für viele der noch folgenden Themen legen, die wir hier in Zukunft noch behandeln werden und darum möchte ich erklären, wie ein Nutanix Cluster grundsätzlich aufgebaut ist.

Beginnen wir mit der kleinsten Einheit, mit einem so genannten Node. Dieser entspricht einem einzelnen x86 Server, auf dem direkt der Hypervisor installiert ist und entsprechend auch VMs betrieben werden können.

ntnx_wb_1x1_0

Ein Nutanix Cluster besteht jedoch immer aus mindestens drei Nodes.

ntnx_wb_1x1_1

Der wohl wichtigste Grund hierfür ist, dass die Nutanix Plattform ein verteiltes System ist. Daher müssen bei vielen Prozessen eine Mehrheit der Nodes gewissen Änderungen zustimmen, was in einem 2 Node Cluster so nicht möglich wäre.

Die Nodes beinhalten neben CPUs und RAM wie man das üblicherweise kennt, auch Storage in Form von SSDs und HDDs (Hybrid) oder ausschließlich SSDs (All Flash).

ntnx_wb_1x1_2

Dies Storage-Ressourcen sind direkt mit einem SAS HBA angebunden und werden 1:1 weitergereicht, sprich nicht in einem RAID konfiguriert.

ntnx_wb_1x1_3

Auf jedem Node läuft eine so genannte Nutanix „Controller Virtual Machine“, kurz CVM, welche besagten SAS HBA direkt via PCIe Pass-Through durchgereicht bekommt. Der Hypervisor selbst, bekommt diese Ressourcen somit nicht direkt zu sehen.

ntnx_wb_1x1_4

Die CVM ist das Herzstück der Nutanix Enterprise Cloud Plattform und betreibt nicht nur den Software Defined Storage Layer, sondern besser ausgedrückt, das Nutanix Datacenter Betriebssystem.

Alle CVMs kommunizieren über  Ethernet (wahlweise 1, 10 oder 40 GbE) miteinander und bilden so gemeinsam einen Storage Pool, auch “Distributed Storage Fabric” genannt.

Grundsätzlich ist jede CVM primär für die Verwaltung der jeweils lokalen Ressourcen verantwortlich. Über das Zusammenspiel aller CVMs in der DSF, ergibt sich so jedoch ein verteilter, leistungsfähiger und hochverfügbarer Storage Pool. Dieser sieht für den Hypervisors, oder andere externe Verbraucher, letzendes Endes aus wie ein herkömmlicher zentraler Storage und bietet zusätzlich Features wie Snapshots, Datenreduzierung, Replizierung, etc.

Der Storage Pool spiegelt 1:1 die aggregierte Kapazität aller physikalischen Ressourcen wieder. Wenn z.B. jeder Node über 14 TB Storage verfügt und wir beim Beispiel von drei Nodes bleiben, werden im ersten Schritt 42 TB im Storage Pool zur Verfügung gestellt.

ntnx_wb_1x1_5

Die eigentliche Storage Provisionierung geschieht über so genannte Storage Container, welche (vergleichbar zu einer LUN) aus dem Storage Pool gebildet werden und dem Hypervisor als Datastore präsentiert werden. Auf dieser Ebene werden wesentliche Einstellungen getroffen, beispielsweise wie viele Kopien für die Fehlertoleranz (RF2/RF3) erstellt werden oder auch ob beispielsweise Technologien zur Datenreduzierung wie Deduplizierung oder Komprimierung aktiviert werden sollen. D.h. erst hier definiert sich die tatsächliche nutzbare Kapazität eines Clusters. So hat z.B. ein Pool aus 42TB Rohkapazität in einer RF2 Konfiguration eine theoretische nutzbare Kapazität von 21TB. Betrachtet man jedoch einen Node als Spare Kapazität (N+1 Prinzip) der jederzeit ausfallen darf, so wäre die nutzbare Kapazität 14TB.

ntnx_wb_1x1_6

Jede CVM kommuniziert nicht nur über TCP/IP mit den benachbarten (Peer) CVMs, sondern auch über einen internen vSwitch, ohne externe Uplinks, direkt mit dem Hypervisor. Über diesen Weg (privates Netzwerk 192.168.5.0) greift der Hypervisor auf die Container und somit auch auf die lokalen Storage Ressourcen der CVM zu. Das Zugriffsprotokoll variiert je nach Hypervisor, im Fall von ESXi ist es NFS, bei Hyper-V entsprechend SMB und bei AHV das iSCSI Protokoll.

Die DSF ist wie gesagt ein verteiltes System, wonach die Daten als auch die Metadaten der VMs über das gesamte Cluster verteilt sind. Ein Blick auf den I/O-Pfad zeigt folgendes:

Die geschriebenen Daten einer VM, fließen über den Datastore direkt in die lokale CVM, welche dann in der Verantwortung ist, die Daten zu verarbeiten. Die geschriebenen Daten werden einmal lokal und dann abhängig vom konfigurierten Replication Factor “RF” (2 oder 3) auf weitere CVMs des Clusters synchron repliziert.

ntnx_wb_1x1_7

Damit erreicht man zwei wichtige Punkte:

  1. Data Locality: Die Primäre Kopie einer VM liegt sozusagen immer lokal in der CVM auf dem Host, auf dem die VM aktiv läuft. Somit können Read I/Os direkt aus den lokalen Storage Ressourcen erfolgen. Dies ermöglicht eine entsprechend hohe Performance und reduziert dabei gleichzeitig den Netzwerk Traffic auf ein Minimum.
  2. Rebuild Zeiten: Die Kopien für die Fehlertoleranz, werden komplett im Cluster verteilt und nicht immer an die gleiche Peer CVM(s) gesendet. Somit ist es möglich, dass ein Rebuild nicht nur von bzw. auf eine CVM stattfindet, sondern die Daten von vielen CVMs und deren lokalen Disks gelesen und auf beliebige CVMs und Disks wiederhergestellt werden können. Somit können Rebuild Zeiten deutlich optimiert werden.

Abschließend möchte ich noch die Frage beantworten, was passiert, wenn eine VM zwischen den Nodes migriert wird oder ein Node ausfällt und eine VM auf einem anderen Node wieder gestartet werden muss?

Grundsätzlich ändert sich aus Sicht der VM nichts. Diese wird, egal durch welches Event, auf einem neuen Node gestartet und greift dort direkt über die lokale CVM auf den Storage Container zu. Verfügt die lokale CVM bereits über einen Teil der VM Daten, so können diese direkt lokal gelesen werden. Wahrscheinlich müssen aber Teile der Daten über das Netzwerk gelesen werden, dies ist jedoch für die VM komplett transparent. Über Zeit kann so die Data Locality der VM wiederhergestellt werden, indem die Daten auf den neuen Node der jetzt die VM hostet, migriert werden. Einzige Voraussetzung, die VM muss die Daten die noch remote liegen auch tatsächlich lesen, sodass diese für eine Migration in Betracht gezogen werden.


[DE] Nutanix Metro Availability auf VMware vSphere

Dieser Beitrag beschreibt das Feature „Metro Availability“, also wie ein raumübergreifendes Cluster Design auf Basis der Nutanix Plattform zusammen mit VMware vSphere aussieht und wie einfach dies zu konfigurieren ist.

Da in einer Hyper-Converged Lösung der Hypervisor und Storage in einem Server vereint werden, muss für ein besseres Verständnis geklärt sein, dass hier trotz dieser Konvergenz zwei Ebenen separat voneinander betrachtet werden müssen:

  • Hypervisor Ebene: Hier beziehe ich mich tatsächlich rein auf den Hypervisor, im Folgenden einfach Hosts genannt, also wie die einzelnen Hosts z.B. in Form eines vSphere Clusters konfiguriert werden.
  • Storage Ebene: Hier wiederum beziehe ich mich auf die Nutanix Plattform, welche alle nötigten Storage-Funktionalitäten der Lösung zur Verfügung stellt. Gebildet wird dies durch das Zusammenspiel mehrere physischer Server, im Folgenden als Nodes bezeichnet.

Die Nutanix Metro Availability Implementierung sieht vor, dass in beiden Seiten jeweils ein eigenständiges Nutanix Cluster betrieben wird. Das ist wie gesagt jedoch zunächst unabhängig davon zu sehen, wie letztlich die einzelnen Hosts zusammenspielen. Ein Nutanix Cluster besteht dabei aus mindesten drei Nodes, die gemeinsam die bei Nutanix so genannte Distributed Storage Fabric kurz DSF bilden. Dabei werden alle physikalischen Ressourcen aller beteiligten Nodes in einem Storage Pool zusammengefasst. Aus diesem Pool werden wiederum so genannte Container erstellt, welche dann den Hosts in Form von NFS Datastores präsentiert werden.

Auf Ebene der Container werden letztlich Einstellungen wie beispielsweise des Replication Factor (RF), also das Level an Fehlertoleranz des Nutanix Clusters, oder aber auch ob die Capacity Optimization Engine (COE) Technologien wie Compression, De-Dupe oder Erasure Coding auf die darin gespeicherten Objekte anwenden soll.

Das heißt zusammengefasst, dass in jeder der beiden Seiten je ein Nutanix Cluster bestehend aus mindesten drei Nodes betrieben werden muss.

Tipp: Für kleinere Umgebungen ist es auch möglich zwei herkömmliche Nodes mit einem „Storage Only“ Node pro Seite zu kombinieren, um so die minimale Konfiguration von drei Nodes zu erreichen. Der Storage Only Node tritt dann nur in der Storage Ebene in Erscheinung und auf Hypervisor Ebene laufen dann tatsächlich nur zwei Hosts pro Seite.

Aber wie werden jetzt aus zwei Nutanix Clustern, die in sich bereits redundant und voll Funktionsfähig sind, eine Metro Lösung?

 

Nutanix / Storage Ebene

Aus zwei Nutanix Clustern wird eine Metro Lösung, wenn man folgende Schritte durchführt:

  1. Die beiden Cluster gegenseitig bekannt machen, dazu wird in beiden Clustern das jeweils andere Cluster als Remote Site eingerichtet.
  2. Die Container erstellen, welche synchron gespiegelt werden sollen.
  3. Danach kann man eine Protection Domain (PD) für die Metro Availability einrichten, welche primär definiert, welche Container synchron gespiegelt werden sollen.

 

Prism Element >> Data Protection >> + Remote Site >> Physical Cluster

Über das Hinzufügen der jeweils anderen Remote Site, werden die beiden Cluster bidirektional miteinander verbunden. Als IP Adresse wird jeweils die „Cluster Virtual IP Address“ sowie Name der jeweils anderen Seite verwendet.

Im zweiten Schritt können weitere Eigenschaften der Cluster zu Cluster Kommunikation definiert werden. Dabei gilt zu beachten:

  • Compression on Wire sollte deaktiviert sein.
  • Das VStore Name Mapping wird nicht benötigt, dieses kommt nur bei der asynchronen Spiegelung zum Einsatz.

Danach sollte die jeweils andere Remote Site beziehungsweise das jeweils andere Nutanix Cluster in der Liste der Remote Sites auftauchen.

Im nächsten Schritt werden die synchron zu spiegelnden Container erstellt. Dabei ist es möglich, gleichzeitig synchron gespiegelte, asynchron oder auch nicht gespiegelte Container zu verwenden, die Entscheidung in welchem Container eine Applikation betrieben werden soll, hängt letztlich von deren Anforderungen hinsichtlich SLAS/RPO/RTO ab.

 

Prism Element >> Storage >> Tab Container >> + Container

Die Metro Implementierung empfiehlt mindestens zwei Container pro Seite, um eine parallele Nutzung beider Cluster zu ermöglichen. Dabei läuft Container 1 aktiv in Seite 1 und ist gleichzeitig passiv in Seite 2, während Container 2 in Seite 2 aktiv ist und dafür passiv in Seite 1. Wichtig dabei ist, dass die Container auf beiden Seiten identisch benannt sein müssen, denn der Name des Containers entspricht 1:1 den Namen des an die Hosts präsentierten Datastores und diese müssen unbedingt an allen Hosts identisch sein.

Für diesen Post gehe ich nicht weiter auf die COE ein und lasse alle Features deaktiviert. Nach der Erstellung der Container werden diese automatisch an alle Hosts des jeweils lokalen Cluster gemountet.

Jetzt muss beiden Clustern noch beigebracht werden, welcher Container von Seite 1 auf welchen Container in Seite 2 gespiegelt wird und wie sich die Cluster verhalten soll, wenn die Kommunikation unterbrochen wird.

 

Prism Element >> Data Protection >> + Protection Domain >> Metro Availability

An dieser Stelle noch eine kurze Erklärung zu den Failure Handling Optionen:

  • Witness: Eingeführt mit AOS 5.0, ermöglicht durch eine weitere Nutanix Instanz in Form einer virtuelle Appliancen in einer unabhänigen dritten Seite, die Failover Entscheidung zu automatisieren.
  • Automatic Resume: Standardmäßig wird nach 30 Sekunden unterbrocher Kommunkation zwischen beiden Clustern die Replizierung gestoppt, sodass die VMs lokal weiter laufen können, ohne das es zu einem permantenen Stopp des I/O Flusses kommt. Erfordert jedoch ein manuelles eingreifen wenn eine Seite ausfällt, um die Container in der verbleibenden Seite zu aktivieren.
  • Manual: Keinerlei Automatisierung. Die Replizierung muss zugunsten des I/O Flusses manuell gestoppt, beziehungsweise die Container in der verbleibenden Seite aktiv geschaltet werden.

Hinweis: Der dargestellte Schedule mit 7 täglichen Snapshots ist exemplarisch und optional. Standardmäßig wird alle 4 Stunden ein Snapshot erstellt und bis zum nächsten Snapshot aufbewahrt. Dies dient dazu, das wenn die Daten re-synchronisiert werden, nur die Differenz zum letzten Snapshot übertragen werden muss. Daher übernimmt der Schedule auch automatisch die angegebene Anzahl der Snapshots für die Remote Seite, +1 für den Snapshot der grundsätzlich immer erstellt wird. In diesem Beispiel also 8.

Die Einrichtung erfolgt dabei Bi-Direktional, sprich die Einrichtung für den Container VMW-Metro01 erfolgt in der Prism Element UI von Cluster 1 („VMW01“) Richtung Cluster 2 („VMW02“) und entsprechend umgekehrt, sodass dies am Ende wie folgt aussehen sollte. Dabei können natürlich mehrere Container pro Seite erstellt werden.

Damit existiert jetzt in jeder Seite ein aktiver Container, auf dem die virtuellen Maschinen entsprechend aktiv zugreifen und ein passiver Container, welcher den Datenstrom des aktiven Containers der anderen Seite entgegennimmt.

Danach bietet die UI grundsätzlich zwei Optionen an:

  • Disable / Re-Enable: De- oder reaktiviert die Protection Domain und damit die synchrone Replizierung.
  • Promote (nur auf der Standby PD): Schaltet eine standby (passive) Protection Domain aktiv, sodass diese auf dem aktivierten Cluster entsprechend I/Os entgehen nehmen kann.
  • Take Snapshot: Erstellt einen Snapshot des gesamten Containers und damit auch aller darin gespeicherten Objekte.

 

Hypervisors Ebene

Cluster & Datastores

Alle Hosts werden dann in ein gemeinsames strechted Cluster konfiguriert, in dem dann entsprechend auch VMware HA, DRS, etc. genutzt werden kann.

Aus der Sicht des Hypervisors sehen alle Hosts jetzt zwei Datastores. “VMW-Metro01” und “VM-Metro02”. Obwohl diese ihren Ursprung in unterschiedlichen Nutanix Clustern haben, sieht es auf Grund des gleichen Namens, für alle Hosts wie zwei herkömmliche shared Datastores aus. So lassen sich auch VMs per vMotion problemlos zwischen den beiden Seiten hin und her bewegen. Jedoch gibt es dann zu beachten, dass der I/O Traffic dann gegebenenfalls auf den passiven Container trifft und dieser erst zum aktiven Container weitergeleitet werden muss, was zu einer Erhöhung der Latenzen beiträgt.

DRS Regeln

Es sollte generell sichergestellt werden, dass alle VMs die aktiv in Seite 1 laufen, auch auf einem Datastore (Container) liegen, der auf dem Cluster 1 beziehungsweise in Seite 1aktiv ist. Umgekehrt gilt dies natürlich auch für alle VMs in Seite 2, die über Cluster 2 zugreifen sollen. So lassen sich die VMs einfach gesagt 50/50 auf die beiden Seiten verteilen. Dazu braucht es je zwei DRS Host- und VM-Gruppen.

Die VM-Gruppen werden dann über DRS Affinity “Should” Rules, zu deutsch “Sollte”-Regeln, den passenden Host-Gruppen zugewiesen werden.

Das Ergebnis sollte wie folgt aussehen.

 

Failover Szenarien

Annahme: Seite1 und Seite 2 betreiben beide aktiv VMs, sprich jede Seite verfügt über aktive und passive Protection Domains.

Szenario Witness Automatic Resume Manual
Ausfall von Seite 1 oder kompletter Netzwerkausfall in Seite 1 Metro Availability wird gestoppt.

Automatischer Failover zu Seite 2.

VMs in Seite 2 laufen weiter.

 

Metro Availability wird gestoppt.

Admin muss PDs in Seite 2 aktivieren und VMs manuell starten.

VMs in Seite 2 laufen weiter.

Admin muss passive PDs in Seite 2 aktivieren und VMs manuell starten.

VMs in Seite 2 laufen weiter.

Ausfall von Seite 2 oder kompletter Netzwerkausfall in Seite 2 Metro Availability wird gestoppt.

Automatischer Failover zu Seite 1.

VMs in Seite 1 laufen weiter.

Admin muss PDs in Seite 1 aktivieren und VMs manuell starten.

VMs in Seite 1 laufen weiter.

Admin muss passive PDs in Seite 2 aktivieren und VMs manuell starten.

VMs in Seite 1 laufen weiter.

Split-Brain – Netzwerkausfall zwischen Seite 1 und 2 Metro Availability wird gestoppt.

VMs laufen in ihrer ursprünglichen Seite weiter.

Metro Availability wird gestoppt.

I/O läuft nach Timeout (Default 30 Sek.) weiter.

VMs laufen in ihrer ursprünglichen Seite weiter.

I/O Pausiert bis Admin eingreift.
Witness Ausfall Keine Auswirkungen. Trifft nicht zu. Trifft nicht zu.
Netzwerkausfall zwischen Seite 1 und Witness VMs laufen in ihrer ursprünglichen Seite weiter. Trifft nicht zu. Trifft nicht zu.
Netzwerkausfall zwischen Seite 2 und Witness VMs laufen in ihrer ursprünglichen Seite weiter. Trifft nicht zu. Trifft nicht zu.
Netzwerkausfall zwischen Seite 1 und Witness sowie Seite 2 und Witness VMs laufen in ihrer ursprünglichen Seite weiter. Trifft nicht zu. Trifft nicht zu.
Ausfall Seite 1 und Seite 2 Metro Availability wird gestoppt.

Admin Eingriff notwendig.

Metro Availability wird gestoppt.

Admin Eingriff notwendig.

Metro Availability wird gestoppt.

Admin Eingriff notwendig.

Split-Brain – Netzwerkausfall zwischen Seite 1 und Seite 2 sowie zwischen Seite 1 und Witness I/O in Seite 1 pausiert.

Parallel Failover zu Seite 2. VMs werden durch HA dort neugestartet.

Alle VMs in Seite 1 müssen heruntergefahren werden.

Trifft nicht zu. Trifft nicht zu.

 

 

Einrichtung der Witness Appliance

Dieser Prozess ist denkbar einfach:

  • Download der Appliance für den Ziel Hypervisor (AHV/Hyper-V/ESXi) aus dem Download Portal. Z.B. im Fall von ESXi, Deployment via OVF.
  • Booten der VM und öffnen der Konsole
  • Login: nutanix & nutanix/4u
  • Ausführen der folgenden Schritte
    • $ sudo vi /etc/sysconfig/network-scripts/ifcfg-eth0
      • NETMASK=xxx.xxx.xxx.xxx
      • IPADDR=xxx.xxx.xxx.xxx
      • BOOTPROTO=”none”
      • GATEWAY=xxx.xxx.xxx.xxx
    • cluster -s <Witness VM IP> –cluster_function_list=witness_vm create
    • Optional kann ein extra User angelegt werden: nuclei
  • Registrierung der Witness Appliance in beiden Nutanix Clustern (Login: admin & nutanix/4u)

Wichtige Punkte bei der Verwendung der Witness Appliance:

  • Die Verbindungen der beiden Seiten zum dritten Standort sollten unabhängig von der Verbindung zwischen den beiden Clustern sein.
  • Latenz für Witness Anbindung < 200ms RTT
  • Latenz für Cluster zu Cluster Kommunikation < 5ms RTT
  • Witness VM muss nicht auf Nutanix Hardware laufen
  • Unterstützt bis zu 50 Protection Domains pro Witness
  • vHardware Anforderungen:
    • 2 vCPUs
    • 4 GB RAM
    • 25 GB Storage

Tipp: Die Witness Appliance bietet ein via Browser erreichbares Dashbaord, um den Status der einzelnen Protection Domains / Container zu prüfen.