Important : Cette version comporte uniquement des mises à jour pour les scénarios de protection azure-à-Azure et de VMware-to-Azure modernisés.
Introduction
Cet article décrit les problèmes résolus dans le correctif cumulatif 69 dans les versions suivantes de Microsoft Azure Site Recovery :
-
Azure vers Azure
-
VMware/Physique modernisé vers Azure
Découvrez les détails des problèmes résolus et les prérequis qui doivent être vérifiés avant d’installer cette mise à jour.
Conditions préalables
Pour installer Microsoft Azure Site Recovery Provider Update Rollup 69, l’un des éléments suivants doit être installé :
-
Fournisseur Microsoft Azure Site Recovery (version 5.1.7700 ou ultérieure)
-
Installation unifiée de Microsoft Azure Site Recovery (VMware vers Azure) (version 9.52.xxxx.x ou ultérieure)
-
Microsoft Azure Recovery Services Agent (version 2.0.9202.0 ou ultérieure)
Remarque : vous pouvez case activée la version du fournisseur installée dans l’élément Programmes et fonctionnalités de Panneau de configuration.
Améliorations apportées et problèmes résolus dans cette mise à jour
Une fois cette mise à jour installée, les problèmes suivants sont résolus et les améliorations suivantes sont incluses.
Service Mobilité
Prise en charge du système d’exploitation Linux
-
Azure vers Azure
-
Rocky Linux 8.7
-
Rocky Linux 9.0
-
Rocky Linux 9.1
-
SUSE Linux Enterprise Server 15 SP5
-
-
VMware/Physique modernisé vers Azure
-
Rocky Linux 8.7
-
Rocky Linux 9.0
-
Rocky Linux 9.1
-
SUSE Linux Enterprise Server 15 SP5
-
Prise en charge du système d’exploitation Windows
-
Azure vers Azure
-
Windows 11
-
Problèmes résolus :
-
Ajout d’un case activée qui garantit qu’une resynchronisation n’est pas déclenchée si l’ordinateur protégé s’arrêtait correctement, ce qui évite d’autres opérations de transfert de données.
-
Correction d’un problème pour les machines virtuelles Oracle Linux 7.9 VMware, où le pilote ASR n’était pas en mesure d’identifier quelques fichiers et provoquait le blocage du noyau.
-
Modification des messages d’erreur où les métriques d’attrition s’affichaient avec des unités incorrectes.
-
Résolution d’un bogue dans lequel les machines RHEL protégées où Site Recovery pilote peuvent provoquer un plantage en raison de pics de mémoire.
-
Correction d’un problème où l’opération de reprotéger une machine Debian 11 échouait en raison d’étapes de nettoyage manquantes.
-
Correction d’un problème où l’installation du service mobilité échouait sur les machines CentOS 7.8, en raison d’une opération non compatible avec les noyaux antérieurs à 3.1.x.
-
Correction d’un problème où l’opération initiale de réplication/resynchronisation ne progressait pas pendant la reprotection d’une machine virtuelle Windows VMware, car un processus du service Mobilité ne s’arrêtait pas.
Appliance de réplication Microsoft Azure Site Recovery
Mises à jour :
|
Composant |
Version |
|---|---|
|
Serveur de découverte physique |
|
|
Serveur de découverte |
|
|
fournisseur Site Recovery |
|
|
Gestionnaire de configuration de l’appliance |
|
|
Serveur proxy |
|
|
Service de réplication |
|
|
Serveur de reprotection |
|
|
Agent d’installation push |
|
|
Agent Recovery Services |
|
|
Serveur de traitement |
Mise à jour de vos composants Azure Site Recovery locaux
Entre un site VMM local et Azure
-
Téléchargez le correctif cumulatif pour le fournisseur de Site Recovery Microsoft Azure.
-
Installez le correctif cumulatif sur le serveur VMM local.
-
Installez la dernière version de Microsoft Azure Recovery Services Agent sur tous les hôtes Hyper-V.
Remarque Si votre VMM est un VMM hautement disponible (VMM en cluster), veillez à installer la mise à niveau sur tous les nœuds du cluster où le service VMM est installé.
Entre un site Hyper-V local et Azure
-
Téléchargez le correctif cumulatif pour le fournisseur de Site Recovery Microsoft Azure.
-
Installez le fournisseur sur chaque nœud des serveurs Hyper-V que vous avez inscrits dans Azure Site Recovery.
Remarque Si votre hyper-V est un serveur Hyper-V en cluster hôte, veillez à installer la mise à niveau sur tous les nœuds du cluster.
Entre un site VMware local ou un site physique vers Azure (expérience modernisée)
-
Vérifiez que votre Appliance de gestion locale est à jour en accédant au gestionnaire de configuration de l’appliance. Si ce n’est pas le cas, téléchargez la dernière version pour les composants qui se trouvent derrière la dernière version.
-
Accédez à la Portail Azure, puis à la page Éléments protégés > Éléments répliqués. Sélectionnez une machine virtuelle sur cette page. Sélectionnez le bouton Mettre à jour l’agent qui s’affiche en bas de la page pour chaque machine virtuelle. Cela met à jour l’agent du service Mobilité sur toutes les machines virtuelles protégées.
Remarque : Un redémarrage est recommandé après chaque mise à niveau de l’agent Mobility pour s’assurer que toutes les dernières modifications sont chargées sur l’ordinateur source. Ce n’est pas obligatoire. Toutefois, un redémarrage est obligatoire si la différence entre les versions de l’agent du dernier redémarrage et la version cible est supérieure à quatre (4) dans la dernière décimale. Pour obtenir une explication détaillée, consultez le tableau suivant.
|
Version de l’agent lors du dernier redémarrage |
Mise à niveau vers |
Un redémarrage est-il obligatoire ? |
|---|---|---|
|
9.25 |
9.27 |
Non obligatoire |
|
9.25 |
9.28 |
Non obligatoire |
|
9.25 |
9.29 |
Non obligatoire |
|
9.25 |
9.30 |
Obligatoire |
