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

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 *