La popularité du cloud public connaît une croissance exceptionnelle ; de plus en plus d’organisations déplacent leur infrastructure, leurs bases de données et leurs applications vers le cloud. La migration de bases de données Oracle vers Google Cloud est l’un des cas d’utilisation les plus importants que de nombreuses organisations adoptent et privilégient pour commencer leur transition.

La migration de bases de données Oracle vers Google Cloud est l’un des cas d’utilisation les plus importants que de nombreuses organisations adoptent et privilégient pour commencer leur transition

Cela s’explique par la flexibilité, l’évolutivité, la fiabilité et la sécurité qu’offre Google Cloud. Et à mesure que nous évoluons, nous nous attendons à voir davantage d’entreprises envisager de tirer parti de ces capacités.

La migration de bases de données est l’un des composants les plus critiques de toute migration de charges de travail et, en effet, cela peut s’avérer une tâche complexe pour plusieurs raisons :

• Beaucoup de technologies et de fonctionnalités propriétaires sont intégrées aux technologies de bases de données existantes, comme les procédures stockées, les fonctions personnalisées, Oracle RAC, etc.
• Les bases de données historiques sur site sont toutes des serveurs monolithiques et volumineux.
• Problèmes d’incompatibilité : Les applications internes et externes, qui dépendent toutes de la base de données, pourraient ne pas être compatibles avec différentes plateformes de bases de données.

Il existe 4 façons d’exécuter Oracle dans Google Cloud

• Bare metal avec Region Extensions :
  • Calcul et stockage certifiés Oracle au sein des extensions de région
  • Connectivité à faible latence vers GCP (<1ms)
  • Même coût de licence que sur site (pas de pénalité nuagique 2x)
  • Modèle BYOL, les serveurs bare metal occupés par un seul locataire assurent une faible barrière d’entrée depuis le sur site, tous les processus et scripts existants fonctionnent sans accroc
  • Gérez vous-même la base de données Oracle ou faites appel à un partenaire, Google gère l’infrastructure, SLA 99.9 %
• Google Cloud VMWare Engine :
  • Infrastructure VMWare entièrement managée par Google Cloud
  • Gestion, services de réseau, plateforme d’exploitation et infrastructure backend opérés à grande échelle par Google Cloud
  • Approvisionnez votre environnement VMware dans Google Cloud en quelques minutes
  • Gestion API du SDDC VMware
  • Rémédiation automatisée des composants défaillants
  • Libérez les clients du fardeau opérationnel lié à l’infrastructure
• El Carro – Oracle sur Anthos :
  • Exécutez Oracle en conteneur avec la puissance du Bare Metal
  • Modernisez l’écosystème Oracle en adoptant les pratiques DevOps du monde des conteneurs
  • Les conteneurs offrent une densité plus élevée par cœur (environ 2x) que les VM avec une performance bare metal, ce qui réduit les coûts de licence
  • Tâches du cycle de vie comme le provisionnement, la sauvegarde et la restauration, etc. automatisées par l’opérateur Kubernetes avec plein accès administratif
• Database Anywhere :
  • Exécutez votre base de données n’importe où, sur site ou dans un centre de données partenaire, et connectez-vous à GCP via un service d’interconnexion à haute vitesse d’Equinix
  • Offre aux applications et bases de données sur site sensibles à la latence un accès direct et sécurisé aux capacités étendues de Google Cloud
  • Tirer parti de BQ, y compris la diffusion de données en continu en temps réel et l’analytique prédictive avec apprentissage automatique intégré
  • Permettre aux clients SaaS d’archiver leurs bases de données Oracle sur Google Cloud via une interconnexion directe, sécurisée et privée

Il est important de prendre en considération les risques liés à la migration d’une base de données Oracle sur site vers le cloud. Selon l’infrastructure actuelle, le calendrier et les déclencheurs de la migration, ainsi que les ambitions du client, plusieurs cibles et stratégies peuvent être envisagées.

En général, il existe deux types de migrations de bases de données :

1. Migration homogène (Lift & Shift/ Re-hébergement, Replatforming)
2. Migration hétérogène

Tout commence par une évaluation ; il s’agit de l’étape la plus critique de l’engagement. Il est important de passer du temps, lors de l’évaluation, à analyser les bases de données sources afin de déterminer les candidats appropriés pour chaque type de migration et d’approche.

Migration homogène

Lift and shift, Re-hébergement : Vous conservez le même moteur de base de données, mais vous effectuez simplement le déplacement du sur site vers le cloud. Le lift and shift consiste à héberger la base de données sur le cloud sans modifier la plateforme sous-jacente (OS) ni l’application. Il existe plusieurs façons de procéder dans Google Cloud :

• Re-héberger la charge virtuelle VMware sur Google Cloud en utilisant GCVE (Google Compute VM-Ware Engine).
• Utiliser la solution Bare Metal pour des charges spécialisées    
• Re-héberger la base de données sur GCE (Google Compute Engine)    

Chacune de ces options a ses propres considérations. Par exemple, considérations de licence sur GCE :    

• Si l’éditeur de base de données actuel autorise la mobilité des licences     
• L’éditeur certifie-t-il une plateforme en particulier ? Cela peut avoir des implications de support.
• Dimensionnement adéquat,      dans le cas des charges non virtualisées sur Bare Metal
• Implications sur la performance

Cette approche est très courante et apporte de nombreux avantages, comme :

• Vous disposez déjà d’une équipe formée qui comprend la technologie et connaît la solution actuelle. Ainsi, migrer vers le cloud n’aura pas d’impact sur les ressources – car il n’y a pas autant de courbe d’apprentissage, ce qui permet également d’accélérer les délais de migration.
• Le moteur de la base de données reste le même – il y a peu ou pas de réécriture d’application, ce qui signifie un risque réduit et des délais de migration raccourcis.

Figure 2 : Benchmarking et dimensionnement optimal

Replatforming : Garder l’application inchangée tout en adoptant des plateformes compatibles avec le cloud ou permettant d’ajouter de la valeur pendant la migration vers le cloud. Par exemple, migrer des bases de données de AIX vers Linux.

D’autres exemples incluent la migration de bases sur site MS SQL Server / MySQL / PostgreSQL vers Cloud SQL

Cette approche implique aussi de prendre en compte :

• Délais du projet
• Compatibilité des fonctionnalités
• Temps d’arrêt
• Outils
• Coût

Migration hétérogène

L’autre type de migration est appelé migration hétérogène, lorsque vous souhaitez remplacer le moteur de la base de données existante. Les organisations l’utilisent couramment dans le cadre de projets de modernisation ou de transformation numérique.

Raisons de déclencher des migrations hétérogènes

• Coût de la licence et de son renouvellement
• Avec la croissance des entreprises, elles ont tendance à développer de plus en plus de nouvelles applications. Ainsi, pour bénéficier des avantages du cloud comme la réduction des coûts, la diminution du TCO (coût total de possession)
• Réduire la dépendance envers un fournisseur et ses technologies propriétaires.
• Adoption de technologies open source

Bien que de façon générale, il semble attrayant de migrer d’une base de données d’entreprise comme Oracle vers une base de données open source comme PostgreSQL, on peut immédiatement envisager des impacts positifs comme l’absence de coût de renouvellement périodique ou la liberté de choisir une base de données open source. Cependant, les facteurs suivants doivent être évalués pour orienter le choix.

• Aucune application sur mesure n’aura exactement le même schéma. Contrairement au lift and shift ou au replatforming, les problèmes de conversion hétérogène sont plus profonds. Les objets et le code de la base de données ne peuvent pas être migrés tels quels. Une analyse approfondie du schéma s’impose avant de s’engager.
• Vérifier s’il existe du code intégré ou un ORM (Object Relational Mapper)
• La connaissance de la logique d’affaires est essentielle en cas de refonte d’application ou de réécriture de code de base de données.
• Discordance de fonctionnalités entre la base source et la base cible. Par exemple, les packages natifs de la source peuvent ne pas avoir d’équivalent sur la cible. Cela nécessite des solutions de contournement spécifiques pouvant être chronophages.
• Disponibilité de la fenêtre d’arrêt ; cela n’est pas un facteur lors de la conversion de code, mais devient critique lors du basculement. Le choix des outils est donc essentiel.
• La complexité du code et la taille de la base déterminent l’effort requis.
• Si l’application a été développée sur une longue période, il est possible que le développeur d’origine ne soit plus présent et qu’il subsiste du code hérité à réécrire.
• Les tests fonctionnels relèvent principalement de l’équipe applicative, mais nécessiteront la mobilisation des ressources de base de données. On peut estimer que le temps total consacré aux tests fonctionnels et de performance représente environ 50 %. Ces chiffres sont indicatifs et peuvent varier grandement selon la complexité du schéma et des applications ou les besoins.

L’idée de migrer l’ensemble du paysage de bases de données de “A” vers “B” constitue une décision d’affaires très critique. Une évaluation réaliste permettra des tentatives fructueuses plutôt qu’un échec causé par un excès d’ambition. L’évaluation pour la migration hétérogène sert de fondement à une migration réussie

• Plateforme IaaS (open source ou version d’entreprise supportée) ou PaaS (Cloud SQL PostgreSQL)
• Effort requis pour la conversion de la couche applicative et de la couche base de données
• Outils à utiliser
• Faisabilité

Le choix de la plateforme est déterminant pour le succès de la migration, car différentes plateformes offrent différentes capacités. Ce choix aura aussi un impact sur l’effort requis en cas de souci de compatibilité de code. Le choix des outils dépend de la plateforme sélectionnée et de la fenêtre d’indisponibilité disponible (notamment pour un environnement de production)

Le choix de l’outil de migration est un autre facteur important. Plusieurs outils sont disponibles, tant open source que sous licence. Chacun présente ses propres avantages, défis et coûts. Savoir quand utiliser tel ou tel outil dépend de l’expérience de l’équipe. Par exemple, il existe des situations où vous pourriez préférer un outil open source comme Ora2PG pour la conversion, ou au contraire, un outil sous licence comme Ispirer, selon le contexte.

La taille des données et le taux de changement sont également des facteurs à considérer pour les applications et bases critiques qui ne peuvent tolérer aucun arrêt lors du basculement, ou qui nécessitent une exécution en parallèle. Dans ce cas, un outil de synchronisation basé sur CDC (Capture de Données de Changement) doit être envisagé pour faciliter la quasi-absence d’arrêt, la synchronisation continue et une possibilité de retour arrière. Des options cloud natives et des outils tiers sont disponibles.

L’image ci-dessous présente une vue d’ensemble des étapes d’une migration hétérogène, par exemple d’Oracle vers Cloud SQL

Figure 3 : Étapes de migration d’Oracle vers Cloud SQL

Complexité de la migration :

La complexité d’une migration résulte de plusieurs facteurs. Les plus significatifs sont illustrés ci-dessous.

Figure 4 : Matrice de complexité

Conclusion

La migration de base de données est un processus complexe et les organisations doivent définir leur feuille de route cloud avec une planification infaillible basée sur une évaluation approfondie. À la fois les migrations homogènes et hétérogènes ont leurs avantages et défis qui doivent être pris en compte pendant la phase de découverte et d’évaluation. L’effort de migration doit être justifié par les gains escomptés. Une migration « big bang » sans tenir compte des défis peut aboutir à un résultat indésirable. Les bases de données sources doivent être choisies sur la base d’une estimation réelle de l’effort requis plutôt que sur des suppositions. Avec une planification rigoureuse, de bonnes stratégies, des outils adaptés et les bonnes ressources, une migration réussie peut être réalisée et les organisations peuvent récolter les véritables avantages de Google Cloud.