En savoir plus sur Oracle Data Guard Fast-Start Failover

Oracle AI Database@Azure permet des workloads Oracle AI Database stratégiques dans les data centers Azure à l'aide d'Oracle Exadata Database Service on Exascale Infrastructure et d'Oracle Exadata Database Service on Dedicated Infrastructure.

Vous obtenez une haute disponibilité, des performances et une évolutivité intégrées d'Oracle Exadata Database Machine et d'Oracle Real Application Clusters (Oracle RAC), avec une faible latence pour les applications basées sur Azure.

L'extension de la solution avec une base de données de secours dans une autre zone ou région de disponibilité assure la protection des données et la récupération après sinistre pour les pannes de centre de données et régionales.

Data Guard transporte de manière synchrone les données vers la base de données de secours afin d'éviter toute perte de données. Fast-Start Failover permet au broker de basculer automatiquement la base de données de secours cible vers le rôle principal sans étapes de basculement manuel.

Les sites observateurs surveillent l'environnement Fast-Start Failover. Un observateur est un composant côté client distinct qui s'exécute sur une machine virtuelle de calcul différente des bases de données principale et de secours et surveille la disponibilité de la base de données principale.

Fast-Start Failover fournit un basculement plus rapide avec un objectif de temps de récupération (RTO) configurable, avec une perte de données nulle en mode synchrone ou un objectif de point de récupération limité en mode asynchrone.

Dans ce guide stratégique de solution, vous apprendrez à configurer et déployer Data Guard et à activer Fast-Start Failover dans les zones de disponibilité Oracle AI Database@Azure à l'aide d'Oracle Exadata Database Service on Exascale Infrastructure. La même solution s'applique à Oracle Exadata Database Service on Dedicated Infrastructure.

Avant de commencer

Vérifiez les prérequis et les références avant de configurer Data Guard et Fast-Start Failover.

Avant de commencer, vérifiez les éléments suivants :

  • Les clusters de machines virtuelles Exascale sont déployés dans différentes zones de disponibilité Azure.
  • Oracle AI Database 26ai est créé dans la zone de disponibilité principale.
  • Les plages de CIDR d'adresse IP réseau des clusters de machines virtuelles Exascale principal et de secours ne se chevauchent pas.

Consultez les solutions proposées :

Vous devez ensuite provisionner une machine virtuelle de calcul dans Azure pour héberger l'observateur, de préférence dans une zone de disponibilité différente de celle des bases de données principale et de secours. L'observateur peut s'exécuter sur une machine virtuelle légère car il fonctionne en tant que client Oracle se connectant aux bases de données principale et de secours.

Architecture

Oracle AI Database est exécuté dans un cluster de machines virtuelles Exascale dans la zone de disponibilité principale. Pour la protection des données, Data Guard réplique les données vers une autre zone de disponibilité (de secours locale) de la même région.

L'architecture suivante présente une instance Data Guard interzones avec l'observateur exécuté dans une autre zone de disponibilité :


Description de l'image cross-zones-dg-oracledb-azure.png ci-après
Description de l'illustration cross-zones-dg-oracledb-azure.png ci-après

cross-zones-dg-oracledb-azure-oracle.zip

Vous pouvez acheminer le trafic Data Guard via le réseau Oracle Cloud Infrastructure (OCI) ou Azure. Cette architecture dirige le trafic réseau Data Guard via le réseau Azure pour conserver toutes les données au sein de la plate-forme Azure. Les réseaux cloud virtuels sur le site OCI sont créés une fois que les clusters de machines virtuelles Oracle Exadata Database Service on Exascale Infrastructure sur Oracle AI Database@Azure ont été créés pour les bases de données principale et de secours.

Dans cette architecture :

  • Le cluster de machines virtuelles Exascale principal est déployé dans la zone de disponibilité principale dans VNet1 avec le CIDR 10.10.0.0/16 et le CIDR de sous-réseau délégué 10.10.1.0/24.
  • Le cluster de machines virtuelles Exascale de secours est déployé dans la zone de disponibilité de secours dans VNet2 avec le CIDR 10.20.0.0/16 et le CIDR de sous-réseau délégué 10.20.1.0/24.
  • L'observateur est déployé dans VNet3 avec le CIDR 10.30.0.0/16 et le CIDR de sous-réseau 10.30.1.0/24.
  • VNet1 est appairé avec VNet2 pour permettre au trafic Data Guard de circuler entre les bases de données principale et de secours.
  • VNet3 est appairé avec VNet1 et VNet2 pour permettre à l'observateur de se connecter aux deux bases de données.

Cette architecture comporte 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 une des autres et peuvent les séparer d'un pays ou d'un continent à l'autre, et les grandes distances peuvent les séparer.

    Les régions Azure et OCI sont des zones géographiques localisées. Pour Oracle AI 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é dans OCI. Les paires de régions Azure et OCI sont sélectionnées pour minimiser la distance et la latence.

  • Domaine de disponibilité Azure

    Le domaine de disponibilité Azure, ou ensemble de disponibilité, est un regroupement logique de machines virtuelles.

  • Réseau virtuel Azure et sous-réseau

    Le réseau virtuel Azure (VNet) vous permet de déployer des ressources Azure dans un réseau privé isolé logiquement que vous définissez. Ce réseau ressemble à un réseau sur site traditionnel, tout en bénéficiant de l'infrastructure cloud évolutive et hautement disponible d'Azure. Une fois que vous avez créé un VNet, vous pouvez le segmenter en sous-réseaux afin d'organiser et de contrôler le trafic réseau pour vos charges globales.

  • Sous-réseau délégué Azure

    Un sous-réseau délégué est un sous-réseau VNet réservé et délégué au service Oracle AI Database@Azure, ce qui permet à Oracle de déployer et de gérer les ressources de base de données requises dans l'espace IP de votre réseau privé.

  • Carte d'interface Azure Virtual Network (VNIC)

    Les services des centres de données Azure disposent de cartes d'interface réseau (NIC) physiques. 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 VNIC principale qui est créée et attachée automatiquement au cours du lancement et qui est disponible pendant la durée de vie de l'instance.

  • Machine virtuelle de calcul Microsoft Azure

    Les machines virtuelles Azure fournissent des ressources de calcul évolutives à la demande que vous pouvez utiliser comme un serveur physique ou un bureau. Utilisez des machines virtuelles lorsque vous avez besoin d'un contrôle total sur le système d'exploitation et l'environnement logiciel.

    Les machines virtuelles éliminent la nécessité de gérer le matériel physique, mais vous configurez, appliquez des patches et gérez le logiciel qui s'exécute dessus. Ils prennent en charge les charges de travail personnalisées et héritées.

  • Région OCI

    Une région OCI est une zone géographique précise qui contient des centres de données, hébergeant des domaines de disponibilité. Les régions sont indépendantes les une des autres et peuvent les séparer d'un pays ou d'un continent à l'autre, et les grandes distances peuvent les séparer.

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

  • Groupe de sécurité réseau

    Les groupes de sécurité réseau agissent comme des pare-feux virtuels 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.

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

  • Oracle AI Database@Azure

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

    Oracle AI Database@Azure intègre les technologies Oracle Exadata Database Service, Oracle Real Application Clusters (Oracle RAC) et 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 Azure Virtual Network (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 AI 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 AI Database s'appuie sur l'infrastructure Oracle Exadata, est auto-géré, auto-sécurisé et auto-réparé, ce qui aide à éliminer la gestion manuelle des bases de données et les erreurs humaines. Autonomous AI Database permet le développement d'applications évolutives alimentées par l'IA avec toutes les données à l'aide de fonctionnalités d'IA intégrées à l'aide de votre choix de grand modèle de langage (LLM) et d'emplacement de déploiement.

    Oracle Exadata Database Service et Oracle Autonomous AI Database Serverless sont 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'activation de Fast-Start Failover pour Oracle Exadata Database Service on Exascale Infrastructure sur Oracle AI Database@Azure.

Vos exigences peuvent différer de l'architecture décrite ici.

  • Placez l'observateur sur un hôte sur un troisième site distinct. Cela garantit que si le site principal ou de secours échoue entièrement, l'observateur reste actif pour coordonner le basculement ou surveiller le site restant.
  • Si aucun troisième site n'est disponible, placez l'observateur sur le site principal.
  • Configurez plusieurs observateurs sur différents serveurs pour une haute disponibilité. Alors qu'un seul observateur peut être l'observateur principal, des observateurs supplémentaires servent d'observateurs de secours.
  • Suivez la documentation Oracle pour définir les valeurs des propriétés de configuration Fast-Start Failover, telles que les propriétés Fast-Start Failover, telles que FastStartFailoverThreshold, FastStartFailoverLagLimit et FastStartFailoverAutoReinstate.
  • Exécutez toujours l'observateur du broker Data Guard à l'aide de la même version majeure et du même niveau de patch (y compris la mise à jour de version [RU]) que les répertoires de base Oracle AI Database dans votre configuration Data Guard. Cette combinaison reçoit les tests les plus approfondis et minimise les risques opérationnels. Elle garantit également que toutes les corrections affectant à la fois le code côté client (observateur) et le code côté serveur (base de données) sont en place à tout moment. Une différence pouvant aller jusqu'à une version majeure du support à long terme (LTS) entre l'observateur et la base de données est autorisée, principalement pour faciliter les mises à niveau non simultanées et minimiser les temps d'arrêt. Par exemple, l'observateur à 26ai avec la base de données à 19c pendant les procédures de mise à niveau ou vice versa.

Points à prendre en compte

Lors de l'activation de Fast-Start Failover pour Oracle Exadata Database Service on Exascale Infrastructure sur Oracle AI Database@Azure, tenez compte des points suivants :
  • Ne placez jamais l'observateur sur le même site que la base de données de secours. Si le site de secours tombe en panne, la base principale s'arrête également car elle ne peut pas communiquer avec l'observateur, ce qui entraîne une panne complète.
  • L'observateur peut s'exécuter sur une machine virtuelle légère. Toutefois, la stabilité de la connexion réseau à la base principale et à la base de secours est essentielle pour garantir le bon fonctionnement et éviter les basculements inutiles.
  • Configurez le mode de disponibilité maximale de Data Guard pour éviter toute perte de données. Si vous êtes plus préoccupé par les performances de la base de données principale qu'une perte minimale de données, envisagez d'activer Fast-Start Failover lorsque le mode de protection de la configuration est défini sur Performances maximales.

  • Le temps de basculement dépend du fait que la base de données de secours cible a ou non appliqué toutes les données de journalisation reçues de la base de données principale. La fonction Fast-Start Failover est plus rapide lorsque vous prenez des mesures pour optimiser la récupération afin que l'application des données de journalisation à la base de secours soit mise à jour avec le taux d'application des données de journalisation de la base principale. Reportez-vous à la section Remarques concernant les performances pour Fast-Start Failover de la documentation Data Guard sur les concepts de broker.

  • Le temps de basculement dépend de l'état d'application des informations de journalisation dans la base de données de secours.

A propos des services et rôles requis

Passez en revue les services et rôles requis pour créer une base de données de secours et gérer les fonctions de réseau pour Fast-Start Failover.

Cette solution requiert les services et rôles suivants :

  • Oracle Exadata Database Service on Exascale Infrastructure
  • Oracle Cloud Infrastructure Networking

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

Nom du service : Rôle Obligatoire pour...
Base de données OCI : manage database-family Créer une base de données de secours Data Guard
Mise en réseau OCI : manage vcn-family Gestion du groupe de sécurité réseau dans OCI

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