Mettre en oeuvre la récupération après sinistre avec une base de données de secours multirégion sur Oracle Database@Azure

Architecture

This architecture shows Oracle Exadata Database Service on Dedicated Infrastructure on Oracle Database@Azure in a multi-region disaster recovery topology using two remote standby databases.

Le diagramme suivant illustre cette architecture de référence.

Description de multi-région-standby-dr-db-azure-arch.png :

Description de l'illustration multi-region-standby-dr-db-azure-arch.png

multi-région-veille-dr-db-azure-arch-oracle.zip

Oracle Database s'exécute dans une grappe de machines virtuelles Exadata dans la région principale. Pour la protection des données et la récupération après sinistre, Oracle Active Data Guard réplique les données vers deux bases de données de secours s'exécutant sur des grappes de machines virtuelles Exadata dans deux régions de secours différentes. Une configuration de base de données de secours distante assure la protection des données contre les défaillances régionales et peut également être utilisée pour décharger le traitement des interrogations en lecture seule. Répliquez l'application entre les régions pour éviter une latence plus élevée après le passage à une base de données de secours.

Vous pouvez acheminer le trafic Active Data Guard au moyen du réseau Azure. Toutefois, cette architecture se concentre sur le trafic réseau Active Data Guard au moyen du réseau OCI pour optimiser le débit et la latence du réseau.

The Oracle Exadata Database Service on Dedicated Infrastructure on Oracle Database@Azure network is connected to the Exadata client subnet using a Dynamic Routing Gateway (DRG) managed by Oracle. Une passerelle DRG est également requise pour créer une connexion d'appairage entre des réseaux en nuage virtuels dans différentes régions. Comme une seule passerelle DRG est autorisée par VCN dans OCI, un deuxième VCN agissant en tant que VCN central avec sa propre passerelle DRG est requis pour connecter les réseaux en nuage virtuels principal et de secours de chaque région. Dans cette architecture :

La grappe de machines virtuelles Exadata principale est déployée dans Region 1 dans VCN1 avec CIDR 10.10.0.0/16.
Le VCN central dans le Region 1 principal est HubVCN1 avec CIDR 10.11.0.0/16.
La première grappe de machines virtuelles Exadata de secours est déployée dans Region 2 dans VCN2 avec CIDR 10.20.0.0/16.
Le VCN central dans la première région de secours est HubVCN2 avec CIDR 10.22.0.0/16.
La deuxième grappe de machines virtuelles Exadata de secours est déployée dans Region 3 dans VCN3 avec CIDR 10.30.0.0/16.
Le VCN central dans la deuxième région de secours est HubVCN3 avec CIDR 10.33.0.0/16.

Aucun sous-réseau n'est requis pour que les réseaux en nuage virtuels de concentrateur puissent activer le routage de transit. Par conséquent, ces réseaux en nuage virtuels peuvent utiliser de très petits intervalles d'adresses IP CIDR. The VCNs on the OCI child site are created after the Oracle Exadata Database Service on Dedicated Infrastructure VM clusters on Oracle Database@Azure are created for the Primary and Standby databases.

Microsoft Azure fournit les composants suivants :

Région Azure
Une région Azure est une zone géographique dans laquelle résident un ou plusieurs centres de données Azure physiques, appelés zones de disponibilité. Les régions sont indépendantes les unes des autres, et de grandes distances peuvent les séparer (à travers les pays ou même les continents).

Les régions Azure et OCI sont des zones géographiques localisées. Pour Oracle Database@Azure, une région Azure est connectée à une région OCI, avec des zones de disponibilité dans Azure connectées à des domaines de disponibilité (AD) dans OCI. Des paires de régions Azure et OCI sont sélectionnées pour réduire la distance et la latence.
Zone de disponibilité Azure
Les zones de disponibilité Azure sont des emplacements physiquement séparés au sein d'une région Azure, conçus pour assurer une haute disponibilité et résilience en fournissant une alimentation, un refroidissement et un réseau indépendants.
Réseau virtuel Azure (VNet)
Azure Virtual Network (VNet) est le bloc de construction fondamental de votre réseau privé dans Azure. VNet permet à de nombreux types de ressources Azure, telles que les machines virtuelles Azure, de communiquer en toute sécurité entre elles, sur Internet et sur les réseaux sur place.
Sous-réseau délégué Azure
Un sous-réseau délégué vous permet d'insérer un service géré, en particulier un service de plate-forme-service (PaaS), directement dans votre réseau virtuel en tant que ressource. Vous disposez d'une gestion complète de l'intégration des services PaaS externes dans vos réseaux virtuels.
Carte d'interface réseau virtuelle Azure (VNIC)
Les services des centres de données Azure disposent de cartes d'interface réseau physiques (NIC). Les instances de machine virtuelle communiquent à l'aide des cartes NIC virtuelles (vNIC) associées aux cartes NIC physiques. Chaque instance a une carte VNIC principale qui est automatiquement créée et attachée lors du lancement et qui est disponible pendant la durée de vie de l'instance.

OCI fournit les composants suivants :

Région
Une région Oracle Cloud Infrastructure est une zone géographique précise qui contient un ou plusieurs centres de données et qui héberge des domaines de disponibilité. Les régions sont indépendantes les unes des autres, et de grandes distances peuvent les séparer (à travers les pays ou même les continents).
Domaines de disponibilité
Les domaines de disponibilité sont des centres de données indépendants et autonomes dans une région. Les ressources physiques de chaque domaine de disponibilité sont isolées des ressources des autres domaines de disponibilité, ce qui garantit la tolérance aux pannes. Les domaines de disponibilité ne partagent pas les éléments d'infrastructure (alimentation ou refroidissement, par exemple) ni le réseau de domaines de disponibilité interne. Ainsi, une défaillance d'un domaine de disponibilité ne doit pas avoir d'incidence sur les autres domaines de disponibilité de la région.
Réseau en nuage virtuel (VCN) et sous-réseaux
Un réseau VCN est un réseau défini par logiciel personnalisable que vous configurez dans une région Oracle Cloud Infrastructure. Comme les réseaux de centre de données traditionnels, les réseaux en nuage virtuels vous permettent de contrôler votre environnement de réseau. Un VCN peut disposer de plusieurs blocs CIDR sans chevauchement que vous pouvez modifier après avoir créé le VCN. Vous pouvez segmenter un VCN en sous-réseaux, dont la portée peut concerner une région ou un domaine de disponibilité. Un sous-réseau est constitué d'un intervalle contigu d'adresses qui ne chevauchent pas les autres sous-réseaux dans le réseau en nuage virtuel. Vous pouvez modifier la taille d'un sous-réseau après sa création. Un sous-réseau peut être public ou privé.
Table de routage
Les tables de routage virtuelles contiennent des règles pour acheminer le trafic des sous-réseaux vers des destinations en dehors d'un VCN, généralement au moyen de passerelles.
Appairage local
L'appairage local vous permet d'appairer un VCN à un autre VCN dans la même région. L'appairage signifie que les réseaux en nuage virtuels communiquent à l'aide d'adresses IP privées, sans que le trafic passe par Internet ou passe par votre réseau sur place.
Passerelle de routage dynamique (DRG)
La passerelle DRG est un routeur virtuel qui fournit un chemin pour le trafic de réseau privé entre des réseaux en nuage virtuels de la même région, entre un réseau VCN et un réseau en dehors de la région, tel qu'un réseau VCN dans une autre région Oracle Cloud Infrastructure, un réseau sur place ou un réseau dans un autre fournisseur de nuage.
Stockage d'objets
Le service de stockage d'objets pour OCI donne accès à de grandes quantités de données structurées et non structurées de tous types, notamment des sauvegardes de base de données, des données analytiques et du contenu enrichi, comme des images et des vidéos. Vous pouvez stocker des données en toute sécurité directement à partir d'Internet ou de la plate-forme en nuage. Vous pouvez adapter le stockage sans que la performance ou la fiabilité des services soit affectée.

Utilisez le stockage standard pour le stockage "à chaud" auquel vous devez accéder rapidement, immédiatement et fréquemment. Utilisez le stockage d'archives pour le stockage "à froid" que vous conservez pendant de longues périodes et auquel vous accédez rarement.
Data Guard
Oracle Data Guard et Oracle Active Data Guard offrent un ensemble complet de services qui créent, maintiennent, gèrent et surveillent une ou plusieurs bases de données de secours et qui permettent aux bases de données Oracle de production de rester disponibles sans interruption. Oracle Data Guard gère ces bases de données de secours en tant que copies de la base de données de production à l'aide de la réplication en mémoire. Si la base de données de production devient indisponible en raison d'une interruption planifiée ou non planifiée, Oracle Data Guard peut basculer n'importe quelle base de données de secours vers le rôle de production, réduisant ainsi le temps d'arrêt associé à l'interruption. Oracle Active Data Guard offre la possibilité supplémentaire de décharger les charges de travail en lecture la plupart du temps vers les bases de données de secours et offre également des fonctions avancées de protection des données.
Service de récupération autonome d'Oracle Database
Oracle Database Autonomous Recovery Service est un service Oracle Cloud qui protège les bases de données Oracle. L'automatisation des sauvegardes et les capacités améliorées de protection des données pour les bases de données OCI vous permettent de décharger toutes les exigences de traitement des sauvegardes et de stockage vers Oracle Database Autonomous Recovery Service, ce qui réduit les coûts d'infrastructure de sauvegarde et les frais généraux d'administration manuelle.
Service Exadata Database sur une infrastructure dédiée
Oracle Exadata Database Service on Dedicated Infrastructure enables you to leverage the power of Exadata in the cloud. Le service Oracle Exadata Database Service fournit des capacités éprouvées d'Oracle Database sur l'infrastructure Oracle Exadata optimisée et spécialement conçue dans le nuage public. L'automatisation intégrée du nuage, l'évolutivité élastique des ressources, la sécurité et la performance rapide pour toutes les charges de travail Oracle Database vous aident à simplifier la gestion et à réduire les coûts.
Oracle Database@Azure
Oracle Database@Azure is the Oracle Database service (Oracle Exadata Database Service on Dedicated Infrastructure and Oracle Autonomous Database Serverless) running on Oracle Cloud Infrastructure (OCI), deployed in Microsoft Azure data centers. Le service offre des fonctions et une parité de prix avec OCI. Achetez le service sur Azure Marketplace.

Oracle Database@Azure intègre Oracle Exadata Database Service, Oracle Real Application Clusters (Oracle RAC) et les technologies Oracle Data Guard dans la plate-forme Azure. Les utilisateurs gèrent le service sur la console Azure et avec les outils d'automatisation Azure. Le service est déployé dans le réseau virtuel Azure (VNet) et intégré au système de gestion des identités et des accès Azure. Les mesures génériques et les journaux de vérification d'OCI et d'Oracle Database sont disponibles de manière native dans Azure. Le service exige que les utilisateurs disposent d'un abonnement Azure et d'une location OCI.

Autonomous Database repose sur l'infrastructure Oracle Exadata, est auto-gérée, auto-sécurisée et auto-réparée, ce qui contribue à éliminer la gestion de base de données manuelle et les erreurs humaines. Autonomous Database permet le développement d'applications évolutives alimentées par intelligence artificielle avec toutes les données à l'aide de capacités d'IA intégrées à l'aide de votre choix de grands modèles de langage (LLM) et d'un emplacement de déploiement.

Oracle Exadata Database Service et Oracle Autonomous Database Serverless sont facilement provisionnés au moyen du portail Azure natif, ce qui permet d'accéder à l'écosystème Azure plus large.

Recommandations

Use the following recommendations as a starting point when performing disaster recovery for Oracle Exadata Database Service on Dedicated Infrastructure on Oracle Database@Azure. Vos exigences peuvent différer de l'architecture décrite ici.

Utilisez Active Data Guard pour la prévention complète de la corruption de données avec réparation automatique de blocs, mises à niveau et migrations en ligne, et déchargez la charge de travail vers la base de données de secours avec une évolutivité en lecture majoritaire.
Activez la continuité de l'application pour masquer les interruptions de base de données pendant les événements planifiés et non planifiés des utilisateurs finaux et assurer l'interruption des applications.
Configurez la sauvegarde automatique dans Oracle Database Autonomous Recovery Service (dans Azure ou OCI) même si les données sont protégées par Oracle Data Guard pour minimiser la charge de travail de sauvegarde sur la base de données en mettant en oeuvre la stratégie de sauvegarde incrémentielle permanente qui élimine les sauvegardes complètes hebdomadaires. Les clients peuvent également utiliser le stockage d'objets OCI pour les sauvegardes automatiques.
Activez les sauvegardes à partir de la base de données de secours pour effectuer une réplication de sauvegarde entre les régions.
Utilisez la récupération après sinistre de pile complète OCI pour orchestrer les opérations de permutation et de basculement de base de données.
Utilisez le service Chambre forte OCI pour stocker les clés TDE (Transparent Data Encryption) de la base de données à l'aide de clés gérées par le client.

Points à considérer

When performing multi-regional disaster recovery for Oracle Exadata Database Service on Dedicated Infrastructure on Oracle Database@Azure, consider the following.

Lorsque des grappes de machines virtuelles Exadata sont créées dans le site enfant Oracle Database@Azure, chaque grappe de machines virtuelles est créée dans son propre VCN OCI. Oracle Data Guard exige que les bases de données communiquent entre elles pour expédier les données redo. Peer les réseaux en nuage virtuels pour activer cette communication. Par conséquent, les réseaux en nuage virtuels de grappe de machines virtuelles Exadata ne doivent pas partager des intervalles CIDR IP qui se chevauchent.
La préparation d'un scénario de sinistre nécessite une approche globale qui prend en compte les différentes exigences commerciales et architectures de disponibilité et qui englobe ces considérations dans un plan exploitable, à haute disponibilité et de reprise après sinistre. Le scénario décrit ici fournit des directives pour vous aider à sélectionner l'approche qui convient le mieux à votre déploiement d'application en utilisant un basculement simple mais efficace pour la configuration de récupération après sinistre dans vos environnements OCI et Microsoft Azure.
OCI est le réseau privilégié pour atteindre une meilleure performance, mesurée par la latence et le débit, et pour atteindre un coût réduit, y compris les 10 premiers To/mois de sortie gratuits.
Vous pouvez créer jusqu'à six bases de données de secours pour une base de données principale au moyen des outils en nuage.
La création d'une base de données de secours associée à une autre base de données de secours (base de secours en cascade) n'est pas prise en charge à l'aide des outils en nuage.

Déployez

Pour configurer la communication réseau entre les régions indiquées dans le diagramme d'architecture, procédez comme suit :

Pour configurer la région principale, procédez comme suit :

Ajoutez les règles de trafic entrant suivantes à la liste de sécurité du sous-réseau client de VCN1 pour autoriser le trafic entrant depuis VCN2 et VCN3.

Sans état	Source	Protocole IP	Intervalle de ports sources	Intervalle de ports de destination	Autorise	Description
Non	`10.20.0.0/16`	TCP	1521	1521	Trafic TCP pour les ports : 1521	Autoriser le trafic entrant depuis `VCN2`
Non	`10.30.0.0/16`	TCP	1521	1521	Trafic TCP pour les ports : 1521	Autoriser le trafic entrant depuis `VCN3`

Créez un réseau en nuage virtuel HubVCN1 avec CIDR 10.11.0.0/16.
Créez la passerelle d'appairage local HubLPG1 dans le réseau en nuage virtuel HubVCN1.
Créez la passerelle d'appairage local LPG1R dans le réseau en nuage virtuel VCN1.
Établissez la connexion d'appairage local entre LPG1R et HubLPG1.

Ajoutez des règles de routage à la table de routage du sous-réseau client de VCN1 pour transférer le trafic ciblé pour VCN2 et VCN3 vers LPG1R.

Destination	Type de cible	Cible	Type de route	Description
`10.20.0.0/16`	Passerelle d'appairage local	`LPG1R`	Statique	Trafic vers `VCN2`
`10.30.0.0/16`	Passerelle d'appairage local	`LPG1R`	Statique	Trafic vers `VCN3`

Créez une table de routage HubLPG1rt dans HubVCN1.
Associez la table de routage HubLPG1rt à la passerelle d'appairage local HubLPG1.
Créer la passerelle de routage dynamique DRG1.
Créez une table de routage DRG1rt dans HubVCN1.

Ajoutez une règle de routage à la table de routage DRG1rt pour transférer le trafic ciblé pour VCN1 vers HubLPG1.

Destination	Type de cible	Cible	Type de route	Description
`10.10.0.0/16`	Passerelle d'appairage local	`HubLPG1`	Statique	Trafic vers `VCN1`

Pour joindre DRG1 à HubVCN1 :
1. Sélectionnez Table de routage Drg générée automatiquement pour les attachements de VCN.
2. Sélectionnez la table de routage existante DRG1rt.
3. Sélectionnez des blocs CIDR de VCN.
Créez deux connexions d'appairage distant dans DRG1, nommées RPC1a et RPC1b.

Ajoutez deux règles de routage à HubLPG1rt pour transférer le trafic ciblé pour VCN2 et VCN3 à DRG1.

Destination	Type de cible	Cible	Type de route	Description
`10.20.0.0/16`	Passerelle de routage dynamique	`DRG1`	Statique	Trafic vers `VCN2`
`10.30.0.0/16`	Passerelle de routage dynamique	`DRG1`	Statique	Trafic vers `VCN3`

Pour créer la première région de secours (région 2), procédez comme suit :

Ajoutez les règles de trafic entrant suivantes à la liste de sécurité du sous-réseau client de VCN2 pour autoriser le trafic entrant depuis VCN1 et VCN3.

Sans état	Source	Protocole IP	Intervalle de ports sources	Intervalle de ports de destination	Autorise	Description
Non	`10.10.0.0/16`	TCP	1521	1521	Trafic TCP pour les ports : 1521	Autoriser le trafic entrant depuis `VCN1`
Non	`10.30.0.0/16`	TCP	1521	1521	Trafic TCP pour les ports : 1521	Autoriser le trafic entrant depuis `VCN3`

Créez le réseau en nuage virtuel HubVCN2 avec le bloc CIDR 10.22.0.0/16.
Créez la passerelle d'appairage local HubLPG2 dans le réseau en nuage virtuel HubVCN2.
Créez la passerelle d'appairage local LPG2R dans le réseau en nuage virtuel VCN2.
Établissez la connexion d'appairage local entre LPG2R et HubLPG2.

Ajoutez des règles de routage à la table de routage du sous-réseau client de VCN2 pour transférer le trafic ciblé pour VCN1 et VCN3 vers LPG2R.

Destination	Type de cible	Cible	Type de route	Description
`10.10.0.0/16`	Passerelle d'appairage local	`LPG2R`	Statique	Trafic vers `VCN1`
`10.30.0.0/16`	Passerelle d'appairage local	`LPG2R`	Statique	Trafic vers `VCN3`

Créez une table de routage HubLPG2rt dans HubVCN2.
Associez la table de routage HubLPG2rt à la passerelle d'appairage local HubLPG2.
Créer la passerelle de routage dynamique DRG2.
Créez une table de routage DRG2rt dans HubVCN2.

Ajoutez une règle de routage à DRG2rt pour transférer le trafic ciblé pour VCN2 vers HubLPG2.

Destination	Type de cible	Cible	Type de route	Description
`10.20.0.0/16`	Passerelle d'appairage local	`HubLPG2`	Statique	Trafic vers `VCN2`

Pour joindre DRG1 à HubVCN2 :
1. Sélectionnez Table de routage Drg générée automatiquement pour les attachements de VCN.
2. Sélectionnez la table de routage existante DRG2rt.
3. Sélectionnez des blocs CIDR de VCN.
Créez deux connexions d'appairage distant dans DRG2, nommées RPC2a et RPC2c.
Établissez une connexion d'appairage distant entre RPC1a (région 1) et RPC2a (région 2).

Ajoutez deux règles de routage à HubLPG2rt pour transférer le trafic ciblé pour VCN1 et VCN3 à DRG2.

Destination	Type de cible	Cible	Type de route	Description
`10.10.0.0/16`	Passerelle de routage dynamique	`DRG2`	Statique	Trafic vers `VCN1`
`10.30.0.0/16`	Passerelle de routage dynamique	`DRG2`	Statique	Trafic vers `VCN3`

Pour créer la deuxième région de secours (région 3), procédez comme suit :

Ajoutez les règles de trafic entrant suivantes à la liste de sécurité du sous-réseau client de VCN3 pour autoriser le trafic entrant depuis VCN1 et VCN2.

Sans état	Source	Protocole IP	Intervalle de ports sources	Intervalle de ports de destination	Autorise	Description
Non	10.10.0.0/16	TCP	1521	1521	Trafic TCP pour les ports : 1521	Autoriser le trafic entrant depuis VCN1
Non	10.20.0.0/16	TCP	1521	1521	Trafic TCP pour les ports : 1521	Autoriser le trafic entrant depuis VCN2

Créez un réseau en nuage virtuel HubVCN3 avec CIDR 10.33.0.0/16.
Créez la passerelle d'appairage local HubLPG3 dans le réseau en nuage virtuel HubVCN3.
Créez la passerelle d'appairage local LPG3R dans le réseau en nuage virtuel VCN3.
Établissez la connexion d'appairage local entre LPG3R et HubLPG3.

Ajoutez des règles de routage à la table de routage du sous-réseau client de VCN3 pour transférer le trafic ciblé pour VCN1 et VCN2 vers LPG3R.

Destination	Type de cible	Cible	Type de route	Description
`10.10.0.0/16`	Passerelle d'appairage local	`LPG3R`	Statique	Trafic vers `VCN1`
`10.20.0.0/16`	Passerelle d'appairage local	`LPG3R`	Statique	Trafic vers `VCN2`

Créez une table de routage HubLPG3rt dans HubVCN3.
Associez la table de routage HubLPG3rt à la passerelle d'appairage local HubLPG3.
Créer la passerelle de routage dynamique DRG3.
Créez une table de routage DRG3rt dans HubVCN3.

Ajoutez une règle de routage à DRG3rt pour transférer le trafic ciblé pour VCN3 vers HubLPG3.

Destination	Type de cible	Cible	Type de route	Description
`10.30.0.0/16`	Passerelle d'appairage local	`HubLPG3`	Statique	Trafic vers `VCN3`

Pour joindre DRG1 à HubVCN3 :
1. Sélectionnez Table de routage Drg générée automatiquement pour les attachements de VCN.
2. Sélectionnez la table de routage existante DRG3rt.
3. Sélectionnez des blocs CIDR de VCN.
Créez deux connexions d'appairage distant dans DRG3, nommées RPC3b et RPC3c.
Établissez une connexion d'appairage distant entre RPC1b (région 1) et RPC3b (région 3).
Établissez une connexion d'appairage distant entre RPC2c (région 2) et RPC3c (région 3).

Ajoutez deux règles de routage à HubLPG3rt pour transférer le trafic ciblé pour VCN1 et VCN2 à DRG3.

Destination	Type de cible	Cible	Type de route	Description
`10.10.0.0/16`	Passerelle de routage dynamique	`DRG3`	Statique	Trafic vers `VCN1`
`10.20.0.0/16`	Passerelle de routage dynamique	`DRG3`	Statique	Trafic vers `VCN2`

Informations complémentaires

En savoir plus sur Oracle Database@Azure et Oracle Data Guard.

Vérifiez ces ressources supplémentaires :

Remerciements

Auteurs : Sinan Petrus Toma, Sebastian Solbach, Julien Silverston
Contributeur : Sreya Dutta