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

La continuité des activités est essentielle au succès de la conception des applications. Pour y parvenir, il faut une stratégie de récupération après sinistre capable de restaurer rapidement le service en cas de perturbations.
Depuis des décennies, les entreprises s'appuient sur Oracle Exadata Database Machine et Oracle Data Guard, la première technologie de récupération après sinistre d'Oracle, pour prendre en charge des applications stratégiques, sur site ou au sein d'Oracle Cloud Infrastructure (OCI). Oracle Exadata Database Service on Dedicated Infrastructure sur Oracle Database@AWS offre les mêmes performances, l'ensemble de fonctionnalités et la même parité de prix que Exadata sur OCI. Le matériel réside dans les data centers d'AWS pour fournir une faible latence aux applications AWS en plus de capacité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.

Dans ce guide de solution, vous apprendrez à implémenter la récupération après sinistre avec des bases de données locales et régionales sur Oracle Database@AWS.

Avant de commencer

Avant de commencer, vérifiez les éléments suivants :
  • L'infrastructure Exadata et les clusters de machines virtuelles Exadata sont déployés dans la zone et la région de disponibilité de secours.
  • Les plages de CIDR d'adresse IP réseau pour les clusters de machines virtuelles Exadata principal et de secours ne se chevauchent pas.

Consultez les solutions proposées :

Consultez les ressources associées 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 autre zone de disponibilité.
  • Base de données de secours distante dans une autre région.

Description de l'image 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 un cluster de machines virtuelles Exadata dans le fichier Region 1 principal. 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 clusters de machines virtuelles Exadata suivants :

  • Une dans la même région mais dans une autre zone de disponibilité (base de secours locale). Une base de données de secours locale est idéale pour les scénarios de basculement, sans perte de données pour les pannes locales, tandis que les applications continuent à fonctionner sans la surcharge de performances liée à la communication avec une région distante.
  • Une 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 globales en lecture seule.

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

Le réseau Oracle Exadata Database Service sur Oracle Database@AWS 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 deuxième VCN avec son propre DRG est requis pour connecter les réseaux cloud virtuels principal et de secours dans chaque région.

  • Le cluster de machines virtuelles Exadata principal est déployé dans Region 1, availability zone 1 dans VCN1 avec le CIDR 10.10.0.0/16 et le CIDR de sous-réseau client 10.10.1.0/24.
  • VCN1 dispose de passerelles d'appairage local LPG1 remote et LPG1 local.
  • Le VCN du hub dans le Region 1 principal est Hub VCN1 avec le CIDR 10.11.0.0/16.
  • Le premier cluster de machines virtuelles Exadata de secours est déployé dans Region 1, availability zone 2 dans VCN2 avec le CIDR 10.20.0.0/16 et le CIDR de sous-réseau client 10.20.1.0/24.
  • VCN2 dispose de deux passerelles d'appairage local LPG2 remote et LPG2 local.
  • Le VCN hub est le même que le VCN hub pour la base de données principale, Hub VCN1, car il réside dans la même région.
  • Hub VCN1 dispose de la passerelle d'appairage local Hub LPG1, Hub LPG2 et DRG1.
  • Le deuxième cluster de machines virtuelles Exadata de secours est déployé dans Region 2 dans VCN3 avec le CIDR 10.30.0.0/16 et le CIDR de sous-réseau client 10.30.1.0/24.
  • VCN3 dispose d'une passerelle d'appairage local LPG3 remote.
  • Le VCN hub dans la base de données de secours distante Region 2 est Hub VCN3 avec le CIDR 10.33.0.0/16.
  • Hub VCN3 possède une passerelle d'appairage local Hub LPG3 et une passerelle d'appairage local DRG DRG3.
  • 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 de 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 qui sont connectées avec un réseau à faible latence, haut débit et 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 et sous-réseau cloud virtuel OCI

    Un réseau cloud virtuel est un réseau personnalisable défini par logiciel que vous configurez dans une région OCI. Comme les Réseaux de centre de données traditionnels, les Réseaux cloud virtuels vous donnent un contrôle sur l'environnement réseau. Un VCN peut comporter plusieurs blocs de routage interdomaine sans classe (CIDR) qui ne se chevauchent pas et que vous pouvez modifier une fois le VCN 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 permettant de router le trafic des sous-réseaux vers des destinations en dehors d'un VCN, généralement via des passerelles.

  • Groupe de sécurité réseau

    Les groupes de sécurité réseau servent de pare-feu virtuel pour vos ressources cloud. Avec le modèle de sécurité sans confiance d'OCI, vous contrôlez le trafic réseau au sein 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 à un seul ensemble de cartes d'interface réseau virtuelles (VNIC) dans un seul VCN.

  • Appairage local

    L'appairage local permet à deux réseaux cloud virtuels de la même région OCI de communiquer directement à l'aide d'adresses IP privées. Cette communication ne traverse ni Internet ni votre réseau sur site. L'appairage local est activé par une passerelle d'appairage local, qui sert de point de connexion entre les réseaux cloud virtuels. Configurez une passerelle d'appairage local 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

    Le DRG est un routeur virtuel qui fournit un chemin pour le trafic de réseau privé entre les réseaux cloud virtuels d'une 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 site ou un réseau dans un autre fournisseur cloud.

  • Appairage à distance

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

  • Oracle 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 AI Database sur une infrastructure Oracle Exadata optimisée et spécialement conçue dans le cloud public. L'automatisation intégrée du cloud, l'évolutivité élastique des ressources, la sécurité et les performances rapides pour tous les workloads 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 maintenir, de gérer et de surveiller des bases de données de secours afin que des bases de données Oracle de production puissent 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 planifiée, 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 principalement vers les bases de données de secours et fournit également des fonctionnalités avancées de protection des données.

Recommandations

Utilisez les recommandations suivantes comme point de départ lors de la récupération après sinistre pour Oracle Exadata Database Service sur Oracle Database@AWS. 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 grâce à la réparation automatique des blocs, aux mises à niveau en ligne et aux migrations, et pour décharger la charge de travail vers la base de données de secours avec un redimensionnement majoré en lecture.
  • Activez 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.
  • Configurez des sauvegardes automatiques vers Oracle Database Autonomous Recovery Service dans OCI. Bien que les données soient protégées par Oracle Data Guard, réduisez la charge globale de sauvegarde sur la base de données en implémentant la stratégie de sauvegarde incremental-forever qui élimine les sauvegardes complètes hebdomadaires. Vous pouvez également utiliser Amazon Simple Storage Service pour les sauvegardes automatiques.
  • Exécutez des sauvegardes à partir de la base de données de secours pour effectuer une réplication de sauvegarde inter-région.
  • Utilisez OCI Full Stack DR pour orchestrer les opérations de permutation et de basculement de base de données.
  • Stockez les clés de cryptage transparent des données (TDE) de la base de données dans OCI Vault avec des clés gérées par le client.

Points à prendre en compte

Lorsque vous effectuez une 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 clusters de machines virtuelles Exadata sont créés sur le site enfant Oracle Database@AWS, chaque cluster de machines virtuelles Exadata est provisionné dans son propre VCN OCI. homologuez les réseaux cloud virtuels, évitez les chevauchements de CIDR et assurez-vous que les bases de données communiquent entre elles afin que Data Guard puisse envoyer les données redo.
  • La latence inter-région est généralement trop élevée pour le transport synchrone dans les applications stratégiques. Par conséquent, utilisez la réplication ASYNC Data Guard entre les régions. Ajoutez la synchronisation à distance Active Data Guard pour garantir l'absence de perte de données entre les régions.
  • Configurez OCI comme réseau préféré pour de meilleures performances, une latence plus faible, un débit plus élevé et des coûts réduits. Les 10 premiers To/mois de sortie de données sont gratuits dans 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 cloud.

A propos des services et rôles requis

Cette solution requiert les services et rôles suivants :

  • Oracle Cloud Infrastructure Networking
  • Oracle Exadata Database Service

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

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

Reportez-vous à Produits, solutions et services Oracle pour obtenir ce dont vous avez besoin.