Nutanix


[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 – Acropolis Block Services (ABS)

In diesem Blog geht es um das Thema Acropolis Block Services (ABS), was sich dahinter verbirgt, wie es funktioniert und natürlich wie man es einrichtet.

Hinter ABS verbirgt sich erst einmal ganz vereinfacht gesprochen, die Möglichkeit die Storage Ressourcen der Nutanix Plattform über iSCSI an Clients zu präsentieren, gleich ob virtualisiert oder physikalisch.

Warum ist dies eine wichtige Komponente einer Enterprise Cloud?

Hierzu muss man nur einen Blick in eigene Infrastruktur wagen. Welche Workloads sind dort möglicherweise noch nicht virtualisiert und warum?  Als klassisches Beispiel wären hier Datenbanken zu nennen, vor allem auf Grund der Lizenzierungs-Thematik. Möchte man als Unternehmen den Schritt Richtung einer Hyper-Converged Plattform gehen und hat noch immer die Anforderung, in welcher Form auch immer, Workloads mit performantem und hochverfügbarem Storage zu versorgen, sollen diese natürlich nicht zugrückgelassen werden. Allerdings soll gleichzeitig der Bedarf an zusätzlichen Storage Silos und die damit Verbundene Komplexität eliminiert werden.

Wie kann ABS jetzt diesen Anforderungen gerecht werden?

ABS ist ein integraler Bestandteil der Nutanix Distributed Storage Fabric (DSF) und ermöglicht es „vDisks“, die man normalerweise an virtuelle Maschinen präsentieren würde, via iSCSI an externe Systeme zu präsentieren. Für ein besseres Verständnis, kann man im ersten Schritt eine vDisk mit einer LUN vergleichen, welche an ein System präsentiert wird. Dabei gibt es bei ABS ein paar spezielle Features, die im Vergleich zu herkömmlichen Storage Systemen, besonders hervorgehoben werden sollten.

Im ersten Schritt muss für das Nutanix Cluster die „External Data Services IP Address“ (DSIP) konfiguriert werden, denn diese ist das zentrale Bindeglied zwischen der DSF und den Clients. Die DSIP agiert dabei als iSCSI Portal, denn dort schlagen sämtliche iSCSI Anfragen aller Clients auf.

Die DSIP wird von einer der Controller Virtual Machines (CVMs) des Clusters gehostet und kann von jeder anderen CVM im Fehlerfall übernommen werden, sprich diese IP ist stets erreichbar.

Um die eigentlichen Storage Ressourcen in Form von vDisks für die Freigabe via iSCSI zu konfigurieren, sind nur wenige Klicks notwendig. Über so genannte Volume Groups werden sämtliche Einstellung dazu getroffen.

Storage >> Table >> Volume Groups >> + Volume Group

Der Prozess erfordert nur wenige Eingaben, neben Namen und einer optionalen Beschreibung, sind die wichtigsten Schritte die einzelnen vDisks hinzuzufügen und den Clients, via IP oder IQN, den Zugriff zu gestatten. Für dieses Beispiel habe ich vier 500GB vDisks hinzugefügt, die dann gleich auch als vier unabhängige Disks am Betriebssystem des Clients erscheinen werden.

Tipp: Mit der Option „Flash Mode“ werden alle vDisks auf dem SSD Performance Tier festgepinnt und quasi das automatische Tiering deaktiviert, sodass I/O Anfragen nicht durch das langsamere HDD Tier beantwortet werden müssen. Wenn nicht alle vDisks im Flash Mode laufen sollen, so kann dies via CLI auch auf einzelne vDisks angewendet werden: acli vg.disk_update

Jetzt kommen zwei wirklich praktische Eigenschaften der ABS zum Zuge. Zum einen ist eine Hyper-Converged Plattform auf Scale-Out ausgelegt und nach diesem Prinzip würde es keinen Sinn machen, dass ein einzelner Node alle vier vDisks hostet und alle Storage Zugriffe verarbeiten muss. Daher verteilt die DSF im Hintergrund die Ownership der einzelnen vDisks auf vier verschiedene CVMs und damit vier verschiedene physikalische Nodes. Damit sind die Storage Ressourcen für den Client über vier Storage Controller gestreut und so profitiert dieser von der Leistungsfähigkeit und den Ressourcen aller beteiligten Nodes.

Auf Seiten des Clients ist dabei keine MPIO Software notwendig. Es genügt, die DSIP des Nutanix Clusters im jeweiligen Software iSCSI Initiators des Betriebssystems anzugeben.

Danach erscheinen die zu Beginn erstellten vier Disks der Volume Group, die sich jetzt bequem verbinden, anschließend online schalten, initialisieren und formatieren lassen.

Zur Demonstration des Scale-Out Features, habe ich im Anschluss etwas Last auf allen vier Disks erzeugt und die Prism UI zeigt entsprechend auch, dass alle vier Disks gleichermaßen unter Last stehen.

Ein Blick auf die Hosts zeigt, dass diese gleichmäßig belastet werden.

Gut zu erkennen ist, dass keine der CVMs in Sachen RAM oder CPU überlastet ist, da alle vier CVMs in diesem vier Node Cluster gleichermaßen mithelfen die I/O Anfragen abzuarbeiten.

Die CVM welche die DSIP hostet, nutzt so genannte iSCSI Re-Directions, um die Clients an den eigentlichen Owner einer vDisk weiterzuleiten. Für jede der vDisks innerhalb einer Volume Group wird also ein iSCSI Target kreiert, weclhes sozusagen stets mit der vDisk mitwandert, egal von welcher CVM diese gehostet wird. Der eigentliche Storage Zugriff erfolgt dann über die IP der jeweiligen CVM.

Fällt eine CVM oder ein ganzer Node aus, so übernimmt eine andere CVM die DSIP und natürlich auch die Ownership für jene vDisks, deren ursprüngliche CVM gerade offline ist. Der Client registriert ein Timeout und stellt eine neue Anfrage über die DSIP, welche entsprechend mit einer Weiterleitung zur neuen CVM IP antwortet.

Verfügt Host 2 beziehungsweise die darauf laufende CVM2 über lokale Kopien der Daten, so können diese direkt von dort gelesen werden. Ansonsten ist die CVM aber auch in der Lage, auf die Storage Ressourcen aller anderen CVMs zuzugreifen und I/O Anfragen entsprechend von den remote Ressourcen zu beantworten. Somit gibt es grundsätzlich keine Bindung daran, dass eine spezielle CVM die Ownership für eine spezielle vDisk übernehmen muss, sondern jede CVM kann jede vDisk hosten. Selbst in einem Nutanix Cluster welches auch Storage Only Nodes beinhaltet, können deren CVMs ebenfalls ABS vDisks hosten und bereitstellen.

Der Failover dauert ca. 10 Sekunden. Kommt die ursprüngliche CVM wieder online und läuft für 120 Sekunden stabil, wird die vDisk Ownership wieder zurück übertragen. Der einfache Grund dahinter ist, dass die ursprüngliche CVM einen Großteil der Daten lokal gespeichert hat und somit die Zugriffe über das Netzwerk minimiert werden können.

ABS unterstützt zudem die vDisks online zu vergrößern und darüber hinaus auch SCSI UNMAP, sodass gelöschte Daten auch in der darunterliegenden DSF wieder freigeben werden können. Ebenfalls ist es möglich, Volume Groups zu klonen, um diese zum Beispiel an Test- und Entwicklungs-Systemen zu präsentieren. Zu guter Letzt sei erwähnt, dass zu Disaster Recovery Zwecken natürlich auch die Möglichkeit besteht, Volume Groups und sollte es sich bei den Client Systemen um virtuellen Maschinen auf der Nutanix Plattform handeln, diese in einer gemeinsamen „Protection Domain“ zu konfigurieren und damit Snapshots zu erstellen und diese auch asynchron zu replizieren.


[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.