Um die Architektur der Nutanix-Enterprise-Cloud zu verstehen, ist es wichtig, sich die beiden Basiselemente, aus denen eine Cloud normalerweise besteht, etwas genauer anzusehen. Sie umfasst die Hardwareplattform und die darauf installierte Software-Ebene, die Virtualisierungsschicht. Diese Ebene lässt sich wiederum in zwei Module aufteilen: den Hypervisor und das Cloudbetriebssystem, das in einer lokalen Cloud auch für die Bereitstellung des Software-defined Storage (SDS) zuständig ist. Es finden sich also zentrale Elemente, die aus einer klassischen IT-Umgebung bekannt sind, in Software gegossen wieder und werden so als Hyper-Converged-Infrastruktur (HCI) bereitgestellt. Nutanix nennt diese Plattform "Acropolis". Das Cloud- beziehungsweise verteilte Betriebssystem nennt sich Acropolis Cloud Operating System (AOS) und der Hypervisor von Nutanix wird als Acropolis Hypervisor (AHV) bezeichnet.

Nutanix stellt zwei sogenannte "Stable Releases " von AOS zur Verfügung. LTS-Versionen (Long Term Support) erscheinen alle zwölf bis 15 Monate. Zwischen den LTS-Versionen veröffentlicht der Hersteller in der Regel alle drei bis sechs Monate eine Zwischenversion, die STS-Version (Short Term Support). Dabei erhalten die STS-Versionen zuerst neue Funktionalitäten.

Die lokale Nutanix-Plattform können Sie aktuell mit drei unterschiedlichen Hypervisoren, also Hypervisor-agnostisch, betreiben. Sie haben die Wahl zwischen AHV von Nutanix, Hyper-V von Microsoft oder ESXi aus der vSphere-Familie. Der XenServer-Hypervisor aus dem Hause Citrix wurde Ende 2019 abgekündigt.

Die Hardwareplattform, also die physische Infrastruktur, auf der die Nutanix-Enterprise-Cloud läuft, basiert auf einer Cluster-Architektur, allgemein oft einfach nur als Nutanix-Cluster bezeichnet. Ein weiterer Begriff, der in diesem Kontext vorkommt, ist "Node". Dies bezeichnet ein Element, das mit anderen Knoten (Nodes) verbunden ist. Ein solcher vernetzter Node-Verbund ergibt dann einen Cluster. Bei den Nodes handelt es sich um Server ohne Spezialausstattung, die alle miteinander vernetzt sind.

Die Cluster-Größe kann variieren, üblicherweise kommen mindestens drei Nodes zum Einsatz. Sie können auch Nutanix-Cluster aufbauen, die aus zwei oder sogar nur aus einem Node bestehen. Diese Art von Clustern sollten Sie allerdings nicht in Ihrem Rechenzentrum betreiben, sondern eher in Co- oder ROBO-Lokationen (Remote-Office und Back-Office). An dieser Stelle noch eine wichtige Info: Der Zwei-Node-Cluster benötigt eine Witness-VM, die Nutanix Kunden zur Verfügung stellt. Die Witness-VM dient zur Feststellung des Cluster-Zustands und sollte sich demzufolge auch in einer separaten Fehlerdomäne befinden. Der One-Node-Cluster stellt zwar einen voll funktionsfähigen Cluster dar, aber Sie sollten sich darüber im Klaren sein, dass bei Ausfall dieses Nodes auch keine IT mehr vorhanden ist.

Neben den Software-Elementen zum Aufbau der Cloudplattform stellt Nutanix weitere Anwendungen bereit, mit denen Sie die Plattform um zusätzliche Services ergänzen können. Dabei handelt es sich dann beispielsweise um S3- oder File-Storage oder um automatisiertes Data-Center-Management oder auch Application-Lifecycle-Automation.

Und damit sich die Software dann auch auf der geeigneten Hardware installieren lässt, benötigen Sie die entsprechenden Nodes. Nutanix ist ein reiner Softwarehersteller. Damit es für Betreiber einer lokalen Cloudinfrastruktur aber so einfach wie möglich ist, Cluster aufzubauen, haben sich Nutanix und die meisten der sich am Markt befindenden Hardwarehersteller zusammengetan und gemeinsam entsprechende Appliances entwickelt.

Die Appliances beziehungsweise Knoten zum Aufbau Ihrer lokalen Cloud können Sie also je nach persönlichen Herstellervorlieben oder Unternehmensstrategien auswählen. Nutanix bietet Ihnen eine ganze Palette an verschiedenen Möglichkeiten im Hinblick auf die Hardware der Nodes. Ob Sie nun die Nodes direkt von Nutanix, von einem OEM oder eher die Hardware Compatibility List und einen Drittanbieter bevorzugen, bleibt Ihnen überlassen.

Schauen wir aber nun etwas tiefer in das System hinein beziehungsweise genauer auf die einzelnen Thematiken, die eine derartige Plattform überhaupt erst möglich gemacht haben, beginnend mit Shared-Nothing. Eine Shared-Nothing-Architektur zeichnet sich generell durch eine hohe und vor allem lineare Skalierbarkeit aus. Die Idee, einfach nur physisch vollkommen eigenständige Node-Elemente mittels LAN untereinander zu verbinden, erlaubt das lineare Skalieren eines Clusters. Das heißt also, dass die Ressourcen, wie die Com-pute- und die Storage- Leistung eines einzelnen Nodes, nicht mit den anderen Nodes im Cluster geteilt werden müssen.

Dadurch bringt das Hinzufügen von weiteren Nodes nicht nur eine lineare Leistungsverbesserung, sondern auch ein theoretisch unbegrenztes Wachstum eines Clusters. In diesem Zusammenhang sprechen wir auch oftmals von einer Web-Scale-Architektur. Wenn einmal ein Knoten ausfällt, hat dies überhaupt keinen Einfluss auf einen anderen Node im Clusterverbund. Jeder einzelne Node im Cluster kann via Failover somit die Aufgaben eines ausgefallenen Knotens ohne Probleme übernehmen.

Sie müssen bei der Anschaffung einer IT-Umgebung immer darüber nachdenken, welche und wie viele Ressourcen im Nutzungszeitraum erforderlich sind. Das ist natürlich immer ein Blick in die Glaskugel, aber sollten Sie einmal danebengelegen haben, dann ist das mit einer Web-Scale-Architektur absolut kein Beinbruch. Dies soll ein kleines Beispiel veranschaulichen: Nehmen wir an, Sie haben in Ihrem Rechenzentrum einen Nutanix-Cluster, der aus vier Nodes besteht und zur Virtualisierung Ihrer Workloads eingesetzt wird. Nun bekommen Sie unplanmäßig die Anforderung, dass Sie weitere Workloads auf dieser Virtualisierungsplattform betreiben sollen. Die vorhandenen Ressourcen reichen dazu nicht aus, trotzdem müssen Sie den Anforderungen nachkommen. Ein Nutanix-Cluster lässt sich, ohne die vorhandene Infrastruktur zu beeinträchtigen, einfach schrittweise durch Hinzufügen einzelner Nodes erweitern – also ein Scale-Out. Anschließend verteilen sich die Workloads dann entsprechend der vorhandenen Ressourcen automatisch im Cluster.

Eine weitere gute Nachricht in diesem Zusammenhang ist, dass es keine Einschränkungen hinsichtlich der Ausstattung des neuen Nodes gibt. Das heißt, Sie können Ihrem vorhandenen Cluster auch neue Nodes hinzufügen, die eine andere Ausstattung im Hinblick auf CPU, RAM, Diskmenge oder -art haben. Dies gilt auch für die Erweiterung eines Clusters mit Nodes einer neueren Hardwaregeneration.

Darüber hinaus haben Sie auch noch die Wahl, einzelne Nodes, die mit mehr Storage ausgestattet sind als andere, problemlos in den Cluster einzufügen. Weiter besteht noch die Option für Sie, ausschließlich mit SSDs bestückte Nodes mit solchen, die eine hybride Diskbestückung (Flash und magnetische Disks) aufweisen, in einem einzelnen Cluster zu betreiben. Eine derartige Architektur eines Clusters erlaubt Ihnen beispielsweise auch Workloads, die auf All-Flash-Nodes betrieben werden müssen, entsprechend zu berücksichtigen, ohne dass Sie den ganzen Cluster mit All-Flash-Nodes ausstatten müssen.

Dieses Prozedere ist zudem auch in der anderen Richtung machbar. Das heißt, Sie können einem Cluster Nodes entnehmen. Stellen Sie sich zum Beispiel vor, Sie migrieren einen Teil Ihrer Workloads in einen anderen Cluster und es werden so viel Ressourcen frei, dass Sie ohne weiteres auf einen Node verzichten können. Das funktioniert auch im laufenden Betrieb.

Die Storage-Kapazität einer HCI lässt sich per Scale-Out granular über die Menge der Nodes im Cluster steuern. Weiter können Sie auch die Compute-Ressourcen wie CPU und RAM auf diese Art und Weise ganz einfach vergrößern.

Neben dem Scale-Out gibt es aber auch noch eine zweite Methode, um die Ressourcen in Ihrer HCI zu steuern – die vertikale Skalierung (Scale-Up). Konfigurieren Sie die Nodes Ihres Clusters hierbei im Vorfeld so, dass bezüglich der aktuellen Ausstattung später noch eine nachträgliche Erweiterung möglich ist. Da sich einzelne Nodes eines Clusters ohne Downtimes von Services außer Betrieb nehmen lassen, ist eine nachträgliche Erweiterung basierend auf dem Konzept des Scale-Up ebenfalls eine interessante Methodik.

Auch lassen sich einzelne Nodes vertikal skalieren, was erlaubt, mit der Anzahl oder der Kapazität der Disks in den Knoten eines Clusters die Storage-Kapazität der HCI ebenfalls granular zu steuern. Gleiches gilt selbstverständlich auch für CPU und RAM in einem Node.

Die Controller Virtual Machine (CVM) ist das Herzstück jeder Nutanix-HCI. Die CVM stellt sämtliche Dienste und auch die Speicherressourcen inklusive Software-defined Storage im Cluster bereit. Auf jedem Node innerhalb eines Nutanix-Clusters befindet sich eine CVM und alle CVMs sind untereinander über das Netzwerk verbunden (Bild 1). Über diese Verbindung tauschen die CVMs Daten untereinander aus. Dies gewährleistet einen einheitlichen Informationsstand, wodurch auch ein möglicher Ausfall einer einzelnen CVM erkannt und kompensiert wird. Der Replikationsfaktor sorgt für die notwendige Redundanz im Cluster.

Die CVMs laufen unter AOS und werden, je nachdem, was sie leisten müssen, mit einer bestimmten Menge an Compute-Ressourcen ausgestattet. Handelt es sich zum Beispiel um einen Cluster, dessen Aufgabe es ist, Produktions-Workloads zu hosten, hat die CVM normalerweise vier vCPUs und 32 GByte vRAM. Betreiben Sie allerdings in Ihren Rechenzentren mehrere Cluster, deren Workloads zwischen den Clustern repliziert werden, dann sieht die vCPU- und vRAM-Ausstattung natürlich anders aus. Wie genau sich der Bedarf an Ressourcen dann allerdings darstellt, hängt damit zusammen, in welchem Umfang Sie Ihre Workloads replizieren möchten und auch was für ein Replikationsverfahren Sie wählen.

Es gibt eine ganze Reihe von Nutanix-Cluster-Komponenten im AOS, die die Cluster-Services bereitstellen und miteinander interagieren. Die AOS-Funktionen lassen sich grundsätzlich in zwei Gruppen aufteilen: Distributed-Storage- und App-Mobility-Fabric. Deren jeweiligen Funktionen basieren auf den Nutanix-Cluster-Komponenten und den dazugehörigen Services. Die meisten der Dienste arbeiten im Hintergrund und Sie werden in der Regel bei der täglichen Arbeit nichts mit ihnen zu tun haben.

Doch es gibt auch einen Service, mit dem Sie sehr oft in Dialog treten – den Prism-Dienst. Prism stellt Ihnen das User-Interface ("Prism Element") in HTML5 zur Cluster-Verwaltung zur Verfügung. Prism Element erreichen Sie entweder direkt über die IP-Adresse einer der CVMs im Cluster oder über die IP-Adresse, die Sie dem Cluster zugeordnet haben unter "https://<IP-Adresse-CVM oder IP-Adresse-Cluster>:9440".

Die Prism-Services der einzelnen CVMs handeln unter sich einen Master aus. Dieser ist dann unter der Cluster-IP-Adresse erreichbar. Ist die CVM, deren Prism-Service der Master ist, für die anderen CVMs im Cluster nicht mehr erreichbar, dann wählen die verbleibenden CVMs einen neuen Master aus, wobei dieser dann wieder sofort unter der Cluster-IP-Adresse ansprechbar ist.

Ein weiterer Dienst, der hier in diesem Kontext eine große Rolle spielt, ist der Stargate-Service. Dieser ist dafür verantwortlich, den Hypervisor mit dem Storage zu versorgen, in dem sich die Workloads befinden. Bild 1 zeigt den Aufbau und wie Sie den Storage nutzen können.

Der in der Serverhardware verbaute SCSI-Controller verwaltet die vorhandenen Datenträger. Im Betrieb wird dieser SCSI-Controller dann basierend auf den Möglichkeiten der Gerätevirtualisierung des Hypervisors via Passthrough-Modus der CVM exklusiv zugeteilt. Hierdurch steht die gesamte Diskspeicherkapazität, die in einem Node existiert, ausschließlich der CVM dieses Nodes zur Verfügung. Wenn Sie sich nun vorstellen, dass dieses Konzept für alle CVMs im Cluster gleichermaßen gilt, erkennen Sie sicherlich sofort das große Ganze des verteilten Speichers innerhalb des Cluster-Verbunds.

Also bilden die CVMs in einer HCI von Nutanix gemeinsam die Distributed Storage Fabric (DSF), indem sie den gesamten DAS (Direct Attached Storage) der einzelnen Nodes zu einem verteilten SDS (Software-defined Strorage) zusammenfassen und nutzbar machen. Der von Ihnen verwendete Hypervisor bezieht seinen Storage also über sein bevorzugtes Protokoll direkt von der CVM. DSF stellt dabei eine verteilte Datenebene dar, die Funktionen wie Data Locality und Replikationsfaktor innerhalb des SDS von AOS bereitstellt. Auf diese Funktionen gehen wir gleich noch im Detail ein.

Im Fall des AHV ist dies das iSCSI-Protokoll, über das der AHV den Storage erreicht. Der ESXi-Host kann den Storage via NFS anbinden und Hyper-V verwendet das SMB-Protokoll, um über den vorhandenen Speicher zu verfügen. Und hier sehen Sie nun den großen Vorteil dieser Umsetzungsidee: Sie beinhaltet quasi die Möglichkeit, jeden beliebigen Hypervisor in die Plattform einzufügen. Entscheidet sich Nutanix zukünftig, einen weiteren Hypervisor zu unterstützen, ist dies mit dieser Art der Architektur problemlos möglich.

Werfen wir an dieser Stelle abermals einen kurzen Blick auf die schematische Darstellung in Bild 1. Wie Sie dort sehen, bekommt der Hypervisor, der auf einem Node arbeitet, über die CVM, die sich auf dem gleichen Node befindet, die lokalen Datenträger als lokalen Storage zur Verfügung gestellt. In der Nutanix-Cluster-Architektur ist es also grundsätzlich so, dass ein Workload, also eine virtuelle Maschine, unter normalen Betriebsbedingungen immer lokal auf einem Node läuft (Bild 2). Das impliziert kurze Wege und natürlich geringe Latenz, da ja alle Daten, die zu einer VM gehören, immer lokal gespeichert werden. Dieser Sachverhalt wird von Nutanix als "Data Locality" bezeichnet. Die Daten einer VM liegen also immer auf den lokalen Datenträgern eines Nodes. Jetzt stellt sich natürlich unweigerlich die Frage, was passiert, wenn der Node, auf dem sich die VM befindet, ausfällt. Dazu beinhaltet DSF eine entsprechende Schutzfunktion, damit keine Daten verloren gehen. Wie dieser Schutz funktioniert, darauf gehen wir etwas später im Detail ein.

Bleiben wir aber zunächst noch einen Augenblick bei der "Data Locality" und schauen, was das eigentlich genau bedeutet. Ein kleines Beispiel soll mehr Klarheit bringen: Konservativ betrachtet lässt sich für die meisten Umgebungen ein durchschnittliches Read/Write-Verhältnis von 70 zu 30 angeben. Stellen Sie sich nun einmal die Frage, was das denn im Hinblick auf die Latenz bedeutet, wenn die Data Locality sicherstellt, dass die Daten immer lokal auf den Knoten gespeichert sind. Sie lesen die Daten der Workloads ja direkt von den Disks, die im Server eingebaut sind, und nicht von entfernten Devices über ein irgendwie geartetes Speichernetzwerk.

Das bedeutet, dass in diesem Beispiel 70 Prozent der Daten, mit denen Ihre Work-loads arbeiten, mit fast vernachlässigbarer Latenz verarbeitet werden können. Wie Sie hier nun sehen, ergeben sich die optimalen Eigenschaften des Konzepts der vollständigen Data Locality aus der Tatsache, dass ausschließlich die lokalen Disks eines Nodes zum Einsatz kommen. Das bedeutet, dass jeder einzelne Node im Cluster seine maximale Leistung exklusiv den Workloads zur Verfügung stellt, die er virtualisiert. Was folglich auch einer der Gründe dafür ist, warum die Betrachtung von IOPS in einem Nutanix-Cluster keine so große Rolle spielt, wie es in klassischen Architekturen der Fall ist.

Bei Write-Operationen sieht es allerdings etwas anders aus, denn hier spielt die Datensicherheit eine Rolle – Stichwort Replikationsfaktor. Und hier kommt es dann leider auch wie bei allen Architekturen zu Latenzen. Doch bei Nutanix-Clustern betrifft dies gerade einmal 30 Prozent der gesamten Datenbewegung. Dennoch lässt sich feststellen, dass die Datenlokalität eine deutlich spürbare Verbesserung der Workload-Experience zur Folge hat. Ein weiterer Vorteil dieses Software-Konzepts ist, dass es das Netzwerk wenig belastet, da der Read-Vorgang lokal abläuft, was einer weiteren Optimierung gleichkommt.

Ein Nutanix-Cluster hält sämtliche Daten redundant vor: Fällt ein Node aus, sind trotzdem noch alle Daten der Workloads vollständig im Cluster vorhanden. Die Methode, die sicherstellt, dass die Daten im System auch wirklich redundant vorliegen, beruht auf Replikation und wird als Replikationsfaktor (RF) bezeichnet. Wenn Sie zum Beispiel einen Nutanix-Cluster mit dem Replikationsfaktor 2 einsetzen, dann wird jeder Block im SDS der HCI zwei Mal vorgehalten (Bild 2). Setzen Sie dagegen einen Cluster ein, dessen Daten mit einem RF von 3 abgesichert sind, dann existiert jeder Datenblock sogar drei Mal im System. Hierbei gibt es dann die lokalen Blöcke (Data Locality) und noch zwei vollständige über den gesamten SDS des Clusters verteilte Kopien.

Stellen Sie sich nun einmal vor, dass alle Datenblöcke im System durch Nutzung von einem RF von 2 doppelt vorhanden sind. In diesem Fall gibt es die lokalen Daten und eine auf alle anderen Nodes des Clusters verteilte Kopie der lokalen Daten. Fällt ein Knoten aus, existiert immer noch eine vollständige Datenkopie, mit der Sie weiterarbeiten können. Betreiben Sie hingegen eine Nutanix-HCI mit einem RF von 3, sind also alle Datenblöcke Ihrer Workloads dreifach im Cluster vorhanden, dürfen Ihnen sogar zwei komplette Nodes im Cluster ausfallen und Sie verfügen immer noch über Ihren vollständigen Datenbestand.

Schauen wir uns hierzu beispielhaft zwei mögliche Szenarien an: Stellen Sie sich einen Cluster bestehend aus drei Nodes und einem RF von 2 vor. Wenn in diesem Szenario ein Node ausfällt, stehen nur noch zwei Knoten zur Verfügung. Auf diesen zwei noch verbleibenden Nodes starten nun neben den Workloads, die lokal auf diesen beiden Knoten arbeiten, auch noch die Workloads neu, die ursprünglich einmal auf dem ausgefallenen Node liefen. In diesem Szenario darf jetzt kein weiterer Knoten mehr ausfallen. Anders sieht es dagegen aus, wenn Sie einen RF von 3 in Ihrem Cluster nutzen. Um Ausfallsicherheit zu gewährleisten, muss bei diesem RF die Cluster-Größe bei mindestens fünf Nodes liegen. Wenn Sie sich mittels RF von 3 eine so sichere HCI aufbauen und eine derartig hohe Datenredundanz schaffen, hat dies natürlich zur Folge, dass Sie sehr viel Speicherplatz für die Reserveblöcke benötigen.

Nutanix bietet mit seiner HCI eine ganze Reihe unterschiedlicher Verfahren, um seine Workloads und Services hochperformant und sicher zu betreiben. Die Möglichkeiten zum Aufbau einer lokalen Cloudumgebung sind umfangreich und bieten eine hohe Flexibilität und Elastizität. Dadurch sind Veränderungen und Erweiterungen mit Nutanix-HCI jederzeit möglich. Sollten einmal unerwartete oder projektbedingte Lastanforderungen eintreten, so lässt sich ein Nutanix-Cluster problemlos an die neue Situation anpassen.