Patrick


Nutanix Calm – Life Cycle Management

Bevor ich jetzt mit der Blog-Serie zum Thema Nutanix Calm fortfahre und in die Details zu Calm selbst einsteige, möchte ich zunächst noch das Thema Komplexität von Upgrades bzw. Life Cycle Management kurz beleuchten. Also was es bedeutet, die Automatisierungs-Infrastruktur auf dem neusten Stand zu halten, was typischerweise mit seitenlangen Upgrade Guides und damit auch sehr oft einem hohen Zeitbedarf und personellen Aufwand einhergeht.

Im Folgenden zeige ich, wie einfach man nicht nur Prism Central (PC), sondern auch Calm selbst aktualisieren kann. Bisher ging ein Upgrade von Calm immer mit dem gleichzeitigen Upgrade von Prism Central einher. Hatte man zum Beispiel PC auf 5.9.0 aktualisiert, so erhielt man automatisch die neuste Version 2.3.0 von Calm. Um zukünftig Calm auch unabhängig von PC aktualisieren und damit einen unabhängigen Release Cycle pflegen zu können, wird Calm zukünftig über den ebenfalls in PC integrierten „Life Cycle Manager“ (LCM), unabhängig von PC aktualisiert.

Also zunächst mache ich ein gewöhnliches 1-Click Upgrade von Prism Central 5.9.0 auf 5.9.1. Dies funktioniert wie gewohnt über die „Upgrade Prism Central“ Funktion. Die dafür benötigte Software wird einfach „over the air“ heruntergeladen und im nächsten Schritt starte ich das „rolling Upgrade“, welches die neuste Version auf allen Prism Central Knoten ausrollt. Denn in meiner Umgebung läuft Prism Central bereits als „Scale-out Cluster“, besteht also aus mehreren VMs. Das aber nur am Rande.

Nach erfolgreichem Upgrade wechsele ich in den LCM und starte ein sogenannten „Inventory“ Prozess, welcher die installierten Softwarekomponenten mit den verfügbaren Upgrades abgleicht. Dabei aktualisiert sich der LCM selbst von Version 2.0 auf 2.1. Sehr praktisch, oder?

Nach erfolgreichem Inventory und der Aktualisierung auf LCM 2.1, erscheinen dann auch schon die verfügbaren Software Upgrades zur Auswahl.

Über „Edit“ gelange ich zu den Details, welche zeigen, dass für Calm und Epsilon (gehören technisch betrachtet zusammen) ein Upgrade verfügbar ist.

Anschließend speichere ich die Auswahl und starte das Upgrade.

Ein paar Minuten und ein Kaffee später, ist Calm und Epsilon auf dem neusten Stand und ich kann mir die neuen Features ansehen. Dazu aber in einem eigenen Blog mehr dazu.

 

So viel für den Moment zum Thema Life Cycle Management und wie einfach Prism Central, respektive Calm, auf dem neusten Stand gehalten werden können. Ich glaube der dargestellte Prozess und die Bilder sprechen dabei für sich. Ein Jeder kann jetzt seine persönlichen Erfahrungen mit komplexen Upgrades, mit dem vergleichen, was Nutanix im täglichen Betrieb an Erleichterungen ermöglicht. Persönlich, nicht viel Aufwändet als ein Upgrade meines Smartphones.


Nutanix Calm – Multi-Cloud & Applikations-Automatisierung

In einem Unternehmen hat ein Jeder eine Aufgabe zu erledigen, für die er auch persönlich verantwortlich ist und an der auch oft der Erfolg gemessen wird. Und was kann hier frustrierender sein, als auf andere zu warten, um besagte Aufgabe zu erledigen? Unter Umständen Stunden, Tage, oder gar Wochen?

Das ist durchaus oft der Fall, wenn es um die Bereitstellung von IT-Ressourcen, wie beispielsweise Applikationen oder einfach nur virtuelle Maschinen geht. Oft müssen mühsam Tickets von Hand bearbeitet werden, was als Konsequenz auf beiden Seiten Frust hervorrufen kann. Vor allem in Zeiten in denen beispielsweise Entwickler in nur wenigen Tagen ein neues Feature entwickeln wollen und danach die Infrastruktur, welche dazu genutzt wurde, wieder eingerissen werden soll, ist es fatal, wenn die Bereitstellungsdauer länger als die Nutzungsdauer ist. Und so ist es wenig verwunderlich, wenn die „Schatten IT“ kontinuierlich überhandnimmt und die benötigten Ressourcen, z.B. in der Public Cloud abgerufen werden. Ich möchte damit nicht sagen, dass es nicht viele gute Use Cases für die Pulic Cloud gibt und diese verteufeln, sondern eher, dass diese dann bewusst genutzt werden sollte, mit entsprechender Kostenkontrolle & einem ausgeprägtem Sicherheitsbewusstsein.

Aber warum scheitern scheinbar so viele Unternehmen dabei, mit der Public Cloud in Sachen Self-Service und Automatisierung Schritt zu halten?

Was meine persönliche Erfahrung betrifft, so ist einer der wohl größten Faktoren, die Komplexität die mit der  Automatisierung selbst einhergeht, diese ans Laufen zu bekommen und im weiteren Verlauf auch entsprechend einfach betreiben zu können. Sprich, viel Zeit und Energie geht bereits verloren, die dafür notwenige Infrastruktur zu schaffen.

Und genau hier setzt Nutanix mit mehreren Komponenten an. Hyper-Converged Infrastructure (HCI) ist dabei nur der grundlegende IaaS „Building Block“, welcher die zugrundeliegende Infrastruktur vereinfacht und somit viele Stellschrauben und Reibungsfläche zwischen IT-Silos beseitigt. Doch um Ressourcen in Minuten bereitstellen zu können, bedarf es weit mehr. Ein Portal für den Self-Service Portal (SSP), Rollenbasierter Zugriff, uvm. Und genau hier kommt Nutanix Calm ins Spiel.

Nutanix Calm ist die integrierte Applikations-Automatisierung, welche es erlaubt, ganze Applikationen, oder auch einfache VMs, den Anwendern im Self-Service-Verfahren bereitzustellen. Ganz gleich ob lokal on-premises im eigenen Rechenzentrum, oder in der Public Cloud, bei den gängigen Providern wie AWS, GCP und Azure. Was auch zeigt, dass es hier nicht um einen Kampf lokal vs. Cloud geht, sondern darum eine Plattform für alle Clouds zu schaffen um die Workloads in die beste dafür geeignete Cloud zu provisionieren.

Nun stellt sich zunächst die Frage, wieviel Aufwand denn wieder dahinterstecken mag, diese Lösung bereitzustellen. Und die Antwort auf diese Frage zeigt deutlich, wie sich Nutanix von bisherigen Lösungen unterschiedet. Nutanix Calm „lebt“ in Prism Central und ist dort nativ integriert. Sprich rollt man Prism Central aus, was bei Nutanix Kunden typischerweise immer der Fall ist, da damit auch erweitere Funktionen für die zentrale Infrastrukturverwaltung einhergehen, z.B. um mehrere verteilte Nutanix Cluster zu veralten, ist Calm nur einen Klick entfernt, ganz nach der Nutanix “1-Click” Philosophie. Wichtig ist auch an dieser stelle zu erwähnen, dass Calm damit auch in den 1-Click Upgrades von Prism Central integriert ist und damit bequem auf dem neusten Stand gehalten werden kann.

 

Danach ist Calm einsatzbereit. Es bedarf also nicht wochenlanger Vorarbeit und Experten, nur um die Automatisierungs-Lösung zu implementieren. Jetzt kann zum Beispiel damit begonnen werden, Projekte anzulegen, in denen (AD/LDAP) Benutzer und deren Rollen innerhalb eines Projekts definiert werden. Die IT kann entscheiden, ob Sie die vordefinierten Applikationen (Blueprints) über den so genannten Marketplace Manager freigeben und somit im Marketplace veröffentlichen will, oder ob sie doch lieber eigene Applikationen definiert und veröffentlicht. Ganz gleich, der Marketplace dient als zentrale Anlaufstelle für den Self-Service der Benutzer, um von dort Applikationen selbstständig zu provisionieren.

Auch besteht die Möglichkeit, ganz einfach, mehrere Clouds anzubinden, die dann als Zielplattform für die Provisionierung genutzt werden können. So entsteht eine Control Plane, wo in Zeiten von „Multi-Cloud“ eine einfache zentrale Verwaltung möglich wird. Egal ob Nutanix AHV als Hypervisor, eine bestehende VMware vSphere Umgebung, oder auch wie angesprochen, die gängigen Cloud Provider. Hier wird alles unter einem Dach vereint.

In weiteren Blog Posts werde ich in die Einzelheiten einsteigen und alles Komponenten genauer erklären. Zum Abschluss hier noch ein kurzer Rundgang durch die einzelnen Teile von Calm.


[DE] Nutanix Cluster Erweiterung (Scale-Out)

Hinweis: Cross-Post von invisible-it.de

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:

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

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


[DE] Das Nutanix Cluster – Die Grundlagen

Hinweis: Cross-Post von invisible-it.de

Im folgenden Post möchte ich den Grundstein für viele der noch folgenden Themen legen, die wir hier in Zukunft noch behandeln werden und darum möchte ich erklären, wie ein Nutanix Cluster grundsätzlich aufgebaut ist.

Beginnen wir mit der kleinsten Einheit, mit einem so genannten Node. Dieser entspricht einem einzelnen x86 Server, auf dem direkt der Hypervisor installiert ist und entsprechend auch VMs betrieben werden können.

ntnx_wb_1x1_0

Ein Nutanix Cluster besteht jedoch immer aus mindestens drei Nodes.

ntnx_wb_1x1_1

Der wohl wichtigste Grund hierfür ist, dass die Nutanix Plattform ein verteiltes System ist. Daher müssen bei vielen Prozessen eine Mehrheit der Nodes gewissen Änderungen zustimmen, was in einem 2 Node Cluster so nicht möglich wäre.

Die Nodes beinhalten neben CPUs und RAM wie man das üblicherweise kennt, auch Storage in Form von SSDs und HDDs (Hybrid) oder ausschließlich SSDs (All Flash).

ntnx_wb_1x1_2

Dies Storage-Ressourcen sind direkt mit einem SAS HBA angebunden und werden 1:1 weitergereicht, sprich nicht in einem RAID konfiguriert.

ntnx_wb_1x1_3

Auf jedem Node läuft eine so genannte Nutanix „Controller Virtual Machine“, kurz CVM, welche besagten SAS HBA direkt via PCIe Pass-Through durchgereicht bekommt. Der Hypervisor selbst, bekommt diese Ressourcen somit nicht direkt zu sehen.

ntnx_wb_1x1_4

Die CVM ist das Herzstück der Nutanix Enterprise Cloud Plattform und betreibt nicht nur den Software Defined Storage Layer, sondern besser ausgedrückt, das Nutanix Datacenter Betriebssystem.

Alle CVMs kommunizieren über  Ethernet (wahlweise 1, 10 oder 40 GbE) miteinander und bilden so gemeinsam einen Storage Pool, auch “Distributed Storage Fabric” genannt.

Grundsätzlich ist jede CVM primär für die Verwaltung der jeweils lokalen Ressourcen verantwortlich. Über das Zusammenspiel aller CVMs in der DSF, ergibt sich so jedoch ein verteilter, leistungsfähiger und hochverfügbarer Storage Pool. Dieser sieht für den Hypervisors, oder andere externe Verbraucher, letzendes Endes aus wie ein herkömmlicher zentraler Storage und bietet zusätzlich Features wie Snapshots, Datenreduzierung, Replizierung, etc.

Der Storage Pool spiegelt 1:1 die aggregierte Kapazität aller physikalischen Ressourcen wieder. Wenn z.B. jeder Node über 14 TB Storage verfügt und wir beim Beispiel von drei Nodes bleiben, werden im ersten Schritt 42 TB im Storage Pool zur Verfügung gestellt.

ntnx_wb_1x1_5

Die eigentliche Storage Provisionierung geschieht über so genannte Storage Container, welche (vergleichbar zu einer LUN) aus dem Storage Pool gebildet werden und dem Hypervisor als Datastore präsentiert werden. Auf dieser Ebene werden wesentliche Einstellungen getroffen, beispielsweise wie viele Kopien für die Fehlertoleranz (RF2/RF3) erstellt werden oder auch ob beispielsweise Technologien zur Datenreduzierung wie Deduplizierung oder Komprimierung aktiviert werden sollen. D.h. erst hier definiert sich die tatsächliche nutzbare Kapazität eines Clusters. So hat z.B. ein Pool aus 42TB Rohkapazität in einer RF2 Konfiguration eine theoretische nutzbare Kapazität von 21TB. Betrachtet man jedoch einen Node als Spare Kapazität (N+1 Prinzip) der jederzeit ausfallen darf, so wäre die nutzbare Kapazität 14TB.

ntnx_wb_1x1_6

Jede CVM kommuniziert nicht nur über TCP/IP mit den benachbarten (Peer) CVMs, sondern auch über einen internen vSwitch, ohne externe Uplinks, direkt mit dem Hypervisor. Über diesen Weg (privates Netzwerk 192.168.5.0) greift der Hypervisor auf die Container und somit auch auf die lokalen Storage Ressourcen der CVM zu. Das Zugriffsprotokoll variiert je nach Hypervisor, im Fall von ESXi ist es NFS, bei Hyper-V entsprechend SMB und bei AHV das iSCSI Protokoll.

Die DSF ist wie gesagt ein verteiltes System, wonach die Daten als auch die Metadaten der VMs über das gesamte Cluster verteilt sind. Ein Blick auf den I/O-Pfad zeigt folgendes:

Die geschriebenen Daten einer VM, fließen über den Datastore direkt in die lokale CVM, welche dann in der Verantwortung ist, die Daten zu verarbeiten. Die geschriebenen Daten werden einmal lokal und dann abhängig vom konfigurierten Replication Factor “RF” (2 oder 3) auf weitere CVMs des Clusters synchron repliziert.

ntnx_wb_1x1_7

Damit erreicht man zwei wichtige Punkte:

  1. Data Locality: Die Primäre Kopie einer VM liegt sozusagen immer lokal in der CVM auf dem Host, auf dem die VM aktiv läuft. Somit können Read I/Os direkt aus den lokalen Storage Ressourcen erfolgen. Dies ermöglicht eine entsprechend hohe Performance und reduziert dabei gleichzeitig den Netzwerk Traffic auf ein Minimum.
  2. Rebuild Zeiten: Die Kopien für die Fehlertoleranz, werden komplett im Cluster verteilt und nicht immer an die gleiche Peer CVM(s) gesendet. Somit ist es möglich, dass ein Rebuild nicht nur von bzw. auf eine CVM stattfindet, sondern die Daten von vielen CVMs und deren lokalen Disks gelesen und auf beliebige CVMs und Disks wiederhergestellt werden können. Somit können Rebuild Zeiten deutlich optimiert werden.

Abschließend möchte ich noch die Frage beantworten, was passiert, wenn eine VM zwischen den Nodes migriert wird oder ein Node ausfällt und eine VM auf einem anderen Node wieder gestartet werden muss?

Grundsätzlich ändert sich aus Sicht der VM nichts. Diese wird, egal durch welches Event, auf einem neuen Node gestartet und greift dort direkt über die lokale CVM auf den Storage Container zu. Verfügt die lokale CVM bereits über einen Teil der VM Daten, so können diese direkt lokal gelesen werden. Wahrscheinlich müssen aber Teile der Daten über das Netzwerk gelesen werden, dies ist jedoch für die VM komplett transparent. Über Zeit kann so die Data Locality der VM wiederhergestellt werden, indem die Daten auf den neuen Node der jetzt die VM hostet, migriert werden. Einzige Voraussetzung, die VM muss die Daten die noch remote liegen auch tatsächlich lesen, sodass diese für eine Migration in Betracht gezogen werden.