Partager via

Résoudre les problèmes de réplication pour les serveurs physiques et machines virtuelles VMware

  • Article

Cet article décrit certains problèmes courants et erreurs spécifiques que vous pouvez rencontrer lorsque vous répliquez des machines virtuelles et serveurs physiques VMware locaux sur Azure avec Site Recovery.

Étape 1 : Surveiller l’intégrité du serveur de processus

Site Recovery utilise le serveur de processus pour recevoir et optimiser les données répliquées, ainsi que pour les envoyer à Azure.

Nous vous recommandons d’analyser l’intégrité des serveurs de processus dans le portail, pour vous assurer qu’ils sont connectés et fonctionnent correctement, et que la réplication des machines sources qui sont associées au serveur de processus progresse.

  • En savoir plus sur la surveillance des serveurs de processus
  • [Passer en revue les meilleures pratiques]. (vmware-physical-azure-troubleshoot-process-server.md#best-practices-for-process-server-deployment)
  • Détecter un problème d’intégrité du serveur de processus

Étape 2 : Détecter les problèmes de connectivité et de réplication

Les problèmes de connectivité entre le serveur source et le serveur de processus ou entre ce dernier et Azure provoquent souvent des défaillances de réplication initiales et en cours.

Pour résoudre ces difficultés, détectez les problèmes de connectivité et de réplication.

Étape 3 : Détecter les problèmes de machines sources qui ne sont pas disponibles pour la réplication

Lorsque vous tentez de sélectionner la machine source pour activer la réplication avec Site Recovery, il se peut que cette machine ne soit pas disponible pour l’une des raisons suivantes :

  • Deux machines virtuelles avec le même UUID d’instance : si deux machines virtuelles sous vCenter ont le même UUID d’instance, la première machine découverte par le serveur de configuration s’affiche dans le portail Azure. Pour résoudre ce problème, assurez-vous que deux machines virtuelles n’ont pas le même UUID d’instance. Ce scénario est courant dans les cas où une machine virtuelle de sauvegarde devient active et est connectée à nos enregistrements de découverte. Consultez Azure Site Recovery, WMware vers Azure : comment nettoyer les entrées en double ou périmées pour résoudre le problème.
  • Informations d’identification de l’utilisateur vCenter incorrectes : Vérifiez que vous avez ajouté les informations d’identification de vCenter correctes lors de la configuration du serveur de configuration en utilisant le modèle OVF ou une configuration unifiée. Pour vérifier les informations d’identification que vous avez ajoutées pendant la configuration, voir Modifier les informations d’identification pour la découverte automatique.
  • Privilèges insuffisants pour vCenter : Si les autorisations fournies pour accéder à vCenter ne sont pas les autorisations requises, la découverte des machines virtuelles pourrait échouer. Assurez-vous que les autorisations décrites dans Préparer un compte pour la découverte automatique sont ajoutées au compte d’utilisateur de vCenter.
  • Serveurs d’administration Azure Site Recovery : si la machine virtuelle est utilisée comme serveur d’administration sous un ou plusieurs des rôles suivants (serveur de configuration, serveur de processus avec scale-out, serveur cible maître), vous ne pouvez pas choisir la machine virtuelle à partir du portail. Les serveurs d’administration ne peuvent pas être répliqués.
  • Machine virtuelle déjà protégée/basculée par le biais des services Azure Site Recovery : si la machine virtuelle est déjà protégée ou basculée par le biais de Site Recovery, vous ne pouvez pas la sélectionner à des fins de protection dans le portail. Vérifiez que la machine virtuelle que vous recherchez sur le portail n’est pas déjà protégée par un autre utilisateur ou sous un autre abonnement.
  • vCenter non connecté : vérifiez si vCenter est dans un état connecté. Pour cela, accédez au coffre Recovery Services > Infrastructure Site Recovery > Serveurs de configuration > cliquez sur un serveur de configuration > un panneau s’ouvre à droite avec des détails sur les serveurs associés. Vérifiez si vCenter est connecté. S’il présente l’état « Non connecté », résolvez le problème, puis actualisez le serveur de configuration dans le portail. Après cela, la machine virtuelle n’est pas répertoriée dans le portail.
  • ESXi hors tension : si l’hôte ESXi sous lequel la machine virtuelle réside est dans un état hors tension, la machine virtuelle n’est pas répertoriée ou ne peut pas être sélectionnée dans le Portail Azure. Mettez l’hôte ESXi sous tension, puis actualisez le serveur de configuration dans le portail. Après cela, la machine virtuelle est répertoriée dans le portail.
  • Redémarrage en attente : si un redémarrage est en attente sur la machine virtuelle, vous ne pouvez pas sélectionner la machine dans le portail Azure. Veillez à effectuer les activités de redémarrage en attente, puis actualisez le serveur de configuration. Après cela, la machine virtuelle est répertoriée dans le portail.
  • IP introuvable ou la machine n’a pas d’adresse IP : si la machine virtuelle n’est pas associée à une adresse IP valide, vous ne pouvez pas sélectionner la machine dans le portail Azure. Veillez à attribuer une adresse IP valide à la machine virtuelle, puis actualisez le serveur de configuration. Cela peut également se produire si la machine n’est pas associée à une adresse IP valide associée à l’une de ses cartes réseau. Affectez une adresse IP valide à toutes les cartes réseau ou supprimez celle dont l’adresse IP est manquante. Après cela, la machine virtuelle est répertoriée dans le portail.

Détecter les problèmes de machines virtuelles protégées qui apparaissent en grisé dans le portail

Les machines virtuelles répliquées sous Azure Site Recovery sont indisponibles sur le portail Azure s’il existe des entrées en double dans le système. Découvrez-en plus sur la suppression des entrées obsolètes et la résolution du problème.

Une autre raison peut être que la machine a été clonée. Quand des machines sont déplacées d’un hyperviseur vers un autre, et si l’ID du BIOS change, l’agent de mobilité bloque la réplication. La réplication des machines clonées n’est pas prise en charge par le service Site Recovery.

Aucun point de récupération cohérent avec les incidents disponible pour la machine virtuelle pendant les « XXX » dernières minutes

Voici une liste des problèmes les plus courants :

Problèmes de réplication initiale [erreur 78169]

Après vous être assuré de l’absence de problèmes de connectivité, de bande passante ou de synchronisation de l’heure, vérifiez les points suivants :

  • Aucun antivirus ne bloque Azure Site Recovery. Apprenez-en plus sur les exclusions de dossier requises pour Azure Site Recovery.

Machines sources à taux d’évolution élevé [erreur 78188]

Causes possibles :

  • Le taux de modification des données (octets écrits/s) sur les disques répertoriés de la machine virtuelle dépasse les limites prises en charge par Azure Site Recovery pour le type de compte de stockage cible de réplication.
  • L’attrition connaît un pic soudain à cause duquel un important volume de données est en attente de chargement.

Résolution du problème :

  • Assurez-vous que le type de compte de stockage cible (Standard ou Premium) est approvisionné conformément aux exigences d’attrition au niveau de la source.

  • Si vous effectuez déjà une réplication vers un disque managé Premium (de type asrseeddisk), vérifiez que la taille du disque prend en charge le taux d’évolution observé, conformément aux limites Site Recovery. Vous pouvez augmenter la taille du disque de type asrseeddisk si nécessaire. Procédez comme suit :

    • Accédez au panneau Disques de la machine répliquée concernée et copiez le nom du disque de réplica.
    • Accédez à ce disque managé de réplica.
    • Vous pouvez voir une bannière dans le panneau Vue d’ensemble indiquant qu’une URL de signature d’accès partagé a été générée. Cliquez sur cette bannière et annulez l’exportation. Ignorez cette étape si vous ne voyez pas la bannière.
    • Dès que l’URL de la signature d’accès partagé est révoquée, accédez au panneau Configuration du disque managé et augmentez la taille de manière à ce qu’Azure Site Recovery prenne en charge l’attrition observée sur le disque source.

  • Si l’attrition observée est temporaire, attendez quelques heures que le chargement des données en attente rattrape son retard et crée des points de récupération.

  • Si le disque contient des données non critiques, comme des journaux temporaires ou des données de test, déplacez ces données ou excluez l’intégralité de ce disque de la réplication.

  • Si le problème persiste, utilisez le Planificateur de déploiement Site Recovery pour faciliter la planification de la réplication.

Machines sources dépourvues de pulsation [erreur 78174]

Cette erreur se produit lorsque l’agent Mobilité d’Azure Site Recovery sur la machine source communique avec le serveur de configuration (CS).

Pour résoudre ce problème, procédez comme suit pour vérifier la connectivité réseau entre la machine virtuelle source et le serveur de configuration :

  1. Vérifiez que la machine source est en cours d’exécution.

  2. Connectez-vous à la machine source à l’aide d’un compte disposant de privilèges d’administrateur.

  3. Vérifiez que les services ci-après sont en cours d’exécution et, dans le cas contraire, redémarrez-les :

    • Svagents (InMage Scout VX Agent)
    • Service d’application InMage Scout

  4. Sur la machine source, examinez les journaux à l’emplacement ci-après pour obtenir les détails de l’erreur :

    C:\Program Files (X86)\Microsoft Azure Site Recovery\agent\svagents*.log

Serveur de processus dépourvu de pulsation [erreur 806]

Si le serveur de traitement n’affiche aucune pulsation, vérifiez les éléments suivants :

  1. La machine virtuelle du serveur de traitement est opérationnelle

  2. Consultez les journaux ci-après sur le serveur de traitement pour obtenir les détails de l’erreur :

    C:\ProgramData\ASR\home\svsystems\eventmanager*.log
    et
    C:\ProgramData\ASR\home\svsystems\monitor_protection*.log

Serveur cible maître dépourvu de pulsation [erreur 78022]

Cette erreur se produit lorsque l’agent Mobilité d’Azure Site Recovery sur la cible maître ne communique pas avec le serveur de configuration.

Pour résoudre ce problème, vérifiez l’état du service en procédant comme suit :

  1. Vérifiez que la machine virtuelle cible maître est en cours d’exécution.

  2. Connectez-vous à la machine virtuelle cible maître à l’aide d’un compte disposant de privilèges d’administrateur.

    • Vérifiez que le service svagents est en cours d’exécution. S’il l’est, redémarrez le service

    • Vérifiez les journaux à l’emplacement ci-après pour obtenir les détails de l’erreur :

      C:\Program Files (X86)\Microsoft Azure Site Recovery\agent\svagents*.log

  3. Pour inscrire le serveur cible maître auprès du serveur de configuration, accédez au dossier %PROGRAMDATA%\ASR\Agent, puis exécutez ce qui suit dans l’invite de commandes :

    cmd
cdpcli.exe --registermt

net stop obengine

net start obengine

exit

Impossible d’activer la protection de la machine virtuelle [erreur 78253]

Cette erreur peut se produire si une stratégie de réplication n’a pas été associée correctement au serveur de configuration. Cela peut également se produire si la stratégie associée au serveur de configuration n’est pas valide.

Pour confirmer la cause de cette erreur, accédez au coffre de récupération > gérer l’Infrastructure Site Recovery, puis affichez les stratégies de réplication des machines physiques et VMware pour vérifier l’état des stratégies configurées.

Pour résoudre le problème, vous pouvez associer la stratégie au serveur de configuration en cours d’utilisation ou créer une stratégie de réplication et l’associer. Si la stratégie n’est pas valide, vous pouvez la dissocier et la supprimer.

ID d’erreur 78144 : aucun point de récupération cohérent avec l’application disponible pour la machine virtuelle pendant les « XXX » dernières minutes

Des améliorations ont été apportées aux versions 9.23 et 9.27 de l’agent de mobilité pour gérer les comportements d’échec d’installation de VSS. Assurez-vous de disposer des dernières versions pour obtenir les meilleurs conseils en matière de résolution des défaillances VSS.

Certains des problèmes les plus courants sont répertoriés ci-dessous :

Cause 1 : Problème connu dans SQL Server 2008/2008 R2

Procédure de résolution : il existe un problème connu dans SQL Server 2008/2008 R2. Référez-vous à cet article de la base de connaissances : Azure Site Recovery Agent or other non-component VSS backup fails for a server hosting SQL Server 2008 R2 (L’agent Azure Site Recovery ou une autre sauvegarde VSS sans composant échoue sur un serveur hébergeant une instance SQL Server 2008 R2)

Cause 2 : Les tâches Azure Site Recovery échouent lorsque des serveurs hébergent les instances de n’importe quelle version de SQL Server avec des bases de données AUTO_CLOSE

Procédure de résolution : reportez-vous à cet article de la base de connaissances

Procédure de résolution : référez-vous à cet article de la base de connaissances

Cause 3 : Problème connu dans SQL Server 2016 et 2017

Procédure de résolution : reportez-vous à cet article de la base de connaissances

Cause 4 : Cohérence des applications non activée sur les serveurs Linux

Procédure de résolution : Azure Site Recovery pour le système d’exploitation Linux prend en charge les scripts personnalisés des applications à des fins de cohérence. Le script personnalisé avec options pré et post-script sera utilisé par l’agent Mobilité Azure Site Recovery pour la cohérence des applications. Voici les étapes pour l’activer.

Pour mieux résoudre le problème, vérifiez les fichiers sur la machine source pour obtenir le code d’erreur exact de l’échec :

C:\Program Files (x86)\Microsoft Azure Site Recovery\agent\Application Data\ApplicationPolicyLogs\vacp.log

Comment localiser les erreurs dans le fichier ? Recherchez la chaîne « vacpError » en ouvrant le fichier vacp.log dans un éditeur

Ex: vacpError:220#Following disks are in FilteringStopped state [\\.\PHYSICALDRIVE1=5, ]#220|^|224#FAILED: CheckWriterStatus().#2147754994|^|226#FAILED to revoke tags.FAILED: CheckWriterStatus().#2147754994|^|

Dans l’exemple précédent, 2147754994 est le code d’erreur qui vous informe de l’échec, comme indiqué ci-dessous :

L’enregistreur VSS n’est pas installé - erreur 2147221164

Procédure de résolution : pour générer une balise de cohérence d’application, Azure Site Recovery utilise le service VSS (cliché instantané de volume) de Microsoft. Il installe un fournisseur VSS pour que l’opération prenne des clichés instantanés de la cohérence d’application. Ce fournisseur VSS est installé en tant que service. Si le service de fournisseur VSS n’est pas installé, la création de clichés instantanés de la cohérence d’application échoue et l’ID d’erreur 0x80040154 « Classe non inscrite » s’affiche.

Consultez l’article relatif au dépannage de l’installation de l’enregistreur VSS

L’enregistreur VSS est désactivé - erreur 2147943458

Procédure de résolution : pour générer une balise de cohérence d’application, Azure Site Recovery utilise le service VSS (cliché instantané de volume) de Microsoft. Il installe un fournisseur VSS pour que l’opération prenne des clichés instantanés de la cohérence d’application. Ce fournisseur VSS est installé en tant que service. Si le service de fournisseur VSS est désactivé, la création de clichés instantanés de la cohérence d’application échoue et l’ID d’erreur « Le service spécifié est désactivé et ne peut pas être démarré (0x80070422) » s’affiche.

  • Si le service VSS est désactivé :
    • Vérifiez que le type de démarrage du service fournisseur VSS est défini sur Automatique.
    • Redémarrez les services suivants :
      • Service VSS
      • Fournisseur VSS d’Azure Site Recovery
      • Service VDS (Virtual Disk Service)

VSS PROVIDER NOT_REGISTERED - erreur 2147754756

Procédure de résolution : pour générer une balise de cohérence d’application, Azure Site Recovery utilise le service VSS (cliché instantané de volume) de Microsoft. Vérifiez si le service de fournisseur VSS d’Azure Site Recovery est installé.

  • Réessayez d’installer le fournisseur à l’aide des commandes suivantes :
  • Désinstallez le fournisseur existant : C:\Program Files (x86)\Microsoft Azure Site Recovery\agent\InMageVSSProvider_Uninstall.cmd
  • Réinstallez : C:\Program Files (x86)\Microsoft Azure Site Recovery\agent\InMageVSSProvider_Install.cmd

Vérifiez que le type de démarrage du service fournisseur VSS est défini sur Automatique. - Redémarrez les services suivants : - Service VSS - Fournisseur VSS d’Azure Site Recovery - Service VDS

ID d’erreur 95001 : Autorisations insuffisantes

Cette erreur se produit lorsque vous tentez d’activer la réplication alors que les dossiers d’application ne disposent pas d’autorisations suffisantes.

Procédure de résolution : pour résoudre ce problème, assurez-vous que l’utilisateur IUSR détient le rôle de propriétaire pour tous les dossiers suivants :

  • C\ProgramData\Microsoft Azure Site Recovery\private
  • Répertoire d’installation. Par exemple, si le répertoire d’installation est le lecteur F, fournissez les autorisations nécessaires pour :
    • F:\Program Files (x86)\Microsoft Azure Site Recovery\home\svsystems
  • Dossier \pushinstallsvc dans le répertoire d’installation. Par exemple, si le répertoire d’installation est le lecteur F, fournissez les autorisations nécessaires pour :
    • F:\Program Files (x86)\Microsoft Azure Site Recovery\home\svsystems\pushinstallsvc
  • Dossier \etc dans le répertoire d’installation. Par exemple, si le répertoire d’installation est le lecteur F, fournissez les autorisations nécessaires pour :
    • F:\Program Files (x86)\Microsoft Azure Site Recovery\home\svsystems\etc
  • C:\Temp
  • C:\thirdparty\php5nts
  • Tous les éléments sous le chemin suivant :
    • C:\thirdparty\rrdtool-1.2.15-win32-perl58\rrdtool\Release*

Gérer les changements d’heure sur les serveurs répliqués et résoudre les problèmes associés

Cette erreur se produit quand l’heure de la machine source est avancée, puis retourne rapidement à l’heure réelle. Vous ne remarquerez peut-être pas le changement car l’heure est corrigée rapidement.

Procédure de résolution : pour résoudre ce problème, attendez que l’heure système croise l’heure future décalée. Une autre option consiste à désactiver et à réactiver la réplication, ce qui n’est possible que pour la réplication vers l’avant (données répliquées d’un emplacement local vers Azure) et n’est pas applicable à la réplication inversée (données répliquées d’Azure vers un emplacement local).

Étapes suivantes

Si vous avez besoin d’aide supplémentaire, publiez votre question sur la page de questions Microsoft Q&A sur Azure Site Recovery. Nous avons une communauté active et l’un de nos ingénieurs peut vous aider.