Zuverlässigkeit in Azure Storage Mover

  • Artikel

Dieser Artikel beschreibt die Zuverlässigkeitsunterstützung in Azure Storage Mover und behandelt sowohl regionsinterne Resilienz mittels Verfügbarkeitszonen als auch regionsübergreifende Notfallwiederherstellung und Geschäftskontinuität. Eine ausführlichere Übersicht über die Zuverlässigkeitsprinzipien in Azure finden Sie unter Azure-Zuverlässigkeit.

Unterstützung für Verfügbarkeitszonen

Azure-Verfügbarkeitszonen sind mindestens drei physisch getrennte Gruppen von Rechenzentren innerhalb jeder Azure-Region. Die Rechenzentren innerhalb jeder Zone sind mit unabhängiger Stromversorgung, Kühlung und Netzwerkinfrastruktur ausgestattet. Bei einem Fehler in der lokalen Zone sind Verfügbarkeitszonen so konzipiert, dass regionale Dienste, Kapazität und Hochverfügbarkeit von den verbleibenden beiden Zonen unterstützt werden, wenn eine Zone betroffen ist.

Ausfälle können von Software- und Hardwareausfällen bis hin zu Ereignissen wie Erdbeben, Überflutungen und Bränden reichen. Fehlertoleranz wird durch Redundanz und logische Isolierung von Azure-Diensten erreicht. Ausführlichere Informationen zu Verfügbarkeitszonen in Azure finden Sie unter Regionen und Verfügbarkeitszonen.

Azure-Dienste mit Unterstützung von Verfügbarkeitszonen bieten das richtige Maß an Zuverlässigkeit und Flexibilität. Für die Konfiguration gibt es zwei Möglichkeiten. Sie können entweder zonenredundant mit automatischer zonenübergreifender Replikation oder zonenbasiert mit Instanzen sein, die an eine bestimmte Zone angeheftet werden. Sie können diese Ansätze auch kombinieren. Weitere Informationen zur zonalen im Vergleich zur zonenredundanten Architektur finden Sie unter Empfehlungen für die Verwendung von Verfügbarkeitszonen und Regionen.

Azure Storage Mover unterstützt ein zonenredundantes Bereitstellungsmodell.

Wenn Sie eine Azure Storage Mover-Ressource bereitstellen, müssen Sie eine bestimmte Region auswählen, in der die Instanzmetadaten der Ressource gespeichert sind.

Wenn die Region Verfügbarkeitszonen unterstützt, werden die Instanzmetadaten automatisch in mehreren Verfügbarkeitszonen innerhalb dieser Region repliziert.

Wichtig

Azure Storage Mover-Instanzmetadaten umfassen Projekte, Endpunkte, Agents, Auftragsdefinitionen und Auftragsausführungsverlauf, enthalten jedoch nicht die tatsächlich zu migrierenden Daten. Azure-Speicherkonten, die als Migrationsziele verwendet werden, verfügen über ihre eigene Zuverlässigkeitsunterstützung.

Voraussetzungen

Zonenausfall

Während eines zonenweiten Ausfalls ist während der Zonenwiederherstellung keine Aktion erforderlich. Azure Storage Mover wurde entwickelt, um sich selbst zu reparieren und neu auszubalancieren, um die Vorteile der fehlerfreien Zone automatisch zu nutzen.

Für jedes Zielspeicherkonto der Migration sind möglicherweise eigene Wiederherstellungsschritte erforderlich. Diese Anforderung hängt von den Redundanzoptionen ab, die für jedes Speicherkonto ausgewählt werden. Im Handbuch zur Notfallwiederherstellung für Speicherkonten können Sie ermitteln, ob weitere Schritte erforderlich sind.

Wenn anstelle von Redundanzoptionen ein lokaler Speicher gewählt wurde, müssen Sie möglicherweise während des Ausfalls ein neues Speicherkonto für die Verwendung bei Migrationen erstellen.

Regionsübergreifende Notfallwiederherstellung und Geschäftskontinuität

Bei der Notfallwiederherstellung (DR) geht es um die Wiederherstellung nach Ereignissen mit schwerwiegenden Auswirkungen, z. B. Naturkatastrophen oder fehlerhaften Bereitstellungen, die zu Downtime und Datenverlust führen. Unabhängig von der Ursache ist das beste Mittel gegen einen Notfall ein gut definierter und getesteter Notfallplan und ein Anwendungsdesign, die Notfallwiederherstellung aktiv unterstützt. Bevor Sie mit der Erstellung Ihres Notfallwiederherstellungsplans beginnen, lesen Sie die Empfehlungen zum Entwerfen einer Notfallwiederherstellungsstrategie.

Bei DR verwendet Microsoft das Modell der gemeinsamen Verantwortung. In einem Modell der gemeinsamen Verantwortung stellt Microsoft sicher, dass die grundlegenden Infrastruktur- und Plattformdienste verfügbar sind. Gleichzeitig replizieren viele Azure-Dienste nicht automatisch Daten oder greifen automatisch auf eine ausgefallene Region zurück, um eine regionsübergreifende Replikation in eine andere aktivierte Region durchzuführen. Für diese Dienste sind Sie dafür verantwortlich, einen Notfallwiederherstellungsplan zu erstellen, der für Ihre Workload geeignet ist. Die meisten Dienste, die auf Azure Platform as a Service (PaaS)-Angeboten laufen, bieten Funktionen und Anleitungen zur Unterstützung von Notfallwiederherstellung und Sie können dienstspezifische Funktionen zur Unterstützung einer schnellen Wiederherstellung nutzen, um Ihren Notfallwiederherstellungsplan zu entwickeln.

Wenn ein Storage Mover-Agent registriert ist, stellt er eine Verbindung mit der Region her, in der die Storage Mover-Ressource registriert ist. Wenn die Azure-Region eines Agents einen Ausfall erlebt, ist der Agent selbst nicht betroffen, aber Verwaltungsvorgänge, die auf Azure basieren, können möglicherweise nicht abgeschlossen werden. Darüber hinaus können aktive Datenmigrationen zu Speicherkonten in der betroffenen Region fehlschlagen.

Storage Mover unterstützt zwei Formen der Notfallwiederherstellung:

Wichtig

Die Notfallwiederherstellung für lokale Datenquellen liegt in der Verantwortung des Kunden.

Von Azure initiierte Notfallwiederherstellung

Die von Azure initiierte Notfallwiederherstellung gilt nur für Regionen mit Regionspaaren. Wenn die regionsübergreifende Replikation verwendet wird, werden Instanzmetadaten in jede Region repliziert, dürfen aber niemals die Geografie verlassen.

Azure Storage Mover verwendet Cosmos DB zum Speichern von Instanzmetadaten. Zu einem Datenverlust kann es nur bei einem nicht behebbaren Notfall in der Azure Cosmos DB kommen. Weitere Informationen finden Sie unter Regionsausfälle. Die von Azure initiierte Wiederherstellung ist aktiv-passiv, und die vollständige Wiederherstellung einer Region kann bis zu 24 Stunden dauern.

Vom Kunden initiierte Notfallwiederherstellung

Die vom Kunden initiierte Notfallwiederherstellung ist nicht auf gekoppelte Regionen beschränkt.

Bevor ein regionaler Ausfall eintritt:

  • Stellen Sie einen zonenredundanten Storage Mover bereit, indem Sie Storage Mover-Ressourcen in einer Region erstellen, die Verfügbarkeitszonen unterstützt.

  • Erstellen Sie in regelmäßigen Abständen – entweder gemäß einem Zeitplan oder nach jeder wesentlichen Änderungen – eine Momentaufnahme Ihrer Storage Mover-Ressourcen. Das Speichern der Momentaufnahmen mithilfe eines Versionskontrollsystems ist eine gute Möglichkeit zum Speichern und Nachverfolgen des Verlaufs der Momentaufnahmen. Sie verwenden die letzte gute Momentaufnahme im Falle einer Katastrophe, in der Sie Ihre Ressourcen in einer neuen Region wiederherstellen müssen.

Während eines regionalen Ausfalls:

Sie haben zwei Möglichkeiten:

  • Wählen Sie aus zu warten, bis Azure die Region wiederhergestellt hat.
  • Minimieren Sie Ausfallzeiten, indem Sie Ihre Ressourcen in einer anderen Region erneut bereitstellen. Da der Zugriff auf Ihre Ressourcen während eines Ausfalls beeinträchtigt sein kann, sollten Sie die letzte gute Momentaufnahme Ihrer Ressourcen verwenden.

Tipp

Bei jeder dieser Strategien kann es erforderlich sein, dass Sie vor einer Katastrophe weitere Schritte unternehmen müssen, also prüfen und planen Sie entsprechend.

Bereitstellen von Ressourcen in einer anderen Region

Weitere Anweisungen zum Exportieren von Ressourcen als ARM (Azure Resource Manager)-Vorlage finden Sie in der Dokumentation zum Exportieren von Vorlagen.

Wenn sich Ihr Storage Mover und verwandte Ressourcen in einem Container ohne zusätzliche Ressourcen befinden, sollten Sie einen Ressourcengruppen-Export ausführen, um den aktuellen Zustand zu erfassen. Wenn Ihre Ressourcengruppe jedoch nicht verwandte Ressourcen enthält, müssen Sie die Ressourcen möglicherweise aus der Vorlage entfernen oder anderweitig ausschließen.

Vorhandene Agents können nicht in einer anderen Region erneut bereitgestellt werden. Wenn die Region, in der sie ursprünglich konfiguriert wurden, einen Ausfall erlebt, ist es eventuell nicht möglich, die Registrierung des Agents vollständig aufzuheben und ihn erneut zu registrieren. In diesem Dokument wird davon ausgegangen, dass neue Agents in einer neuen Region registriert werden.

Um die exportierte Vorlage für die Notfallwiederherstellung zu verwenden, sind einige Änderungen an der Vorlage erforderlich.

  • Entfernen Sie zunächst alle Microsoft.StorageMover/agents- und Microsoft.HybridCompute/machines-Ressourcen aus der Vorlage. Stellen Sie sicher, dass Sie auch alle Abhängigkeitsverweise zu diesen Ressourcen entfernen.
  • Entfernen Sie als Nächstes die agentResourceId-Eigenschaft aus allen Auftragsdefinitionen. Sie müssen sie nach der Bereitstellung einem neuen Agent zuweisen.
  • Aktualisieren Sie nach dem Entfernen aller Verweise auf Agent- und Hybrid Compute-Computerressourcen die Standorteigenschaft der Storage Mover-Ressource der obersten Ebene. Ersetzen Sie den Namen der aktuell bereitgestellten Region durch den Namen der neuen Region.
  • Ermitteln Sie schließlich, ob die vorhandene Speicherkontoressourcen-ID beibehalten werden soll. Ersetzen Sie es bei Bedarf durch ein anderes Speicherkonto.

Nachdem Sie die vorherigen Schritte abgeschlossen und überprüft haben, ob die Vorlagenparameter korrekt sind, ist die Vorlage für die Bereitstellung in einer neuen Region bereit. Sie sollten die Vorlage in einer neuen Ressourcengruppe bereitstellen, welche dieselbe Standardregion wie die Standorteigenschaft in der Vorlage aufweist.

Registrieren des neuen Agents

Führen Sie die Schritte im Artikel zum Bereitstellen eines Azure Storage Mover-Agents aus, um einen neuen Agent in der neuen Storage Mover-Ressource zu registrieren.

Zuweisen des Agents zu Auftragsdefinitionen

Nachdem der neue Agent registriert und als online gemeldet wurde, verwenden Sie das Azure-Portal oder PowerShell, um die vorhandenen Auftragsdefinitionen dem neuen Agent zuzuordnen. Das folgende PowerShell-Beispiel wird zur Vereinfachung bereitgestellt.

In der Definition eines neuen Migrationsauftrags finden Sie Anleitungen zum Zugreifen auf die Auftragsdefinitionen für Ihr Projekt.


## Update the agent in a job definition resource
$resourceGroupName  = "[Your resource group name]"
$storageMoverName   = "[Your storage mover name]"
$projectName        = "[Your project name]"
$jobDefName         = "[Your job definition name]"
$agentName          = "[The name of an agent previously registered to the same storage mover resource]"

Update-AzStorageMoverJobDefinition `
    -ResourceGroupName $resourceGroupName `
    -StorageMoverName $storageMoverName `
    -ProjectName $projectName `
    -Name $jobDefName `
    -AgentName $agentName

Gewähren des Agentzugriffs auf den Zielspeichercontainer

Sie müssen der verwalteten Identität die Rolle „Datenmitwirkender“ zuweisen, um einen Migrationsauftrag erfolgreich durchzuführen. Weisen Sie den systemseitig verwalteten Identitätszugriff der Hybrid Compute-Ressource der Ressource des Zielspeicherkontos zu. Der Artikel Zuweisen eines verwalteten Identitätszugriffs zu einer Ressource enthält Anleitungen zum Gewähren des Zugriffs auf die Zielressource.

Jetzt können Sie Migrationsaufträge mit den neu bereitgestellten Storage Mover-Ressourcen starten.

Nächste Schritte