Mettre en oeuvre la récupération après sinistre avec des bases de secours locales et régionales sur Oracle Database@Azure

Il est essentiel d'assurer une continuité d'activité ininterrompue pour réussir la conception des applications. Pour ce faire, il faut une stratégie robuste de reprise après sinistre conçue pour restaurer rapidement les fonctionnalités en cas de perturbations.

Pendant des années, les organisations se sont appuyées sur le service Oracle Exadata Database Service, qui est les principales technologies de reprise après sinistre d'Oracle pour prendre en charge les applications essentielles, que ce soit sur place ou dans Oracle Cloud Infrastructure (OCI). Oracle Exadata Database Service on Dedicated Infrastructure on Oracle Database@Azure brings the same industry-leading performance, feature set, and price parity as Exadata on OCI. Il exploite les zones de disponibilité (AZ) et les régions de Microsoft Azure pour fournir une faible latence aux applications d'Azure, en plus des capacités inégalées de haute disponibilité et de reprise après sinistre, assurant des opérations transparentes pendant la maintenance et en cas de perturbation.

Architecture

This architecture shows Oracle Exadata Database Service on Dedicated Infrastructure on Oracle Database@Azure in a disaster recovery topology using two standby databases, a local standby across zones, and a remote standby across regions.

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


Description de local-régional-standby-dr-db-azure-arch.png
Description de l'illustration local-régional-standby-dr-db-azure-arch.png

local-régional-standby-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 deux grappes de machines virtuelles Exadata, la première dans la même région mais dans une zone différente (base de secours locale) et la seconde dans une autre région (base de secours distante). Une base de données de secours locale est idéale pour les scénarios de basculement, car elle ne présente aucune perte de données pour les pannes locales tandis que les applications continuent de fonctionner sans la surcharge de performance liée à la communication avec une région distante. Une base de données de secours distante est généralement utilisée pour la récupération après sinistre ou pour décharger des charges de travail en lecture seule. Avec plusieurs zones de disponibilité, vous pouvez tirer parti du déploiement de niveau d'application de zone de disponibilité multiple Azure pour créer une solution fiable et répliquer le niveau d'application vers l'emplacement 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, zone 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 1, zone 2 dans VCN2 avec CIDR 10.20.0.0/16.
  • Le VCN hub est le même que le VCN hub pour la base de données principale, HubVCN1 car il réside dans la même région.
  • La deuxième grappe de machines virtuelles Exadata de secours est déployée dans Region 2 dans VCN3 avec CIDR 10.30.0.0/16.
  • Le VCN central dans la base de données de secours distante Region 2 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

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

  • 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.

Déployez

Voyez comment configurer la communication réseau entre les régions indiquées dans le diagramme d'architecture.

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

  1. 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
  2. Créez un réseau en nuage virtuel HubVCN1 avec CIDR 10.11.0.0/16.
  3. Créez la passerelle d'appairage local HubLPG1 et HubLPG2 dans le réseau en nuage virtuel HubVCN1.
  4. Créez la passerelle d'appairage local LPG1R et LPG1L dans le réseau en nuage virtuel VCN1.
  5. Créez la passerelle d'appairage local LPG1R et LPG1L dans le réseau en nuage virtuel VCN2.
  6. Établissez la connexion d'appairage local entre LPG1R et HubLPG1.
  7. Établissez la connexion d'appairage local entre LPG2R et HubLPG2.
  8. Établissez la connexion d'appairage local entre LPG1L et LPG2L.
  9. Ajoutez des règles de routage à la table de routage du sous-réseau client de VCN1 pour transmettre le trafic ciblé pour VCN2 à LPG1L et transmettre le trafic ciblé pour VCN3 à LPG1R.
    Destination Type de cible Cible Type de route Description
    10.20.0.0/16 Passerelle d'appairage local LPG1L Statique Trafic vers VCN2
    10.30.0.0/16 Passerelle d'appairage local LPG1R Statique Trafic vers VCN3
  10. Ajoutez des règles de routage à la table de routage du sous-réseau client de VCN2 pour transmettre le trafic ciblé pour VCN1 à LPG2L et transmettre le trafic ciblé pour VCN3 à LPG2R.
    Destination Type de cible Cible Type de route Description
    10.10.0.0/16 Passerelle d'appairage local LPG2L Statique Trafic vers VCN1
    10.30.0.0/16 Passerelle d'appairage local LPG2R Statique Trafic vers VCN3
  11. Créez une table de routage HubLPG1rt dans HubVCN1.
  12. Associez la table de routage HubLPG1rt à la passerelle d'appairage local HubLPG1.
  13. Associez la table de routage HubLPG2rt à la passerelle d'appairage local HubLPG2.
  14. Créer la passerelle de routage dynamique DRG1.
  15. Créez une table de routage DRG1rt dans HubVCN1.
  16. Ajoutez deux règles de routage à la table de routage DRG1rt : une pour transférer le trafic ciblé pour VCN1 vers HubLPG1 et une deuxième pour transférer le trafic ciblé pour VCN2 vers HubLPG2.
    Destination Type de cible Cible Type de route Description
    10.10.0.0/16 Passerelle d'appairage local HubLPG1 Statique Trafic vers VCN1
    10.10.0.0/16 Passerelle d'appairage local HubLPG2 Statique Trafic vers VCN2
  17. 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.
  18. Créez une connexion d'appairage distant dans DRG1, nommée RPC1.
  19. Ajoutez une règle de routage à HubLPG1rt pour transférer le trafic ciblé pour VCN2 et VCN3 à DRG1.
    Destination Type de cible Cible Type de route Description
    10.30.0.0/16 Passerelle de routage dynamique DRG1 Statique Trafic vers VCN3
  20. Ajoutez une règle de routage à HubLPG2rt pour transférer le trafic ciblé pour VCN2 et VCN3 à DRG1.
    Destination Type de cible Cible Type de route Description
    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 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
  2. Créez un réseau en nuage virtuel HubVCN3 avec CIDR 10.33.0.0/16.
  3. Créez la passerelle d'appairage local HubLPG3 dans le réseau en nuage virtuel HubVCN3.
  4. Créez la passerelle d'appairage local LPG3R dans le réseau en nuage virtuel VCN3.
  5. Établissez 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 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
  7. Créez une table de routage HubLPG3rt dans HubVCN3.
  8. Associez la table de routage HubLPG3rt à la passerelle d'appairage local HubLPG3.
  9. Créer la passerelle de routage dynamique DRG3.
  10. Créez une table de routage DRG3rt dans HubVCN3.
  11. 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
  12. Pour joindre DRG3 à 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.
  13. Créez une connexion d'appairage distant dans DRG3, nommée RPC3.
  14. Établissez une connexion d'appairage distant entre RPC1 (région 1) et RPC3 (région 3).
  15. 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