Migrer des applications d'affaires critiques vers Oracle Database@Azure à l'aide d'une stratégie progressive

Migrez une base de données et une application sur place vers le nuage, en minimisant les temps d'arrêt grâce à des stratégies progressives ou hybrides, pour assurer une connectivité transparente des applications basées sur le nuage aux bases de données sur place. Un plan bien structuré accélère la sortie du centre de données, atténue les risques et maintient la fiabilité. Une approche hybride en deux phases permet une transition en douceur tout en maintenant la stabilité.

Lorsque vous déplacez une base de données et une application sur place vers le nuage, vous devez relever plusieurs défis afin d'assurer une transition en toute transparence. Choisissez une stratégie de migration qui minimise les temps d'arrêt, comme la migration progressive ou les solutions en nuage hybrides, pour maintenir le temps de disponibilité des applications, en particulier pour les charges de travail critiques. Assurez-vous que les applications déjà en nuage, qui se connectent aux bases de données sur place, sont également prises en compte dans le plan de migration pour éviter les problèmes de connectivité. Pour les applications SaaS, où l'application réside dans le nuage, mais où la base de données est sur place, assurez-vous d'une stratégie complète incluant les deux composants. Répondez à ces défis de manière proactive afin d'assurer une transition en douceur et de maintenir la fiabilité de vos applications d'affaires critiques. Une stratégie bien structurée vous aide également à accélérer la sortie des centres de données et à réduire les risques de migration, assurant ainsi la fiabilité de vos applications d'affaires essentielles.

Oracle Database@Azure élimine la dépendance à Exadata sur place ou à Oracle Real Application Clusters (Oracle RAC) en rapprochant la base de données des charges de travail d'application dans Microsoft Azure. Cette intégration permet d'héberger la base de données et les applications dans le même centre de données, ce qui réduit la latence et minimise la dépendance à l'infrastructure physique.

La mise en œuvre de cette configuration nécessite souvent une solution soigneusement conçue pour établir l'architecture cible sans perturber les opérations commerciales critiques. De nombreuses charges de travail critiques sont déployées dans plusieurs régions pour assurer la continuité des activités dans des environnements de reprise après sinistre ou de secours. Cette approche prend en charge une stratégie de migration hybride en deux phases, permettant des transitions transparentes tout en maintenant la stabilité opérationnelle.

Étapes préliminaires

Avant de commencer, assurez-vous de tenir compte des éléments suivants :

  • Désactivez Fast-Start Failover dans Oracle Data Guard pour assurer une transition fluide et contrôlée entre les régions principale et de secours lors de la migration.
  • Le service de migration de bases de données pour OCI fournit des migrations Oracle Database et MySQL validées, interversion, tolérantes aux pannes et incrémentielles pour les cas d'utilisation en ligne et hors ligne, tels que le ZDM et le service de migration pour OCI.
  • Cette architecture de référence suit le modèle Oracle Gold Maximum Availability Architecture (MAA) dans une configuration de secours active avec déploiement inter-régions pour une résilience améliorée. Cette architecture de référence peut être étendue pour utiliser MAA platinum, où la haute disponibilité locale est obtenue par réplication synchrone à l'aide d'Oracle Data Guard entre les zones de disponibilité, tandis que la récupération après sinistre inter-région est mise en oeuvre avec la réplication asynchrone.

Architecture

Cette architecture décrit une approche progressive pour la migration d'Oracle Database sur place vers Oracle Exadata Database Service dans Oracle Database@Azure avec un temps d'arrêt minimal.

Pour simplifier cette stratégie, nous la décomposons en trois aspects clés : l'état actuel, l'état futur et les phases de migration.

Cette architecture de référence comporte quatre composants principaux (marqués avec des nombres bleus dans le diagramme).
Numérique Composant Description
1 Centre de données principal sur place Héberge la base de données et l'application en tant que système principal avant la migration.
2 Centre de données de secours sur place Tient à jour un système de secours, en répliquant la base de données principale sur place.
3 Région principale Azure Exécute l'application et la base de données sur Oracle Database@Azure, devenant ainsi le système principal après la migration.
4 Région de secours Azure Site de récupération après sinistre répliquant la région principale à l'aide d'Oracle Data Guard.

Description de l'architecture logique-diagram.png :
Description de l'illustration logic-architecture-diagram.png

logique-architecture-diagram-oracle.zip

État courant

Dans la configuration existante, le centre de données principal (1) et le centre de données de secours (2) sont hébergés sur place pour prendre en charge les charges de travail et les bases de données d'application. Le centre de données principal traite toutes les demandes, tandis que le centre de données de secours gère la réplication asynchrone à l'aide d'Oracle Data Guard. Cela garantit une haute disponibilité, le système de secours étant prêt pour le basculement en cas de panne inattendue.

État futur

L'architecture future reflète la configuration courante, mais est entièrement hébergée dans le nuage, couvrant deux régions Azure : la région principale (3) et la région de secours (4). La base de données est migrée vers les services Exadata Oracle Database@Azure, avec une réplication asynchrone entre les bases de données principale et de secours gérées au moyen d'Oracle Data Guard sur le réseau Oracle Cloud Infrastructure (OCI).

Pour une connectivité sécurisée entre le centre de données sur place et Azure, un pare-feu Azure est déployé dans un réseau étendu virtuel sécurisé (vWAN) Hub dans Azure.

Phases de migration

La migration suit une approche en deux phases pour assurer une transition contrôlée et fiable.

Phase 1 – Transition de la base de données de secours sur place vers Azure et permutation

Au cours de cette phase, le système de secours sur place (2) est migré vers Azure (3). Une fois l'opération terminée, les rôles principal (1) et de secours (3) sont échangés, faisant d'Azure la nouvelle région principale.

  1. Établissez la connectivité entre les systèmes sur place et Azure à l'aide d'Azure ExpressRoute.
  2. Configurez le concentrateur sécurisé Azure, le pare-feu Azure et le réseau vWAN pour la sécurité (si ce n'est pas déjà fait).
  3. Provisionnez Oracle Exadata Cloud Infrastructure dans la région principale d'Azure, puis :
    1. Configurez une grappe de machines virtuelles Oracle Exadata et créez la base de données cible.
    2. Activez les journaux d'archivage et la journalisation forcée sur la base de données principale (si elle n'est pas déjà activée).
  4. Configurez Oracle Net pour les noms de processus d'écoute et TNS pour la détection.
  5. Effectuez une restauration à partir du service pour configurer une base de données de secours dans la région principale (3) d'Azure.
  6. Effectuez une permutation, faisant de la base de données Azure (3) la nouvelle base principale.
  7. Migrer des applications vers la région principale Azure (3) et mettre à jour les routes DNS.
  8. Vérifiez la configuration de Data Guard et surveillez le statut de réplication.

Phase 2 – Établissement d'une base de données de secours dans Azure et mise hors service sur place

Au cours de cette phase, un système de secours (4) est configuré dans Azure et les ressources sur place (1 et 2) sont mises hors service.

  1. Provisionnez Oracle Exadata Cloud Infrastructure dans la région de secours (4) avec Oracle Database@Azure.
  2. Configurez une grappe de machines virtuelles Oracle Exadata et créez la base de données de secours.
  3. Activez Oracle Data Guard pour associer la base de données de région principale (3) à la base de données de secours (4).
  4. Utilisez le réseau OCI pour la réplication à haut débit, en tirant parti de l'appairage local et distant au sein d'une topologie en étoile entre les bases de données principale et de secours.
  5. Migrer les charges de travail d'application vers la région de secours Azure (4).
  6. Arrêtez la synchronisation avec les ressources sur place, puis mettez hors service les ressources d'application et de base de données sur place à partir des centres de données principal (1) et de secours (2).

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


Description de l'architecture physique-diagram.png
Description de l'illustration physical-architecture-diagram.png

architecture physique-diagramme-oracle.zip

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.

  • Azure VNet

    Microsoft 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

    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-service (PaaS), directement dans votre réseau virtuel. Cela vous permet de désigner ou de déléguer un sous-réseau comme répertoire de base pour un service géré externe dans votre réseau virtuel, de sorte que le service externe agit en tant que ressource de réseau virtuel, même s'il s'agit d'un service PaaS externe.

  • Carte VNIC Azure

    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.

  • Passerelle de réseau virtuel Azure

    La passerelle de réseau virtuel Azure établit une connectivité sécurisée entre les locaux entre un réseau virtuel Azure et un réseau sur place. Il vous permet de créer un réseau hybride qui couvre votre centre de données et Azure.

  • Réseau étendu virtuel Azure

    Microsoft Azure Virtual WAN (VWAN) est un service de réseau qui rassemble de nombreuses fonctionnalités de réseau, de sécurité et de routage pour fournir une interface opérationnelle unique.

  • Centre sécurisé Azure

    Un hub sécurisé Azure, également connu sous le nom de hub virtuel sécurisé, est un hub WAN virtuel Azure amélioré par des politiques de sécurité et de routage gérées par Azure Firewall Manager. Il simplifie la création d'architectures de réseau en étoile et transitives en intégrant des services de sécurité natifs pour la gouvernance et la protection du trafic. Cette configuration automatise le routage du trafic, éliminant ainsi le besoin de routes définies par l'utilisateur (UDR). Les organisations peuvent utiliser un concentrateur sécurisé pour filtrer et sécuriser le trafic entre les réseaux virtuels, les succursales et Internet, assurant une sécurité robuste et une gestion réseau rationalisée.

  • Gestionnaire de pare-feu Azure

    Azure Firewall Manager est un service centralisé de gestion de la sécurité qui simplifie le déploiement et la configuration d'Azure Firewall dans plusieurs régions et abonnements. Il permet une gestion hiérarchique des politiques, permettant une application cohérente des politiques de pare-feu globales et locales. Lorsqu'il est intégré à Azure Virtual WAN (vWAN) et à un concentrateur sécurisé, Azure Firewall Manager améliore la sécurité en automatisant le routage et le filtrage du trafic sans avoir besoin de routes définies par l'utilisateur (UDR). Cette intégration garantit que le trafic entre les réseaux virtuels, les succursales et Internet est géré et surveillé en toute sécurité, offrant une solution de sécurité réseau robuste et rationalisée.

  • Azure ExpressRoute

    Azure ExpressRoute est un service qui permet des connexions privées entre les centres de données sur place et Microsoft Azure, en contournant l'Internet public. Cela se traduit par une sécurité, une fiabilité et des vitesses supérieures avec des latences cohérentes. Les connexions ExpressRoute peuvent être établies par l'intermédiaire d'un fournisseur de connectivité à l'aide de diverses méthodes telles que l'Ethernet point à point, le RPV IP ou les interconnexions virtuelles. Lors de l'intégration avec des centres de données sur place, ExpressRoute permet l'extension transparente de votre réseau dans le nuage, facilitant les scénarios de nuage hybride, la reprise après sinistre et la migration de données avec une performance et une sécurité améliorées.

Oracle Cloud Infrastructure 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).

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

    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.

  • Liste de sécurité

    Pour chaque sous-réseau, vous pouvez créer des règles de sécurité qui spécifient la source, la destination et le type de trafic autorisé à entrer et à sortir du sous-réseau.

  • 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'Oracle Cloud Infrastructure, vous contrôlez le trafic réseau dans un réseau VCN. Un groupe de sécurité de réseau est composé d'un jeu de règles de sécurité pour les données entrantes et sortantes qui s'appliquent seulement à un jeu spécifié de cartes vNIC dans un seul réseau VCN.

  • 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

    vous permet de tirer parti de la puissance d'Exadata dans le nuage. 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.

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

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

  • Appairage distant

    L'appairage distant permet aux ressources de différents réseaux en nuage virtuels de communiquer à l'aide d'adresses IP privées. L'appairage distant élimine le besoin d'une passerelle Internet ou d'adresses IP publiques pour les instances qui doivent communiquer avec un autre VCN dans une autre région.

  • Réseau en nuage virtuel du centre

    Un réseau en nuage virtuel (VCN) hub sert de point central pour la gestion et le routage du trafic entre plusieurs réseaux en nuage virtuels, à la fois dans la même région et entre différentes régions. À l'aide de passerelles d'appairage local (LPG), le VCN hub se connecte à plusieurs réseaux en nuage virtuels spoke dans la même région, ce qui facilite une communication efficace et une gestion centralisée. Pour la connectivité inter-région, des groupes d'appairage distant (RPG) sont utilisés, où chaque VCN est attaché à une passerelle de routage dynamique (DRG) et établit des connexions d'appairage distant (RPC). Cette configuration est particulièrement utile pour le routage du trafic Oracle Data Guard. Elle garantit que les fichiers de journalisation et autres données de synchronisation sont transmis efficacement de la base principale d'une région à la base de secours d'une autre région, ce qui assure la cohérence des données et la haute disponibilité.

Le système sur place comprend les composants suivants :

  • Centre de données principal

    Un centre de données sur place hébergeant des applications et une base de données Oracle sert de site principal pour les activités commerciales, garantissant ainsi une haute performance et une disponibilité des données. Pour améliorer la reprise après sinistre et la continuité des activités, ce centre de données principal est associé à un centre de données de secours, souvent situé dans une région géographique différente. Le centre de données de secours gère une copie synchronisée de la base de données Oracle à l'aide d'Oracle Data Guard, qui réplique en continu les modifications de la base de données principale vers la base de secours. En cas de défaillance ou de sinistre sur le site principal, le centre de données de secours peut rapidement prendre le relais, réduisant ainsi les temps d'arrêt et les pertes de données, garantissant ainsi des opérations commerciales ininterrompues.

  • Centre de données de secours

    Un centre de données de secours est un élément essentiel d'une stratégie de reprise après sinistre, conçue pour assurer la continuité des activités dans des conditions imprévues. Il héberge une réplique des applications principales et d'Oracle Database, synchronisée au moyen de technologies telles qu'Oracle Data Guard. En cas de défaillance ou de sinistre au centre de données principal, le centre de données de secours peut reprendre les opérations de façon transparente, réduisant ainsi les temps d'arrêt et les pertes de données. Cette configuration garantit le bon fonctionnement des processus d'affaires, en assurant la résilience contre les perturbations et en maintenant la disponibilité des services pour les utilisateurs et les clients.

  • Base de données

    Une base de données Oracle hébergée dans un centre de données sur place joue un rôle crucial dans le stockage et la gestion des données d'affaires. Il fournit un environnement sécurisé à haut rendement pour le traitement des activités commerciales critiques, assurant ainsi l'intégrité et la disponibilité des données. Cette configuration permet aux organisations de garder un contrôle total sur leur infrastructure de données, de personnaliser les configurations pour répondre à des besoins spécifiques et de se conformer aux exigences réglementaires. En tirant parti des robustes fonctions de base de données d'Oracle, les entreprises peuvent traiter efficacement les transactions, générer des rapports et soutenir les processus de prise de décision.

  • Applications

    Les applications s'exécutant dans un centre de données sur place au-dessus d'une base de données Oracle sont essentielles aux opérations commerciales. Ces applications tirent parti de la robuste et fiable base de données Oracle pour traiter les transactions, gérer les données de client et générer des analyses d'affaires critiques. En opérant dans un environnement sécurisé et contrôlé, ils garantissent un rendement élevé, l'intégrité des données et la conformité aux normes réglementaires. Cette configuration permet aux entreprises de personnaliser leur infrastructure pour répondre à des besoins spécifiques, fournissant une base stable pour les opérations quotidiennes et la prise de décision stratégique.

Recommandations

Utilisez les recommandations suivantes comme point de départ. Vos exigences peuvent différer de l'architecture décrite ici.

Performance

Un réseau OCI est fortement recommandé pour la réplication de récupération après sinistre. L'infrastructure réseau haute performance d'OCI assure une connectivité à faible latence et à bande passante élevée, ce qui est essentiel pour une réplication et une synchronisation efficaces des données entre les bases de données principale et de secours. L'utilisation du réseau OCI pour Oracle Data Guard avec Oracle Database@Azure offre des avantages importants en matière de performance, de sécurité et de fiabilité.

Cette configuration renforce la reprise après sinistre en permettant une transmission rapide et sécurisée des fichiers de journalisation et des données critiques, réduisant ainsi les pertes de données et les temps d'arrêt lors des scénarios de basculement. En outre, les fonctions de sécurité intégrées d'OCI, notamment le chiffrement du réseau et les contrôles d'accès avancés, offrent une protection robuste pour les données sensibles.

En intégrant le réseau OCI à Oracle Database@Azure, les organisations peuvent réaliser une architecture de base de données transparente, résiliente et hautement disponible qui améliore la continuité des activités et l'efficacité opérationnelle.

Points à considérer

Tenez compte des points suivants lors du déploiement de cette architecture de référence.

  • Continuité des activités

    L'intégration d'Oracle Database Autonomous Recovery Service à Oracle Data Guard crée une stratégie de protection des données complète et résiliente pour les configurations de base de données principale et de base de secours. Oracle Data Guard assure la haute disponibilité et la récupération après sinistre en conservant une base de données de secours synchronisée qui peut prendre le relais en cas de défaillance d'une base de données principale, réduisant ainsi les temps d'arrêt et les pertes de données.

    En complément, Oracle Database Autonomous Recovery Service fournit une solution de sauvegarde entièrement gérée et centralisée, sans aucune perte de données et avec des capacités de récupération en temps réel. Cette combinaison assure une protection continue des données grâce à la réplication en temps réel et à des mécanismes de sauvegarde robustes, améliorant ainsi l'intégrité des données et la continuité des activités.

  • Disponibilité

    Le déploiement de plusieurs instances Oracle Database dans différentes zones de disponibilité au sein d'une région, ainsi que d'Active Data Guard, améliore considérablement les capacités de haute disponibilité et de reprise après sinistre. Les ZA sont isolées les unes des autres, ce qui garantit que les défaillances de l'une n'affectent pas les autres. En répartissant les instances de base de données entre plusieurs zones de disponibilité, les organisations peuvent atténuer les risques associés aux défaillances localisées telles que les pannes de courant ou les problèmes matériels.

    Active Data Guard renforce encore cette configuration en conservant une réplique synchronisée en temps réel de la base de données principale, ce qui permet un basculement transparent en cas de défaillance d'une instance principale. Cette approche assure une protection continue des données, des temps d'arrêt minimes et une stratégie robuste de reprise après sinistre, fournissant une infrastructure résiliente pour les applications critiques.

  • Volume traité

    Lors de la migration de bases de données sur place vers Azure, il est essentiel de tenir compte de la bande passante d'Azure ExpressRoute pour assurer un transfert fluide et efficace. Par exemple, si vous migrez une petite base de données de 100 Go, un circuit de 200 Mbps ExpressRoute peut gérer le transfert en environ 1 heure et 10 minutes, en supposant des conditions optimales et sans frais généraux. Toutefois, pour une base de données plus volumineuse de 1 To, le même circuit de 200 Mbps prendrait environ 11 heures et 40 minutes. La mise à niveau vers un circuit de 1 Gbit/s réduirait considérablement ce temps à environ 2 heures et 20 minutes. Planifiez en conséquence afin que la bande passante entière ne soit pas consommée; sinon, d'autres applications communiquant entre les applications sur place et en nuage pourraient être touchées.

Informations complémentaires

Pour en savoir plus sur Oracle Database et les outils connexes, consultez les ressources suivantes.

Examinez ces ressources de déploiement pour implémenter cette architecture de référence :

Vérifiez ces ressources supplémentaires :

Remerciements

  • Auteurs : Neeraj Tyagi, Thomas Van Buggenhout
  • Contributeurs : Emiel Ramakers, John Sulyok