Implémenter la récupération après sinistre avec une base de données de secours multi-région sur Oracle Database@Azure

La continuité des activités est essentielle à la réussite de la conception d'applications. Pour y parvenir, il faut une stratégie robuste de reprise après sinistre conçue pour restaurer rapidement les fonctionnalités en cas de perturbations.

Depuis des années, les entreprises s'appuient sur Oracle Exadata Database Service, qui est la première technologie de récupération après sinistre d'Oracle pour prendre en charge des applications stratégiques, que ce soit sur site ou dans Oracle Cloud Infrastructure (OCI). Oracle Exadata Database Service on Dedicated Infrastructure sur Oracle Database@Azure apporte les mêmes performances, ensemble de fonctionnalités et parité de prix de pointe qu'Exadata sur OCI. Il tire parti des zones de disponibilité (AZ) et des régions de Microsoft Azure pour fournir une faible latence aux applications d'Azure, en plus de fonctionnalités de haute disponibilité et de récupération après sinistre inégalées, garantissant des opérations transparentes pendant la maintenance et en cas de perturbation.

Architecture

Cette architecture présente Oracle Exadata Database Service on Dedicated Infrastructure sur Oracle Database@Azure dans une topologie de récupération après sinistre multi-région à l'aide de deux bases de données de secours distantes.

Le schéma suivant illustre cette architecture de référence.


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

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

Oracle Database est exécuté dans un cluster 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 exécutées sur des clusters de machines virtuelles Exadata dans deux régions de secours différentes. Une configuration de base de données de secours distante garantit la protection des données contre les pannes régionales et peut également être utilisée pour décharger le traitement des requêtes en lecture seule. Répliquez l'application entre les régions pour éviter une latence plus élevée après le basculement vers une base de données de secours.

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

Le réseau Oracle Exadata Database Service on Dedicated Infrastructure sur 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 des réseaux cloud virtuels dans différentes régions. Etant donné qu'un seul DRG est autorisé par VCN dans OCI, un second VCN agissant comme un VCN Hub avec son propre DRG est requis pour connecter les réseaux cloud virtuels principal et de secours dans chaque région. Dans cette architecture :

  • Le cluster de machines virtuelles Exadata principal est déployé dans Region 1 dans VCN1 avec CIDR 10.10.0.0/16.
  • Le VCN hub dans le Region 1 principal est HubVCN1 avec CIDR 10.11.0.0/16.
  • Le premier cluster de machines virtuelles Exadata de secours est déployé dans Region 2 dans VCN2 avec CIDR 10.20.0.0/16.
  • Le VCN hub dans la première région de secours est HubVCN2 avec CIDR 10.22.0.0/16.
  • Le deuxième cluster de machines virtuelles Exadata de secours est déployé dans Region 3 dans VCN3 avec CIDR 10.30.0.0/16.
  • Le VCN hub 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 cloud virtuels hub activent le routage de transit. Par conséquent, ces réseaux cloud virtuels peuvent utiliser de très petites plages CIDR IP. 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 on Dedicated Infrastructure sur Oracle Database@Azure pour les bases de données principale et de secours.

Microsoft Azure fournit les composants suivants :

  • Région 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 (entre 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é (AZ) dans Azure connectées à des domaines de disponibilité dans OCI. Les paires de régions Azure et OCI sont sélectionnées pour minimiser la distance et la latence.

  • Zone de disponibilité Azure

    Les zones de disponibilité Azure sont des emplacements physiquement distincts au sein d'une région Azure, conçus pour assurer la haute disponibilité et la résilience en fournissant une alimentation, un refroidissement et une mise en 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 (VM) Azure, de communiquer en toute sécurité entre elles, avec Internet et avec les réseaux sur site.

  • 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 en tant que 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 au sein de vos réseaux virtuels.

  • Carte d'interface réseau virtuelle Azure

    Les services dans les centres de données Azure ont des cartes d'interface réseau physiques (NIC). 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 carte d'interface réseau virtuelle principale créée et attachée automatiquement lors du lancement. Elle 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 localisée contenant des centres de données hébergeant des domaines de disponibilité. Les régions sont indépendantes les unes des autres et de grandes distances peuvent les séparer (entre les pays ou même les continents).

  • Domaines 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, les réseaux cloud virtuels 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.

  • Appairage local

    L'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 routage via votre réseau sur site.

  • Passerelle de routage dynamique

    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.

  • Object storage

    OCI Object Storage permet d'accéder à 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 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 qui créent, tiennent à jour, gèrent et surveillent des bases de données de secours et permettent 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, réduisant ainsi le temps d'inactivité associé à la coupure. Oracle Active Data Guard offre la possibilité de décharger les charges globales en lecture principalement vers 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 est un service Oracle Cloud qui protège les bases de données Oracle. L'automatisation des sauvegardes et les fonctionnalité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 et de stockage des sauvegardes vers Oracle Database Autonomous Recovery Service, ce qui réduit les coûts d'infrastructure de sauvegarde et les frais d'administration manuels.

  • Exadata Database Service on Dedicated Infrastructure

    Oracle Exadata Database Service on Dedicated Infrastructure vous permet de tirer parti de la puissance d'Exadata dans le cloud. Oracle Exadata Database Service offre des fonctionnalités éprouvées d'Oracle Database sur une infrastructure Oracle Exadata optimisée et spécialement conçue dans le cloud public. L'automatisation cloud intégrée, l'évolutivité élastique des ressources, la sécurité et les performances rapides de toutes les charges de travail Oracle Database vous aident à simplifier la gestion et à réduire les coûts.

  • Oracle Database@Azure

    Oracle Database@Azure est le service Oracle Database (Oracle Exadata Database Service on Dedicated Infrastructure et Oracle Autonomous Database Serverless) exécuté sur Oracle Cloud Infrastructure (OCI), déployé dans les centres de données Microsoft Azure. Le service offre des fonctionnalités et une parité de prix avec OCI. Achetez le service sur Azure Marketplace.

    Oracle Database@Azure intègre les technologies Oracle Exadata Database Service, Oracle Real Application Clusters (Oracle RAC) et Oracle Data Guard sur 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 d'audit OCI et 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é, auto-sécurisé et auto-réparateur, ce qui aide à éliminer la gestion manuelle des bases de données et les erreurs humaines. Autonomous Database permet de développer des applications évolutives alimentées par l'IA avec toutes les données à l'aide de fonctionnalités d'IA intégrées en utilisant votre choix de modèle de langage volumineux (LLM) et d'emplacement de déploiement.

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

Recommandations

Utilisez les recommandations suivantes comme point de départ lors de l'exécution de la récupération après sinistre pour Oracle Exadata Database Service on Dedicated Infrastructure sur Oracle Database@Azure. Vos exigences peuvent différer de l'architecture décrite ici.
  • Utilisez Active Data Guard pour une prévention complète de l'altération des 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 mise à l'échelle en lecture principalement.
  • Activez la continuité des applications pour masquer les pannes de base de données lors des événements planifiés et non planifiés des utilisateurs finaux et garantir des applications ininterrompues.
  • Configurez une sauvegarde automatique vers Oracle Database Autonomous Recovery Service (dans Azure ou OCI), même si les données sont protégées par Oracle Data Guard afin de minimiser la charge globale de sauvegarde sur la base de données en implémentant la stratégie de sauvegarde incrémentielle permanente qui élimine les sauvegardes complètes hebdomadaires. Les clients peuvent également utiliser OCI Object Storage pour les sauvegardes automatiques.
  • Activez les sauvegardes à partir de la base de données de secours pour réaliser la réplication de sauvegarde entre les régions.
  • Utilisez OCI Full Stack DR pour orchestrer les opérations de permutation et de basculement de base de données.
  • Utilisez OCI Vault pour stocker les clés de chiffrement transparent des données (TDE) de la base de données à l'aide de clés gérées par le client.

Points à prendre en compte

Lors de l'exécution de la récupération après sinistre multirégionale pour Oracle Exadata Database Service on Dedicated Infrastructure sur Oracle Database@Azure, tenez compte des éléments suivants.

  • Lorsque des clusters de machines virtuelles Exadata sont créés dans le site enfant Oracle Database@Azure, chaque cluster de machines virtuelles est créé 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. Appeler les réseaux cloud virtuels pour activer cette communication. Par conséquent, les réseaux cloud virtuels de cluster de machines virtuelles Exadata ne doivent pas partager des plages CIDR IP qui se chevauchent.
  • La préparation d'un scénario de sinistre nécessite une approche complète 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 exploitable, haute disponibilité et. Le scénario décrit ici fournit des directives pour vous aider à sélectionner l'approche qui convient le mieux au déploiement de votre 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 préféré pour obtenir de meilleures performances, mesurées par la latence et le débit, et pour obtenir un coût réduit, y compris les 10 premiers To / mois de sortie gratuitement.
  • Vous pouvez créer jusqu'à six bases de données de secours pour une base de données principale via Cloud Tooling.
  • La création d'une base de données de secours associée à une autre base de données de secours (base de données de secours en cascade) n'est pas prise en charge à l'aide des outils cloud.

Déployez

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

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

  1. Ajoutez les règles entrantes suivantes à la liste de sécurité du sous-réseau client de VCN1 pour autoriser le trafic entrant à partir de VCN2 et de VCN3.
    Sans conservation de statut Source Protocole IP Plage de ports source Plage de ports de destination Permet Description
    No 10.20.0.0/16 TCP 1521 1521 Trafic TCP pour les ports : 1521 Autoriser l'entrée à partir de VCN2
    No 10.30.0.0/16 TCP 1521 1521 Trafic TCP pour les ports : 1521 Autoriser l'entrée à partir de VCN3
  2. Créez un réseau cloud virtuel HubVCN1 avec CIDR 10.11.0.0/16.
  3. Créez la passerelle d'appairage local HubLPG1 dans le réseau cloud virtuel HubVCN1.
  4. Créez la passerelle d'appairage local LPG1R dans le réseau cloud virtuel VCN1.
  5. Etablissez la connexion d'appairage local entre LPG1R et HubLPG1.
  6. Ajoutez des règles de routage à la table de routage du sous-réseau client de VCN1 afin de transférer le trafic ciblé pour VCN2 et VCN3 vers LPG1R.
    Destination Type de cible Target Type de routage 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
  7. Créez la table de routage HubLPG1rt dans HubVCN1.
  8. Associez la table de routage HubLPG1rt à la passerelle d'appairage local HubLPG1.
  9. Créez la passerelle de routage dynamique DRG1.
  10. Créez la table de routage DRG1rt dans HubVCN1.
  11. Ajoutez une règle de routage à la table de routage DRG1rt afin de transférer le trafic ciblé pour VCN1 vers HubLPG1.
    Destination Type de cible Target Type de routage Description
    10.10.0.0/16 Passerelle d'appairage local HubLPG1 Statique Trafic vers VCN1
  12. Pour attacher DRG1 à HubVCN1, procédez comme suit :
    1. Sélectionnez Table de routage Drg générée automatiquement pour les pièces jointes VCN.
    2. Sélectionnez la table de routage existante DRG1rt.
    3. Sélectionnez Blocs CIDR de VCN.
  13. Créez deux connexions d'appairage à distance dans DRG1, nommées RPC1a et RPC1b.
  14. Ajoutez deux règles de routage à HubLPG1rt pour transférer le trafic ciblé pour VCN2 et VCN3 vers DRG1.
    Destination Type de cible Target Type de routage 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 :

  1. Ajoutez les règles entrantes suivantes à la liste de sécurité du sous-réseau client de VCN2 pour autoriser le trafic entrant à partir de VCN1 et de VCN3.
    Sans conservation de statut Source Protocole IP Plage de ports source Plage de ports de destination Permet Description
    No 10.10.0.0/16 TCP 1521 1521 Trafic TCP pour les ports : 1521 Autoriser l'entrée à partir de VCN1
    No 10.30.0.0/16 TCP 1521 1521 Trafic TCP pour les ports : 1521 Autoriser l'entrée à partir de VCN3
  2. Créez le réseau cloud virtuel HubVCN2 avec le CIDR 10.22.0.0/16.
  3. Créez la passerelle d'appairage local HubLPG2 dans le réseau cloud virtuel HubVCN2.
  4. Créez la passerelle d'appairage local LPG2R dans le réseau cloud virtuel VCN2.
  5. Etablissez la connexion d'appairage local entre LPG2R et HubLPG2.
  6. Ajoutez des règles de routage à la table de routage du sous-réseau client de VCN2 afin de transférer le trafic ciblé pour VCN1 et VCN3 vers LPG2R.
    Destination Type de cible Target Type de routage 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
  7. Créez la table de routage HubLPG2rt dans HubVCN2.
  8. Associez la table de routage HubLPG2rt à la passerelle d'appairage local HubLPG2.
  9. Créez la passerelle de routage dynamique DRG2.
  10. Créez la table de routage DRG2rt dans HubVCN2.
  11. Ajoutez une règle de routage à DRG2rt afin de transférer le trafic ciblé pour VCN2 vers HubLPG2.
    Destination Type de cible Target Type de routage Description
    10.20.0.0/16 Passerelle d'appairage local HubLPG2 Statique Trafic vers VCN2
  12. Pour attacher DRG1 à HubVCN2, procédez comme suit :
    1. Sélectionnez Table de routage Drg générée automatiquement pour les pièces jointes VCN.
    2. Sélectionnez la table de routage existante DRG2rt.
    3. Sélectionnez Blocs CIDR de VCN.
  13. Créez deux connexions d'appairage à distance dans DRG2, nommées RPC2a et RPC2c.
  14. Etablissez une connexion d'appairage à distance entre RPC1a (région 1) et RPC2a (région 2).
  15. Ajoutez deux règles de routage à HubLPG2rt pour transférer le trafic ciblé pour VCN1 et VCN3 vers DRG2.
    Destination Type de cible Target Type de routage 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 :

  1. Ajoutez les règles entrantes suivantes à la liste de sécurité du sous-réseau client de VCN3 pour autoriser le trafic entrant à partir de VCN1 et de VCN2.
    Sans conservation de statut Source Protocole IP Plage de ports source Plage de ports de destination Permet Description
    No 10.10.0.0/16 TCP 1521 1521 Trafic TCP pour les ports : 1521 Autoriser l'entrée à partir de VCN1
    No 10.20.0.0/16 TCP 1521 1521 Trafic TCP pour les ports : 1521 Autoriser l'entrée à partir de VCN2
  2. Créez un réseau cloud virtuel HubVCN3 avec CIDR 10.33.0.0/16.
  3. Créez la passerelle d'appairage local HubLPG3 dans le réseau cloud virtuel HubVCN3.
  4. Créez la passerelle d'appairage local LPG3R dans le réseau cloud virtuel VCN3.
  5. Etablissez la connexion d'appairage local entre LPG3R et HubLPG3.
  6. Ajoutez des règles de routage à la table de routage du sous-réseau client de VCN3 afin de transférer le trafic ciblé pour VCN1 et VCN2 vers LPG3R.
    Destination Type de cible Target Type de routage 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
  7. Créez la table de routage HubLPG3rt dans HubVCN3.
  8. Associez la table de routage HubLPG3rt à la passerelle d'appairage local HubLPG3.
  9. Créez la passerelle de routage dynamique DRG3.
  10. Créez la table de routage DRG3rt dans HubVCN3.
  11. Ajoutez une règle de routage à DRG3rt afin de transférer le trafic ciblé pour VCN3 vers HubLPG3.
    Destination Type de cible Target Type de routage Description
    10.30.0.0/16 Passerelle d'appairage local HubLPG3 Statique Trafic vers VCN3
  12. Pour attacher DRG1 à HubVCN3, procédez comme suit :
    1. Sélectionnez Table de routage Drg générée automatiquement pour les pièces jointes VCN.
    2. Sélectionnez la table de routage existante DRG3rt.
    3. Sélectionnez Blocs CIDR de VCN.
  13. Créez deux connexions d'appairage à distance dans DRG3, nommées RPC3b et RPC3c.
  14. Etablissez une connexion d'appairage à distance entre RPC1b (région 1) et RPC3b (région 3).
  15. Etablissez une connexion d'appairage à distance entre RPC2c (région 2) et RPC3c (région 3).
  16. Ajoutez deux règles de routage à HubLPG3rt pour transférer le trafic ciblé pour VCN1 et VCN2 vers DRG3.
    Destination Type de cible Target Type de routage 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

En savoir plus

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

Consultez les ressources supplémentaires suivantes :

Accusés de réception

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