Planung für die Bereitstellung einer Azure-Dateisynchronisierung

Azure-Dateisynchronisierung ist ein Dienst, mit dem Sie mehrere Azure-Dateifreigaben auf einem lokalen Computer unter Windows Server oder einer Cloud-VM zwischenspeichern können.

In diesem Artikel werden die Konzepte und Features von Azure-Dateisynchronisierung vorgestellt. Sobald Sie mit Azure-Dateisynchronisierung vertraut sind, finden Sie im Bereitstellungsleitfaden für Azure-Dateisynchronisierung eine Anleitung, wie Sie diesen Dienst ausprobieren können.

Die Dateien werden in der Cloud in Azure-Dateifreigaben gespeichert. Azure-Dateifreigaben können auf zwei Weisen genutzt werden: durch direktes Einbinden dieser serverlosen Azure-Dateifreigaben (SMB) oder durch lokales Zwischenspeichern von Azure-Dateifreigaben mithilfe von Azure-Dateisynchronisierung. Welche Bereitstellungsoption Sie wählen, ändert die Aspekte, die Sie beim Planen der Bereitstellung berücksichtigen müssen.

• Direktes Einbinden einer Azure-Dateifreigabe: Weil Azure Files SMB-Zugriff bietet, können Sie Azure-Dateifreigaben lokal oder in der Cloud mithilfe des standardmäßigen SMB-Clients einbinden, der unter Windows, macOS und Linux verfügbar ist. Da Azure-Dateifreigaben serverlos sind, ist für die Bereitstellung in Produktionsszenarien keine Verwaltung eines Dateiservers oder NAS-Geräts erforderlich. Dies bedeutet, dass Sie keine Softwarepatches anwenden oder physische Datenträger austauschen müssen.

• Lokales Zwischenspeichern von Azure-Dateifreigaben mit Azure-Dateisynchronisierung: Die Azure-Dateisynchronisierung ermöglicht das Zentralisieren der Dateifreigaben Ihrer Organisation in Azure Files, ohne auf die Flexibilität, Leistung und Kompatibilität eines lokalen Dateiservers verzichten zu müssen. Die Azure-Dateisynchronisierung transformiert Ihre lokalen Windows Server-Computer in einen schnellen Cache für Ihre Azure-Dateifreigabe.

Verwaltungskonzepte

Eine Azure-Dateisynchronisierungsbereitstellung umfasst drei grundlegende Verwaltungsobjekte:

• Azure-Dateifreigabe: Eine Azure-Dateifreigabe ist eine serverlose Clouddateifreigabe, die den Cloudendpunkt einer Azure-Dateisynchronisierungs-Synchronisierungsbeziehung bereitstellt. Auf Dateien in einer Azure-Dateifreigabe kann direkt mit SMB oder dem FileREST-Protokoll zugegriffen werden. Wir empfehlen Ihnen jedoch, auf die Dateien hauptsächlich über den Windows Server-Cache zuzugreifen, wenn die Azure-Dateifreigabe mit Azure-Dateisynchronisierung verwendet wird. Das liegt daran, dass Azure Files derzeit über keinen effizienten Mechanismus zur Erkennung von Änderungen verfügt, wie es bei Windows Server der Fall ist, sodass direkte Änderungen an der Azure-Dateifreigabe Zeit benötigen, um erneut an die Serverendpunkte weitergegeben zu werden.
• Serverendpunkt: Der Pfad auf dem Windows-Server, der mit einer Azure-Dateifreigabe synchronisiert wird. Dies kann ein bestimmter Ordner auf einem Volume oder das Stammverzeichnis des Volumes sein. Mehrere Serverendpunkte können auf demselben Volume vorhanden sein, wenn sich ihre Namespaces nicht überschneiden.
• Synchronisierungsgruppe: Das-Objekt, das die Synchronisierungsbeziehung zwischen einem Cloudendpunkt oder einer Azure-Dateifreigabe und einem Serverendpunkt definiert. Endpunkte innerhalb einer Synchronisierungsgruppe bleiben miteinander synchron. Wenn Sie beispielsweise über zwei unterschiedliche Sätze von Dateien verfügen, die Sie mit der Azure-Dateisynchronisierung verwalten möchten, würden Sie zwei Synchronisierungsgruppen erstellen und beiden unterschiedliche Endpunkte hinzufügen.

Konzepte der Azure-Dateifreigabeverwaltung

Azure-Dateifreigaben werden in Speicherkonten bereitgestellt, bei denen es sich um Objekte der obersten Ebene handelt, die einen freigegebenen Speicherpool darstellen. Dieser Speicherpool kann verwendet werden, um mehrere Dateifreigaben sowie andere Speicherressourcen wie Blobcontainer, Warteschlangen oder Tabellen bereitzustellen. Für alle Speicherressourcen, die in einem Speicherkonto bereitgestellt werden, treffen die für dieses Speicherkonto geltenden Grenzwerte zu. Die aktuellen Grenzwerte für ein Speicherkonto finden Sie unter Skalierbarkeits- und Leistungsziele für Azure Files.

Es gibt zwei Haupttypen von Speicherkonten, die Sie für Azure Files-Bereitstellungen verwenden:

• Speicherkonten vom Typ Universell Version 2 (GPv2) : GPv2-Speicherkonten ermöglichen Ihnen die Bereitstellung von Azure-Dateifreigaben auf Standard- bzw. festplattenbasierter Hardware (HDD-basiert). Neben Azure-Dateifreigaben können in GPv2-Speicherkonten auch andere Speicherressourcen wie Blobcontainer, Warteschlangen oder Tabellen gespeichert werden.
• FileStorage-Speicherkonten: FileStorage-Speicherkonten ermöglichen Ihnen die Bereitstellung von Azure-Dateifreigaben auf SSD-basierter Hardware (Premium/Solid State Drive). FileStorage-Konten können nur zum Speichern von Azure-Dateifreigaben verwendet werden. In einem FileStorage-Konto können keine anderen Speicherressourcen (Blobcontainer, Warteschlangen, Tabellen usw.) bereitgestellt werden. Nur FileStorage-Konten können sowohl SMB- als auch NFS-Dateifreigaben bereitstellen.

Es gibt mehrere andere Speicherkontotypen, die Sie möglicherweise im Azure-Portal, in PowerShell oder in der CLI finden. Zwei Speicherkontotypen (BlockBlobStorage- und BlobStorage-Speicherkonten) dürfen keine Azure-Dateifreigaben enthalten. Die anderen beiden Speicherkontotypen, die Sie möglicherweise sehen, sind Universell Version 1 (GPv1) und klassische Speicherkonten. Beide können Azure-Dateifreigaben enthalten. Obwohl GPv1 und klassische Speicherkonten Azure-Dateifreigaben enthalten können, sind die meisten neuen Features von Azure Files nur in GPv2- und FileStorage-Speicherkonten verfügbar. Daher empfiehlt es sich, für neue Bereitstellungen nur GPv2- und FileStorage-Speicherkonten zu verwenden und GPv1- und klassische Speicherkonten zu aktualisieren, wenn diese bereits in Ihrer Umgebung vorhanden sind.

Konzepte der Azure-Dateisynchronisierungsverwaltung

Synchronisierungsgruppen werden in Speichersynchronisierungsdiensten bereitgestellt. Dabei handelt es sich um Objekte der obersten Ebene, die Server für die Verwendung mit Azure-Dateisynchronisierung registrieren und die Synchronisierungsgruppenbeziehungen enthalten. Die Speichersynchronisierungsdienst-Ressource ist der Speicherkontoressource gleichgeordnet und kann in ähnlicher Weise in Azure-Ressourcengruppen bereitgestellt werden. Ein Speichersynchronisierungsdienst kann Synchronisierungsgruppen erstellen, die Azure-Dateifreigaben für mehrere Speicherkonten und mehrere registrierte Windows-Server enthalten.

Bevor Sie eine Synchronisierungsgruppe in einem Speichersynchronisierungsdienst erstellen können, müssen Sie zunächst einen Windows-Server beim Speichersynchronisierungsdienst registrieren. Dadurch wird ein registriertes Serverobjekt erstellt, das eine Vertrauensstellung zwischen Ihrem Server oder Cluster und dem Speichersynchronisierungsdienst darstellt. Um einen Speichersynchronisierungsdienst zu registrieren, müssen Sie zunächst den Azure-Dateisynchronisierungs-Agent auf dem Server installieren. Ein einzelner Server oder Cluster kann zu einem beliebigen Zeitpunkt jeweils nur bei einem Speichersynchronisierungsdienst registriert sein.

Eine Synchronisierungsgruppe enthält einen Cloudendpunkt oder eine Azure-Dateifreigabe und mindestens einen Serverendpunkt. Das Serverendpunktobjekt enthält die Einstellungen, die die Cloudtieringfunktion konfigurieren, die die Zwischenspeicherungsfunktion der Azure-Dateisynchronisierung bereitstellt. Um eine Synchronisierung mit einer Azure-Dateifreigabe durchführen zu können, muss sich das Speicherkonto, das die Azure-Dateifreigabe enthält, in der gleichen Azure-Region befinden wie der Speichersynchronisierungsdienst.

Berücksichtigen der Anzahl von benötigten Speichersynchronisierungsdiensten

In einem vorherigen Abschnitt wird die Kernressource erläutert, die für die Azure-Dateisynchronisierung konfiguriert werden soll: ein Speichersynchronisierungsdienst. Ein Windows Server kann nur für einen Speichersynchronisierungsdienst registriert sein. Daher ist es oft am besten, nur einen einzigen Speichersynchronisierungsdienst bereitzustellen und alle Server bei ihm zu registrieren.

Erstellen Sie mehrere Speichersynchronisierungsdienste nur, wenn Folgendes zutrifft:

• Sie haben unterschiedliche Gruppen von Servern, die Daten niemals untereinander austauschen dürfen. In diesem Fall sollten Sie das System so entwerfen, dass bestimmte Gruppen von Servern für die Synchronisierung mit einer Azure-Dateifreigabe ausgeschlossen werden, die bereits als Cloudendpunkt in einer Synchronisierungsgruppe in einem anderen Speichersynchronisierungsdienst verwendet wird. Eine andere Möglichkeit, dies zu untersuchen, ist, dass Windows-Server, die für einen anderen Speichersynchronisierungsdienst registriert wurden, nicht mit derselben Azure-Dateifreigabe synchronisiert werden können.
• Sie benötigen mehr registrierte Server oder Synchronisierungsgruppen, als ein einzelner Speichersynchronisierungsdienst unterstützen kann. Weitere Informationen finden Sie in Skalierbarkeitsziele für die Azure-Dateisynchronisierung.

Planen von ausgeglichenen Synchronisierungstopologien

Vor dem Bereitstellen von Ressourcen ist es wichtig, genau zu planen, was Sie auf einem lokalen Server synchronisieren werden, auf dem die Azure-Dateifreigabe verwendet wird. Durch die Planung können Sie einfacher ermitteln, wie viele Speicherkonten, Azure-Dateifreigaben und Synchronisierungsressourcen Sie benötigen werden. Diese Überlegungen sind selbst dann noch relevant, wenn Ihre Daten zurzeit nicht auf einem Windows-Server oder dem Server gespeichert sind, den Sie langfristig verwenden möchten. Anhand des Abschnitts „Migration“ können Sie geeignete Migrationspfade für Ihre Situation ermitteln.

In diesem Schritt ermitteln Sie, wie viele Azure-Dateifreigaben Sie benötigen. Eine einzelne Windows Server-Instanz (oder ein Cluster) kann bis zu 30 Azure-Dateifreigaben synchronisieren.

Möglicherweise verfügen Sie über weitere Ordner auf Ihren Volumes, die Sie derzeit lokal als SMB-Freigaben für Ihre Benutzer und Apps freigeben. Am einfachsten können Sie sich dieses Szenario vorstellen, wenn Sie sich eine lokale Freigabe vorstellen, die sich 1:1 zu einer Azure-Dateifreigabe zuordnen lässt. Bei einer ausreichend geringen Anzahl von Freigaben (weniger als 30 für eine einzelne Windows Server-Instanz) wird eine 1:1-Zuordnung empfohlen.

Wenn Sie über mehr als 30 Freigaben verfügen, ist es häufig nicht nötig, eine lokale Freigabe 1:1 einer Azure-Dateifreigabe zuzuordnen. Ziehen Sie folgende Möglichkeiten in Betracht.

Gruppierung von Freigaben

Wenn Ihre Personalabteilung z. B. über 15 Freigaben verfügt, können Sie in Erwägung ziehen, alle Personaldaten in einer einzelnen Azure-Dateifreigabe zu speichern. Wenn Sie mehrere lokale Freigaben in einer Azure-Dateifreigabe speichern, können Sie trotzdem die üblichen 15 SMB-Freigaben auf Ihrer lokalen Windows Server-Instanz erstellen. Die Gruppierung der Freigaben bedeutet lediglich, dass Sie die Stammordner dieser 15 Freigaben als Unterordner in einem gemeinsamen Ordner organisieren. Anschließend synchronisieren Sie diesen gemeinsamen Ordner mit einer Azure-Dateifreigabe. Dadurch wird für diese Gruppe lokaler Freigaben nur eine einzige Azure-Dateifreigabe in der Cloud benötigt.

Volumesynchronisierung

Die Azure-Dateisynchronisierung unterstützt das Synchronisieren eines Volumestamms mit einer Azure-Dateifreigabe. Wenn Sie den Volumestamm synchronisieren, werden alle Unterordner und Dateien in derselben Azure-Dateifreigabe abgelegt.

Das Synchronisieren des Volumestamms ist daher nicht immer empfehlenswert. Das Synchronisieren mehrerer Speicherorte hat auch Vorteile. Auf diese Weise lässt sich beispielsweise die Anzahl von Elementen pro Synchronisierungsvorgang reduzieren. Die Tests von Azure-Dateifreigaben und der Azure-Dateisynchronisierung erfolgen mit 100 Millionen Elementen (Dateien und Ordner) pro Freigabe. Es empfiehlt sich jedoch häufig, in einer einzelnen Freigabe maximal 20 bis 30 Millionen Elemente zu verwenden. Das Einrichten der Azure-Dateisynchronisierung mit einer geringeren Anzahl von Elementen ist nicht nur für die Dateisynchronisierung von Vorteil. Von einer geringeren Anzahl von Elementen profitieren Sie auch in Szenarien wie den folgenden:

• Die anfängliche Überprüfung des Cloudinhalts kann schneller durchgeführt werden, was wiederum die Wartezeit für die Anzeige des Namespace auf einem Server mit aktivierter Azure-Dateisynchronisierung verringert.
• Die cloudseitige Wiederherstellung aus einer Azure-Dateifreigabe-Momentaufnahme kann schneller durchgeführt werden.
• Die Notfallwiederherstellung eines lokalen Servers kann erheblich beschleunigt werden.
• Änderungen, die direkt in einer Azure-Dateifreigabe vorgenommen wurden (außerhalb der Synchronisierung), können schneller erkannt und synchronisiert werden.

Strukturierte Vorgehensweise für eine Bereitstellungszuordnung

Vor der Bereitstellung von Cloudspeicher in einem späteren Schritt ist es wichtig, eine Zuordnung zwischen lokalen Ordnern und Azure-Dateifreigaben zu erstellen. Diese Zuordnung informiert darüber, wie viele und welche Ressourcen in der Synchronisierungsgruppe für die Azure-Dateisynchronisierung bereitgestellt werden. Eine Synchronisierungsgruppe bindet die Azure-Dateifreigabe an den Ordner auf dem Server und stellt eine Synchronisierungsverbindung her.

Um zu entscheiden, wie viele Azure-Dateifreigaben benötigt werden, sehen Sie sich die folgenden Grenzwerte und bewährten Methoden an. Auf diese Weise können Sie die Zuordnung optimieren.

• Ein Server, auf dem der Azure-Dateisynchronisierungs-Agent installiert ist, kann eine Synchronisierung mit bis zu 30 Azure-Dateifreigaben durchführen.

• Eine Azure-Dateifreigabe wird in einem Speicherkonto bereitgestellt. Das macht das Speicherkonto zu einem Skalierungsziel für Leistungswerte wie IOPS und Durchsatz.

  Beachten Sie beim Bereitstellen von Azure-Dateifreigaben die IOPS-Einschränkungen eines Speicherkontos. Idealerweise sollten Sie eine 1:1-Zuordnung von Dateifreigaben zu Speicherkonten vornehmen. Dies ist jedoch aufgrund von verschiedenen Grenzwerten und Einschränkungen (sowohl von Ihrer Organisation als auch von Azure) vielleicht nicht immer möglich. Wenn es nicht möglich ist, eine einzige Dateifreigabe in einem Speicherkonto bereitzustellen, sollten Sie darauf achten, welche Dateifreigaben besonders aktiv und welche weniger aktiv sind. So können Sie sicherstellen, dass die am stärksten genutzten Dateifreigaben nicht gemeinsam in einem Speicherkonto platziert werden.

  Wenn Sie beabsichtigen, eine App in Azure zu verschieben, die die Azure-Dateifreigabe nativ verwendet, benötigen Sie möglicherweise mehr Leistung von der Azure-Dateifreigabe. Wenn diese Art der Verwendung eine Möglichkeit (auch in Zukunft) darstellt, ist die Erstellung einer einzelnen Azure-Dateifreigabe vom Typ „Standard“ in einem eigenen Speicherkonto die beste Lösung.

• Es gilt ein Grenzwert von 250 Speicherkonten pro Abonnement und Azure-Region.

Es wird empfohlen, die Anzahl der Elemente pro Synchronisierungsbereich gering zu halten. Dies ist ein wichtiger Faktor, der bei der Zuordnung von Ordnern zu Azure-Dateifreigaben zu berücksichtigen ist. Die Azure-Dateisynchronisierung wird mit 100 Millionen Elementen (Dateien und Ordner) pro Freigabe getestet. Es empfiehlt sich jedoch häufig, in einer einzelnen Freigabe maximal 20 bis 30 Millionen Elemente zu verwenden. Teilen Sie Ihren Namespace in mehrere Freigaben auf, wenn Sie merken, dass Sie diese Grenze überschreiten. Sie können weiterhin mehrere lokale Freigaben in derselben Azure-Dateifreigabe gruppieren, wenn Sie ungefähr unter dieser Grenze bleiben. Diese Methode bietet Ihnen Raum für Wachstum.

Möglicherweise können in Ihrem Fall mehrere Ordner logisch mit derselben Azure-Dateifreigabe synchronisiert werden (mithilfe des oben beschriebenen neuen, gemeinsamen Stammordners). Trotzdem kann es besser sein, die Ordner so zu gruppieren, dass sie nicht mit einer, sondern mit zwei Azure-Dateifreigaben synchronisiert werden. Mit dieser Methode kann die Anzahl der Dateien und Ordner pro Dateifreigabe auf dem Server ausgeglichen werden. Sie können auch Ihre lokalen Freigaben aufteilen und sie über mehrere lokale Server hinweg synchronisieren, was die Synchronisierung mit 30 weiteren Azure-Dateifreigaben pro zusätzlichem Server ermöglicht.

Häufige Szenarien und Überlegungen zur Dateisynchronisierung

#	Synchronisierungsszenario	Unterstützt	Überlegungen (oder Einschränkungen)	Lösung (oder Problemumgehung)
1	Dateiserver mit mehreren Datenträgern/Volumes und mehreren Freigaben für dieselbe Azure-Zieldateifreigabe (Konsolidierung)	Nein	Eine Azure-Zieldateifreigabe (Cloudendpunkt) unterstützt nur die Synchronisierung mit einer einzigen Synchronisierungsgruppe. Eine Synchronisierungsgruppe unterstützt nur einen einzigen Serverendpunkt pro registriertem Server.	1) Beginnen Sie mit der Synchronisierung eines einzigen Datenträgers (dessen Stammvolume) mit der Azure-Zieldateifreigabe. Wenn Sie mit dem größten Datenträger/Volume beginnen, können Sie lokale Speicheranforderungen erfüllen. Konfigurieren Sie das Cloudtiering, um alle Daten in die Cloud auszulagern, wodurch Speicherplatz auf dem Dateiserverdatenträger frei wird. Verschieben Sie Daten aus anderen Volumes/Freigaben in das aktuelle Volume, das gerade synchronisiert wird. Führen Sie die Schritte nacheinander aus, bis alle Daten in die Cloud ausgelagert/migriert wurden. 2) Streben Sie jeweils ein Stammvolume (Datenträger) an. Verwenden Sie Cloudtiering, um alle Daten auf die Azure-Zieldateifreigabe auszulagern. Entfernen Sie den Serverendpunkt aus der Synchronisierungsgruppe, erstellen Sie den Endpunkt mit dem nächsten Stammvolume/-datenträger erneut, synchronisieren Sie, und wiederholen Sie den Vorgang. Hinweis: Möglicherweise ist eine Neuinstallation des Agents erforderlich. 3) Empfehlen Sie die Verwendung von mehreren Azure-Zieldateifreigaben (dasselbe oder ein anderes Speicherkonto, basierend auf den Leistungsanforderungen).
2	Dateiserver mit einzelnem Volumen und mehreren Freigaben für dieselbe Azure-Zieldateifreigabe (Konsolidierung)	Ja	Es ist nicht möglich, mehrere Serverendpunkte pro registriertem Server mit derselben Azure-Zieldateifreigabe zu synchronisieren (wie oben angegeben).	Synchronisieren Sie den Stamm des Volumes, das mehrere Freigaben oder Ordner der obersten Ebene enthält. Weitere Informationen finden Sie im Konzept „Gruppierung freigeben“ und unter Volumesynchronisierung.
3	Dateiserver mit mehreren Freigaben und/oder Volumes zu mehreren Azure-Dateifreigaben unter einem einzelnen Speicherkonto (1:1-Freigabezuordnung)	Ja	Eine einzelne Windows Server-Instanz (oder ein Cluster) kann bis zu 30 Azure-Dateifreigaben synchronisieren. Ein Speicherkonto ist ein Skalierungsziel für Leistung. IOPS und Durchsatz werden über Dateifreigaben gemeinsam genutzt. Behalten Sie die Anzahl von Elementen pro Synchronisierungsgruppe innerhalb von 100 Millionen Elementen (Dateien und Ordner) pro Freigabe bei. Im Idealfall ist es am besten, unter 20 oder 30 Millionen pro Freigabe zu bleiben.	1) Verwenden Sie mehrere Synchronisierungsgruppen (Anzahl von Synchronisierungsgruppen = Anzahl der zu synchronisierenden Azure-Dateifreigaben). 2) In diesem Szenario können nur jeweils 30 Freigaben synchronisiert werden. Wenn Sie auf diesem Dateiserver mehr als 30 Freigaben haben, verwenden Sie das Konzept „Gruppierung freigeben“ und die Volumesynchronisierung, um die Anzahl von Stammordnern oder Ordnern der obersten Ebene an der Quelle zu verringern. 3) Verwenden Sie zusätzliche Dateisynchronisierungsserver lokal, und teilen/verschieben Sie Daten auf diese Server, um Einschränkungen auf dem Windows-Quellserver zu umgehen.
4	Dateiserver mit mehreren Freigaben und/oder Volumes zu mehreren Azure-Dateifreigaben unter einem anderen Speicherkonto (1:1-Freigabezuordnung)	Ja	Eine einzelne Windows Server-Instanz (oder ein einzelner Cluster) kann bis zu 30 Azure-Dateifreigaben (dasselbe oder ein anderes Speicherkonto) synchronisieren. Behalten Sie die Anzahl von Elementen pro Synchronisierungsgruppe innerhalb von 100 Millionen Elementen (Dateien und Ordner) pro Freigabe bei. Im Idealfall ist es am besten, unter 20 oder 30 Millionen pro Freigabe zu bleiben.	Dieselbe Vorgehensweise wie oben
5	Mehrere Dateiserver mit einem einzelnen Stammvolume oder einer einzelnen Freigabe für dieselbe Azure-Zieldateifreigabe (Konsolidierung)	Nein	Eine Synchronisierungsgruppe kann einen Cloudendpunkt (Azure-Dateifreigabe), der bereits in einer anderen Synchronisierungsgruppe konfiguriert wurde, nicht verwenden. Obwohl eine Synchronisierungsgruppe Serverendpunkte auf verschiedenen Dateiservern haben kann, können die Dateien nicht unterschiedlich sein.	Folgen Sie der Anleitung im Szenario Nr. 1 oben mit der zusätzlichen Überlegung, jeweils einen Dateiserver anzustreben.

Erstellen einer Zuordnungstabelle

Bestimmen Sie anhand der zuvor beschriebenen Informationen, wie viele Azure-Dateifreigaben Sie benötigen und welche Teile Ihrer vorhandenen Daten in welcher Azure-Dateifreigabe platziert werden sollen.

Erstellen Sie eine Tabelle mit den wichtigsten Aspekten, die Sie für Ihre Umgebung berücksichtigen müssen, damit Sie bei Bedarf darauf zugreifen können. Beim Erstellen Ihres Zuordnungsplans sollten Sie organisiert vorgehen, um nicht den Überblick zu verlieren, wenn Sie eine große Anzahl von Azure-Ressourcen gleichzeitig bereitstellen. Laden Sie die folgende Excel-Datei herunter, um sie als Vorlage zum Erstellen Ihrer Zuordnung zu verwenden.

Laden Sie eine Namespace-Zuordnungsvorlage herunter.

Überlegungen zu Windows-Dateiservern

Um die Synchronisierungsfunktion unter Windows Server zu aktivieren, müssen Sie den herunterladbaren Azure-Dateisynchronisierungs-Agent installieren. Der Azure-Dateisynchronisierungs-Agent stellt zwei Hauptkomponenten bereit: FileSyncSvc.exe, den Windows-Hintergrunddienst, der für die Überwachung von Änderungen an den Serverendpunkten und das Initiieren von Synchronisierungssitzungen zuständig ist, und StorageSync.sys, einen Dateisystemfilter, der das Cloudtiering und die schnelle Notfallwiederherstellung ermöglicht.

Betriebssystemanforderungen

Die Azure-Dateisynchronisierung wird mit den folgenden Versionen von Windows Server unterstützt:

Version	Unterstützte SKUs	Unterstützte Bereitstellungsoptionen
Windows Server 2025	Azure, Datacenter, Essentials, Standard und IoT	Vollständig und Core
Windows Server 2022	Azure, Datacenter, Essentials, Standard und IoT	Vollständig und Core
Windows Server 2019	Rechenzentrum, Essentials, Standard und IoT	Vollständig und Core
Windows Server 2016	Rechenzentrum, Essentials, Standard und Speicherserver	Vollständig und Core
Windows Server 2012 R2*	Rechenzentrum, Essentials, Standard und Speicherserver	Vollständig und Core

*Erfordert das Herunterladen und Installieren von Windows Management Framework (WMF) 5.1. Das Paket, das für Windows Server 2012 R2 heruntergeladen und installiert werden sollte, lautet Win8.1AndW2K12R2-KB-x64.msu.

Zukünftige Versionen von Windows Server werden hinzugefügt, sobald sie veröffentlicht werden.

Mindestens erforderliche Systemressourcen

Azure-Dateisynchronisierung erfordert einen Server, entweder physisch oder virtuell, mit mindestens einer CPU, mindestens 2 GB Arbeitsspeicher und einem lokal angefügten Volume, das mit dem NTFS-Dateisystem formatiert ist.

Für die meisten Produktionsworkloads empfiehlt es sich nicht, einen Azure-Dateisynchronisierungsserver nur mit den Mindestanforderungen zu konfigurieren. Weitere Informationen finden Sie unter Empfohlenen Systemressourcen.

Empfohlene Systemressourcen

Ebenso wie jede Serverfunktion oder -anwendung werden die Systemressourcenanforderungen für die Azure-Dateisynchronisierung durch die Skalierung der Bereitstellung bestimmt. Größere Bereitstellungen auf einem Server erfordern umfangreichere Systemressourcen. Für die Azure-Dateisynchronisierung wird die Skalierung durch die Anzahl der Objekte an den Serverendpunkten und die Änderung für das Dataset bestimmt. Ein einzelner Server kann über mehrere Serverendpunkte in mehreren Synchronisierungsgruppen verfügen, und die Anzahl der in der folgenden Tabelle aufgeführten Objekte gilt für den vollständigen Namespace, an den ein Server angefügt ist.

Beispiel: Serverendpunkt A mit 10 Millionen Objekten + Serverendpunkt B mit 10 Millionen Objekten = 20 Millionen Objekte. Für diese Beispielbereitstellung wird die Verwendung von 8 CPUs, 16 GiB Arbeitsspeicher für den stabilen Status und (falls möglich) 48 GiB Arbeitsspeicher für die Erstmigration empfohlen.

Namespacedaten werden aus Leistungsgründen im Arbeitsspeicher gespeichert. Aus diesem Grund benötigen größere Namespaces mehr Arbeitsspeicher, um eine gute Leistung zu gewährleisten, und umfangreiche Änderungen erfordern mehr CPU-Leistung für die Verarbeitung.

In der folgenden Tabelle sind sowohl die Größe des Namespace als auch eine Konvertierung in die Kapazität typischer universeller Dateifreigaben angegeben, wobei die durchschnittliche Dateigröße 512 KiB beträgt. Wenn Ihre Dateigrößen geringer sind, sollten Sie ggf. zusätzlichen Arbeitsspeicher für die gleiche Kapazität hinzufügen. Verwenden Sie als Grundlage für Ihre Arbeitsspeicherkonfiguration die Größe des Namespace.

Namespacegröße: Dateien und Verzeichnisse (Millionen)	Typische Kapazität (TiB)	CPU-Kerne	Empfohlener Arbeitsspeicher (GiB)
3	1.4	2	8 (Erstsynchronisierung) / 2 (normale Änderungen)
5	2.3	2	16 (Erstsynchronisierung) / 4 (normale Änderungen)
10	4,7	4	32 (Erstsynchronisierung) / 8 (normale Änderungen)
30	14,0	8	48 (Erstsynchronisierung) / 16 (normale Änderungen)
50	23,3	16	64 (Erstsynchronisierung) / 32 (normale Änderungen)
100*	46,6	32	128 (Erstsynchronisierung) / 32 (normale Änderungen)

*Die Synchronisierung von mehr als 100 Millionen Dateien und Verzeichnisse wird derzeit nicht empfohlen. Dies ist eine weiche Einschränkung basierend auf unseren getesteten Schwellenwerten. Weitere Informationen finden Sie unter Skalierbarkeitsziele für die Azure-Dateisynchronisierung.

Auswertungs-Cmdlet

Vor der Bereitstellung der Azure-Dateisynchronisierung müssen Sie mit dem Auswertungs-Cmdlet für die Azure-Dateisynchronisierung auswerten, ob sie mit Ihrem System kompatibel ist. Dieses Cmdlet prüft auf potenzielle Probleme mit Ihrem Dateisystem und Dataset, z. B. nicht unterstützte Zeichen oder eine nicht unterstützte Betriebssystemversion. Damit werden die meisten, aber nicht alle der unten genannten Features überprüft. Es wird empfohlen, dass Sie den verbleibenden Teil dieses Abschnitts sorgfältig durchzulesen, um sicherzustellen, dass Ihre Bereitstellung reibungslos verläuft.

Sie können das Auswertungs-Cmdlet installieren, indem Sie das PowerShell-Modul „Az“ anhand der folgenden Anweisungen installieren: Installieren und Konfigurieren von Azure PowerShell.

Verwendung

Sie können das Auswertungstool in unterschiedlicher Weise aufrufen: Sie können die Systemprüfungen, die Datasetprüfungen oder beide Prüfungen durchführen. So führen Sie sowohl die System- als auch die Datasetprüfungen durch:

Invoke-AzStorageSyncCompatibilityCheck -Path <path>

So prüfen Sie nur Ihr Dataset:

Invoke-AzStorageSyncCompatibilityCheck -Path <path> -SkipSystemChecks

So testen Sie nur die Systemanforderungen:

Invoke-AzStorageSyncCompatibilityCheck -ComputerName <computer name> -SkipNamespaceChecks

So zeigen Sie die Ergebnisse in einer CSV-Datei an:

$validation = Invoke-AzStorageSyncCompatibilityCheck C:\DATA
$validation.Results | Select-Object -Property Type, Path, Level, Description, Result | Export-Csv -Path C:\results.csv -Encoding utf8

Dateisystemkompatibilität

Azure-Dateisynchronisierung wird nur auf direkt zugeordneten NTFS-Volumes unterstützt. Direkt zugeordneter Speicher (DAS) unter Windows Server bedeutet, dass das Windows Server-Betriebssystem der Besitzer des Dateisystems ist. DAS kann durch physisches Anfügen von Datenträgern an den Dateiserver, durch Anfügen von virtuellen Datenträgern an eine Dateiserver-VM (z. B. eine von Hyper-V gehostete VM) oder sogar durch iSCSI bereitgestellt werden.

Nur NTFS-Volumes werden unterstützt. ReFS, FAT, FAT32 und andere Dateisysteme werden nicht unterstützt.

In der folgenden Tabelle wird der Interop-Status der NTFS-Dateisystemfeatures gezeigt:

Funktion	Status der Unterstützung	Notizen
Zugriffssteuerungslisten (ACLs)	Vollständig unterstützt.	Diskrete Zugriffssteuerungslisten im Windows-Stil werden von der Azure-Dateisynchronisierung beibehalten und von Windows Server für Serverendpunkte erzwungen. ACLs können auch erzwungen werden, wenn die Azure-Dateifreigabe direkt eingebunden wird. Hierfür ist jedoch zusätzliche Konfiguration erforderlich. Weitere Informationen finden Sie im Abschnitt Identität.
Feste Links	Ausgelassen
Symbolische Links	Ausgelassen
Bereitstellungspunkte	Teilweise unterstützt	Bereitstellungspunkte können der Stamm eines Serverendpunkts sein, aber sie werden übersprungen, wenn sie im Namespace des Serverendpunkts enthalten sind.
Verbindungen	Ausgelassen	Beispiel: Die Ordner „DfrsrPrivate“ und „DFSRoots“ des verteilten Dateisystems.
Analysepunkte	Ausgelassen
NTFS-Komprimierung	Teilweise unterstützt	Die Azure-Dateisynchronisierung unterstützt keine Serverendpunkte, die sich auf einem Volume befinden, auf dem das Verzeichnis „System Volume Information“ (SVI) komprimiert ist.
Sparsedateien	Vollständig unterstützt.	Sparsedateien werden synchronisiert (werden nicht blockiert), werden jedoch als vollständige Dateien in die Cloud synchronisiert. Wenn sich der Inhalt der Datei in der Cloud (oder auf einem anderen Server) ändert, handelt es sich bei der Datei nicht länger um eine Sparsedatei, sobald die Änderung heruntergeladen wird.
Alternative Datenströme (ADS)	Beibehalten, aber nicht synchronisiert	Beispielsweise werden von der Dateiklassifizierungsinfrastruktur erstellte Klassifizierungstags nicht synchronisiert. Vorhandene Klassifizierungstags in Dateien auf den einzelnen Serverendpunkten bleiben hiervon unberührt.

Die Azure-Dateisynchronisierung überspringt auch bestimmte temporäre Dateien und Systemordner:

Datei/Ordner	Hinweis
pagefile.sys	Systemspezifische Datei
Desktop.ini	Systemspezifische Datei
thumbs.db	Temporäre Datei für Miniaturansichten
ehthumbs.db	Temporäre Datei für Miniaturansichten von Medien
~$*.*	Temporäre Office-Datei
*.tmp	Temporäre Datei
*.laccdb	Access-DB-Sperrdatei
635D02A9D91C401B97884B82B3BCDAEA.*	Interne Synchronisierungsdatei
\System Volume Information	Volumespezifischer Ordner
$RECYCLE.BIN	Ordner
\SyncShareState	Ordner für die Synchronisierung
.SystemShareInformation	Ordner für die Synchronisierung in der Azure-Dateifreigabe

Überlegungen zum benötigten freien Speicherplatz auf dem lokalen Datenträger

Berücksichtigen Sie bei der Planung der Verwendung der Azure-Dateisynchronisierung, wie viel freien Speicherplatz Sie auf dem lokalen Datenträger benötigen, auf dem Sie einen Serverendpunkt einrichten möchten.

Für die Azure-Dateisynchronisierung müssen Sie die folgenden Faktoren berücksichtigen, die Speicherplatz auf Ihrem lokalen Datenträger belegen:

• Bei aktiviertem Cloudtiering:

  • Analysepunkte für Tieringdateien
  • Metadatendatenbank der Azure-Dateisynchronisierung
  • Wärmespeicher der Azure-Dateisynchronisierung
  • Vollständig heruntergeladene Dateien in Ihrem Hot Cache (sofern vorhanden)
  • Anforderungen der Richtlinie für freien Volumespeicherplatz

• Bei deaktiviertem Cloudtiering:

  • Vollständig heruntergeladene Dateien
  • Wärmespeicher der Azure-Dateisynchronisierung
  • Metadatendatenbank der Azure-Dateisynchronisierung

Anhand eines Beispiels wird veranschaulicht, wie Sie den auf Ihrem lokalen Datenträger benötigten freien Speicherplatz ermitteln können. Angenommen, Sie haben Ihren Azure-Dateisynchronisierungs-Agent auf Ihrem virtuellen Azure Windows-Computer installiert und planen die Erstellung eines Serverendpunkts auf Datenträger F. Sie verfügen über 1 Million Dateien und möchten alle Dateien, 100.000 Verzeichnisse und einen Datenträgercluster mit einer Größe von 4 KiB per Tiering auslagern. Die Datenträgergröße beträgt 1000 GiB. Sie möchten Cloudtiering aktivieren und die Richtlinie für freien Volumespeicherplatz auf 20 % festlegen.

1. NTFS ordnet jeder Tieringdatei eine Clustergröße zu. 1 Million Dateien * 4 KiB Clustergröße = 4.000.000 KiB (4 GiB)

   Hinweis

   Um die Vorteile von Cloudtiering optimal nutzen zu können, wird empfohlen, kleinere NTFS-Clustergrößen (weniger als 64 KB) zu verwenden, da jede mehrstufige Datei einen Cluster belegt. Also wird der von Tieringdateien belegte Speicherplatz von NTFS zugeordnet. Aus diesem Grund wird er auf keiner Benutzeroberfläche angezeigt.

2. Synchronisierungsmetadaten nehmen eine Clustergröße pro Element ein. (1 Million Dateien + 100.000 Verzeichnisse) * 4 KiB Clustergröße = 4.400.000 KiB (4,4 GiB)
3. Der Wärmespeicher der Azure-Dateisynchronisierung belegt 1,1 KiB pro Datei. 1 Million Dateien * 1,1 KiB = 1.100.000 KiB (1,1 GiB)
4. Die Richtlinie für freien Volumespeicherplatz ist auf 20 % festgelegt. 1000 GiB * 0,2 = 200 GiB

In diesem Fall würde die Azure-Dateisynchronisierung etwa 209.500.000 KiB (209,5 GiB) Speicherplatz für diesen Namespace benötigen. Fügen Sie diese Speicherplatzmenge zu jedem gewünschten zusätzlichen freien Speicherplatz hinzu, um herauszufinden, wie viel freier Speicherplatz für diesen Datenträger erforderlich ist.

Failoverclustering

1. Windows Server-Failoverclustering wird von der Azure-Dateisynchronisierung für die Bereitstellungsoption „Dateiserver zur allgemeinen Verwendung“ unterstützt. Weitere Informationen zum Konfigurieren der Rolle „Dateiserver zur allgemeinen Verwendung“ für einen Failovercluster finden Sie unter Bereitstellen eines geclusterten Dateiservers mit zwei Knoten.
2. Das einzige von der Azure-Dateisynchronisierung unterstützte Szenario ist ein Windows Server-Failovercluster mit gruppierten Datenträgern.
3. Failoverclustering wird auf einem „Dateiserver mit horizontaler Skalierung für Anwendungsdaten“ (Scale-Out File Server, SOFS), auf freigegebenen Clustervolumes (Clustered Shared Volume, CSV) und lokalen Datenträgern nicht unterstützt.

Datendeduplizierung

Windows Server 2025, Windows Server 2022, Windows Server 2019 oder Windows Server 2016
Die Datendeduplizierung wird unter Windows Server 2016, Windows Server 2019, Windows Server 2022 und Windows Server 2025 unterstützt, unabhängig davon, ob das Cloudtiering auf einem oder mehreren Serverendpunkten auf dem Volume aktiviert oder deaktiviert ist. Durch das Aktivieren der Datendeduplizierung auf einem Volume mit aktiviertem Cloudtiering können Sie weitere Dateien lokal zwischenspeichern, ohne mehr Speicher bereitstellen zu müssen.

Wenn die Datendeduplizierung für ein Volume mit aktiviertem Cloudtiering aktiviert ist, wird das Tiering von für die Deduplizierung optimierten Dateien innerhalb des Serverendpunkt-Speicherorts ähnlich wie bei einer normalen Datei basierend auf den Richtlinieneinstellungen für Cloudtiering ausgeführt. Nachdem das Tiering der für die Deduplizierung optimierten Dateien ausgeführt wurde, wird der Garbage Collection-Auftrag „Datendeduplizierung“ automatisch ausgeführt, um Speicherplatz freizugeben, indem unnötige Blöcke entfernt werden, die nicht mehr von anderen Dateien auf dem Volume referenziert werden.

Beachten Sie, dass die Volumeeinsparungen nur für den Server gelten. Die Daten in der Azure-Dateifreigabe werden nicht dedupliziert.

Windows Server 2012 R2
Datendeduplizierung und Cloudtiering auf demselben Volume werden unter Windows Server 2012 R2 von der Azure-Dateisynchronisierung nicht unterstützt. Wenn die Datendeduplizierung auf einem Volume aktiviert wird, muss Cloudtiering deaktiviert werden.

Hinweise

• Wenn die Datendeduplizierung vor dem Azure-Dateisynchronisierungs-Agent installiert wird, ist ein Neustart erforderlich, damit die Datendeduplizierung und das Cloudtiering auf demselben Volume unterstützt werden.

• Wenn die Datendeduplizierung nach dem Cloudtiering auf einem Volume aktiviert wird, werden durch den ersten Auftrag zur Optimierung der Deduplizierung Dateien auf dem Volume optimiert, für die noch kein Tiering erfolgt ist. Dies hat folgende Auswirkungen auf das Cloudtiering:

  • Die Richtlinie für die Freigabe von Speicherplatz bewirkt, dass Dateien entsprechend dem freien Speicherplatz auf dem Volume, der anhand des Wärmebilds ermittelt wird, weiterhin umgelagert werden.
  • Die Datumsrichtlinie bewirkt, dass das Tiering für Dateien übersprungen wird, die eigentlich infrage gekommen wären. Dies liegt daran, dass durch den Auftrag zur Optimierung der Deduplizierung auf die Dateien zugegriffen wird.

• Sofern die Datei nicht bereits verlagert wurde, wird das Cloudtiering mit Datumsrichtlinie bei laufenden Aufträgen zur Optimierung der Deduplizierung verzögert. Dies liegt an der MinimumFileAgeDays-Einstellung der Datendeduplizierung.

  • Beispiel: Wenn die MinimumFileAgeDays-Einstellung sieben Tage beträgt und die Datumsrichtlinie für das Cloudtiering 30 Tage vorsieht, werden Dateien gemäß der Datumsrichtlinie nach 37 Tagen umgelagert.
  • Hinweis: Sobald eine Datei von der Azure-Dateisynchronisierung umgelagert wurde, wird sie vom Auftrag zur Optimierung der Deduplizierung übersprungen.

• Wenn ein Server unter Windows Server 2012 R2 mit installiertem Azure-Dateisynchronisierungs-Agent auf Windows Server 2016, Windows Server 2019, Windows Server 2022 oder Windows Server 2025 aktualisiert wird, sind die folgenden Schritte erforderlich, damit die Datendeduplizierung und das Cloudtiering auf demselben Volume unterstützt werden:

  • Deinstallieren Sie den Azure-Dateisynchronisierungs-Agent für Windows Server 2012 R2, und starten Sie den Server neu.
  • Laden Sie den Azure-Dateisynchronisierungs-Agent für die neue Serverbetriebssystemversion (Windows Server 2016, Windows Server 2019, Windows Server 2022 oder Windows Server 2025) herunter.
  • Installieren Sie den Azure-Dateisynchronisierungs-Agent, und starten Sie den Server neu.

  Hinweis: Bei der Deinstallation und Neuinstallation des Agents werden die Konfigurationseinstellungen der Azure-Dateisynchronisierung auf dem Server beibehalten.

Verteiltes Dateisystem (Distributed File System, DFS)

Die Azure-Dateisynchronisierung unterstützt die Interoperabilität mit DFS-Namespaces (DFS-N) und DFS-Replikation (DFS-R).

DFS-Namespaces (DFS-N): Die Azure-Dateisynchronisierung wird bei der DFS-N-Implementierung vollständig unterstützt. Sie können den Azure-Dateisynchronisierungs-Agent auf einem oder mehreren Dateiservern installieren, um Daten zwischen den Serverendpunkten und dem Cloudendpunkt zu synchronisieren, und DFS-N dann zum Bereitstellen des Namespace-Diensts verwenden. Weitere Informationen finden Sie unter Übersicht über DFS-Namespaces und DFS-Namespaces mit Azure Files.

DFS-Replikation (DFS-R) : Da DFS-R und die Azure-Dateisynchronisierung beides Replikationslösungen sind, empfehlen wir in den meisten Fällen das Ersetzen von DFS-R durch die Azure-Dateisynchronisierung. Es gibt aber mehrere Szenarien, in denen die parallele Nutzung von DFS-R und Azure-Dateisynchronisierung sinnvoll sein kann:

• Sie migrieren von einer DFS-R-Bereitstellung zu einer Bereitstellung der Azure-Dateisynchronisierung. Weitere Informationen finden Sie unter Migrieren einer DFS-R-Bereitstellung (DFS-Replikation) zur Azure-Dateisynchronisierung.
• Nicht jeder lokale Server, für den eine Kopie Ihrer Dateidaten erforderlich ist, kann direkt mit dem Internet verbunden werden.
• Bei Teilstrukturservern werden Daten auf einem einzelnen Hubserver zusammengefasst, für den Sie die Azure-Dateisynchronisierung verwenden möchten.

Für die parallele Nutzung von Azure-Dateisynchronisierung und DFS-R gilt Folgendes:

1. Das Azure-Dateisynchronisierungs-Cloudtiering muss auf Volumes mit replizierten DFS-R-Ordnern deaktiviert sein.
2. Serverendpunkte sollten nicht in schreibgeschützten DFS-R-Replikationsordnern konfiguriert werden.
3. Nur ein einziger Server-Endpunkt kann sich mit einem DFS-R-Standort überschneiden. Wenn sich mehrere Serverendpunkte mit anderen aktiven DFS-R-Standorten überschneiden, kann dies zu Konflikten führen.

Weitere Informationen finden Sie unter Übersicht über DFS-Namespaces und DFS-Replikation.

Sysprep

Die Verwendung von Sysprep auf einem Server, auf dem der Azure-Dateisynchronisierungs-Agent installiert ist, wird nicht unterstützt und kann zu unerwarteten Ergebnissen führen. Die Agent-Installation und Serverregistrierung sollte nach der Bereitstellung des Serverimages und nach Abschluss des Mini-Setups für Sysprep erfolgen.

Windows-Suche

Wenn auf einem Serverendpunkt Cloudtiering aktiviert ist, werden Tieringdateien von Windows Search übersprungen und nicht indiziert. Dateien ohne Tiering werden ordnungsgemäß indiziert.

Andere Lösungen für hierarchisches Speichermanagement (HSM)

Es sollten keine anderen HSM-Lösungen in Verbindung mit der Azure-Dateisynchronisierung verwendet werden.

Leistung und Skalierbarkeit

Da der Azure-Dateisynchronisierungs-Agent auf einem Windows Server-Computer ausgeführt wird, der mit den Azure-Dateifreigaben verbunden wird, hängt die effektive Synchronisierungsleistung von einer Reihe von Faktoren in Ihrer Infrastruktur ab: von Windows Server und der zugrunde liegenden Datenträgerkonfiguration, der Netzwerkbandbreite zwischen dem Server und Azure Storage, der Dateigröße, der gesamten Datasetgröße und der Aktivität im Dataset. Da die Azure-Dateisynchronisierung auf Dateiebene ausgeführt wird, werden die Leistungsmerkmale einer auf der Azure-Dateisynchronisierung basierenden Lösung besser in der Anzahl von Objekten (Dateien und Verzeichnisse) gemessen, die pro Sekunde verarbeitet werden.

Änderungen, die über das Azure-Portal oder den SMB an der Azure-Dateifreigabe vorgenommen wurden, werden im Gegensatz zu Änderungen am Serverendpunkt nicht sofort erkannt und repliziert. Azure Files verfügt weder über Änderungsmitteilungen noch über eine Journalfunktion, sodass es keine Möglichkeit gibt, eine Synchronisierungssitzung automatisch zu initiieren, wenn Dateien geändert werden. Unter Windows Server verwendet die Azure-Dateisynchronisierung das Windows-USN-Journaling, um automatisch eine Synchronisierungssitzung zu starten, wenn sich Dateien ändern.

Zur Erkennung von Änderungen an der Azure-Dateifreigabe verfügt die Azure-Dateisynchronisierung über einen geplanten Auftrag: den so genannten Änderungserkennungsauftrag. Ein Änderungserkennungsauftrag zählt jede Datei in der Dateifreigabe auf und vergleicht sie anschließend mit der Synchronisierungsversion für die betreffende Datei. Wenn der Änderungserkennungsauftrag feststellt, dass sich Dateien geändert haben, startet die Azure-Dateisynchronisierung eine Synchronisierungssitzung. Der Änderungserkennungsauftrag wird alle 24 Stunden ausgelöst. Da der Änderungserkennungsauftrag jede Datei in der Dateifreigabe von Azure aufzählt, dauert die Änderungserkennung bei großen Namespaces länger als bei kleineren Namespaces. Bei großen Namespaces dauert die Ermittlung der geänderten Dateien unter Umständen länger als 24 Stunden.

Weitere Informationen finden Sie unter Leistungsmetriken der Azure-Dateisynchronisierung und Skalierbarkeitsziele für die Azure-Dateisynchronisierung.

Identität

Die Azure-Dateisynchronisierung funktioniert mit Ihrer AD-basierten Standardidentität, ohne dass ein besonderes Setup über das Einrichten der Synchronisierung hinaus erforderlich ist. Bei Verwendung der Azure-Dateisynchronisierung wird im Allgemeinen davon ausgegangen, dass die meisten Zugriffe über die Zwischenspeicherungsserver der Azure-Dateisynchronisierung und nicht über die Azure-Dateifreigabe erfolgen. Da sich die Serverendpunkte unter Windows Server befinden und Windows Server seit langer Zeit ACLs im AD- und Windows-Stil unterstützt, ist nichts weiter erforderlich, als sicherzustellen, dass die beim Speichersynchronisierungsdienst registrierten Windows-Dateiserver zur Domäne gehören. Die Azure-Dateisynchronisierung speichert ACLs für die Dateien in der Azure-Dateifreigabe und repliziert sie auf alle Serverendpunkte.

Auch wenn die Synchronisierung von direkt an der Azure-Dateifreigabe vorgenommenen Änderungen mit den Serverendpunkten in der Synchronisierungsgruppe länger dauert, sollten Sie auch sicherstellen, dass Sie Ihre AD-Berechtigungen für Ihre Dateifreigabe auch direkt in der Cloud durchsetzen können. Zu diesem Zweck müssen Sie Ihr Speicherkonto mit Ihrem lokalen AD in die Domäne einbinden, ebenso wie die Windows-Dateiserver in die Domäne eingebunden werden. Weitere Informationen zum Domänenbeitritt Ihres Speicherkontos zu einem Active Directory im Besitz des Kunden finden Sie unter Azure Files Active Directory: Übersicht.

Netzwerk

Der Azure-Dateisynchronisierungs-Agent kommuniziert mit dem Speichersynchronisierungsdienst und der Azure-Dateifreigabe unter Verwendung des Azure-Dateisynchronisierungs-REST-Protokolls und des FileREST-Protokolls. Beide Protokolle verwenden immer HTTPS über Port 443. SMB wird nie zum Hochladen oder Herunterladen von Daten zwischen Ihrem Windows-Server und der Azure-Dateifreigabe verwendet. Da die meisten Unternehmen HTTPS-Datenverkehr über Port 443 als Voraussetzung für den Besuch der meisten Websites zulassen, ist für die Bereitstellung von Azure-Dateisynchronisierung normalerweise keine spezielle Netzwerkkonfiguration erforderlich.

Je nach den Richtlinien Ihres Unternehmens oder gesetzlichen Anforderungen benötigen Sie möglicherweise eine restriktivere Kommunikation mit Azure. Daher bietet die Azure-Dateisynchronisierung mehrere Mechanismen zur Konfiguration von Netzwerken. Basierend auf Ihren Anforderungen können Sie Folgendes ausführen:

• Tunneln der Synchronisierung und des Datenverkehrs für Uploads/Downloads über ExpressRoute oder ein Azure-VPN.
• Nutzen von Azure Files- und Azure-Netzwerkfeatures, z. B. von Dienstendpunkten und privaten Endpunkten.
• Konfigurieren der Azure-Dateisynchronisierung zur Unterstützung Ihres Proxys in Ihrer Umgebung.
• Drosseln der Netzwerkaktivität aus der Azure-Dateisynchronisierung.

Weitere Informationen zu Azure-Dateisynchronisierung und -Netzwerken finden Sie unter Netzwerküberlegungen zur Azure-Dateisynchronisierung.

Verschlüsselung

Wenn Sie Azure-Dateisynchronisierung verwenden, sind drei verschiedene Verschlüsselungsebenen zu beachten: Verschlüsselung im ruhenden Speicher von Windows Server, Verschlüsselung während der Übertragung zwischen dem Azure-Dateisynchronisierungs-Agent und Azure und Verschlüsselung im Ruhezustand Ihrer Daten in der Azure-Dateifreigabe.

Windows Server-Verschlüsselung ruhender Daten

Es gibt zwei Strategien für die Verschlüsselung von Daten unter Windows Server, die in der Regel mit der Azure-Dateisynchronisierung funktionieren: Verschlüsselung unterhalb des Dateisystems, sodass das Dateisystem und alle Daten, die in das Dateisystem geschrieben werden, verschlüsselt sind, und Verschlüsselung im Dateiformat selbst. Diese Methoden schließen sich nicht gegenseitig aus. Sie können bei Bedarf auch zusammen verwendet werden, weil sich der Verschlüsselungszweck unterscheidet.

Um Verschlüsselung unterhalb des Dateisystems bereitzustellen, bietet Windows Server einen BitLocker-Posteingang. BitLocker ist für die Azure-Dateisynchronisierung vollständig transparent. Der Hauptgrund für die Verwendung eines Verschlüsselungsmechanismus wie BitLocker besteht darin, die physische Exfiltration von Daten durch Diebstahl der Datenträger aus Ihrem lokalen Rechenzentrum zu verhindern sowie das Querladen eines nicht autorisierten Betriebssystems zur Durchführung nicht autorisierter Lese-/Schreibvorgänge auf Ihren Daten zu verhindern. Weitere Informationen zu BitLocker finden Sie unter BitLocker: Übersicht.

Produkte von Drittanbietern, die ähnlich wie BitLocker funktionieren, da sie sich unterhalb des NTFS-Volumes befinden, sollten auf ähnliche Weise vollständig transparent mit der Azure-Dateisynchronisierung zusammenarbeiten.

Die andere Hauptmethode zum Verschlüsseln von Daten besteht darin, den Datenstrom der Datei zu verschlüsseln, wenn die Datei von der Anwendung gespeichert wird. Manche Anwendungen können dies nativ ausführen, aber in der Regel ist das nicht der Fall. Ein Beispiel für eine Methode zum Verschlüsseln des Datenstroms der Datei ist Azure Information Protection (AIP)/Azure Rights Management Services (Azure RMS)/Active Directory RMS. Der Hauptgrund für die Verwendung eines Verschlüsselungsmechanismus wie AIP/RMS besteht darin, die Exfiltration von Daten aus Ihrer Dateifreigabe durch Benutzer zu verhindern, die sie an andere Speicherorte kopieren (z. B. auf ein Flashlaufwerk) oder per E-Mail an eine nicht autorisierte Person senden. Wenn der Datenstrom einer Datei als Teil des Dateiformats verschlüsselt ist, wird diese Datei weiterhin auf der Azure-Dateifreigabe verschlüsselt sein.

Azure-Dateisynchronisierung kann nicht mit NTFS EFS (NTFS Encrypted File System) oder Verschlüsselungslösungen von Drittanbietern zusammenarbeiten, die sich oberhalb des Dateisystems, aber unterhalb des Datenstroms der Datei befinden.

Verschlüsselung während der Übertragung

Der Azure-Dateisynchronisierungs-Agent kommuniziert mit dem Speichersynchronisierungsdienst und der Azure-Dateifreigabe unter Verwendung des Azure-Dateisynchronisierungs-REST-Protokolls und des FileREST-Protokolls. Beide Protokolle verwenden immer HTTPS über Port 443. Die Azure-Dateisynchronisierung sendet keine unverschlüsselten Anforderungen über HTTP.

Azure-Speicherkonten enthalten einen Switch, der Verschlüsselung während der Übertragung erfordert. Dieser ist standardmäßig aktiviert. Auch wenn der Switch auf Speicherkontoebene deaktiviert ist (was bedeutet, dass unverschlüsselte Verbindungen mit Ihren Azure-Dateifreigaben möglich sind), verwendet die Azure-Dateisynchronisierung weiterhin nur verschlüsselte Kanäle für den Zugriff auf Ihre Dateifreigabe.

Der Hauptgrund für die Deaktivierung der Verschlüsselung während der Übertragung für ein Speicherkonto ist die Unterstützung einer älteren Anwendung, die unter einem älteren Betriebssystem wie z. B. Windows Server 2008 R2 oder einer älteren Linux-Distribution ausgeführt werden muss und direkt mit einer Azure-Dateifreigabe kommuniziert. Wenn die Legacyanwendung mit dem Windows Server-Cache der Dateifreigabe kommuniziert, hat das Umschalten dieser Einstellung keine Auswirkungen.

Wir empfehlen dringend, sicherzustellen, dass die Verschlüsselung von Daten während der Übertragung aktiviert ist.

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

Verschlüsselung der Azure-Dateifreigabe im Ruhezustand

Alle in Azure Files gespeicherten Daten werden im Ruhezustand mithilfe der Azure-Speicherdienstverschlüsselung (Storage Service Encryption, SSE) verschlüsselt. Die Speicherdienstverschlüsselung funktioniert ähnlich wie BitLocker unter Windows: Daten werden unterhalb der Dateisystemebene verschlüsselt. Da Daten durch die Codierung auf dem Datenträger unterhalb des Dateisystems der Azure-Dateifreigabe verschlüsselt werden, benötigen Sie keinen Zugriff auf den zugrunde liegenden Schlüssel auf dem Client, um aus der Azure-Dateifreigabe zu lesen oder in diese zu schreiben. Die Verschlüsselung ruhender Daten wird auf SMB- und NFS-Protokolle angewendet.

Standardmäßig werden in Azure Files gespeicherte Daten mit von Microsoft verwalteten Schlüsseln verschlüsselt. Bei von Microsoft verwalteten Schlüsseln ist Microsoft im Besitz der Schlüssel zum Verschlüsseln/Entschlüsseln der Daten und damit dafür verantwortlich, sie in regelmäßigen Abständen zu rotieren. Sie können auch Ihre eigenen Schlüssel selbst verwalten, sodass Sie den Rotationsvorgang steuern können. Wenn Sie Ihre Dateifreigaben mit vom Kunden verwalteten Schlüsseln verschlüsseln, ist Azure Files für den Zugriff auf Ihre Schlüssel autorisiert, um Lese- und Schreibanforderungen von Ihren Clients zu erfüllen. Mit vom Kunden verwalteten Schlüsseln können Sie diese Autorisierung jederzeit widerrufen. Dies bedeutet jedoch, dass die Azure-Dateifreigabe nicht mehr über SMB oder die FileREST-API zugänglich ist.

Azure Files verwendet dasselbe Verschlüsselungsschema wie die anderen Azure-Speicherdienste, z. B. Azure Blob Storage. Weitere Informationen zur Azure-Speicherdienstverschlüsselung finden Sie unter Azure Storage-Verschlüsselung für ruhende Daten.

Speicherebenen

Azure Files bietet zwei verschiedene Speichermedientarife (SSD und HDD), sodass Sie Ihre Freigaben an die Leistungs- und Preisanforderungen Ihres jeweiligen Szenarios anpassen können:

• SSD (Premium): Premiumdateifreigaben verwenden SSDs (Solid State Drives), die konsistent hohe Leistung und niedrige Latenz (im einstelligen Millisekundenbereich für die meisten E/A-Vorgänge) für E/A-intensive Workloads bieten. Premium-Dateifreigaben sind für eine Vielzahl von Workloads wie Datenbanken, Websitehosting und Entwicklungsumgebungen geeignet. Sie können mit SMB- und NFS-Protokollen (Server Message Block bzw. Network File System) verwendet werden. Premium-Dateifreigaben werden im Speicherkonto vom Typ „FileStorage“ bereitgestellt und sind nur in einem bereitgestellten Abrechnungsmodell verfügbar. Weitere Informationen zum bereitgestellten Abrechnungsmodell für Premium-Dateifreigaben finden Sie unter Grundlegendes zur Bereitstellung für Premium-Dateifreigaben. Premiumdateifreigaben bieten eine SLA mit höherer Verfügbarkeit als Standarddateifreigaben (weitere Informationen finden Sie unter „Azure Files Premium-Tarif“).

• HDD (Standard): Standarddateifreigaben verwenden Festplattenlaufwerke (HDDs) und bieten eine kostengünstige Speicheroption für universelle Dateifreigaben. Standarddateifreigaben werden in der Speicherkontoart Universell Version 2 (GPv2) bereitgestellt. Weitere Informationen zur SLA finden Sie auf der Seite Vereinbarung zum Servicelevel für Azure (unter „Speicherkonto“). Standarddateifreigaben verwenden ein nutzungsbasiertes Bezahlungsmodell, das nutzungsbasierte Preise bietet. Mit der Zugriffsebene einer Dateifreigabe können Sie die Speicherkosten an IOPS-Kosten anpassen, um Ihre Gesamtrechnung zu optimieren:

  • Transaktionsoptimierte Dateifreigaben bieten die günstigsten Transaktionspreise für transaktionsintensive Workloads, die nicht die geringe Latenz benötigen, die Premium-Dateifreigaben bieten. Empfohlen beim Migrieren von Daten zu Azure Files.
  • Heiße Dateifreigaben bieten ausgewogene Speicher- und Transaktionspreise für Workloads, die ein gutes Maß an beidem aufweisen.
  • Kalte Dateifreigaben bieten die kosteneffizientesten Speicherpreise für speicherintensive Workloads.

Berücksichtigen Sie bei der Wahl einer Medienebene für Ihre Workload Ihre Leistungs- und Nutzungsanforderungen. Wenn Ihre Workload eine einstellige Latenzzeit erfordert oder Sie SSD-Speichermedien vor Ort verwenden, ist der Premium-Tarif wahrscheinlich die beste Lösung. Sollte eine geringe Latenz nicht so wichtig sein (etwa bei Teamfreigaben, die aus Azure lokal eingebunden oder unter Verwendung der Azure-Dateisynchronisierung lokal zwischengespeichert werden), bietet der Standardspeicher unter Umständen ein besseres Preis-Leistungs-Verhältnis.

Nachdem Sie eine Dateifreigabe in einem Speicherkonto erstellt haben, kann sie nicht mehr in für andere Speicherkontoarten exklusive Ebenen verschoben werden. Wenn Sie also beispielsweise eine transaktionsoptimierte Dateifreigabe in die Premium-Ebene verschieben möchten, müssen Sie eine neue Dateifreigabe in einem FileStorage-Speicherkonto erstellen und die Daten aus der ursprünglichen Freigabe in eine neue Dateifreigabe im FileStorage-Konto kopieren. Wir empfehlen die Verwendung von AzCopy, um Daten zwischen Azure-Dateifreigaben zu kopieren. Sie können aber auch Tools wie robocopy (Windows) oder rsync (macOS und Linux) verwenden.

Weitere Informationen finden Sie unter Grundlegendes zur Azure Files-Abrechnung.

Regionale Verfügbarkeit der Azure-Dateisynchronisierung

Informationen zur regionalen Verfügbarkeit finden Sie unter Verfügbare Produkte nach Region.

In den folgenden Regionen müssen Sie für die Azure-Dateisynchronisierung den Zugriff auf Azure Storage anfordern:

• Frankreich, Süden
• Südafrika, Westen
• VAE, Mitte

Führen Sie die Anweisungen in diesem Dokument aus, um den Zugriff für diese Regionen anzufordern.

Redundanz

Um die Daten in Ihren Azure-Dateifreigaben vor Datenverlusten oder Beschädigungen zu schützen, speichert Azure Files beim Schreiben mehrere Kopien der einzelnen Dateien. Je nach Ihren Anforderungen können Sie verschiedene Grade der Redundanz wählen. Azure Files unterstützt derzeit die folgenden Datenredundanzoptionen:

• Lokal redundanter Speicher (LRS) : Bei LRS wird jede Datei in einem Azure-Speichercluster dreimal gespeichert. Dies schützt vor Datenverlusten aufgrund von Hardwarefehlern, z. B. bei einem schadhaften Laufwerk. Bei einem Katastrophenfall wie einem Brand oder einer Überschwemmung in einem Rechenzentrum ist es jedoch möglich, dass alle Replikate in einem Speicherkonto mit LRS verloren gehen oder nicht mehr wiederhergestellt werden können.
• Zonenredundanter Speicher (ZRS): Mit ZRS werden drei Kopien jeder Datei gespeichert. Diese Kopien werden jedoch physisch in drei verschiedenen Speicherclustern in verschiedenen Azure-Verfügbarkeitszonen isoliert. Verfügbarkeitszonen sind eindeutige physische Standorte in einer Azure-Region. Jede Zone besteht aus mindestens einem Rechenzentrum, dessen Stromversorgung, Kühlung und Netzwerkbetrieb unabhängig funktionieren. Ein Schreibvorgang in den Speicher wird erst akzeptiert, wenn die Daten in allen drei Verfügbarkeitszonen in die Speichercluster geschrieben wurden.
• Georedundanter Speicher (GRS): Bei GRS verfügen Sie über zwei Regionen, eine primäre und eine sekundäre Region. Dateien werden dreimal in einem Azure-Speichercluster in der primären Region gespeichert. Schreibvorgänge werden asynchron in eine von Microsoft definierte sekundäre Region repliziert. GRS bietet sechs Kopien Ihrer Daten, die auf zwei Azure-Regionen verteilt sind. Bei einem größeren Notfall, z. B. dem permanenten Verlust einer Azure-Region aufgrund einer Naturkatastrophe oder eines ähnlichen Ereignisses, führt Microsoft ein Failover durch. In diesem Fall wird die sekundäre Region zur primären Region, die alle Vorgänge bedient. Weil die Replikation zwischen der primären und der sekundären Region asynchron ist, gehen die Daten, die noch nicht in die sekundäre Region repliziert wurden, bei einem größeren Notfall verloren. Sie können auch ein manuelles Failover eines georedundanten Speicherkontos ausführen.
• Geozonenredundanter Speicher (GZRS): Sie können sich GZRS wie ZRS vorstellen, jedoch mit Georedundanz. Bei GZRS werden Dateien dreimal in drei verschiedenen Speicherclustern in der primären Region gespeichert. Alle Schreibvorgänge werden dann asynchron in eine von Microsoft definierte sekundäre Region repliziert. Der Failoverprozess für GZRS funktioniert genauso wie bei GRS.

Standard-Azure-Dateifreigaben bis zu 5 TiB unterstützen alle vier Redundanztypen. Standarddateifreigaben über 5 TiB unterstützen nur LRS and ZRS. Azure-Premium-Dateifreigaben unterstützen nur LRS und ZRS.

Speicherkonten der universellen Version 2 (GPv2) bieten zwei weitere Redundanzoptionen, die Azure Files nicht unterstützt: georedundanter Speicher mit Lesezugriff (RA-GRS) und geozonenredundanter Speicher mit Lesezugriff (RA-GZRS). Sie können Azure-Dateifreigaben in Speicherkonten mit diesen Optionen bereitstellen, Azure Files unterstützt jedoch nicht das Lesen aus der sekundären Region. Azure-Dateifreigaben, die in RA-GRS- oder RA-GZRS-Speicherkonten bereitgestellt werden, werden als GRS bzw. GZRS abgerechnet.

Migration

Wenn Sie einen Windows-Dateiserver 2012R2 oder höher haben, kann die Azure-Dateisynchronisierung direkt installiert werden, ohne dass Daten auf einen neuen Server verschoben werden müssen. Wenn Sie im Rahmen der Einführung der Azure-Dateisynchronisierung die Migration auf einen neuen Windows-Dateiserver planen oder wenn sich Ihre Daten derzeit auf Network Attached Storage (NAS) befinden, gibt es mehrere mögliche Migrationsansätze, um Azure-Dateisynchronisierung mit diesen Daten zu nutzen. Welche Migrationsmethode Sie wählen sollten, ist vom derzeitigen Speicherort Ihrer Daten abhängig.

Eine ausführliche Anleitungen finden Sie im Artikel Übersicht über die Migration von Azure-Dateisynchronisierung und Azure-Dateifreigaben.

Virenschutz

Da für den Virenschutz Dateien auf bekannte Schadsoftware überprüft werden müssen, kann ein Virenschutzprodukt den Rückruf von Tieringdateien verursachen und damit zu hohen Ausgangsgebühren führen. Bei Tieringdateien wurde das sichere Windows-Attribut FILE_ATTRIBUTE_RECALL_ON_DATA_ACCESS festgelegt. Wir empfehlen, dass Sie bei Ihrem Softwareanbieter nachfragen, wie seine Lösung so konfiguriert werden kann, dass das Lesen von Dateien mit diesem festgelegten Attribut übersprungen wird (bei vielen geschieht dies automatisch).

Die internen Virenschutzlösungen von Microsoft – Windows Defender und System Center Endpoint Protection (SCEP) – überspringen beide automatisch das Lesen von Dateien, für die dieses Attribut festgelegt ist. Wir haben sie getestet und ein kleineres Problem identifiziert: Wenn Sie einer bestehenden Synchronisierungsgruppe einen Server hinzufügen, werden Dateien, die kleiner als 800 Byte sind, auf dem neuen Server zurückgerufen (heruntergeladen). Diese Dateien verbleiben auf dem neuen Server und werden nicht in Speicherebenen aufgeteilt, weil sie nicht die Größenanforderungen für das Tiering (>64 KB) erfüllen.

Backup

Wenn Cloudtiering aktiviert ist, sollten Lösungen, die den Server-Endpunkt oder eine VM, auf der sich der Server-Endpunkt befindet, direkt sichern, nicht verwendet werden. Cloudtiering bewirkt, dass nur eine Teilmenge der Daten auf dem Serverendpunkt gespeichert wird, während sich das vollständige Dataset in Ihrer Azure-Dateifreigabe befindet. Abhängig von der verwendeten Sicherungslösung werden mehrstufige Dateien entweder übersprungen und nicht gesichert (da für sie das Attribut FILE_ATTRIBUTE_RECALL_ON_DATA_ACCESS festgelegt ist), oder sie werden auf den Datenträger zurückgerufen, sodass hohe Gebühren für ausgehenden Datenverkehr anfallen. Es wird empfohlen, die Azure-Dateifreigabe direkt mithilfe einer Cloudsicherungslösung zu sichern. Weitere Informationen finden Sie unter Informationen zum Sichern von Azure-Dateifreigaben, oder wenden Sie sich an Ihren Sicherungsanbieter, um zu erfahren, ob dieser das Sichern von Azure-Dateifreigaben unterstützt.

Wenn Sie eine lokale Sicherungslösung verwenden möchten, sollten Sicherungen auf einem Server in der Synchronisierungsgruppe mit deaktivierter Cloudebene ausgeführt werden, und Sie sollten sicherstellen, dass keine mehrstufigen Dateien vorhanden sind. Wenn Sie eine Wiederherstellung durchführen, verwenden Sie die Wiederherstellungsoptionen auf Volume- oder Dateiebene. Mithilfe der Wiederherstellungsoption auf Dateiebene wiederhergestellte Dateien werden mit allen Endpunkten in der Synchronisierungsgruppe synchronisiert. Dabei werden vorhandene Dateien durch die aus der Sicherung wiederhergestellte Version ersetzt. Bei der Wiederherstellung auf Volumeebene werden die neueren Dateiversionen in der Azure-Dateifreigabe oder auf anderen Serverendpunkten nicht ersetzt.

Datenklassifizierung

Wenn Sie Datenklassifizierungssoftware installiert haben, kann die Aktivierung des Cloudtierings aus zwei Gründen zu höheren Kosten führen:

1. Wenn Cloudtiering aktiviert ist, werden die am häufigsten verwendeten (heißesten) Dateien lokal zwischengespeichert, und für die am seltensten verwendeten (kältesten) Dateien wird ein Tiering zur Azure-Dateifreigabe in der Cloud durchgeführt. Wenn Ihre Datenklassifizierung regelmäßig alle Dateien in der Dateifreigabe überprüft, müssen die Dateien, für die ein Tiering zur Cloud durchgeführt wurde, bei jeder Überprüfung abgerufen werden.

2. Wenn die Datenklassifizierungssoftware die Metadaten im Datenstrom einer Datei verwendet, muss die Datei vollständig abgerufen werden, damit die Software die Klassifizierung erkennen kann.

Diese Erhöhung der Anzahl von Abrufen sowie der abgerufenen Datenmenge kann zu höheren Kosten führen.

Updaterichtlinie für den Azure-Dateisynchronisierungs-Agent

Der Azure-Dateisynchronisierungs-Agent wird regelmäßig aktualisiert, um neue Funktionalität hinzuzufügen und Probleme zu beheben. Wir empfehlen, den Agent für die Azure-Dateisynchronisierung zu aktualisieren, sobald neue Versionen verfügbar sind.

Unterschiede zwischen Haupt- und Nebenversionen des Agents

• Hauptversionen des Agents enthalten oft neue Features und haben eine aufsteigende Zahl als ersten Teil der Versionsnummer. Beispiel: 17.0.0.0
• Nebenversionen des Agents werden auch als „Patches“ bezeichnet und werden häufiger veröffentlicht als Hauptversionen. Sie enthalten oft Fehlerbehebungen und kleinere Verbesserungen, aber keine neuen Features. Beispiel: 17.2.0.0

Upgradepfade

Es gibt fünf bewährte und getestete Wege, um die Updates des Azure-Dateisynchronisierungs-Agents zu installieren.

1. Verwenden Sie das Feature für automatische Upgrades des Agents für die Azure-Dateisynchronisierung, um Agent-Updates zu installieren. Der Azure-Dateisynchronisierungs-Agent führt automatisch ein Upgrade durch. Sie können wählen, ob Sie die neueste Version des Agents installieren möchten, wenn sie verfügbar ist, oder ob Sie ein Update durchführen möchten, wenn der aktuell installierte Agent bald abläuft. Weitere Informationen finden Sie unter Automatische Agent-Lebenszyklusverwaltung.
2. Konfigurieren Sie Microsoft Update zum automatischen Herunterladen und Installieren von Agent-Updates. Es wird empfohlen, jedes Azure-Dateisynchronisierungsupdate auszuführen, um sicherzustellen, dass Sie Zugriff auf die neuesten Fehlerbehebungen für den Server-Agent haben. Mit Microsoft Update ist dies ein nahtloser Prozess, da Updates automatisch für Sie heruntergeladen und installiert werden.
3. Verwenden von AfsUpdater.exe zum Herunterladen und Installieren von Agent-Updates. Die AfsUpdater.exe befindet sich im Installationsverzeichnis für den Agent. Doppelklicken Sie auf die ausführbare Datei, um Agent-Updates herunterzuladen und zu installieren. Je nach Releaseversion müssen Sie den Server möglicherweise neu starten.
4. Patchen Sie einen vorhandenen Azure-Dateisynchronisierungs-Agent mithilfe einer Microsoft Update-Patchdatei oder einer ausführbaren MSP-Datei. Das neueste Updatepaket für die Azure-Dateisynchronisierung kann aus dem Microsoft Update-Katalog heruntergeladen werden. Wenn Sie eine ausführbare MSP-Datei verwenden, wird Ihre Installation der Azure-Dateisynchronisierung mit der gleichen Methode aktualisiert, die auch von Microsoft Update automatisch verwendet wird. Das Anwenden eines Microsoft Update-Patches führt ein direktes Upgrade einer Azure-Dateisynchronisierungsinstallation aus.
5. Laden Sie das Installationsprogramm für den neuesten Azure-Dateisynchronisierungs-Agent aus dem Microsoft Download Center herunter. Um eine bestehende Installation des Azure-Dateisynchronisierungs-Agents zu aktualisieren, deinstallieren Sie die ältere Version und installieren Sie dann die neueste Version mit dem heruntergeladenen Installationsprogramm. Die Serverregistrierung, Synchronisierungsgruppen und alle anderen Einstellungen werden vom Installationsprogramm für die Azure-Dateisynchronisierung beibehalten.

Automatische Agent-Lebenszyklusverwaltung

Der Azure-Dateisynchronisierungs-Agent führt automatisch ein Upgrade durch. Sie können einen von zwei Modi auswählen und ein Wartungsfenster angeben, in dem das Upgrade auf dem Server durchgeführt werden soll. Diese Funktion soll Sie bei der Agent-Lebenszyklusverwaltung unterstützen, indem entweder verhindert wird, dass der Agent abläuft, oder eine problemlose aktuelle Einstellung ermöglicht wird.

1. Mit der Standardeinstellung wird versucht zu verhindern, dass der Agent abläuft. Innerhalb von 21 Tagen vor dem angegebenen Ablaufdatum des Agents versucht der Agent, ein Selbstupgrade durchzuführen. Er versucht, das Upgrade einmal pro Woche innerhalb von 21 Tagen vor dem Ablauf und im ausgewählten Wartungsfenster durchzuführen. Unabhängig von dieser Option müssen weiterhin reguläre Microsoft Update-Patches durchgeführt werden.
2. Optional können Sie auswählen, dass der Agent automatisch ein Selbstupgrade durchführt, wenn eine neue Agent-Version verfügbar ist (derzeit nicht auf gruppierte Server anwendbar). Dieses Update erfolgt auch während des ausgewählten Wartungsfensters, sodass neue Funktionen und Verbesserungen auf dem Server genutzt werden können, sobald sie allgemein verfügbar sind. Dies ist die empfohlene Einstellung, über die Agent-Hauptversionen sowie reguläre Updatepatches auf dem Server bereitgestellt werden. Jeder veröffentlichte Agent hat GA-Qualität. Wenn Sie diese Option auswählen, erhalten Sie von Microsoft die neueste Agent-Version als Flight. Gruppierte Server sind ausgeschlossen. Nach Abschluss des Test-Flighting steht der Agent auch auf der Microsoft Update-Website und im Microsoft Download Center zur Verfügung.

Ändern der Einstellung für automatische Upgrades

Die folgenden Anweisungen beschreiben, wie Sie die Einstellungen nach Abschluss des Installationsprogramms ändern können, wenn dies erforderlich ist.

Öffnen Sie eine PowerShell-Konsole, und navigieren Sie zu dem Verzeichnis, in dem Sie den Synchronisierungs-Agent installiert haben. Importieren Sie dann die Server-Cmdlets. Dies sieht üblicherweise etwa wie folgt aus:

cd 'C:\Program Files\Azure\StorageSyncAgent'
Import-Module -Name .\StorageSync.Management.ServerCmdlets.dll

Sie können Get-StorageSyncAgentAutoUpdatePolicy ausführen, um die aktuelle Richtlinieneinstellung zu überprüfen und festzustellen, ob Sie sie ändern möchten.

Um die aktuelle Richtlinieneinstellung auf das Modell verzögerter Updates umzustellen, können Sie folgenden Befehl verwenden:

Set-StorageSyncAgentAutoUpdatePolicy -PolicyMode UpdateBeforeExpiration

Um die aktuelle Richtlinieneinstellung auf das Modell sofortiger Updates umzustellen, können Sie folgenden Befehl verwenden:

Set-StorageSyncAgentAutoUpdatePolicy -PolicyMode InstallLatest -Day <day> -Hour <hour>

Garantien zu Agent-Lebenszyklus und Änderungsverwaltung

Die Azure-Dateisynchronisierung ist ein Clouddienst, über den kontinuierlich neue Funktionen und Verbesserungen eingeführt werden. Dies bedeutet, dass eine bestimmte Version des Azure-Dateisynchronisierungs-Agents nur für eine begrenzte Zeit unterstützt werden kann. Für eine einfachere Bereitstellung gelten die folgenden Regeln, damit sichergestellt ist, dass Sie genügend Zeit haben und benachrichtigt werden, um Updates und Upgrades von Agents in Ihrem Änderungsverwaltungsprozess zu berücksichtigen:

• Die Hauptversionen des Agents werden für mindestens sechs Monate ab dem Datum der Erstveröffentlichung unterstützt.
• Eine Überlappung von mindestens drei Monaten bei der Unterstützung der Agent-Hauptversionen wird garantiert.
• Warnungen werden für registrierte Server ausgegeben, die einen bald ablaufenden Agent mindestens drei Monate vor Ablauf verwenden. Ob ein registrierter Server eine ältere Version des Agents verwendet, können Sie im Abschnitt „Registrierte Server“ eines Speichersynchronisierungsdiensts überprüfen.
• Die Lebensdauer einer Nebenversion des Agents hängt von der zugehörigen Hauptversion ab. Wenn beispielsweise die Agent-Version 17.0.0.0 auf „ablaufen“ festgelegt wird, werden alle Agent-Versionen 17.*.*.* gleichzeitig auf „ablaufen“ festgelegt.

Nächste Schritte

• Berücksichtigen von Firewall- und Proxyeinstellungen
• Bereitstellen von Azure Files
• Bereitstellen der Azure-Dateisynchronisierung
• Überwachen der Azure-Dateisynchronisierung