Xtract – VMware Migration auf die Nutanix Art

Mit Nutanix Xtract (https://portal.nutanix.com/#/page/xtract) stellen wir Ihnen ein Tool für die Migration ihrer virtuellen Maschinen von VMware auf AHV vor. In diesem Artikel möchte ich ihnen die Vorteile des Tools aufzeigen.

Xtract wird zunächst als virtuelle Maschine in Ihrer AHV-Umgebung bereitgestellt. Dies kann über ein Imagedeployment oder über die Cli Ihres Clients (OSX, Linux und Windows) erfolgen. Über den Link bekommen sie die benötigten Files und einen User Guide für die Installation.

Unterstütz werden derzeit folgende Hypervisor Versionen:
1

Nach der Installation, kann über die IP-Adresse der Xtract VM das Migrationsdashboard aufgerufen werden. Nach Vergabe des Passworts kann die Konfiguration starten.
2

Nach dem einloggen, müssen als erstes die Quell- und Zielumgebungen hinzugefügt werden.  Die Registrierung von Quellumgebungen erfolgt durch die Eingabe Ihrer vCenter-Instanz und die Angabe des Namens oder der IP-Adresse sowie der entsprechenden Anmeldedaten. Ziel-AHV-Umgebungen werden ebenfalls auf die gleiche Art registriert, indem Xtract entweder direkt auf den AHV-Cluster oder auf eine Prism Central-Instanz registriert wird.

Sobald Ihre Quell- und Zielhosts definiert sind, erstellen sie einen Migrationsplan.

6

Zuerst wählen Sie die Target Plattform und den StorageContainer aus:
7

Im Anschluss werden die zu migrierenden virtuellen Maschinen selektiert:
8

Falls zusätzliche Tasks für die Migration erforderlich sind,  werden diese aufgezeigt. User-Name und Passwort für die zu migrierenden VM´s und das Zielnetzwerk müssen im Anschluß noch eingetragen und definiert werden.

9

Es wird vor der Migration geprüft, dass die Zielumgebung über genügend Rechen- und Speicherressourcen verfügt. Xtract kann nach migrierbaren und nicht migrierbaren VMs sortieren und liefert eine Zusammenfassung, warum bestimmte VMs nicht migriert werden können, wie z. B. die Notwendigkeit, VMware-Tools oder Mindestwerte für virtuelle Hardwareversionen zu installieren.

Aus Sicht des virtuellen Gastbetriebssystems werden alle von AHV unterstützten Betriebssysteme auch von Xtract for VMs unterstützt.  Eine vollständige Liste der von Xtract unterstützten Betriebssysteme finden sie hier:

  • Windows 2016 Standard, 2016 Datacenter
  • Windows 7, 8, 8.1, 10
  • Windows Server 2008 R2, 2012, 2012 R2, 2016
  • CentOS 6.4, 6.5, 6.6, 6.7, 6.8, 7.0, 7.1, 7.2, 7.3
  • Ubuntu 12.04.5, 14.04.x, 16.04.x, 16.10, Server, Desktop (32-bit and 64-bit)
  • FreeBSD 9.3, 10.0, 10.1,10.2, 10.3, 11.0
  • SUSE Linux Enterprise Server 11 SP3 / SP4
  • SUSE Linux Enterprise Server 12 Oracle Linux 6.x, 7.x
  • RHEL 6.4, 6.5, 6.6, 6.7, 6.8, 7.0, 7.1, 7.2, 7.3
  • Data-Only Support
  • Windows 32-bit Operating Systems
  • Windows with UAC enabled
  • RHEL 4.0, 5.x
  • CentOS Linux 4.0, 5.x
  • Ubuntu 12.x or lower
  • VMs using UEFI-VMs requiring PCI or IDE bus

oder in unserem Support Portal.

Bevor die Migration startet, wird alles noch mal in der Zusammenfassung angezeigt. Die Migrationspläne können natürlich gespeichert und später gestartet werden. Zusätzlich kann ein Migrationszeitplan definiert werden, so dass das Seeding der Daten innerhalb eines vorgegebenen Zeitfensters automatisch gestartet werden kann.
10

Xtract verwendet die VMware vStorage API for Data Protection (VADP) für die Verwaltung des Replikationsprozesses, so dass keine Agenten innerhalb der virtuellen Maschinen oder ESXi-Hosts installiert werden müssen. Optional können Sie Xtract auch die Berechtigung geben, AHV-kompatible Gerätetreiber in der virtuellen Maschine zu installieren und Netzwerkeinstellungen zu erfassen, damit sie in die Zielumgebung übertragen werden können. Anmeldedaten der ausgewählten virtuellen Maschinen können für alle VMs oder individuell nach Bedarf festgelegt werden. Netzwerk-Mappings werden auch spezifiziert, um den Quell- und Zielnetzwerken für die VMs zu entsprechen.

11

Sobald die oben genannten Optionen eingestellt sind, kann die Migration beginnen. Wie bereits erwähnt wird VADP verwendet, um die Migration der Daten an den AHV-Cluster durchzuführen. Dazu werden ESXi-basierte Snapshots für jede VM erstellt und anschließend die virtuellen Laufwerke in den angegebenen AHV-Container repliziert. Laufende Migrationen können jederzeit angehalten oder abgebrochen werden. Die vmdk-Dateien für die zu migrierenden VM´s werden in einem temporären Ordner gespeichert und mithilfe von APIs zur Änderungsblockverfolgung (CBT) und weiteren Snapshot-Operationen inkrementell auf dem neuesten Stand gehalten.

Wenn die Migration beendet ist, schaltet Xtract die Quell VM´s aus und trennt die virtuellen Netzwerkkarten. Inkrementelle Daten werden dann auf den AHV-Cluster synchronisiert. Sobald alle Daten repliziert sind, werden die vmdk-Dateien mit dem AHV-Bildservice in das native RAW-Format konvertiert, das von AHV verwendet wird. Die Konvertierung ist extrem schnell, wenn Sie von einer vmdk-Datei auf RAW umstellen, da die Plattenformate dieselben sind. Xtract liefert auch eine geschätzte Cutover-Zeit, so dass jedes Wartungsfenster ermittelt werden kann. Virtuellen Maschinen innerhalb eines Plans können gemeinsam oder einzeln auf die Target Plattform übergeben werden.

12

Um die Migration abzuschließen, werden VM´s eingeschaltet und alle temporären vmdk-Dateien und konvertierten Images innerhalb des Imageservices entfernt. Die Quell VM´s bleiben bestehen, allerdings ausgeschaltet und ihren Netzwerken getrennt, falls sie aus irgendeinem Grund nochmals benötigt werden. Jede migrierte VM enthält eine Bemerkung im Textfeld, die angibt, wann die VM migriert wurde, wo sie migriert wurde und welche Version von Xtract verwendet wurde.

Die migrierten VM´s können nun verwaltet werden, und Xtract bietet Links, mit denen Sie Ihre Betriebssysteme und Anwendungen auf ihre Einsatzbereitschaft überprüfen können.  Xtract behält die Übersicht über die migrierten VMs und welche noch verschoben werden müssen. Wenn Sie also zusätzliche Migrationspläne erstellen, ist es einfach zu wissen, was noch zu tun ist.

Acropolis Block Services (ABS)

In diesem Artikel geht es um Acropolis Block Services (ABS) und wie damit der Storage der Nutanix Plattform an externe Verbraucher via iSCSI präsentiert werden kann.

Use Cases gibt es dabei einige, denkt man zum Beispiel daran, dass es noch immer Workloads gibt vor deren Virtualisierung man z.B. auf Grund von Herausforderungen bei der Lizensierung zurückschreckt. Also was tun, wenn man zwar den Großteil seiner Workloads virtualisiert und auf eine neue Hyper-Converged Plattform migriert, jedoch besagte Workloads noch mit einem performanten, hochverfügbaren Storage versorgen muss?

Genau hierfür wurde ABS entwickelt und ist dabei denkbar einfach zu verwenden. Für die Verwendung von ABS muss als erstes die so genannte External Data Services IP (DSIP) für das Nutanix Cluster konfiguriert sein.

ABS DSIP

 

Die DSIP dient den Clients als Zugriffspunkt und wird später im iSCSI Initiator des Clients entsprechend konfiguriert.

Im zweiten Schritt, muss eine Volume Group angelegt werden.

Eine Volume Group ist lediglich ein logisches Konstrukt, zur Verwaltung des Storage und der dazugehörigen Zugriffssteuerung. Eine VG vereint so die eigentlichen vDisks (Anzahl & Größe), die dem Client präsentiert werden, als auch die entsprechenden Sicherheitseinstellungen wie IP/IQN Whitelist und CHAP Authentifizierung.

ABS Add VG3

Jede vDisk, die innerhalb der Volume Group konfiguriert wird, taucht am Client später als unabhängig Disk auf. Sprich benötigt der Client z.B. 3 verschiedene Platten, für TempDB, Logs und Datenbank, so muss der VG entsprechend drei vDisks in der gewünschten Größe konfiguriert werden.

ABS Add VG3 Add Disk

ABS Add VG3 Add Disk2

Anschließend noch den Haken für „External Access“ setzen und die entsprechenden Initiatoren via „Add New Client“ der Whitelist hinzufügen. Optional kann hier die Client CHAP Authentifizierung aktiviert werden. So ließe sich letzten Endes Client als auch Server via Mutual CHAP authentifizieren.

ABS Add VG3 Add iSCSI Client

Den Punkt „Attach to a VM“ überspringen wir, da dieser im Falle des AHV Hypervisors dazu dient, eine vDisk direkt an VMs zu mappen und nicht via iSCSI zu präsentieren.

Zuletzt ließe sich optional noch der Flash Mode aktivieren, dieser verhindert, dass Daten einer vDisk in einem hybriden System auf HDD ausgelagert werden, pinnt also die vDisks in den schnellen Flash Tier.

Damit ist die Konfiguration seitens Nutanix bereits abgeschlossen und der ist Storage bereit entsprechend konsumiert zu werden.

Die erste Besonderheit an ABS ist, dass auf Seiten des Clients nur die DSIP angegeben werden muss und keine MPIO Software installiert werden und keine Pfadoptimierung bzw. Konfiguration erfolgen muss. Der iSCSI Initiator frägt über die DSIP die Ressourcen an und wird dann via iSCSI Re-Direction an die eigentlichen CVMs, welche die vDisks hosten, weitergeleitet. Die DSIP ist entsprechend hochverfügbar und kann im Fehlerfall von jeder FSVMs übernommen werden.

ABS iSCSI Init 1

ABS iSCSI Init 2

ABS iSCSI Init 3

ABS DiskMgr

Das führt direkt zur nächsten Besonderheit, den Scale-Out Fähigkeiten. Der Client kann eine dedizierte iSCSI Session zu jeder einzelnen vDisk innerhalb einer Volume Group aufbauen, die potentiell alle auf verschiedenen CVMs gehostet sein können. So kann im Falle eines 10 Node Nutanix Clusters, eine VG mit 10 vDisk, die entstehende Last über 10 physischen Nodes und deren Ressourcen verteilt werden.

Sofern ABS unter Nutanix AHV als Hypervisor eingesetzt werden, so greift auch hier das Acropolis Dynamic Scheduler (ADS) Feature und hilft dabei Hot Spots zu vermeiden. Das beutetet, die Plattform erkennt überlastete CVMs und kann als Gegenmaßnahme die durch ABS präsentierten vDisks zwischen den CVMs neu verteilen, um den Hotspot zu eliminieren.

ABS Überblick

Im Fehlerfall eines Hosts oder einer CVM, werden die dort gehosteten vDisks von einer anderen CVM übernommen und der Client versucht sich erneut über die DSIP einzuloggen und wird dann einfach über die iSCSI Re-Rirection Funktionalität an die neue(n) CVM(s) weitergeleitet.

ABS Failover

Hier ein Beispiel Video des Kollegen Albert Chen

Nutanix Shadow Clones

Shadow Clones kommen vor allem in VDI-Umgebungen mit Linked Clones zum Einsatz. Sowohl Citrix XenDesktop mit MCS als auch VMware Horizon View arbeiten hier mit einem Master-Image, auf welchem alle Linked Clones basieren bzw. darauf verweisen. Das spart enorm viel Speicherplatz, da das Golden Image nur einmal gespeichert werden muss und alle damit verknüpften VMs lesend auf dieses Image zugreifen. Die vermeintlichen Nachteile von Linked Clones sind, der erhöhte I/O-Bedarf auf dem Storage und ein erhöhter Netzwerkverkehr. Das können in einer 3-Tier Umgebung eine LUN und ein FibreChannel Netzwerk sein, oder Falle von HCI Umgebungen, ein einzelner Host mit seinen lokalen Festplatten und dem 10G Ethernet. Ohne Shadow Clones würden also alle Linked Clones über das Netzwerk auf die „vDisk“ des Golden Images zugreifen.

shadowclones2Um den daraus resultierenden Hotspot auf den physischen Festplatten zu vermeiden und Netzwerkverkehr zu reduzieren, überwacht die Distributed Storage Fabric (DSF) den Zugriff auf alle vDisks. Entdeckt sie dabei eine vDisk, welche zum einen Zugriffe von mindestens zwei remote CVMs und der lokalen CVM aufweist und zum anderen ausschließlich Read Requests bedient, so wird diese als immutable (read-only – unveränderbar) markiert. Von nun an wird diese vDisk auf den allen Hosts zwischengespeichert, welche Daten von dieser vDisk anfragen. Damit können die CVMs im Cluster nun Leseanfragen von Linked Clones sofort lokal bedienen. Somit wird quasi die Data Locality automatisch sichergestellt und die VMs profitieren so von einer extrem niedrigen I/O-Latenz.

shadowclones1-page-1Ein manuelles Kopieren des Golden Images auf alle Hosts im Cluster entfällt dadurch. Um das Netzwerk zu schonen, passiert dies auch nicht pro-aktiv, sondern erst wenn ein Block erstmalig angefragt wird. Nimmt man Änderungen am Golden Image vor, z.B durch das Einspielen von Windows Updates, werden die Shadow Clones verworfen und der Prozeß neu gestartet.

Wie konfiguriert man Shadow Clones? Gar nicht! Shadow Clones sind automatisch aktiv. Das Ein- und Ausschalten erfolgt über die nCLI:
ncli cluster edit-params enable-shadow-clones=<true/false>

Zu Shadow Clones gibt es auch ein Video im nu.school-Kanal von Nutanix auf YouTube:

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