Migration d'applications stratégiques vers Oracle Database@Azure à l'aide d'une stratégie progressive

Migrez une base de données et une application sur site vers le cloud, en minimisant les temps d'arrêt grâce à des stratégies échelonnées ou hybrides, ce qui garantit une connectivité transparente pour les applications cloud vers les bases de données sur site. 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 site vers le cloud, vous devez relever plusieurs défis pour assurer une transition transparente. Choisissez une stratégie de migration qui minimise les temps d'arrêt, tels que la migration progressive ou les solutions cloud hybrides, pour maintenir le temps de fonctionnement des applications, en particulier pour les charges de travail critiques. Assurez-vous que les applications déjà dans le cloud, qui se connectent aux bases de données sur site, 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 cloud, mais où la base de données est sur site, assurez-vous d'avoir une stratégie complète qui inclut les deux composants. Relevez ces défis de manière proactive pour assurer une transition en douceur et maintenir la fiabilité de vos applications métier critiques. Une stratégie bien structurée vous aide également à accélérer la sortie du datacenter et à réduire les risques de migration, garantissant ainsi la fiabilité de vos applications métier critiques.

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

L'implémentation de cette configuration nécessite souvent une solution soigneusement conçue pour établir l'architecture cible sans perturber les opérations métier critiques. De nombreuses charges de travail critiques sont déployées dans plusieurs régions pour assurer la continuité des activités via des environnements de récupération 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.

Avant de commencer

Avant de commencer, prenez en compte les points suivants :

  • Désactivez Fast-Start Failover dans Oracle Data Guard pour garantir une transition fluide et contrôlée entre les régions principale et de secours lors de la migration.
  • OCI Database Migration fournit des migrations Oracle Database et MySQL validées, interversions, tolérantes aux pannes et incrémentielles pour les cas d'utilisation en ligne et hors ligne, tels que ZDM et OCI Migration.
  • Cette architecture de référence suit le modèle Oracle Gold Maximum Availability Architecture (MAA) dans une configuration actif-de secours avec déploiement inter-région 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 assurée par la 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 implémentée avec la réplication asynchrone.

Architecture

Cette architecture décrit une approche progressive de la migration d'Oracle Database sur site vers Oracle Exadata Database Service sur Oracle Database@Azure avec un temps d'inactivité 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 de chiffres bleus dans le diagramme).
Chiffre Composant Description
1 Centre de données principal sur site 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 site Tient à jour un système de secours en répliquant la base de données principale sur site.
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'image logical-architecture-diagram.png
Description de l'illustration logical-architecture-diagram.png

logique-architecture-diagramme-oracle.zip

Etat en cours

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 site, prenant en charge les charges de travail et les bases de données des applications. Le centre de données principal gère 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.

Etat futur

L'architecture future reflète la configuration actuelle mais est entièrement hébergée dans le cloud, 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 réplication asynchrone entre les bases de données principale et de secours gérées via Oracle Data Guard sur le réseau Oracle Cloud Infrastructure (OCI).

Pour une connectivité sécurisée entre le centre de données sur site et Azure, un pare-feu Azure est déployé dans un hub WAN virtuel (vWAN) sécurisé 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 site vers Azure et permutation

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

  1. Etablissez la connectivité entre Azure et sur site à l'aide d'Azure ExpressRoute.
  2. Configurez le hub sécurisé Azure, le pare-feu Azure et le réseau virtuel virtuel pour la sécurité (s'il n'est pas déjà en place).
  3. Provisionnez Oracle Exadata Cloud Infrastructure dans la région principale d'Azure, puis effectuez les opérations suivantes :
    1. Configurez un cluster de machines virtuelles Oracle Exadata et créez la base de données cible.
    2. Activez les fichiers de journalisation archivés 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 le processus d'écoute et les noms TNS pour le repérage.
  5. Effectuez une restauration à partir du service pour configurer une base de données de secours dans la région principale d'Azure (3).
  6. Effectuez une permutation, en faisant de la base de données Azure (3) la nouvelle base de données principale.
  7. Migrez les applications vers la région principale Azure (3) et mettez à jour les routages DNS.
  8. Vérifiez la configuration Data Guard et surveillez le statut de réplication.

Phase 2 – Etablissement d'une base de données de secours dans Azure et mise hors service sur site

Dans cette phase, un système de secours (4) est configuré dans Azure et les ressources sur site (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 un cluster 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 les fonctions de réseau OCI pour la réplication haut débit, en tirant parti de l'appairage local et distant dans une topologie hub-and-spoke entre les bases de données principale et de secours.
  5. Migrez les charges globales d'application vers la région de secours Azure (4).
  6. Arrêtez la synchronisation avec les ressources sur site, puis désactivez les ressources d'application et de base de données sur site des centres de données principal (1) et de secours (2).

Le schéma 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 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.

  • Zone de disponibilité Azure

    Les zones de disponibilité Azure sont des emplacements physiquement distincts au sein d'une région Azure, conçus pour assurer la haute disponibilité et la résilience en fournissant une alimentation, un refroidissement et une mise en réseau indépendants.

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

  • Passerelle de réseau virtuel Azure

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

  • WAN virtuel Azure

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

  • Hub 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é avec des stratégies de sécurité et de routage gérées par Azure Firewall Manager. Il simplifie la création d'architectures de réseau hub-and-spoke 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 entreprises peuvent utiliser un hub sécurisé pour filtrer et sécuriser le trafic entre les réseaux virtuels, les succursales et Internet, garantissant ainsi une sécurité robuste et une gestion réseau rationalisée.

  • Gestionnaire de pare-feu Azure

    Azure Firewall Manager est un service de gestion de sécurité centralisé qui simplifie le déploiement et la configuration d'Azure Firewall dans plusieurs régions et abonnements. Il permet une gestion hiérarchique des stratégies, permettant d'appliquer de manière cohérente les stratégies de pare-feu globales et locales. Lorsqu'il est intégré à Azure Virtual WAN (vWAN) et à un hub sécurisé, Azure Firewall Manager améliore la sécurité en automatisant le routage et le filtrage du trafic sans avoir besoin de routages définis 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é, fournissant 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 site et Microsoft Azure, en contournant l'Internet public. Cela améliore la sécurité, la fiabilité et accélère les vitesses avec des latences cohérentes. Les connexions ExpressRoute peuvent être établies via un fournisseur de connectivité à l'aide de diverses méthodes telles que l'Ethernet point à point, n'importe quel (VPN IP) ou les interconnexions virtuelles. Lors de l'intégration à des centres de données sur site, ExpressRoute permet une extension transparente de votre réseau dans le cloud, facilitant ainsi les scénarios de cloud hybride, la récupération après sinistre et la migration des données avec des performances 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 localisée contenant des centres de données hébergeant des 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).

  • 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 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 autorisés à entrer et sortir du sous-réseau.

  • Groupe de sécurité réseau

    Les groupes de sécurité réseau agissent comme des pare-feu virtuels pour les ressources cloud. Avec le modèle de sécurité de confiance zéro d'Oracle Cloud Infrastructure, 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 uniquement à un ensemble spécifié de cartes d'interface réseau virtuelles dans un seul VCN.

  • Oracle Database Autonomous Recovery Service

    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 fonctionnalité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 et de stockage des sauvegardes vers Oracle Database Autonomous Recovery Service, ce qui réduit les coûts d'infrastructure de sauvegarde et les frais d'administration manuels.

  • Exadata Database Service

    vous permet d'exploiter toute 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.

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

  • Appairage local

    L'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.

  • Appairage à distance

    L'appairage à distance permet aux ressources de différents réseaux cloud virtuels de communiquer à l'aide d'adresses IP privées. L'appairage à distance é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 cloud virtuel de hub

    Un réseau cloud virtuel (VCN) hub sert de point central pour la gestion et le routage du trafic entre plusieurs réseaux cloud virtuels, à la fois au sein de la même région et entre différentes régions. En utilisant des passerelles d'appairage local (LPG), le VCN hub se connecte à plusieurs réseaux cloud virtuels spoke au sein de 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 à distance (RPG) sont utilisés, où chaque VCN s'attache à une passerelle de routage dynamique (DRG) et établit des connexions d'appairage à distance (RPC). Cette configuration est particulièrement utile pour acheminer le trafic Oracle Data Guard, en veillant à ce que les fichiers de journalisation et autres données de synchronisation soient transmis efficacement de la base principale d'une région à la base de données de secours d'une autre région, préservant ainsi la cohérence des données et la haute disponibilité.

Le système sur site comporte les composants suivants :

  • Centre de données principal

    Un centre de données sur site hébergeant des applications et une base de données Oracle sert de site principal pour les opérations commerciales, garantissant des performances élevées et une disponibilité des données élevée. Pour améliorer la récupération 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 permanence les modifications de la base de données principale vers la base de données de secours. En cas de panne 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 via des technologies telles qu'Oracle Data Guard. En cas de panne ou de sinistre au niveau du centre de données principal, le centre de données de secours peut reprendre les opérations en toute transparence, réduisant ainsi les temps d'arrêt et la perte de données. Cette configuration garantit le bon fonctionnement des processus métier, assurant ainsi la résilience face aux perturbations et le maintien de la disponibilité du service 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 site joue un rôle crucial dans le stockage et la gestion des données d'entreprise. Il fournit un environnement sécurisé et hautes performances pour la gestion des opérations commerciales critiques, garantissant l'intégrité et la disponibilité des données. Cette configuration permet aux entreprises de conserver 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 exploitant les fonctionnalités de base de données fiables d'Oracle, les entreprises peuvent traiter efficacement les transactions, générer des rapports et prendre des décisions en charge.

  • Applications

    Les applications exécutées dans un centre de données on-premise sur une base de données Oracle font partie intégrante des opérations commerciales. Ces applications exploitent la base de données fiable et robuste d'Oracle pour traiter les transactions, gérer les données client et générer des informations commerciales essentielles. En opérant dans un environnement sécurisé et contrôlé, ils garantissent des performances élevées, 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, en 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.

Performances

Un réseau OCI est fortement recommandé pour la réplication de récupération après sinistre. L'infrastructure réseau hautes performances d'OCI garantit une connectivité à faible latence et à bande passante élevée, essentielle à la réplication et à la 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 significatifs en matière de performances, de sécurité et de fiabilité.

Cette configuration renforce la récupération après sinistre en permettant une transmission rapide et sécurisée des fichiers de journalisation et des données critiques, ce qui réduit les pertes de données et les temps d'inactivité lors des scénarios de basculement. En outre, les fonctionnalités de sécurité intégrées d'OCI, y compris le chiffrement du réseau et les contrôles d'accès avancés, fournissent une protection robuste pour les données sensibles.

En intégrant le réseau OCI à Oracle Database@Azure, les entreprises peuvent obtenir 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 à prendre en compte

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 secours. Oracle Data Guard garantit 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 de la base de données principale, réduisant ainsi les temps d'arrêt et la perte de données.

    En plus de cela, Oracle Database Autonomous Recovery Service fournit une solution de sauvegarde centralisée entièrement gérée avec des fonctionnalités de protection contre les pertes de données et de récupération en temps réel. Cette combinaison garantit 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 fonctionnalités de haute disponibilité et de récupération après sinistre. Les ZA sont isolées les unes des autres, ce qui garantit que les défaillances dans l'une n'ont pas d'impact sur les autres. En répartissant les instances de base de données entre plusieurs zones, les entreprises peuvent atténuer les risques associés à des pannes localisées telles que des pannes de courant ou des 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 panne d'une instance principale. Cette approche garantit une protection continue des données, un temps d'arrêt minimal et une stratégie de reprise après sinistre robuste, fournissant une infrastructure résiliente pour les applications stratégiques.

  • Débit

    Lors de la migration de bases de données sur site vers Azure, il est essentiel de prendre en compte 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 ExpressRoute de 200 Mbps peut gérer le transfert en environ 1 heure et 10 minutes, en supposant des conditions optimales et aucune surcharge. 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 de sorte que la bande passante entière ne soit pas consommée. Sinon, d'autres applications communiquant entre les applications sur site et le cloud peuvent être affectées.

En savoir plus

Pour en savoir plus sur Oracle Database et les outils associés, reportez-vous aux ressources suivantes.

Consultez les ressources de déploiement suivantes pour implémenter cette architecture de référence :

Consultez les ressources supplémentaires suivantes :

Accusés de réception

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