Überlegungen zum Netzwerkbetrieb mit der Azure-Dateisynchronisierung

Sie können auf zwei Arten eine Verbindung mit einer Azure-Dateifreigabe herstellen:

1. Sie greifen über die Protokolle SMB oder FileREST direkt auf die Freigabe zu. Dieses Zugriffsmuster kommt in erster Linie zum Einsatz, um so wenige lokale Server wie möglich einzubeziehen.
2. Sie erstellen mithilfe der Azure-Dateisynchronisierung einen Cache der Azure-Dateifreigabe auf einem lokalen Server (oder auf einer Azure-VM) und greifen auf dem lokalen Server über ein Protokoll Ihrer Wahl (SMB, NFS, FTPS, usw.) auf die Daten der Dateifreigabe zu. Dieses Zugriffsmuster ist praktisch, weil es die Vorteile der lokalen Leistung mit Mehrwertdiensten im Cloudmaßstab – z. B. Azure Backup – kombiniert.

Dieser Artikel konzentriert sich auf das zweite Szenario: Es wird beschrieben, wie Sie das Netzwerk konfigurieren, wenn Ihr Anwendungsfall eine Nutzung der Azure-Dateisynchronisierung zum lokalen Zwischenspeichern von Dateien statt des direkten Einbindens der Azure-Dateifreigabe über SMB erfordert. Weitere Informationen zu Überlegungen zum Netzwerkbetrieb für eine Azure Files-Bereitstellung finden Sie unter Azure Files – Überlegungen zum Netzwerkbetrieb.

Die Netzwerkkonfiguration für die Azure-Dateisynchronisierung umfasst zwei verschiedene Azure-Objekte: einen Speichersynchronisierungsdienst und ein Azure-Speicherkonto. Ein Speicherkonto ist ein Verwaltungskonstrukt, das einen gemeinsam genutzten Pool mit Speicherplatz darstellt, in dem Sie mehrere Dateifreigaben sowie weitere Speicherressourcen wie Blobs oder Warteschlangen bereitstellen können. Ein Speichersynchronisierungsdienst ist ein Verwaltungskonstrukt für registrierte Server. Hierbei handelt es sich um Windows-Dateiserver mit einer etablierten Vertrauensstellung mit der Azure-Dateisynchronisierung und mit Synchronisierungsgruppen, mit denen die Topologie der Synchronisierungsbeziehung definiert wird.

Herstellen einer Verbindung zwischen Windows-Dateiserver und Azure mit Azure-Dateisynchronisierung

Zum Einrichten und Verwenden von Azure Files und Azure-Dateisynchronisierung mit einem lokalen Windows-Dateiserver sind außer einer grundlegenden Internetverbindung keine speziellen Netzwerkfunktionen für Azure erforderlich. Zum Bereitstellen der Azure-Dateisynchronisierung installieren Sie den Azure-Dateisynchronisierung-Agent auf dem Windows-Dateiserver, den Sie mit Azure synchronisieren möchten. Der Azure-Dateisynchronisierung-Agent erreicht die Synchronisierung mit einer Azure-Dateifreigabe über zwei Kanäle:

• Dem FileREST-Protokoll, einem HTTPS-basiertes Protokoll, das für den Zugriff auf Ihre Azure-Dateifreigabe verwendet wird. Weil das FileREST-Protokoll den HTTPS-Standard für die Datenübertragung verwendet, muss ausgehend auf Port 443 zugegriffen werden. Die Azure-Dateisynchronisierung verwendet nicht das SMB-Protokoll für die Datenübertragung zwischen Ihren lokalen Windows-Servern und Ihrer Azure-Dateifreigabe.
• Dem Protokoll der Azure-Dateisynchronisierung, einem HTTPS-basierten Protokoll, das für den Austausch von Synchronisierungswissen, d. h. den Versionsinformationen zu den Dateien und Ordner zwischen Endpunkten in Ihrer Umgebung, verwendet wird. Dieses Protokoll wird auch zum Austauschen von Metadaten wie Zeitstempel und Zugriffssteuerungslisten (Access Control Lists, ACLs) über die Dateien und Ordner verwendet.

Weil Azure Files direkten SMB-Protokollzugriff auf Azure-Dateifreigaben bietet, fragen Kunden sich oft, ob sie spezielle Netzwerkfunktionen zum Einbinden dieser Freigaben mithilfe von SMB konfigurieren müssen, damit der Azure-Dateisynchronisierungs-Agent darauf zugreifen kann. Dies ist nicht erforderlich, und außer in Administratorszenarien wird davon abgeraten, weil direkt an der Azure-Dateifreigabe vorgenommene Änderungen nicht schnell erkannt werden können. Je nach Größe und Anzahl der Elemente in der Azure-Dateifreigabe werden Änderungen möglicherweise erst nach mehr als 24 Stunden erkannt. Wenn Sie anstelle der Azure-Dateisynchronisierung zum lokalen Zwischenspeichern die Azure-Dateifreigabe direkt verwenden möchten, lesen Sie Azure Files – Überlegungen zum Netzwerkbetrieb.

Obwohl die Azure-Dateisynchronisierung keine besondere Netzwerkkonfiguration erfordert, möchten einige Kunden möglicherweise erweiterte Netzwerkeinstellungen konfigurieren, um die folgenden Szenarien zu ermöglichen:

• Interoperabilität mit der Proxyserverkonfiguration Ihrer Organisation.
• Öffnen Sie die lokale Firewall Ihrer Organisation für die Dienste Azure Files und Azure-Dateisynchronisierung.
• Tunneln des Datenverkehrs von Azure Files und der Azure-Dateisynchronisierung über ExpressRoute oder eine VPN-Verbindung (Virtual Private Network, virtuelles privates Netzwerk).

Konfigurieren von Proxyservern

Viele Organisationen verwenden einen Proxyserver als Vermittler zwischen Ressourcen innerhalb Ihres lokalen Netzwerks und Ressourcen außerhalb Ihres Netzwerks, z. B. in Azure. Proxyserver sind für viele Anwendungsbereiche wie Netzwerkisolation und Sicherheit sowie Überwachung und Protokollierung nützlich. Die Azure-Dateisynchronisierung kann mit einem Proxyserver vollständig zusammenarbeiten. Sie müssen jedoch die Proxyendpunkt-Einstellungen für Ihre Umgebung mit der Azure-Dateisynchronisierung manuell konfigurieren. Dies muss über PowerShell mithilfe des Server-Cmdlets Set-StorageSyncProxyConfiguration der Azure-Dateisynchronisierung erfolgen.

Weitere Informationen zum Konfigurieren der Azure-Dateisynchronisierung mit einem Proxyserver finden Sie unter Proxy- und Firewalleinstellungen der Azure-Dateisynchronisierung.

Konfigurieren von Firewalls und Diensttags

Viele Organisationen isolieren ihre Dateiserver von den meisten Internetspeicherorten aus Sicherheitsgründen. Um die Azure-Dateisynchronisierung in einer solchen Umgebung verwenden zu können, müssen Sie Ihre Firewall so konfigurieren, dass sie ausgehenden Zugriff auf ausgewählte Azure-Dienste zulässt. Lassen Sie dazu für Port 443 ausgehenden Zugriff auf erforderliche Cloudendpunkte zu, die diese spezifischen Azure-Dienste hosten, wenn Ihre Firewall URLs/Domänen unterstützt. Ist dies nicht der Fall, können Sie die IP-Adressbereiche für diese Azure-Dienste über Diensttags abrufen.

Die Azure-Dateisynchronisierung benötigt die IP-Adressbereiche für die folgenden Dienste, wie durch die Diensttags angegeben:

Wenn Sie die Azure-Dateisynchronisierung in Azure nutzen (selbst wenn dies in einer anderen Region geschieht), können Sie den Namen des Diensttags direkt in Ihrer Netzwerksicherheitsgruppe verwenden, um Datenverkehr zu diesem Dienst zuzulassen. Weitere Informationen finden Sie unter Netzwerksicherheitsgruppen.

Wenn Sie die Azure-Dateisynchronisierung lokal verwenden, können Sie mithilfe der Diensttag-API bestimmte IP-Adressbereiche für die Positivliste Ihrer Firewall abrufen. Es gibt zwei Methoden zum Abrufen dieser Informationen:

• Die aktuelle Liste der IP-Adressbereiche für alle Azure-Dienste, die Diensttags unterstützen, wird wöchentlich im Microsoft Download Center in Form eines JSON-Dokuments veröffentlicht. Es gibt für jede Azure-Cloud ein eigenes JSON-Dokument mit den IP-Adressbereichen, die für diese Cloud relevant sind:
  • Azure öffentlich
  • Azure US Government
  • Microsoft Azure, betrieben von 21Vianet
  • Azure Deutschland
• Die Diensttagermittlungs-API (Vorschauversion) ermöglicht das programmgesteuerte Abrufen der aktuellen Liste von Diensttags. In der Vorschauversion gibt die Diensttagermittlungs-API eventuell weniger aktuelle Informationen zurück, als in den im Microsoft Download Center veröffentlichten JSON-Dokumenten enthalten sind. Sie können je nach Ihren Automatisierungsvorlieben auch die API-Benutzeroberfläche verwenden:
  • REST-API
  • Azure PowerShell
  • Azure-Befehlszeilenschnittstelle

Weitere Informationen zur Verwendung der Diensttag-API zum Abrufen der Adressen Ihrer Dienste finden Sie unter Positivliste für Azure-Dateisynchronisierungs-IP-Adressen.

Tunneln von Datenverkehr über ein virtuelles privates Netzwerk oder über ExpressRoute

Einige Organisationen fordern, dass die Kommunikation mit Azure über einen Netzwerktunnel erfolgt, z. B. ein VPN oder ExpressRoute, um eine zusätzliche Sicherheitsebene zu gewährleisten oder sicherzustellen, dass die Kommunikation mit Azure einer deterministischen Route folgt.

Wenn Sie einen Netzwerktunnel zwischen Ihrem lokalen Netzwerk und Azure einrichten, entsteht eine Peeringbeziehung zwischen Ihrem lokalen Netzwerk und mindestens einem virtuellen Netzwerk in Azure. Ein virtuelles Netzwerk (VNet) ähnelt einem herkömmlichen Netzwerk in Ihrer lokalen Umgebung. Ähnlich wie ein Azure-Speicherkonto oder eine Azure-VM ist ein VNet eine Azure-Ressource, die in einer Ressourcengruppe bereitgestellt wird.

Azure Files und die Azure-Dateisynchronisierung unterstützen die folgenden Mechanismen zum Tunneln von Datenverkehr zwischen Ihren lokalen Servern und Azure:

• Azure VPN Gateway: Ein VPN-Gateway ist eine spezielle Art von Gateway für virtuelle Netzwerke, das verwendet wird, um verschlüsselten Datenverkehr zwischen einem virtuellen Azure-Netzwerk und einem anderen Standort (beispielsweise einer lokalen Umgebung) über das Internet zu senden. Azure VPN Gateway ist eine Azure-Ressource, die neben einem Speicherkonto oder anderen Azure-Ressourcen in einer Ressourcengruppe bereitgestellt werden kann. Da die Azure-Dateisynchronisierung mit einem lokalen Windows-Dateiserver verwendet werden soll, verwenden Sie normalerweise ein Site-to-Site-VPN (S2S), obwohl es technisch möglich ist, ein Point-to-Site-VPN (P2S) zu verwenden.

  Site-to-Site-VPN-Verbindungen (S2S) verbinden Ihr virtuelles Azure-Netzwerk und das lokale Netzwerk Ihrer Organisation. Mit dieser Lösung können Sie einmalig eine VPN-Verbindung für einen VPN-Server oder ein im Netzwerk Ihrer Organisation gehostetes Gerät konfigurieren und müssen diese Einrichtung nicht für jedes Clientgerät wiederholen, das auf Ihre Azure-Dateifreigabe zugreifen muss. Informationen zur Vereinfachung der Bereitstellung einer S2S-VPN-Verbindung finden Sie unter Konfigurieren eines Site-to-Site-VPN zur Verwendung mit Azure Files.

• ExpressRoute ermöglicht Ihnen die Erstellung einer definierten Route (private Verbindung) zwischen Azure und Ihrem lokalen Netzwerk, die nicht über das Internet läuft. Da ExpressRoute einen dedizierten Pfad zwischen Ihrem lokalen Rechenzentrum und Azure bereitstellt, kann dieser Dienst sehr nützlich sein, wenn die Netzwerkleistung ein wichtiger Aspekt ist. ExpressRoute ist auch dann eine gute Option, wenn die Richtlinie Ihrer Organisation oder gesetzliche Vorschriften einen deterministischen Pfad zu den Ressourcen in der Cloud erfordern.

Private Endpunkte

Zusätzlich zu den standardmäßigen öffentlichen Endpunkten, die Azure Files und die Azure-Dateisynchronisierung über das Speicherkonto und den Speichersynchronisierungsdienst bereitstellen, bieten sie die Möglichkeit, pro Ressource über einen oder mehrere private Endpunkte zu verfügen. Auf diese Weise können Sie eine private und sichere Verbindung mit Azure-Dateifreigaben über VPN oder ExpressRoute und aus einem Azure-VNet lokal herstellen. Wenn Sie einen privaten Endpunkt für eine Azure-Ressource erstellen, erhält sie eine private IP-Adresse aus dem Adressraum Ihres virtuellen Netzwerks. Dies ist vergleichbar mit einem lokalen Windows-Dateiserver, der eine IP-Adresse aus dem dedizierten Adressraum Ihres lokalen Netzwerks erhält.

Ein privater Endpunkt ist einem bestimmten Subnetz des virtuellen Azure-Netzwerks zugeordnet. Speicherkonten und Speichersynchronisierungsdienste können über private Endpunkte in mehreren virtuellen Netzwerken verfügen.

Die Verwendung privater Endpunkte ermöglicht Folgendes:

• Herstellen einer sicheren Verbindung mit Ihren Azure-Ressourcen aus lokalen Netzwerken über eine VPN- oder ExpressRoute-Verbindung mit privatem Peering.
• Sichern Ihrer Azure-Ressourcen durch Deaktivieren der öffentlichen Endpunkte für Azure Files und Dateisynchronisierung. Durch die Erstellung eines privaten Endpunkts werden Verbindungen mit dem öffentlichen Endpunkt nicht standardmäßig blockiert.
• Erhöhen der Sicherheit für das virtuelle Netzwerk durch die Möglichkeit zum Blockieren der Exfiltration von Daten aus dem virtuellen Netzwerk (und Peeringgrenzen)

Informationen zum Erstellen eines privaten Endpunkts finden Sie unter Konfigurieren von Netzwerkendpunkten für die Azure-Dateisynchronisierung.

Private Endpunkte und DNS

Wenn Sie einen privaten Endpunkt erstellen, erstellen wir standardmäßig auch eine private DNS-Zone, die der Unterdomäne privatelink entspricht, oder wir aktualisieren eine vorhandene private DNS-Zone entsprechend. Für öffentliche Cloudregionen sind diese DNS-Zonen privatelink.file.core.windows.net für Azure Files und privatelink.afs.azure.net für die Azure-Dateisynchronisierung.

Wenn Sie private Endpunkte für ein Speicherkonto und einen Speichersynchronisierungsdienst erstellen, erstellen wir für diese A-Datensätze in ihren jeweiligen privaten DNS-Zonen. Außerdem aktualisieren wir den öffentlichen DNS-Eintrag so, dass die regulären voll qualifizierten Domänennamen CNAMEs für den relevanten privatelink-Namen sind. So können die vollqualifizierten Domänennamen auf die IP-Adress(en) des privaten Endpunkts verweisen, wenn sich der Anforderer innerhalb des virtuellen Netzwerks befindet, und auf die IP-Adress(en) des öffentlichen Endpunkts, wenn der Anforderer sich außerhalb des virtuellen Netzwerks befindet.

Bei Azure Files verfügt jeder private Endpunkt über einen einzelnen, dem Muster storageaccount.privatelink.file.core.windows.net folgenden vollqualifizierten Domänennamen, der einer privaten IP-Adresse für den privaten Endpunkt zugeordnet ist. Für die Azure-Dateisynchronisierung hat jeder private Endpunkt vier vollständig qualifizierte Domänennamen für die vier verschiedenen Endpunkte, die die Azure-Dateisynchronisierung verfügbar macht: Verwaltung, Synchronisierung (primär), Synchronisierung (sekundär) und Überwachung. Die vollqualifizierten Domänennamen für diese Endpunkte folgen normalerweise dem Namen des Speichersynchronisierungsdiensts, außer wenn der Name Nicht-ASCII-Zeichen enthält. Wenn der Name Ihres Speichersynchronisierungsdiensts beispielsweise mysyncservice in der Region „USA, Westen 2“ ist, wären die entsprechenden Endpunkte mysyncservicemanagement.westus2.afs.azure.net, mysyncservicesyncp.westus2.afs.azure.net, mysyncservicesyncs.westus2.afs.azure.net und mysyncservicemonitoring.westus2.afs.azure.net. Jeder private Endpunkt für einen Speichersynchronisierungsdienst enthält vier verschiedene IP-Adressen.

Da Ihre private Azure-DNS-Zone mit dem virtuellen Netzwerk verbunden ist, das den privaten Endpunkt enthält, können Sie sich die DNS-Konfiguration ansehen, indem Sie das Cmdlet Resolve-DnsName über PowerShell auf einer Azure-VM aufrufen (oder nslookup unter Windows und Linux):

Resolve-DnsName -Name "storageaccount.file.core.windows.net"

In diesem Beispiel wird das Speicherkonto storageaccount.file.core.windows.net in die private IP-Adresse des privaten Endpunkts (192.168.0.4) aufgelöst.

Name                              Type   TTL   Section    NameHost
----                              ----   ---   -------    --------
storageaccount.file.core.windows. CNAME  29    Answer     csostoracct.privatelink.file.core.windows.net
net

Name       : storageaccount.privatelink.file.core.windows.net
QueryType  : A
TTL        : 1769
Section    : Answer
IP4Address : 192.168.0.4


Name                   : privatelink.file.core.windows.net
QueryType              : SOA
TTL                    : 269
Section                : Authority
NameAdministrator      : azureprivatedns-host.microsoft.com
SerialNumber           : 1
TimeToZoneRefresh      : 3600
TimeToZoneFailureRetry : 300
TimeToExpiration       : 2419200
DefaultTTL             : 300

Wenn Sie den gleichen Befehl lokal ausführen, sehen Sie, dass der gleiche Speicherkontoname stattdessen in die öffentliche IP-Adresse des Speicherkontos aufgelöst wird. storageaccount.file.core.windows.net ist ein CNAME-Eintrag für storageaccount.privatelink.file.core.windows.net, was wiederum ein CNAME-Eintrag für den Azure-Speichercluster ist, von dem das Speicherkonto gehostet wird:

Name                              Type   TTL   Section    NameHost
----                              ----   ---   -------    --------
storageaccount.file.core.windows. CNAME  60    Answer     storageaccount.privatelink.file.core.windows.net
net
storageaccount.privatelink.file.c CNAME  60    Answer     file.par20prdstr01a.store.core.windows.net
ore.windows.net

Name       : file.par20prdstr01a.store.core.windows.net
QueryType  : A
TTL        : 60
Section    : Answer
IP4Address : 52.239.194.40

Dies spiegelt die Tatsache wider, dass Azure Files und Azure-Dateisynchronisierung sowohl ihre öffentlichen Endpunkte als auch einen oder mehrere private Endpunkte pro Ressource verfügbar machen können. Um sicherzustellen, dass die vollqualifizierten Domänennamen für Ihre Ressourcen in die privaten IP-Adressen der privaten Endpunkte aufgelöst werden, müssen Sie die Konfiguration auf Ihren lokalen DNS-Servern ändern. Hierzu gibt es verschiedene Möglichkeiten:

• Ändern Sie die Hostdatei auf Ihren Clients, um die vollqualifizierten Domänennamen für Ihre Speicherkonten und Speichersynchronisierungsdienste in die gewünschten privaten IP-Adressen aufzulösen. Bei Produktionsumgebungen wird davon dringend abgeraten, da Sie diese Änderungen für jeden Client vornehmen müssen, der auf Ihre privaten Endpunkte zugreifen muss. Änderungen an Ihren privaten Endpunkten/Ressourcen (Löschungen, Modifizierungen usw.) werden nicht automatisch behandelt.
• Erstellen von DNS-Zonen auf Ihren lokalen Servern für privatelink.file.core.windows.net und privatelink.afs.azure.net mit A-Datensätzen für Ihre Azure-Ressourcen. Dies hat den Vorteil, dass Clients in Ihrer lokalen Umgebung Azure-Ressourcen automatisch auflösen können und Sie nicht jeden einzelnen Client konfigurieren müssen. Diese Lösung ist jedoch ähnlich fehleranfällig wie das Ändern der Hosts-Datei, weil Änderungen nicht angezeigt werden. Für einige Umgebungen ist diese Lösung trotz ihrer Fehleranfälligkeit möglicherweise die beste Wahl.
• Weiterleiten der Zonen core.windows.net und afs.azure.net von Ihren lokalen DNS-Servern an Ihre private Azure-DNS-Zone. Der private Azure-DNS-Host ist über eine spezielle IP-Adresse (168.63.129.16) erreichbar, auf die nur innerhalb von virtuellen Netzwerken zugegriffen werden kann, die mit der privaten Azure-DNS-Zone verknüpft sind. Zur Umgehung dieser Einschränkung können Sie zusätzliche DNS-Server in Ihrem virtuellen Netzwerk ausführen, die core.windows.net und afs.azure.net an die entsprechenden privaten Azure-DNS-Zonen weiterleiten. Zur Vereinfachung dieser Konfiguration stehen PowerShell-Cmdlets zur Verfügung, die automatisch DNS-Server in Ihrem virtuellen Azure-Netzwerk bereitstellen und wie gewünscht konfigurieren. Informationen zum Einrichten der DNS-Weiterleitung finden Sie unter Konfigurieren von DNS mit Azure Files.

Verschlüsselung während der Übertragung

Verbindungen, die zwischen dem Azure-Dateisynchronisierung-Agent und Ihrer Azure-Dateifreigabe oder einem Speichersynchronisierungsdienst hergestellt werden, sind immer verschlüsselt. Obwohl Azure-Speicherkonten über eine Einstellung zum Deaktivieren der Voraussetzung der Verschlüsselung während der Übertragung für die Kommunikation mit Azure Files (und den anderen Azure-Speicherdiensten, die über das Speicherkonto verwaltet werden) verfügen, wirkt sich das Deaktivieren dieser Einstellung nicht auf die Verschlüsselung der Azure-Dateisynchronisierung bei der Kommunikation mit Azure Files aus. Standardmäßig ist in allen Azure-Speicherkonten die Verschlüsselung während der Übertragung aktiviert.

Weitere Informationen zur Verschlüsselung während der Übertragung finden Sie unter Vorschreiben einer sicheren Übertragung in Azure Storage.

Weitere Informationen

• Planung für die Bereitstellung einer Azure-Dateisynchronisierung
• Bereitstellen der Azure-Dateisynchronisierung