Planung für die Bereitstellung einer Azure-Dateisynchronisierung

Interview and demo introducing Azure File Sync - click to play!

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: Da 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, erfordert die Bereitstellung für Produktionsszenarien keine Verwaltung eines Dateiservers oder NAS-Geräts. 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 deren 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.

Wichtig

Sie können Änderungen am Namespace jedes beliebigen Cloud- oder Serverendpunkts in der Synchronisierungsgruppe vornehmen und Ihre Dateien mit den anderen Endpunkten in der Synchronisierungsgruppe synchronisieren lassen. Wenn Sie eine Änderung direkt am Cloudendpunkt (Azure-Dateifreigabe) vornehmen, müssen Änderungen zunächst von einem Azure-Dateisynchronisierungsauftrag zum Erkennen von Änderungen entdeckt werden. Ein Auftrag zum Erkennen von Änderungen für einen Cloudendpunkt wird nur einmal alle 24 Stunden gestartet. Weitere Informationen finden Sie unter Häufig gestellte Fragen zu Azure Files.

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 für ihn 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 zu planen, was Sie auf einem lokalen Server synchronisieren werden, bei dem die Azure-Dateifreigabe verwendet wird. Durch das Erstellen eines Plans 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.

Tipp

Wenn Sie nicht wissen, wie viele Dateien und Ordner Sie besitzen, kann z. B. das Tool TreeSize von der JAM Software GmbH für Sie hilfreich sein.

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.

    Eine Azure-Dateifreigabe vom Standardtyp kann theoretisch die maximale Leistung abdecken, die ein Speicherkonto bereitstellen kann. Das Platzieren mehrerer Freigaben in einem einzelnen Speicherkonto bedeutet, dass Sie einen freigegebenen Pool mit IOPS und Durchsatz für diese Freigaben erstellen. Wenn Sie die Azure-Dateisynchronisierung nur an diese Dateifreigaben anfügen möchten, wird durch das Gruppieren mehrerer Azure-Dateifreigaben im selben Speicherkonto kein Problem verursacht. Prüfen Sie die Leistungsziele der Azure-Dateifreigabe, um präzisere Erkenntnisse über die relevanten Metriken zu erhalten. Diese Einschränkungen gelten nicht für Storage Premium, bei dem die Leistung für jede Freigabe explizit bereitgestellt und garantiert wird.

    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.

Tipp

Auf Grundlage dieser Informationen ist es oft erforderlich, mehrere Ordner der obersten Ebene auf Ihren Volumes in einem neuen gemeinsamen Stammverzeichnis zu gruppieren. Anschließend synchronisieren Sie dieses neue Stammverzeichnis und alle darin gruppierten Ordner mit einer einzelnen Azure-Dateifreigabe. Diese Vorgehensweise ermöglicht es Ihnen, den Grenzwert für die Synchronisierung von 30 Azure-Dateifreigaben pro Server einzuhalten.

Diese Gruppierung unter einem gemeinsamen Stamm hat keine Auswirkung auf den Datenzugriff. Ihre Zugriffssteuerungslisten (ACLs) bleiben unverändert. Sie müssen lediglich Freigabepfade (wie SMB- oder NFS-Freigaben) anpassen, die möglicherweise für die lokalen Serverordner bestehen und die Sie nun in einen gemeinsamen Stamm geändert haben. Ansonsten ändert sich nichts.

Wichtig

Der wichtigste Skalierungsvektor für die Azure-Dateisynchronisierung ist die Anzahl der Elemente (Dateien und Ordner), die synchronisiert werden müssen. Weitere Informationen finden Sie in Skalierbarkeitsziele für die Azure-Dateisynchronisierung.

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.

Erstellen einer Zuordnungstabelle

Diagram that shows an example of a mapping table. Download the following file to experience and use the content of this image.

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.


Excel icon that sets the context for the download. 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 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 2022 Azure, Datacenter, Standard und IoT Vollständig und Core
Windows Server 2019 Datacenter, Standard und IoT Vollständig und Core
Windows Server 2016 Datacenter, Standard und Storage Server Vollständig und Core
Windows Server 2012 R2 Datacenter, Standard und Storage Server Vollständig und Core

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

Wichtig

Es wird empfohlen, alle Servercomputer, die für die Azure-Dateisynchronisierung verwendet werden, mit den neuesten Updates von Windows Update auf dem neuesten Stand zu halten.

Mindestens erforderliche Systemressourcen

Für die Azure-Dateisynchronisierung ist entweder ein physischer oder ein virtueller Server mit mindestens einer CPU und mindestens 2 GiB Arbeitsspeicher erforderlich.

Wichtig

Wenn der Server auf einem virtuellen Computer ausgeführt wird, für den dynamischer Arbeitsspeicher aktiviert ist, muss der virtuelle Computer mit mindestens 2048 MiB Arbeitsspeicher konfiguriert werden.

Bei den meisten Produktionsworkloads empfiehlt es sich nicht, einen Azure-Dateisynchronisierungsserver nur mit den Mindestanforderungen zu konfigurieren. Weitere Informationen finden Sie unter Empfohlenen 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. Dabei beträgt die durchschnittliche Dateigröße 512 KiB. 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 Verzeichnissen wird zurzeit nicht empfohlen. Dies ist eine weiche Einschränkung basierend auf unseren getesteten Schwellenwerten. Weitere Informationen finden Sie unter Skalierbarkeitsziele für die Azure-Dateisynchronisierung.

Tipp

Die Erstsynchronisierung eines Namespace ist ein aufwendiger Vorgang. Es wird daher empfohlen, bis zum Abschluss der Erstsynchronisierung mehr Arbeitsspeicher zuzuordnen. Dies ist nicht zwingend erforderlich, kann jedoch die Erstsynchronisierung beschleunigen.

Eine normale Änderung umfasst 0,5 % des Namespace pro Tag. Wenn bei Ihnen mehr Änderungen auftreten, sollten Sie weitere CPUs hinzufügen.

  • Ein lokal angeschlossenes Volume, das mit dem NTFS-Dateisystem formatiert ist

Auswertungs-Cmdlet

Vor der Bereitstellung der Azure-Dateisynchronisierung müssen Sie mit dem Auswertungs-Cmdlet für die Azure-Dateisynchronisierung auswerten, ob Kompatibilität mit Ihrem System gegeben 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 durchgehen, 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, das 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 Vollständig unterstützt.
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 Klassifizierungstags, die von der Dateiklassifizierungsinfrastruktur erstellt werden, 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

Ü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 verwenden 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

Der von Tieringdateien belegte Speicherplatz wird von NTFS zugeordnet. Aus diesem Grund wird er auf keiner Benutzeroberfläche angezeigt. 3. Synchronisierungsmetadaten nehmen eine Clustergröße pro Element ein. (1 Million Dateien + 100.000 Verzeichnisse) · 4 KB Clustergröße = 4.400.000 KiB (4,4 GiB) 4. 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) 5. 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.
  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 Vomlume, CSV) und lokalen Datenträgern nicht unterstützt.

Hinweis

Der Azure-Dateisynchronisierungs-Agent muss auf jedem Knoten in einem Failovercluster installiert sein, damit die Synchronisierung ordnungsgemäß funktioniert.

Datendeduplizierung

Windows Server 2016 und Windows Server 2019
Die Datendeduplizierung wird unter Windows Server 2016 und Windows Server 2019 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. Ihre Daten in der Azure-Dateifreigabe werden nicht dedupliziert.

Hinweis

Zur Unterstützung der Datendeduplizierung auf Volumes mit aktiviertem Cloudtiering unter Windows Server 2019 muss das Windows-Update KB4520062: Oktober 2019 oder ein neueres monatliches Rollup-Update installiert und mindestens die Version 12.0.0.0 des Agents für die Azure-Dateisynchronisierung vorhanden sein.

Windows Server 2012 R2
Datendeduplizierung und Cloudtiering auf demselben Volume unter Windows Server 2012 R2 werden 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.
  • Wenn die Datei nicht bereits umgelagert 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 oder Windows Server 2019 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 oder Windows Server 2019) 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 auf DFS-N-Servern vollständig unterstützt. Sie können den Azure-Dateisynchronisierungs-Agent auf einem oder mehreren DFS-N-Membern installieren, um Daten zwischen den Serverendpunkten und dem Cloudendpunkt zu synchronisieren. Weitere Informationen finden Sie unter Übersicht über DFS-Namespaces.

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 Azure-Dateisynchronisierungsbereitstellung. 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. Die Überschneidung mehrerer Serverendpunkte mit anderen aktiven DFS-R-Standorten kann 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.

Wenn auf einem Serverendpunkt Cloudtiering aktiviert ist, werden Tieringdateien in der Windows-Suche übersprungen und nicht indiziert. Dateien ohne Tiering werden ordnungsgemäß indiziert.

Hinweis

Windows-Clients werden beim Durchsuchen der Dateifreigabe zurückrufen, wenn auf dem Clientcomputer die Einstellung Immer nach Dateinamen und Inhalten suchen aktiviert ist. Diese Einstellung ist standardmäßig deaktiviert.

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 bislang über keine Änderungsmitteilungen oder Journalfunktion, sodass es keine Möglichkeit gibt, eine Synchronisierungssitzung automatisch zu initiieren, sobald Dateien geändert werden. Unter Windows Server verwendet die Azure-Dateisynchronisierung das Windows-USN-Journaling, um eine Synchronisierungssitzung bei einer Datenänderung automatisch zu starten.

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.

Identity

Die Azure-Dateisynchronisierung funktioniert mit Ihrer AD-basierten Standardidentität, ohne dass ein besonderes Setup über das Einrichten der Synchronisierung hinaus erforderlich ist. Wenn Sie Azure-Dateisynchronisierung verwenden, besteht die allgemeine Erwartung darin, dass die meisten Zugriffe die Azure-Dateisynchronisierungs-Cacheserver und nicht die Azure-Dateifreigabe durchlaufen. 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 Änderungen, die direkt an der Azure-Dateifreigabe vorgenommen werden, für die Synchronisierung mit den Serverendpunkten in der Synchronisierungsgruppe länger dauern, können Sie dennoch sicherstellen, dass Sie Ihre AD-Berechtigungen für Ihre Dateifreigabe auch direkt in der Cloud erzwingen 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.

Wichtig

Der Domänenbeitritt Ihres Speicherkontos zu Active Directory ist für die erfolgreiche Bereitstellung der Azure-Dateisynchronisierung nicht erforderlich. Dies ist ein streng optionaler Schritt, der es der Azure-Dateifreigabe ermöglicht, lokale ACLs zu erzwingen, wenn Benutzer die Azure-Dateifreigabe direkt einbinden.

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 müssen Sie möglicherweise eine restriktivere Kommunikation mit Azure erzwingen. Daher bietet die Azure-Dateisynchronisierung verschiedene Möglichkeiten, Netzwerke zu konfigurieren. 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.

Wichtig

Die Azure-Dateisynchronisierung unterstützt kein Internetrouting. Die Standardoption für das Netzwerkrouting (Microsoft-Routing) wird jedoch von der Azure-Dateisynchronisierung unterstützt.

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, da 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 zu verhindern, um nicht autorisierte Lese- und Schreibvorgänge für Ihre Daten auszuführen. 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. Einige Anwendungen können dies nativ ausführen. Dies ist jedoch in der Regel 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

Hinweis

Die Unterstützung für TLS 1.0 und 1.1 im Azure-Dateisynchronisierungsdienst wird am 1. August 2020 entfernt. Alle unterstützten Versionen des Azure-Dateisynchronisierungs-Agents verwenden standardmäßig bereits TLS 1.2. Die Verwendung einer früheren Version von TLS kann auftreten, wenn TLS 1.2 auf dem Server deaktiviert wurde oder ein Proxy verwendet wird. Wenn Sie einen Proxy verwenden, sollten Sie die Proxykonfiguration überprüfen. Alle Regionen für den Azure-Dateisynchronisierungsdienst, die nach dem 01.05.2020 hinzugefügt werden, unterstützen ausschließlich TLS 1.2. Die Unterstützung für TLS 1.0 und 1.1 wird in den vorhandenen Regionen am 1. August 2020 entfernt. Weitere Informationen finden Sie im Leitfaden zur Problembehandlung.

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 vier verschiedene Speicherebenen (Premium, transaktionsoptimiert, heiße Ebene und kalte Ebene), sodass Sie Ihre Freigaben an die Leistungs- und Preisanforderungen Ihres jeweiligen Szenarios anpassen können:

  • Premium: Premium-Dateifreigaben basieren auf 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.
  • Transaktionsoptimiert: Transaktionsoptimierte Dateifreigaben ermöglichen die Verwendung transaktionsintensiver Workloads, die nicht auf die Wartezeit von Premium-Dateifreigaben angewiesen sind. Transaktionsoptimierte Dateifreigaben werden auf Standardspeicherhardware angeboten, die auf Festplattenlaufwerken (Hard Disk Drives, HDDs) basiert. „Transaktionsoptimiert“ wurde in der Vergangenheit „Standard“ genannt. Dies bezieht sich jedoch auf den Speichermedientyp und nicht auf die Ebene selbst. (Die heiße und die kalte Ebene sind ebenfalls Standardebenen, da sie auf Standardspeicherhardware basieren.)
  • Hot: Heiße Dateifreigaben verfügen über Speicher, der für universelle Dateifreigabeszenarien optimiert ist, z. B. Teamfreigaben. Heiße Dateifreigaben werden auf HDD-basierter Standardspeicherhardware angeboten.
  • Cool: Kalte Dateifreigaben bieten kostengünstigen Speicher, der für Speicherszenarien mit Onlinearchiv optimiert ist. Kalte Dateifreigaben werden auf HDD-basierter Standardspeicherhardware angeboten.

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. Standarddateifreigaben (einschließlich transaktionsoptimierter, heißer und kalter Dateifreigaben) werden im Speicherkonto vom Typ „Allgemein v2“ (GPv2) mit nutzungsbasierter Bezahlung bereitgestellt.

Berücksichtigen Sie bei der Wahl einer Speicherebene für Ihre Workload Ihre Leistungs- und Nutzungsanforderungen. Wenn Ihre Workload Latenz im einstelligen Bereich erfordert oder Sie lokale SSD-Speichermedien verwenden, ist wahrscheinlich der Premium-Tarif die beste Wahl. 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.

Im Rahmen von GPv2-Speicherkonten bereitgestellte Dateifreigaben können zwischen den Standardebenen (transaktionsoptimiert, heiß und kalt) verschoben werden, ohne ein neues Speicherkonto zu erstellen und Daten zu migrieren. Durch die Änderung der Ebene fallen jedoch Transaktionskosten an. Wenn Sie eine Freigabe von einer heißeren in eine kältere Ebene verschieben, werden Ihnen für jede Datei in der Freigabe die Schreibtransaktionskosten der kälteren Ebene berechnet. Wenn Sie eine Dateifreigabe von einer kälteren in eine heißere Ebene verschieben, werden Ihnen für jede Datei in der Freigabe die Lesetransaktionskosten der kalten Ebene berechnet.

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

Regionale Verfügbarkeit

Für Standarddateifreigaben mit einer Kapazität von 100 TiB gelten bestimmte Einschränkungen.

  • Derzeit werden nur LRS-Konten (Locally Redundant Storage, lokal redundanter Speicher) und ZRS-Konten (Zone Redundant Storage, zonenredundanter Speicher) unterstützt.
  • Nach der Aktivierung großer Dateifreigaben können Sie Speicherkonten nicht in GRS-Konten (Geo-Redundant Storage, georedundanter Speicher) oder in GZRS-Konten (Geo-Zone Redundant Storage, geozonenredundanter Speicher) konvertieren.
  • Die Aktivierung großer Dateifreigaben kann nicht rückgängig gemacht werden.

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, werden für alle Azure-Dateifreigaben beim Schreiben mehrere Kopien der einzelnen Dateien gespeichert. Abhängig von den Anforderungen Ihrer Workload können Sie zusätzliche Redundanzgrade auswä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 in einem Rechenzentrum (Feuer, Überschwemmung usw.) gehen jedoch eventuell alle Replikate in einem Speicherkonto, das LRS verwendet, verloren oder können nicht mehr wiederhergestellt werden.
  • Zonenredundanter Speicher (ZRS) : Bei 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, sodass das sekundäre Replikat zum primären Replikat wird, das für alle Vorgänge verwendet wird. Da 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.

Standardmäßige 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 des Typs Universell v2 bieten zwei zusätzliche Redundanzoptionen, die nicht von Azure Files unterstützt werden: georedundanter Speicher mit Lesezugriff, häufig als RA-GRS bezeichnet, und geozonenredundanter Speicher mit Lesezugriff, häufig als RA-GZRS bezeichnet. 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 georedundanten oder geozonenredundanten Speicherkonten mit Lesezugriff bereitgestellt werden, werden als georedundanter bzw. geozonenredundanter Speicher abgerechnet.

Wichtig

Georedundanter und geozonenredundanter Speicher können ein manuelles Failover des Speichers in die sekundäre Region durchführen. Es wird empfohlen, so nicht außerhalb eines Notfalls vorzugehen, wenn Sie Azure-Dateisynchronisierung verwenden, weil die Wahrscheinlichkeit von Datenverlusten hoch ist. Bei einem Notfall, bei dem Sie ein manuelles Failover des Speichers initiieren möchten, müssen Sie eine Supportanfrage bei Microsoft öffnen, damit die Azure-Dateisynchronisierung die Synchronisierung mit dem sekundären Endpunkt fortsetzt.

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 die Migration auf einen neuen Windows-Dateiserver im Rahmen der Einführung der Azure-Dateisynchronisierung planen oder wenn Ihre Daten zurzeit im Network Attached Storage (NAS) gespeichert sind, gibt es mehrere mögliche Migrationsansätze für die Azure-Dateisynchronisierung mit diesen Daten. Welche Migrationsmethode Sie wählen sollten, ist abhängig vom derzeitigen Speicherort Ihrer Daten.

Im Artikel Übersicht über die Migration von Azure-Dateisynchronisierung und Azure-Dateifreigaben finden Sie ausführliche Anleitungen für Ihr Szenario.

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. Ab Version 4.0 der Azure-Dateisynchronisierung-Agents ist für mehrstufige Dateien das sichere Windows-Attribut „FILE_ATTRIBUTE_RECALL_ON_DATA_ACCESS“ festgelegt. Es empfiehlt es sich, bei Ihrem Softwareanbieter nachzufragen, wie die Lösung so konfiguriert werden kann, dass das Lesen von Dateien mit diesem festgelegten Attribut übersprungen wird (bei vielen ist dies automatisch der Fall).

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, da sie nicht die Größenanforderungen für das Tiering (> 64 KB) erfüllen.

Hinweis

Anbieter von Antivirensoftware können die Kompatibilität zwischen ihrem Produkt und der Azure-Dateisynchronisierung mithilfe der Azure File Sync Antivirus Compatibility Test Suite überprüfen, die aus dem Microsoft Download Center heruntergeladen werden kann.

Backup

Wenn Cloudtiering aktiviert ist, sollten keine Lösungen verwendet werden, die den Serverendpunkt oder einen virtuellen Computer, auf dem sich der Serverendpunkt befindet, direkt sichern. 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 Ausgangsgebühren 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 bevorzugen, sollten die Sicherungen auf einem Server in der Synchronisierungsgruppe ausgeführt werden, auf dem das Cloudtiering deaktiviert ist. Wenn Sie eine Wiederherstellung durchführen, verwenden Sie die Wiederherstellungsoptionen auf Volume- oder Dateiebene. Mithilfe der Wiederherstellungsoption auf Dateiebene wiederhergestellte Dateien werden auf 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.

Warnung

Wenn Sie Robocopy /B mit einem Azure-Dateisynchronisierung-Agent verwenden müssen, der entweder auf dem Quell- oder Zielserver ausgeführt wird, führen Sie ein Upgrade auf Version v12.0 oder höher des Azure-Dateisynchronisierung-Agents durch. Die Verwendung von Robocopy /B mit Agent-Versionen unter v12.0 führt beim Kopieren zur Beschädigung mehrstufiger Dateien.

Hinweis

Bare-Metal-Recovery (BMR) kann zu unerwarteten Ergebnissen führen und wird derzeit nicht unterstützt.

Hinweis

Bei Version 9 des Azure-Dateisynchronisierungs-Agents werden VSS-Momentaufnahmen (einschließlich der Registerkarte „Vorherige Versionen“) jetzt auf Volumes mit aktiviertem Cloudtiering unterstützt. Allerdings müssen Sie die vorherige Versionskompatibilität über PowerShell aktivieren. Weitere Informationen.

Datenklassifizierung

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

  1. Wenn Cloudtiering aktiviert ist, werden Ihre heißesten Dateien lokal zwischengespeichert, und für die 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. Es wird empfohlen, Microsoft Update zu konfigurieren, um Updates für den Azure-Dateisynchronisierungs-Agent zu erhalten, wenn diese 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: *2.*.**
  • 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: **.3.**

Upgradepfade

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

  1. (Bevorzugt) Konfigurieren Sie Microsoft Update zum automatischen Herunterladen und Installieren von Agent-Updates.
    Es wird stets 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.
  2. 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.
  3. 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 im vorherigen Upgradepfad verwendet wird. Das Anwenden eines Microsoft Update-Patches führt ein direktes Upgrade einer Azure-Dateisynchronisierungsinstallation aus.
  4. Laden Sie 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

Mit Agent-Version 6 wurde vom Team für die Dateisynchronisierung eine Funktion für automatische Upgrades für den Agent eingeführt. 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 der Test-Flight-Phase steht der Agent auch im Microsoft Download Center (aka.ms/AFS/agent) 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

Garantien zu Agent-Lebenszyklus und Änderungsverwaltung

Die Azure-Dateisynchronisierung ist ein Clouddienst, über den neue Funktionen und Verbesserungen kontinuierlich 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 3.0 freigegeben wird, werden alle Agent-Versionen 2.* gleichzeitig ablaufen.

Hinweis

Bei der Installation einer Agent-Version mit einer Ablaufmeldung wird zwar eine Warnung angezeigt, sie ist aber dennoch erfolgreich. Der Versuch einer Installation oder Verbindung mit einer abgelaufenen Agent-Version wird nicht unterstützt und wird daher blockiert.

Nächste Schritte