So nutzen Sie Pure Cloud Block Store for Azure VMware-VMs

Vorteile durch native Integration

Das Storage-Unternehmen verspricht durch die native Integration in die Azure-Plattform Kosteneinsparungen, unter anderem bei der Nutzung der Azure VMware Services (AVS). So können die Komprimierungs- und Deduplizierungstechnologien von Pure die VMware-Workloads reduzieren. Darüber hinaus lassen sich die Kosten für den Blockspeicher entzerren. Dies ist möglich, da das Storage nun direkt an die virtuellen Maschinen (VMs) angebunden sind und bei Bedarf nur die Speicherkapazität skaliert werden kann. Es müssen nicht wie zuvor zusätzliche Compute-Nodesoder Hosts hinzugefügt werden, was wiederum zu Kosteneinsparungen führt. Zuvor war oft nur der Einsatz von VMware vSAN in der Azure-Cloud möglich, was im Falle einer Skalierung die Kosten nach oben trieb, da sich nicht nur eine Ressource erweitern ließ. Wurde die Speicherkapazität erhöht, erhöhte sich automatisch die Compute-Ressource. Das wiederum führt zu ungenutzten Komponenten, was dann Mehrkosten verursacht.

Anwender können als Speicher zwischen Ultra Disk oder Premium SSD v2 wählen. Nach wie vor ist mit der Lösung eine Datenmigration in die Cloud möglich, allerdings unter flexibleren Umständen, da sich Compute und Storage unabhängig voneinander erweitern lassen. Für die VMs in Azure kann der Administrator die Snapshots-Erstellungs- und Schutzmechanismen von Pure mit dem Namen Safemode nutzen. Diese Snapshots sollen für eine schnellere Wiederherstellung der Datensätze sorgen. Weitere Funktionen für die Data Protection sind Zero-RPO, Near-Zero-RPO, Active DR und Purity CloudSnap.

Um die Ziele einer Wiederherstellung in AVS zu erreichen, stehen Hochverfügbarkeits- und Cloud-Replikationsfunktionen zur Verfügung, mit denen sich auch in diesen Szenarien der Speicher bedarfsgerecht skalieren lässt. Da das Datenmanagement sowohl am eigenen Standort als auch in der Azure-Cloud über eine einheitliche Plattform durchgeführt wird, können Anwender auf zusätzliche Tools verzichten und eine Multi-Cloud-Governance für ihre Daten einrichten.

Genaue Einsparungspotenziale lassen sich über die Kostenkalkulatoren berechnen. Der Pure Cloud Block Store Savings Calculator errechnet Langzeiteinsparungen mit der Block-Store-Lösungen im Vergleich zu Azure Managed Disk, während der TCO-Rechner die Gesamtkosteneinsparungen angibt.

Zu den weiteren Funktionen von Cloud Block Store gehören die Bereitstellung von Datenservices am eigenen Standort und in der Cloud, was Datensilos und hybride Multi-Cloud-Szenarien ermöglichen soll. DevTest in der Cloud bietet Softwareentwicklern die Möglichkeit, eine Testumgebung in der Cloud einzurichten, die Daten mittels asynchroner Replikation in diese Umgebung zu replizieren und zu prüfen. Mit einer DevText Sandbox können während der Tests Snapshots und Klone angefertigt werden, mit denen sich bei Fehlern, Datenbeschädigungen oder Konfigurationsfehlern schnell zu einem früheren Datenstand zurückkehren lässt. Diese Snapshots oder Klone benötigen nur minimalen Cloud-Speicherplatz, was schnellere Entwicklungszyklen zulässt.

Es bestehen verschiedene Bezugswege: Azure-Kunden können bestehende Commits für die Pure-Services nutzen, ein eigenes Pure-Storage-Abo erwerben und wenn Anwender Cloud Block Store über Evergreen buchen, dann müssen sie die Azure-Ressourcen zusätzlich dazu erwerben. Der Anwender bezahlt Pure Storage für die Kapazität von Cloud Block Store (CBS) und Azure rechnet die Ressourcen ab, die von CBS in Anspruch genommen werden, beispielsweise Compute oder Netzwerkverkehr.

Installationsvoraussetzungen und erste Implementierungsschritte

Um Cloud Block Store in Azure bereitzustellen, benötigt der Anwender eine vollumfängliche Lizenz. Diese umfasst verschiedene Komponenten:

Reserve Commit: Eine Lizenz ist in der Regel mit einem reservierten Commit verbunden. Ein reservierter Commit ist eine vereinbarte Kapazität, die für einen bestimmten Zeitraum (in der Regel 1-3 Jahre) genutzt werden soll. Dieser Commit wird üblicherweise in 10 TBs oder mehr gemessen. Der Vorteil dieses Commit ist, dass der Preis pro GBniedriger ist im Vergleich zu einer Installation ohne reservierten Commit. Admins sollten sich auf eine Nutzung festlegen, die genau dem entspricht, benötigt wird.

On-Demand (bedarfsabhängig): Der On-Demand-Teil der Lizenz tritt in Kraft, wenn der reservierte Commit erschöpft ist, der mit dem konfigurierten Lizenzschlüssel verbunden ist. Im Falle einer Lizenz ohne Reserve-Commit gelten die On-Demand-Gebühren für die gesamte genutzte Kapazität. Beträgt der reservierte Commit beispielsweise 10 TB, gilt der reservierte Commit-Tarif, bis 10 TB verbraucht sind, und erst dann wird der höhere On-Demand-Tarif fällig.

Dauer: Hier wird angegeben, wie lange der Preis gilt. Im Allgemeinen gilt: Je länger die Dauer der Zusage, desto niedriger ist der Preis pro GB.

Produkte: Ein Lizenzvertrag kann sich auf ein bestimmtes Produkt oder eine Reihe von Produkten beziehen. Mit der Evergreen//One-Leistungsstufe können Lizenzen sowohl für FlashArrays vor Ort als auch für CBS-Bereitstellungen generiert werden. Eine Lizenz kann auch nur für den Cloud Block Store gelten. Derzeit ist in der Region Germany West Central nur eine Zone mit dem Code V10/V20MU-R1 verfügbar. In anderen Regionen wie France Central oder West Europe sind es drei. Der Regionscode V20MP2-R2 unterstützt in Deutschland keine Zonen, dafür aber in West Europa und France Central drei.

Bevor sich alle Funktionen nutzen lassen, müssen einige Vorbedingungen erfüllt sein. Zunächst muss eine Azure Active Directory Premium 2 Licence (Preis: 8,40 Euor pro Nutzer und Monat) vorhanden und aktiviert sein. Darüber hinaus ist das Aktivieren des Just-in-Time-Zugriffs (JIT) obligatorisch. Dieser ermöglicht dem Speicherhersteller, Live-Support zu leisten und unterbrechungsfreie Upgrades für Kunden durchzuführen. JIT gibt Anwendern die Möglichkeit, Anfragen von Pure Support zur Durchführung von Supportfunktionen zu genehmigen. Es wird empfohlen, Azure-VM-Instanzen zu reservieren. Dafür gibt Microsoft den Kunden die Option bedarfsgerecht zu bezahlen oder einen vorher festgelegten Kauf von Azure Reserved VM-Instanzen (RI) zu vereinbaren. Die Zahlung für On-Demand-VMs-Instanzen ermöglicht es Kunden, nur für die VMs zu zahlen, wenn sie eingeschaltet sind. Im Vergleich zu Reserved Instances sind sie pro Stunde teurer, wenn sie eingeschaltet sind. RIs sind stark rabattiert und pro Stunde günstiger, aber die Kunden sind verpflichtet, für sie zu zahlen, unabhängig davon, ob die VM-Instanz ein- oder ausgeschaltet ist.

Des Weiteren muss sichergestellt sein, dass genügend vCPU-Ressourcen vorhanden sind. Dafür kann der Admin das Get-AzVMUsage PowerShell cmdlet für seine Region ausführen und seine CPU-Ressourcen einsehen. Je nach Cloud-Block-Store-Typ werden 64 oder 128 vCPUs benötigt. Ebenso notwendig für den Einsatz von CBS ist das Einrichten der Azure-IAM-Rollen und Genehmigungen. Die einfachste Möglichkeit ist, die Rolle des Contributor für das Abonnement zu haben, in dem die CBS-Instanz bereitgestellt wird. Wenn das nicht möglich ist, kann ein Benutzer den Cloud Block Store trotzdem bereitstellen, solange er die folgenden drei aufgeführten Mindestrollen hat:

• Managed Application Contributor-Rolle für das Abo
• Managed Application Contributor-Rolle für die Ressourcengruppe, für die CBS bereitgestellt werden soll
• Managed Application Contributor-Rolle für die Subnetze, mit denen CBS genutzt werden soll.

Cloud Block Store wird mit den folgenden vier Netzwerkschnittstellen auf jeder Controller-VM bereitgestellt:

• System
• iSCSI
• Management
• Replikation

Es sollten schon VNets oder Subnetze vorhanden sein, denn während der CBS-Bereitstellung ist ein Einrichten von neuen Vnets oder Subnetzen nicht möglich. Und führt zum Fehlschlagen der CBS-Bereitstellung. Alle Netzwerkschnittstellenmüssen im gleichen Vnet sein, da diese alle mit dem gleichen Controller verbunden sind. Allerdings können die Interfaces auf verschiedenen Subnetzen liegen.

Unerlässlich für die Nutzung von CBS für Azure-VMs ist natürlich eine gut funktionierende Internetanbindung. Dabei ist es unerheblich, wie die Verbindung hergestellt wird, beispielsweise direkt oder über ein Gateway. Um erhöhte Sicherheit zu gewährleisten, empfiehlt es sich die Firewall-Regeln zu überprüfen und im Bedarfsfall anzupassen. Sie sollten so konfiguriert sein, dass sie den notwendigen Ports Internetzugang gewähren. Auch dies muss vor dem Einsatz des CBS erfolgen. Zusätzlich dazu müssen Service-Endpoints eingerichtet werden. CBS verwendet CosmosDB, um Metadaten des CBS und der darunter liegenden Komponenten zu speichern. Die Endpunkte sollten für das Subnetz erstellt werden, das für die Systemschnittstellen verwendet wird. Neben den Endpunkten müssen auch Rollen für die Netzwerksicherheitsgruppen (Network Security Groups) eingerichtet werden. Zu guter Letzt ist eine User Managed Identity zwingend nötig, um die Sicherheit des Datenverkehrs zu gewährleisten. Das ist notwendig, da die beiden genutzten Komponenten Azure Key Vault und CosmosDB einen öffentlichen Netzwerkzugriff erlauben. Um diese Konfiguration zu ändern, benötigen Anwender die User Managed Identity, die vor der CBS-Nutzung eingerichtet werden muss.

Sind all diese Schritte unternommen, kann der Cloud Block Store für Azure-VMs genutzt werden, beispielsweise für Datenmigrationen oder Disaster Recovery. Eine Schritt-für-Schritt-Anleitung für die Bereitstellung von CBS mit dem Azure-GUI finden sie auf dieser Webseite, während ein Deployment mittels Azure CLI an dieser Stelle beschrieben wird. 

Die Migration von Azure-VMs erklärt

Für eine Migration von lokalen virtuellen Maschinen in die Azure-Cloud werden Azure Migrate, das Pure FlashArray und Cloud Block Store entsprechend konfiguriert. Azure Migrate stellt zunächst fest, dass sich die zu migrierende VM im vCenter befinden, und wird dann so konfiguriert, dass nur das Boot-Disk/Volume migriert wird. Sobald die anfängliche Synchronisierung abgeschlossen ist, erstellt Azure die Instanz (Azure VM) und fügt das Boot-Volume an diese an, da die Migrationskonfiguration die Daten-Volumes ausschließt. Diese Volumes werden mit der integrierten Pure-Replikation zwischen FlashArray und CBS repliziert und können mit In-Guest-iSCSi in die erstellte Instanz eingebunden werden. Vor der Migration muss CBS eingerichtet sein. Ebenso ist es wichtig, die Verbindung für die asynchrone Replikation zwischen dem standorteigenen FlashArray und dem CBS einzurichten. Falls VMFS Datastores genutzt werden, müssen diese in vVols konvertiert werden.

Erste Schritte vor der Migration

Als erstes müssen die Genehmigungen des Azure-Kontos verifiziert werden. Im Menüpunkt Subscription wählt der Admin dafür Access Control (IAM) aus und prüft seine Zugriffsdetails (View my Access). Der Contributor sollte hier Owner-Genehmigungen haben. Im zweiten Schritt wird ein neues Azure-Migrate-Projekt erstellt. Dies kann im Menü mit Get started > Discover, Assess and Migrate und dann mit dem Button Create Project umgesetzt werden.

Danach stellt der IT-Verantwortliche die Azure-Migrate-Appliance bereit. Dazu wird unter Discover in Azure Migrate VMware vSphere als Hypervisor ausgewählt und ein Name für die Appliance bestimmt. Mit einem Klick auf Generate Key erhält man einen Schlüssel, mit dem die Registrierung der Appliance abgeschlossen werden kann. Als nächstes lädt der Administrator mit der vSphere-Client-Konsole die OVA-Datei ins vCenter herunter und führt das OVA Template aus. Ein Wizard hilft hier bei der Umsetzung der OVA-Bereitstellung.

In der vSphere-Konsole erfolgt dann die Konfiguration der Azure-Migrate-Appliance. Der Konfigurationsmanager prüft zunächst, ob alle Vorbedingungen erfüllt sind. Für die Konfiguration nutzt der Admin den vorher erzeugten Schlüssel für das Login. Dies generiert den Gerätecode, mit dem man sich bei Azure authentifiziert.

Im Anschluss daran nutzt der Anwender seine Anmeldeinformationen für vCenter, um VMware-VMs ausfindig zu machen. Nach der Anmeldung werden gefundene VMware-VMs im Azure-Portal aufgelistet. Optional kann der Admin nun Azure VM Assessments einrichten. Die Bewertungen helfen bei der Größenbestimmung der ermittelten VMs und empfehlen, welche Azure-VM-Größe und welcher Festplattentyp für diese Maschinen in Frage kommen. Es gibt zwei Arten der Größenbestimmung: Die eine ist leistungsbasiert und basiert auf den gesammelten Daten von vCenter. Die zweite Art basiert auf den tatsächlichen Größen der VMs in der VMware-Umgebung.

Nun kann die Quell-VM für die Migration vorbereitet werden. Hierfür muss die Quell-VM für die Fernverbindung konfiguriert werden. Hier gibt es Unterschiede je nach verwendetem Betriebssystem. Für virtuelle Maschinen in Windows muss der Remote Desktop in der Windows-Firewall aktiv und zugelassen sein. Bei Linux-VMs muss der Admin sicherstellen, dass Secure Shell Service aktiviert ist und beim Booten automatisch startet. Darüber hinaus müssen in den Firewall-Regeln die SSH-Verbidnungen zugelassen werden.

Die Migration: Azure Migrate

Für die Migration werden als erstes die virtuellen Maschinen repliziert. Dazu wählt der Admin in Azure Migrate Windows, Linux and SQL Server aus und unter Server Migration die Schaltfläche Replicate. In den Source Settings wird VMware vSphere und die entsprechende standorteigene Appliance angeklickt. Dann wählt der IT-Verantwortliche die zu replizierenden VMs aus. Unter Target Settings gibt man an, wo die VMs nach der Migration platziert sind. Im Bereich Compute wird der Name der Azure-VM bestimmt, den die Maschine nach der Migration haben soll, die VM-Größe festgelegt und die OS Disk angegeben. Danach vergibt der Admin nur noch Tags, kann seine Angeben überprüfen und die Migration starten. Dafür muss er nur unter den Menüpunkt Windows, Linux and SQL Server wählen und unter Azure Migrate: Server Migration auf Migrate klicken.

In der oberen Menüleiste steht ein Benachrichtigungssymbol zur Verfügung. Dort kann der Anwender auf Migrationsauftrag starten, um den Migrationsauftrag zu verfolgen. Unter Virtual Machines lassen sich die migrierten VMs dann auswählen. Die VMs haben jeweils nur eine private IP-Adresse. Für die Verbindung zur VM gibt es zwei Möglichkeiten. Zum einen können Sie eine Jump-Box-Maschine oder Bastion verwenden, um eine Verbindung über die private IP-Adresse herzustellen. Eine weitere Option ist es, eine öffentliche IP-Adresse zu erstellen und zuzuweisen.

Die Migration: Cloud Block Store

Um die Replikation von einem standorteigenen FlashArray aus zu konfigurieren, muss sich der Admin mit dem Cloud Block Store verbinden, den Verbindungsschlüssel abrufen und damit die Verbindung zwischen dem Array und CBS einrichten. Dies erfolgt in vier einfachen Schritten:

• Eingabe der Managementadresse: Das ist die CBS-IP-Adresse, um sich mit dem GUI zu verbinden.
• Typ des Prozesses angeben: Hier wird asynchrone Replikation ausgewählt.
• Verbindungsschlüssel eingeben: Der zuvor erhaltene Schlüssel wird genutzt.
• Replikationsadresse: Die Replikationsadressen werden normalerweise automatisch erkannt, es sei denn, es wird NAT eingesetzt. In dem Fall muss der Admin über das GUI unter Einstellungen > Netzwerk die Adresse ausfindig machen.

Danach wird eine Schutzgruppe (Protection Group) für die Replikation zum CBS eingerichtet. Diese Schutzgruppe klickt der Anwender an, womit er dann den Zeitplan der Replikation bearbeiten und aktivieren kann. Unter Target fügt man das Ziel für die Schutzgruppe hinzu, was der Cloud Block Store ist. Über das Pure-Storage-Plug-in importiert der Administrator diese Schutzgruppe ins vCenter.

Unter dem Menüpunkt VM and Templates wählt man die zu replizierenden VMs mit einem Rechtsklick aus und klickt dann den Button Edit VM Storage Policies. Im nächsten Schritt aktiviert der Admin die Option Configure by Disk (Konfigurieren pro Datenträger) und weist den Datenträgern/Volumes die Replikationsrichtlinie zu (der Betriebssystemdatenträger muss nicht ausgewählt werden, da er bereits mit Azure Migrate in den vorherigen Abschnitten repliziert wurde).

Nachdem die Snapshots zum CBS repliziert wurden, wird der replizierte Snapshot auf ein Volume kopiert. Danach muss der Admin einen Host in CBS erstellen und mit der IQN konfiguriert, die von der neuen Azure VM-Instanz gesammelt wurde. Die VM-Volumes werden dann mit dem neuen Host verbunden. Daraufhin können die Azure-VMs über den CBS konfiguriert werden.

Eine vollständige Anleitung für das Disaster Recovery von Azure-VMs über mehrere Regionen hinweg kann hier eingesehen werden.