Azure File Sync: Daten zwischen File-Server und der Cloud replizieren

Dabei kann auch ein Tiering aktiviert werden, welches oft verwendete ("hot") Daten lokal zwischen­speichert und weniger oft verwendete ("cold") Dateien in die Cloud auslagert. Backups lassen sich an die Cloud delegieren (Azure Backup), so dass Anwender ggfs. die lokalen Backupstrategien reduzieren können.

Dies erspart Kosten für den fort­währenden und vorausplanenden lokalen Speicher­ausbau plus dessen Wartung. Darüber hinaus kann Azure File Sync auch dem Disaster Recovery dienen.

Lokale Ordnerfreigabe

Ich gehe Schritt für Schritt durch eine Basis-Konfiguration von AFS sowie die dafür erforderlichen Vorberei­tungen in Azure. In meiner On-prem-Infrastruktur befinden sich zwei Windows Server 2019 als File-Server.

Der primäre liefert ausgehend die klassische Freigabe für alle Abteilungen auf Basis von NTFS und beide sind Mitglied der AD DS (Active Directory Domain Services).

Vorbereitungen in Azure

Wie schon erwähnt, starten wir in Azure, Voraus­setzung dort ist eine Subscription (hier: Pay-As-You-Go, nutzungs­basiert). Zu Beginn erstelle ich unter meiner Resource Group den benötigten Storage Account als Basis für die weitere Konfiguration.

Dabei lege ich für mein Lab keinen Wert auf Performance und somit kommt ein Standard-Account/Cool zum Einsatz. Die Replikation kann auch hoch­verfügbar mit Geographically Redundant Storage (GRS, weitere Information dazu finden Sie in meinem Beitrag zu Azure Storage) festgelegt werden.

Unter diesem Konto erstellen wir jetzt in File Service den Azure File share. Dieser ist standard­mäßig limitiert auf 5 TiB (Tebibyte, ca. 5,5 TB) und heißt in unserem Beispiel syncshare.

Tipp: Legen Sie sich im linken Navigations­baum des Azure-Portals Favoriten zu den häufigsten Themen an. Üblicher­weise werden Einstellungen bzw. Auswer­tungen unterhalb der Storage Accounts des Öfteren benötigt.

Danach suchen wir im Marketplace nach dem Azure File Sync-Dienst. Die angezeigte Visio verdeutlicht hier gut eine mögliche Infrastruktur-Übersicht.

Für das Aktivieren des Dienstes geben wir unter anderem Name, Ressourcen-Gruppe und Lokation an. Letztere ist identisch mit der unseres Speicher­kontos (Storage Account), nämlich West-Europa.

Danach können wir unseren filesync auch wieder über die Ressourcen­gruppe aus­wählen. Dort klicken wir auf den Menüpunkt Registered Server. Hier erscheinen natürlich erst einmal keine Einträge, da wir unsere File-Server noch nicht registriert haben.

Bevor wir das tun können, müssen wir den Azure File Sync-Agent für das entsprechende OS herunter­laden und lokal installieren.

Im oberen Drittel der Seite finden Sie den benötigten Link für den Download. Unterstützt werden die Betriebs­systeme Windows Server 2012 R2, 2016 und 2019.

Als nächstes wechseln wir zu den Servern unserer lokalen Infra­struktur, welche mit Azure synchronisiert werden sollen.

Lokale File-Server vorbereiten

Bevor wir jedoch den Agenten auf die Server bringen können, müssen diese mit dem PowerShell-Modul AzureRM versorgt werden. Über

Install-Module -Name AzureRM

installieren wir automatisch den NuGet Provider, falls er noch nicht vorhanden sein sollte, und anschließend das erwähnte PowerShell-Modul AzureRM.

Erst dann lässt sich der Storage Sync-Agent komplett installieren und mit unserem Azure-Mandanten bekannt­machen.

Die Installation richtet den Storage Sync-Agent Service auf den beiden Systemen ein, er startet später automatisch. Bei Bedarf kann man die Proxy-Einstellungen dediziert konfigurieren.

Nach erfolg­reicher Installation prüft die Software, ob es neuere Agenten-Versionen zum Download gibt (falls man diese Option aktiviert hat). Anschließend startet der Konfigu­rations-Wizard und man kann die Server über ein Sign-in bei Azure registrieren.

Dafür müssen interaktiv die Subscription Credentials, also Kontoname und Passwort, eingegeben werden.

Tipp: Schalten Sie auf dem Server vorher über den Server Manager temporär die IE Enhanced Security Configuration (IE ESC) für den Admini­strator aus.

Nach der erfolg­reichen Authentifizierung lassen sich die Subscription, Ressourcen­gruppe und der bereits angelegte Storage Sync Service auswählen. Danach erfordert der Prozess in meiner Umgebung erneut die Eingabe der Azure Credentials.

Sind die Registrierung und das Einrichten der nötigen Vertrauens­stellung abgeschlossen, kehren wir wieder in das Azure-Portal unterhalb des Storage Sync Service zurück. In der Liste der registrierten Server tauchen nun meine beiden Rechner mit ihrem FQDN auf. (Lassen Sie sich aktuell nicht von der angezeigten OS-Version irritieren, das Lab besteht aus Server 2019, hier muss sicher nachgebessert werden)

Konfiguration in Azure

Über den Link zu den Sync groups können nun die nötigen Synchro­nisations­gruppen eingerichtet werden. Diese müssen einen Cloud-Endpunkt enthalten, der seinerseits eine Azure-Dateifreigabe zur Speicherung der Daten umfasst, sowie einen oder mehrere Server-Endpunkte.

Im zuständigen Dialog vergibt man somit einen Namen für die Gruppe und wählt den Storage Account, die Subscription und Azure File Share aus.

Nachdem die Synchro­nisations­gruppe mit dem Cloud-Endpunkt eingerichtet ist, können nun die lokalen File-Server über Add server endpoints zugeordnet werden. Dazu gebe ich die jeweiligen Pfade zu meiner Datei­freigabe an. Mein Ausgangs-Server ist FSRV-2019-01, hier liegen aktuell die Freigabedaten. Ein Tiering findet nicht statt, die Shares liegen in meinem Lab auf dem System-Laufwerk, somit entfällt diese Option.

Der zweite Server enthält aktuell keine freige­gebenen Daten. Der Weg soll nun sein: Synchronisation des Datenbestandes von FSRV-2019-01 nach Azure und von da nach FSRV-2019-02.

Da der Umfang meiner zu synchroni­sierenden Daten gering ist, braucht der Prozess der Replizierung ca. 5 Minuten. Beide Server sind danach auf dem gleichen Stand.

Ein Blick in den Azure File Share verrät, dass der Abgleich funktioniert hat (Synchronisiert wird verschlüsselt über Port 443). Die Daten des ersten Servers wurden in die Cloud repliziert. Der zweite Server erhielt anschließend eine Kopie aller Dateien. Auch die NTFS-Berechtigungen wurden im Zuge der Synchro­nisierung beibehalten.

Die Daten in den Verzeichnissen der beiden Server werden nun künftig synchron gehalten. Das gilt nicht nur für das Anlegen und Ändern von Dateien, sondern natürlich auch für das Löschen. Entferne ich eine Datei am zweiten Server, verschwindet sie etwas zeitversetzt (ca. 20 Sekunden) auch am ersten.