AWS renchérit dans la bataille du lift & shift

Comme CloudEndure, mais intégré à la console de gestion AWS. Ainsi pourrait-on décrire Application Migration Service (MGN). Le groupe américain vient de rappeler avoir récemment lancé cette offre destinée à accompagner les démarches de réhébergement (lift & shift). Il en recommande l’usage non seulement en remplacement de CloudEndure, mais aussi de Server Migration Service (SMS)… dans la mesure du possible.

(cliquer sur l’image pour l’agrandir)

Principale différence par rapport à SMS : la méthode de réplication des serveurs. Avec MGN, elle est continue, au niveau bloc. Et non basée sur des instantanés. Ce qui est censé permettre des fenêtres de transition plus courtes.

Qu’entendre par « dans la mesure du possible » ? En particulier, réhéberger dans une région AWS où MGN est effectivement disponible. Mais aussi de pouvoir installer un agent sur chaque serveur source.

Cet agent assure l’association des serveurs via l’API MGN, puis le transfert des données et la synchronisation des écritures au niveau OS. AWS annonce une consommation de l’ordre de 5 % du CPU et de 250 Mo de RAM.

Le paramétrage initial suppose la création d’un modèle de réplication qui s’appliquera par défaut à chaque serveur source. On y définit deux aspects. D’un côté, les règles de transfert (routage et bande passante). De l’autre, la configuration des serveurs de réplication.

Ces serveurs de réplication consistent en des instances EC2 lancées dans un sous-réseau au sein du VPC. De base, il s’agit de VM t3.small assorties de volumes EBS st1 (disques durs « à débit optimisé »).

Ces propriétés peuvent ensuite être changées pour tout serveur ou groupe de serveurs sources. On trouvera ici la liste des systèmes d’exploitation compatibles.

La réplication implique une compression LZW (60 à 70 %) et un chiffrement en transit (AES-256). En moyenne, un serveur de réplication prendra en charge 15 volumes EBS (un par disque source).

90 jours pour migrer

Une fois la réplication configurée, il faut définir les paramètres de lancement de chaque serveur réhébergé. On crée en fait un template EC2 qui va permettre l’exécution native sur AWS. Le processus de conversion passe par un VM intermédiaire lancée au sein du même sous-réseau et qui effectue les changements nécessaires : chargeur d’amorçage, pilotes d’hyperviseur, outils cloud… Il en résulte les instances « finales », fondées sur le dernier état des volumes EBS – et donc des serveurs sources.

Parmi ces paramètres de lancement :

Option de sélection automatique de l’instance la mieux adaptée
Démarrage manuel ou automatique des instances de destination
Vérification de correspondance de l’IP privée avec celle qu’utilise le serveur source
Transfert des étiquettes éventuellement attribuées au serveur source
Transfert des licences

MGN fonctionne avec AWS Migration Hub, pour suivre les opérations au niveau des applications en plus des serveurs. L’outil ne peut être lancé que par un admin qui aura activé au préalable l’authentification multifacteur sur son compte.

Dans l’absolu, MGN en lui-même est gratuit. En tout cas pour les réplications faites sous 90 jours. Il faut néanmoins y ajouter le coût des ressources EBS et EC2 consommées.

Illustration principale © peshkov – Adobe Stock