Effectuer une récupération après sinistre inter-régionale pour Oracle Exadata Database Service sur Oracle Database@Azure

Architecture

Cette architecture présente une application Azure Kubernetes Service (AKS) en conteneur haute disponibilité avec Oracle Exadata Database Service sur Oracle Database@Azure dans une topologie de récupération après sinistre interrégionale.

Une application Azure Kubernetes Service (AKS) en conteneur haute disponibilité est déployée dans deux régions Azure : une région principale et une région de secours. Les images de conteneur sont stockées dans le registre de conteneurs Azure et sont répliquées entre les régions principale et de secours. Les utilisateurs accèdent à l'application en externe via un équilibreur de charge public.

Pour la protection des données, Oracle Database est en cours d'exécution dans un cluster de machines virtuelles Exadata de la région principale, Oracle Data Guard ou Oracle Active Data Guard répliquant les données vers la base de données de secours exécutée sur un cluster de machines virtuelles Exadata de la région de secours.

Les clés de cryptage transparent des données de base de données sont stockées dans Oracle Cloud Infrastructure Vault et répliquées entre les régions Azure et OCI. Les sauvegardes automatiques se trouvent dans OCI pour les régions principale et de secours. Les clients peuvent utiliser Oracle Cloud Infrastructure Object Storage ou Oracle Database Autonomous Recovery Service comme solution de stockage préférée.

Le service Oracle Exadata Database Service sur le réseau Oracle Database@Azure est connecté au sous-réseau client Exadata à l'aide d'une passerelle de routage dynamique (DRG) gérée par Oracle. Un DRG est également requis pour créer une connexion homologue entre les réseaux cloud virtuels de différentes régions. Etant donné qu'un seul DRG est autorisé par VCN dans OCI, un second VCN avec son propre DRG est requis pour connecter les réseaux cloud virtuels principal et de secours dans chaque région. Dans cet exemple :

Le cluster de machines virtuelles Exadata principal est déployé dans le sous-réseau client VCN principal VCN (10.5.0.0/24).
Le VCN principal du Hub VCN pour le réseau de transit est 10.15.0.0/29.
Le cluster de machines virtuelles Exadata de secours est déployé dans le sous-réseau client VCN de base de données de secours VCN (10.6.0.0/24).
Le VCN de secours Hub VCN pour le réseau de transit est 10.16.0.0/29.

Aucun sous-réseau n'est requis pour que les réseaux cloud virtuels hub activent le routage de transit. Ces réseaux cloud virtuels peuvent donc utiliser un réseau de très petite taille. Les réseaux cloud virtuels sur le site enfant OCI sont créés après la création des clusters de machines virtuelles Oracle Exadata Database Service sur Oracle Database@Azure pour les bases de données principale et de secours.

Le diagramme suivant illustre l'architecture :

Description de l'image exadb-dr-db-azure.png

Description de l'illustration exadb-dr-db-azure.png

exadb-dr-db-azure-oracle.zip

Microsoft Azure fournit les composants suivants :

Région Microsoft Azure
Une région Azure est une zone géographique dans laquelle résident des 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 des pays voire des 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é (AZ) dans Azure connectées aux domaines de disponibilité (AD) dans OCI. Les paires de régions Azure et OCI sont sélectionnées pour minimiser la distance et la latence.
Zone de disponibilité Microsoft Azure
Une zone de disponibilité est un centre de données physiquement séparé au sein d'une région conçue pour être hautement disponible et tolérant les pannes. Les zones de disponibilité sont suffisamment proches pour disposer de connexions à faible latence vers d'autres zones de disponibilité.
Réseau virtuel Microsoft Azure
Microsoft Azure Virtual Network (VNet) est le bloc de construction fondamental d'un réseau privé dans Azure. VNet permet à de nombreux types de ressources Azure, tels que les machines virtuelles Azure, de communiquer en toute sécurité entre eux, avec Internet et avec des réseaux sur site.
Sous-réseau délégué Microsoft Azure
La délégation de sous-réseau vous permet d'injecter un service géré, en particulier un service de type plate-forme en tant que service (PaaS), directement dans votre réseau virtuel. Un sous-réseau délégué peut être un répertoire de base pour un service géré en externe au sein de votre réseau virtuel afin que le service externe agisse en tant que ressource de réseau virtuel, même s'il s'agit d'un service PaaS externe.
Carte d'interface réseau virtuelle Microsoft Azure
Les services des centres de données Azure disposent de cartes d'interface réseau (NIC) physiques. Les instances de machine virtuelle communiquent à l'aide de cartes d'interface réseau virtuelles (VNIC) associées aux cartes d'interface réseau physiques. Chaque instance dispose d'une VNIC principale qui est automatiquement créée et attachée lors du lancement et est disponible pendant la durée de vie de l'instance.
Table de routage Microsoft Azure
Les tables de routage virtuelles contiennent des règles permettant d'acheminer le trafic des sous-réseaux vers des destinations en dehors d'une instance VNet, généralement via des passerelles. Les tables de routage sont associées à des sous-réseaux dans un VNet.
Passerelle de réseau virtuel Azure
Le service Azure Virtual Network Gateway établit une connectivité inter-sites sécurisée entre un réseau virtuel Azure et un réseau sur site. Il vous permet de créer un réseau hybride qui couvre votre centre de données et Azure.

Oracle Cloud Infrastructure 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, appelés domaines de disponibilité. Les régions sont indépendantes les unes des autres et de grandes distances peuvent les séparer (à travers des pays voire des continents).
Domaine de disponibilité
Les domaines de disponibilité sont des centres de données autonomes indépendants au sein d'une région. Les ressources physiques de chaque domaine de disponibilité sont isolées de celles des autres, ce qui garantit la tolérance aux pannes. Les domaines de disponibilité ne partagent ni infrastructure (par exemple, alimentation, système de refroidissement), ni réseau de domaine de disponibilité interne. Par conséquent, une panne sur un domaine de disponibilité ne doit pas affecter les autres domaines de disponibilité de la région.
Réseau cloud virtuel (VCN) et sous-réseaux
Un VCN est un réseau personnalisable défini par logiciel que vous configurez dans une région Oracle Cloud Infrastructure. Comme les réseaux de centre de données traditionnels, ils vous donnent le contrôle sur l'environnement réseau. Un réseau cloud virtuel peut comporter plusieurs blocs CIDR qui ne se chevauchent pas et que vous pouvez modifier après l'avoir créé. Vous pouvez segmenter un réseau cloud virtuel en plusieurs sous-réseaux ciblant une région ou un domaine de disponibilité. Chaque sous-réseau est composé d'une plage contiguë d'adresses qui ne chevauchent pas celles des autres sous-réseaux du réseau cloud 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 via des passerelles.
Liste de sécurité
Pour chaque sous-réseau, vous pouvez créer des règles de sécurité qui indiquent la source, la destination et le type de trafic qui doivent être autorisés à entrer et sortir du sous-réseau.
Passerelle de routage dynamique (DRG)
Le DRG est un routeur virtuel qui fournit un chemin pour le trafic de réseau privé entre les réseaux cloud virtuels de la même région, entre un VCN et un réseau en dehors de la région, tel qu'un VCN dans une autre région Oracle Cloud Infrastructure, un réseau sur site ou un réseau dans un autre fournisseur cloud.
Passerelle de service
La passerelle de service permet d'accéder à d'autres services à partir d'un VCN, tels qu'Oracle Cloud Infrastructure Object Storage. Le trafic du VCN vers le service Oracle transite par la structure réseau Oracle et ne traverse pas Internet.
Passerelle d'appairage local
Une passerelle d'appairage local vous permet d'appairer un VCN avec un autre VCN dans la même région. L'appairage signifie que les réseaux cloud virtuels communiquent à l'aide d'adresses IP privées, sans que le trafic ne passe par Internet ou ne soit acheminé via votre réseau sur site.
Groupe de sécurité réseau
Le groupe de sécurité réseau fait office de pare-feu virtuel pour vos ressources cloud. Avec le modèle de sécurité zéro confiance d'Oracle Cloud Infrastructure, tout le trafic est refusé et vous pouvez contrôler le trafic réseau à l'intérieur d'un VCN. Un groupe de sécurité réseau se compose d'un ensemble de règles de sécurité entrantes et sortantes qui s'appliquent uniquement à un ensemble spécifié de cartes d'interface réseau virtuelles dans un seul VCN.
Object Storage
Le stockage d'objets permet d'accéder rapidement à de grandes quantités de données, structurées ou non, de tout type de contenu, y compris des sauvegardes de base de données, des données analytiques et du contenu enrichi tel que des images et des vidéos. Vous pouvez stocker les données, puis les extraire directement à partir d'Internet ou de la plate-forme cloud, et ce, en toute sécurité. Vous pouvez redimensionner le stockage sans dégradation des performances ni de la fiabilité des services. Utilisez le stockage standard pour le stockage "à chaud" auquel vous devez accéder rapidement, immédiatement et fréquemment. Utilisez le stockage d'archive 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 fournissent un ensemble complet de services permettant de créer, de tenir à jour, de gérer et de surveiller des bases de données de secours et de permettre aux bases de données Oracle de production de rester disponibles sans interruption. Oracle Data Guard conserve 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 coupure planifiée ou non, Oracle Data Guard peut basculer n'importe quelle base de données de secours vers le rôle de production, ce qui réduit le temps d'inactivité associé à la coupure. Oracle Active Data Guard offre la possibilité supplémentaire de décharger les charges globales en lecture sur les bases de données de secours, ainsi que des fonctionnalités avancées de protection des données.
Oracle Database Autonomous Recovery Service
Oracle Database Autonomous Recovery Service vous permet de créer un instantané ponctuel des données sur les volumes de blocs, les volumes d'initialisation et dans les instances Oracle Database. Grâce à l'automatisation des sauvegardes et aux fonctionnalités améliorées de protection des données pour les bases de données OCI, vous pouvez décharger toutes les exigences de traitement et de stockage des sauvegardes sur Oracle Database Autonomous Recovery Service, éliminant ainsi les coûts d'infrastructure de sauvegarde et les frais d'administration manuelle.
Exadata Database Service
Oracle Exadata est une plate-forme de base de données d'entreprise qui exécute des charges de travail Oracle Database de toute ampleur et criticité avec des performances, une disponibilité et une sécurité élevées. La conception évolutive d'Exadata utilise des optimisations uniques qui permettent au traitement des transactions, aux analyses, au machine learning et aux workloads mixtes de s'exécuter plus rapidement et plus efficacement. La consolidation de diverses charges de travail Oracle Database sur les plates-formes Exadata dans les data centers d'entreprise, sur Oracle Cloud Infrastructure (OCI) et dans les environnements multicloud aide les entreprises à accroître leur efficacité opérationnelle, à réduire leur administration informatique et à réduire leurs coûts.

Oracle Exadata Database Service vous permet de tirer parti de la puissance d'Exadata dans le cloud. Oracle Exadata Database Service offre des fonctionnalités Oracle Database éprouvées sur une infrastructure Oracle Exadata optimisée et spécialement conçue dans le cloud public et sur Cloud@Customer. L'automatisation cloud intégrée, l'évolutivité élastique des ressources, la sécurité et les performances rapides 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 intègre des technologies Oracle, telles qu'Oracle Exadata Database Service, Oracle Autonomous Database Serverless, Oracle Real Application Clusters (Oracle RAC) et Oracle Data Guard dans la plate-forme Microsoft Azure.

Oracle Database@Azure est le service Oracle Database exécuté sur Oracle Cloud Infrastructure (OCI), et est colocalisé dans les centres de données Microsoft Azure. Le service offre une fonctionnalité et une parité de prix avec OCI. Vous pouvez acheter le service sur Azure Marketplace. Oracle Database@Azure offre la même latence faible que les autres services Azure natifs et répond aux exigences de charge de travail et de développement cloud natifs critiques. Vous pouvez gérer 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 est intégré au système de gestion des identités et des accès Azure. Les mesures et les journaux d'audit OCI et Oracle Database sont disponibles de manière native dans Azure. Le service exige que les utilisateurs disposent d'une location Azure et d'une location OCI.

Recommandations

Utilisez les recommandations suivantes comme point de départ lors de l'exécution d'une récupération après sinistre inter-région pour Oracle Exadata Database Service sur Oracle Database@Azure. Vos exigences peuvent différer de l'architecture décrite ici.

Déployez l'infrastructure Exadata requise dans les régions principale et de secours. Pour chaque instance Exadata, déployez un cluster de machines virtuelles Exadata dans le sous-réseau délégué d'un réseau virtuel Microsoft Azure (VNet). La base de données Oracle Real Application Clusters (RAC) peut ensuite être instanciée sur le cluster. Dans le même VNet, déployez Azure Kubernetes Service (AKS) dans un sous-réseau distinct. Configurez Oracle Data Guard pour répliquer les données d'une instance Oracle Database vers l'autre, d'une région à l'autre.
Lorsque des clusters de machines virtuelles Exadata sont créés sur le site enfant Oracle Database@Azure, chacun est créé dans son propre réseau cloud virtuel (VCN) Oracle Cloud Infrastructure. Oracle Data Guard exige que les bases de données communiquent entre elles pour expédier les données de journalisation. Les réseaux cloud virtuels doivent être appairés pour permettre cette communication.

Points à prendre en compte

Lorsque vous effectuez une récupération après sinistre inter-régionale pour Oracle Exadata Database Service sur Oracle Database@Azure, tenez compte des points suivants.

La préparation d'un scénario de catastrophe nécessite une approche globale qui prend en compte les différentes exigences métier et architectures de disponibilité et qui englobe ces considérations dans un plan de reprise après sinistre, à haute disponibilité et exploitable. Le scénario décrit ici fournit des directives pour vous aider à sélectionner l'approche qui correspond 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 Oracle Cloud Infrastructure (OCI) et Microsoft Azure.
Utilisez Oracle Data Guard dans toutes les régions pour les bases de données provisionnées dans le cluster de machines virtuelles Exadata sur Oracle Database@Azure à l'aide d'un réseau géré par OCI.
Oracle Cloud Infrastructure est le réseau préféré pour obtenir de meilleures performances, mesurées par latence et débit, et pour réduire les coûts, car les 10 premiers To/mois sont gratuits.

Déployez

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

Région principale

Créez un réseau cloud virtuel (VCN), HUB VCN Primary, dans la région principale d'Oracle Cloud Infrastructure (OCI).
Déployez deux passerelles d'appairage local, Primary-LPG et HUB-Primary-LPG, respectivement dans VCN Primary et HUB VCN Primary.
Etablissez une connexion de passerelle d'appairage local entre les passerelles d'appairage local pour HUB VCN Primary et VCN Primary.
Dans le VCN principal VCN, mettez à jour la table de routage par défaut pour acheminer le trafic de l'adresse IP associée au sous-réseau client VCN Standby afin d'utiliser l'appairage d'appairage d'appairage local. Exemple :
```
10.6.0.0/24 to Primary-LPG
```
Remarques :
Pour mettre à jour la table de routage par défaut, vous devez actuellement créer un ticket de support portant le titre Autorisation de mise à jour de table de routage VCN requise et fournir la région, l'OCID de location, l'OCID de VCN et l'OCID de service DRG.
Créez une passerelle de routage dynamique (DRG), Primary-DRG dans le VCN principal du VCN hub.
Dans le VCN HUB VCN Primary, créez la table de routage, primary_hub_transit_drg, et affectez la destination du sous-réseau client VCN Primary, un type de cible LPG et la cible HUB-Primary-LPG. Exemple :
```
10.5.0.0/24 target type: LPG, Target: Hub-Primary-LPG
```
Dans le VCN HUB VCN Primary, créez une deuxième table de routage, primary_hub_transit_lpg, et affectez la destination du sous-réseau client VCN Primary, un type de cible DRG et un Primary-DRG cible. Exemple :
```
10.6.0.0/24 target type: DRG, Target: Primary-DRG
```
Attachez le VCN principal VCN Hub au DRG. Modifiez les attachements VCN DRG et, sous les options avancées, modifiez la table de routage VCN de l'onglet pour l'associer à la table de routage primary_hub_transit_drg. Cette configuration permet le routage de transit.
Associez la table de routage primary_hub_transit_lpg à la passerelle Hub-Primary-LPG.
Dans la table de routage par défaut Hub VCN Primary, ajoutez une règle de routage pour la plage d'adresses IP du sous-réseau client VCN Primary afin d'utiliser la passerelle d'appairage local. Ajoutez une autre règle de routage pour la plage d'adresses IP du sous-réseau client VCN Standby afin d'utiliser le DRG. Exemple :
```
10.5.0.0/24 LPG Hub-Primary-LPG
10.6.0.0/24 DRG Primary-DRG
```
Pour Primary-DRG, sélectionnez la table de routage DRG, la table de routage DRG générée automatiquement pour les attachements RPC, VC et IPSec. Ajoutez une route statique à la plage d'adresses IP du client de sous-réseau VCN principal qui utilise le VCN principal VCN du hub avec un type d'attachement de saut suivant VCN et le nom d'attachement de saut suivant Attachement de hub principal. Exemple :
```
10.5.0.0/24 VCN Primary Hub attachment
```
Utilisez le menu des attachements de connexion d'appairage à distance Primary-DRG pour créer une connexion d'appairage à distance, RPC.
Dans le sous-réseau client VCN Primary, mettez à jour le groupe de sécurité réseau afin de créer une règle de sécurité autorisant l'entrée pour le port TCP 1521. Vous pouvez éventuellement ajouter le port SSH 22 pour un accès SSH direct aux serveurs de base de données.

Remarques :
Pour une configuration plus précise, désactivez la distribution de routage d'import de la table de routage DRG générée automatiquement pour les attachements RPC, VC et IPSec. Pour Table de routage DRG générée automatiquement pour les attachements VCN, créez et affectez une nouvelle distribution de routage d'import, y compris uniquement l'attachement RPC requis.

Région de secours

Créez le VCN, base de données de secours VCN HUB, dans la région de secours OCI.
Déployez deux passerelles d'appairage local, Standby-LPG et HUB-Standby-LPG, respectivement dans les réseaux cloud virtuels VCN Standby et HUB VCN Standby.
Etablissez une connexion de passerelle d'appairage local entre les passerelles d'appairage local pour la base de secours VCN et la base de secours VCN HUB.
Dans le VCN de base de données de secours VCN, mettez à jour la table de routage par défaut pour acheminer le trafic de l'adresse IP associée au sous-réseau client principal VCN afin d'utiliser l'appairage d'appairage d'appairage d'appairage local. Exemple :
```
10.5.0.0/24 to Standby-LPG
```
Remarques :
Pour mettre à jour la table de routage par défaut, vous devez actuellement créer un ticket de support portant le titre Autorisation de mise à jour de table de routage VCN requise et fournir la région, l'OCID de location, l'OCID de VCN et l'OCID de service DRG.
Créez un DRG, Standby-DRG dans le VCN Hub VCN Standby.
Dans le VCN de secours HUB VCN, créez une table de routage, standby_hub_transit_lpg, et affectez la destination du sous-réseau client VCN Standby, un type de cible LPG et une HUB-Standby-LPG cible. Exemple :
```
10.6.0.0/24 target type: LPG, Target: Hub-Standby-LPG
```
Dans le VCN de secours HUB VCN, créez une seconde table de routage, standby_hub_transit_drg et affectez la destination du sous-réseau client VCN Standby, un type de cible DRG et un DRG de secours cible. Exemple :
```
10.5.0.0/24 target type: DRG, Target: Standby-DRG
```
Attachez le VCN Hub VCN Standby au DRG. Modifiez les attachements VCN DRG et, sous les options avancées, modifiez la table de routage VCN pour l'associer à la table de routage standby_hub_transit_drg. Cette configuration permet le routage de transit.
Dans la table de routage par défaut Hub VCN Standby, ajoutez des règles de routage pour la plage d'adresses IP du sous-réseau client VCN Standby afin d'utiliser la passerelle d'appairage local et pour la plage d'adresses IP du sous-réseau client VCN Primary afin d'utiliser le DRG. Exemple :
```
10.6.0.0/24 LPG Hub-Standby-LPG
10.5.0.0/24 DRG Standby-DRG
```
Associez la table de routage, standby_hub_transit_lpg, à la passerelle Hub-Standby-LPG.
Pour DRG de secours, sélectionnez la table de routage DRG Table de routage Drg générée automatiquement pour les attachements RPC, VC et IPSec. Ajoutez une route statique à la plage d'adresses IP du client de sous-réseau VCN Standby qui utilise le VCN Hub VCN Standby avec un type d'attachement de saut suivant VCN et le nom d'attachement de saut suivant Attachement de hub de secours. Exemple :
```
10.6.0.0/24 VCN Standby Hub attachment
```
Utilisez le menu des attachements de connexion d'appairage à distance Standby-DRG pour créer une connexion d'appairage à distance, RPC.
Sélectionnez la connexion d'appairage à distance, sélectionnez Etablir une connexion et indiquez l'OCID Primary-DRG. Le statut de l'appairage devient Appairé. Les deux régions sont connectées.
Dans le sous-réseau client VCN Standby, mettez à jour le groupe de sécurité réseau afin de créer une règle de sécurité autorisant l'entrée pour le port TCP 1521. Vous pouvez éventuellement ajouter le port SSH 22 pour un accès SSH direct aux serveurs de base de données.

Association Data Guard

Afin d'activer Oracle Data Guard ou Oracle Active Data Guard pour Oracle Database, sur la page de détails Oracle Database, cliquez sur Associations Data Guard, puis sur Activer Data Guard.
Dans la page Enable Data Guard :
1. Sélectionnez la région de secours.
2. Sélectionnez le domaine de disponibilité de secours mis en correspondance avec Azure AZ.
3. Sélectionnez l'infrastructure Exadata de secours.
4. Sélectionnez le cluster de machines virtuelles de secours souhaité.
5. Choisissez Oracle Data Guard ou Oracle Active Data Guard. MAA recommande Oracle Active Data Guard pour la réparation automatique des interruptions de données et la possibilité de décharger les rapports.
6. Pour les associations Oracle Data Guard inter-régions, seul le mode de protection Performances maximales est pris en charge.
7. Sélectionnez un répertoire de base de base de données existant ou créez-en un. Il est recommandé d'utiliser la même image logicielle de base de données de la base de données principale pour le répertoire de base de la base de données de secours, afin de disposer des mêmes patches.
8. Entrez le mot de passe de l'utilisateur SYS et activez Oracle Data Guard.
Une fois Oracle Data Guard activé, la base de données de secours est répertoriée dans la section Associations Data Guard.
(Facultatif) Activez le basculement automatique (Fast-Start Failover) pour réduire le temps de récupération en cas de panne en installant Data Guard Observer sur une machine virtuelle distincte, de préférence dans un emplacement distinct ou dans le réseau d'applications.

En savoir plus

En savoir plus sur les caractéristiques de cette architecture et sur les architectures associées.

Remerciements

Auteurs : Ricardo Anda, Srikanth Bolisetty, Julien Silverston, Andy Steinorth
Contributeurs : Tammy Bednar, Wei Han, Glen Hawkins, Gavin Parish, Sinan Petrus Toma, Lawrence To, Thomas Van Buggenhout, Robert Lies