Freigeben über

BCDR für Azure Data Factory- und Azure Synapse Analytics-Pipelines

Azure Data Factory
Azure Repos
Azure Synapse Analytics
GitHub

Notfälle können Hardwareausfälle, Naturkatastrophen oder Softwarefehler sein. Der Prozess der Vorbereitung auf und Wiederherstellung nach einem Notfall wird als Notfallwiederherstellung (Disaster Recovery, DR) bezeichnet. In diesem Artikel werden empfohlene Methoden zum Erreichen der Geschäftskontinuität und Notfallwiederherstellung (Business Continuity & Disaster Recovery, BCDR) für Azure Data Factory- und Azure Synapse Analytics-Pipelines erläutert.

BCDR-Strategien umfassen Redundanz durch Verfügbarkeitszonen, automatisierte Wiederherstellung durch Azure-Notfallwiederherstellung sowie benutzerseitig verwaltete Wiederherstellung mithilfe von CI/CD (Continuous Integration/Continuous Delivery).

Aufbau

Diagramm, das Verfügbarkeitszonen und Regionen für Azure Synapse Analytics- und Data Factory-Pipelines BCDR zeigt.

Laden Sie eine Visio-Datei dieser Architektur herunter.

Arbeitsablauf

  1. Data Factory- und Azure Synapse-Pipelines erzielen Resilienz mithilfe von Azure-Regionen und Azure-Verfügbarkeitszonen.

    • Jede Azure-Region verfügt über eine Gruppe von Rechenzentren, die in einem durch die Latenz definierten Umkreis bereitgestellt werden.
    • Azure-Verfügbarkeitszonen sind physisch getrennte Standorte innerhalb der einzelnen Azure-Regionen, die Fehlertoleranz bei lokalen Ausfällen bieten.
    • Alle Azure-Regionen und -Verfügbarkeitszonen sind über ein dediziertes, regionales, latenzarmes Netzwerk sowie über ein Hochleistungsnetzwerk verbunden.
    • Um Resilienz sicherzustellen, sind in allen für Verfügbarkeitszonen aktivierten Regionen drei separate Verfügbarkeitszonen vorhanden.

  2. Wenn ein Rechenzentrum, ein Teil eines Rechenzentrums oder eine Verfügbarkeitszone in einer Region ausfällt, erfolgt ein Failover ohne jegliche Ausfallzeiten für zonenresiliente Data Factory- und Azure Synapse-Pipelines.

Komponenten

Szenariodetails

Data Factory- und Azure Synapse-Pipelines speichern Artefakte, die die folgenden Daten umfassen:

Metadaten

  • Rohrleitung
  • Datensätze
  • Verknüpfte Dienste
  • Integrationslaufzeit
  • Auslöser

Überwachen von Daten

  • Rohrleitung
  • Auslöser
  • Aktivitätsausführungen

Notfälle können auf unterschiedliche Weise eintreten, z. B. Hardwareausfälle, Naturkatastrophen oder Softwarefehler, die auf menschliche Fehler oder Cyberangriffe zurückzuführen sind. Abhängig von den Arten von Fehlern können deren geografische Auswirkungen regional oder global sein. Berücksichtigen Sie bei der Planung einer Notfallwiederherstellungsstrategie sowohl die Art des Notfalls als auch seine geografischen Auswirkungen.

BCDR in Azure arbeitet mit einem Modell der gemeinsamen Verantwortung. Bei vielen Azure-Diensten ist es erforderlich, dass Kunden ihre Notfallwiederherstellungsstrategie explizit einrichten, während Azure bei Bedarf die Baselineinfrastruktur und Plattformdienste bereitstellt.

Sie können die folgenden empfohlenen Methoden verwenden, um BCDR für Data Factory- und Azure Synapse-Pipelines in verschiedenen Fehlerszenarien zu erreichen. Implementierung finden Sie unter Bereitstellen dieses Szenarios.

Automatisierte Wiederherstellung mit Azure-Notfallwiederherstellung

Wenn bei der automatisierten Wiederherstellung Sicherung und Notfallwiederherstellung ein vollständiger regionaler Ausfall für eine Azure-Region mit einer gekoppelten Region, Data Factory- oder Azure Synapse-Pipelines vorhanden ist, tritt beim Einrichten der automatisierten Wiederherstellung automatisch ein Failover auf die gekoppelte Region auf. Ausnahmen sind die Regionen „Asien, Südosten“ und „Brasilien“, in denen Datenresidenzanforderungen erfordern, dass Daten in diesen Regionen verbleiben.

Beim Failover zwecks Notfallwiederherstellung stellt Data Factory die Produktionspipelines wieder her. Wenn Sie Ihre wiederhergestellten Pipelines überprüfen müssen, können Sie die Azure Resource Manager-Vorlagen für Ihre Produktionspipelines im Geheimnisspeicher sichern und die wiederhergestellten Pipelines mit den Sicherungen vergleichen.

Das Azure Global-Team führt regelmäßige BCDR-Drills durch, an denen Azure Data Factory und Azure Synapse Analytics teilnehmen. Ein BCDR-Drill simuliert einen Regionsausfall und führt einen Failover von Azure-Diensten in eine gekoppelte Region ohne Kundenbeteiligung durch. Weitere Informationen zu den BCDR-Drills finden Sie unter "Testen von Diensten".

Benutzerseitig verwaltete Redundanz mit CI/CD

Um BCDR im Falle eines Ausfalls einer ganzen Region zu erzielen, benötigen Sie eine Data Factory oder Azure Synapse-Arbeitsbereich in der sekundären Region. Bei versehentlichem Löschen einer Data Factory- oder Azure Synapse-Pipeline, bei Ausfällen oder internen Wartungsereignissen können Sie Git und CI/CD verwenden, um die Pipelines manuell wiederherzustellen.

Optional können Sie eine Aktiv/Passiv-Implementierung verwenden. Die primäre Region verarbeitet normale Vorgänge und bleibt aktiv, während für die sekundäre Notfallwiederherstellungsregion je nach spezifischer Implementierung vorausgeplante Schritte erforderlich sind, um zur primären Region höhergestuft zu werden. In diesem Fall sind alle erforderlichen Konfigurationen für die Infrastruktur in der sekundären Region verfügbar, aber nicht bereitgestellt.

Mögliche Anwendungsfälle

Benutzerseitig verwaltete Redundanz ist nützlich in Szenarien wie:

  • Versehentliches Löschen von Pipelineartefakten aufgrund menschlichen Versagens.
  • Umfangreiche Ausfälle oder Wartungsereignisse, die keine BCDR auslösen, weil kein Notfall gemeldet wird.

Sie können Ihre Produktionsworkloads schnell in andere Regionen verschieben, wodurch Sie dann von dem Notfall nicht betroffen sein.

Überlegungen

Diese Überlegungen bilden die Säulen des Azure Well-Architected Framework, einer Reihe von Leitprinzipien, die Sie zur Verbesserung der Qualität eines Workloads verwenden können. Weitere Informationen finden Sie unter Well-Architected Framework.

Zuverlässigkeit

Zuverlässigkeit trägt dazu bei, dass Ihre Anwendung die Verpflichtungen erfüllen kann, die Sie für Ihre Kunden vornehmen. Weitere Informationen finden Sie in der Prüfliste zur Entwurfsüberprüfung für Zuverlässigkeit.

Data Factory- und Azure Synapse-Pipelines sind gängige Azure-Dienste, die Verfügbarkeitszonen unterstützen, und sie sind so konzipiert, dass sie das richtige Maß an Resilienz und Flexibilität zusammen mit extrem niedriger Latenz bieten.

Mit dem benutzerseitig verwalteten Wiederherstellungsansatz können Sie den Betrieb fortsetzen, wenn in der primären Region Wartungsereignisse, Ausfälle oder menschliche Fehler auftreten. Mithilfe von CI/CD können die Data Factory- und Azure Synapse-Pipelines in ein Git-Repository integriert und zur sofortigen Wiederherstellung in einer sekundären Region bereitgestellt werden.

Kostenoptimierung

Die Kostenoptimierung konzentriert sich auf Möglichkeiten, unnötige Ausgaben zu reduzieren und die betriebliche Effizienz zu verbessern. Weitere Informationen finden Sie in der Prüfliste für die Entwurfsüberprüfung für die Kostenoptimierung.

Die benutzerseitig verwaltete Wiederherstellung integriert Data Factory in Git mithilfe von CI/CD und verwendet optional eine sekundäre Notfallwiederherstellungsregion, die über alle erforderlichen Infrastrukturkonfigurationen als Sicherung verfügt. Dieses Szenario kann zusätzliche Kosten verursachen. Verwenden Sie zum Schätzen der Kosten den Azure-Preisrechner.

Beispiele für Data Factory- und Azure Synapse Analytics-Preise finden Sie unter:

Operative Exzellenz

„Optimaler Betrieb“ deckt die Betriebsprozesse ab, die für die Bereitstellung einer Anwendung und deren Ausführung in der Produktion sorgen. Weitere Informationen finden Sie in der Prüfliste zur Entwurfsüberprüfung für Operational Excellence.

Mithilfe des benutzerseitig verwalteten CI/CD-Wiederherstellungsansatzes können Sie Integrationen in Azure Repos oder GitHub durchführen. Weitere Informationen zu bewährten CI/CD-Methoden finden Sie unter Bewährte Methoden für CI/CD.

Bereitstellen dieses Szenarios

Führen Sie die folgenden Aktionen aus, um eine automatisierte oder benutzerseitig verwaltete Notfallwiederherstellung für Data Factory- und Azure Synapse-Pipelines einzurichten.

Einrichten der automatisierten Wiederherstellung

In Data Factory können Sie die Azure-Integrationslaufzeit (IR)-Region für die Ausführung Ihrer Aktivität oder den Versand im Setup der Integrationslaufzeit festlegen. Um das automatische Failover im Falle eines vollständigen regionalen Ausfalls zu aktivieren, legen Sie die Region auf " Automatische Auflösung" fest.

Screenshot der Option

Im Kontext der Integrationslaufzeiten schlägt IR beim Auswählen der automatischen Auflösung als IR-Region automatisch zum gekoppelten Bereich fehl. Für andere spezifische Standortregionen können Sie eine sekundäre Data Factory in einer anderen Region erstellen und CI/CD verwenden, um Ihre Data Factory aus dem Git-Repository bereitzustellen.

Verknüpfte Dienste sind nach einem Failover aufgrund ausstehender privater Endpunkte im neueren Netzwerk der Region nicht vollständig aktiviert. Sie müssen private Endpunkte in der wiederhergestellten Region konfigurieren. Sie können die Erstellung privater Endpunkte mithilfe der Genehmigungs-API automatisieren.

Einrichten der benutzerseitig verwalteten Wiederherstellung über CI/CD

Sie können Git und CI/CD verwenden, um Pipelines im Falle der Löschung einer Data Factory- oder Azure Synapse-Pipeline manuell wiederherzustellen.

Wenn Sie benutzerseitig verwaltete Redundanz mithilfe von CI/CD bereitstellen, führen Sie die folgenden Aktionen aus:

Trigger deaktivieren

Deaktivieren Sie Trigger in der ursprünglichen primären Data Factory, sobald sie wieder online ist. Sie können die Trigger manuell deaktivieren oder eine Automatisierung implementieren, um die Verfügbarkeit der ursprünglichen primären Instanz in regelmäßigen Abständen zu überprüfen. Deaktivieren Sie unmittelbar nach der Wiederherstellung der Factory alle Trigger für die ursprüngliche primäre Data Factory.

Informationen zur Verwendung von Azure PowerShell zum Deaktivieren oder Aktivieren von Data Factory-Triggern finden Sie unter Beispiel für Skripts undCI/CD-Verbesserungen im Zusammenhang mit Pipelinetriggern.

Umgang mit doppelten Schreibvorgängen

Die meisten ETL-Pipelines (Extrahieren, Transformieren, Laden) sind für die Handhabung doppelter Schreibvorgänge konzipiert, da diese für Abgleich und Neuformulierung erforderlich sind. Datensenken, die transparentes Failover unterstützen, können doppelte Schreibvorgänge durch Zusammenführen von Datensätzen oder durch Löschen und Einfügen aller Datensätze in dem spezifischen Zeitbereich verarbeiten.

Bei Datensenken, die Endpunkte nach einem Failover ändern, kann es im primären und sekundären Speicher zu doppelten oder teilweisen Daten kommen. Sie müssen die Daten manuell zusammenführen.

Überprüfen des Zeugen und Steuern des Pipelineflusses (optional)

Im Allgemeinen müssen Sie Ihre Pipelines so entwerfen, dass sie Aktivitäten wie Fehler- und Lookup-Aktivitäten für das Neustarten fehlerhafter Pipelines vom „Point of Interest“ einschließen.

  1. Fügen Sie einen globalen Parameter in Ihrer Data Factory hinzu, um die Region anzugeben, z. B. region='EastUS' in der primären und region='CentralUS' in der sekundären Data Factory.

  2. Erstellen Sie einen Zeugen in einer dritten Region. Der Zeuge kann ein REST-Aufruf oder ein beliebiger Speichertyp sein. Der Zeuge gibt standardmäßig die aktuelle primäre Region zurück, z. B 'EastUS'.

  3. Wenn ein Notfall eintritt, aktualisieren Sie den Zeugen manuell, sodass die neue primäre Region zurückgegeben wird, z. B 'CentralUS'.

  4. Fügen Sie in Ihrer Pipeline eine Aktivität hinzu, um den Zeugen nachzuschlagen und den aktuellen primären Wert mit dem globalen Parameter zu vergleichen.

    • Wenn die Parameter übereinstimmen, wird diese Pipeline in der primären Region ausgeführt. Fahren Sie mit der eigentlichen Arbeit fort.
    • Wenn die Parameter nicht übereinstimmen, wird diese Pipeline in der sekundären Region ausgeführt. Geben Sie nur das Ergebnis zurück.

Hinweis

Dieser Ansatz führt eine Abhängigkeit vom Zeugenlookup in Ihre Pipeline ein. Wenn der Zeuge nicht gelesen werden kann, werden alle Pipelineausführungen angehalten.

Beitragende

Dieser Artikel wird von Microsoft gepflegt. Er wurde ursprünglich von folgenden Mitwirkenden geschrieben:

Hauptautoren:

Andere Mitwirkende:

  • Mario Zimmermann | Principal Software Engineering Manager – Azure Data Factory-Team
  • Wee Hyong Tok | Hauptdirektor von PM – Azure Data Factory-Team

Um nicht öffentliche LinkedIn-Profile anzuzeigen, melden Sie sich bei LinkedIn an.

Nächste Schritte