Freigeben über

Migration von Linux zu einer Hybrid-Cloud-Bereitstellung mit der Azure-Dateisynchronisierung

  • Artikel

Dieser Artikel zur Migration ist einer von mehreren Artikeln im Zusammenhang mit den Schlüsselwörtern „NFS“ und „Azure-Dateisynchronisierung“. Überprüfen Sie, ob dieser Artikel für Ihr Szenario zutrifft:

  • Datenquelle: Network Attached Storage (NAS)
  • Migrationsroute: Linux-Server mit SAMBA ⇒ Windows Server 2012R2 oder höher ⇒ Synchronisierung mit Azure-Dateifreigabe(n)
  • Lokales Zwischenspeichern von Dateien: Ja, das endgültige Ziel ist eine Azure-Dateisynchronisierung-Bereitstellung.

Wenn Ihr Szenario anders ist, sehen Sie sich die Tabelle mit Migrationsleitfäden an.

Die Azure-Dateisynchronisierung arbeitet auf Windows Server-Instanzen mit direkt angeschlossenem Speicher. Die Synchronisierung mit und von Linux-Clients, SMB-Remotefreigaben (Server Message Block) oder NFS-Freigaben (Network File System) wird nicht unterstützt.

Wenn Sie Ihre Dateidienste in eine Hybridbereitstellung umwandeln, wird daher eine Migration zu Windows Server erforderlich. Dieser Artikel führt Sie durch die Planung und Durchführung einer solchen Migration.

Gilt für:

Dateifreigabetyp SMB NFS
Standard-Dateifreigaben (GPv2), LRS/ZRS Ja Nein
Standard-Dateifreigaben (GPv2), GRS/GZRS Ja Nein
Premium-Dateifreigaben (FileStorage), LRS/ZRS Ja Nein

Migrationsziele

Das Ziel besteht darin, Freigaben auf Ihrem Linux-Samba-Server auf eine Windows Server-Instanz zu verschieben. Anschließend soll die Azure-Dateisynchronisierung für eine Hybrid Cloud-Bereitstellung verwendet werden. Diese Migration muss so erfolgen, dass die Integrität der Produktionsdaten und die Verfügbarkeit während der Migration gewährleistet wird. Letzteres erfordert minimale Ausfallzeiten, damit sie in normalen Wartungsfenstern stattfinden kann oder diese nur geringfügig überschreitet.

Übersicht zur Migration

Wie im Artikel mit der Migrationsübersicht zu Azure Files beschrieben wird, ist es wichtig, das richtige Kopiertool und den richtigen Ansatz zu verwenden. Ihr Linux-Samba-Server macht SMB-Freigaben direkt in Ihrem lokalen Netzwerk verfügbar. Das in Windows Server integrierte Tool Robocopy bietet die beste Methode, Ihre Dateien in diesem Migrationsszenario zu verschieben.

Wenn Sie Samba nicht auf Ihrem Linux-Server ausführen und stattdessen Ordner zu einer Hybridbereitstellung unter Windows Server migrieren möchten, können Sie anstelle von Robocopy die Linux-Kopiertools verwenden. Beachten Sie die Genauigkeitsfunktionen Ihres Kopiertools. Lesen Sie den Abschnitt über Grundlagen zur Migration im Artikel zur Übersicht über die Migration, um zu erfahren, worauf Sie bei einem Kopiertool achten müssen.

Phase 1: Ermitteln der Anzahl der benötigten Azure-Dateifreigaben

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.

    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.

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.

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

Darstellung eines Beispiels für eine Zuordnungstabelle. Laden Sie die folgende Datei herunter, um den Inhalt dieser Abbildung kennenzulernen und zu verwenden.

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-Symbol, das den Kontext für den Laden festlegt. Laden Sie eine Namespace-Zuordnungsvorlage herunter.

Phase 2: Lokales Bereitstellen einer geeigneten Windows Server-Instanz

  • Erstellen Sie eine Instanz von Windows Server 2022 als virtuellen Computer oder physischen Server. Es ist mindestens Windows Server 2012 R2 erforderlich. Ein Windows Server-Failovercluster wird ebenfalls unterstützt.

  • Stellen Sie einen direkt angeschlossenen Speicher bereit, oder fügen Sie ihn hinzu. NAS (Network-Attached Storage) wird nicht unterstützt.

    Die bereitgestellte Speichermenge kann kleiner sein als jene, die Sie zurzeit auf Ihrem Linux-Samba-Server verwenden, wenn Sie das Cloudtiering-Feature der Azure-Dateisynchronisierung verwenden.

Die bereitgestellte Speichermenge kann kleiner sein als diejenige, die Sie zurzeit auf Ihrem Linux-Samba-Server verwenden. Diese Konfigurationsoption erfordert, dass Sie auch das Feature Cloudtiering der Azure-Dateisynchronisierung verwenden. Wenn Sie jedoch Ihre Dateien in einer späteren Phase aus dem größeren Linux-Samba-Serverbereich in das kleinere Windows Server-Volume kopieren, müssen Sie in Batches arbeiten:

  1. Verschieben Sie eine Dateimenge, die auf den Datenträger passt.
  2. Lassen Sie die Dateisynchronisierung und das Cloudtiering interagieren.
  3. Wenn mehr freier Speicherplatz auf dem Volume geschaffen wurde, fahren Sie mit dem nächsten Dateibatch fort. Überprüfen Sie alternativ den RoboCopy-Befehl im Abschnitt „RoboCopy“ weiter unten zur Verwendung des neuen Switches /LFSM. Die Verwendung von /LFSM kann Ihre RoboCopy-Aufträge erheblich vereinfachen, ist aber mit einigen anderen RoboCopy-Switches nicht kompatibel, von denen Sie möglicherweise abhängig sind.

Sie können diesen Batchverarbeitungsansatz vermeiden, indem Sie auf der Windows Server-Instanz den entsprechenden Speicherplatz bereitstellen, den Ihre Dateien auf dem Linux-Samba-Server belegen. Aktivieren Sie die Deduplizierung unter Windows. Wenn Sie diese große Menge an Speicher nicht dauerhaft auf Ihre Windows Server-Instanz übertragen möchten, können Sie die Volumegröße nach der Migration und vor der Anpassung der Cloudtieringrichtlinien verringern. Dadurch wird ein kleinerer lokaler Cache Ihrer Azure-Dateifreigaben erstellt.

Die Ressourcenkonfiguration (Compute und RAM) der von Ihnen bereitgestellten Windows Server-Instanz hängt größtenteils von der Anzahl der Elemente (Dateien und Ordner) ab, die synchronisiert werden sollen. Wenn Sie Bedenken haben, empfiehlt es sich, eine leistungsstärkere Konfiguration zu verwenden.

Erfahren Sie, wie Sie die Größe einer Windows Server-Instanz basierend auf der Anzahl der zu synchronisierenden Elemente (Dateien und Ordner) anpassen.

Hinweis

Der zuvor verknüpfte Artikel enthält eine Tabelle mit einem Bereich für den Serverarbeitsspeicher (RAM). Sie können sich an der geringeren Zahl für Ihren Server orientieren, müssen jedoch davon ausgehen, dass die anfängliche Synchronisierung wesentlich mehr Zeit in Anspruch nehmen kann.

Phase 3: Bereitstellen der Cloudressource für die Azure-Dateisynchronisierung

Sie benötigen die Anmeldeinformationen für Ihr Azure-Abonnement, um diesen Schritt abschließen zu können.

Die wichtigste Ressource, die für die Azure-Dateisynchronisierung konfiguriert werden muss, ist der Speichersynchronisierungsdienst. Es wird empfohlen, nur einen solchen Dienst für alle Server bereitzustellen, die aktuell oder in Zukunft für die Synchronisierung der gleichen Dateien verwendet werden. Erstellen Sie mehrere Speichersynchronisierungsdienste nur dann, wenn Sie über separate Server verfügen, zwischen denen niemals ein Datenaustausch stattfinden darf. Sie könnten z. B. über Server verfügen, die niemals dieselbe Azure-Dateifreigabe synchronisieren dürfen. Andernfalls besteht eine bewährte Methode darin, einen einzelnen Speichersynchronisierungsdienst zu verwenden.

Wählen Sie eine Azure-Region für Ihren Speichersynchronisierungsdienst aus, die sich in der Nähe Ihres Standorts befindet. Alle anderen Cloudressourcen müssen innerhalb derselben Region bereitgestellt werden. Für eine vereinfachte Verwaltung erstellen Sie in Ihrem Abonnement eine neue Ressourcengruppe für Synchronisierungs- und Speicherressourcen.

Weitere Informationen finden Sie im Abschnitt über das Bereitstellen des Speichersynchronisierungsdiensts im Artikel über das Bereitstellen der Azure-Dateisynchronisierung. Führen Sie nur die Schritte in diesem Abschnitt des Artikels aus. Spätere Schritte enthalten Links zu anderen Abschnitten dieses Artikels.

Phase 4: Bereitstellen von Azure Storage-Ressourcen

Sehen Sie sich in dieser Phase die Zuordnungstabelle aus Phase 1 an, und verwenden Sie diese, um die richtige Anzahl von Azure-Speicherkonten und Dateifreigaben darin bereitzustellen.

Eine Azure-Dateifreigabe wird in der Cloud in einem Azure-Speicherkonto gespeichert. Im Hinblick auf die Leistung sollten dabei einige wichtige Aspekte berücksichtigt werden.

Wenn Ihre Freigaben intensiv genutzt werden, z. B. von einer großen Anzahl von Benutzern und/oder Anwendungen, wird die maximale Leistung eines Speicherkontos möglicherweise mit zwei Azure-Dateifreigaben erreicht.

Als bewährte Methode empfiehlt es sich, Speicherkonten mit je einer Dateifreigabe bereitzustellen. Sie können mehrere Azure-Dateifreigaben in demselben Speicherkonto zusammenfassen, wenn Sie Archivierungsfreigaben verwenden oder nur eine geringe tägliche Aktivität erwarten.

Diese Überlegungen gelten eher für direkten Cloudzugriff (über eine Azure-VM oder Azure-Dateisynchronisierung) als für die Azure-Dateisynchronisierung. Wenn Sie Freigaben lediglich für die Azure-Dateisynchronisierung verwenden möchten, können Sie mehrere Freigaben in einem einzelnen Azure-Speicherkonto gruppieren.

Wenn Sie eine Liste Ihrer Freigaben erstellt haben, sollten Sie jede Freigabe dem Speicherkonto zuordnen, in dem sie sich befindet.

Im vorherigen Schritt haben Sie die geeignete Anzahl von Freigaben bestimmt. In diesem Schritt haben Sie eine Zuordnung von Speicherkonten und Dateifreigaben erstellt. Nun stellen Sie die geeignete Anzahl von Azure-Speicherkonten mit der geeigneten Anzahl von Azure-Dateifreigaben bereit.

Stellen Sie sicher, dass die Region der einzelnen Speicherkonten identisch ist und mit der Region der Speichersynchronisierungsdienst-Ressource übereinstimmt, die Sie bereits bereitgestellt haben.

Achtung

Wenn Sie eine Azure-Dateifreigabe mit maximal 100 TiB erstellen, kann diese Freigabe als Redundanzoptionen nur lokal redundanten Speicher oder zonenredundanten Speicher verwenden. Daher sollten Sie Ihre Speicherredundanzanforderungen berücksichtigen, bevor Sie Dateifreigabe mit 100 TiB verwenden.

Azure-Dateifreigaben werden standardmäßig weiterhin mit einem Grenzwert von 5 TiB erstellt. Führen Sie die unter Erstellen einer Azure-Dateifreigabe beschriebenen Schritte aus, um eine große Dateifreigabe zu erstellen.

Ein weiterer Aspekt, den Sie bei der Bereitstellung eines Speicherkontos berücksichtigen sollten, ist die Redundanz von Azure Storage. Weitere Informationen finden Sie unter Redundanzoptionen von Azure Storage.

Auch die Namen Ihrer Ressourcen sind wichtig. Wenn Sie z.B. mehrere Freigaben für die Personalabteilung in einem Azure-Speicherkonto gruppieren, sollten Sie einen entsprechenden Namen für das Speicherkonto wählen. Gleichermaßen sollten Sie beim Benennen Ihrer Azure-Dateifreigaben Namen verwenden, die denen der lokalen Entsprechungen ähneln.

Phase 5: Bereitstellen des Azure-Dateisynchronisierungs-Agents

In diesem Abschnitt installieren Sie den Azure-Dateisynchronisierungs-Agent auf Ihrer Windows Server-Instanz.

Im Bereitstellungsleitfaden wird beschrieben, dass Sie die verstärkte Sicherheitskonfiguration für Internet Explorer deaktivieren müssen. Diese Sicherheitsmaßnahme ist nicht auf die Azure-Dateisynchronisierung anwendbar. Wenn Sie sie deaktivieren, können Sie sich problemlos bei Azure authentifizieren.

Öffnen Sie PowerShell. Installieren Sie die erforderlichen PowerShell-Module mithilfe der folgenden Befehle. Installieren Sie das vollständige Modul und den NuGet-Anbieter, wenn Sie dazu aufgefordert werden.

Install-Module -Name Az -AllowClobber
Install-Module -Name Az.StorageSync

Wenn auf Ihrem Server Probleme mit der Internetverbindung auftreten, sollten Sie diese Probleme jetzt beheben. Bei der Azure-Dateisynchronisierung wird eine beliebige verfügbare Internetverbindung verwendet. Konfigurationen, in denen für die Internetverbindung ein Proxyserver erforderlich ist, werden ebenfalls unterstützt. Sie können entweder jetzt einen computerweiten Proxy konfigurieren oder während der Agent-Installation einen Proxy angeben, der ausschließlich für die Azure-Dateisynchronisierung verwendet wird.

Wenn die Konfiguration eines Proxy erfordert, dass Sie Ihre Firewalls für diesen Server öffnen, könnte dieser Ansatz für Sie geeignet sein. Am Ende der Serverinstallation und nach abgeschlossener Serverregistrierung werden in einem Bericht zur Netzwerkkonnektivität die genauen Endpunkt-URLs in Azure angezeigt, mit denen die Azure-Dateisynchronisierung für Ihre ausgewählte Region kommunizieren muss. Der Bericht enthält zudem Informationen dazu, weshalb diese Kommunikation erforderlich ist. Sie können den Bericht verwenden, um die Firewalls auf diesem Server zu sperren und nur bestimmte URLs zuzulassen.

Sie können auch einen konservativeren Ansatz wählen, bei dem die Firewalls nicht vollständig geöffnet werden. Sie können stattdessen die Kommunikation des Servers auf übergeordnete DNS-Namespaces beschränken. Weitere Informationen finden Sie unter Proxy- und Firewalleinstellungen der Azure-Dateisynchronisierung. Halten Sie sich an ihre eigenen bewährten Methoden für Netzwerke.

Am Ende des Assistenten für die Serverinstallation wird ein Assistent zur Serverregistrierung geöffnet. Registrieren Sie den Server bei der zuvor genannten Azure-Speichersynchronisierungsdienst-Ressource.

Im Bereitstellungshandbuch sind diese Schritte näher beschrieben. Dabei wird auch auf die PowerShell-Module eingegangen, die zuerst installiert werden sollten: Installation des Azure-Dateisynchronisierungs-Agents.

Verwenden Sie den neuesten Agent. Sie können ihn aus dem Microsoft Download Center herunterladen: Azure-Dateisynchronisierungs-Agent.

Nach der Installation und Registrierung des Servers können Sie überprüfen, ob dieser Schritt erfolgreich ausgeführt wurde. Wechseln Sie im Azure-Portal zur Storage Sync Service-Ressource. Wechseln Sie im linken Menü zu Registrierte Server. Ihr Server sollte in dieser Liste enthalten sein.

Phase 6: Konfigurieren der Azure-Dateisynchronisierung in der Windows Server-Bereitstellung

Die registrierte lokale Windows Server-Instanz muss für diesen Prozess vorbereitet und mit dem Internet verbunden sein.

In diesem Schritt werden alle Ressourcen und Ordner miteinander verknüpft, die Sie im vorherigen Schritt auf Ihrer Windows Server-Instanz eingerichtet haben.

  1. Melden Sie sich beim Azure-Portal an.
  2. Wechseln Sie zu Ihrer Speichersynchronisierungsdienst-Ressource.
  3. Erstellen Sie innerhalb des Speichersynchronisierungsdiensts für jede Azure-Dateifreigabe eine neue Synchronisierungsgruppe. Im Kontext der Azure-Dateisynchronisierung wird die Azure-Dateifreigabe zu einem Cloudendpunkt in der Synchronisierungstopologie, die Sie durch das Erstellen einer Synchronisierungsgruppe beschreiben. Weisen Sie beim Erstellen der Synchronisierungsgruppe einen aussagekräftigen Namen zu, damit Sie erkennen können, welche Dateien synchronisiert werden. Stellen Sie sicher, dass Sie mit einem übereinstimmenden Namen auf die Azure-Dateifreigabe verweisen.
  4. Nach dem Erstellen der Synchronisierungsgruppe wird in der Liste der Synchronisierungsgruppen eine eigene Zeile für diese Gruppe angezeigt. Wählen Sie den Namen (einen Link) aus, um die Inhalte der Synchronisierungsgruppe anzuzeigen. Ihre Azure-Dateifreigabe wird unter Cloudendpunkte aufgeführt.
  5. Suchen Sie die Schaltfläche Serverendpunkt hinzufügen. Der Ordner auf dem lokalen Server, den Sie bereitgestellt haben, wird als Pfad für diesen Serverendpunkt verwendet.

Wichtig

Cloudtiering ist ein Feature der Azure-Dateisynchronisierung, das es dem lokalen Server ermöglicht, weniger Speicherkapazität als in der Cloud zu haben, aber trotzdem über den vollständigen Namespace zu verfügen. Lokal relevante Daten werden zudem für eine schnelle Zugriffsleistung lokal zwischengespeichert. Das Cloudtiering ist ein optionales Feature, das pro Serverendpunkt der Azure-Dateisynchronisierung agiert.

Warnung

Wenn Sie auf Ihren Windows Server-Volumes weniger Speicher bereitgestellt haben als für die Daten auf dem Linux-Samba-Server verwendet werden, ist das Cloudtiering obligatorisch. Wenn Sie das Cloudtiering nicht aktivieren, gibt der Server nicht genügend Speicherplatz zum Speichern aller Dateien frei. Legen Sie Ihre Tieringrichtlinie vorübergehend für die Migration auf 99 % freien Speicherplatz für ein Volume fest. Achten Sie darauf, nach Abschluss der Migration zu Ihren Cloudtieringeinstellungen zurückkehren und diese auf eine langfristig sinnvollere Stufe festzulegen.

Wiederholen Sie die Schritte zum Erstellen einer Synchronisierungsgruppe und zum Hinzufügen des jeweiligen Serverordners als Serverendpunkt für alle Azure-Dateifreigaben und Serverspeicherorte, die für die Synchronisierung konfiguriert werden müssen.

Nach der Erstellung aller Serverendpunkte funktioniert die Synchronisierung. Sie können eine Testdatei erstellen und beobachten, dass sie an Ihrem Serverstandort mit der verbundenen Azure-Dateifreigabe synchronisiert wird (wie vom Cloudendpunkt in der Synchronisierungsgruppe beschrieben).

Beide Speicherorte – die Serverordner und die Azure-Dateifreigaben – sind andernfalls leer und erwarten Daten. Im nächsten Schritt beginnen Sie mit dem Kopieren von Dateien auf die Windows Server-Instanz, damit die Azure-Dateisynchronisierung diese in die Cloud verschieben kann. Falls Sie das Cloudtiering aktiviert haben, beginnt der Server dann mit der Aufteilung der Dateien, wenn die Kapazität auf den lokalen Volumes ausgeschöpft ist.

Phase 7: Robocopy

Der grundlegende Migrationsansatz ist die Verwendung von Robocopy zum Kopieren von Dateien sowie der Azure-Dateisynchronisierung zum Synchronisieren.

Erstellen Sie die erste lokale Kopie in Ihrem Windows Server-Zielordner:

  1. Ermitteln Sie den ersten Speicherort auf Ihrem Linux-Samba-Server.
  2. Identifizieren Sie den entsprechenden Ordner auf der Windows Server-Instanz, auf der die Azure-Dateisynchronisierung bereits konfiguriert wurde.
  3. Starten Sie den Kopiervorgang mit Robocopy.

Mit dem folgenden Robocopy-Befehl werden Dateien vom Speicher Ihres Linux-Samba-Servers in den Windows Server-Zielordner kopiert. Windows-Server synchronisiert diesen Ordner mit den Azure-Dateifreigaben.

Wenn Sie auf Ihrer Windows Server-Instanz weniger Speicher bereitgestellt haben, als Ihre Dateien auf dem Linux-Samba-Server benötigen, haben Sie Cloudtiering konfiguriert. Wenn das lokale Windows Server-Volume voll ist, beginnt das Cloudtiering für die Dateien, die bereits erfolgreich synchronisiert wurden. Durch das Cloudtiering wird ausreichend Speicherplatz generiert, um mit dem Kopiervorgang vom Linux-Samba-Server fortzufahren. Einmal pro Stunde wird überprüft, was bereits im Cloudtiering synchronisiert wurde, und Speicherplatz freigegeben, um auf dem Volume einen freien Speicherplatz von 99 % zu erreichen.

Robocopy verschiebt die Dateien möglicherweise zu schnell für den Synchronisierungsvorgang mit der Cloud und führt dann ein lokales Tiering durch. Dadurch kann der Speicherplatz auf dem lokalen Datenträger knapp werden. Robocopy führt dann zu einem Fehler. Es wird empfohlen, die Freigaben nacheinander abzuarbeiten, um dieses Problem zu verhindern. Beispielsweise sollten Sie nicht für alle Freigaben gleichzeitig Robocopy-Aufträge starten. Sie können auch Freigaben verschieben, für die der aktuell freie Speicherplatz auf der Windows Server-Instanz ausreicht. Falls Ihr Robocopy-Auftrag fehlschlägt, können Sie den Befehl jederzeit erneut ausführen, wenn Sie die folgende Option zum Spiegeln/Bereinigen verwenden:

robocopy <SourcePath> <Dest.Path> /MT:20 /R:2 /W:1 /B /MIR /IT /COPY:DATSO /DCOPY:DAT /NP /NFL /NDL /XD "System Volume Information" /UNILOG:<FilePathAndName>
Schalter Bedeutung
/MT:n Hiermit kann Robocopy mit mehreren Threads ausgeführt werden. Der Standardwert für n ist 8. Das Maximum beträgt 128 Threads. Eine hohe Anzahl von Threads trägt zwar dazu bei, die verfügbare Bandbreite auszuschöpfen, aber dies bedeutet nicht, dass Ihre Migration mit mehr Threads immer schneller ist. Tests mit Azure Files zeigen, dass mit einer Anzahl von 8 bis 20 Threads eine ausgewogene Leistung für einen ersten Kopierlauf erzielt wird. Nachfolgende Ausführungen von /MIR werden zunehmend durch die verfügbare Computeleistung und nicht durch die verfügbare Netzwerkbandbreite beeinflusst. Stimmen Sie bei nachfolgenden Ausführungen den Wert für die Threadanzahl genauer auf die Prozessorkernanzahl und die Threadanzahl pro Kern ab. Überprüfen Sie, ob Kerne für andere Tasks reserviert werden müssen, über die ein Produktionsserver verfügen könnte. Tests mit Azure Files haben gezeigt, dass bis zu 64 Threads eine gute Leistung liefern, aber nur, wenn Ihre Prozessoren sie gleichzeitig aktiv halten können.
/R:n Dies ist die maximale Anzahl der Wiederholungsversuche für eine Datei, bei der beim ersten Kopierversuch ein Fehler auftritt. Robocopy führt n Versuche durch, bevor bei der Ausführung für die Datei ein dauerhafter Kopierfehler auftritt. Sie können die Leistung Ihres Durchlaufs optimieren: Wählen Sie einen Wert von 2 oder 3, wenn Sie annehmen, dass Timeouts in der Vergangenheit zu Fehlern geführt haben. Dies kann bei WAN-Verbindungen häufiger vorkommen. Wählen Sie keine Wiederholung oder den Wert 1, wenn Sie glauben, dass die Datei nicht kopiert werden konnte, weil sie aktiv in Verwendung war. Ein erneuter Versuch ein paar Sekunden später reicht möglicherweise nicht aus, um den Status der Datei zu ändern. Benutzer oder Apps, die die Datei geöffnet haben, benötigen möglicherweise einige Stunden mehr Zeit. Wenn Sie in diesem Fall akzeptieren, dass die Datei nicht kopiert wurde, und dies in einem späteren geplanten Robocopy-Lauf nachholen, kann die Datei möglicherweise erfolgreich kopiert werden. So kann der aktuelle Durchlauf schneller abgeschlossen werden, ohne sich durch zahlreiche Wiederholungsversuche in die Länge zu ziehen, die letztlich dazu führen, dass ein Großteil der Kopiervorgänge fehlschlägt, weil die Dateien nach Ablauf des Zeitlimits für Wiederholungsversuche weiterhin geöffnet sind.
/W:n Hiermit wird die Zeit angegeben, die Robocopy vor dem Versuch wartet, eine Datei zu kopieren, die bei einem vorherigen Versuch nicht erfolgreich kopiert wurde. n entspricht der Anzahl der zwischen Wiederholungsversuchen zu wartenden Sekunden. /W:n wird häufig in Verbindung mit /R:n verwendet.
/B Führt Robocopy in dem Modus aus, den auch eine Sicherungsanwendung verwenden würde. Diese Option ermöglicht Robocopy das Verschieben von Dateien, für die der aktuelle Benutzer keine Berechtigungen hat. Die Sicherungsoption ist abhängig von der Ausführung des Robocopy-Befehls in einer Konsole mit Administratorrechten oder einem PowerShell-Fenster. Wenn Sie Robocopy für Azure Files verwenden, stellen Sie sicher, dass Sie die Azure-Dateifreigabe mit dem Zugriffsschlüssel des Speicherkontos und nicht mit einer Domänenidentität einbinden. Andernfalls führen Sie die Fehlermeldungen möglicherweise nicht intuitiv zu einer Lösung des Problems.
/MIR (Quelle im Ziel spiegeln) Hiermit hat Robocopy die Möglichkeit, nur Deltas zwischen der Quelle und dem Ziel zu kopieren. Leere Unterverzeichnisse werden kopiert. Elemente (Dateien oder Ordner), die geändert wurden oder nicht im Ziel vorhanden sind, werden kopiert. Elemente, die im Ziel, aber nicht in der Quelle vorhanden sind, werden aus dem Ziel gelöscht. Wenn Sie diese Option verwenden, passen Sie die Quell- und Zielordnerstrukturen genau an. Übereinstimmung bedeutet, dass aus der richtigen Quelle und Ordnerebene in die entsprechende Ordnerebene im Ziel kopiert wird. Nur dann kann ein Kopiervorgang zum „Aufholen“ erfolgreich durchgeführt werden. Wenn die Quelle und das Ziel nicht übereinstimmen, können mithilfe von /MIR umfassende Lösch- und wiederholte Kopiervorgänge durchgeführt werden.
/IT Sorgt dafür, dass die Genauigkeit in bestimmten Spiegelungsszenarien beibehalten wird.
Wenn beispielsweise bei einer Datei zwischen zwei Robocopy-Ausführungen eine ACL-Änderung und ein Attributupdate durchgeführt werden, wird diese als „ausgeblendet“ gekennzeichnet. Ohne /IT bemerkt Robocopy die ACL-Änderung möglicherweise nicht und führt daher auch keine Übertragung an den Zielspeicherort aus.
/COPY:[copyflags] Dies ist die Genauigkeit der Dateikopie. Standardwert: /COPY:DAT. Kopierflags: D = Daten, A = Attribute, T = Zeitstempel, S = Sicherheit = NTFS-ACLs, O = Besitzerinformationen, U = Überwachungsinformationen Überwachungsinformationen können nicht in einer Azure-Dateifreigabe gespeichert werden.
/DCOPY:[copyflags] Dies ist die Genauigkeit für die Kopie von Verzeichnissen. Standardwert: /DCOPY:DA. Kopierflags: D = Daten, A = Attribute, T = Zeitstempel.
/NP Hiermit wird angegeben, dass der Kopierfortschritt für alle Dateien und Ordner nicht angezeigt wird. Das Anzeigen des Fortschritts reduziert die Kopierleistung erheblich.
/NFL Gibt an, dass Dateinamen nicht protokolliert werden. Hiermit wird die Kopierleistung verbessert.
/NDL Gibt an, dass Verzeichnisnamen nicht protokolliert werden. Hiermit wird die Kopierleistung verbessert.
/XD Gibt die auszuschließenden Verzeichnisse an. Wenn Sie Robocopy im Stammverzeichnis eines Volumes ausführen, erwägen Sie den Ausschluss des ausgeblendeten Ordners System Volume Information. Bei bestimmungsgemäßer Verwendung gelten alle darin enthaltenen Informationen für genau dieses Volume auf genau diesem System und können bei Bedarf wiederhergestellt werden. Das Kopieren dieser Informationen in die Cloud oder das Zurückkopieren der Daten auf ein anderes Windows-Volume hat keinen Nutzen. Der Wegfall dieser Inhalte sollte nicht als Datenverlust betrachtet werden.
/UNILOG:<file name> Hiermit wird der Status als Unicode in die Protokolldatei geschrieben. (Überschreibt das vorhandene Protokoll.)
/L Nur für einen Testlauf
Dateien sollen nur aufgelistet werden. Sie werden nicht kopiert, nicht gelöscht und nicht mit einem Zeitstempel versehen. Wird häufig mit /TEE für die Konsolenausgabe verwendet. Flags aus dem Beispielskript, z. B. /NP, /NFL und /NDL, müssen möglicherweise entfernt werden, um ordnungsgemäß dokumentierte Testergebnisse zu erzielen.
/LFSM Nur für Ziele mit mehrstufigem Speicher vorgesehen. Nicht unterstützt, wenn es sich bei dem Ziel um eine Remote-SMB-Freigabe handelt.
Hiermit wird angegeben, dass Robocopy im Modus „Nicht genügend freier Speicherplatz“ ausgeführt wird. Diese Option ist nur für Ziele mit mehrstufigem Speicher nützlich, bei denen möglicherweise der lokale Speicherplatz aufgebraucht ist, bevor die Robocopy-Ausführung fertiggestellt wird. Sie wurde spezifisch für die Verwendung mit einem Ziel hinzugefügt, für das das Cloudtiering der Azure-Dateisynchronisierung aktiviert ist. Die Option kann unabhängig von der Azure-Dateisynchronisierung verwendet werden. In diesem Modus pausiert die Robocopy-Ausführung immer dann, wenn ein Dateikopiervorgang dazu führen würde, dass der freie Speicherplatz des Zielvolumes einen bestimmten Schwellenwert unterschreitet. Dieser Wert kann mit dem /LFSM:n-Formular des Flags festgelegt werden. Der Parameter n wird im Dualsystem festgelegt: nKB, nMB oder nGB. Wenn /LFSM ohne einen expliziten Schwellenwert festgelegt wird, wird der Schwellenwert auf 10 % der Größe des Zielvolumes festgelegt. Der Modus für nicht genügend freien Speicherplatz ist mit /MT, /EFSRAW oder /ZB nicht kompatibel. Support für /B wurde in Windows Server 2022 hinzugefügt. Weitere Informationen, u. a. Details zu einem verwandten Fehler und eine Problemumgehung, finden Sie weiter unten im Abschnitt „Windows Server 2022 und RoboCopy LFSM“.
/Z Umsichtige Verwendung
Dateien werden im Neustartmodus kopiert. Diese Option wird nur in einer instabilen Netzwerkumgebung empfohlen. Sie reduziert die Kopierleistung aufgrund der zusätzlichen Protokollierung erheblich.
/ZB Umsichtige Verwendung
Der Neustartmodus wird verwendet. Wenn der Zugriff verweigert wird, wird der Sicherungsmodus verwendet. Diese Option reduziert die Kopierleistung aufgrund der Prüfpunkte erheblich.

Wichtig

Es wird empfohlen, Windows Server 2022 zu verwenden. Stellen Sie bei Verwendung von Windows Server 2019 sicher, dass die neueste Patchebene angewendet wurde oder mindestens das Betriebssystemupdate KB5005103 installiert ist. Dieses Update enthält wichtige Korrekturen für bestimmte Robocopy-Szenarien.

Phase 8: Benutzerübernahme

Wenn Sie den Robocopy-Befehl zum ersten Mal ausführen, greifen Ihre Benutzer und Anwendungen weiterhin auf Dateien auf dem Linux-Samba-Server zu und ändern sie möglicherweise. Es kann vorkommen, dass Robocopy ein Verzeichnis verarbeitet, mit dem nächsten fortfährt und dann ein Benutzer am Quellspeicherort (Linux) eine Datei hinzufügt, ändert oder löscht. Diese wird dann während der aktuellen Robocopy-Ausführung nicht verarbeitet. Dies ist das erwartete Verhalten.

Der erste Schritt besteht darin, den Großteil der Daten auf Ihre Windows Server-Instanz und dann über die Azure-Dateisynchronisierung in die Cloud zu verschieben. Der erste Kopiervorgang kann einige Zeit in Anspruch nehmen, die von folgenden Faktoren abhängig ist:

  • Downloadbandbreite
  • Uploadbandbreite
  • Geschwindigkeit des lokalen Netzwerks und Anzahl der optimalen Übereinstimmungen von Robocopy-Threads
  • Anzahl der Elemente (Dateien und Ordner), die von Robocopy und der Azure-Dateisynchronisierung verarbeitet werden müssen

Nachdem die erste Ausführung beendet wurde, führen Sie den Befehl erneut aus.

Beim zweiten Mal wird der Vorgang schneller abgeschlossen, da nur Änderungen, die seit der letzten Ausführung aufgetreten sind, übertragen werden müssen. Während dieser zweiten Ausführung können sich auch neue Änderungen ansammeln.

Wiederholen Sie diesen Vorgang, bis Sie der Auffassung sind, dass die bis zum Abschluss eines Robocopy-Vorgangs für einen bestimmten Speicherort benötigte Zeit ein akzeptables Ausfallzeitfenster darstellt.

Wenn Sie die Ausfallzeit als akzeptabel betrachten und darauf vorbereitet sind, den Linux-Speicherort offline zu schalten, können Sie die ACLs für den Freigabestamm ändern, sodass Benutzer nicht mehr auf den Speicherort zugreifen können. Sie können auch einen anderen geeigneten Schritt ausführen, der das Ändern von Inhalten in diesem Ordner auf Ihrem Linux-Server verhindert.

Führen Sie einen letzten Robocopy-Durchgang aus. Dadurch werden alle Änderungen übernommen, die zuvor möglicherweise ausgelassen wurden. Wie lange dieser letzte Schritt dauert, hängt von der Geschwindigkeit des Robocopy-Scans ab. Sie können die Zeit (gleich der Ausfallzeit) schätzen, indem Sie messen, wie lange die vorherige Ausführung gedauert hat.

Erstellen Sie eine Freigabe für den Windows Server-Ordner, und passen Sie Ihre DFS-N-Bereitstellung ggf. so an, dass sie auf diese zeigt. Stellen Sie sicher, dass Sie die gleichen Berechtigungen auf Freigabeebene wie auf den SMB-Freigaben Ihres Linux-Samba-Servers festlegen. Wenn Sie lokale Benutzer auf Ihrem Linux-Samba-Server verwendet haben, müssen Sie diese als lokale Benutzer von Windows Server neu erstellen. Sie müssen auch die vorhandenen SIDs, die Robocopy auf Ihre Windows Server-Instanz verschoben hat, den SIDs Ihrer neuen lokalen Benutzer von Windows Server zuordnen. Wenn Sie Active Directory-Konten und ACLs verwendet haben, werden diese von Robocopy unverändert verschoben, und es ist keine weitere Aktion erforderlich.

Sie haben die Migration einer Freigabe oder Gruppe von Freigaben zu einem gemeinsamen Stamm oder Volume (je nach Zuordnung aus Phase 1) abgeschlossen.

Sie können einige dieser Kopiervorgänge parallel ausführen. Es wird empfohlen, jeweils eine Azure-Dateifreigabe auf einmal zu verarbeiten.

Warnung

Nachdem Sie alle Daten von Ihrem Linux-Samba-Server auf die Windows Server-Instanz verschoben haben und die Migration abgeschlossen wurde, wechseln Sie im Azure-Portal zu allen Synchronisierungsgruppen zurück. Legen Sie den Prozentsatz des freien Speicherplatzes für das Cloudtiering auf einen Wert fest, der für die Cachenutzung besser geeignet ist, z. B. 20 %.

Die Richtlinie für den freien Speicherplatz für das Cloudtiering wirkt sich auf eine Volumeebene aus, von der aus potenziell mehrere Serverendpunkte synchronisiert werden. Wenn Sie vergessen, den freien Speicherplatz auf einem Serverendpunkt anzupassen, wird für die Synchronisierung weiterhin die restriktivste Regel angewandt, und es wird versucht, 99 % freien Speicherplatz beizubehalten. Der lokale Cache funktioniert in diesem Fall nicht wie erwartet. Dies kann sinnvoll sein, wenn Sie den Namespace für ein Volume erhalten möchten, das ausschließlich selten genutzte Archivdaten enthält, und Sie den restlichen Speicherplatz für ein anderes Szenario reservieren.

Problembehandlung

Das häufigste Problem besteht darin, dass der Robocopy-Befehl mit dem Fehler Volume voll auf Windows Server-Seite beendet wird. Das Cloudtiering erfolgt einmal stündlich, um Inhalte vom lokalen Windows Server-Datenträger abzurufen, die bereits synchronisiert wurden. Das Ziel besteht darin, 99 % freien Speicherplatz auf dem Volume zu erreichen.

Warten Sie, bis durch den Synchronisierungsvorgang und das Cloudtiering Speicherplatz freigegeben wurde. Sie können dies im Datei-Explorer unter Windows Server beobachten.

Wenn auf Ihrer Windows Server-Instanz ausreichende Kapazität verfügbar ist, wird das Problem durch erneutes Ausführen des Befehls behoben. Falls Sie auf diese Situation stoßen, treten keine Schäden auf, und Sie können einfach fortfahren. Der zusätzliche Aufwand durch das erneute Ausführen des Befehls ist die einzige Folge.

Unter dem Link im folgenden Abschnitt finden Sie Informationen zur Behandlung von Problemen mit der Azure-Dateisynchronisierung.

Nächste Schritte

In den folgenden Artikeln werden erweiterte Optionen, bewährte Methoden und Ansätze zum Troubleshooting für die Azure-Dateisynchronisierung erläutert.