Right Sizing – Make it simple mit Nutanix

Dieser kurze Artikel soll allen interessierten zeigen welche Hilfen Nutanix bietet um ein korrektes Sizing einer Nutanix Umgebung, auch mit unterschiedlichen Workloads zu berechnen und durch zuspielen.

Qualität des Input schafft Qualität beim Output

Bevor wir und den „Nutanix Sizer“ ansehen, möchte ich ein paar Worte zu den Workload Daten verlieren. Ein altes Sprichwort sagt „Bullshit in = Bullshit out„, was soviel bedeutet wie. Schlechte Datenrecherche und schlechte Qualität der Eingangsdaten erzeugen auch eine schlechte Qualität der Ausgabe Daten.

Wenn man also bei der „Erhebung“ der Workload oder Leistungsdaten schlampt, kann selbst das beste Tool keine guten Ergebnisse daraus generieren. Daher, bitte für eine gute Datengrundlage sorgen. Die Workload oder Application Experten der Kunden sind hier die besten Informationsquellen. Existieren die Workload schon, dann kann man sicher reale Betriebsdaten aus den Systemen ziehen. Die bekannten „RV-Tools“ sollen hier nur als Beispiel dienen.

Der Nutanix Sizer

Nutanix stellt allen Consultans, SEs und Partnern ein Online Tool zur Verfügung welches aus eingegebenen Workload Daten die benötigte Nutanix (oder auch OEM etc.) Infrastruktur berechnet. Diese Tool nennt sich „Nutanix Sizer“

SizerLoginScreen

Bild 1: Nutanix Sizer Login Screen [https://services.nutanix.com/#/]

Aufbau und Struktur im Sizer

SizerScreen

Bild 2: Sizer Home Screen

Bild 2 zeigt des Home Screen des Sizers. Wie man sehen kann existieren hier verschiedene sogenannte „Scenarios“. Ein Scenario ist praktisch ein „Kundenumgebung“ die einen oder mehrere Workloads enthalten kann. In dieser Übersicht sieht man direkt wir die Scenarios in Bezug auf CPU, RAM, SSD und HDD Auslastung gesized sind.

Es ist möglich solch ein Scenario mit anderen Nutzern des Sizers zu sharen! Sehr hilfreich wenn man Kollegen oder Partner in den Sizing Prozess einbeziehen möchte. Der Kollege kann das Scenario allerdings nicht bearbeiten, sondern nur lesen. Will man ein gesharedes Scenario bearbeiten kann man es allerdings in den eigenen Bereich clonen.

Lets Start – Ein Durchgang durch den Sizer

Starten wir einfach einen Durchgang durch ein Sizing. Wir starten dazu immer mit einem neuen Scenario.

NewScenario

Bild 3: Neues Scenario anlegen

In Bild 3 sehen wir den Dialog für ein Neues Scenario. Hier einen sinnvollen Namen eingeben und (wenn die Berechtigung vorhanden ist) den Appliance Hersteller auswählen. Normalerweise sind das min. die Nutanix NX Modelle. Partner finden hier aber auch, je nach Partnerstatus, Modelle unserer OEMs bzw. unterstützter Plattformen.

Direkt nach Anlegen eines neuen Scenarios fragt der Sizer den ersten Workload ab.

FirstWorkload

Bild 4: Workload anlegen

Der Nutanix Sizer bietet verschieden vordefinierte Workload Typen an die direkt ausgewählt und mit den entsprechenden Parametern abgefragt werden.

Hat man qualitative Daten über den Workload wie z.B. Anzahl der geforderten vCPUs, vCPU Ration, geforderten vRAM, gewünschte Verteilung von HDD und SSD oder gar All-Flash dann kann man z.B. den Workload Type „RAW input“ wählen.

Für alle anderen Workloads werden typische Parameter oder Kennzahlen abgefragt (z.B. bei VDI ob vmware View oder Citrix Xen Desktop zugrunde gelegt werden sollen).

VDI-CitrixExample

Bild 5: Beispiel Citrix Xen Desktop Workload – User Type etc.

Als Beispiel soll hier einmal eine Abfrage für einen VDI Workload basierend auf Citrix Xen Desktop dienen. Wie am im Bild 5 sehen kann gibt der Sizer für einen User Typ „Task Worker“ gewisse Vorgaben vor. Diese sind selbstverständlich anpassbar (rechts). Passen die Parameter muss man einfach die Anzahl der User dieses Typs und verwendeten Provisioning Typ auswählen und der Sizer kann die benötigte Umgebung berechnen. Anschließend fragt der Sizer ob Parameter „customized“ werden sollen (Anzahl vCPUs etc.) und ob diese VMs mittels Nutanix Mitteln geschützt werden sollen.

VDI-CitrixExample-ContainerRep

Bild 6: Information zum Container für diesen Workload

In Bild 6 sehen wir die Abfrage nach den Containereigenschaften für diesen Workload. Es wird default von einem Replikationsfaktor für die Daten von 2 ausgegangen. Wir lassen im Beispiel alles bei den Defaultwerten und können dann den Workload abspeichern.

Der Sizer errechnet uns nun eine mögliche Nutanix Umgebung für diesen Workload (siehe Bild 7).

VDI-CitrixExample-Summary

Bild 7: Output des Scenarios mit dem beschriebenen Beispiel Workload

Da ich im Beispiel angegeben habe „Store User Data in AFS Home Directory“ wurden direkt zwei Workload angelegt. Einer für meine „Invisible VDI“ Umgebung und ein zweiter für die User Home Directory’s in einem Acropolis File Service [AFS] Share.

Zwischenbilanz

Wenn dieser erste automatische Sizing Entwuf noch optimiert werden soll, so ist auch das möglich. Jeder Workload kann editiert werden und auch das automatische Sizing kann manuell nachgearbeitet werden. Hier ist es z.B. möglich schnellere CPUs oder größere bzw. kleinere RAM Module zu verwenden (soweit für das Modell angeboten). Man kann auch den Sizer anweisen nur bestimmte Appliance Modelle zu nutzen bzw. auszuschließen.

Manuel-Sizing

Bild 8: Automatic oder Manual Sizing Modus

Bild 8 zeigt den Dialog in dem man vom Automatic auf den Manual Sizing Modus umschalten kann. Hier können NX Modelle gewählt oder ausgeschlossen werden und weitere Rahmenparameter eingestellt werden.

Ergebnis Download – BOM

Wenn das Sizing Ergebnis den Erwartungen Entspricht kann man direkt aus dem Sizer ein sogenanntes „Bill of Material“ BOM als PDF downloaden.

BOM-Download

Bild 9: Download BOM

Bild 9 zeigt den Download Dialog.  Einem symbolischen Rack View, den Sizing Details und den empfohlenen SKUs anreichern. Man erhält so ein vollständiges Dokument inkl. aller relevanten Information für ein qualifiziertes Vertriebsgespräch.

Financial Analysis sind, meines Wissens für Partner nicht verfügbar.

BOM

Bild 10: Deckblatt BOM

Fazit

Dieser Beitrag gibt sicher nur einen unvollständigen Überblick über die Möglichkeiten des Nutanix Sizers. Mit den korrekten Daten gefüttert ist es hier sehr leicht Möglich verlässliche Sizing Informationen zu einem geplanten Projekt zu ermitteln. Da der Sizer in Echtzeit arbeitet und man Scenarien sharen und auch clonen kann ist es leicht möglich verschiedene Möglichkeiten einer Projekt Realisierung mit Nutanix durch zuspielen. Bei korrekten Eingabedaten geben wir die Garantie das die anvisierte Lösung den Erwartungen entspricht!

Nutanix und SRM

In letzter Zeit wurde ich häufiger von Kunden und Partnern auf Nutanix und VMware Site Recovery Manager (SRM) angesprochen. Einige hatten irgendwo gehört oder gelesen, das ginge nicht zusammen oder sei von VMware nicht supported. Ein Blick auf die Website von VMware verrät zumindest schon mal, dass der Storage Replication Adapter (SRA) von Nutanix für SRM 6.1 von VMware supported wird. Aktuell nur die AOS Versionen 4.6 und 4.7. AOS 5.0 wird bald folgen.

Link zum VMware Compatibility Guide

vmwarecompatbguidesrm

Was ist der SRA und was kann er?

SRAs für den SRM gibt es von vielen Storage-Herstellern. Diese erlauben es dem SRM Snapshots und Replikation auf den Storage auszulagern und damit die Performance erheblich zu verbessern. Würde man die Snapshots einfach nur mit VMware Bordmitteln von einem Host auf einen anderen Host kopieren, wäre die Replizierungs-Performance der Snapshots nicht optimal. Gerade bei langen Snapshot-Ketten kann dies sehr langsam sein.

Auch Nutanix stellt einen SRA als Plugin für den SRM Server bereit. Er kommuniziert über die PRISM REST APIs mit dem Nutanix Cluster. So kann SRM mit Hilfe des SRA eine sogenannte ”Array-Based Replication” (ABR)  über die Nutanix eigenen Snapshots & Replizierung durchführen.

Architektur

Folgendes Schaubild zeigt eine vereinfachte Darstellung eines SRM-Setups. vCenter und SRM Server liegen in der Praxis natürlich nicht auf derselben Infrastruktur, sondern  in der Regel auf einem eigenen Management Cluster. Dies ist nur zwecks Vereinfachung hier so dargestellt:

SRMSetup

Das SRM-Setup besteht aus zwei Seiten, zwei Rechenzentren oder zwei Brandabschnitten. Die sogenannte „Protected Site“ ist typischerweise die produktive Seite, in der auch die VMs primär laufen. Die sogenannte „Recovery Site“ ist die Ausfallseite, auf welcher die VMs im DR-Fall neu gestartet werden sollen. Auf jeder Seite läuft ein Nutanix-Cluster bestehend aus mindestens drei Hosts, entsprechend mit ESXi als Hypervisor. Die zu schützenden VMs befinden sich in einem so genannten Storage Container, was auf Seiten des ESXi als Datastore angebunden wird. Der Name des Containers/Datastores muss auf beiden Seiten gleich sein. Warum das so sein muß, sehen wir wenn wir uns die vStores ansehen.

vStores

Ein vStore ist ein separater Mountpunkt innerhalb eines Containers mit einem eigenen NFS Namespace. Dieser NFS Namespace wiederum bezieht sich in Nutanix auf eine sogenannte Protection Domain. Die Protection Domain umfasst dabei die zu schützenden VMs, ähnlich eines Backup Sets. Jeder vStore bzw. jede Protection Domain, wird als Device über den Nutanix SRA exportiert. Man muss explizit einen vStore auswählen, ansonsten werden die VMs nicht vom SRM geschützt. Der Name des vStores muss auf beiden Seiten gleich. Da dieser sich vom Containernamen ableitet, müssen also die Container auf beiden Seiten den gleichen Namen haben.

Wichtig!

Eine VM kann nur exklusiv über den SRA geschützt werden. Eine parallele Sicherung mit nativen Nutanix Snapshots ist nicht möglich.

SRA ist derzeit in der Version 2.2 verfügbar und unterstützt SRM 6.1/6.0/5.8/5.5U1/5.5

Der Adapter steht im Support Portal zur Verfügung:

http://download.nutanix.com/utils/Nutanix-SRA-2.2-Setup.exe.

Weitere Informationen zur Installation und Konfiguration findet man dort ebenfalls:

http://download.nutanix.com/guides/additional_releases/SRA/Nutanix_SRA_for_SRM.pdf

IT-Fachkräftemangel – Ein kleiner Denkanstoß

StudieSeit einigen Jahren besteht in der IT ein stetig wachsender Fachkräftemangel. Auf vielen Webseiten und in unzähligen Studien, wie der Bitkom Studie, wurde darüber berichtet. Wahrscheinlich suchen auch Sie händeringend einen Storage- oder Virtualisierungsadmin, Programmierer und andere, die sich um all die vielen Aufgaben kümmern, die anfallen um eine komplexe Multi-Vendor, Multi-Tier Architektur am Laufen zu halten. Kommen Ihre Entwickler auch immer öfter zu Ihnen und brauchen schneller Systeme als sie diese bereitstellen können?

Hier und da werden dann mal auf die schnelle AWS, Azure oder andere Clouddienste genutzt, weil es schnell und einfach geht, wie ein Smartphone. Kann das Teil einer unternehmensweiten IT-Strategie sein?

Ist das die digitale Revolution? Revolution – sicher, aber ob die Richtung stimmt?

Eigentlich sollten Unternehmen sich schon lange zusammen mit den Fachabteilungen über die nächsten Strategien und Umsetzungen von IT 4.0, Digitale Transformation, Cloud (ja ist immer noch ein Thema) und nicht zu vergessen der IT-Sicherheit abstimmen. Aber die Zeit und das Personal fehlt, um Freiräume zu schaffen.

Mal ehrlich, was sind die Top-Schlagworte, die Sie bisher immer in Verbindung mit neuen IT-Architekturen gehört haben.

  • Einfach zu administrieren

  • Bedarfsorientiert wachsen

  • Zukunftssicher

  • Cloudbasiert

  • Bester Service und Support

Und war das jemals einfach? SAN-Zoning, LUN-Masking, Portmapping, Volumegruppen oder Arrays anlegen, planen und konfigurieren, etc. Neuer Hersteller – neue Schulungen. Das Schulungsbudget geht für die Rezertifizierung oder eine Umschulung auf neue Systeme drauf, anstatt die Mitarbeiter in neuen Themen zu schulen, die für ihren geschäftlichen Erfolg wichtig wären.

Wie oft hat das Sizing Ihrer Infrastruktur gepasst? Waren Sie je flexibel genug, um schnell auf die nächsten Anforderungen zu reagieren? Wenn Sie bis hierher durchgehalten und das ein oder andere mal genickt haben, möchte ich Ihnen eine mögliche Lösung aufzeigen.

Was wäre, wenn die oben genannten Schlagworte zutreffen würden. Marketing, Traum oder die Realität? Für Nutanix sind das nicht nur Schlagworte. Lassen sie mich näher auf die genannten Schlagworte eingehen.

  • Einfach zu administrieren

Prism GuiEine einfache HTML5 Oberfläche mit der so gut wie alles administriert, überwacht und konfiguriert werden kann. Wenn sie nicht auf bunte Oberflächen stehen und lieber in der Shell oder der Commandline arbeiten, kein Problem. Plattenpools oder Datastores anlegen und an die vorhandenen Hosts mappen mit nur einem Klick. Einen Cluster erweitern und damit auf neue Situationen reagieren mit einem anderen.

LCMDurch unser 1-Click update und unsere Life Cycle Management Implementierung sind selbst Updates der gesamten Plattform einfach und schnell erledigt. Hypervisor-, BIOS- und Storage (inkl. HDDs, SSDs, HBA), erledigt das System wie von selbst. Und der Clou, demnächst auch Cluster übergreifend, z.B. für Außenstellen.

performanceMit unserer Prism Weboberfläche haben Sie die wichtigsten Analyse- und Performanceindikatoren  ohne vorher zusätzliche Software zu installieren geschweige denn zu lizenzieren. Infrastruktur- und Hypervisor Management out off the box. Alle Informationen, bis runter zum Füllgrad, der Performance und der aktuellen Latenz einer einzelnen SSD, werden in Prism dargestellt.

  • Bedarfsorientiert wachsen

ClusterexpandEine Erweiterung eines Clusters erfolgt mit wenigen Klicks. Die neuen Systeme werden, sofern noch Platz vorhanden ist, in das Chassis gesteckt, verkabelt und eingeschaltet. Bei der Clustererweiterung wird im Anschluss ausgewählt welche Nodes oder Blöcke mit in den Cluster aufgenommen werden soll. Anschließend noch die IP-Adressen eintragen. Zur Not muss noch ein Hypervisor ISO mit angegeben werden. Das ist alles, den Rest macht unsere 1-Click Cluster Erweiterung in ihrer Pause.

 

  • Zukunftssicher

hostsDie Systeme sind abgeschrieben und sollen aus dem Cluster genommen werden, auch kein Problem. Mit dem Remove Host, werden die VM´s und Daten von dem bestehenden Cluster migriert und der Knoten kann dann einfach ausgetauscht werden.

 

  • Cloudbasiert

AHV_LogoUnser eigener Hypervisor – AHV ist ein Hypervisor, der für die Cloud entwickelt wurde. Unsere Dienste, wie beispielsweise die Prism UI, sind keine singulären Dienste sondern über jeden Knoten im Cluster verteilt. Web-Scale durch und durch und für diesen Zweck konzipiert, nicht aus einem bunten Portfoliomix kreiert.

Wir integrieren uns nahtlos in OpenStack, und bieten Docker und anderen Lösungen eine Plattform. AHV bietet die wichtigsten Funktionen wie unter anderem HA und ähnliche Verfügbarkeitsmechanismen ohne Aufpreis an.

Scale-Out als Konzept stammt von den großen Firmen, wie Google, Facebook oder Amazon. Diese Firmen haben erkannt, dass man in modernen IT-Umgebungen nicht mehr die Möglichkeit hat einzelne Servern und deren IP’s zu wissen. Was in kleineren Umgebungen wunderbar funktioniert, in großen Umgebungen ist das nicht mehr so einfach. Auch sollten sich die Administratoren eher um Wichtigere Angelegenheiten kümmern, wie zum Beispiel Applikationen und Dienste am Laufen zu halten.

Die eigene Infrastruktur sollte ein Konsumptionsmodell ermöglichen, ähnlich wie bei den aktuellen Cloudanbietern, bei denen ich mich nicht auf die Kenntnisse und Befindlichkeiten von einzelnen verlassen muss, sondern meine Ressourcen nach Bedarf abrufen kann.

Web-Scale bedeutet auch, Entscheidungen zu treffen damit das System sich selbst heilen kann, und nicht ewig lange zu hoffen das ein Admin eingreift um die Gesundheit einzelner Komponenten wiederherzustellen.

All dies sind Konzepte, die in größeren Unternehmen ausschlaggebend für den Erfolg und die Flexibilität sind, können mit Hilfe von Nutanix auch in kleinen und mittleren Umgebung für Flexibilität sorgen. Ganz ohne die Riesen IT-Mannschaft.

 

  • Bester Service und Support

NETPromoterEigenlob ist hier nicht angebracht, deshalb lassen wir uns über den Net Promoter Score bewerten. Und um den Service wirklich zu testen, hilft nur selbst erleben und testen. Am besten mit einem Try & Buy, falls sie noch kein Kunde sind.

Oder Fragen sie unsere Kunden, die werden Ihnen das gerne bestätigen, sofern sie schon Kontakt hatten.

So ich hoffe sie stimmen mir bei meinem kleinen Denkanstoß zu. Wenn sie mehr erfahren wollen sind wir gerne für sie da.

 

Acropolis File Services (AFS) Deep Dive

Der Deep Dive entspricht derzeit AFS 2.2

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 File Server 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.

AFS2.2 Update: AFS hilft jetzt auch beim Deployment, die Anzahl der FSVMs und der virtuellen Hardware, basierend auf dem zu erwartenden Workload, korrekt zu bestimmen. Die Workload-Angaben erfolgen in Form der gleichzeitigen Sitzungen und Durchsatz-Anforderungen.

AFS-Deployment-Recommendation

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 SMB2.0 und 2.1 und Seit AFS 2.2 auch via SMB3.0* 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

*In Version AFS 2.2 werden Advanced SMB3.0 Features wie z.B. Continuous availability/Transparent fail-over oder Multi-Channel noch nicht unterstützt.

Es wird empfohlen zwei getrennte Netzwerke zu verwenden, um Frontend Traffic zwischen Clients sowie File Server und File Server 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 File Server 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 File Server 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 File Server 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

Hierzu werden die Snapshots der Nutanix Distributed Storage Fabric (DSF) verwendet. Diese werden wie immer über so genannte „Protection Domains“ (PD) konfiguriert. In eine PD werden alle File Server VMs und dazugehörigen Backend vDisks aufgenommen und mit einem Snapshot Schedule versehen, sodass entweder nur lokale oder auch remote Snapshots auf einem weiteren Nutanix Cluster erstellt werden.

AFS_PD_Overview

AFS 2.1 Update: Auch ist es jetzt möglich, besagte Snapshots als Quelle zu verwenden um den gesamten File Server zu klonen und unter neuem Namen hochzufahren. Damit könnte man beispielsweise Änderungen testen oder z.B. Analyse tools für unstrukturierte Daten, ohne Einfluss auf den produktiven File Server, gegen den Klon laufen lassen.

Clone_AFS_FS

AFS2.2 Update: Es ist ebenso möglich direkt via Prism die File Server Administratoren zu definieren, welche über vollen Zugriff verfügen sollen, bzw. Backup-Accounts, welche beispielsweise nur lesen können sollen.

AFS-Add-Admins2

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

Tipp: DFS-N Unterstützung – AFS Shares können in vorhandene DFS Namespaces integriert werden, sodass existierende mappings, scripts, etc. nicht zwangsweise auf einen neuen Pfad geändert werden müssen. Wie exemplarisch in den folgenden Screenshots zu erkennen, wird der vorhandene Namespace „\ntnx.test\Existing_Namespace\home“ auf „\fs-mgmt\home“ weitergeleitet.

AFS-DFS-N-1

AFS-DFS-N-2

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

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.

AFS 2.1 Update: Ein weiteres Werkzeug zur Verwaltung der Shares und der dazugehörigen Berichtigung zur Verfügung ist ein Microsoft Management Console (MMC) Snap-In für AFS. Dieses erlaubt beispielsweise die Share, bzw. die „Top Level Directories“ (TLD) umzubenennen, sowie deren Berechtigungen rekursiv zu editieren, sodass diese an die entsprechenden Unterorder vererbt werden.

AFS-MMC-1

AFS-MMC-2

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

AFS Anti-Virus Integration

Mit AFS 2.2 wurde die Unterstützung für das ICAP – Internet Content Adaptation Protocol – eingeführt. Das heißt, das es nach einem Update auf Version 2.2 möglich ist, Anti-Viren Scans entsprechend effizient zu offloaden. Als erstere Hersteller wurden Kaspersky, McAfee und Symantec validiert. Die Einrichtung ist dabei denkbar einfach, wie der folgende Screenshot aus Prism zeigt. Neben AFS 2.2 wird AOS 5.1.2 und mindestens zwei ICAP Server benötigt.

file-server-configure-icap

Danach folgt der Date Zugriff folgendem Muster:

AFS_ICAP_Overview

  1. Client öffnet Datei
  2. AFS sendet Scan Anfrage zu Anti-Virus Server
  3. Anti-Virus Server senden Scan Ergebnis an AFS
  4. Client kann Datei öffnen

Die folgenden beiden Screenshots zeigen, dass in Quarantäne verschobene file direkt in Prism angezeigt werden und man diese dort auch wieder aus der Quarantäne holen kann.

file-server-av-quarantined-filesfile-server-av-unquarantined-files

Prism gibt außerdem Aufschluss darüber, wieviele Dateien bereits gescannt wurden bzw. noch in der Warteschlange (Queue) für einen Scan stehen und wie lange die Scans dauern (Latenz in Millisekunden) dauern.

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 ganz 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. Jedoch strebt AFS einen Schwenk der Connection innerhalb eines möglichst kurzen Zeitfensters an, sodass der Client kein Connection Error/Timeout erhält.

AFS Upgrade Software