Azure als SMB-Server

Adieu lokaler SMB-Server, willkommen Azure? Kann ein Dateiserver in die Cloud verlagert werden? Ihre Firma ist auf dem 100% Weg in die Cloud und Postfächer (Exchange), Collaboration (Teams) und Buchhaltung (DATEV, Microsoft CRM, SAP etc.) sind schon verlagert. Selbst das Client Management und Softwareverteilung sind per Intune/EMS/AzureAD-Join schon aus der Cloud möglich. Am Ende haben sie lokal eigentlich nur noch eine Firewall und ein paar Switches. Dann steht noch ein einsamer Dateiserver rum, für dessen Funktion aber auch noch ein Domain Controller (Active Directory, ADSync) betrieben werden muss. Wenn der auch noch weg könnte, dann wäre die komplette Verwaltung der Anwender in der Cloud möglich. Heile Welt?

Beachten Sie in dem Zuge auch die generelle Seite zu SMB im WAN und SMB Caching

Wer braucht noch SMB?

Da liegt der Wunsch nahe, auch den lokalen Dateiserver irgendwie zu migrieren. Wir wissen ja alle, dass ein Dateiserver eigentlich ein Saurier in unserer Umgebung ist. Dateiserver gibt es schon seit Jahrzehnten und erlaubte über unterschiedlichste Protokolle (SMB, AppleTalk, FTP, NFS, Novell etc.) die gemeinsame Nutzung von Dateien.

Die gemeinsame Nutzung war aber auch stark eingeschränkt.

  • Es gibt keine Versionierung von Dateien
    Das geht besser in SharePoint, GIT o.ä.
  • Gleichzeitiges Bearbeiten
    Anwender können nur gemeinsam an einem Dokument arbeiten, wenn die Client-Applikation dies unterstützt
  • Offline, Cache und Replikation
    Egal, ob sie nun DFS oder Branch-Cache auf dem Server oder "Windows Aktienkoffer", "Windows Offline Ordner" oder 3rd Party bemühen. Es sind alles limitierte Ansätze eine echte Synchronisierung oder Offline-Tauglichkeit zu erreichen.
  • Benachrichtigung
    Kein Windows Dateiserver protokolliert von Hause aus Änderungen an Dokumenten und sendet ggfls. Informationen an Kollegen o.ä. Ein Anwender kann auch nicht einstellen, dass er informiert werden soll.
  • Protokoll sind nicht "Internet Tauglich"
    Heute werden Informationen auch über Firmengrenzen hinweg bereit gestellt. Mit SMB und RPC ist das faktisch nicht möglich. Die Welt spricht HTTPS. DAs ist nicht nur für den Zugang über WLAN-AccessPoints (Hotel etc.) oder Firewalls/Proxy-Server ein Thema. Immer mehr Clients sind "mobil" (Smartphone/Tablet) und sprechen überhaupt kein SMB.

Es ist also nicht nur die pure Existenz eines großen Datenpools mit sehr eingeschränkter Funktionalität, die einen Umzug der Dokumente und Daten auf andere Plattformen beschleunigt. OneDrive und Sharepoint bieten einfach deutlich mehr Funktionen aber unterliegen auch Einschränkungen. Klassische Dateiserver können z.B. hier punkten.

  • Nicht "Mountbar"
    Aktuell kann ich ein OneDrive-Bereich in Office 365 nicht als "Laufwerksbuchstabe" verbinden. Ich kann per Office oder Browser direkt drauf zugreifen oder mit dem OneDrive Client ausgewählte Daten lokal synchronisieren aber ich habe kein Netzwerklaufwerk. Programme, die keinen nativen OneDrive-Support haben, müssen daher mit einer lokalen Kopie arbeiten.
  • Kein File-Locking/Record-Locking
    Es gibt immer noch Programme, die mit Dateisperren arbeiten. Microsoft Access ist und ein Beispiel und es gibt immer noch viele Lösungen ohne Client-Server-Technik. Hier brauchen wir ein "Netzwerklaufwerk", welches Datei- und Satzsperren unterstützt.
  • XXL-Datenmengen
    Neben den "kostbaren Daten" gibt es immer noch große statische Daten, z.B. Softwareinstallationsquellen, ISO-Dateien, statische Kataloge, Videos etc. auf die mehrere Clients zugreifen und damit ein sehr hohes Transfervolumen erzeugen. Das Netzwerk könnte hier die Nutzung erschweren oder gar verhindern.

Also stellt sich schon die Frage, ob und und welchem Umfang auch Dateiserver in Azure betrieben werden können.

Clients

Neben dem Backend, wo immer es auch steht, ist auch der Client und sein Standort ein wichtiger Teil der Betrachtung. Wenn Sie sehr viele Clients an einem LAN-Standort haben, die auch lokal zugreifen, dann spricht viel für einen lokalen Dateiserver. Wenn Sie natürlich viel mehr mobile Anwender unterstützen wollen, dann könnte ein Dateiserver in der Cloud eine bessere Option sein. Niemand wird natürlich SMB over Internet anbieten, so dass vielleicht ein VPN ratsam ist. Drei Clients möchte ich exemplarisch aufführen, die auf SMB-Services in einer Cloud zugreifen könnten.

  • Client im LAN per WAN-VPN
    Der klassische Anwender nutzt einen PC im Firmennetzwerk, welcher z.B. über eine VPN-Verbindung zu Azure auf einen SMB-Server oder Service in Azure zugreift.
  • Client und Server in Azure
    Bei einem zweiten Szenario steht der Client ebenfalls in Azure oder der Cloud. Es ist mittlerweile ja möglich auch Windows Desktop in Azure bereit zu stellen. Quasi Terminal-Server NG, so dass der Anwender
  • Clients im Internet/Homeoffice
    Die dritte Klasse sind Anwender mit Geräten, die unterwegs sind und bisher per VPN auf eine Dateiserver im Firmennetzwerk zugegriffen haben. Bei einem Service in der Cloud sind natürlich andere Wege gewünscht, um den Umweg über das Firmennetzwerk zu vermeiden.

Für alle Clients, die bei ihnen im Einsatz sind, müssen Sie natürlich Lösungen bereit stellen.

Backend

Der lokale Dateiserver im Haus ist ja heute schnell bereit gestellt. Das kann ja ein Windows Server, ein LINUX-Server oder ein irgendwie geartetes NAS sein. Selbst eine Fritz!Box mit einem USB-Stick oder USB-Festplatte ist ein kleines NAS und SMB-Server. Zugegeben, natürlich ohne umfangreichere Berechtigungen und oft werden Rechte nur auf der Ebene einer Freigabe vergeben. Aber auch das kann in kleinen Umgebungen reichen. Wenn Sie aber nun nichts mehr im LAN betreiben wollen oder ein Service in der Cloud einfach eine bessere Erreichbarkeit von überall in der Welt verspricht, dann stehen ihnen im Microsoft Umfeld nur zwei Optionen bereit:

Plattform Eigene VM mit Windows oder Linux/SAMBA Azure Files

Beschreibung

Sie können auf Basis von Azure einfach virtuelle Maschinen kaufen, einrichten und als Windows Dateiserver nach ihren Vorstellungen veröffentlichen.

Einfache "Dateifreigaben" in der Cloud

Patchen

Eigenverantwortlich bzw. Windows Update

Erfolgt durch Microsoft

Kosten

Die VM kostet natürlich je nach Ausstattung monatlich einen Betrag. Zudem dürfen Sie nicht

Belegter Speicherplatz (5ct/GB
+ Transferkosten nach Transaktionen
https://azure.microsoft.com/de-de/pricing/details/storage/files/

Berechtigungen

Auf Freigaben, Ordnern und Dateien wie bei einem normalen SMB-Server

Soweit ich gesehen habe, sind Berechtigungen nur auf der "Freigabe" aber nicht auf Verzeichnisse oder Dateien möglich. Änderungen können bis zu 30 Sekunden dauern

Authentifizierung

Der Server kann "Mitglied" eines bestehenden Active Directory sein und damit ihre Anmeldedaten nutzen

Im Mai 2019 war eine Anmeldung mit AzureAD-Daten noch nicht möglich. Stattdessen bedurfte es eigener Storage Konten und Keys

Absicherung

Sie können den Zugang zum Service über ein VPN absichern, so dass Sie nicht SMB/RPC über das Internet erreichbar machen wollen. Allerdings ist das natürlich eine Zwischenschicht mehr

Keine Firewall o.ä. "davor"

Backup

Eigenverantwortlich

Sicherung auf anderen Azure Storage möglich

VSS

Bestandteil des Betriebssystems

"Momentaufnahmen" möglich"

Share einrichten

Wenn Sie in Azure nach "Shared" oder SMB" suchen, finden Sie den Dienst erst mal nicht. Er ist als "Files" unter den Speicher Ressourcen zu finden und hier legen Sie einfach einen Share mit der maximalen Größen an.

Aktuell ist eine Verbindung per Active Directory Benutzer oder ADFS allerdings noch nicht möglich.

Über den Punkt Zugriffsrichtlinie können Sie steuern, welche Berechtigungen jemand für welchen Zeitraum hat:

Laufwerk verbinden

Dafür liefert AzureAD eine PowerShell-Zeile, mit der ein Laufwerk verbunden wird:

Erreichbarkeit des Service prüfen
Test-NetConnection `
   -ComputerName resgroup1.file.core.windows.net `
   -Port 445

Invoke-Expression `
   -Command "cmdkey /add:resgroup1.file.core.windows.net /user:Azure\resgroup1 /pass:xxxxxxxx=="

# Laufwerk einbinden
New-PSDrive `
   -Name Z `
   -PSProvider FileSystem `
   -Root "\\resgroup1.file.core.windows.net\share1"

Hinter dem FQDN des Dateiservers verbirgt sich in meinem Beispiel genau eine IP-Adresse:

Resolve-DnsName resgroup1.file.core.windows.net

Name                           Type   TTL   Section    NameHost
----                           ----   ---   -------    --------
resgroup1.file.core.win CNAME  59    Answer     file.am3prdstr10a.store.core.windows.net
dows.net

Name       : file.am3prdstr10a.store.core.windows.net
QueryType  : A
TTL        : 26
Section    : Answer
IP4Address : 191.239.203.12


Name                   : store.core.windows.net
QueryType              : SOA
TTL                    : 69
Section                : Authority
NameAdministrator      : azuredns-hostmaster.microsoft.com
SerialNumber           : 1
TimeToZoneRefresh      : 3600
TimeToZoneFailureRetry : 300
TimeToExpiration       : 2419200
DefaultTTL             : 300

Blick auf das Kabel

SMB und RPC über Kabel?  Da musste ich doch gleich mal Wireshark mit einen Filter auf die Zieladresse starten und die Verbindung, Anmeldung und Daten zugriff genauer untersuchen. Es ist aber schon sehr schnell sichtbar, dass die Übertragung erst mal keine offensichtliche Lücken offenbart. Allerdings habe ich natürlich einen aktuellen Client verwendet, der auch die neuesten Funktionen unterstützt. Ich habe leider nicht gefunden, wie "alt" und damit wie unsicher ein Client sein darf, der sich noch mit Azure Files verbinden kann.

Nach dem üblichen TCP SYN ACK RES handeln die beiden Endpunkte die SMB-Funktionen aus. Hier ist schon zu sehen, dass der Server ein "Signing Required" anfordert.

Auch die späteren Nutzdaten sind komplett verschlüsselt.

Performance

Im Azure Portal finde ich natürlich auch Informationen über die Leistung. Interessant habe ich hier die "E2E Latency" gefunden. Ich sammle ja auch die ein oder anderen Werte über meine Skripte auf Ende zu Ende Monitoring.

Allerdings sehe ich hier, dass die Auflösung wohl eher in Stunden erfolgt und auch Werte vorliegen, zu denen der Speicherpool noch gar nicht aktiv genutzt wird. Es scheint mir so, als ob Microsoft Azure hier selbst aktive Tests fährt um Zahlen zu erhalten und nicht die Latenzzeit der Client ermittelt.

Einschätzung

Aktuell ist Azure Files noch meilenweit davon entfernt einen lokalen Dateiserver ablösen zu können. Das scheitert schon an der Steuerung von Berechtigungen und endet nicht bei der Latenzzeit. Sie können damit sicher erste Tests und Gehversuche machen aber prüfen Sie genau den Einsatzzweck. Ich habe nun gar nicht erst geprüft, ob z.B. Dateisperren auf dem SMB-Share funktionieren, was z.B. für Anforderungen wie "Access-Datenbanken" notwendig wäre. Wer heute Dateiservices in der Cloud braucht, sollte sich genauer mit OneDrive und SharePoint beschäftigen.

Weitere Links