Lineare Skalierbarkeit

Die Worte „web-scale“ und „scale-out-Architecture“ definieren einen Paradigmenwechsel im Datacenter und fassen Lösungen für die obigen Themen bei der Skalierung zusammen

3-Tier-Architektur klassischer Rechenzentren

Traditionelle Rechenzentrums-Infrastrukturen, bestehend aus den drei Gewerken „Compute“, „Storage“ und „Network“, skalieren durchaus – allerdings in großen Schritten, denn Einschränkungen wie „Nutzungsdauer“, „Redundanz- und Hochverfügbarkeitsarchitektur“, „Min-/Max-Konfigurationen“ und „technische Abhängigkeiten“ müssen beachtet werden. Ein Ansatz wie „einfach ein paar zusätzliche Festplatten in ein Storage-Shelf zu stecken“, ist nicht möglich.

Zudem gibt es in der Regel einen dedizierten Auslöser für die Entscheidung, einen Skalierungsschritt zu gehen: Es werden mehr Ressourcen in einem der Bereiche Compute, Storage oder Netzwerk benötigt. Die beiden verbleibenden Bereiche werden nachrangig nur erweitert, um den führenden Bereich optimal zu stützen. Das Resultat ist ungleichmäßiges Wachstum der Gewerke.Konnten -in der Regel nach Abschluss eines Wochen oder Monate dauernden Prozesses- alle Unwägbarkeiten aufgelöst werden, erfolgt die Beschaffung. In der Regel wird sie so dimensioniert erfolgen, dass eine Wiederholung des Prozesses nicht in Kürze erneut nötig wird und sich die IT auf das fokussieren kann, was eigentlich ihr Job ist: Dem Unternehmen mit den Mitteln der IT einen Wettbewerbsvorteil zu verschaffen, indem sie Fachabteilungen optimal unterstützt.

Ergo: eine klassische 3-Tier-Infrastruktur skaliert, doch der Skalierungsschritt hat nie die angemessene Dimension, ist dafür aber wenigstens teuer und langwierig 😉

Comes in Hyperconvergence!

Die Worte „web-scale“ und „scale-out-Architecture“ definieren einen Paradigmenwechsel im Datacenter und fassen Lösungen für die obigen Themen bei der Skalierung zusammen. In einer HCI, einer „HyperConverged Infrastructure“, wird ein ähnlicher Ansatz verfolgt, wie in der Prozessor-Entwicklung: Performance durch Multiplizierung einfacher gleichartiger Module. Je mehr Module, desto höhere kumulierte Gesamtperformance, desto größere Workloads sind abbildbar. Zudem integriert Hyperkonvergenz Compute und Storage und reduziert damit Komplexität.

In einer Nutanix HCI sind Nutanix Nodes diese einfach aufgebauten gleichartigen Module: Commodity Server Hardware, lokaler Storage, ein Hypervisor sowie die „Controller VM“, eine virtuelle Maschine, die in Software die Intelligenz der Infrastruktur beherbergt:

Architektur

In einer Nutanix HCI gibt es zwar zentrale Datenhaltung hinsichtlich der Sichtbarkeit der Daten, nicht jedoch in Bezug auf deren tatsächlichen physischen Speicherort: Die Daten eines Nutanix-Clusters liegen im Distributed Storage Fabric (DSF). Das DSF kann man sich vorstellen wir eine Torte: Jedes Stück der Torte stellt den lokalen Massenspeicher einer Nutanix Node dar. Aus Hypervisor- Sicht erscheint das DSF jedoch wie ein zentrales Storage Array – tatsächlich wird sämtlicher Storage-Traffic auf der lokalen Node verarbeitet, um maximale Performance für Schreib- und Lesezugriffe zu gewährleisten.

Nutanix arbeitet folglich nach dem Prinzip der „Data Locality“, bei dem kein Storage-Traffic einer VM den lokalen Hypervisor verlassen und über Nadelöhre wie Ethernet oder SAN zu einem zentralen Storage transferiert werden muss: Die Daten einer VM befinden sich immer auf der Cluster-Node, auf der die VM ausgeführt wird. Zusätzlich erfolgen sämtliche Schreibzugriffe innerhalb einer Node initial auf das SSD-Tier.

Im folgenden Video ist zu sehen, wie die Schreib- und Lesezugriffe innerhalb einer Nutanix Node ablaufen:

Tech TopX: I/O Path (https://youtu.be/SULqVPVXefY)

Es wird offensichtlich, dass jede Nutanix Node für sich ein performantes „Virtualisierungs-Modul“ darstellt. In Konsequenz sind auch mehrere Module für sich performant – die Möglichkeit zur Skalierung in angemessen kleinen Schritten ist somit gegeben.

Da jedes Modul über lokalen Storage verfügt und Workloads nur auf diesen zugreifen, gleichzeitig aber sämtlicher Storage zentralistisch sichtbar ist und verwaltet werden kann, skaliert eine Nutanix HCI linear:

 

Software Defined

Diese lineare Skalierbarkeit basiert allerdings nicht nur darauf, dass Schreibzugriffe grundsätzlich lokal und auf SSDs erfolgen: Wenn ein Knoten 100 Performancepunkte leistet, sollen drei Knoten 300 Punkte bringen und 72 Knoten 7200.

Wie also sieht es mit der Skalierung des verteilten Systems, also des Nutanix Clusters aus? Verteilte Systeme müssen drei Anforderungen erfüllen:

  • Sie dürfen keine „Single Points of Failure“ besitzen, also müssen alle Komponenten verteilt implementiert sein
  • Flaschenhälse sind verboten, denn sie verhindern lineare Skalierung
  • Ihre Module müssen unabhängig voneinander miteinander funktionieren können, denn der Ausfall einer Komponente darf nicht das Gesamtsystem beeinträchtigen

Nutanix integriert daher fortschrittliche web-scale Softwaretechnologien wie Apache Cassandra (als Datenbank zur verteilten Speicherung von Metadaten) oder Apache Zookeeper (für das Cluster-Management), die von vornherein zur verteilten Nutzung entwickelt wurden. Sämtliche Komponenten sind darauf ausgelegt, auf mindestens drei Systemen im Cluster zu arbeiten, damit dieses jederzeit den Ausfall einer Node verkraften kann. Genutzt wird ein Master/Slave-System, bei dem der Master-Node den Takt angibt, aber alle Nodes denselben Datenstand halten. Wenn ein Master ausfällt, wählen die verbleibenden Nodes einen neuen.

In Nutanix verteiltem Management-Interface PRISM, das in der CVM jeder Node eines Nutanix Clusters ausgeführt wird, werden sowohl die aktuellen Cluster-Ressourcen dynamisch angezeigt, als auch ein visueller Forcast zur zukünftigen Entwicklung der Ressourcen-Nutzung erzeugt. Dies schafft Transparenz hinsichtlich der aktuellen Nutzung und ermöglicht, den Zeitpunkt einer Erweiterung exakt vorhersagen zu können.

Die Erweiterung eines Clusters ist zur Laufzeit möglich: die Ressourcen neuer Nodes stehen direkt nach ihrer Integration zur Verfügung.

Use-Case VDI

Der perfekte Use-Case für lineare Skalierung ist VDI: Die zu erwartende Workload ist in jeder Hinsicht vorhersehbar, wenn in der Planung bestimmte Typen von VDI-Profilen definiert werden (bspw. Task Worker, Power User, Developer, CAD-Designer).

Ein Unterschied bei der Nutzung einer Nutanix HCI im Vergleich zum klassischen Setup: Booten 100 VDI-Sessions gleichzeitig von einem SAN-Array, herrscht ein „Boot Storm“, da immenser Traffic entsteht – immer wieder gleiche Datenblöcken müssen durch das Nadelöhr SAN. Bei Nutanix- werden diese Daten genau einmal Mal vom Storage gelesen, sämtliche nachfolgenden Lesezugriffe werden aus dem Extent Cache der lokalen CVM bedient: direkt und mit maximaler Performance aus dem vRAM. So reduziert sich der Bedarf an IOPs pro Hypervisor-Host (also Nutanix Node) extrem.

VDI-Deployments werden schwierig, wenn mehr als 200 bis 300 VDI-Sessions benötigt werden, denn Netzwerk- und Storage-Last und damit das Risiko von „Contention“ steigen erheblich. Im klassischen SAN-Umfeld werden Metadaten von nur 1-4 SAN-Köpfen gelesen: je mehr Zugriffe, desto geringere Storage-Performance. Im Nutanix Cluster dagegen sind alle Metadaten redundant über das Cluster verteilt – es kann nicht zu Peaks kommen, denn die Zugriffe verteilen sich über alle Nodes. Je mehr Nodes im Cluster, desto höher die Performance beim Metadaten-Zugriff.

Zusammenfassung

Eine Nutanix HCI skaliert linear, weil:

  • Compute- und Storage-Ressourcen konvergent innerhalb jeder Cluster-Node vorhanden sind
  • Jede Node für sich performant arbeitet
  • Sämtliche Daten von virtuellen Maschinen lokal vorhanden sind
  • Alle Schreibzugriffe lokal und zunächst in den SSD-Tier erfolgen
  • Alle Lesezugriffe lokal erfolgen
  • Wiederholte Lesezugriffe direkt aus dem Extent Cache der CVM bedient werden
  • Sämtliche Softwarekomponenten mit dem Fokus auf verteilte Systeme entwickelt wurden
  • Verteilte Metadaten, verteilter Metadata-Cache
  • Von vornherein entwickelt als „Shared Nothing Distributed Architecture“

Related Posts