Problèmes connus - Azure Site Recovery sur Azure Stack Hub

Cet article décrit les problèmes connus liés à Azure Site Recovery sur Azure Stack Hub. Utilisez les sections suivantes pour plus d’informations sur les problèmes et limitations connus actuels dans Azure Site Recovery sur Azure Stack Hub.

La taille maximale du disque prise en charge est de 1 022 Go

Lorsque vous protégez une machine virtuelle, Azure Site Recovery doit ajouter 1 Go de données supplémentaires à un disque existant. Étant donné qu’Azure Stack Hub a une limitation matérielle pour la taille maximale d’un disque à 1023 Go, la taille maximale d’un disque protégé par Site Recovery doit être égale ou inférieure à 1022.

Lorsque vous essayez de protéger une machine virtuelle avec un disque de 1023 Go, le comportement suivant se produit :

• L’activation de la protection réussit en tant que disque initial de seulement 1 Go est créé et prêt à être utilisé. Il n’y a aucune erreur à cette étape.

• La réplication est bloquée à xx % synchronisée et après un certain temps, l’intégrité de la réplication devient critique avec l’erreur AzStackToAzSourceAgentDiskSourceAgentSlowResyncProgressOnPremToAzure. L’erreur se produit car pendant la réplication, Site Recovery tente de redimensionner le disque initial à 1024 Go et d’y écrire. Cette opération échoue, car Azure Stack Hub ne prend pas en charge les disques de 1024 Go.

  

• Le disque initial créé pour ce disque (dans l’abonnement cible) est toujours de taille de 1 Go, et le journal d’activité affiche quelques échecs de disque d’écriture avec le message d’erreur « 1024 » du paramètre « disk.diskSizeGb » est hors limites. La valeur '1024' doit être comprise entre '1' et '1023' inclus.

  

La solution de contournement actuelle pour ce problème consiste à créer un disque (de 1022 Go ou moins), à l’attacher à votre machine virtuelle source, copier les données du disque de 1023 Go vers le nouveau disque, puis supprimer le disque de 1023 Go de la machine virtuelle source. Une fois cette procédure effectuée et que la machine virtuelle a tous les disques plus petits ou 1022 Go, vous pouvez activer la protection à l’aide d’Azure Site Recovery.

Reprotection : emplacements de disque de données disponibles sur l’appliance

1. Vérifiez que la machine virtuelle de l’appliance dispose de suffisamment d’emplacements de disque de données, car les disques de réplica pour la reprotection sont attachés à l’appliance.

2. Le nombre initial autorisé de disques en même temps est de 31. La taille par défaut de l’appliance créée à partir de l’élément de la Place de marché est Standard_DS4_v2, qui prend en charge jusqu’à 32 disques de données et l’appliance elle-même utilise un disque de données.

3. Si la somme des machines virtuelles protégées est supérieure à 31, effectuez l’une des actions suivantes :

   • Fractionnez les machines virtuelles qui nécessitent une reprotection en groupes plus petits pour vous assurer que le nombre de disques reprotectionnés en même temps ne dépasse pas le nombre maximal de disques de données pris en charge par l’appliance.
   • Augmentez la taille de la machine virtuelle de l’appliance Azure Site Recovery.

   Remarque

   Nous ne testons pas et ne validons pas les références SKU de machine virtuelle volumineuse pour la machine virtuelle de l’appliance.

4. Si vous essayez de reprotéger une machine virtuelle, mais qu’il n’y a pas suffisamment d’emplacements sur l’appliance pour contenir les disques de réplication, le message d’erreur Une erreur interne s’est produite. Vous pouvez case activée le nombre de disques de données actuellement sur l’appliance ou vous connecter à l’appliance, accéder à l’Observateur d’événements et ouvrir les journaux d’activité d’Azure Site Recovery sous Journaux des applications et services :

   

   

   Recherchez l’avertissement le plus récent pour identifier le problème.

Version du noyau de machine virtuelle Linux non prise en charge

1. Vérifiez votre version du noyau en exécutant la commande uname -r.

   

   Pour plus d’informations sur les versions de noyau Linux prises en charge, consultez Azure pour support Azure matrice.

2. Avec une version de noyau prise en charge, le basculement, qui entraîne le redémarrage de la machine virtuelle, peut entraîner la mise à jour de la machine virtuelle basculée vers une version plus récente du noyau qui peut ne pas être prise en charge. Pour éviter une mise à jour en raison d’un redémarrage d’une machine virtuelle de basculement, exécutez la commande sudo apt-mark hold linux-image-azure linux-headers-azure pour que la mise à jour de la version du noyau puisse continuer.

3. Pour une version de noyau non prise en charge, case activée pour une version antérieure du noyau sur laquelle vous pouvez effectuer la restauration, en exécutant la commande appropriée pour votre machine virtuelle :

   • Debian/Ubuntu : dpkg --list | grep linux-image

   L’image suivante montre un exemple dans une machine virtuelle Ubuntu sur la version 5.4.0-1103-azure, qui n’est pas prise en charge. Une fois la commande exécutée, vous pouvez voir une version prise en charge, 5.4.0-1077-azure, qui est déjà installée sur la machine virtuelle. Avec ces informations, vous pouvez revenir à la version prise en charge.

   

4. Revenez à une version de noyau prise en charge en procédant comme suit :

   1. Tout d’abord, effectuez une copie de /etc/default/grub en cas d’erreur ; par exemple, sudo cp /etc/default/grub /etc/default/grub.bak.

   2. Ensuite, modifiez /etc/default/grub pour définir GRUB_DEFAULT sur la version précédente que vous souhaitez utiliser. Vous pouvez avoir quelque chose de similaire à GRUB_DEFAULT="Options avancées pour Ubuntu Ubuntu>, avec Linux 5.4.0-1077-azure ».

      

   3. Sélectionnez Enregistrer pour enregistrer le fichier, puis sélectionnez Quitter.

   4. Exécutez sudo update-grub pour mettre à jour le grub.

   5. Enfin, redémarrez la machine virtuelle et passez à la restauration vers une version du noyau prise en charge.

5. Si vous n’avez pas d’ancienne version du noyau vers laquelle vous pouvez restaurer, attendez la mise à jour de l’agent de mobilité pour que votre noyau puisse être pris en charge. La mise à jour est effectuée automatiquement, si elle est prête, et vous pouvez case activée la version sur le portail pour confirmer :

   

La resynchronisation manuelle de la resynchronisation manuelle n’est pas encore prise en charge

Une fois la tâche de reprotéger terminée, la réplication est démarrée en séquence. Pendant la réplication, il peut y avoir des cas qui nécessitent une resynchronisation, ce qui signifie qu’une nouvelle réplication initiale est déclenchée pour synchroniser toutes les modifications.

Il existe deux types de resynchronisation :

• Resynchronisation automatique. Nécessite aucune action de l’utilisateur et est effectuée automatiquement. Les utilisateurs peuvent voir certains événements affichés sur le portail :

  

• Resynchronisation manuelle. Nécessite l’action de l’utilisateur pour déclencher la resynchronisation manuelle et est nécessaire dans les instances suivantes :

  • Le compte de stockage choisi pour la reprotection est manquant.

  • Le disque de réplication sur l’appliance est manquant.

  • L’écriture de réplication dépasse la capacité du disque de réplication sur l’appliance.

    Conseil

    Vous pouvez également trouver les raisons de resynchronisation manuelle dans le panneau des événements pour vous aider à déterminer si une resynchronisation manuelle est requise.

Problèmes connus dans l’automatisation PowerShell

• Si vous laissez $failbackPolicyName et $failbackExtensionName videz ou null, la reprotéger peut échouer. Regardez les exemples suivants :

  

  

• Spécifiez toujours le $failbackPolicyName et $failbackExtensionName, comme indiqué dans l’exemple suivant :

  $failbackPolicyName = "failback-default-replication-policy"
  $failbackExtensionName = "default-failback-extension"
  $parameters = @{
      "properties" = @{
          "customProperties" = @{
              "instanceType" = "AzStackToAzStackFailback"
              "applianceId" = $applianceId
              "logStorageAccountId" = $LogStorageAccount.Id
              "policyName" = $failbackPolicyName
              "replicationExtensionName" = $failbackExtensionName
          }
      }
  }
  $result = Invoke-AzureRmResourceAction -Action "reprotect" ` -ResourceId $protectedItemId ` -Force -Parameters $parameters 
  

Avertissement de l’agent service Mobility

Lors de la réplication de plusieurs machines virtuelles, l’intégrité de l’élément protégé peut être modifiée en erreur Avertissement dans les travaux Site Recovery.

Ce message d’erreur ne doit être qu’un avertissement et n’est pas un problème bloquant pour les processus de réplication ou de basculement réels.

Conseil

Vous pouvez case activée l’état de la machine virtuelle respective pour vous assurer qu’elle est saine.

La suppression de la machine virtuelle de l’appliance (source) bloque la suppression du coffre (cible)

Pour supprimer le coffre Azure Site Recovery sur la cible, vous devez d’abord supprimer toutes les machines virtuelles protégées. Si vous supprimez d’abord la machine virtuelle de l’appliance, le coffre Site Recovery bloque la suppression des ressources protégées et tente de supprimer le coffre lui-même échoue également. La suppression du groupe de ressources échoue également et la seule façon de supprimer le coffre consiste à supprimer l’abonnement utilisateur Azure Stack Hub dans lequel le coffre est créé.

Pour éviter ce problème, veillez d’abord à supprimer la protection de tous les éléments du coffre, avant de supprimer la machine virtuelle de l’appliance. Cela permet au coffre de terminer la ressource propre up sur l’appliance (côté source). Une fois les éléments protégés supprimés, vous pouvez supprimer le coffre et supprimer la machine virtuelle de l’appliance.

Étapes suivantes

• Azure Site Recovery sur Azure Stack Hub
• Planification de la capacité Azure Site Recovery sur Azure Stack Hub