Migrer vers Oracle Database@Azure avec Oracle Zero Downtime Migration

Passez à Oracle Database@Azure avec Oracle Zero Downtime Migration

Oracle Database@Azure vous permet d'exécuter vos bases de données Oracle stratégiques sur Oracle Exadata Database Service on Dedicated Infrastructure dans le centre de données Microsoft Azure.

Profitez de la haute disponibilité, des performances et de l'évolutivité intégrées fournies par Oracle Exadata Database Service et Oracle Real Application Clusters (Oracle RAC) tout en bénéficiant d'une faible latence pour vos applications Azure.

La migration de la base de données vers le cloud est généralement un processus manuel associé à des temps d'arrêt pour votre entreprise. Oracle Zero Downtime Migration simplifie et automatise les migrations de bases de données Oracle avec un temps d'arrêt nul ou minimal, intègre les meilleures pratiques d'Oracle Maximum Availability Architecture (Oracle MAA) par défaut, prend en charge les migrations de parc et est gratuit, entre autres avantages.

Depuis sa publication en 2019, Oracle Zero Downtime Migration est l'outil de migration fiable pour les clients du monde entier pour les migrations de bases de données Oracle vers des machines Oracle Exadata sur site, Oracle Exadata Database Service on Cloud@Customer et Oracle Cloud Infrastructure (OCI). Pour en savoir plus sur Oracle Zero Downtime Migration, reportez-vous à En savoir plus.

Architecture

Cette architecture de référence décrit les migrations Oracle Database d'un environnement sur site vers Oracle Exadata Database Service on Dedicated Infrastructure sur Oracle Database@Azure à l'aide du workflow de migration en ligne physique basé sur Oracle Data Guard et du transfert de données direct, offrant simplicité, automatisation et continuité des activités lors des migrations de base de données vers Oracle Database@Azure.

L'hôte du service Oracle Zero Downtime Migration est installé sur une machine virtuelle sur site distincte en regard de la base de données source. La cible Oracle Exadata Database Service on Dedicated Infrastructure est provisionnée dans le centre de données d'Azure au sein du réseau virtuel Azure (VNet) d'un sous-réseau délégué vers Oracle Database@Azure. Le centre de données sur site est connecté au centre de données d'Azure via Azure ExpressRoute ou un VPN site à site. Le workflow en ligne physique Oracle Zero Downtime Migration basé sur le transfert direct de données crée la base de données cible à l'aide de la restauration à partir d'une méthode de service et évite de sauvegarder la base de données source vers un emplacement de stockage intermédiaire. Oracle Zero Downtime Migration utilise automatiquement Oracle Data Guard pour répliquer les données de la base de données sur site vers la base de données cible. Oracle Zero Downtime Migration configure automatiquement Oracle Data Guard, le gère et nettoie la configuration une fois la migration terminée. Par conséquent, aucune connaissance de la configuration et de la maintenance d'Oracle Data Guard n'est requise. Une fois la migration terminée, la base de données cible peut utiliser la fonctionnalité de sauvegarde automatique pour sauvegarder la base de données dans Oracle Database Autonomous Recovery Service.

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

Description de l'illustration oracle-db-azure-zdm.png

oracle-db-azure-zdm-oracle.zip

Microsoft Azure fournit les composants suivants :

Carte d'interface réseau virtuelle Azure
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 automatiquement créée et attachée lors du lancement et est disponible pendant toute la durée de vie de l'instance.
Passerelle de réseau virtuel Azure
La passerelle de réseau virtuel Azure est un service qui é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.
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, directement dans votre réseau virtuel. Cela signifie que vous pouvez désigner ou déléguer un sous-réseau comme répertoire de base d'un service géré externe dans votre réseau virtuel. En d'autres termes, ce service externe agira comme une ressource de réseau virtuel, même s'il s'agit techniquement d'un service de plate-forme en tant que service externe.
Réseau virtuel Azure
Le réseau virtuel Azure (VNet) est le bloc de construction fondamental de votre réseau privé dans Azure. VNet permet à de nombreuses ressources Azure, telles que les machines virtuelles Azure, de communiquer en toute sécurité entre elles, avec Internet et avec les réseaux sur site.

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, appelés domaines de disponibilité. Les régions sont indépendantes les unes des autres et de grandes distances peuvent les séparer (dans des pays voire des continents).
Réseau cloud virtuel (VCN) et sous-réseaux
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 de 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é.
Réseau sur site
Ce réseau est le réseau local utilisé par votre organisation. C'est l'un des rayons de la topologie.
Passerelle de service
La passerelle de service fournit un accès à partir d'un VCN à d'autres services, tels qu'Oracle Cloud Infrastructure Object Storage. Le trafic du VCN vers le service Oracle transite par la structure réseau Oracle et ne traverse pas Internet.
Data Guard
Oracle Data Guard et Oracle Active Data Guard fournissent un ensemble complet de services permettant de créer, de tenir à jour, de gérer et de surveiller des bases de données de secours, et permettant 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.
Service de base de données Exadata
Oracle Exadata Database Service vous permet de tirer parti de la puissance d'Exadata dans le cloud. Vous pouvez provisionner des systèmes Exadata X9M flexibles qui vous permettent d'ajouter des serveurs de calcul de base de données et de stockage à votre système en fonction de l'évolution de vos besoins. Les systèmes Exadata X9M offrent une mise en réseau RDMA sur Ethernet convergé (RoCE) pour une bande passante élevée et une faible latence, des modules de mémoire persistante (PMEM) et le logiciel Exadata intelligent. Vous pouvez provisionner des systèmes Exadata X9M à l'aide d'une forme équivalente à un système X9M en quart de rack, puis ajouter des serveurs de base de données et de stockage à tout moment après le provisionnement.

Oracle Exadata Database Service on Dedicated Infrastructure fournit Oracle Exadata Database Machine en tant que service dans un centre de données Oracle Cloud Infrastructure (OCI). L'instance Oracle Exadata Database Service on Dedicated Infrastructure est un cluster de machines virtuelles qui réside dans les racks Exadata d'une région OCI.

Oracle Exadata Database Service on Cloud@Customer fournit Oracle Exadata Database Service qui est hébergé dans votre centre de données.
Hôte du service Zero Downtime Migration
L'hôte du service Oracle Zero Downtime Migration doit être un système dédié, mais il peut être partagé à d'autres fins.

Le logiciel Oracle Zero Downtime Migration requiert un hôte Oracle Linux autonome exécuté sur l'une des plates-formes suivantes : Oracle Linux 7, Oracle Linux 8 ou Red Hat Enterprise Linux 8.

L'hôte de service Oracle Zero Downtime Migration doit pouvoir se connecter aux serveurs de base de données source et cible. Tant que la connectivité est garantie, l'hôte de service peut être localisé n'importe où.
Oracle Database Autonomous Recovery Service
Oracle Database Autonomous Recovery Service est un service Oracle Cloud qui protège les bases de données Oracle. Grâce à l'automatisation des sauvegardes et aux fonctionnalités améliorées de protection des données pour les bases de données OCI, vous pouvez décharger toutes les exigences de traitement et de stockage des sauvegardes sur Oracle Database Autonomous Recovery Service, éliminant ainsi les coûts d'infrastructure de sauvegarde et les temps système d'administration manuelle.

Workflows de migration Oracle Zero Downtime Migration

Remarques :

Pour chaque ligne de travail de migration répertoriée, reportez-vous à Explorer davantage pour plus de détails.

Vous pouvez effectuer les workflows suivants pour migrer votre instance Oracle Database vers Oracle Exadata Database Service on Dedicated Infrastructure sur Oracle Database@Azure.

Migration physique en ligne
Le workflow de migration physique en ligne prend en charge les migrations entre les mêmes versions de base de données et plates-formes. Il utilise le transfert direct de données et la méthode "restore from service" pour créer la base de données cible, évitant explicitement de sauvegarder la base de données source dans un emplacement de stockage intermédiaire. Oracle Data Guard assure la synchronisation des bases de données source et cible pour une migration avec un temps d'inactivité minimal.
Migration physique hors ligne
Le workflow de migration physique hors ligne prend en charge les migrations entre les mêmes versions de base de données et plates-formes. Il crée la base de données cible à l'aide de la sauvegarde et de la restauration RMAN (Recovery Manager). Le service Azure Files fournit un partage de fichiers NFS pour stocker les fichiers de sauvegarde RMAN.
Migration logique en ligne
Le workflow logique de migration en ligne prend en charge les migrations entre la même version de base de données et des plates-formes différentes. Il utilise l'export et l'import Oracle Data Pump pour créer la base de données cible. Le service Azure Files fournit un partage de fichiers NFS pour stocker les fichiers dump Data Pump. OCI GoldenGate maintient la synchronisation des bases de données source et cible afin d'atteindre un temps d'inactivité minimal.
Migration logique hors ligne
Le workflow de migration logique hors ligne prend en charge les migrations entre la même version de base de données et les différentes plates-formes. Il utilise l'export et l'import Oracle Data Pump pour créer la base de données cible. Le service Azure Files fournit un partage de fichiers NFS pour stocker les fichiers dump Data Pump.

Vous pouvez effectuer les workflows de migration Oracle Zero Downtime Migration suivants pour migrer Oracle Database vers Oracle Autonomous Database Serverless sur Oracle Database@Azure.

Migration logique en ligne
Le workflow logique de migration en ligne prend en charge les migrations entre la même version de base de données et des plates-formes différentes. Il utilise l'export et l'import Oracle Data Pump pour créer la base de données cible. Le service Azure Files fournit un partage de fichiers NFS pour stocker les fichiers dump Data Pump. OCI GoldenGate maintient la synchronisation des bases de données source et cible afin d'atteindre un temps d'inactivité minimal.
Migration logique hors ligne
Le workflow de migration logique hors ligne prend en charge les migrations entre la même version de base de données et les différentes plates-formes. Il utilise l'export et l'import Oracle Data Pump pour créer la base de données cible. Le service Azure Files fournit un partage de fichiers NFS pour stocker les fichiers dump Data Pump.

Recommandations

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

Téléchargez la dernière version du logiciel Oracle Zero Downtime Migration à partir de My Oracle Support (MOS) en recherchant le patch numéro 33509650 dans l'onglet Patches & Updates.
Installez l'hôte du service Oracle Zero Downtime Migration sur site en regard de votre base de données source.
Assurez-vous que l'hôte du service Oracle Zero Downtime Migration dispose d'au moins 100 Go de stockage gratuit.
Assurez une connectivité réseau sécurisée et privée entre l'environnement sur site et Azure via un VPN site à site ou Azure ExpressRoute.
En fonction de la taille de votre base de données, assurez-vous que le débit réseau de votre réseau sur site vers Azure est suffisant.

Points à prendre en compte

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

La base de données cible doit :
- Être provisionné à l'aide des outils Oracle Cloud sans activer les sauvegardes automatiques.
- Avoir une version de fichier de fuseau horaire identique ou supérieure à celle de la base de données source.
Les bases de données source et cible doivent :
- Ayez le même nom de base de données (DB_NAME).
- Ont des noms uniques de base de données différents (DB_UNIQUE_NAME).
- Utilisez un fichier de paramètres serveur (SPFILE).
- Utilisez le même jeu de caractères.
- Avoir le même algorithme de cryptage défini dans le fichier sqlnet.ora.
- Avoir la même version majeure (par exemple, 19c). Toutefois, la base de données cible peut avoir un niveau de patch plus élevé (par exemple, source à la version 19.21 et cible à la version 19.22). Si le niveau de patch de la base de données cible est supérieur à celui de la base de données source, Oracle Zero Downtime Migration exécute automatiquement datapatch dans le cadre de la migration.
Le mot de passe du compte utilisateur SYS doit être identique sur les bases de données source et cible.
Le paramètre d'initialisation de la base de données COMPATIBLE doit être identique sur les bases de données source et cible.
Pour Oracle Database 12c version 2 et versions ultérieures, le portefeuille TDE doit exister sur la source et le statut du portefeuille doit être OPEN. La base de données source n'a pas nécessairement besoin d'être cryptée, mais un portefeuille TDE doit être configuré.
Oracle Zero Downtime Migration exige que la clé SSH sur l'hôte de service Oracle Zero Downtime Migration soit au format RSA (dans Oracle Linux 8, la valeur par défaut est OPENSSH).

En savoir plus

En savoir plus sur les services de cette architecture.

Consultez les ressources supplémentaires suivantes :

Remerciements

Auteurs : Sinan Petrus Toma, Ricardo Gonzalez, Thomas Van Buggenhout
Contributeurs : Emiel Ramakers, Wei Han, John Sulyok