Passer d’une reprise d’activité classique à une reprise d’activité VMware moderne
Cet article fournit des informations sur l’architecture, l’infrastructure nécessaire ainsi que les FAQ relatives au passage d’une architecture classique à une architecture de protection moderne pour vos réplications machines VMware ou physiques. Avec cette fonctionnalité de migration, vous pouvez transférer correctement vos éléments répliqués à partir d’un serveur de configuration vers une appliance de réplication Azure Site Recovery. Cette migration est guidée par un mécanisme de réplication intelligente, qui garantit que la réplication initiale complète ne sera pas effectuée à nouveau pour les éléments répliqués non critiques, et que seules les données différentielles seront transférées.
Notes
Les plans de récupération ne seront pas déplacés et devront être créés à nouveau dans le coffre Recovery Services moderne.
Architecture
Le tableau suivant récapitule les composants impliqués dans la migration des éléments répliqués d’une machine VMware ou physique :
| Composant | Prérequis |
|---|---|
| Éléments répliqués dans un coffre Recovery Services classique | Un ou plusieurs éléments répliqués protégés à l’aide de l’architecture classique et d’un serveur de configuration sain. L’élément répliqué doit être dans un état non critique et doit être répliqué à partir d’un emplacement local vers un emplacement Azure à l’aide de l’agent Mobility s’exécutant sur la version 9.50 ou une version ultérieure. |
| Serveur de configuration utilisé par les éléments répliqués | Le serveur de configuration, qui est utilisé par les éléments répliqués, doit être dans un état non critique et ses composants doivent être mis à niveau vers la dernière version (9.50 ou ultérieure). |
| Coffre Recovery Services avec expérience moderne | Un coffre Recovery Services avec expérience moderne. |
| Appliance de réplication Azure Site Recovery saine | Une appliance de réplication Azure Site Recovery non critique capable de découvrir des machines locales, avec tous ses composants mis à niveau vers la dernière version (9.50 ou ultérieure). Les versions exactes nécessaires sont les suivantes : Serveur de processus : 9.50 Server proxy : 1.35.8419.34591 Agent Recovery Services : 2.0.9249.0 Service de réplication : 1.35.8433.24227 |
Infrastructure requise
Pour déplacer correctement un élément répliqué, vérifiez que vous disposez des éléments suivants :
- Un coffre Recovery Services avec l’expérience moderne.
Notes
L’expérience moderne sera activée par défaut dans tous les nouveaux coffres Recovery Services. Vous ne pouvez pas basculer vers l’expérience classique, car sa dépréciation a déjà été annoncée.
- Une appliance de réplication Azure Site Recovery qui a été correctement inscrite dans le coffre et dont tous les composants sont dans un état non critique.
- La version de l’appliance doit être 9.50 ou ultérieure. Pour obtenir une description détaillée de la version, cliquez ici.
- Les détails du serveur vCenter ou de l’hôte vSphere, où se trouvent les machines répliquées existantes, sont ajoutés à l’appliance pour que la découverte locale réussisse.
Prérequis
Préparer l’infrastructure
Effectuez les étapes suivantes avant de passer de l’architecture classique à l’architecture moderne :
- Créez un coffre Recovery Services et vérifiez que l’expérience n’est pas passée en classique
- Déployez une appliance de réplication Azure Site Recovery.
- Ajoutez les informations vCenter Server de la machine locale à l’appliance afin qu’elle effectue correctement la découverte.
Préparer le coffre Recovery Services classique
Vérifiez ce qui suit pour les éléments répliqués que vous prévoyez de déplacer :
- L’élément répliqué est une machine VMware ou physique qui est répliquée via un serveur de configuration.
- La réplication n’est pas effectuée dans un compte de stockage non managé, mais plutôt sur un disque managé.
- La réplication est effectuée à partir d’un emplacement local vers un emplacement Azure, et l’élément répliqué n’a pas été basculé ni restauré automatiquement.
- L’élément répliqué ne réplique pas les données à partir d’Azure vers un emplacement local.
- La réplication initiale n’est pas en cours et est déjà terminée.
- L’élément répliqué n’est pas en cours de resynchronisation.
- La version du serveur de configuration est 9.50 ou ultérieure et son état de santé est dans un état non critique.
- Le serveur de configuration a une pulsation saine.
- La version de l’agent de service Mobility installée sur la machine source est égale ou supérieure à 9.50.
- Les coffres Recovery Services avec MSI activés sont pris en charge.
- Les coffres Recovery Services avec les points de terminaison privés activés sont pris en charge.
- L’élément répliqué est dans un état non critique ou ses points de récupération ont bien été créés.
Préparer le coffre Recovery Services moderne
Pour la configuration de l’architecture moderne, vérifiez que :
- Le coffre Recovery Services utilisé pour la configuration de l’architecture moderne se trouve au même emplacement géographique que le coffre classique.
- Une appliance de réplication Azure Site Recovery a été déployée localement avec la version 9.50 ou une version ultérieure.
- L’appliance est correctement inscrite au coffre.
- L’appliance et tous ses composants sont dans un état non critique et l’appliance a une pulsation saine.
- La version de vCenter Server est prise en charge par l’architecture moderne.
- Les informations vCenter Server de la machine source sont ajoutées à l’appliance.
- La version de distribution Linux est prise en charge par l’architecture moderne. Plus d’informations
- La version de Windows Server est prise en charge par l’architecture moderne. Plus d’informations
Calculer le temps total nécessaire au déplacement
Le temps total nécessaire pour déplacer n’importe quel élément répliqué du coffre classique vers le coffre moderne dépend de l’état de réplication de l’élément et de la taille du disque.
| State | Temps de migration vers un coffre moderne |
|---|---|
| L’état de protection de l’élément répliqué est sain et le dernier point de récupération a été créé il y a moins de 50 minutes | La migration sera terminée sous 1 à 2 heures |
| L’état de protection de l’élément répliqué n’est pas sain ou le dernier point de récupération a été créé il y a plus de 50 minutes | Le temps de migration varie et dépend de la taille du disque |
Si l’état de protection de vos machines n’est pas sain, utilisez la formule ci-dessous pour calculer le temps exact pour vos machines :
Temps de migration = 1 heure + 45 secondes/Gio
| Configuration d’un ordinateur | Temps de migration |
|---|---|
| 1 machine avec 2 disques, tous les deux de 256 Gio | ~ 4 heures 15 minutes [Les deux disques sont migrés en parallèle] |
| 10 machines avec 2 disques chacune, tous les deux de 256 Gio | ~ 4 heures 15 minutes [Toutes les machines virtuelles et leurs disques sont migrés en parallèle] |
| 1 machine avec 4 disques, tous les quatre de 512 Gio | ~ 7 heures 30 minutes [Les deux disques sont migrés en parallèle] |
| 10 machines avec 4 disques chacune, tous de 512 Gio | ~ 7 heures 30 minutes [Toutes les machines virtuelles et leurs disques sont migrés en parallèle] |
La même formule est utilisée pour calculer le temps de migration qui est affiché sur le portail.
Comment définir l’infrastructure nécessaire
Lorsque vous effectuez la migration de machines d’une architecture classique vers une architecture moderne, vous devez vérifier que l’infrastructure nécessaire a déjà été inscrite dans le coffre Recovery Services moderne. Pour définir l’infrastructure nécessaire, reportez-vous aux informations de dimensionnement et de capacité.
En règle générale, vous devez configurer le même nombre d’appliances de réplication que le nombre de serveurs de processus dans votre coffre Recovery Services classique. Dans le coffre-fort classique, s'il y avait un serveur de configuration et quatre serveurs de processus, vous devez configurer quatre dispositifs de réplication dans le coffre-fort Recovery Services modernisé.
Tarifs
Les frais de licence Site Recovery continueront d’être facturés pour le coffre classique jusqu’à ce que la période de conservation de tous les points de récupération ait expiré. Une fois que tous les points de récupération auront été nettoyés, la facturation s’arrêtera également pour le coffre classique. Une fois que la période de conservation aura expiré pour tous les points de récupération, l’élément répliqué sera automatiquement supprimé via une opération de réplication de vidage déclenchée par le système.
Site Recovery ne commencera à facturer des frais de licence sur les éléments répliqués du coffre moderne qu’après la génération du premier point de récupération et le nettoyage de l’ancien coffre. S’il existe des jours d’utilisation en attente dans le cadre de l’essai gratuit du coffre classique, les mêmes informations seront transmises au coffre moderne. La facturation du coffre moderne ne commencera qu’une fois cette période d’évaluation passée.
Notes
À un moment donné, la facturation ne concernera l’utilisation que d’un seul coffre, soit le coffre classique, soit le coffre moderne.
FAQ
Pourquoi effectuer la migration des machines vers l’architecture moderne ?
Il est important de noter que l’architecture classique pour la récupération d’urgence sera progressivement supprimée. Les utilisateurs doivent donc s’assurer de passer à la version la plus récente et modernisée. Le tableau suivant fournit une comparaison des deux architectures pour vous aider à choisir l’option appropriée pour sécuriser vos machines en cas de sinistre.
| Architecture classique | Architecture moderne [Nouveau] |
|---|---|
| Plusieurs configurations sont nécessaires pour la découverte des données locales. | Découverte centrale du centre de données local à l’aide du service de découverte. |
| Nombreuses étapes nécessaires pour l’intégration initiale. | Expérience d’intégration simplifiée par l’automatisation de la création d’artefacts et l’ajout de valeurs par défaut pour réduire le nombre d’entrées nécessaires. |
| Utilisation d’un fichier téléchargé manuellement pour obtenir le contexte cloud. | Ajout de la clé de réplication pour obtenir le contexte cloud lors de la configuration de l’appliance. |
| Un grand nombre d’étapes est nécessaire pour un simple processus d’activation de la réplication. | Expérience d’activation de la réplication simplifiée par la réduction du nombre d’entrées nécessaires et par la redéfinition de chaque panneau. |
| Le serveur de configuration continue d’être une infrastructure locale impliquant une configuration importante pour différents composants. | Amélioration de l’appliance par la conversion de tous les composants en microservices hébergés par Azure. Cela simplifie la mise à l’échelle, le monitoring et la résolution des problèmes de l’appliance. |
| Nécessité d’un serveur de processus de scale-out et d’un serveur cible maître dans Azure pour les machines Linux, ce qui constitue une entrave. | Suppression de la nécessité de séparer le serveur de processus et le serveur cible maître. |
| Utilisation d’une phrase secrète statique pour l’authentification, ce qui interfère avec les exigences métier du client lors de la rotation périodique des mots de passe. | Ajout de l’authentification basée sur les certificats, qui est plus sécurisée et résout les problèmes de sécurité du client. |
| La mise à niveau vers une version mise à jour doit être effectuée manuellement, ce qui est un processus fastidieux. | Ajout des mises à niveau automatiques pour les composants de l’appliance et le service Mobility. |
| Le serveur de configuration ne dispose pas de la haute disponibilité et présente donc un risque d’effondrement. | Implémentation de la haute disponibilité d’appliance pour garantir la résilience. |
| Nécessité de mettre à jour les informations d’identification racines régulièrement pour garantir une expérience de mise à niveau sans erreur. | Suppression de la nécessité de conserver les informations d’identification racines de la machine grâce à des mises à niveau automatiques. |
| Nécessité d’affecter l’adresse IP statique au serveur de configuration pour maintenir la connectivité. | Ajout d’une connectivité basée sur le nom de domaine complet entre l’appliance et les machines locales. |
| Seul ce réseau virtuel (sur lequel le VPN de site à site ou ExpressRoute est activé) doit être utilisé. | Suppression de la nécessité d’un VPN de site à site ou d’ExpressRoute pour la réplication inversée. |
| Un outil tiers, MySQL, doit également être configuré. | Suppression de la dépendance à l’égard d’outils tiers. |
Quelles machines doivent faire l’objet d’une migration vers l’architecture moderne ?
Toutes les machines VMware ou physiques qui sont répliquées à l’aide d’un serveur de configuration doivent faire l’objet d’une migration vers l’architecture moderne.
Où dois-je créer mon coffre Recovery Services moderne ?
Le coffre Recovery Services moderne doit se trouver dans la même région et le même locataire que le coffre classique. Il peut faire partie de n’importe quel abonnement ou groupe de ressources.
Ma réplication continuera-t-elle pendant la migration ?
Non, la réplication s’interrompt pendant que la migration est en cours. Pendant ce temps, vous pourrez basculer vers le dernier point de récupération créé dans le coffre Recovery Services classique. Une fois la migration terminée, un nouveau point de récupération est généré dans le coffre Recovery Services moderne.
Quand mon opération de migration sera-t-elle marquée comme terminée ?
L’opération de migration n’est marquée qu’une fois le premier point de récupération créé dans le coffre Recovery Services moderne.
Quelles opérations peuvent être effectuées à partir de mon coffre Recovery Services classique, une fois la migration effectuée ?
Après la migration, vous pouvez uniquement effectuer un basculement à partir de votre coffre classique. L’opération de basculement continuera d’être disponible dans le coffre classique jusqu’à l’expiration des points de récupération.
Par exemple, si la période de rétention d’un élément répliqué est de 72 heures (trois jours), le dernier point de rétention du coffre classique continuera d’être disponible pendant 72 heures (trois jours) après une migration réussie. Après la période prévue, Azure Site Recovery déclenche une opération de réplication de vidage sur l’élément répliqué, et effectue le nettoyage de tous les éléments de stockage et de facturation associés.
Que se passe-t-il si ma machine connaît un sinistre pendant que l’opération de migration est en cours ?
Tout élément répliqué en cours de migration peut toujours prendre en charge l’opération de basculement via le coffre Recovery Services classique jusqu’à la fin de la période de rétention pour le point de récupération final. Si vous essayez d’exécuter une opération de basculement, elle est prioritaire sur l’opération de migration et la tâche de migration est abandonnée. Pour garantir la migration de votre élément répliqué, vous devez déclencher à nouveau l’opération de migration à un moment ultérieur.
Notes
Les propriétés Calcul et Réseau des éléments répliqués peuvent être mises à jour pendant la migration. Toutefois, les modifications peuvent ne pas être répliquées dans le coffre Recovery Services moderne.
Combien de machines puis-je migrer d’un coffre classique vers un coffre moderne ?
Vous pouvez migrer jusqu’à 10 machines à la fois via le portail.
Dois-je recréer les réseaux virtuels, les comptes de stockage et la stratégie de réplication à utiliser dans le nouveau coffre ?
Non, les ressources utilisées précédemment seront utilisées par défaut dans le coffre moderne. Vous pourrez toujours les modifier à partir du panneau Calcul et Réseau de votre élément répliqué. Vous devez faire en sorte que les ressources continuent de disposer de l’accès nécessaire.
Comment mes stratégies de réplication seront-elle déplacées vers le coffre moderne ?
Dans le cadre des prérequis, Site Recovery crée des stratégies de réplication dans le coffre moderne, avec la même configuration que celle du coffre classique. Ainsi, avant qu’un élément répliqué ne soit déplacé, la stratégie associée est créée dans le coffre modernisé. Nous recommandons d’éviter d’apporter des modifications à la configuration des stratégies de réplication dans le coffre classique une fois la migration déclenchée, car ces modifications ne seront pas répercutées dans le coffre modernisé. Il est préférable d’apporter ces modifications avant de commencer le processus de migration.
La stratégie de réplication créée dans le coffre moderne verra son nom modifié dans celui-ci. Le nom sera suffixé du nom du groupe de ressources et de celui du coffre Recovery Services moderne. Par conséquent, si le nom de la stratégie était « stratégie de réplication par défaut » dans le coffre classique, alors dans le coffre modernisé, le nom de la cette stratégie est default replication policy contoso-modern-vault_contoso-rg, puisque le nom du coffre est contoso-modern-vault et que le nom du groupe de ressources du coffre est contoso-rg.
Puis-je modifier ma stratégie de réplication pendant la migration ou après la migration dans le coffre classique ?
Si le réplica d’une stratégie de réplication a déjà été créé dans le coffre moderne, les modifications apportées à la stratégie dans le coffre classique ne seront pas propagées vers le coffre moderne.
Par conséquent, si 10 éléments sont répliqués à l’aide d’une stratégie et que vous décidez d’en déplacer 5 vers l’expérience moderne, une copie de la stratégie est créée avant le démarrage de la migration. À présent, avant d’effectuer la migration des 5 éléments restants, si des modifications sont apportées à la stratégie du coffre classique, la stratégie du coffre moderne ne sera pas mise à jour. Vous devez également apporter ces modifications de configuration dans le coffre modernisé.
Comment migrer les éléments répliqués qui sont présents dans un groupe de réplication (également appelé « groupe de cohérence multimachine virtuelle ») ?
Tous les éléments répliqués qui font partie d’un groupe de réplication sont migrés ensemble. Vous pouvez sélectionner tous en sélectionnant le groupe de réplication ou en les ignorant tous. Si le processus de migration échoue pour certaines machines d’un groupe de réplication, mais réussit pour d’autres, une restauration vers l’expérience classique est effectuée pour les éléments répliqués ayant échoué et le processus de migration peut être déclenché à nouveau pour ces éléments.
Étapes suivantes
Comment passer d’une reprise d’activité classique à une reprise d’activité VMware moderne