StarWind Virtual SAN - Hybrid Cloud for Azure: Hochverfügbaren Speicher für VMs einrichten

Genau dieser gemeinsame Speicher für Hyper-V lässt sich auch nach Azure erweitern und VMs können live in die Cloud migriert werden bzw. on-prem ihre Dienste anbieten. Erforderlich hierfür sind gebuchte Maschinen in Azure, Dv3 oder Ev3, mit aktivierter Nested Virtualization. Für mein Lab sind diese in West-Europa (Amsterdam) verfügbar, zum Zeitpunkt dieses Blog-Posts aber noch nicht in den deutschen Rechenzentren (Frankfurt oder Magdeburg).

Bei unserem "Stretched"-Cluster-Design sind im Vorfeld einige Bedingungen abzuklären, zusammen­gefasst ergeben sich folgende Voraussetzungen:

• Eine registrierte Azure Subscription
• Eine Azure Region mit der angesprochenen Möglichkeit für die Nested Virtualization und geringer Netzwerk-Latenz

Mein Kurztest zur Latenz findet über AzureSpeed.com statt, für ausführlichere Tests liefern CloudHarmony oder PsPing via TCP entsprechende Werte. Die Ergebnisse sind sicher erst einmal keine Überraschung, da klar ist, welches RZ am nächsten ist. Sie erlauben jedoch eine erste Einordnung.

Darüber hinaus benötigen wir

• Eine statische öffentliche IP-Adresse für unser VPN mit Azure (siehe Abb. 1.0 - VPN Device und Virtual Network Gateway)
• Eine performante Internet-Verbindung, sinnvoll sind als Minimum 100 Mbit aufwärts
• Active Directory inkl. DNS im lokalen Netzwerk (On-Premises), ggfs. ein konfiguriertes RRAS
• Windows Server 2016 auf allen Cluster-Knoten

Vorbereitungen unter Azure

Innerhalb des aktuellen Azure Portals erstellen wir die nötigen Ressourcen beispiels­weise nach folgendem Muster:

• Hier legen wir zu Beginn eine Ressourcengruppe (RG) an, welche als Container für alle separaten Ressourcen dient
• Innerhalb der RG über Hinzufügen müssen wir dann ein neues Virtual Network anlegen
• Unterhalb des virtuellen Netzwerk und Subnetze ein Gatewaysubnetz bestimmen
• Über (+) Neu ein Gateway für virtuelle Netzwerke (Virtual Network Gateway) für das Site-to-Site VPN erstellen

Die Bereitstellung des Virtual Network Gateway dauerte bei mir im Labor 27 Minuten. Schließlich stehen noch folgende Aufgaben an:

• Lokales Netzwerk-Gateway (Local Network Gateway) mit (+) Neu definieren, soll heißen das on-premises VPN-Gerät angeben (Public IP der VPN-Device und den IP-Bereich des lokalen Netzwerks)
• Unterhalb des Gateway für virtuelle Netzwerke über Verbindungen => Verbindung hinzufügen und Site-to-Site (IPSec) konfigurieren.

Im Azure Marketplace suche ich nach dem vorkonfigurierten Image StarWind Virtual SAN BYOL. Dieses Image erfordert später eine gültige StarWind-Lizenz.

Über Erstellen wird dann der virtuelle Computer in Azure definiert. Nachdem die Angaben zur Grundeinstellung gemacht wurden (vorhandene RG, usw.), lässt sich die Größe der Dv3 oder Ev3 festlegen. Für mein Labor wähle ich einen Standard-D4S_V3 mit 4 vCPUs und 16 GB RAM.

Unter Einstellung nutzen wir unser bereits konfiguriertes virtuelles Netzwerk, das Default-Subnetz und die Public-IP-Adresse. In der Netzwerk­sicherheits­gruppe füge ich folgende IKEv2 UDP Ports hinzu: 500, 4500, 1701 und 50 für eingehenden plus ausgehenden VPN-Traffic.

Danach kann man sich über RDP mit der Azure Host-Maschine verbinden und innerhalb dieser dann Hyper-V, Multipath I/O und das Feature Failover-Clustering aktivieren.

Zusätzliche Netzwerkschnittstellen werden im Azure Portal erstellt und der ausgeschalteten VM angefügt. Weitere Managed Disks lassen sich innerhalb der Azure VM über Einstellungen hinzufügen.

Vorbereitungen im eigenen Rechenzentrum (On-prem)

On-Premises muss zu Beginn Ihre VPN-Appliance vorbereitet werden oder der Routing and Remote Access Service (RRAS) installiert und konfiguriert sein. Ob das VPN-Gerät mit Azure kompatibel ist, lässt sich auf den Seiten Microsofts herausfinden.

Der RRAS kann auf einem Windows Server 2016 System beispielsweise im Server-Manager mit der Rolle Remotezugriff aktiviert werden. Weiter sind dann die Rollendienste DirectAccess und VPN (RAS), Routing und IIS erforderlich. Auch die lokalen UDP Firewallports 500, 4500, 1701 und 50 müssen in beide Richtungen für den VPN-Traffic geöffnet sein. Die Konfiguration enthält anschließend folgende Werte:

• Konsole Routing und RAS öffnen
• Routing und RAS konfigurieren und aktivieren
• Sichere Verbindung zwischen zwei privaten Netzwerken aktivieren
• Bei Bedarf herzustellende Wählverbindung: Ja
• Wie sollen IP-Adressen zugewiesen werden: Automatisch
• Name der Schnittstelle für Wählen bei Bedarf vergeben
• Verbindung über ein VPN herstellen
• Typ: IKEv2
• Azure Public IP eintragen (GW für virtuelle Netzwerke)
• Routing von IP-Paketen auf dieser Schnittstelle
• Statische Route zum Azure-VM-Netzwerk eintragen
• Azure Virtuellen Netzwerkadressbereich einfügen
• Anmelde­informationen Benutzername: Azure
• Unterhalb von Routing und RAS, Netzwerk­schnittstellen, Eigenschaften der Schnittstelle
• Optionen: Persistente Verbindung
• Sicherheit: in Azure definierten Schlüssel zur Authentifizierung eingeben
• Abschließend über das Kontextmenü Verbinden wählen. Ist der Tunnel aufgebaut, zeigt auch die Azure "Site2Site"-Verbindung diesen Status.

Stretched Hyper-V Cluster erstellen

Bevor wir nun StarWinds VSAN konfigurieren und den Hyper-V-Cluster erstellen können, muss die Azure-VM der lokalen Domäne beitreten. Für die Namensauflösung dient der on-prem DNS, welchen ich im Azure VNet hinterlegt habe.

Lokal existieren derzeit zwei Cluster-Knoten inklusive aktiviertem Hyper-V. Beide benötigen ein installiertes StarWind Virtual SAN v8, der Azure-Knoten enthält bereits StarWinds VSAN-Software. Wie eine Installation abläuft und eine darauffolgende Konfiguration der LUNs habe ich in einem früheren Beitrag beschrieben.

Wenn der zentrale Speicher zur Verfügung steht, kann schlussendlich der Hyper-V Cluster gebildet werden.

*Dieser Text ist ein bezahlter Beitrag von StarWind Software.