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

2025-04-25

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 à 1 023 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% de synchronisation et après un certain temps, l'intégrité de la réplication devient critique avec l'erreur AzStackToAzStackSourceAgentDiskSourceAgentSlowResyncProgressOnPremToAzure. L’erreur se produit car lors de la réplication, Site Recovery tente de redimensionner le disque initial à 1 024 Go et d’y écrire. Cette opération échoue, car Azure Stack Hub ne prend pas en charge 1 024 Disques.
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 1 022 Go ou moins), à l’attacher à votre machine virtuelle source, copier les données du disque de 1 023 Go vers le nouveau disque, puis supprimer le disque de 1 023 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 1 022 Go, vous pouvez activer la protection à l’aide d’Azure Site Recovery.

Reprotection : emplacements de disque de données disponibles sur l'appareil

Assurez-vous que la machine virtuelle de l’appliance dispose de suffisamment d’emplacements pour les disques de données, car les disques de réplica utilisés pour la reprotection sont attachés à l’appliance.
Le nombre initial autorisé de disques reprotégés 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 seul disque de données.
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 reprotégé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 tailles de machines virtuelles (VM SKU) élevées pour l'appliance.
Si vous essayez de reprotéger une machine virtuelle, mais qu'il n'y a pas suffisamment d'emplacements sur l'appareil pour contenir les disques de réplication, le message d'erreur Une erreur interne s'est produite s'affiche. Vous pouvez vérifier le nombre de disques de données actuellement présents 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 Applications et Journaux des services :

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

Version du noyau de machine virtuelle Linux non prise en charge

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 la matrice de prise en charge d’Azure vers Azure.
Avec une version de noyau prise en charge, le basculement, qui entraîne le redémarrage de la machine virtuelle, peut provoquer la mise à jour de la machine virtuelle défaillante vers une version de noyau plus récente qui peut ne pas être prise en charge. Pour éviter une mise à jour due au redémarrage d'une machine virtuelle basculante, exécutez la commande sudo apt-mark hold linux-image-azure linux-headers-azure afin que la mise à jour de la version du noyau puisse avoir lieu.
Pour obtenir une version de noyau non prise en charge, recherchez 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.
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.
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 vérifier la version sur le portail pour confirmer :

La resynchronisation manuelle de Reprotect n'est pas encore prise en charge

Une fois la tâche de reprotection 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 / Astuce
  
  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 vides ou nuls, la reprotection peut échouer. Consultez 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 du service de la mobilité

Lors de la réplication de plusieurs machines virtuelles, il se peut que l'erreur Protected item health changed to Warning s'affiche dans les travaux de 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 / Astuce

Vous pouvez vérifier l’état de la machine virtuelle correspondante pour vous assurer qu’elle est saine.

La suppression de la machine virtuelle de l'appliance (source) bloque la suppression de l'espace de stockage (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 à supprimer la protection de tous les éléments du coffre-fort avant de supprimer la machine virtuelle. Cela permet à l'espace de stockage de terminer le nettoyage des ressources sur l'appliance (côté source). Une fois les éléments protégés supprimés, vous pouvez supprimer l'espace de stockage et la machine virtuelle de l'appliance.

Partager via