Die Evolution des nativ integrierten Nutanix Self-Service Portal (SSP), was hat sich getan und welche neuen Möglichkeiten bieten sich mit AOS 5.5?

Mit AOS 5.5 respektive dem dazugehörigen neuen Prism Central (PC) 5.5 Release hat sich ein Punkt maßgeblich verändert. Denn bisher war das SSP fester Bestandteil der Nutanix Controller Virtual Maschine (CVM) und somit limitiert auf ein einzelnes Nutanix Cluster. Mit dem neuen Release zieht das SSP um, nämlich aus der CVM, in Prism Central. Ein elementar wichtiger Schritt, um das Thema Self-Service in der privaten Cloud weiter zu optimieren.

Für die Leser, die Prism Central noch nicht kennen, PC ist eine zentrale Instanz, welche es erlaubt, mehrere Nutanix Cluster zentral zu verwalten. Egal ob mehrere lokale Cluster innerhalb eines Rechenzentrums (RZ) oder in verteilten Umgebungen, wie im Falle von Außenstellen.

Aber was macht diesen Umzug jetzt besonders? Die Tatsache, dass jetzt alleine durch das einfache Deployment von Prism Central, oder eines Upgrades des vorhanden PC, ein zentrales Self-Service Portal zur Verfügung gestellt werden kann, welches erlaubt Workloads Cluster übergreifend, bzw. in verschiedenen Nutanix Clustern auszurollen.

Das Look and Feel des bisherigen SSP wird größtenteils beibehalten und an einigen Stellen um neue Funktionen erweitert. Auch integriert sich in Prism Central in bereits bekannte Strukturen der „Explore“ Ansicht, dazu aber gleich mehr.

Migration des SSP

Führt man ein One-Click Upgrade des Nutanix Clusters auf AOS 5.5 durch, so erhält man direkt den ersten Hinweis darauf, dass das SSP umzieht. Wie der Hinweis ebenfalls nahelegt, bitte zuerst Prism Central auf 5.5. aktualisieren.

Loggt man sich anschließend in Prism Central ein und hat dieses vorher erfolgreich auf 5.5 aktualisiert, erhält man auch hier einen nicht zu übersehenden Hinweis, dass das SSP noch migriert werden muss.

Dazu sind nur zwei Schritt notwendig. Wobei jedes SSP einzeln zu migrieren ist, sprich betreibt man bereits mehrere Cluster mit aktiviertem SSP, so muss folgendes entsprechend mehrfach durchgeführt werden.

Das war die Migration, damit wurden alle bestehenden Rollen, Projekte, etc. in das neue SSP in Prism Central übertragen.

Danach oder sofern bisher kein SSP genutzt, kann wie folgt das SSP als auch CALM (Apps) aktiviert werden.

Schritt 1: Die AD Anbindung.

Schritt 2: Definition der SSP Administratoren (AD User oder Gruppen) und einem Default Cluster.

Schritt 3: CALM/Apps aktivieren, auf welches über das SSP zugegriffen wird. Mehr Details zu CALM folgenden in einem eigenen Artikel.

Jetzt ist das SSP startklar. Wie bereits erwähnt, integrieren sich die SSP Komponenten nahtlos in die neu strukturierte „Explore“ Ansicht in Prism Central. Wobei zu erwähnen ist, dass es sich bei der folgenden Ansicht um die administrative Ansicht handelt, daher werden hier noch deutlich mehr Menüpunkte angezeigt, welches dem User später verborgen bleiben.

Rollenbasierter Zugriff (RBAC)

Prism Central erhält mit diesem Update ein neues Rechtekonzept, welches einen rollenbasierten Zugriff auf das SSP & CALM erlaubt. Sprich es kann ein Active-Directory oder ein Open LDAP Verzeichnis angebunden werden und dann innerhalb von Projekten, den Benutzern entsprechende Berechtigungen über Rollen zugewiesen werden. Somit kann z.B. eine AD-Gruppe mit der vordefinierten Rolle „Consumer“ und andere Benutzer wiederum, mit einer selbst definierten Rolle unterschiedlich innerhalb des Projekts berechtigt werden.

Eine zusätzliche Option wurde eingeführt um zu kontrollieren, ob ein Benutzer innerhalb eines Projektes, ebenso Zugriff auf die Workloads anderer Benutzer erhalten soll oder nicht.

Generell wurden die Rollen im Vergleich zur vorherigen Version deutlich ausgeweitet, da natürlich neben dem SSP noch weitere Neuerungen in Prism Central Einzug gehalten haben, wie z.B. Nutanix CALM, deren Nutzung zukünftig über das gleiche Rollen-Konstrukt gesteuert werden kann. CALM ist dabei ein Thema für sich, daher hier für den Moment nur die Übersicht aller Berechtigungen, die einer Rolle zugewiesen werden können. Am Rande sei erwähnt, dass die Berechtigungen für Acropolis Container Services (ACS) 1.0 entfernt wurden, da ACS in seiner bisherigen Form nicht weiter angeboten.

 Cluster Zuweisung

Das SSP erlaubt es jetzt, dass innerhalb des Projekts zugeordnet wird, auf welchem Nutanix Cluster die Workloads ausgerollt werden dürfen. Somit kann man sehr einfach steuern, dass beispielsweise Fachabteilungen an Standort A, nur Workloads auf deren lokalen Cluster A ausrollen/nutzen dürfen und keine Möglichkeit haben, sofern nicht bewusst dazu berechtigt, Workloads auf Cluster B in Standort B zu starten.

 

Im Folgenden noch einmal alle Einstellmöglichkeiten, welche den SSP-Administratoren auf Ebene eines Projekts zur Verfügung stehen. Im Bereich der Netzwerke tauchen dann natürlich nur die Netze auf, die dem ausgewählten Nutanix Cluster bekannt sind. Im Bereich der Quotas gab es keine Änderungen.

Use Cases gibt es dabei zuhauf, beispielsweise ist man so in der Lage, Benutzern in Außenstellen Konsolen-Zugriff auf deren eigene VMs zu geben. Oder aber, dass entsprechende Fachabteilungen sich Workloads, gleich ob produktiv oder zu Testzwecken, auf den dafür vorgesehenen Nutanix Clustern ausrollen können. Alle haben dabei eins gemeinsam, die IT-Abteilung zu entlasten und gleichzeitig den Benutzern mehr Kontrolle und ein „Cloud Like“ User Experience zu ermöglichen. Warum also in die Public Cloud gehen, wenn es jetzt im eigenen RZ genauso einfach geht?

 

Images & Guest Customization – Anpassung der Gastbetriebssysteme

Ein weiteres Detail ist, dass es ebenso möglich ist, wenn man als Benutzer neue VMs ausrollen möchte, einfach eine entsprechende „Guest Customization“ durchzuführen. Sprich das beispielsweise der Hostname auf den VM Namen angepasst wird, oder das ein entsprechendes admin/root Passwort gesetzt wird, um ein paar gängige Beispiele zu nennen. Die SSP-Administratoren können dabei für jedes Template einige Vorgaben machen, was ein Benutzer während des Deployments angeben muss bzw. darf, um die Angaben möglichst zu reduzieren. Fügt ein Administrator eine vorhandene VM in den „Catalog“ hinzu, können entsprechende Anpassungen vorgenommen werden. Alternativ können aus cloud-init bzw. sysprep Skripte angeben werden.

Der Name ist der Name unter dem das Template später im Catalog zu finden ist und diesem werden entsprechend die getroffenen Einstellung mitgegeben.

In diesem Fall würde diese VM bzw. das „Catalog“ Objekt, also die Quell-VM aus der neue VMs erzeugt werden können, nur in dem Cluster zur Verfügung gestellt, in dem die Quell-VM existiert.

Möchte man eine VM global über Cluster Grenzen hinweg anbieten, so kann man daraus ein Image generieren und in den neuen Image Service importieren. In den Versionen < 5.5, war dieser Dienst ebenfalls lokal und an einen Nutanix Cluster gebunden. Mit AOS bzw. PC 5.5 können die Images jetzt zentral gepflegt werden.

Leider gibt es hierfür noch keine One-Click Prozess, der aus einer VM ein Image im zentralen Image Service erzeugt. Hierzu muss man noch auf die CLI zurückgreifen.

Auf einer CVM, auf der die Quell VM läuft per SSH einloggen und den Pfad zur vDisk heraussuchen:

vm.get TESTVM include_vmdisk_paths=1

Anschließend in Prism Central per SSH einloggen und den Pfad in folgendem Befehl verwenden. Die unten angegebene IP ist eine CVM IP Adresse um auf den Storage container zuzugreifen:

image.create name=Win2016 image_type=DISK_IMAGE source_uri=nfs://172.23.2.16/VMs/.acropolis/vmdisk/c85d183c-1756-4069-90dd-d80ac188e07c

Ist die gewünschte Datei im Image Service, so kann dieses den Usern über den Catalog zur Verfügung gestellt werden.

 

Frontend – Benutzer Ansicht

Loggt sich jetzt ein Benutzer ein sieht er erst einmal folgendes, wobei die Ansicht variieren kann, je nachdem welche Rolle dem Benutzer zugeordnet wurde.

Über „Create VM“ kann der Benutzer einfach neue VMs ausrollen. Im Folgenden wird genau dieser Prozess dargestellt.

Dann kann er entweder aus den VM Templates oder Disk Images wählen. Bei den VM Templates wird nicht nur eine vorinstallierte vDisk als Grundlage hergenommen, sondern eben auch die gesamte virtuelle Hardware Konfiguration. Während es bei den Disk Images, wie der Name schon andeutet, nur um eine vDisk handelt, auf der das Betriebssystem bereits installiert ist. Oder alternativ um ein ISO, sodass User selbstständig eine Installation durchführen könnten.

Abschließend können gewünschte oder benötigte Anpassungen vorgenommen werden, bevor die VM abschließend ausgerollt wird. Beispielsweise kann das Projekt und somit auch das Zielcluster ausgewählt werden oder auch das Zielnetzwerk, sofern im Projekt mehrere zur Auswahl hinterlegt wurden.

Ist die VM ausgerollt, so kann der Benutzer jetzt alle Aktionen mit der VM durchführen, die seiner zugeordneten Rolle entsprechen, wie beispielsweise die VM Konsole öffnen.

So viel zu den Basisfunktion des neuen Self-Service Portals, wobei es sich hier nur um einen Baustein der Enterprise Cloud handelt. Ein weiterer essentieller Baustein ist die CALM Komponente, welche im nächsten Artikel genauer erläutert wird. Aber hier schon mal ein kleiner Vorgeschmack.