Plan für Resilienz

Ihr Unternehmen oder Ihre Organisation verfügt über bestimmte Anforderungen für eine Reselient-Datenintegration. Verwenden Sie die Zeit zur Planung einer Integrationsarchitektur, die Ihren Anforderungen in ihren Vorgaben entspricht, bevor Sie mit dem Entwerfen von Details beginnen.

Resilienzanforderungen festlegen

Bevor Sie das Resilienzverfahren Ihrer Umgebung teilen, müssen Sie zuerst die Resilienz für Sie und Ihr Unternehmen definieren. Wie hoch sind die Kosten für den Ausfall Ihrer Integrationsprozesse?

Bei einigen Kunden ist ein Ausfall von einigen Minuten zulässig. Er verzögert nur einen Batchprozess, der ordnungsgemäß innerhalb des Verarbeitungsfensters ausgeführt wird. Für andere Kunden ergeben sogar einige Sekunden der Ausfall finanzielle Verluste, die eine direkte Auswirkung auf das Unternehmen haben.

Aus dieser Perspektive ist es wichtig, die folgenden Elemente zu betrachten:

Wie lange dauert der zulässige Ausfall in Ihrer Umgebung? Hier müssen Sie die Kosten für das Unternehmen im Falle eines Ausfalls definieren und umrechnen, wie sich der Ausfall mit der Dauer des Ausfalls verbreitet.
Welche Technologien werden verwendet, und wie können sie auf der erwarteten Serviceebene bereitstellen? Nehmen Sie einen Echtzeit- oder Batchansatz vor? Oder eine Kombination der beiden? Wie viele Daten werden verarbeitet?

Resilienzarchitektur definieren

Die Definition einer Resilienzarchitektur erfordert die Anzeige der End-to-End-Datenintegrationslösung.

Bei einem Integrationsprozess müssen Sie die folgenden Komponenten der Architektur berücksichtigen (sowohl Hardware als auch Software):

Resilienz des Quellsystems
Resilienz des Zielsystems
Resilienz der Staging Area, falls vorhanden
Resilienz der Datenintegrationstools
Resilienz der Orchestrierung (falls außerhalb des ETL-Tools)
Resilienz des Netzwerks (sowohl aus einer Konnektivitätsperspektive als auch aus einer Bandbreitenperspektive)

Außerdem sollten Sie die Anforderungen in Bezug auf Disaster Recovery und High Availability berücksichtigen. Was geschieht, wenn Sie das Data Center verlieren, in dem diese Infrastruktur installiert ist?

Die folgenden Elemente sind erforderlich, damit Ihre Oracle Data Integrator-Installation resilient ist:

Ihre Agents müssen redundant sein: JEE-Agents sind dafür ausgelegt, Resilienz zu bieten, dass ein Load Balancer die Last zwischen Agents verteilt.
Das Oracle Data Integrator-Repository muss auf einem Resilienzsystem ausgeführt werden: Eine Oracle RAC - oder Exadata-Installation wäre eine Mindestanforderung, sodass der Verlust eines Knotens nicht den Verlust der vollständigen Infrastruktur bedeutet. Für Oracle Cloud-Deployments stellt Oracle Database Exadata Cloud Service eine Resilienzlösung bereit.
Wenn Sie ein externes Produkt zur Orchestrierung der Oracle Data Integrator-Prozesse verwenden (z. B. Oracle Integration ), müssen Sie sicherstellen, dass dieses Produkt ebenfalls resilient ist.

Wenn Sie eine Disaster Recovery-Strategie berücksichtigen, sind dieselben Elemente wie oben beschrieben erforderlich. Deshalb müssen Sie Folgendes sicherstellen:

Sie haben eine (letzte ausreichende) Kopie des Oracle Data Integrator-Repositorys auf Ihrer DR-Site, sodass Sie Ihre Oracle Data Integrator-Prozesse weiter ausführen können.
Sie verfügen über Oracle Data Integrator-Agents in dieser DR-Site, um auf dieses Repository zuzugreifen.
Sie haben Zugriff auf die Quell- und Zielsysteme oder Zugriff auf eine Kopie der Quell- und Zielsysteme.

Für Oracle Data Integrator gibt es speziell zwei Elemente der Topologie, die validiert werden müssen:

Die IP-Adresse oder der Servername des Oracle Data Integrator-Arbeits-Repositorys wird im Oracle Data Integrator-Master-Repository gespeichert. Wenn sich der Name oder die IP-Adresse beim Wechsel zu Ihrer DR-Site ändern, müssen Sie sicherstellen, dass diese Informationen aktualisiert werden, bevor Sie Oracle Data Integrator starten.
Die IP-Adresse oder der Servername für die Quell- und Zielsysteme werden im Arbeits-Repository gespeichert. Es gibt zwei mögliche Strategien:
- Definieren Sie separate Kontexte für jede Umgebung (Primär und DR), sodass Sie zwei unterschiedliche physische Serverdefinitionen für jede logische Einheit haben können.
- Sie können auch die IP-Adressen oder Servernamen überschreiben, bevor Sie Oracle Data Integrator in der DR-Site starten.
In allen Fällen muss jedes Skript, das das SDK verwendet, das Informationen in den Oracle Data Integrator-Repositorys überschreibt, ein umgekehrtes Skript haben, um die Informationen in der Primärsite wiederherzustellen.

Plan für anfängliche und nachfolgende Ladevorgänge

Vorfälle müssen Sie einen etwas anderes Prozess für die anfängliche Belastung Ihres Zielsystems entwerfen, bevor Sie sich auf die regulären Ladevorgänge konzentrieren können (z. B. nahe in Echtzeit oder tägliche Batches).

Wenn Sie sich vor unerwünschten zukünftigen Ausfällen schützen möchten, ist es entscheidend, diese ersten Ladeprozesse beizubehalten und zu verwalten. Wenn die Möglichkeit besteht, einen ersten Ladevorgang (oder einen teilweisen anfänglichen Ladevorgang) erneut auszuführen, darf dies nur bei folgenden Situationen geschehen:

Ein wesentlicher Fehler wird bei der Gültigkeit der geladenen Daten ermittelt (fehlende Daten, ungültige Formel in ETL usw.).
Ein wesentlicher Ausfall tritt auf dem Zielsystem auf, was zu einem hohen Datenverlust führt.
Aus irgendeinem Grund können die Integrationsprozesse nicht für einen zu langen Zeitraum ausgeführt werden.

Wenn Sie anfängliche Ladevorgänge gleichzeitig ausführen können, können neue Umgebungen auch instanziiert werden.

Sie können diese Ladestrategien auch mit der Möglichkeit erweitern, eine frühere Belastung erneut anzuwenden (wie z. B. ein vorheriges Ziel für Daten). Dies kann eine Kombination aus einer teilweisen Bereinigung der geladenen Daten sowie einem teilweisen Ladevorgang erfordern.