Partager via

Résoudre les problèmes de réplication dans le cadre de la reprise d’activité d’une machine virtuelle Azure

  • Article

Cet article décrit les problèmes courants rencontrés dans Azure Site Recovery quand vous répliquez et récupérez des machines virtuelles Azure d’une région vers une autre. Il explique également comment détecter les problèmes courants. Pour plus d’informations sur les configurations prises en charge, consultez la matrice de prise en charge pour la réplication des machines virtuelles Azure.

Azure Site Recovery réplique des données de manière cohérente de la région source vers la région de récupération d’urgence. Il crée également un point de récupération cohérent en cas d’incident toutes les 5 minutes. Si Site Recovery ne peut pas créer de points de récupération pendant 60 minutes, il vous en informe et vous communique les informations suivantes :

Error message: "No crash consistent recovery point available for the VM in the last 60 minutes."

Error ID: 153007

Les sections suivantes décrivent les causes et solutions.

Taux élevé de changement de données sur la machine virtuelle source

Azure Site Recovery crée un événement si le taux de modification des données sur la machine virtuelle source dépasse les limites prises en charge. Pour voir si le problème est dû à un taux d’évolution élevé, accédez à Éléments répliqués>Machine virtuelle>Événements – dernières 72 heures. Vous devez normalement voir l’événement Taux de changement des données au-dessus des limites prises en charge :

Page Azure Site Recovery qui affiche un taux de changement de données trop élevé.

Si vous sélectionnez l’événement, vous pouvez consulter les informations relatives au disque :

Limites Azure Site Recovery

Le tableau suivant présente les limites d’Azure Site Recovery. Ces limites sont basées sur nos tests, mais ne peuvent pas couvrir toutes les combinaisons possibles d’entrée/sortie (E/S) d’application. Les résultats réels varient en fonction de la combinaison d’E/S de votre application.

Deux limites sont à prendre en compte : le taux d’évolution des données par disque et le taux d’évolution des données par machine virtuelle. Passez en revue les limites d’attritionici.

Solution

Les limites des taux de modification des données d’Azure Site Recovery dépendent du type de disque. Pour voir si ce problème est récurrent ou momentané, trouvez le taux de modification des données de la machine virtuelle concernée. Accédez à la machine virtuelle source, recherchez les mesures sous Surveillance et ajoutez les mesures comme illustré sur cette capture d'écran :

Page qui montre le processus en trois étapes permettant de déterminer le taux de changement des données.

  1. Sélectionnez Ajouter une mesure, puis ajoutez Octets écrits/s sur disque de système d’exploitation et Octets écrits/s sur disque de données.
  2. Surveiller le pic comme indiqué dans la capture d’écran.
  3. Affichez le total des opérations en écriture sur le disque du système d’exploitation et sur tous les disques de données combinés. Ces mesures peuvent ne pas vous renseigner sur le niveau par disque, mais indiquent le modèle total d'activité des données.

Un pic dans le taux de modification des données peut provenir d’une rafale occasionnelle de données. Si le taux de modification des données est supérieur à 10 Mo/s (pour Premium) ou 2 Mo/s (pour Standard) puis diminue, la réplication rattrapera son retard. Si l’évolution est la plupart du temps bien supérieure à la limite prise en charge, envisagez l’une des options suivantes :

  • Exclure le disque à l’origine d’un taux élevé de modification des données : Tout d’abord, désactivez la réplication. Vous pouvez ensuite exclure le disque à l’aide de PowerShell.

  • Modifiez la taille du disque du réplica. Cette option est utile uniquement si l’attrition des données de disque est inférieure à 20 Mo/s par disque, ou moins de 50 Mo/s par disque pour Attrition élevée. Par exemple, en supposant que vous n’avez pas choisi la prise en charge élevée de l’activité et que vous disposez d’une machine virtuelle avec un disque de 128 Gio et une activité de données comprise entre 8 Mo/s et 10 Mo/s. Maintenant que la taille du disque de 128 Gio a une limite d’attrition de 8 Mo/s, vous pouvez augmenter la taille du disque à 512 Gio pour prendre en charge une attrition plus élevée. Cette solution est possible seulement pour les machines qui utilisent des disques managés Premium. Effectuez les étapes suivantes :

    1. Accédez au panneau Disques de la machine répliquée concernée et copiez le nom du disque de réplica.
    2. Accédez à ce réplica du disque managé.
    3. Vous pouvez voir une bannière dans vue d’ensemble qui indique qu’une URL SAS 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.
    4. Dès que l’URL SAS est révoquée, accédez à Taille + performances pour le disque managé. Augmentez la taille afin que Site Recovery prenne en charge le taux d’évolution observé sur le disque source.

Important

La limite d’attrition prise en charge par Azure Site Recovery dépend de la taille du disque SSD Premium du réplica. Cette limite reste la même, même si vous modifiez le niveau de performances du disque réplica. Par exemple, si vous avez créé un disque de réplica SSD Premium d’une taille de disque de 128 Gio, son niveau de performances de base est P10. Si vous mettez à jour son niveau de performances sur P50 sans modifier la taille du disque, la limite d’attrition ne change pas.

Considérations relatives au changement de référence SKU/niveau de disque

Quand d’un changement de référence SKU ou de niveau de disque, toues les captures instantanées (signets) correspondant au disque sont créés par le fournisseur de ressources disque. Par conséquent, vous pouvez avoir des points de récupération où certaines captures instantanées sous-jacentes n’existent pas du côté du fournisseur de ressources disque.

Une fois que vous déclenchez un basculement avec un point de récupération créé avant le changement de référence SKU/niveau, le basculement éventuellement échoue avec une erreur BookmarkNotFound. Étant donné que le nettoyage de points de récupération est un travail planifié, vous pouvez voir ces points de récupération sur le portail, bien qu’ils soient supprimés au fil du temps.

Recommandation : attendez la publication du changement apporté au disque par un point de récupération avec une Date/Heure.

Problèmes de connectivité réseau

Latence du réseau pour le compte de stockage de cache

Site Recovery envoie les données répliquées vers le compte de stockage de cache. Vous pouvez rencontrer une latence du réseau si le chargement des données entre une machine virtuelle et le compte de stockage de cache est inférieur à 4 Mo en 3 secondes.

Pour vérifier s’il existe un problème lié à la latence, utilisez AzCopy. Vous pouvez utiliser cet utilitaire de ligne de commande pour charger des données de la machine virtuelle vers le compte de stockage de cache. Si la latence est élevée, vérifiez si vous utilisez une appliance virtuelle réseau (NVA) pour contrôler le trafic réseau sortant des machines virtuelles. L’appliance peut être limitée si tout le trafic de réplication passe par elle.

Nous vous recommandons de créer un point de terminaison de service réseau dans votre réseau virtuel pour « Stockage » afin que le trafic de réplication n’atteigne pas l’appliance virtuelle réseau. Pour plus d'informations, consultez Configuration des appliances virtuelles réseau.

Connectivité réseau

Pour que la réplication Site Recovery fonctionne, la machine virtuelle doit fournir une connectivité sortante vers des URL ou des plages d’adresses IP spécifiques. Votre machine virtuelle peut se trouver derrière un pare-feu ou utiliser des règles de groupe de sécurité réseau (NSG) pour contrôler la connectivité sortante. Si c’est le cas, vous pouvez rencontrer des problèmes. Pour vérifier que toutes les URL sont connectées, consultez Connectivité sortante pour les URL.

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

Voici quelques-uns des problèmes les plus courants.

Problème connu dans SQL Server 2008/2008 R2

Procédure de résolution : Il existe un problème connu avec SQL Server 2008/2008 R2. Référez-vous à l’article 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).

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 à l’article Non-component VSS backups such as Azure Site Recovery jobs fail on servers hosting SQL Server instances with AUTO_CLOSE DBs (Des sauvegardes VSS sans composant telles que des tâches Azure Site Recovery échouent sur des serveurs hébergeant des instances SQL Server avec des bases de données AUTO_CLOSE).

Problème connu dans SQL Server 2016 et 2017

Procédure de résolution : Consultez l’article Mise à jour cumulative 16 pour SQL Server 2017.

Vous utilisez la configuration des espaces de stockage direct Azure

Procédure de résolution : Azure Site Recovery ne peut pas créer de point de récupération cohérent avec l’application pour la configuration des espaces de stockage direct. Configurez la stratégie de réplication.

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 activer cela.

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

Pour localiser les erreurs, ouvrez le fichier vacp.log dans un éditeur de texte, puis recherchez la chaîne vacpError.

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 à la suite de cette phrase.

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. Site Recovery installe un fournisseur VSS pour que l’opération prenne des clichés instantanés de la cohérence d’application. Azure Site Recovery installe ce fournisseur VSS en tant que service. Si le fournisseur VSS n’est pas installé, la création de clichés instantanés de la cohérence d’application échoue. Elle indique l’ID d’erreur 0x80040154 -Classe non inscrite. Consultez l’article relatif à la résolution des problèmes lors de l’installation de l’enregistreur VSS.

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

Procédure de résolution : Pour générer la balise de cohérence d’application, Azure Site Recovery utilise le Service VSS. Site Recovery 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 activé, la création de clichés instantanés de la cohérence d’application échoue. Elle affiche l’erreur : Le service spécifié est désactivé et ne peut pas être démarré (0x80070422).

Si 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 Azure Site Recovery.
    • Service VDS.

VSS PROVIDER NOT_REGISTERED - erreur 2147754756

Procédure de résolution : Pour générer la balise de cohérence d’application, Azure Site Recovery utilise le Service VSS. Vérifiez si le service de fournisseur VSS d’Azure Site Recovery est installé.

Utilisez les commandes suivantes pour réinstaller le fournisseur VSS :

  1. Désinstallez le fournisseur existant :

    "C:\Program Files (x86)\Microsoft Azure Site Recovery\agent\InMageVSSProvider_Uninstall.cmd"

  2. Réinstallez le fournisseur VSS :

    "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 Azure Site Recovery.
  • Service VDS.

Étapes suivantes

Répliquer des machines virtuelles Azure dans une autre région Azure.