Architecture de migration sans agent

Cet article décrit les concepts de réplication lorsque vous migrez des machines virtuelles VMware à l’aide de la méthode de migration sans agent dans Azure Migrate.

Processus de réplication

L’option de réplication sans agent fonctionne à l’aide de captures instantanées VMware et de la technologie de suivi des blocs modifiés (CBT) VMware pour répliquer des données à partir de disques de machine virtuelle. Le diagramme de blocs suivant vous montre les étapes impliquées lors de la migration de vos machines virtuelles à l’aide d’Azure Migrate.

Lorsque vous configurez la réplication pour une machine virtuelle, elle passe par une phase de réplication initiale. Pendant cette phase, Azure Migrate prend une capture instantanée de machine virtuelle. Le service réplique ensuite une copie complète des données des disques d’instantanés vers des disques managés dans votre abonnement cible.

Une fois la réplication initiale de la machine virtuelle terminée, le processus de réplication passe à une phase de réplication incrémentielle (réplication différentielle). Dans cette phase, les modifications de données qui se sont produites depuis le début du dernier cycle de réplication terminé sont répliquées et écrites sur les disques managés du réplica. Cette partie du processus conserve la réplication synchronisée avec les modifications sur la machine virtuelle.

Azure Migrate utilise la technologie VMware CBT pour suivre les modifications entre les cycles de réplication. Au début d’un cycle de réplication, Azure Migrate prend une capture instantanée de machine virtuelle. Le service utilise CBT pour obtenir les modifications entre l’instantané actuel et la dernière capture instantanée répliquée avec succès. Seules les données qui ont changé depuis le cycle de réplication terminé précédent sont répliquées pour conserver la réplication de la machine virtuelle synchronisée. À la fin de chaque cycle de réplication, l’instantané est libéré et Azure Migrate effectue la consolidation des captures instantanées pour la machine virtuelle.

Lorsque vous effectuez l’opération de migration sur une machine virtuelle de réplication, un cycle de réplication delta à la demande réplique les modifications restantes depuis le dernier cycle de réplication. Une fois le cycle à la demande terminé, Azure Migrate crée la machine virtuelle dans Azure à l’aide des disques managés de réplica qui correspondent à la machine virtuelle.

Avant de déclencher la migration, vous devez arrêter la machine virtuelle locale. L’arrêt de la machine virtuelle empêche la perte de données pendant la migration.

Une fois la migration réussie et que la machine virtuelle redémarre dans Azure, veillez à arrêter la réplication de la machine virtuelle. L’arrêt de la réplication supprime les disques intermédiaires (disques de départ) créés lors de la réplication des données. Vous évitez ensuite d’entraîner des frais supplémentaires associés aux transactions de stockage sur ces disques.

Cycles de réplication

Un cycle de réplication est le processus périodique de transfert de données d’un environnement local vers des disques managés Azure. Un cycle de réplication complet comprend les étapes suivantes :

1. Créez un instantané VMware pour chaque disque associé à la machine virtuelle.
2. Chargez des données dans un compte de stockage de journaux dans Azure.
3. Relâchez l’instantané.
4. Consolider les disques VMware.

Un cycle est terminé une fois les disques consolidés.

Composants pour la réplication

Une appliance Azure Migrate possède les composants locaux suivants qui sont responsables de la réplication :

• Agent de réplication de données
• Agent de passerelle

Le tableau suivant récapitule les composants Azure créés lorsque vous utilisez la méthode sans agent de la migration de machine virtuelle VMware.

Autorisations requises

Lorsque vous démarrez la réplication pour la première fois, l’utilisateur connecté doit avoir les rôles suivants :

• Propriétaire ou Contributeur et Administrateur de l’accès utilisateur sur le groupe de ressources du projet Azure Migrate et le groupe de ressources cible

Pour les réplications suivantes, l’utilisateur connecté doit avoir les rôles suivants :

• Propriétaire ou Contributeur sur le groupe de ressources du projet Azure Migrate et le groupe de ressources cible

En plus des rôles précédents, l’utilisateur connecté a besoin de l’autorisation suivante au niveau d’un abonnement : Microsoft.Resources/subscriptions/resourceGroups/read.

Intégrité des données

Il existe deux étapes dans chaque cycle de réplication pour garantir l’intégrité des données entre le disque local (disque source) et le disque réplica dans Azure (disque cible).

Valider la réplication

La première étape vérifie que chaque secteur modifié dans le disque source est répliqué sur le disque cible. Vous effectuez la validation à l’aide de bitmaps.

Le disque source est divisé en secteurs de 512 octets. Chaque secteur du disque source est mappé à un bit de l’image bitmap. Au démarrage de la réplication des données, Azure Migrate crée une bitmap pour tous les blocs modifiés (en cycle delta) dans le disque source qui doit être répliqué. De même, lorsque les données sont transférées vers le disque Azure cible, Azure Migrate crée une bitmap.

Une fois le transfert de données terminé, le service cloud compare les deux bitmaps pour s’assurer qu’il n’a manqué aucun bloc modifié. En cas d’incompatibilité entre les bitmaps, le cycle est considéré comme ayant échoué. Étant donné que chaque cycle est resynchronisation, l’incompatibilité est fixe dans le cycle suivant.

Vérifier les données répliquées

La deuxième étape garantit que les données transférées vers les disques Azure sont identiques aux données répliquées à partir des disques sources.

Chaque bloc modifié chargé est compressé et chiffré avant d’être écrit en tant qu’objet blob dans le compte de stockage du journal. Azure Migrate calcule la somme de contrôle de ce bloc avant la compression. Cette somme de contrôle est stockée sous forme de métadonnées avec les données compressées.

Lors de la décompression, Azure Migrate calcule la somme de contrôle des données et la compare à la somme de contrôle calculée dans l’environnement source. En cas de discordance, les données ne sont pas écrites sur les disques Azure et le cycle est considéré comme ayant échoué. Étant donné que chaque cycle est resynchronisation, l’incompatibilité est fixe dans le cycle suivant.

Sécurité

L’appliance Azure Migrate compresse les données et les chiffre avant de les charger. Les données sont transmises via un canal de communication sécurisé qui utilise HTTPS et TLS 1.2 ou version ultérieure. En outre, Stockage Azure chiffre automatiquement vos données lorsqu’elles sont conservées dans le cloud (chiffrement au repos).

État de la réplication

Lorsqu’une machine virtuelle subit une réplication (copie de données), il existe plusieurs états possibles :

• Réplication initiale mise en file d’attente : la machine virtuelle est mise en file d’attente pour la réplication ou la migration, car d’autres machines virtuelles peuvent consommer les ressources locales pendant la réplication ou la migration. Une fois les ressources gratuites, cette machine virtuelle est traitée.
• Réplication initiale en cours : la machine virtuelle est planifiée pour la réplication initiale.
• Réplication initiale : la machine virtuelle est en cours de réplication initiale. Lorsque la machine virtuelle subit une réplication initiale, vous ne pouvez pas procéder à la migration de test et à la migration de production. Vous pouvez uniquement arrêter la réplication à ce stade.
• Réplication initiale (x%) : la réplication initiale est active et a progressé par le pourcentage indiqué.
• Synchronisation delta : la machine virtuelle peut subir un cycle de réplication différentielle qui réplique l’attrition des données restantes depuis le dernier cycle de réplication.
• Pause en cours : la machine virtuelle subit un cycle de réplication delta actif et est suspendue.
• Suspendu : les cycles de réplication sont suspendus. Vous pouvez reprendre les cycles de réplication en effectuant l’opération pour reprendre la réplication.
• Reprendre la file d’attente : la machine virtuelle est mise en file d’attente pour reprendre la réplication, car d’autres machines virtuelles consomment actuellement les ressources locales.
• Reprendre en cours (x%) : le cycle de réplication est repris pour la machine virtuelle et a progressé par le pourcentage indiqué.
• Arrêter la réplication en cours : le nettoyage de la réplication est en cours. Lorsque vous arrêtez la réplication, les disques managés intermédiaires (disques amorçage) créés pendant la réplication sont supprimés. Vous pouvez en savoir plus sur l’arrêt de la réplication plus loin dans cet article.
• Finalisation de la migration en cours : le nettoyage de la migration est en cours. Une fois la migration terminée, les disques managés intermédiaires (disques amorçage) créés pendant la réplication sont supprimés. Vous pouvez en savoir plus sur la fin de la réplication plus loin dans cet article.
•  : lorsque la machine virtuelle est correctement migrée ou lorsque vous arrêtez la réplication, l’état passe à un tiret. Une fois la migration terminée ou l’arrêt de la réplication et l’opération s’est terminée correctement, la machine virtuelle est supprimée de la liste des machines de réplication. Vous trouverez la machine virtuelle sous l’onglet des machines virtuelles de l’Assistant réplication.

Autres états

• Échec de la réplication initiale : les données initiales n’ont pas pu être copiées pour la machine virtuelle. Suivez les instructions de correction pour résoudre ce problème.

• Réparation en attente : il y a eu un problème dans le cycle de réplication. Vous pouvez sélectionner le lien pour comprendre les causes possibles et les actions permettant de corriger ce problème (le cas échéant). Si vous avez choisi de réparer automatiquement la réplication en sélectionnant Oui lorsque vous avez déclenché la réplication de la machine virtuelle, l’outil tente de le réparer pour vous. Sinon, sélectionnez la machine virtuelle, puis réparez la réplication.

  Si vous n’avez pas choisi de réparer automatiquement la réplication ou si l’étape de réparation ne fonctionnait pas pour vous, arrêtez la réplication pour la machine virtuelle. Réinitialisez le cbT sur la machine virtuelle, puis reconfigurez la réplication.

• Réplication de réparation mise en file d’attente : la machine virtuelle est mise en file d’attente pour la réparation de la réplication, car d’autres machines virtuelles consomment les ressources locales. Une fois les ressources libérées, la machine virtuelle est traitée pour la réplication de réparation.

• Resynchronisation (x %) : la machine virtuelle subit une resynchronisation des données. Cette resynchronisation peut se produire en cas de problème ou d’incompatibilité pendant la réplication des données.

• Échec de l’arrêt de la réplication/de la finalisation de la migration : sélectionnez le lien pour comprendre les causes possibles de l’échec et des actions permettant de corriger le problème (le cas échéant).

État de la migration de test ou de la migration de production

• Test de migration en attente : la machine virtuelle se trouve dans la phase de réplication delta. Vous pouvez maintenant effectuer une migration de test (ou une migration de production).
• Nettoyer la migration de test en attente : une fois la migration de test terminée, effectuez un nettoyage de migration de test pour éviter les frais dans Azure.
• Prêt à migrer : la machine virtuelle est prête pour la migration vers Azure.
• Migration en cours mise en file d’attente : la machine virtuelle est mise en file d’attente pour la migration, car d’autres machines virtuelles consomment les ressources locales pendant la réplication (ou la migration). Une fois les ressources libérées, la machine virtuelle est traitée.
• Migration de test/migration en cours : la machine virtuelle subit une migration de test ou une migration de production. Vous pouvez sélectionner le lien pour vérifier le travail de migration en cours.
• Date, horodatage : La migration de test ou la migration de production s’est produite à cette date et à cette heure.
• – : la réplication initiale est en cours. Vous pouvez effectuer une migration de test ou une migration de production après la transition du processus de réplication vers une phase de synchronisation delta (réplication incrémentielle).

Autres états

• Terminé avec des informations : le travail de migration de test ou de migration de production a terminé avec des informations. Vous pouvez sélectionner le lien pour vérifier la dernière tâche de migration afin de connaître les causes possibles et les actions permettant de corriger le problème (le cas échéant).
• Échec : échec de la migration de test ou du travail de migration de production. Vous pouvez sélectionner le lien pour vérifier la dernière tâche de migration afin de connaître les causes possibles et les actions permettant de corriger le problème.

Logique de planification

La réplication initiale est planifiée lorsque vous configurez la réplication pour une machine virtuelle. Les réplications incrémentielles (réplications delta) suivent-les.

Les cycles de réplication différentielle sont planifiés comme suit :

• Le premier cycle de réplication delta est planifié immédiatement après la fin du cycle de réplication initial.

• Les prochains cycles de réplication delta sont planifiés en fonction de la logique suivante : min[max[1 hour, (<Previous delta replication cycle time>/2)], 12 hours].

  Autrement dit, la réplication delta suivante est planifiée avant 1 heure et pas plus tard que 12 heures. Par exemple, si une machine virtuelle prend 4 heures pour un cycle de réplication delta, le prochain cycle de réplication delta est planifié en 2 heures, et non dans l’heure suivante.

  Remarque

  La logique de planification est différente une fois la réplication initiale terminée. Le premier cycle delta est planifié immédiatement après la fin de la réplication initiale. Les cycles suivants suivent la logique de planification.

• Lorsque vous déclenchez la migration, un cycle de réplication delta à la demande (avant basculement) se produit pour la machine virtuelle avant la migration.

Hiérarchisation

Voici la hiérarchisation des machines virtuelles pour différentes étapes de réplication :

• Les réplications de machines virtuelles en cours sont hiérarchisées par rapport aux réplications planifiées (nouvelles réplications).
• Le cycle de réplication delta à la demande (avant basculement) a la priorité la plus élevée, suivi du cycle de réplication initial. Le cycle de réplication delta a la priorité la plus basse.

Chaque fois que vous déclenchez une opération de migration, le cycle de réplication à la demande de la machine virtuelle est planifié. D’autres réplications en cours doivent attendre s’ils sont en concurrence pour les ressources.

Contraintes

Les contraintes suivantes vous permettent de vous assurer que vous ne dépassez pas les limites d’E/S par seconde sur les réseaux de zone de stockage :

• Chaque appliance Azure Migrate prend en charge la réplication de 52 disques en parallèle.
• Chaque hôte ESXi prend en charge huit disques. Chaque hôte ESXi dispose d’une mémoire tampon NFC de 32 Mo. Vous pouvez donc planifier 8 disques sur l’hôte. (Chaque disque prend jusqu’à 4 Mo de mémoire tampon pour la réponse aux incidents et la récupération d’urgence.)
• Chaque magasin de données peut avoir un maximum de 15 instantanés de disque. La seule exception est lorsque plus de 15 disques sont attachés à une machine virtuelle.

Réplication avec Scale-out

Azure Migrate prend en charge la réplication simultanée de 500 machines virtuelles. Lorsque vous envisagez de répliquer plus de 300 machines virtuelles, vous devez déployer une appliance avec montée en puissance parallèle. L’appliance de montée en puissance parallèle est similaire à une appliance principale Azure Migrate, mais se compose uniquement d’un agent de passerelle pour faciliter le transfert de données vers Azure.

Le diagramme suivant illustre la méthode recommandée pour utiliser l’appliance de Scale-out.

Vous pouvez déployer l’appliance scale-out à tout moment après avoir configuré l’appliance principale, mais elle n’est pas requise tant que 300 machines virtuelles ne sont pas répliqués simultanément. Lorsque 300 machines virtuelles sont répliqués simultanément, vous devez déployer l’appliance scale-out pour continuer.

Arrêt de la réplication ou fin d’une migration

Lorsque vous arrêtez la réplication, les disques managés intermédiaires (disques amorçage) créés pendant la réplication sont supprimés. Vous pouvez arrêter une réplication uniquement pendant une réplication active. Vous pouvez sélectionner Terminer la migration pour arrêter la réplication une fois la machine virtuelle migrée.

Vous pouvez répliquer la machine virtuelle pour laquelle la réplication est arrêtée en réactivant la réplication. Si la machine virtuelle a été migrée, vous pouvez reprendre la réplication et la migration.

En guise de bonne pratique, vous devez toujours effectuer la migration après la migration de la machine virtuelle vers Azure. Cette pratique garantit que vous n’avez pas de frais supplémentaires pour les transactions de stockage sur les disques managés intermédiaires (disques amorçage).

Dans certains cas, l’arrêt de la réplication prend du temps. La raison est que chaque fois que vous arrêtez la réplication, le cycle de réplication en cours est terminé (uniquement lorsque la machine virtuelle est synchronisée delta) avant la suppression des artefacts.

Impact de l’attrition

Vous pouvez réduire la quantité de transfert de données dans chaque cycle de réplication en autorisant les données à plier autant que possible avant de planifier le cycle suivant. La réplication sans agent opérant un repli des données, le modèle de variation est plus important que le taux de variation. Quand un fichier est écrit à plusieurs reprises, le taux n’a pas un impact important. Toutefois, un modèle dans lequel un secteur sur deux est écrit entraîne une variation élevée lors du cycle suivant.

Si le cycle de réplication delta actuel subit des retards en raison d’une activité de données élevée, l’initiation du cycle suivant peut être retardée. Un volume plus élevé de données à répliquer pour un disque spécifique étend la durée nécessaire à la création d’un point de récupération. Par conséquent, le cycle de migration final prend plus de temps. Cette situation entraîne une fenêtre d’arrêt étendue pour la machine virtuelle source.

Si la taille d’instantané augmente (en raison du modèle d’attrition) dans une mesure qui traverse la capacité disponible du magasin de données, il y a un risque que le magasin de données manque d’espace. Cette situation peut affecter négativement les charges de travail de production et peut rendre la machine virtuelle source sans réponse.

Pour atténuer ce risque, nous vous recommandons d’augmenter de manière proactive la taille du magasin de données. Si plusieurs machines virtuelles que vous répliquez simultanément ont des disques dans un magasin de données dont la capacité est faible, nous vous conseillons d’effectuer des migrations d’une machine virtuelle à la fois pour éviter la contention des ressources.

Gestion de la réplication

Limitation

Vous pouvez augmenter ou diminuer la bande passante de réplication à l’aide de NetQosPolicy. La AppNamePrefix valeur à utiliser dans NetQosPolicy est GatewayWindowsService.exe.

Pour limiter le trafic de réplication à partir de l’appliance Azure Migrate, vous pouvez créer une stratégie comme l’exemple suivant sur l’appliance. Cette stratégie s’applique simultanément à toutes les machines virtuelles de réplication de l’appliance Azure Migrate.

New-NetQosPolicy -Name "ThrottleReplication" -AppPathNameMatchCondition "GatewayWindowsService.exe" -ThrottleRateActionBitsPerSecond 1MB

Vous pouvez également augmenter et diminuer la bande passante de réplication en fonction d’une planification à l’aide de l’exemple de script.

Fenêtre d’indisponibilité

Azure Migrate fournit un mécanisme basé sur la configuration que vous pouvez utiliser pour spécifier l’intervalle de temps pendant lequel vous ne souhaitez pas que les réplications continuent. Cet intervalle est appelé fenêtre d’interruption. La nécessité d’une fenêtre de blackout peut survenir dans plusieurs scénarios, par exemple lorsque l’environnement source est limité aux ressources ou que vous souhaitez que la réplication se produise uniquement en dehors des heures d’ouverture.

Vous pouvez spécifier une fenêtre de blackout pour l’appliance en créant ou en mettant à jour le GatewayDataWorker.json fichier dans C:\ProgramData\Microsoft Azure\Config. Un fichier classique comporte ce formulaire :

{
    
    "BlackoutWindows": "List of blackout windows"
    
}

La liste des fenêtres noires est une chaîne délimitée par un canal (|) du format <DayOfWeek>;<StartTime>;<Duration>. Vous pouvez spécifier la durée en jours, heures et minutes. Par exemple, vous pouvez spécifier les fenêtres de blackout comme suit :

{
    
    "BlackoutWindows": "Monday;7:00;7h | Tuesday;8:00;1d7h | Wednesday;16:00;1d | Thursday;18:00;5h | Friday;13:00;8m"
    
}

La première valeur de l’exemple précédent indique une fenêtre de panne qui démarre tous les lundis à 7 h (heure locale, heure sur l’appliance) et dure 7 heures.

Après avoir créé ou mis à jour GatewayDataWorker.json avec ce contenu, vous devez redémarrer le service de passerelle sur l’appliance pour que ces modifications prennent effet.

Dans le scénario de Scale-out, l’appliance primaire et l’appliance de Scale-out respectent les fenêtres d’indisponibilité de manière indépendante. À titre de meilleure pratique, nous vous recommandons de garder les fenêtres cohérentes entre les différents appareils.

Contenu connexe

• Migrer des machines virtuelles VMware vers Azure (sans agent)