Acropolis File Services (AFS) Deep Dive

File Services, kaum ein Unternehmen kommt ohne den Datenzugriff über Netzlaufwerke aus. Die wohl gängigsten Use Cases sind unstrukturierte Daten in Form von Benutzerprofilen oder einfache Abteilungsordner.

Ein genereller Trend ist, weg von dedizierten NAS Systemen hin zu virtualisierten File Servern z.B. auf Basis von Windows, da man damit deutlich flexibler und nicht an die Hardware gebunden ist. Jedoch ist man aus Sicht der IT dann mit der Installation und dem Betrieb konfrontiert, welchen man dabei selbst übernehmen muss. Und genau hier möchte Nutanix der IT eine Möglichkeit bieten, File Services möglichst einfach zur Verfügung zu stellen und dabei die Aufwände für den Betrieb auf ein Minimum zu reduzieren.

Acropolis File Services (AFS) sind ein Weg, besagte File Services direkt über Nutanix zu provisionieren und zu verwalten. Der gesamte Prozess dauert dabei nur wenige Minuten und wird im Folgenden im Detail erklärt.

Wie werden File Services provisioniert?

Login in Prism >> Menü – File Server >> + File Server

AFS NewFS 00AFS NewFS 0

Die gesamte Verwaltung läuft über Prism und im ersten Schritt wird ein virtueller Fileserver erstellt. Dabei darf es durchaus mehrere File Server pro Nutanix Cluster geben, hier gibt es kein Limit. Derzeit werden VMware vSphere und Nutanix AHV als Hypervisor unterstützt.

Bevor das Deployment beginnt, müssen ein paar Dinge gegeben sein und dafür sorgt der Pre-Check, welcher den Benutzer dabei unterstützt die Anforderungen für das Deployment zu erfüllen.

AFS Pre-Check vSphere

AFS NewFS 1

Im ersten Schritt werden Name, Anzahl der File Server VMs (FSVMs) und die Größe des File Servers angegeben.

Die minimale Konfiguration besteht aus drei FSVMs à 4 vCPUs und 12GB RAM, bei einer Größe von 1TB (1024GB). Je nach Performance Anforderungen kann die virtuelle Hardware auch deutlich nach oben geschraubt werden, auf bis zu 12 vCPUs und 96GB RAM.

Alle FSVMs eines File Servers bilden zusammen einen Cluster, der entsprechend für die Performance und Verfügbarkeit der File Services zuständig ist.

fs_2b1Wichtig, der Name wird später entsprechend als oberster Zugriffspunkt für die Clients dienen und darunter die Shares eingehängt. Diese können aktuell von den Clients via SMB 2.0 und 2.1 zugegriffen werden. Der Name sollte maximal 15 Zeichen lang sein. Unterstützt werden derzeit primär Windows Umgebungen, als mit AOS 5.1 auch MAC Betriebssysteme.  Beispiel: \Fileserver1\Share1

Es wird empfohlen zwei getrennte Netzwerke zu verwenden, um Frontend Traffic zwischen Clients sowie Fileserver und Fileserver und Nutanix CVM zu trennen. Für kleinere Umgebungen wird jedoch auch ein einzelnes Netzwerk unterstützt.

Die Frontend IPs der FSVMs müssen entsprechend mit der Domäne bzw. DNS Server kommunizieren können.

Neben der manuellen Angabe von Gateway und Subnet, erfolgt die Zuweisung der eigentlichen FSVM IP Adressen per integriertem IP Address Management (IPAM), sprich es muss nur die IP-Range angegeben werden. Sind im Falle von AHV in Prism bereits Netzwerke mit entsprechender IPAM Konfiguration vorhanden, werden diese übernommen und es muss nichts weiter angegeben werden. Für vSphere müssen die IP-Ranges und die gewünschten Port Gruppen angegeben werden. Grundsätzlich wird für das Frontend n IPs, wobei n die Anzahl der File Server ist, benötigt und für das Backend n+1. Die Zusätzliche IP dient als Cluster Adresse des File Servers, über die das Cluster von den CVMs angesprochen wird.

Und zuletzt noch DNS und NTP Server.AFS NewFS 2 - neu

Das Storage Netzwerk dient der Kommunikation zwischen FSVMs und CVM, über diesen Weg wird der Storage für den Fileserver via iSCSI (Acropolis Block Services ABS) zur Verfügung gestellt. Daher empfiehlt es sich, die IPs aus dem gleiche Subnet als das der CVMs zu wählen.

AFS NewFS 3 - neu

Der Deployment Prozess übernimmt entsprechend auch die gesamte Active Directory (AD) Integration, indem alle nötigen Objekte im AD bzw. im DNS angelegt werden.

Der Benutzer muss entsprechend über Berechtigungen verfügen, diese Objekte anzulegen.

AFS NewFS 4

Mit AOS 5.1 gibt es auch die Möglichkeit den Domain Join zu überspringen, die Objekte manuell anzulegen und später mit einem Konto welches nur über reduzierte Berechtigungen verfügt der Domäne beizutreten. Dies ist vor allem da wichtig, wo der Zugriff auf das AD eingeschränkt ist.

Zum Abschluss des Deployments, wird auch eine Protection Domain (PD) mit allen Objekten die den Fileserver ausmachen erstellt. Diese PD kann später dann für lokale Snapshots oder eine asynchrone Replikation verwendet werden.

AFS NewFS 5

Am Ende hat das gesamte Deployment nur 10 Minuten gedauert.

AFS NewFS Task

Tipp: AFS wird bereits von der Nutanix App Mobility Fabric (AMF) unterstützt. Das heißt, es ist möglich einen Fileserver Hypervisor übergreifend (z.B. von ESXi auf AHV) zu replizieren und im Desaster Fall direkt dort zu starten.

Dazu ein kleines Video eines Kollegen. Danke Dwayne

vSphere DRS & AHV ADS Integration

Damit sichergestellt ist, dass die FSVMS nicht auf dem gleichen Host laufen, werden automatisch entsprechende DRS bzw. ADS Anti-Affinity Regeln angelegt, um die FSVMs voneinander zu trennen.

AFS AHV ADSAFS vSphere DRS

Damit ist der Deployment Prozess abgeschlossen und es kann damit begonnen werden, die eigentlichen Shares zu erstellen.

Shares

Grundsätzlich gibt es zwei Arten von Shares, einen so genannten „Home Share“ und unbegrenzt viele „General Purpose Shares“. Doch worin besteht der Unterschied?

Nach dem Deployment des File Servers, wird automatisch ein so genannter Home Share angelegt. Dieser ist ausgelegt auf viele tausende gleichzeitige Zugriffe der Benutzer.

AFS NewFS Share

So ist dieser Share über alle FSVMs verteilt, während die „General Purpose Shares“ jeweils von einer FSVMs gehostet werden. Das wichtige dabei ist, dass der Zugriff auf alle Shares für die Clients völlig transparent ist, dass heißt, hier muss man sich keine Gedanken über den korrekten Zugriff über die richtige FSVM machen. Im Falle des „General Purpose Shares“ ist dies relativ einfach, aber wie funktioniert das bei den verteilten „Home Shares“?

In diesem Fall greift AFS auf ein Microsoft Distributed File System (DFS) Feature zurück, DFS Referrals. Das bedeutet, dass die erste Ordner Ebene innerhalb des Home Shares (Top Level Directories) auf alle beteiligten FSVMs aufgeteilt wird. Das folgende Bild verdeutlich dies ganz gut, dabei ist jede FSVMs für einen Teil der Ordner zuständig. Greift ein Client auf einen Ordner über eine FSVMs zu, welche nicht für diesen verantwortlich ist, so wird der Client einfach an die korrekte FSVM weitergeleitet. Wie gesagt, für den Client ist dies völlig transparent. Somit kann jedoch die Last vieler tausender gleichzeitiger Zugriffe über mehrere FSVMs und damit mehrere physische Nodes verteilt werden.

AFS DFS HomeShares

Auf Ebene der Shares können verschiedene Einstellungen getroffen werden, dazu zählen ABE & WPV sowie Quota Policies. Unterstützt werden auch versteckte/hidden Shares, die mit einem $ enden.

AFS New Share

Access Based Enumeration (ABE):

  • Zeigt dem Benutzer nur Objekte auf die er auch tatsächlich Berechtigungen hat.

Windows Previous Version (WPV):

  • Snapshots (in Guest der FSVMs) – Bei WPV handelt es sich um eine wichtige Funktion, vor allem um Anfragen an die IT zu reduzieren, damit Benutzer selbständig Dateien wiederherstellen können. Das heißt eine Integration in die „Windows Vorgängerversionen“ auf Dateiebene ist essentiell und wird entsprechend auch von AFS unterstützt. Hier wurde mit AOS 5.1 in Prism die Möglichkeit ergänzt, die Häufigkeit bzw. Retention Policies der entsprechenden Snapshots nach eigenen Anforderungen zu definieren.

AFS WPV Schedule

Das Ergebnis sieht dann wie folgt aus.

AFS WPV

Nach Erstellung des Shares, kann optional noch ein oder mehrere Quotas eingerichtet werden, inkl. E-Mail Alarme bei entsprechender Verletzung.

AFS Quotas

Harte Limits können nicht überschritten werden und es wird verhindert, dass neue Daten geschrieben werden können. Während im Gegensatz dazu Soft Limits überschritten werden können und nur die eingetragenen E-Mail Empfänger alarmiert werden. Pro Share können auch mehrere Quota Policies für verschiedene Benutzer und Gruppen erstellt werden.

Hinweis: Wenn eine AD-Gruppe angegeben wird, so erhält JEDER Benutzer innerhalb der Gruppe diese Quota. Also z.B. 10 Benutzer und 100GB Quota entspricht 10 x 100GB = 1TB. Ist ein Benutzer Mitglied mehrerer, angegebener Gruppen, so erhält er die Quota mit der größten Kapazität.

AFS Quotas2

Es empfiehlt sich nach Erstellung eines Shares die Berechtigungen entsprechend auf die gewünschten Abteilungen (AD Gruppen) anzupassen, bevor diese mit Inhalt gefüllt werden. Die Default Berechtigungen sehen dabei wie folgt aus:

HOME SHARES

  • Domain Administrator: Full access
  • Domain User: Read only
  • Creator Owner: Full access – Subfolders and Files only

Wichtig: Aktuell sollten die Top Level Directories innerhalb des Home Shares nicht manuell angelegt werden, sondern z.B. über Active Directory, sodass die Ordner direkt mit dem richtigen Namen des Benutzers angelegt werden und nicht manuell umbenannt werden müssen.

AFS AD Userprofile3

GENERAL PURPOSE SHARES

  • Domain Administrator: Full access
  • Domain User: Full access
  • Creator Owner: Full access – Subfolders and Files only

Eine weitere Besonderheit wurde mit AOS 5.1 eingeführt. Der bisherige Prozess hätte Benutzerprofile wie folgt abgelegt: \fileserver1\homeshare\benutzername. Was aber, wenn in bestehenden Umgebungen die Client Konfiguration bereits überall auf \fileserver\benutzername zeigt? AFS lässt sich per Advanced (cli) Setting so anpassen, dass die Ordner der Benutzer als „Share“ präsentiert werden, sodass der Pfad am Ende so aussieht \fileserver\benutzername und keine Anpassungen der Clients notwendig ist.

Backend Storage

Wie bereits erwähnt, wird der Backend Storage durch Acropolis Block Services (ABS) via iSCSI zur Verfügung gestellt. Ohne zu sehr in die Details von ABS einzutauchen, denn dazu existiert bereits ein eigener Artikel, soll zumindest die Grundlage geschaffen werden um zu verstehen, wie die Hochverfügbarkeit & Skalierbarkeit des File Servers möglich gemacht wird.AFS ABS VGs

Alle FSVMs greifen auf so genannte Volume Groups (VGs) über ABS via iSCSI zu. Volume Groups organisieren die eigentlichen vDisks (Anzahl, Größe) und wer darauf zugreifen darf (IP, IQN). Während des Deployments eines AFS File Servers, werden automatisiert alle benötigen VGs erstellt und die iSCSI Sessions zwischen FSVMs und CVM entsprechend hergestellt. Jede CVM kann auf jede VG zugreifen, so kann im Fall eines Ausfalls einer FSVM, eine andere FSVM die dann „ausgefallenen“ VGs und die dazugehörigen Shares übernehmen und die Daten weiter an die Clients präsentieren. Genauso einfach können die Disks unter den FSVMs neu verteilt werden, um einen Lastenausgleich zu erreichen, aber dazu gleich mehr.

Der „Home Share“ ist dabei über mehrere FSVMs und mehrere VGs verteilt, wohingegen „General Purpose Shares“ auf eine FSVM und eine VG „limitiert“ sind. Das derzeitige Limit eines solchen Shares liegt bei 40TB an Daten und bei „Home Shares“ bei 200TB.

Ist das darunter liegende Nutanix Container, in dem vDisks gespeichert sind, oder die File Server Kapazität zu 90% genutzt, erhält der Administrator entsprechende Alarme via Prism.

Durch die Verwendung der Distributed Storage Fabric (DSF), kann natürlich entsprechend auch die Capacity Optimization Engine (COE) verwendet werden, mit z.B. Deduplizierung, Komprimierung und Erasure Coding (ECX).

Skalierbarkeit

Eine weitere Besonderheit von AFS ist die integrierte & automatisierte Skalierbarkeit. Es wird dauerhaft die Auslastung der einzelnen FSVMs überwacht und wenn entsprechende Schwellwerte überschritten sind, erhält der Adminitrator über Prism eine Möglichkeit die Performance zu optimieren. Die dazu nötigen Schritte sind komplett automatisiert, der Benutzer hat jedoch die Möglichkeit zu entscheiden, wie er optimieren möchte:

AFS Alert Perf. Opt.

Scale-Up: Hier werden den FSVMs mehr vCPUs und RAM hinzugefügt, ab AOS 5.1 erfolgt dies vollständig online ohne Service Unterbrechung, indem die Ressourcen im Hot-Add Verfahren hinzugefügt werden.

Rebalance: In diesem Fall werden die Backend Disks, auf denen die eigentlichen Files abgelegt sind, neu zwischen den einzelnen FSVMs verteilt, um z.B. Hotspots durch zu viele Zugriffe auf einer einzelnen FSVMs zu eliminieren.

Scale-Out: Diese Option rollt zusätzliche FSVMs aus, über welche dann die Gesamtlast verteilt werden kann.

In allen drei Szenarien entstehen keine zusätzlichen administrativen Aufgaben, denn der gesamte Prozess ist vollständig automatisiert.

Fehlerszenarien

Ein AFS Cluster ist natürlich so designed, das alle möglichen Fehler der einzelnen Komponenten abgefangen werden können.

FSVM Ausfall

  • Eine andere FSVM übernimmt die Ownership der VGs, importiert das Filesystem (via Metadaten) und Clients können dann direkt wieder auf die Daten zugreifen.

CVM Ausfall

  • Im Prinzip ein ABS Thema, die VGs werden von einer anderen CVM übernommen und die FSVM muss lediglich neue iSCSI Sessions zu den benötigten VGs (vDisks) über die neue CVM herstellen.

Host

  • In diesem Fall treten ja beiden oben genannten Fehler ein, sodass quasi beides parallel abläuft.

Software (File Server) Upgrades

Als Teil der Nutanix 1-Click Philosophie, kann der File Server auch unabhängig von AOS via Prism aktualisiert werden. Sofern das Cluster mit dem Nutanix Support Portal kommunizieren kann, ist es möglich von dort die neuste Software direkt herunterzuladen. Diese kann dann über ein automatisiertes, rollierendes Upgrade auf allen FSVMs ausgerollt werden. Diese sind derzeit jedoch nicht Non-Disruptive, da als Teil des Upgrades natürlich die FSVMs neu starten und so die bestehenden Client Connections auf andere FSVMs übertragen werden müssen.

AFS Upgrade Software

Nutanix Acropolis File Service – Dateidienste waren noch nie so einfach

Seit der AOS Version 5.0 sind die Acropolis File Services, kurz AFS, nun vollwertiger Bestandteil des Nutanix Acropolis Stacks. In gewohnter 1-Click-Manier lassen sich nun Dateidienste, z.B. ein SMB Share, bereitstellen.

In diesem Beitrag möchte ich an einem praktischen Beispiel zeigen wie einfach File Service mit Hilfe der Enterprise Cloud Plattform zu planen, implementieren und betreiben sind.

Bei diesem Beispiel gehen wir von einer VDI-Umgebung für 500 Concurrent User aus, diese 500 Desktops werden im Zuge eines Dreischichtbetrieb genutzt und somit werden 1500 User Profile benötigt. Im folgenden sieht man ein Nutanix Sizing für die eigentlichen Desktops.

Für die 500 Benutzer werden, abhängig vom gewählten Benutzerprofil, sechs Nutanix NX-3060-G5 Nodes mit jeweils 28 Cores, 512GB Memory und 2,88TB Flashspeicher benötigt.

Die Planung

Dank extensiver Lasttest ist es dem Nutanix Entwicklungsteam möglich, anhand bestimmter Parameter, wie z.B. Art des Shares, gleichzeitige Benutzer zugriffe und des benötigten Speicherplatzes, zu bestimmen, mit welcher Konfiguration die Acropolis File Services bereitgestellt werden müssen.

Diese benötigten Werten lassen sich ebenso einfach in den Nutanix Sizer eintragen, wie die Angaben zu den eigentlichen Desktops. Dieser gibt eine entsprechende Empfehlung bzgl. der benötigten Nutanix Nodes aus, um zusätzlich noch die File Services bereitzustellen.

Hierzu wählt man zunächst den gewünschten Workload Type (File Services) und den Use Case (Home Directory / User Profile) aus.

Anschließend werden die Details für den Use Case definiert. In unserem Fall benötigten wir Speicherplatz für 1500 Benutzerprofile, müssen aber nur 500 davon gleichzeitig bereitstellen. Entsprechend sind die Werte „Number of Total Users“ auf 500 gesetzt und „Total Storage Requirements“ auf 2048 GiB. Jeder Benutzer bekommt als ca. 1,5GB Speicherplatz.

Abschließend kann noch die Frequenz und Anzahl der Snapshots definiert werden. Dahinter steckt die Möglichkeit mittels Windows Previous Versions Dateien wieder herzustellen, sowohl als Administrator als auch Benutzer selbst.

Nachdem der File Server Workload hinzugefügt wurde passt der Nutanix Sizer das Szenario automatisch an. In unserem Fall können die File Services mit der bestehenden Compute-Leistung abgedeckt werden, lediglich mehr Speicherplatz wird benötigt. Aus diesem Grund erhöht der Sizer einfach die Bruttospeicherkapazität pro Node von 2,88TB auf 4,80TB.

Die Architektur

AFS ist nicht Bestandteil der Nutanix Controller VM (CVM) sondern wir als separater, hochverfügbarer File Server Cluster bereitgestellt.

fs_2b

Genutzt werden die gleichen Prinzipien der Nutanix Web-scale Plattform, d.h. es werden immer mindestens drei virtuelle File Server bereitgestellt um eine Hochverfügbarkeit sicherstellen zu können.

Ein weiterer Vorteil ist, dass AFS unabhängig von den eigentlichen CVMs läuft und so einen unabhängigen Upgradepfad hat, somit können Updates für die File Service schneller und ohne Auswirkungen auf die herkömmlichen CVMs durchgeführt werden.

Die File Services werden über die Acropolis Block Services (ABS) mit Speicherkapazitäten aus einem Nutanix Cluster versorgt.

Die Inbetriebnahme

Die Inbetriebnahme der Acropolis File Services setzt lediglich folgende Dinge voraus:

  1. Einen bestehenden Nutanix Cluster mit freien Ressourcen
  2. Das AFS Installationspaket wurde auf dem Cluster geladen
  3. IP-Adressen, FQDN und Domänen-Account

Der Rest der Konfiguration wird durch den Pre-Check und den Deployment Wizard begleitet.

AFSDeployment

Nachdem der File Server über den Deployment Wizard erstellt wurde können über den „Create Share“ Wizard die gewünschten Netzwerkfreigaben inkl. Funktionalitäten wie Access Based Enumeration und Windows Previous Versions angelegt werden.

AFS New Share

Anschließend stehen die File Server über die bei der Erstellung angegeben IP-Adresse bzw. FQDN zur Verfügung, z.B. \fs-mgmt.ntnx.test\FiBu.

 

Die Wartung

Die Wartung von AFS ist kinderleicht. Um genau zu sein, gibt es zwei Situationen in welchen man als Administrator eingreifen muss:

  • Aktualisierung von AFS auf eine neue Version
  • Erweiterung (Scale-up oder Scale-out) der AFS im Zuge neuer Anforderungen

Die Aktualisierung erfolgt wie gewohnt über das 1-Click-Upgrade. In wenigen Schritten lassen sich die File Services aktualisieren. Neben den üblichen Sicherheits- und Bugfixes kommen natürlich auch neue Features via 1-Click-Upgrades.

AFS Upgrade Software

Stand heute (Version 5.0) ist jedoch zu beachten, dass 1-Click-Upgrades der Acropolis File Services, im Gegensatz zu den AOS Upgrade, disruptive sind außerhalb der Geschäftszeiten bzw. in einem Wartungsfenster durchgeführt werden sollten. Grund hierfür ist die fehlende Unterstützung von SMB 3.x mit welcher in künftigen Versionen zu rechnen ist.

Die Erweiterung hingegen lässt im laufenden Betrieb durchführen. Ein Grund hierfür könnte z.B. eine wachsende Anzahl an Nutzern sein der eine Erweiterung der File Services benötigt.

AFS Alert Perf. Opt.

Dank der integrierte Maschinenintelligenz erkennt AFS eigenständig ob es zu einem Engpass kommt und empfiehlt einen Scale-out oder Scale-up.

In kürze folgt hierzu ein Deep Dive Artikel, der einen noch tieferen Einblick in die Technologie von AFS ermöglicht.

Nutanix VMware vSphere Web Client Extension nun verfügbar

Mit der Veröffentlichung der Nutanix AOS Version 5.1.4 werden die Träume alle VMware Admins endlich wahr und Nutanix liefert eine native Integration in den vSphere Web Client.

Dank der aktuellsten Adobe Flash Entwicklungen ist es Nutanix nun möglich die agile, Browser- und Betriebssystem-unabhängige, auf HTML 5-basierende PRISM Administrationsoberfläche abzulösen.

vmware_vsphere_web_client0f1cc62970e7b8be11cd4d7662c4ac36

Mit Hilfe der modernen, verschachtelten Kontextmenüs kann man nun über den vSphere Web Client neuen Speicherbereich bereitstellen und Snapshots/Klone erstellen.

vmware_vsphere_web_client_32b701a43e4be9e54bc569ce3f5123e74

Vorbei sind die Tage an welchen all solche Funktionen automatisiert über die VAAI-Integration ohne zusätzliche Menüs darstellbar waren. Auch bieten wir jetzt endlich eine Abhängigkeit zum vCenter und können unabhängig von diesem nicht mehr den Nutanix Cluster verwalten.

 

Nutanix Cluster Erweiterung (Scale-Out)

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:

 

Node Rebalancing

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

 

 

 

 

 

ntnx_storagepool_3

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