Yearly Archives: 2017


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