In meinen bisherigen Blog-Beiträgen zum Thema Microsoft Storsimple bin ich auf die grundlegenden Funktionen der Microsoft StorSimple eingegangen. Microsoft StorSimple ist eine hybride Storage-Lösung von Microsoft, um den lokalen Anwendern einfach, schnell und sehr kostengünstig Storage aus dem Microsoft Azure Rechenzentrum zur Verfügung zu stellen.

Nun möchte ich in den folgenden Blog-Beiträgen einzelne Aspekte weiter vertiefen. Eins der wichtigsten Themen ist Desaster-Recovery. Nach der grundlegenden Installation der Microsoft StorSimple sind Maßnahmen zu treffen, um die Lösung anhand der Anforderungen an die Verfügbarkeit entsprechend auszurichten. Am Beispiel eines File-Servers möchte ich dieses Szenario technisch näher beschreiben.

Architektur

Wie sieht die Architektur dieses Szenarios aus? Der File-Server wird mit Windows Server 2012 R2 betrieben in einer VM. Ggf. als Failover-Cluster Konfiguration. Storage bezieht der Server von der StorSimple in Form von iSCSI-Volumes als Cluster Shared Volume (CSV). Die Volumes werden von der StorSimple nach Azure gespiegelt (Cloud-Snapshots). Die Anwender greifen als Domänen-Anwender auf die Ressourcen zu.

Diese Architektur bietet eine hervorragende Verfügbarkeit. Sämtliche Komponenten sind redundant vorhanden. Der Betrieb beschränkt sich auf ein Minimum an Aufwand und Kosten.

 

Was muss ich wissen?

Was muss ich wissen um die Umgebung für ein „Enterprise“-Desaster Recovery fit zu machen? In diesem Abschnitt gehe ich auf die einzelnen Bestandteile ein, die ich benötige, um das DR aufzubauen. Diese sind:

• Cloud-Appliance für iSCSI-Volumes in Microsoft Azure
• Active-Directory in Azure oder lokal
• Azure Site-Recovery Vault
• Azure Automation

Ich habe in den vorangegangenen Blog-Beiträgen beschrieben welche Funktionalitäten Microsoft StorSimple bietet. Zu nennen ist in diesem Kontext die Möglichkeit Cloud-Snapshots anzufertigen. Diese Funktion kopiert den gesamten Datenbestand verschlüsselt und sicher von einem bestimmten iSCSI-Volume in die Microsoft Azure Cloud auf Blob-Storage. Super! Damit sind meine Daten also erstmal sicher. Nun fehlt die Möglichkeit auf die Daten zuzugreifen. Zum einen müssen die Daten aus den iSCSI-Volumes, verfügbar gemacht werden. Dafür wird die Microsoft StorSimple Cloud-Appliance genutzt. Die Microsoft StorSimple Cloud-Appliance ist die virtuelle Appliance in Form einer Microsoft Azure VM. Die Cloud-Appliance bietet die gleichen Funktionalitäten wie die Hardware-Appliance. Stellt also Servern iSCSI-Volumes zur Verfügung. Besondere Beachtung ist aber folgendem Umstand geschuldet. Eine Cloud-Appliance kann maximal 64 TB an Daten verwalten. Liegen auf der Hardware-Appliance also mehr als 64 TB Daten in verschiedenen iSCSI-Volumes, so müssen die iSCSI-Volumes auf mehrere Cloud-Appliances verteilt werden. Das liegt daran, dass die Cloud-Appliance ja auch nur eine schlichte VM in Azure ist. Und bekanntermaßen unterstützt eine VM eine maximale Festplattengröße von 1023 GB und eine Anzahl von 64 Stck..

 

Nun benötige ich die Möglichkeit, dass die Anwender weiterhin authentifiziert werden können. Dafür bieten sich je nach Komplexität der Umgebung die folgenden Möglichkeiten an. Für weniger komplexe Umgebungen in denen nur ein Domain-Controller betrieben wird und nur eine kleine Anzahl von Anwender arbeitet,  bietet es sich an die komplette VM mit dem Domain-Controller mittels Azure Site Recovery nach Azure zu spiegeln und im Falle eines Desasters einfach hochzufahren. Wenn dann irgendwann der Desasterfall beendet ist, dann müssen natürlich sämtliche Änderungen an der Struktur in Azure im eigenen RZ nachgeholt werden. Das find ich nicht optimal und das ist teilweise auch gar nicht möglich. In einer großen Umgebung mit vielen DCs (in einem Forest), vielen Anwendern und auch einer hohen Änderungsrate im AD ist es anzuraten einen weiteren DC in Azure einzurichten der Teil der Gesamtstruktur ist. Also auch automatisch alle Änderungen in der Struktur in Microsoft Azure als Teil der Replication Topology wieder zurückspiegelt. Habe ich mir darum Gedanken gemacht komme ich nun zum zweiten Teil.

Nun benötige ich die Möglichkeit die File-Server, die die entsprechende Logik abbilden, dass Anwender auf die Shares (per DFS, Failover-Cluster, etc.) zugreifen können, auch während des Desasters verfügbar zu machen. Dafür benutze ich Microsoft Azure Site Recovery, um die entsprechenden VMs als bitgenaue Kopie ins Azure Datacenter zu replizieren, um sie im Desaster-Fall hochfahren zu können. Die nachfolgende Abbildung zeigt die grundlegende Funktionsweise von Microsoft Azure Site Recovery in diesem speziellen Szenario. Benötigt wird der „Azure Site Recovery Provider“, der auf den Hyper-V Host die Desaster-Aktionen koordiniert.

Er kommuniziert per Port 443 mit dem Microsoft Azure Datacenter. Dies wird den Datenschützer freuen. Zudem benötigt man einen „Recovery Services Agent“ auf jeder VM. Dieser führt bei Bedarf Scripte auf den eigentlichen VMs aus, um die Aktivitäten während eines Desasters auszuführen.

Zu guter Letzt benötige ich eine Möglichkeit den Failover-Prozess automatisiert durchzuführen. Dies ist möglich mit Microsoft Azure Automation. Dafür richte ich einen Azure Automation Account ein. Und wähle aus einem Fundus an fertigen! Scripten das entsprechende Runbook aus. Wenn ich das Runbook meinem Account hinzugefügt habe kann ich mit nur einem Mausklick mehrere Aktivitäten starten.

Der Planned Failover versucht die VMs im lokalen Rechenzentrum „freundlich“ herunterzufahren, um dann die Ressourcen in Azure hochzufahren. Dazu wird ein vorhandener Cloud-Snapshot an die Virtual-Appliance gemappt. Voilá.

Der Unplanned Failover fährt nur noch die VMs in Azure hoch und führt ein Failover des Volume-Containers der StorSimple durch. Danach sind die Volumes für die VMs verfügbar und der Fileserver kann wieder auf die Daten zugreifen

Der Testfailover hat keinerlei Auswirkungen auf die lokalen Server. Die VMs werden lediglich in Azure hochgefahren und die Volumes an die VMs gemappt. Zuvor werden die Volumes der StorSimple gecloned und an die Virtual Appliance angehängt. Hier habe ich also eine perfekte Spielwiese.

Besonders die bereits vorhandenen Runbooks für dieses Thema machen die Arbeit sehr einfach. Diese Scripte sind vorgefertigt und können an die eigenen Bedürfnisse angepasst werden.

Fazit und Ausblick

Ich bin auf die zahlreichen Vorteile der Microsoft StorSimple Lösung bereits in den vorangegangenen Blog-Beiträgen eingegangen. Die hybride Lösung die ich hier beschrieben habe verspricht eine sehr gute Verfügbarkeit für die bereitgestellten Fileservices, eine sehr einfache Administration und ein hohes Kosteneinsparungspotenzial. Denn als Desaster-Standort wird das Microsoft Azure Rechenzentrum verwendet. Ein zweiter eigener Standort an dem Failover-Hard- und Software betrieben werden muss ist hiermit obsolet geworden.
Microsoft wird in Zukunft die hybriden Datacenter-Lösungen stark weiterentwickeln. Bereits jetzt sind mit Azure Site Recovery, Azure StorSimple oder Azure Active Directory Lösungen am Start, die die lokale Infrastruktur mit Azure optimal verbinden.
In zukünftigen Blog-Beiträgen werde ich weitere Aspekte rund um das Thema hybride Rechenzentrumsarchitekturen in ähnlicher Aufmachung vertiefen.

Quellen

http://download.microsoft.com/download/7/7/5/775B1D68-BF20-4B3E-AD54-D12846CCDB38/StorSimple%20DR%20Solution%20using%20ASR%202015-12-07.pdf

https://azure.microsoft.com/en-us/blog/storsimple-azure-site-recovery-better-together/

https://technet.microsoft.com/en-us/library/cc755994(v=ws.10).aspx

http://www.comparex-group.com/web/de/de/blog/topics/it-infrastruktur/microsoft-azure-storsimple.htm

http://www.comparex-group.com/web/de/de/blog/topics/it-infrastruktur/storsimple-virtual-array.htm