Share:

Par le passé, le transfert d’un parc d’applications important vers le Cloud impliquait la remise en question de la connectivité, des dépendances, de la configuration et de la manière dont l’application devait être réinstallée dans le Cloud. Une fois l’installation des applications réalisée, un cycle de test et d’acceptation était nécessaire, ce qui faisait que le délai pour la migration d’une seule application s’étendait sur plusieurs mois, voire plus. L’application d’une approche similaire à des centaines d’applications a rendu les migrations de grands centres de données difficiles et imprévisibles. 

Ces dernières années, les services de réplication par blocs continus ont rendu le déplacement des charges de travail de l’infrastructure physique ou virtuelle vers le Cloud beaucoup plus facile, permettant le concept de migrations à grande vitesse. 

Les options permettant de lever et de déplacer les charges de travail dans Google Cloud Platform (GCP) tournent autour de Velostrata, récemment renommé Migrate for Compute Engine.

Comment aborder les migrations

De la même manière qu’il n’est pas toujours possible de moderniser chaque charge de travail d’un grand portefeuille, je ne recommanderais pas de déplacer chaque application en utilisant une approche « lift and shift ». Certaines applications critiques pour l’entreprise ou génératrices de revenus peuvent bénéficier d’une transformation complète à l’aide d’une conception Cloud native, qui offre également des avantages en termes de coûts et de performances.

L’approche que je privilégie lorsqu’il s’agit d’aborder une importante migration Cloud vers Google consiste à définir des critères clairs pour attribuer les 6R (inspirés de cet article de Gartner publié en 2010) en fonction des facteurs techniques et commerciaux. Les points de données techniques peuvent être collectés à l’aide d’un outil de découverte automatisé, tel que Cloudamize. Cloudamize, ou d’autres outils similaires disponibles sur le marché, peuvent fournir des coûts d’exploitation comparables à ceux de GCP, ainsi que les nombreux points de données qui peuvent être utilisés pour évaluer l’application. Les points de données commerciales sont généralement collectés au moyen d’enquêtes et/ou d’entretiens, mais l’approche spécifique peut varier en fonction de vos besoins particuliers. Selon la taille du portefeuille, l’évaluation de la quantité d’informations recueillies changera.

Toutes les applications qui sont considérées comme techniquement mobiles pour GCP et qui ne bénéficieront pas de transformation, seront marquées comme Rehost et seront déplacées en tant que lift and shift.

Quelles options ai-je dans GCP

Très bien, vous avez évalué vos applications et décidé d’en transférer certaines vers GCP par « lift and shift ». Quelle est la prochaine étape ? 

Comme mentionné, Migrate for Compute Engine est la meilleure option pour un réhébergement simple. Il prend en charge la migration à partir d’un environnement VMware sur site ou d’autres fournisseurs de services Cloud. Un large éventail de systèmes d’exploitation est pris en charge :

  • Windows 2003 et versions ultérieures
  • Linux avec noyau 2.6+ pour les migrations hors ligne
  • Linux avec noyau 3.13+ pour les migrations en ligne

Des informations complémentaires sur les systèmes d’exploitation pris en charge sont disponibles ici.

J’y suis, comment puis-je commencer ?


Nous supposons que vous avez configuré votre environnement Cloud avec au moins un projet et un VPC connecté à votre centre de données sur site. En plus de l’environnement Cloud, certains ports réseau doivent être ouverts afin de permettre la communication entre votre environnement GCP et VMware. 

Une fois la connectivité réseau configurée, vous pouvez déployer Compute Engine Manager. Le gestionnaire vous guidera à travers un assistant, qui créera un compte de service et une machine virtuelle qui exécutera le gestionnaire lui-même. 

Ensuite, pour utiliser Migrate for Compute Engine, vous devez déployer une machine virtuelle principale sur votre environnement VMware. Les instructions détaillées sont disponibles ici, mais il convient de mentionner deux points de vigilance principaux :

  1. La taille de la VM que vous devez créer varie en fonction de la quantité de serveurs à transférer par « lift and shift ». La quantité de serveurs qui se répliquent aura également un impact sur les besoins en bande passante de votre réseau
  2. La VM de sauvegarde sur vSphere nécessitera un ensemble spécifique de permissions qui sont accordées en tant que rôle de service. En fonction de vos exigences en matière de sécurité, répondez à ce besoin dès le début afin d’éviter tout retard pendant la migration.

La dernière étape avant votre première migration consiste à configurer une extension Cloud. L’extension déploiera deux nœuds Edge, qui se chargeront de recevoir les données répliquées sur site et de les stocker dans Cloud Storage en tant que zone intermédiaire. 

Génial, vous êtes maintenant prêt à migrer votre première charge de travail !

Test d’une VM dans GCP

L’exécution de la configuration est probablement l’activité qui prend le plus de temps pour utiliser Migrate for Compute Engine. Pour déplacer une VM à partir d’une installation sur site, il suffit d’utiliser le client vSphere pour choisir la VM que vous souhaitez exécuter dans le Cloud, puis de sélectionner « Migrate for Google Compute Engine Operations > Run-in-Cloud ».

L’une des principales différences entre Migrate for Compute Engine et d’autres outils qui peuvent être utilisés pour le « lift and shift » est que « Run-in-Cloud » ne migre pas réellement la VM. Au lieu de cela, l’outil synchronisera suffisamment le disque de la VM pour permettre un démarrage tandis que les données restantes sont diffusées en continu et mises en cache localement sur GCP. Cette approche réduit le temps nécessaire pour tester les machines virtuelles, en particulier lorsque le stockage sur site représente plusieurs centaines de Go.

La documentation de Migrate for Compute Engine est assez complète, je ne vais donc pas énumérer toutes les étapes ici. Ce qui vaut la peine d’être souligné lors du test de VM dans le Cloud :

  1. Lors de la sélection de la politique de stockage, « Write Back » écrira toutes les modifications effectuées sur GCP vers le site. Ce paramètre peut être dangereux, en particulier si vous devez adapter la VM pour qu’elle fonctionne dans GCP. Nous vous recommandons d’utiliser l’option « Write Isolation », beaucoup plus sûre, afin de ne pas affecter vos charges de travail en direct.
  2. Même si l’option « Write ~Isolation » est activée, votre VM interagira très probablement avec d’autres VM (bases de données, serveurs d’applications, etc.) qui peuvent ou non se déplacer en même temps. En outre, dans le cas des charges de travail Windows (Windows Workloads), la VM peut être jointe au domaine du répertoire actif de votre entreprise. Il est important de vérifier les balises réseau appliquées à la VM afin de s’assurer que l’interaction avec les autres systèmes est maîtrisée.

Une fois les tests terminés, Migrate for Compute Engine permet de basculer le stockage sur site vers GCP, en arrêtant effectivement la VM source et en la remplaçant par celle dans le Cloud.

Très bien, mais puis-je en faire plus?

Souvent, un lift and shift (portage virtuel) directs ne suffisent pas, car certaines modifications seront nécessaires pour que la machine virtuelle fonctionne correctement. 

Migrate for Compute Engine prend en charge l’exécution de scripts d’adaptation au démarrage. Les scripts peuvent être utilisés pour modifier les interfaces réseau, désinstaller des outils qui ne sont pas nécessaires dans le nouvel environnement ou même désactiver temporairement les services qui causeront des problèmes pendant les tests.  

Pour les hôtes Windows et Linux, le fonctionnement des scripts est le même : les scripts doivent être placés dans un répertoire spécifique de la machine virtuelle source et seront exécutés selon des règles spécifiques. 

En plus des scripts d’automatisation, Migrate for Compute Engine prend en charge la mise à niveau de la version de Windows de 2008 R2 vers un Windows 2012 plus moderne (et convivial pour le Cloud). Votre kilométrage peut varier en fonction de la complexité de la machine virtuelle et si l’un des logiciels installés a des dépendances matérielles à Windows 2008, mais la possibilité d’effectuer une mise à niveau sur place orchestrée par Migrate for Compute Engine est un énorme avantage par rapport à d’autres logiciels qui effectuent une réplication de bloc similaire.

 

Pour terminer

Migrate for Compute Engine, a repris toutes les fonctionnalités de Velostrata et amélioré avec des fonctionnalités supplémentaires telles que la mise à niveau sur place, et plus récemment la possibilité de migrer dans un conteneur plutôt que dans une machine virtuelle. 

Il n’y a aucune raison de ne pas choisir GCP comme Cloud cible pour les charges de travail lift and shift, et notre expérience chez Cloudreach est que le moteur Migrate for Compute augmente la vitesse des migrations vers la plate-forme.

Contactez-nous si vous souhaitez en savoir plus sur la migration vers le Cloud et sur la façon dont Cloudreach peut aider votre organisation à passer à GCP  !