Google Cloud veut accélérer les migrations vers Cloud SQL

Une migration en cinq étapes vers cloud SQL

Accessible depuis la console Google Cloud, le service DMS réclame de créer un job spécifique à la migration. Le client nomme cette opération, choisit le type de migration qu’il veut opérer, puis le type du job, c’est-à-dire s’il s’agit d’une migration unique, lift and shift, ou d’une réplication continue.

Ensuite, l’utilisateur peut consulter les prérequis de configuration de la base de données source et du réseau. Puis, il doit définir la configuration réseau de sa source (aussi appelé profil de connexion), en fournissant le nom d’hébergement de la source ou son IP, le port associé, le nom d’utilisateur et les paramètres de configuration SSL/TLS s’ils sont appliqués. Ces profils sont réutilisables. Il convient de créer une instance cloud SQL en indiquant ses identifiants, la version de la base de données à migrer (DMS supporte MySQL 5,5, 5.6, 5.7 et 8.0), la région, la zone cloud et les ressources souhaitées (types de machines, stockage SSD ou HDD, capacité de stockage, autoscaling). L’avant-dernière étape consiste à choisir la méthode de connexion (liste d’IP autorisé, tunnel Reverse SSH pour des VM cloud, VPN ou un appairage VPC).

Enfin, il faut lancer un test pour valider la configuration, puis lancer le job de migration. Un outil de supervision permet d’observer le déroulement de l’opération. Dans la documentation, on apprend que l’appairage VPC n’est possible que si la source et la destination sont hébergées sur GCP. Avec une migration lift and shift, il s’agit de migrer un snapshot pris à un instant T vers la nouvelle instance, ce qui requiert d’arrêter d’écrire sur l’ancienne base pour éviter des efforts de synchronisation post-opération. Dans tous les cas avec DMS, toutes les données, tables et schéma sont migrés (via InnoDB). Les rôles s’appliquant à l’ancienne instance sont à redéfinir dans Cloud SQL.

Pour l’instant, DMS est disponible pour les migrations MySQL. Un nombre « limité » de clients peuvent utiliser l’équivalent pour PostgreSQL. (En explorant la documentation du cloudiste, nous apprenons qu’il supporte désormais la version 13.0 de PostgreSQL depuis le 5 novembre).

Convaincre les clients à passer le cap…

À première vue, on peut considérer comme tardive l’arrivée de cet outil de migration alors que d’autres comme AWS et Microsoft Azure disposent déjà depuis plusieurs années de solutions équivalentes. Plusieurs éléments peuvent expliquer cette décision. Tout comme leurs clients, les cadres de Google Cloud Platform s’appuient sur les prédictions de Gartner. Et le cabinet d’analystes a vu dans sa boule de cristal que 75 % des bases de données seront exécutées dans le cloud d’ici à 2023.

Google Cloud a parfaitement conscience de la difficulté de migrer une base de données sur site vers une version cloud. Jusqu’alors le géant proposait des tutoriels et des offres de conseils pour aider ses clients à rejoindre les services équivalents. Cela réclame habituellement une stratégie qui consiste à préparer, sauvegarder, archiver, synchroniser, importer les données et les schémas, entre autres.

Suivant le SGBDR d’origine, GCP propose une ou deux méthodes de migration réclamant d’utiliser plusieurs services cloud, ce qui entraîne des coûts non négligeables. DMS est utilisable gratuitement, des frais additionnels sont imputables à la création d’instances cloud SQL et de l’utilisation des services de réseau (Google Cloud VPC pour l’utilisation de Bastion, VM Compute Engine pour Reverse SSH) sans oublier les tarifs d’extractions des données possiblement appliqués par les fournisseurs de cloud tiers.

Comme nous l’avons précisé, une telle migration provoque des temps d’arrêt de la database généralement utilisée en production. Conséquence, certaines entreprises préfèrent conserver leurs installations sur site et de faire du débord, de déployer des SGBD dans le cloud pour des applications non critiques. DMS ne règle pas forcément le problème, même s’il simplifie cette étape.

Évidemment, cette situation n’arrange pas les fournisseurs cloud qui préféreraient voir des applications critiques rejoindre leurs infrastructures. Outre un aspect valorisant, un Google ou un AWS ne manquera pas de se réjouir de voir un client quitter Oracle ou Microsoft Server SQL pour son service, il s’agit de faciliter l’adoption des bases de données cloud, synonyme d’une augmentation du panier moyen par client. Et si GCP commence avec MySQL, il compte bien séduire les utilisateurs de PostgreSQL.

« [...] PostgreSQL possède un grand nombre de ces fonctionnalités que les clients d'Oracle recherchent. »

« Ces dernières années, nous avons assisté à un changement spectaculaire sur le marché et l’adoption de PostgreSQL a explosé. De nombreux clients considèrent PostgreSQL comme une alternative ouverte aux fonctionnalités de base de données d’entreprise. PostgreSQL possède un grand nombre de ces fonctionnalités que les clients d’Oracle recherchent », commente Andi Gutmans, directeur général et vice-président ingénierie et base de données, chez Google Cloud, auprès de nos confrères de SearchDataManagement [Propriété de Techtarget, également propriétaire du MagIT].

… Et chercher des clients chez Oracle et AWS

Et pour encourager les plus frileux, GCP n’omet pas de citer les cas de Samsung Electronics, Cirruseo (filiale d’Accenture) ou Ryde qui ont déjà pu utiliser le service DMS. Ryde est notamment passé d’Amazon RDS à Cloud SQL, preuve qu’il s’agit également, avec tout le soft power que cela requiert, d’aller chercher des clients chez les concurrents les plus directs (c’est d’ailleurs la seule distribution cloud de MySQL pour laquelle GCP a développé un chemin de migration pour le moment).

L’annonce de DMS sonne comme une réponse à Data Migration Accelarator d’AWS, un service de migration lancé récemment par AWS qui combine outils et conseils d’experts pour un « prix fixe ». Sur le papier, les opérations avec Google Cloud DMS sont beaucoup plus simples (la documentation d’AWS pour migrer de SQL Server à Amazon Aurora MySQL fait 450 pages) que ce service, mais Amazon a aussi un service nommé DMS, « gratuit ». Seulement, ce dernier réclame une étape de conversion des schémas, due en partie aux libertés prises par AWS au regard du code des versions open source.

« Les services traditionnels de migration de bases de données en cloud ont été construits sur le change data capture et n’utilisent pas les capacités de réplication de base de données natives. Il y avait donc toutes ces petites nuances qui pouvaient mal tourner pour les clients, comme des changements de schéma qui ne seraient pas répliqués de la bonne manière. Nous avons donc décidé d’adopter une approche différente et de nous baser sur les meilleures pratiques en matière de migration, à savoir l’utilisation de la réplication native des bases de données », défend Andi Gutmans.

De plus, le directeur général estime que Google a fait les efforts nécessaires pour renforcer la sécurité et assurer la souveraineté des données, que ces deux freins « ont été éliminés ces dernières années ». Enfin, la crise sanitaire accélérerait les discussions avec les clients, qui se préoccupent moins des questions « de migration, de coût total de possession et de sécurité, etc. La plupart des conversations portent maintenant sur la manière et sur la rapidité avec lesquelles ils peuvent migrer ».