Dateien ohne Grenzen

von Dr. Christian Knermann

Mit Azure Files und Azure File Sync stellt Microsoft klassische Dateifreigaben für Clients unter Windows, macOS sowie Linux in der Cloud und ohne herkömmlichen Dateiserver bereit. Die Synchronisation mit lokalen Dateiservern und verschiedene Möglichkeiten der Zugriffssteuerung runden die Funktionen ab. Dieser Workshop stellt die Dienste vor und begleitet durch deren Einrichtung.

Der ungebrochene Trend zu cloudbasierten Infrastrukturen hat viele neue Webanwendungen und Dienste hervorgebracht, die sich in ihrer Architektur vom klassischen Client-Server-Modell unterscheiden. Dies macht auch vor dem Speichermanagement keinen Halt, wo Objektspeicher für nahezu beliebig große Datenmengen, wie zum Amazon Simple Storage Service (S3) kompatible oder zumindest in der Funktionsweise ähnliche Dienste, auf dem Vormarsch sind. Auch Microsoft möchte auf diesem Feld mitspielen und bietet in der Azure-Cloud Blobcontainer, Warteschlangen und Tabellen als Speicher für cloudnative Anwendungen an.

Altlasten CIFS, SMB und NFS

In vielen Unternehmen existieren demgegenüber jedoch auch noch geschäftskritische Anwendungen im lokalen Netz, die nach althergebrachten Prinzipien funktionieren und auf herkömmliche Dateifreigaben setzen. Vor allem Windows setzt hierbei auf das Protokoll Server Message Block (SMB), doch auch macOS und Linux mit dem Paket "cifs-utils" verstehen sich darauf.

Verschiedentlich findet sich im Alltag mit dem Common Internet File System (CIFS) auch noch der von Microsoft geprägte ursprüngliche Begriff. Bei genauer Betrachtung bezeichnet CIFS allerdings nur den ersten Standardisierungsvorschlag, den Microsoft bei der Internet Engineering Task Force eingereicht hatte, und nicht das inzwischen bei der Version 3.1.1 angekommene SMB-Protokoll. Im Folgenden verwenden wir daher nur die Bezeichnung SMB. Mit dem freien Programmpaket Samba agieren Linux und UNIX-Derivate als SMB-Server und sogar eingeschränkt als Domaincontroller im Active Directory (AD), setzen daneben von Haus aus jedoch eher auf das Network File System (NFS).

Dateifreigaben ohne Server

Nun können Unternehmen, die eine Cloudstrategie verfolgen, längst nicht alle existierenden Anwendungen und Dienste, die auf SMB und NFS aufbauen, kurzfristig durch moderne Alternativen ersetzen. Hier stellt sich Admins somit die Frage, wie sie bestehende Applikationen auf Basis dieser Protokolle ganz oder teilweise in die Cloud migrieren. Sie können bisher lokal betriebene Server schlicht und einfach komplett als virtuelle Maschinen in die Cloud verlagern. Doch mit Azure Files [1] hat Microsoft auch eine schlankere Alternative im Portfolio.

Mit Azure Files realisiert Microsoft serverlos vollständig verwaltete Dateifreigaben in der Cloud, die Clients unter Win-dows, macOS und Linux per SMB oder NFS einbinden [2]. Hierbei verwenden Sie die bekannten Wege über den grafischen Datei-Explorer, die Kommandozeile, PowerShell oder Linux-Shell. Clients sowie Endanwender bemerken anschließend im besten Fall keinen Unterschied gegenüber der Arbeit mit einem herkömmlichen lokalen Dateiserver. Zusätzlich stellt der Dienst eine REST-API, in der Online-Dokumentation auch als FileREST-API bezeichnet, bereit und ermöglicht so den Zugriff per HTTPS.

Loslegen im Azure-Portal

Für Ihre ersten Schritte mit Azure Files benötigen Sie zunächst ein Speicherkonto in der Azure-Cloud. Am schnellsten gelangen Sie ans Ziel, indem Sie im Azure-Portal aus dem vertikalen Menü zur Linken den obersten Punkt "Ressource er- stellen" wählen, in der Liste der Dienste und des Marktplatzes nach "Speicherkonto" suchen und dann die Aktion "Erstellen / Speicherkonto" wählen. Alternativ erstellen Sie ein Speicherkonto und Freigaben darin auch per PowerShell oder dem Azure Command Line Interface (CLI), doch wir folgen zunächst weiter dem Assistenten.

Wählen Sie Ihr Abonnement und, sofern bereits vorhanden, die gewünschte Ressourcengruppe. Falls Sie einen Anwendungsfall komplett in der Cloud abbilden möchten, ist die Ressourcengruppe naheliegend, in der sich auch die SMB- oder NFS-Clients befinden. Beachten Sie beim Namen des Speicherkontos, dass dieser Teil der URL für den Zugriff über öffentliche Netze zum Einsatz kommt und daher global eindeutig sein muss. Bei Allgemeinplätzen wie "azurefiles" oder "azfiles" reagiert das Portal entsprechend mit einer Fehlermeldung, da der Name schon vergeben ist. Im Folgenden verwenden wir für unsere Beispiele den Kontonamen "wolkendateien".

Unterschiede in den Azure-Konten

Im Hinblick auf die Leistung unterscheidet Microsoft die Stufen "Standard" und "Premium". Erstere bezeichnet ein universelles v2-Konto, das auf festplattenbasierten Speicher setzt und laut Microsoft bereits die meisten Anwendungsfälle mit bis zu 1000 IOPS abdeckt. Ein solcher Account speichert neben Dateifreigaben zusätzlich auch die Speicherressourcen Blobcontainer, Warteschlangen und Tabellen. Er unterstützt zudem die lokal redundante (LRS), zonenredundante (ZRS), georedundante (GRS) und geozonenredundante (GZRS) Speicherung [3].

Ein Premium-Konto, auch als FileSto-rage-Speicherkonto bezeichnet, verwendet dagegen SSD-Datenträger und empfiehlt sich für Anwendungen, die eine besonders geringe Latenz und mehr als 1000 IOPS verlangen. Ein FileStorage-Account darf nur entweder Dateifreigaben, Seitenblobs oder Blockblobs, jedoch keine weiteren Speicherressourcen gleichzeitig enthalten und bietet nur die Redundanz- stufen LRS und ZRS.

Ein weiterer wichtiger Unterschied ist hier nicht auf den ersten Blick erkennbar: Standard-Konten beherrschen nur das SMB-Protokoll in den Versionen von 2.1 bis 3.1.1, während das NFS-Protokoll Premium-Accounts vorbehalten ist. Weiterhin unterstützt Azure Files NFS aktuell nur bis zur Version 4.1 und dies auch nur eingeschränkt ohne Funktionen, wie etwa Delegierungen und Rückrufe aller Art, Kerberos-Authentifizierung und Verschlüsselung während der Übertragung.

Während Azure Files für SMB die identitätsbasierte Authentifizierung per Kerberos sowie mit gemeinsam verwendeten Schlüsseln über das NTLMv2-Protokoll unterstützt, funktionieren Zugriffe per NFS nur mittels hostbasierter Authentifizierung. Weiterhin macht Azure Files nur SMB ab Version 3.0 aufwärts optional über das Internet zugänglich, NFS dagegen nicht. Wir legen daher im Folgenden den Fokus auf SMB-Freigaben.

Unabhängig von der Leistung beeinflusst die Redundanz auch die maximale Größe der Dateifreigaben. Lokal redundante und zonenredundante Konten fassen mit der optionalen Funktion "Große Dateifreigaben" bis zu 100 TByte, georedundante und geozonenredundante Konten nur maximal 5 TByte. Sie können die Unterstützung für große Dateifreigaben auch nachträglich noch einschalten, dies jedoch nicht mehr rückgängig machen, sobald die Option einmal aktiv ist. Mit Blick auf die Kosten können Sie später für einzelne Freigaben auch eine niedrigere maximale Kapazität konfigurieren.

Auf der nächsten Registerkarte "Erweitert" belassen wir es bei den Voreinstellungen. Mit TLS 1.2 ist hier die höchste verfügbare Mindestversion für die Transport-Layer-Security bereits aktiv. Optional können Sie hier zudem Kopiervorgänge auf Speicherkonten im selben Microsoft-Entra.ID-Mandanten oder Konten mit privaten Endpunkten zum selben virtuellen Netzwerk beschränken. Die Funktion hatte Microsoft bis zum Redaktionsschluss allerdings noch als Vorschau ausgewiesen.

Zugriff über öffentliche Netze

Weitere Möglichkeiten, den Zugriff einzuschränken, finden Sie auf der folgenden Registerkarte "Netzwerk". So ist standardmäßig der öffentliche Zugriff über alle Netze aktiv, also auch aus dem Internet. Alternativ beschränken Sie den öffentlichen Zugriff auf ausgewählte virtuelle Netzwerke und IP-Adressen oder deaktivieren ihn, sodass nur noch der private Zugriff bleibt. Letzteres setzt die explizite Konfiguration einer privaten Endpunktverbindung voraus. Die vorgewählte Präferenz des Microsoft-Netzwerkroutings leitet den Datenverkehr möglichst nah am Client in die Microsoft-Cloud, das Internetrouting dagegen nah am Azure-Endpunkt.

Auch wenn der öffentliche Zugriff aktiv ist, erübrigt dies je nach Anwendungsfall nicht weitere Überlegungen zur Netzwerkkonfiguration, da viele Unternehmensnetze, jedoch auch Internetprovider, den für SMB verwendeten TCP-Port 445 blockieren. Sofern sich Ihre SMB-Clients selbst in der Azure-Cloud befinden, stellt dies kein Problem dar. Lokalen Clients hilft eine VPN- oder ExpressRoute-Verbindung zwischen Ihrem lokalen und dem Azure-Netzwerk mit einem privaten Endpunkt für Azure Files innerhalb Ihres virtuellen Azure-Netzwerks. Die Überlegungen zum Netzwerkbetrieb erläutert Microsoft im Detail in der Online-Dokumentation unter [4].

Schutz der Daten

Der Tab "Datenschutz" adressiert nicht den Datenschutz im rechtlichen Sinne, sondern den Schutz vor versehentlichem Löschen. Für Dateifreigaben schreibt Microsoft ab Werk eine Aufbewahrungsdauer von sieben Tagen vor. Wichtig ist hierbei zu beachten, dass sich diese Angabe nur auf das Löschen der Dateifreigabe als Ganzes und nicht auf einzelne Daten innerhalb der Freigabe bezieht. Diese Schutzfunktion ist also kein Ersatz für Backups und Momentaufnahmen, die Sie pro Dateifreigabe konfigurieren.

Auf der Registerkarte zur Verschlüsselung ruhender Daten haben Sie die Wahl zwischen von Microsoft verwalteten Schlüsseln (Microsoft Managed Key, MMK) oder kundenseitig verwalteten Schlüsseln (Customer Managed Key, CMK). Im ersten Fall ist Microsoft im Besitz der Schlüssel und kümmert sich darum, diese regelmäßig zu rotieren. Sie können auch Ihre eigenen Schlüssel verwalten, müssen sich dann aber selbst um den Rotationsvorgang kümmern. Weiterhin müssen Sie Azure Files für den Zugriff auf Ihre Schlüssel autorisieren, um Lese- und Schreibanforderungen von Clients zu ermöglichen.

Optional versehen Sie das Speicherkonto noch mit Tags, die in großen Umgebungen das Kategorisieren von Ressourcen und die Anzeige konsolidierter Abrechnungen erleichtern. Schließlich überprüfen Sie die gewählten Einstellungen und erstellen das Speicherkonto, das kurze Zeit später unter dem Punkt "Speicherkonten" im Hauptmenü des Azure-Portals erscheint. Wählen Sie das Objekt aus, blendet das Portal ein Untermenü ein, in dem Sie die beim Einrichten gewählten erweiterten Optionen sowie die Einstellungen zu Netzwerk, Datenschutz und Verschlüsselung auch nachträglich noch ändern können. Dies funktioniert nur, soweit die Abhängigkeiten der Funktionen es zulassen. So schränkt etwa eine aktivierte Option für große Dateifreigaben die Auswahl der Redundanzen ein.

Freigaben mit Backups und Snapshots

Wählen Sie nun aus dem Untermenü Ihres Speicherkontos den Punkt "Datenspeicher / Dateifreigaben" und legen Sie eine erste Freigabe an, hier exemplarisch mit dem Namen "wolkenfreigabe". Neben einem Namen lässt sich bei den allgemeinen Informationen die Ebene konfigurieren. Diese bezieht sich auf den primären Einsatzzweck der Dateifreigabe. Die Ebene "Heiß" dient universellen Dateifreigaben für die direkte Interaktion mit Endanwendern bei der Arbeit im Team sowie auch als Basis für Azure File Sync.

Die Ebene "Kühl" optimiert den Speicher für die Verwendung als Onlinearchiv und "Transaktion optimiert" empfiehlt sich für transaktionsintensive Serveranwendungen ohne besonders hohe Anforderungen an die Latenz. Letztere adressiert "Premium", dies steht aber nur innerhalb von Speicheraccounts zur Wahl, die SSD-basierten Premium-Speicher verwenden. Für unsere erste Freigabe wählen wir "Heiß".

Auf der Registerkarte "Backup" aktiviert Microsoft standardmäßig tägliche Datensicherungen und bewahrt diese für jeweils 30 Tage auf. Alternativ konfigurieren Sie eine individuelle Richtlinie für die Sicherung. Die verfügbaren Optionen sind überschaubar. Statt einer täglichen Sicherung stehen stündliche Backups alle vier, sechs, acht oder zwölf Stunden zur Wahl.

Ist die Freigabe erstellt, können Sie anschließend in deren Untermenü unter dem Reiter "Vorgänge / Backup" manuell eine initiale Sicherung veranlassen oder den ersten zeitgesteuerten Lauf abwarten. Sobald Backups vorhanden sind, stellen Sie wahlweise die komplette Freigabe wieder her oder holen einzelne Ordner und Dateien zurück. Zusätzlich zu Backups erzeugen Sie unter "Vorgänge / Momentaufnahmen" bis zu 200 inkrementelle Snapshots pro Freigabe, die Sie bis zu zehn Jahre lang für rein lesenden Zugriff aufbewahren können.

Verbinden mit Windows, Linux und macOS

Zunächst wollen wir unsere Freigabe auf einem Client manuell verbinden. Ohne weiteres Identitätsmanagement, auf das wir gleich zurückkommen werden, benötigen Sie dazu einen Zugriffsschlüssel als Passwort. Diesen Schlüssel finden Sie auf der Ebene des Speicherkontos unter dem Menüpunkt "Sicherheit + Netzwerkbetrieb / Zugriffsschlüssel". Auf der Seite bietet Ihnen das Azure-Portal zwei Keys an, die Sie gleichwertig verwenden und unabhängig voneinander rotieren. So können Sie jeweils einen der Schlüssel ersetzen, während Sie den anderen gerade verwenden.

Verbinden Sie nun auf einem Windows-Client im Explorer ein Netzlaufwerk. Als Ziel verwenden Sie dabei den FQDN des Speicherkontos und der Freigabe darin, in unserem Fall "\\wolkendateien.file.core. windows.net\wolkenfreigabe". In das Feld für den Benutzernamen tragen Sie den Namen des Speicherkontos ein und beim Kennwort einen der beiden Zugriffsschlüssel (Bild 1). Die Freigabe in der Cloud erscheint nun im Explorer als Netzlaufwerk. Alternativ zum grafischen Dialog hilft unter Windows die Kommandozeile

Alle Ordner und Dateien, die Sie nun unter Windows in der Dateifreigabe speichern, erscheinen auch im Azure-Portal in der Darstellung der jeweiligen Freigabe unter dem Menüpunkt "Durchsuchen". Die Option "Verbinden" in der Kopfzeile dieser Ansicht liefert Ihnen zudem Skripte für Windows, Linux und macOS, mit denen Sie die Freigabe künftig ohne manuellen Aufwand einbinden (Bild 2).

Granulare Berechtigungen nur mit IAM

Beachten Sie dabei, dass die Verbindung per Zugriffsschlüssel zwar schnell konfiguriert ist, jedoch keine granularen Berechtigungen zulässt. Über diesen Weg verbinden Sie eine Freigabe immer mit vollen administrativen Rechten. Daher empfiehlt Microsoft diese Art des Zugriffs nur zusammen mit VPN-Verbindungen und privaten Endpunkten, jedoch nicht für den öffentlichen Zugriff über das Internet. Innerhalb der Freigabe können Sie zudem ohne Weiteres keine NTFS-Berechtigungen für Benutzer und Gruppen aus Ihrer lokalen Domäne vergeben, da das Speicherkonto in der Cloud diese Identitäten nicht kennt. Die Integration per Zugriffsschlüssel taugt folglich nur für manche Serveranwendungen, die ohne unmittelbare Interaktion mit den Endanwendern auskommen, weniger für die Arbeit im Team.

Doch Microsoft bietet für granulares Identitäts- und Berechtigungsmanagement gleich mehrere Optionen, darunter die Integration mit Entra ID, dem ehemals als Azure AD bekannten cloudbasierten Identity- und Access-Management (IAM), sowie die Anbindung an ein lokales AD [5]. Letzteres setzt allerdings die Synchronisation des lokalen AD mit der Cloud per Microsoft Entra Connect, ehemals Azure AD Connect, voraus.

Synchronisationsdiensteinrichten

Mit Azure Files in die Cloud verlagerte SMB-Freigaben erscheinen Endanwendern wie lokale Ressourcen. Doch was tun, falls die Bandbreite zu mager oder die Latenz zu groß ist und Anwender bei der Arbeit mit dort gespeicherten Daten über mangelnde Performance klagen? Hier springt Azure File Sync ein, im Deutschen als Azure-Dateisynchronisierung bezeichnet. Diese nutzt einen oder mehrere Windows-Server, auch an unterschiedlichen Standorten, als lokalen Cache und verbindet so die Vorteile zentraler Speicherung in der Cloud mit der höheren Geschwindigkeit eines lokalen Zugriffs.

Wählen Sie wiederum im Azure-Portal die Option "Ressource erstellen" aus dem Hauptmenü, suchen Sie nach "Azure File Sync" und richten Sie eine neue Ressource dieses Typs ein. Im ersten Schritt bestimmen Sie, in welchem Abonnement sowie welcher Ressourcengruppe der Dienst unterkommt, und geben ihm einen Namen, hier exemplarisch "wolkensync". Ähnlich wie beim Speicherkonto können Sie den Zugriff über alle Netzwerke oder nur über private Endpunkte erlauben, die Ressource optional mit Tags versehen und schließlich erstellen.

Wechseln Sie anschließend zur neuen Ressource. In deren Untermenü wählen Sie den Punkt "Synchron. / Synchronisierungsgruppen" und erstellen eine neue Gruppe. Neben einem Namen wählen Sie auch hier das Abonnement, das gewünschte Speicherkonto und eine Freigabe darin, die bidirektional als Quelle und Ziel für den Abgleich mit Ihrem lokalen Dateiserver fungieren soll.

Konfiguration für Windows Server von 2012 R2 bis 2022

Sofern noch nicht vorhanden, installieren Sie auf dem lokalen Dateiserver das PowerShell-Modul für den Azure Resource Manager. Dazu führen Sie in einer administrativen PowerShell Install-Module -Name AzureRM aus. Die PowerShell verlangt hierbei nach dem NuGet-Anbieter und der Erlaubnis, das Repository "PSGallery" zu verwenden, was Sie beides bestätigen.

Laden und installieren Sie nun den für Windows Server 2012 R2, 2016, 2019 und 2022 verfügbaren Azure-File-Sync-Agenten [6]. Die Setuproutine präsentiert die unvermeidlichen Lizenzbestimmungen, fragt nach dem Pfad zur Installation und nutzt optional einen Proxy-Server sowie Microsoft Update für Aktualisierungen.

Der Assistent zur Konfiguration verbindet sich wahlweise zur Azure-Cloud oder den separaten Cloudinstanzen für den chinesischen Markt oder die US-Regierung. In der Regel ist hierzulande "AzureCloud" die richtige Wahl. Nach der Anmeldung an der Cloud mit einem administrativen Benutzerkonto wählen Sie auch hier Ihr Abonnement, die Ressourcengruppe und den Speicher-Synchronisierungsdienst darin.

Der Assistent registriert Ihren Server daraufhin in der Cloud und testet die Netzwerkverbindung (Bild 3). Ist beides von Erfolg gekrönt, erscheint der Server im Azure-Portal und dort in der Ressource des Speichersynchronisierungsdiensts unter dem Menüpunkt "Synchron. / Registrierte Server".

Navigieren Sie nun zur Ansicht der zuvor erstellten Synchronisierungsgruppe und wählen Sie die Aktion "Serverendpunkt hinzufügen". Im nächsten Schritt richten Sie Ihren lokalen Server und einen Pfad auf dem Server als Gegenstelle für die Synchronisation ein.

Möchten Sie große Datenmengen transferieren, unterstützt Microsoft neben der Synchronisation über das Netzwerk alternativ auch die Verfahren DataBox und DataBox Heavy [7]. Die Daten finden dann ihren Weg in die Cloud, indem Microsoft Ihnen ein spezielles DataBox-Speichergerät schickt, auf das Sie offline die gewünschten Daten kopieren, und das Gerät dann mit der Post an Microsoft zurücksenden.

Mit per Default deaktiviertem Cloudtiering synchronisiert der Dienst sämtliche Daten zwischen dem lokalen Server und der Cloud. Aktivieren Sie das Cloudtiering, hält der Dienst nur heiße Daten lokal vor, während kalte Daten in der Cloud verbleiben. Liegen bereits vor der ersten Synchronisierung Daten sowohl lokal als auch in der Cloud vor, behält Azure File Sync im Falle von Konflikten beide Dateien bei. Alternativ können Sie nur den lokalen Server als führend definieren, der bei Dateikonflikten existierende Files in der Cloud überschreibt.

Fazit

Allen Trends in Richtung Cloud zum Trotz setzen viele Anwendungsfälle noch auf klassische SMB- und NFS-Freigaben im lokalen Netzwerk. Mit Azure Files stellt Microsoft solche Dateifreigaben aus der Cloud bereit, die ohne herkömmliche Dateiserver auskommen. Aus Sicht von Clients unter Windows, Linux und macOS erkennen Anwender dabei kaum einen Unterschied.

Ein durchgängiges Management von Identitäten und Berechtigungen erfordert allerdings auch die Integration eines lokalen AD mit der Azure-Cloud. Falls Anforderungen im Hinblick auf Bandbreite oder Latenz es verlangen, sorgt der zusätzliche Dienst Azure File Sync für einen kontinuierlichen Abgleich von lokalen Dateiservern und Dateifreigaben in Azure Files.

Azure Files und Azure File Sync nutzen

Dateien ohne Grenzen

Altlasten CIFS, SMB und NFS

Altlasten CIFS, SMB und NFS

Dateifreigaben ohne Server

Loslegen im Azure-Portal

Unterschiede in den Azure-Konten

Zugriff über öffentliche Netze

Schutz der Daten

Freigaben mit Backups und Snapshots

Verbinden mit Windows, Linux und macOS

Granulare Berechtigungen nur mit IAM

Synchronisationsdiensteinrichten

Konfiguration für Windows Server von 2012 R2 bis 2022

Fazit