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.

Nutanix Self Service Portal (SSP)

In diesem Artikel soll es um eine Lösung gehen, wie IT-Abteilungen die Kollegen der internen Fachabteilungen bequem mit einem Self-Service Portal in die Lage versetzen, Ressourcen selbständig zu provisionieren und zu verwalten. Damit soll dazu beigetragen werden, dass sich wiederholende Aufgaben, wie das provisionieren und installieren von VMs oder speziellen Applikationen, automatisiert oder an die Fachabteilungen ausgelagert werden kann. So werden Ressourcen frei, mit denen die IT-Abteilung weiter an innovativen Lösungen für das Business arbeiten kann.

Aus Nutanix Sicht betrachtet, soll die Inbetriebnahme eines solchen Self-Service nicht in einem Kraftakt ausarten, sondern möglichst einfach von statten gehen. Der Gedankengang der bei der Entwicklung daraus entstanden ist letztlich das integrierte Self-Service Portal (SSP) als neuer, integraler Bestandteil der Nutanix Enterprise Cloud Plattform.

Die Inbetriebnahme ist Denkbar einfach, dazu einem dem Self Service Menüpunkt im Prism Hauptmenü folgen.

SSP-Enable-Menu

Eine weitere Besonderheit ist die hohe Verfügbarkeit. Wie Prism selbst, wird das SSP verteilt über alle CVMs eines Clusters bereitgestellt und ist demnach entweder über die „Cluster Virtual IP Address“ (CVIP) oder über die IPs der einzelnen CVM erreichbar. Am einfachsten ist aber der Zugriff über die CVIP, via https://<CVIP&gt;:9440/ssp – so ermöglicht man den Benutzern den einfachsten Zugang. Diese IP ist eine „floating IP“ und kann z.B. bei rollierenden AOS Upgrades, von CVM zu CVM wandern und bietet so eine sehr hohe Verfügbarkeit.

Bei der ersten Inbetriebnahme muss lediglich die Active Directory Anbindung eingerichtet werden und entsprechend Benutzer/Gruppen als SSP Administratoren hinterlegt werden.

SSP-Connect-AD-1

SSP-Connect-AD-2

Das war es auch schon, jetzt kann es bereits losgehen. Aus IT-Sicht müssen noch ein paar wenige Grundlegende Einstellungen getroffen werden.

SSP-Admin-Overview

Das SSP beschränkt sich nicht alleine auf das Deployment von virtuellen Maschinen (VMs) sondern ermöglicht es auch, Docker Container zu provisionieren. Den Teil der Docker Container habe ich bereits in einem extra Artikel erklärt.

 

Berechtigungen

Neben einigen vordefinierten Rollen, gibt es die Möglichkeit auch eigene Rollen mit entsprechenden Berechtigungen zu definieren.

SSP-Default-Roles

So kann z.B. auch kontrolliert werden, dass in einem Projekt keine neuen Ressourcen provisioniert werden dürfen und man so Benutzern aber trotzdem einfach Konsolenzugriff auf die eigenen VMs ermöglicht.

SSP-Add-Roles

 

Projekte

Danach kann man Bereits ein Projekt anlegen. Ein Projekt ist quasi die kleinste organisatorische Einheit, welcher Benutzer mit entsprechenden Berechtigungen und Quotas zugewiesen werden können. So kann ein Projekt tatsächlich ein Projekt oder aber auch z.B. eine Abteilung repräsentieren.

SSP-Add-Project

Neben einem Namen für das Projekt, können jetzt die gewünschten AD Benutzer oder Gruppen hinzugefügt werden und mit dem gewünschten Rollen verknüpft werden. Zusätzlich können die Netzwerke (VLANs) ausgewählt werden, in denen die Benutzer VMs deployen dürfen. Zum Abschluss besteht optional die Möglichkeit dem Projekt eine Quota zuzuweisen, um die zur Verfügung stehenden Ressourcen einzuschränken.

 

Catalog / Templates

Jetzt fehlt nur noch ein Katalog bzw. Templates, aus denen Benutzer auswählen können. SSP Administratoren können einfach vorhandene VMs in den „Catalog“ aufnehmen, sodass diese für diese als Quelle für die Provisionierung zur Verfügung stehen. Im Hintergrund wird ein Snapshot der VM erstellt, sodass dieser als persistente Quelle dienen kann.

SSP-Add-Image-to-CatalogSSP-Add-VM-to-Catalog-2SSP-Catalog-Items

Zusätzlich greift das SSP auch auf den Nutanix „Image Service“ zu, welcher ISOs oder fertige Disk Images bereithält. Diese können ebenfalls dem Catalog, der übrigens allen SSP Benutzern zur Verfügung steht, hinzugefügt werden.

Auch können vorhandene VMs den Besitzer wechseln. Sodass diese entsprechend bei den Benutzer im Portal auftauchen.

SSP-Manage-Ownership1SSP-Manage-Ownership2

Loggt sich jetzt ein Benutzer ein, so werden diesem nur die Ressourcen aus den zugewiesenen Projekten gezeigt. In diesem Beispiel, wurden noch keine VMs innerhalb des Projekts erstellt. Über den Button Create VM, lässt sich dies jedoch schnell ändern.

SSP-User-No-VMsSSP-Deploy-VM-1SSP-Deploy-VM-2SSP-Deploy-VM-3

Die folgenden Screenshots zeigen, dass Benutzer selbst ihre VMs neu starten, löschen oder auch einfach die VM Konsole starten können.

SSP-User-Overview-1SSP-User-Console

Derzeit ist die Nutzung des SSP auf ein Nutanix AHV Cluster beschränkt und es besteht noch keine Möglichkeit Cloudinit oder Sysprep während des Deployments zu verwenden, jedoch kann man hier gespannt sein, wie sich im Laufe des Jahres das SSP noch weiterentwickelt. Die entsprechenden Neuerungen werden natürlich auch hier wieder im Detail erklärt vorgestellt.

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