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

Print Friendly, PDF & Email

Related Post

It's only fair to share...Tweet about this on TwitterShare on LinkedInEmail this to someone

Leave a comment

Your email address will not be published. Required fields are marked *