Plan de résilience

Déterminer les exigences en matière de résilience

Avant de divulguer dans ce qui rendra votre environnement résilient, vous devez d'abord définir ce que vous signifie résilience et votre entreprise. En d'autres termes, quel est le coût associé à une coupure des processus d'intégration ?

Pour certains clients, une coupure de quelques minutes est acceptable et ne retarde que partiellement un processus en batch exécuté correctement dans sa fenêtre de traitement. Pour les autres clients, même quelques secondes d'indisponibilité entraînent des pertes financières dont l'impact est direct sur l'entreprise.

Du point de vue, il est important de consulter les éléments suivants :

Quelle est la durée d'une coupure acceptable dans votre environnement ? Vous devez définir ici le coût de l'activité en cas de coupure, et visualiser l'évolution de cette coupure et la durée de cette dernière.
Quelles sont les technologies utilisées et comment elles peuvent être fournies sur le niveau de service attendu ? Utilisez-vous une approche en temps réel ou par lots ? Ou une combinaison des deux ? Quelle est la quantité de données que vous traitez ?

Définir une architecture résiliente

La définition d'une architecture résiliente nécessite de consulter la solution d'intégration des données de bout en bout.

Dans le cas d'un processus d'intégration, vous devez prendre en compte les composants suivants de l'architecture (à la fois matériels et logiciels) :

Résilience du système source
Résilience du système cible
Résilience de la zone intermédiaire si elle est utilisée
Résilience des outils d'intégration de données
Résilience de l'orchestration (en dehors de l'outil ETL)
Résilience du réseau (du point de vue de la connectivité et du point de vue de la bande passante)

Vous devez également prendre en compte les exigences en matière de récupération après sinistre et de haute disponibilité. Que se passe-t-il en cas de perte du centre de données dans lequel cette infrastructure est installée ?

Les éléments suivants sont requis pour que votre installation Oracle Data Integrator soit résiliente :

Vos agents doivent être redondants : les agents JEE sont conçus pour fournir une résilience dans laquelle un équilibreur de charge distribuera la charge entre les agents.
Le référentiel Oracle Data Integrator doit être exécuté sur un système résilient : une installation Oracle RAC ou Exadata constitue une exigence minimale, de sorte que la perte d'un noeud ne signifie pas la perte de l'infrastructure complète. Pour les déploiements Oracle Cloud, Oracle Database Exadata Cloud Service fournit une solution résiliente.
Si vous utilisez un produit externe pour orchestrer les processus Oracle Data Integrator ( Oracle Integration, par exemple), vous devez vous assurer que ce produit est également résilient.

Si vous prenez en compte une stratégie de récupération après sinistre, les mêmes éléments que ceux décrits ci-dessus sont requis ; vous devrez donc vous assurer que :

Vous disposez d'une copie (suffisamment récente) du référentiel Oracle Data Integrator dans votre site DR pour pouvoir continuer à exécuter vos processus Oracle Data Integrator.
Des agents Oracle Data Integrator sont disponibles sur ce site de récupération après sinistre pour accéder à ce référentiel.
Vous avez accès aux systèmes source et cible, ou à une copie des systèmes source et cible.

Pour Oracle Data Integrator, il existe deux éléments de topologie à valider :

L'adresse IP ou le nom de serveur du référentiel de travail Oracle Data Integrator est stocké dans le référentiel maître Oracle Data Integrator. Si le nom ou l'adresse IP change lorsque vous passez sur votre site DR, vous devez vous assurer que ces informations sont mises à jour avant de démarrer Oracle Data Integrator.
L'adresse IP ou le nom de serveur des systèmes source et cible est stocké dans le référentiel de travail. Il existe deux stratégies possibles :
- Définir des contextes distincts pour chaque environnement (principal et DR) qui vous permettent d'avoir deux définitions de serveur physique distinctes pour chaque unité logique.
- Ou n'écrasez pas l'adresse IP ou les noms de serveur avant de démarrer Oracle Data Integrator sur le site DR.
Dans tous les cas, tout script utilisant le kit SDK qui écrase les informations des référentiels Oracle Data Integrator doit disposer d'un script inverse pour restaurer les informations du site principal.

Planification des chargements initiaux et successifs

Les causes sont les suivantes : vous devez concevoir un processus légèrement différent pour le chargement initial du système cible avant de pouvoir vous concentrer sur vos charges normales (telles que les lots quotidiens ou en temps réel).

Ainsi, si vous souhaitez vous protéger contre les coupures futures non libellé, il est crucial de conserver et de tenir à jour ces processus de chargement initiaux. Possibilité de réexécuter une charge initiale (ou une charge initiale partielle) ne doit jamais être sous-estimée, en particulier en cas de face aux situations suivantes :

Un problème majeur est détecté dans la validité des données chargées (données manquantes, formule non valide dans le traitement ETL, etc.).
Une panne importante se produit sur le système cible, ce qui entraîne une perte de données importante.
Pour une raison quelconque de l'échec de l'exécution des processus d'intégration pendant une période trop longue.

L'exécution des chargements initiaux peut également permettre d'instancier de nouveaux environnements.

Vous pouvez également améliorer ces stratégies de chargement avec la possibilité de réappliquer un précédent chargement (comme un mois de données précédent). Cette opération nécessitera une combinaison d'un nettoyage partiel des données chargées, mais également un chargement partiel.