En savoir plus sur la reprise après sinistre pour les bases de données locales et régionales

La continuité des activités est essentielle à la réussite de la conception des applications. Pour ce faire, il faut une stratégie de reprise après sinistre qui peut restaurer rapidement le service pendant les interruptions.
Pendant des décennies, les organisations se sont appuyées sur Oracle Exadata Database Machine et Oracle Data Guard, la technologie de reprise après sinistre de premier plan 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@AWS brings the same industry-leading performance, feature set, and price parity as Exadata on OCI. Le matériel réside dans les centres de données d'AWS pour fournir une faible latence aux applications AWS en plus des capacités inégalées de haute disponibilité et de reprise après sinistre, assurant des opérations fluides pendant la maintenance et en cas de perturbation.

Dans ce livre de jeu de solution, vous apprendrez à mettre en oeuvre la récupération après sinistre avec des bases de secours locales et régionales sur Oracle Database@AWS.

Étapes préliminaires

Avant de commencer, vérifiez les points suivants :
  • L'infrastructure Exadata et les grappes de machines virtuelles Exadata sont déployées dans la zone et la région de disponibilité de secours.
  • Les intervalles CIDR d'adresses IP de réseau pour les grappes de machines virtuelles Exadata principale et de secours ne se chevauchent pas.

Examinez les solutions suivantes :

Vérifiez les ressources connexes suivantes :

Architecture

Cette architecture présente Oracle Exadata Database Service sur Oracle Database@AWS dans une topologie de récupération après sinistre à l'aide de deux bases de données de secours :
  • Base de données de secours locale dans la même région que la base de données principale, mais dans une zone de disponibilité différente.
  • Base de données de secours distante dans une autre région.

Description d'exadb-dbaws-dr-arch.png
Description de l'illustration exadb-dbaws-dr-arch.png

exadb-dbaws-dr-arch-oracle.zip

Oracle Database s'exécute dans une grappe de machines virtuelles Exadata dans la Region 1 principale. Pour la protection des données et la récupération après sinistre, Active Data Guard réplique les données vers les deux grappes de machines virtuelles Exadata suivantes :

  • Une dans la même région, mais dans une zone de disponibilité différente (base de secours locale). Une base de données de secours locale est idéale pour les scénarios de basculement, offrant aucune perte de données pour les défaillances locales tandis que les applications continuent de fonctionner sans la surcharge de performance liée à la communication avec une région distante.
  • Deuxième base de données de secours dans une autre région (base de données de secours 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.

Bien que le trafic réseau d'Active Data Guard puisse traverser l'infrastructure AWS, Oracle recommande cette architecture qui l'achemine sur OCI pour un débit et une latence optimisés.

The Oracle Exadata Database Service on Oracle Database@AWS 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 de différentes régions. Comme une seule passerelle DRG est autorisée par VCN dans OCI, un deuxième VCN avec sa propre passerelle DRG est requis pour connecter les réseaux en nuage virtuels principal et de secours dans chaque région.

  • La grappe de machines virtuelles Exadata principale est déployée dans Region 1, availability zone 1 dans VCN1 avec le bloc CIDR 10.10.0.0/16 et le bloc CIDR du sous-réseau client 10.10.1.0/24.
  • VCN1 comporte des passerelles d'appairage local (LPG) LPG1 remote et LPG1 local.
  • Le VCN central dans le Region 1 principal est Hub VCN1 avec le bloc CIDR 10.11.0.0/16.
  • La première grappe de machines virtuelles Exadata de secours est déployée dans Region 1, availability zone 2 dans VCN2 avec le bloc CIDR 10.20.0.0/16 et le bloc CIDR du sous-réseau client 10.20.1.0/24.
  • VCN2 comporte deux passerelles LPG LPG2 remote et LPG2 local.
  • Le VCN central est le même que le VCN central pour la base de données principale, Hub VCN1, car il réside dans la même région.
  • Hub VCN1 a une passerelle LPG Hub LPG1, Hub LPG2 et DRG1.
  • La deuxième grappe de machines virtuelles Exadata de secours est déployée dans Region 2 dans VCN3 avec le bloc CIDR 10.30.0.0/16 et le bloc CIDR du sous-réseau client 10.30.1.0/24.
  • VCN3 a une passerelle LPG LPG3 remote.
  • Le VCN central dans la base de données de secours distante Region 2 est Hub VCN3 avec le bloc CIDR 10.33.0.0/16.
  • Hub VCN3 a une passerelle LPG Hub LPG3 et une passerelle DRG DRG3.
  • 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 CIDR IP.

Cette architecture prend en charge les composants suivants :

  • Région AWS

    Les régions AWS sont des zones géographiques distinctes. Elles se composent de plusieurs zones de disponibilité isolées et physiquement séparées, connectées au moyen d'un réseau à faible latence et à haut débit hautement redondant.

  • Zone de disponibilité AWS

    Les zones de disponibilité sont des centres de données hautement disponibles dans chaque région AWS.

  • Réseau en nuage virtuel et sous-réseau OCI

    Un réseau en nuage virtuel (VCN) est un réseau défini par logiciel personnalisable, configuré dans une région OCI. 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 de routage inter-domaine (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.

  • Groupe de sécurité de réseau

    Les groupes de sécurité de réseau servent de pare-feu virtuels pour vos ressources en nuage. Avec le modèle de sécurité zéro confiance d'OCI, vous contrôlez le trafic réseau dans un VCN. Un groupe de sécurité de réseau est composé d'un jeu de règles de sécurité de trafic entrant et sortant qui s'appliquent seulement à un jeu spécifié de cartes d'interface réseau virtuelle (vNIC) dans un seul VCN.

  • Appairage local

    L'appairage local permet à deux réseaux en nuage virtuels de la même région OCI de communiquer directement à l'aide d'adresses IP privées. Cette communication ne passe pas par Internet ni par votre réseau sur place. L'appairage local est activé par une passerelle d'appairage local (LPG), qui sert de point de connexion entre les réseaux en nuage virtuels. Configurez une passerelle LPG dans chaque VCN et établissez une relation d'appairage pour permettre aux instances, aux équilibreurs de charge et aux autres ressources d'un VCN d'accéder en toute sécurité aux ressources d'un autre VCN dans la même région.

  • Passerelle de routage dynamique (DRG)

    La passerelle DRG est un routeur virtuel qui fournit un chemin pour le trafic réseau privé entre des réseaux en nuage 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 OCI, un réseau sur place ou un réseau dans un autre fournisseur de nuage.

  • Appairage distant

    L'appairage distant permet une communication privée entre les ressources de différents réseaux en nuage virtuels, qui peuvent être situés dans la même région OCI ou dans des régions différentes. Chaque VCN utilise sa propre passerelle de routage dynamique (DRG) pour l'appairage distant. Les passerelles de routage dynamique acheminent le trafic entre les réseaux en nuage virtuels au moyen du réseau fédérateur privé d'OCI, ce qui permet aux ressources de communiquer à l'aide d'adresses IP privées sans acheminer le trafic sur Internet ou au moyen de réseaux sur place. L'appairage distant élimine le besoin de passerelles Internet ou d'adresses IP publiques pour les instances qui doivent se connecter entre les régions.

  • Service Oracle 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'base de données Oracle AI sur l'infrastructure Oracle Exadata optimisée et spécialement conçue dans le nuage public. L'automatisation intégrée du nuage, la mise à l'échelle élastique des ressources, la sécurité et la performance rapide pour toutes les charges de travail d'Oracle AI Database vous aident à simplifier la gestion et à réduire les coûts.

  • Oracle Data Guard

    Oracle Data Guard et Active Data Guard fournissent un ensemble complet de services permettant de créer, de tenir à jour, de gérer et de surveiller une ou plusieurs 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 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.

Recommandations

Utilisez les recommandations suivantes comme point de départ lors de l'exécution de la récupération après sinistre pour le service Oracle Exadata Database Service sur Oracle Database@AWS. 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 pour décharger la charge de travail vers la base de données de secours avec une évolutivité horizontale en lecture principale.
  • 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.
  • Configurez les sauvegardes automatiques dans Oracle Database Autonomous Recovery Service dans OCI. Bien que les données soient protégées par Oracle Data Guard, réduisez la charge de travail de sauvegarde sur la base de données en mettant en oeuvre la stratégie de sauvegarde incremental-forever qui élimine les sauvegardes complètes hebdomadaires. Vous pouvez également utiliser le service de stockage simple d'Amazon pour les sauvegardes automatiques.
  • Exécutez des sauvegardes à partir de la base de secours pour effectuer une réplication de sauvegarde inter-région.
  • 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.
  • Stockez les clés TDE (Transparent Data Encryption) de la base de données dans le service Chambre forte OCI avec des 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@AWS, tenez compte des éléments suivants :

  • Lorsque des grappes de machines virtuelles Exadata sont créées dans le site enfant Oracle Database@AWS, chaque grappe de machines virtuelles Exadata est provisionnée dans son propre VCN OCI. Appliquez un appairage aux réseaux en nuage virtuels et évitez les blocs CIDR qui se chevauchent et assurez-vous que les bases de données communiquent entre elles afin que Data Guard puisse expédier les données redo.
  • La latence inter-régions est généralement trop élevée pour le transport synchrone dans les applications critiques. Par conséquent, utilisez la réplication ASYNC de Data Guard entre les régions. Ajoutez Synchronisation à distance Active Data Guard pour éviter toute perte de données entre les régions.
  • Configurez OCI en tant que réseau privilégié pour une meilleure performance, une latence moindre, un débit plus élevé et un coût réduit. Les 10 premiers To/mois de sortie de données sont gratuits dans toutes les régions.
  • Vous pouvez créer jusqu'à six bases de données de secours par base de données principale à l'aide des outils en nuage.

À propos des services et des rôles requis

Cette solution nécessite les services et rôles suivants :

  • Service de réseau pour Oracle Cloud Infrastructure
  • Service Oracle Exadata Database

Il s'agit des rôles nécessaires pour chaque service.

Nom du service : Rôle Requis pour...
Service Oracle Exadata Database Service : manage database-family Gérer la base de données, y compris l'ajout et l'exploitation des déploiements d'Active Data Guard
Réseau OCI : manage vcn-family Gérer les composants de réseau, notamment les réseaux en nuage virtuels, les sous-réseaux, les règles de sécurité et l'appairage de réseau VCN

Voir Produits, solutions et services Oracle pour obtenir ce dont vous avez besoin.