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 les applications critiques installées, 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 rendait les grandes migrations de centres de données difficiles et imprévisibles.
Ces dernières années, les services de réplication continue de blocs ont facilité le déplacement des charges de travail d’une infrastructure physique ou virtuelle vers le Cloud, permettant ainsi le concept de migrations à grande vitesse.
Les options pour lever et 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. La quantité d’informations collectées varie en fonction de la taille du portefeuille à évaluer.
Toutes les applications qui sont considérées comme techniquement déplaçables vers GCP et qui ne bénéficieront pas de la transformation, seront marquées comme « Rehost » et seront déplacées comme « lift and shift ».
Quelles sont les options disponibles sur GCP ?
Très bien, vous avez évalué vos applications et décidé d’en lever et d’en transférer certaines vers GCP par « lift and shift ». Quelle est la suite ?
Comme mentionné, Migrate for Compute Engine est la meilleure option pour un simple réhébergement. 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.
Par où 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 VM qui exécutera le gestionnaire elle-même.
Ensuite, afin d’utiliser Migrate for Compute Engine, vous devrez déployer une VM principale sur votre environnement VMware. Les instructions détaillées sont disponibles ici, mais il convient de mentionner deux points de vigilance principaux :
- La taille de la VM que vous devez créer varie en fonction du nombre de serveurs à transférer par « lift and shape ». Le nombre de serveurs qui se répliquent aura également un impact sur les besoins en bande passante de votre réseau.
- La VM arrière 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. Cette extension déploiera deux nœuds Edge, qui se chargeront de recevoir les données répliquées depuis le site et de les stocker dans le Cloud comme zone de transit.
Très bien, 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 VM, surtout 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 :
- 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, surtout 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.
- 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, 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.
Pouvez-vous faire plus ?
Souvent, un simple « lift and shift » ne suffit pas, car certaines modifications sont nécessaires pour que la VM 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 les 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 VM 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 adapté au Cloud). Votre consommation peut varier, en fonction de la complexité de la VM et si l’un des logiciels installés a des dépendances strictes à Windows 2008, mais la possibilité d’effectuer une mise à niveau sur place qui est orchestrée par Migrate for Compute Engine constitue 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 les a améliorées en y ajoutant des fonctions 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 VM.
Si vous devez migrer rapidement des charges de travail, GCP est un excellent choix en tant que Cloud cible. Notre expérience chez Cloudreach nous montre que Migrate for Compute Engine augmente la rapidité des migrations vers la plateforme.
Pour plus d’informations sur notre pratique Google Cloud, cliquez ici. Contactez-nous si vous souhaitez discuter des migrations vers le Cloud et de la manière dont Cloudreach peut aider votre organisation à passer à GCP !
