Zuverlässigkeit in Azure Data Factory

Mit Azure Data Factory können Sie flexible und leistungsstarke Datenpipelinen für serverlose Datenintegration und Datentransformation erstellen. Als Azure-Dienst bietet Data Factory eine Reihe von Funktionen zur Unterstützung Ihrer Zuverlässigkeitsanforderungen.

Wenn Sie Azure verwenden, ist Zuverlässigkeit eine gemeinsame Verantwortung. Microsoft bietet eine Reihe von Funktionen zur Unterstützung von Resilienz und Wiederherstellung. Sie sind dafür verantwortlich, zu verstehen, wie diese Funktionen in allen von Ihnen verwendeten Diensten funktionieren, und die Funktionen auswählen, die Sie benötigen, um Ihre Geschäftsziele und Uptime-Ziele zu erfüllen.

In diesem Artikel wird beschrieben, wie Sie Data Factory für eine Vielzahl potenzieller Ausfälle und Probleme widerstandsfähig machen, einschließlich vorübergehender Fehler, Ausfall der Verfügbarkeitszone und Regionsausfälle. Darüber hinaus wird beschrieben, wie Sie Sicherungen verwenden können, um aus anderen Arten von Problemen wiederherzustellen, und hebt einige wichtige Informationen zum Service Level Agreement (Data Factory Service Level Agreement, SLA) hervor.

Übersicht über die Zuverlässigkeitsarchitektur

Data Factory besteht aus mehreren Infrastrukturkomponenten. Jede Komponente unterstützt die Infrastruktursicherheit auf verschiedene Weise.

Zu den Komponenten der Data Factory gehören:

• Der Zentrale Data Factory-Dienst, der Pipelinetrigger verwaltet und die Koordination der Pipelineaktivitäten überwacht. Der Kerndienst verwaltet auch Metadaten für jede Komponente in der Datenfactory. Microsoft verwaltet den Kerndienst.

• Integrationslaufzeiten (IRs), die eine Verbindung mit Datenspeichern herstellen und Aktivitäten ausführen, die in Ihrer Pipeline definiert sind. Es gibt verschiedene Arten von IRs.

  • Von Microsoft verwaltete IRs, diese beinhalten die Azure IR und die IR für Azure-SQL Server Integration Services (Azure-SSIS). Microsoft verwaltet die Komponenten, aus denen diese Laufzeiten bestehen. In einigen Szenarien konfigurieren Sie Einstellungen, die sich auf die Resilienz Ihrer IRs auswirken.

  • Selbstgehostete Integration Runtimes (SHIRs). Microsoft stellt Software bereit, die Sie auf Ihrer eigenen Computeinfrastruktur ausführen können, um einige Teile Ihrer Data Factory-Pipelines auszuführen. Sie sind für die Bereitstellung und Verwaltung von Computeressourcen und für die Resilienz dieser Computeressourcen verantwortlich.

Resilienz für vorübergehende Fehler

Vorübergehende Fehler sind kurze, zeitweilige Fehler in Komponenten. Sie treten häufig in einer verteilten Umgebung wie der Cloud auf und sind ein normaler Bestandteil von Vorgängen. Vorübergehende Fehler korrigieren sich nach kurzer Zeit. Es ist wichtig, dass Ihre Anwendungen vorübergehende Fehler behandeln können. Dies geschieht in der Regel durch Wiederholen betroffener Anforderungen.

Alle in der Cloud gehosteten Anwendungen sollten die Anleitung zur vorübergehenden Fehlerbehandlung von Azure befolgen, wenn sie mit cloudgehosteten APIs, Datenbanken und anderen Komponenten kommunizieren. Weitere Informationen finden Sie unter Empfehlungen zur Behandlung vorübergehender Fehler.

Wenn Sie Data Factory verwenden, ist es wichtig, sich auf vorübergehende Fehler vorzubereiten, insbesondere beim Entwerfen von Pipelines und Aktivitäten.

Idempotenz

Ihre Pipelineaktivitäten sollten idempotent sein, was bedeutet, dass sie mehrmals erneut ausgeführt werden können, ohne nachteilige Auswirkungen zu verursachen. Wenn ein vorübergehender Fehler wie ein Netzwerkausfall oder ein Ausfall der Verfügbarkeitszone auftritt, kann Data Factory Pipelineaktivitäten erneut ausführen. Diese Wiederholung kann doppelte Datensätze erzeugen.

Um das Einfügen doppelter Datensätze aufgrund eines vorübergehenden Fehlers zu verhindern, implementieren Sie die folgenden bewährten Methoden:

• Verwenden Sie eindeutige Bezeichner für jeden Datensatz, bevor Sie in die Datenbank schreiben. Dieser Ansatz kann Ihnen helfen, doppelte Datensätze zu finden und zu beseitigen.

• Verwenden Sie eine Upsert-Strategie für Connectors, die upsert unterstützen. Bevor das Einfügen doppelter Datensätze auftritt, verwenden Sie diesen Ansatz, um zu überprüfen, ob bereits ein Datensatz vorhanden ist. Wenn dies vorhanden ist, aktualisieren Sie sie. Wenn sie nicht vorhanden ist, fügen Sie sie ein. Beispiel: SQL-Befehle wie MERGE oder ON DUPLICATE KEY UPDATE verwenden diesen Upsert-Ansatz.

• Verwenden Sie Strategien für Kopieraktionen. Weitere Informationen finden Sie unter Datenkonsistenzüberprüfung in Kopieraktivitäten.

Wiederholungsrichtlinien

Sie können Wiederholungsrichtlinien verwenden, um Teile Ihrer Pipeline zu konfigurieren, damit sie bei Problemen wie vorübergehenden Fehlern in verbundenen Ressourcen den Vorgang wiederholen. In Data Factory können Sie Wiederholungsrichtlinien für die folgenden Pipelineobjekttypen konfigurieren:

• Auslöser für rollierendes Fenster
• Ausführungsaktivitäten

Weitere Informationen zum Ändern oder Deaktivieren von Wiederholungsrichtlinien für Auslöser und Aktivitäten Ihrer Data Factory finden Sie unter Pipelineausführung und -trigger.

Ausfallsicherheit bei Ausfällen von Verfügbarkeitszonen

Verfügbarkeitszonen sind physisch getrennte Gruppen von Rechenzentren innerhalb einer Azure-Region. Wenn eine Zone ausfällt, erfolgt ein Failover der Dienste zu einer der verbleibenden Zonen.

Data Factory unterstützt Zonenredundanz, die Ausfallsicherheit für Fehler in Verfügbarkeitszonen bietet.

Jeder Teil der Data Factory unterstützt Zonenredundanz:

• Kerndienst: Microsoft verwaltet die Komponenten im zentralen Data Factory-Dienst und verteilt sie über Verfügbarkeitszonen.

  Nach einem Zonenfehler garantiert Microsoft jedoch nicht den Zustand der Trigger mit rollierendem Fenster.

• Irs: Die Unterstützung von Zonenredundanz hängt vom Typ der von Ihnen verwendeten IR ab.

  • Eine Azure IR unterstützt Zonenredundanz, und Microsoft verwaltet diese Funktion.

    

  • Bei einer Azure-SSIS IR müssen Sie mindestens zwei Knoten bereitstellen. Diese Knoten werden automatisch verschiedenen Verfügbarkeitszonen zugeordnet.

    Das folgende Diagramm zeigt eine zonenredundante Pipeline und eine Azure-SSIS Integrationslaufzeit mit zwei Knoten, die in verschiedenen Zonen bereitgestellt werden:

    

  • Eine SHIR überträgt Ihnen die Verantwortung für die Bereitstellung der Computeinfrastruktur zum Hosten der Runtime. Sie können mehrere Knoten bereitstellen, z. B. einzelne virtuelle Computer (VMs), und sie für hohe Verfügbarkeit konfigurieren. Sie können diese Knoten dann über mehrere Verfügbarkeitszonen verteilen. Weitere Informationen finden Sie unter Hohe Verfügbarkeit und Skalierbarkeit.

Anforderungen

Zonenredundante Data Factory-Ressourcen können in jeder Region bereitgestellt werden, die Verfügbarkeitszonen unterstützt.

Kosten

• Kerndienst: Für Zonenredundanz gelten keine zusätzlichen Kosten.

• Irs: Die Kosten der Zonenredundanz variieren je nach Art der verwendeten IR.

  • Eine Azure IR umfasst Zonenredundanz ohne zusätzliche Kosten.

  • Eine Azure-SSIS IR erfordert, dass Sie mindestens zwei Knoten bereitstellen, um Zonenredundanz zu erzielen. Weitere Informationen dazu, wie jeder Knoten abgerechnet wird, finden Sie unter Preisbeispiel: Ausführen von SSIS-Paketen auf einer Azure-SSIS IR.

  • Ein SHIR erfordert, dass Sie die Computeinfrastruktur bereitstellen und verwalten. Um die Zonenresilienz zu erreichen, müssen Sie Ihre Computeressourcen über mehrere Zonen verteilen. Je nach Anzahl der von Ihnen bereitgestellten Knoten und deren Konfiguration entstehen möglicherweise zusätzliche Kosten aus den zugrunde liegenden Computediensten und anderen unterstützenden Diensten. Es gibt keine zusätzliche Gebühr, um den SHIR auf mehreren Knoten auszuführen.

Konfigurieren der Unterstützung von Verfügbarkeitszonen

• Kerndienst: Es ist keine Konfiguration erforderlich. Der Data Factory-Kerndienst unterstützt automatisch Zonenredundanz.

• Irs:

  • Azure IR: Es ist keine Konfiguration erforderlich. Die Azure IR aktiviert automatisch Zonenredundanz.

  • Azure-SSIS IR: Keine Konfiguration erforderlich. Eine Azure-SSIS IR ermöglicht automatisch Zonenredundanz, wenn sie mit zwei oder mehr Knoten bereitgestellt wird.

  • Ein SHIR erfordert, dass Sie Ihre eigene Resilienz konfigurieren, was die Verbreitung Ihrer Knoten über mehrere Verfügbarkeitszonen umfasst.

Kapazitätsplanung und -verwaltung

• Kerndienst: Der Data Factory-Kerndienst wird automatisch basierend auf Bedarf skaliert, und Sie müssen keine Kapazität planen oder verwalten.

• Irs:

  • Eine Azure IR skaliert automatisch basierend auf Bedarf, und Sie müssen keine Kapazität planen oder verwalten.

  • Eine Azure-SSIS IR erfordert, dass Sie die Anzahl der verwendeten Knoten speziell konfigurieren. Zur Vorbereitung auf den Ausfall einer Verfügbarkeitszone sollten Sie die Überbereitstellung der Kapazität Ihrer IR in Betracht ziehen. Durch Überbereitstellung kann die Lösung einen gewissen Kapazitätsverlust tolerieren und ohne beeinträchtigte Leistung weiter funktionieren. Weitere Informationen finden Sie unter Kapazität durch Überbereitstellung verwalten.

  • Ein SHIR erfordert, dass Sie Ihre eigene Kapazität und Skalierung konfigurieren. Erwägen Sie die Überbereitstellung beim Bereitstellen einer SHIR.

Verhalten, wenn alle Zonen fehlerfrei sind

In diesem Abschnitt wird beschrieben, was Sie erwarten müssen, wenn Data Factory-Ressourcen für Zonenredundanz konfiguriert und alle Verfügbarkeitszonen betriebsbereit sind.

• Verkehrslenkung zwischen Zonen: Während des Standardbetriebs verteilt Data Factory automatisch Pipelineaktivitäten, Trigger und andere Arbeiten auf funktionierende Instanzen in jeder Verfügbarkeitszone.

• Datenreplikation zwischen Zonen: Im Allgemeinen ist Data Factory ein zustandsloser Dienst, sodass kein Zustand zwischen Zonen repliziert werden muss.

  Allerdings enthalten Trigger mit rollierendem Fenster einen Zustand, der möglicherweise nicht vollständig zwischen Zonen repliziert wird.

Verhalten bei einem Zoneausfall

In diesem Abschnitt wird beschrieben, was Sie erwarten müssen, wenn Data Factory-Ressourcen für Zonenredundanz konfiguriert sind und eine Verfügbarkeitszone ausfällt.

• Erkennung und Reaktion: Die Data Factory-Plattform ist dafür verantwortlich, einen Fehler in einer Verfügbarkeitszone zu erkennen und darauf zu reagieren. Sie müssen nichts tun, um ein Zonenfailover in Ihren Pipelines oder anderen Komponenten zu initiieren.

• Benachrichtigung: Microsoft benachrichtigt Sie nicht automatisch, wenn eine Zone deaktiviert ist. Sie können jedoch Azure Resource Health verwenden, um den Status einer einzelnen Ressource zu überwachen, und Sie können Ressourcenintegritätswarnungen einrichten, um Sie über Probleme zu informieren. Sie können auch Azure Service Health verwenden, um die allgemeine Integrität des Diensts zu verstehen, einschließlich jeglicher Zonenfehler, und Sie können Dienststatuswarnungen einrichten, um Sie über Probleme zu informieren.

• Aktive Anforderungen: Alle ausgeführten Pipelines und Trigger werden weiterhin ausgeführt, und es treten keine unmittelbaren Unterbrechungen aufgrund eines Zonenausfalls auf. Aktivitäten, die während eines Zonenfehlers ausgeführt werden, können jedoch fehlschlagen und neu gestartet werden. Es ist wichtig, Aktivitäten zu entwerfen, die idempotent sind, was ihnen hilft, sich von Zonenfehlern und anderen Fehlern zu erholen. Weitere Informationen finden Sie unter Resilienz für vorübergehende Fehler.

• Erwartete Ausfallzeiten: Während eines Zonenausfalls wird keine Ausfallzeit erwartet.

• Erwarteter Datenverlust: Insgesamt ist Data Factory ein zustandsloser Dienst, sodass während eines Zonenfehlers kein Datenverlust erwartet wird.

  Wenn Sie jedoch einen Trigger mit rollierendem Fenster verwenden, kann der Zustand des Triggers nach einem Zonenfehler verloren gehen. Sie sollten alle Trigger neu starten oder wieder ausführen, die während des Zonenfehlers aktiv waren.

Zonenwiederherstellung

Wenn die Verfügbarkeitszone wiederhergestellt wird, führt Data Factory automatisch ein Failback auf die ursprüngliche Zone durch. Sie müssen nichts tun, um ein Zonenfailback in Ihren Pipelines oder anderen Komponenten zu initiieren.

Wenn Sie jedoch einen SHIR verwenden, müssen Sie ihre Computeressourcen möglicherweise neu starten, wenn sie beendet wurden.

Test auf Zonenfehler

Für den Kerndienst sowie für Azure und Azure-SSIS IRs übernimmt Data Factory Routing, Failover und Failback des Datenverkehrs für zonenredundante Ressourcen. Da dieses Feature vollständig verwaltet ist, müssen Sie die Ausfallprozesse für Verfügbarkeitszonen weder einleiten noch überprüfen.

Für SHIRs können Sie Azure Chaos Studio verwenden, um einen Verfügbarkeitszonenfehler auf einer Azure-VM zu simulieren.

Widerstandsfähigkeit bei regionalen Ausfällen

Data Factory-Ressourcen werden in einer einzigen Azure-Region bereitgestellt. Wenn die Region nicht verfügbar ist, ist Ihre Datenfabrik ebenfalls betroffen. Es gibt jedoch Ansätze, die Sie verwenden können, um die Ausfallsicherheit bei regionalen Ausfällen sicherzustellen. Diese Ansätze hängen davon ab, ob sich die Datenfabrik in einer gekoppelten oder nicht gekoppelten Region befindet und von Ihren spezifischen Anforderungen und Konfigurationen abhängt.

Von Microsoft verwaltetes Failover auf eine gekoppelte Region

Data Factory unterstützt von Microsoft verwaltetes Failover für Datenfabriken in gekoppelten Regionen, mit Ausnahme von Brasilien Süd- und Südostasien. Im unwahrscheinlichen Fall eines längeren Regionsfehlers initiiert Microsoft möglicherweise ein regionales Failover Ihrer Data Factory-Instanz.

Aufgrund der Datenresidenzanforderungen in den Regionen „Brasilien, Süden“ und „ Asien, Südosten“ werden Data Factory-Daten mithilfe von zonenredundantem Azure Storage-Speicher nur in der lokalen Region gespeichert. Für Südostasien werden alle Daten in Singapur gespeichert. Für Brasilien Süd werden alle Daten in Brasilien gespeichert.

Für Datenfabriken in ungepaarten Regionen oder in Brasilien Süd sowie in Südostasien führt Microsoft in Ihrem Auftrag kein regionales Failover durch.

Failover von IRs

Um sich auf ein Failover vorzubereiten, gibt es möglicherweise einige zusätzliche Überlegungen, je nachdem, welche IR Sie verwenden.

• Sie können Azure IR so konfigurieren, dass die Region, die sie verwendet, automatisch aufgelöst wird. Wenn die Region auf Automatisch auflösen festgelegt ist und es zu einem Ausfall in der primären Region kommt, wird für die Azure IR automatisch ein Failover auf die gekoppelte Region ausgeführt. Dieses Failover unterliegt Einschränkungen. Um die Azure IR-Region für Ihre Aktivitätsimplementierung oder den Versand im IR-Setup zu konfigurieren, legen Sie die Region so fest, dass sie automatisch aufgelöst wird.

• Das Failover der Azure-SSIS IR wird separat vom von Microsoft verwalteten Failover der Data Factory-Instanz verwaltet. Weitere Informationen finden Sie unter benutzerdefinierte Lösungen mit mehreren Regionen zur Resilienz.

• Ein SHIR wird auf der Infrastruktur ausgeführt, für die Sie verantwortlich sind, sodass ein von Microsoft verwaltetes Failover nicht für SHIRs gilt. Weitere Informationen finden Sie unter benutzerdefinierte Lösungen mit mehreren Regionen zur Resilienz.

Rekonfiguration nach einem Failover

Nachdem ein von Microsoft verwaltetes Failover abgeschlossen ist, können Sie in der gekoppelten Region auf Ihre Data Factory-Pipeline zugreifen. Nach Abschluss des Failovers müssen Sie möglicherweise eine Neukonfiguration für IRs oder andere Komponenten durchführen. Dieser Prozess umfasst die erneute Einrichtung der Netzwerkkonfiguration.

Benutzerdefinierte Lösungen mit mehreren Regionen für Resilienz

Wenn Ihre Pipelines für regionale Ausfälle ausfallsicher sein müssen und Sie die Kontrolle über den Failoverprozess benötigen, sollten Sie eine metadatengesteuerte Pipeline verwenden.

• Richten Sie die Quellcodeverwaltung für Data Factory ein , um alle Änderungen ihrer Metadaten nachzuverfolgen und zu überwachen. Sie können diesen Ansatz verwenden, um auf Ihre METADATEN-JSON-Dateien für Pipelines, Datasets, verknüpfte Dienste und Trigger zuzugreifen. Data Factory unterstützt verschiedene Git-Repositorytypen, z. B. Azure DevOps und GitHub. Weitere Informationen finden Sie unter Quellcodeverwaltung in Data Factory.

• Verwenden Sie ein kontinuierliches Integrations- und kontinuierliches Bereitstellungssystem (CI/CD), z. B. Azure DevOps, um Ihre Pipelinemetadaten und -bereitstellungen zu verwalten. Sie können CI/CD verwenden, um Vorgänge schnell in einer Instanz in einer anderen Region wiederherzustellen. Wenn eine Region nicht verfügbar ist, können Sie eine neue Datenfabrik manuell oder automatisch bereitstellen. Nachdem die neue Data Factory erstellt wurde, können Sie Ihre Pipelines, Datasets und verknüpften Dienste JSON aus dem vorhandenen Git-Repository wiederherstellen. Weitere Informationen finden Sie unter Business Continuity and Disaster Recovery (BCDR) für Data Factory- und Azure Synapse Analytics-Pipelines.

Je nach der von Ihnen verwendeten IR gibt es möglicherweise andere Überlegungen.

• Eine Azure-SSIS IR verwendet eine Datenbank, die in der Azure SQL-Datenbank oder in der verwalteten Azure SQL-Instanz gespeichert ist. Sie können die Georeplikation oder eine Failovergruppe für diese Datenbank konfigurieren. Die Azure-SSIS-Datenbank befindet sich in einer primären Azure-Region mit Lese-/Schreibzugriff. Die Datenbank wird kontinuierlich in einen sekundären Bereich repliziert, der schreibgeschützten Zugriff hat. Wenn der primäre Bereich nicht verfügbar ist, löst ein Failover aus, wodurch die primären und sekundären Datenbanken Rollen austauschen.

  Sie können auch ein Dual-Standby-Azure SSIS IR-Paar konfigurieren, das mit einer Azure SQL-Datenbank oder einer SQL Managed Instance-Failovergruppe synchronisiert wird.

  Weitere Informationen finden Sie unter Konfigurieren eines Azure-SSIS IR für BCDR.

• Ein SHIR wird auf der von Ihnen verwalteten Infrastruktur ausgeführt. Wenn der SHIR auf einer Azure-VM bereitgestellt wird, können Sie Azure Site Recovery verwenden, um vm-Failover in eine andere Region auszulösen.

Sichern und Wiederherstellen

Data Factory unterstützt CI/CD über die Integration der Quellcodeverwaltung, sodass Sie die Metadaten einer Data Factory-Instanz sichern können. CI/CD-Pipelines stellen diese Metadaten nahtlos in einer neuen Umgebung bereit. Weitere Informationen finden Sie unter CI/CD in Data Factory.

Service-Level-Vereinbarung

Der Service level agreement (SLA) für Azure-Dienste beschreibt die erwartete Verfügbarkeit jedes Diensts und die Bedingungen, die Ihre Lösung erfüllen muss, um diese Verfügbarkeitserwartungen zu erreichen. Weitere Informationen finden Sie unter SLAs für Onlinedienste.

Data Factory bietet separate Verfügbarkeits-SLAs für:

• Die Erfolgsquote von API-Aufrufen, die Sie tätigen, z. B. die zum Verwalten Ihrer Datenfactory.
• Die Anzahl der Aktivitätsausführungen, die mit der Ausführung beginnen.

Aktivitätsläufe dürfen kurz verzögert werden und erfordern, dass alle Abhängigkeiten zum Ausführen des Auftrags erfüllt wurden.

Verwandte Inhalte

• Zuverlässigkeit in Azure