En savoir plus sur le déploiement de la synchronisation à distance Active Data Guard
Oracle Database@Azure vous permet d'exécuter vos bases de données Oracle stratégiques à l'aide d'Oracle Exadata Database Service on Dedicated Infrastructure dans le centre de données de Microsoft Azure.
Tirez parti de la haute disponibilité, des performances et de l'évolutivité intégrées d'Oracle Exadata Database Service et d'Oracle Real Application Clusters (Oracle RAC) tout en bénéficiant d'une faible latence pour les applications Azure.
L'extension de l'architecture avec une base de données de secours hébergée sur un autre cluster de machines virtuelles Exadata offre une protection de récupération après sinistre contre les pannes de base de données et de cluster. Le fait de placer la base de données de secours dans une autre zone de disponibilité Azure améliore encore la solution, garantissant ainsi une protection contre toute panne d'AZ. Pour une récupération après sinistre régionale complète, la base de données de secours doit être déployée dans une région distincte.
Oracle Data Guard vous permet de transporter les informations de journalisation de manière synchrone vers la base de données de secours afin d'éviter toute perte de données. Toutefois, lorsque la base de données de secours est géographiquement trop éloignée, la latence augmente, ce qui a un impact sur le temps de réponse de validation et le débit des transactions au niveau de la base principale. La synchronisation à distance Active Data Guard peut garantir l'absence de perte de données à distance, avec un impact minimal sur les performances de la base de données principale. La synchronisation à distance, une instance légère, fournit une protection synchrone des informations de journalisation et un basculement sans perte de données sans nécessiter de base de données de secours locale synchrone.
Architecture
Cette architecture de référence présente une récupération après sinistre inter-région avec Active Data Guard.
Deux instances de synchronisation à distance Active Data Guard sont créées dans les régions Oracle Cloud Infrastructure (OCI) correspondantes. La base principale de Toronto envoie les données de journalisation en mode SYNC à l'instance de synchronisation à distance locale de Toronto, qui transmet les données de journalisation en mode ASYNC à la base de secours de la région distante de Sydney.
Après un changement de rôle et que la base de données de Sydney devient la base principale, elle envoie les données de journalisation en mode SYNC à son instance locale de synchronisation à distance à Sydney, qui transmet les données de journalisation en mode ASYNC à la base de données de secours dans la région distante de Toronto.
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. Une instance DRG est également requise 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.
L'application est répliquée dans toutes les régions pour accéder à la base de données de la même région et obtenir la latence la plus faible et les performances les plus élevées.
Le schéma suivant illustre cette architecture de référence.
active-data-guard-far-sync-dba-oracle.zip
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.
- Azure VNet
Le réseau virtuel Microsoft Azure (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
La délégation de sous-réseau est la capacité de Microsoft à injecter un service géré, en particulier un service de plate-forme en tant que service (PaaS), directement dans votre réseau virtuel. Cela vous permet de désigner ou de déléguer un sous-réseau en tant que répertoire de base pour un service géré externe au sein de votre réseau virtuel, de sorte que le service externe joue le rôle de ressource de réseau virtuel, même s'il s'agit d'un service PaaS externe.
- 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.
Oracle Cloud Infrastructure fournit les composants suivants :
- Région
Une région Oracle Cloud Infrastructure est une zone géographique précise, incluant 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 (entre les pays ou même les continents).
- Réseau cloud virtuel (VCN) et sous-réseau
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.
- 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
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 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 routage via votre réseau sur site.
- 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.
- Synchronisation à distance Active Data Guard
Oracle Active Data Guard Far Sync est une instance de base de données Oracle légère qui reçoit les données de journalisation de manière synchrone à partir de la base de données principale et les transmet de manière asynchrone à des bases de données de secours. Elle garantit une perte de données nulle à toute distance, avec un impact minimal sur les performances de la base principale et sans nécessiter de base de données de secours synchrone locale.
- 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
- L'instance de synchronisation à distance doit être suffisamment éloignée de la base de données principale pour s'assurer qu'elle ne peut pas être affectée par le même échec ou sinistre, mais suffisamment proche pour minimiser la latence du réseau.
- Créez deux instances de synchronisation à distance par région pour la haute disponibilité. En l'absence d'autre instance de synchronisation à distance ou si toutes les instances de synchronisation à distance de la région principale ne sont pas disponibles, le transport des informations de journalisation Oracle Data Guard est directement expédié à la base de données de secours en mode ASYNC, ce qui a une incidence sur la protection contre les pertes de données nulles. Selon la configuration et la distance, le retard de transport peut avoir un impact supplémentaire sur le RPO.
- Les performances de stockage de l'instance de synchronisation à distance étant essentielles, la capacité IOPS doit être suffisante pour prendre en charge la charge globale. Le stockage de l'instance de synchronisation à distance doit avoir des performances IOPS égales ou supérieures au stockage des fichiers de journalisation en ligne de la base de données principale.
- Utilisez Oracle Data Guard entre 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é OCI.
Considérations relatives à la reprise après sinistre interrégionale
Lors de l'exécution de la récupération après sinistre inter-région pour Oracle Exadata Database Service sur Oracle Database@Azure, tenez compte des points suivants.
- Oracle Cloud Infrastructure est le réseau préféré pour obtenir de meilleures performances, mesurées par la latence et le débit, et pour réduire les coûts, car les 10 premiers To/mois sont gratuits.
- La synchronisation à distance est une instance légère. Toutefois, les performances du disque sont critiques car la synchronisation à distance écrit les informations de journalisation reçues sur le disque avant d'accuser réception vers la base principale, ce qui peut avoir un impact sur les performances de l'application.
- Les performances réseau de l'instance de synchronisation à distance sont essentielles pour les charges globales lourdes.
- Avec plusieurs bases de données de secours et instances de synchronisation à distance, la configuration peut devenir plus compliquée. Utilisez la propriété RedoRoutes du broker Active Data Guard pour simplifier la définition du mode de transport des informations de journalisation vers les différentes destinations.
- L'utilisation de la synchronisation à distance nécessite l'option Active Data Guard.