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 |
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:
- Erstellen einer Dateifreigabe in Azure
Files
https://docs.microsoft.com/de-de/azure/storage/files/storage-how-to-create-file-share - Verwalten von Speicherkontoeinstellungen
im Azure-Portal
https://docs.microsoft.com/de-de/azure/storage/common/storage-account-manage#access-keys
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
- SMB im WAN
- SMB Caching
- Netzwerk Grundlagen
- TCP Window Scaling, Latenz und Durchsatz, RWIN
- TCP Retransmit Monitoring
- Packet Loss
- TCP Session Timeout
- TCPChimney und Receive Side Scaling (RSS) und Network Direct Memory Access
-
Windows Virtual Desktop VORSCHAU Die beste virtuelle Desktopumgebung – in Azure
https://azure.microsoft.com/de-de/services/virtual-desktop/ - Azure Files
https://azure.microsoft.com/de-de/services/storage/files/ - Azure Active Directory-Authentifizierung
für SMB-Zugriff auf Azure Files ab sofort in
der Public Preview verfügbar
https://azure.microsoft.com/de-de/blog/azure-active-directory-integration-for-smb-access-now-in-public-preview/ - What is Azure Files?
https://docs.microsoft.com/de-de/azure/storage/files/storage-files-introduction - Azure Files scalability and performance
targets
https://docs.microsoft.com/de-de/azure/storage/files/storage-files-scale-targets - Troubleshoot Azure Files problems in
Windows
https://docs.microsoft.com/de-de/azure/storage/files/storage-troubleshoot-windows-file-connection-problems - Use an Azure file share with Windows
https://docs.microsoft.com/en-us/azure/storage/files/storage-how-to-use-files-windows - Frequently asked questions (FAQ) about
Azure Files
https://docs.microsoft.com/de-de/azure/storage/files/storage-files-faq - Troubleshoot Azure Files performance
issues
https://docs.microsoft.com/de-de/azure/storage/files/storage-troubleshooting-files-performance - Azure: Summary of ISPs that Allow /
Disallow Access from Port 445
https://social.technet.microsoft.com/wiki/contents/articles/32346.azure-summary-of-isps-that-allow-disallow-access-from-port-445.aspx - Don’t Use Azure AD Domain Services to
Replace Windows Domain Controllers
https://www.ciraltos.com/dont-use-azure-ad-domain-services-to-replace-windows-domain-controllers/