Migrer des charges de travail Oracle vers Azure
Dans le cadre de l’adoption du cloud, vous devez migrer vos charges de travail existantes vers le cloud. Les charges de travail Oracle sont similaires aux autres charges de travail et nécessitent une approche méthodique pour garantir une migration réussie. Pour plus d’informations sur la méthodologie de migration, consultez Migration cloud dans le Cloud Adoption Framework. Cet article décrit les contraintes et les considérations spécifiques aux charges de travail Oracle.
Processus de migration vers Oracle
Vous devez continuellement réévaluer vos besoins en infrastructure afin d’améliorer les performances et de réduire les coûts en utilisant le type de service adapté à votre charge de travail. Par exemple, si vous planifiez de déplacer votre charge de travail vers Oracle Database@Azure, assurez-vous que la SKU que vous sélectionnez répond à vos exigences. De même, si vous déplacez votre charge de travail vers des Machines Virtuelles Oracle sur Azure, assurez-vous que la taille des ordinateurs virtuels répond à vos exigences. Pour obtenir plus d’informations, consultez Planification de capacité pour la migration de charges de travail Oracle dans des zones d’atterrissage Azure.
Consultez les ressources de migration pour définir votre processus de migration Oracle vers Azure. Vous pouvez également :
Vérifier les limites de quota de l’abonnement Azure : assurez-vous que les limites de quota de votre abonnement Azure correspondent à la taille cible d’ordinateur virtuel que vous choisissez si vous migrez vers les Machines Virtuelles Oracle sur Azure.
Définir un modèle de déploiement : automatisez autant que possible le déploiement des composants de solution en utilisant l’infrastructure en tant que code (IaaS), les pipelines d’intégration continue et livraison continue (CI/CD), et d’autres pratiques DevOps.
Déterminer les dépendances d’applications : veillez à ce que les activités de migration soient le moins perturbantes possible.
Définir la capacité de données : définissez la quantité de données à migrer et évaluez la capacité de connectivité réseau actuellement disponible entre les environnements sur site et Azure. Utilisez ces informations pour déterminer si vous pouvez copier les données directement à partir d’environnements locaux vers Azure. Vous pouvez avoir besoin d’une appliance de transfert de données physique comme Azure Data Box pour le chargement initial des données.
Déterminer les exigences en matière de disponibilité : déterminez les exigences en matière de disponibilité de la charge de travail, car elles peuvent avoir une incidence sur les outils de migration que vous pouvez utiliser.
Pour Oracle Database@Azure, pensez à :
vérifier que la solution Oracle Database@Azure est disponible dans la région où vous souhaitez la déployer. Pour plus d’informations, consultez Régions disponibles.
Envisagez d’utiliser Oracle Zero Downtime Migration pour le processus de migration. Évaluez les stratégies de migration pour déterminer l’approche la plus adaptée à vos exigences spécifiques de la migration. Pour plus d’informations, consultez Zero Downtime Migration.
Activités spécifiques à la charge de travail de migration Oracle
La section suivante décrit amplement le processus de migration. Les étapes ne sont pas nécessairement séquentielles. Vous pouvez effectuer certaines étapes en parallèle.
Évaluer les versions des systèmes source et de destination : vérifiez que les versions du système d’exploitation (OS), des applications et des bases de données sur site sont identiques à celles que vous planifiez utiliser sur Azure.
Si vous devez mettre à jour une ou plusieurs autres ressources, faites-le avant la migration afin d’éviter de compliquer le processus de migration.
Si votre base de données sur site fonctionne sur un OS en mode Big-Endian, tel qu’Oracle Solaris, IBM Advanced Interactive eXecutive ou Hewlett Packard Unix, le processus de migration de la base de données inclut une conversion en mode Endian. Azure ne prend en charge que les systèmes d’exploitation en mode Little-Endian. Cette limitation réduit le nombre d’outils disponibles pour la migration. En particulier, vous ne pouvez pas utiliser Oracle Data Guard ou toute autre méthode de copie de fichiers. Les méthodes de migration compatibles avec la conversion en mode Endian incluent Oracle Data Pump Export ou Import, les espaces de tables transportables inter-plateformes Oracle (XTTS), ou des utilitaires de réplication de données tels qu’Oracle GoldenGate, Quest SharePlex et Striim.
Vous pouvez moderniser ou migrer des serveurs d’applications sur site en fonction des exigences et de la compatibilité. Pour plus d’informations, consultez Scénarios d’adoption du cloud.
Évaluez les exigences de disponibilité des charges de travail pendant le processus de migration : Si vous devez minimiser le temps d’arrêt des charges de travail, des méthodes de migration telles que Data Pump Export ou Import peuvent ne pas convenir à votre charge de travail. Dans ce cas, vous pouvez suivre ce processus en quatre étapes :
Utilisez Oracle Recovery Manager (RMAN) pour sauvegarder, puis rétablir l’intégralité de la base de données dans Azure. Effectuez une conversion en mode Endian via XTTS si nécessaire. Le résultat est une base de données qui est une copie ponctuelle de la base de données source sur site. Pour plus d’informations, consultez Transport de données entre plateformes.
Utilisez Oracle Data Guard pour synchroniser la base de données nouvellement restaurée dans Azure avec la base de données source si les deux sources sont au format Little Endian. Vous ne pouvez pas utiliser Data Guard si la migration implique une conversion des données de big-endian vers little-endian. Utilisez à la place une réplication de données basée sur SQL telle que Oracle GoldenGate, Quest SharePlex ou Striim pour synchroniser la base de données nouvellement restaurée dans Azure avec la base de données source.
Après avoir synchronisé la base de données cible dans Azure avec la base de données source sur site, vous pouvez planifier un basculement. Le basculement arrête la base de données source sur site et évacue les dernières transactions vers la base de données cible dans Azure. Vous pouvez ensuite ouvrir la base de données cible dans Azure en tant que nouvelle base de données source. Le basculement peut prendre quelques minutes, en fonction de la méthode de synchronisation utilisée.
Selon l’approche de migration que vous avez choisie pour les services d’application, il se peut que vous deviez effectuer plusieurs tâches de service d’application avant de migrer complètement l’application vers Azure.
Évaluer les licences requises : votre base de données peut nécessiter différentes licences en fonction des outils de migration. Exemple :
Oracle Data Guard nécessite Oracle Database Enterprise Edition.
Oracle GoldenGate nécessite des licences Oracle GoldenGate.
Pour plus d’informations sur les licences Oracle sur Azure, consultez Gestion des licences pour le logiciel Oracle dans l’environnement de cloud computing.