Problemas conhecidos - Azure Site Recovery no Azure Stack Hub

Artigo
10/30/2024

Este artigo descreve problemas conhecidos do Azure Site Recovery no Azure Stack Hub. Use as seções a seguir para obter detalhes sobre os problemas conhecidos atuais e as limitações no Azure Site Recovery no Azure Stack Hub.

O tamanho máximo do disco suportado é de 1022 GB

Quando você protege uma VM, o Azure Site Recovery precisa adicionar 1 GB adicional de dados a um disco existente. Como o Azure Stack Hub tem uma limitação rígida para o tamanho máximo de um disco em 1023 GB, o tamanho máximo de um disco protegido pela Recuperação de Site deve ser igual ou menor que 1022.

Quando você tenta proteger uma VM com um disco de 1023Gb, ocorre o seguinte comportamento:

A habilitação da proteção é bem-sucedida quando um disco de propagação de apenas 1 GB é criado e pronto para uso. Não há nenhum erro nesta etapa.
A replicação é bloqueada em xx% sincronizada e, depois de um tempo, a integridade da replicação se torna crítica com o erro AzStackToAzStackSourceAgentDiskSourceAgentSlowResyncProgressOnPremToAzure. O erro ocorre porque durante a replicação, a Recuperação de Site tenta redimensionar o disco de propagação para 1024 GB e gravar nele. Essa operação falha, pois o Azure Stack Hub não oferece suporte a discos de 1024 GB.
O disco de propagação criado para este disco (na assinatura de destino) ainda está em 1 GB de tamanho, e o log de atividades mostra algumas falhas de disco de gravação com a mensagem de erro O valor '1024' do parâmetro 'disk.diskSizeGb' está fora do intervalo. O valor '1024' deve estar entre '1' e '1023', inclusive.

A solução alternativa atual para esse problema é criar um novo disco (de 1022 GB ou menos), anexá-lo à VM de origem, copiar os dados do disco de 1023 GB para o novo e remover o disco de 1023 GB da VM de origem. Depois que esse procedimento for concluído e a VM tiver todos os discos menores ou iguais a 1022 GB, você poderá habilitar a proteção usando o Azure Site Recovery.

Reproteção: slots de disco de dados disponíveis no dispositivo

Verifique se a VM do dispositivo tem slots de disco de dados suficientes, pois os discos de réplica para nova proteção estão conectados ao dispositivo.
O número inicial permitido de discos sendo reprotegidos ao mesmo tempo é 31. O tamanho padrão do dispositivo criado a partir do item do marketplace é Standard_DS4_v2, que suporta até 32 discos de dados, e o próprio appliance usa um disco de dados.
Se a soma das VMs protegidas for maior que 31, execute uma das seguintes ações:
- Divida as VMs que exigem nova proteção em grupos menores para garantir que o número de discos reprotegidos ao mesmo tempo não exceda o número máximo de discos de dados suportados pelo dispositivo.
- Aumente o tamanho da VM do dispositivo Azure Site Recovery.
Observação

Não testamos e validamos SKUs de VM grandes para a VM do dispositivo.
Se você estiver tentando proteger novamente uma VM, mas não houver slots suficientes no dispositivo para armazenar os discos de replicação, a mensagem de erro Ocorreu um erro interno será exibida. Você pode verificar o número de discos de dados atualmente no dispositivo ou entrar no dispositivo, ir para Visualizar Eventos e abrir logs para o Azure Site Recovery em Logs de Aplicativos e Serviços:

Encontre o aviso mais recente para identificar o problema.

Versão do kernel da VM Linux não suportada

Verifique sua versão do kernel executando o comando uname -r.

Para obter mais informações sobre versões de kernel Linux com suporte, consulte Matriz de suporte do Azure para Azure.
Com uma versão de kernel suportada, o failover, que faz com que a VM execute uma reinicialização, pode fazer com que a VM com failover seja atualizada para uma versão mais recente do kernel que pode não ser suportada. Para evitar uma atualização devido a uma reinicialização da VM de failover, execute o comando sudo apt-mark hold linux-image-azure linux-headers-azure para que a atualização da versão do kernel possa continuar.
Para uma versão de kernel não suportada, verifique se há uma versão mais antiga do kernel para a qual você pode reverter, executando o comando apropriado para sua VM:
- Debian/Ubuntu: dpkg --list | grep linux-image
A imagem a seguir mostra um exemplo em uma VM do Ubuntu na versão 5.4.0-1103-azure, que não é suportada. Depois que o comando é executado, você pode ver uma versão com suporte, 5.4.0-1077-azure, que já está instalada na VM. Com essas informações, você pode reverter para a versão suportada.
Reverta para uma versão do kernel suportada usando estas etapas:
1. Primeiro, faça uma cópia do /etc/default/grub caso haja um erro, por exemplo, sudo cp /etc/default/grub /etc/default/grub.bak.
2. Em seguida, modifique /etc/default/grub para definir GRUB_DEFAULT para a versão anterior que você deseja usar. Você pode ter algo semelhante a GRUB_DEFAULT="Opções avançadas para o Ubuntu>Ubuntu, com Linux 5.4.0-1077-azure".
3. Selecione Salvar para salvar o arquivo e, em seguida, selecione Sair.
4. Execute sudo update-grub para atualizar o grub.
5. Finalmente, reinicie a VM e continue com a reversão para uma versão de kernel suportada.
Se você não tiver uma versão antiga do kernel para a qual possa reverter, aguarde a atualização do agente de mobilidade para que seu kernel possa ser suportado. A atualização é concluída automaticamente, se estiver pronta, e você pode verificar a versão no portal para confirmar:

A ressincronização manual de proteção reativa ainda não é suportada

Depois que o trabalho de nova proteção for concluído, a replicação será iniciada em sequência. Durante a replicação, pode haver casos que exijam uma ressincronização, o que significa que uma nova replicação inicial é acionada para sincronizar todas as alterações.

Existem dois tipos de ressincronização:

Ressincronização automática. Não requer nenhuma ação do usuário e é feito automaticamente. Os usuários podem ver alguns eventos mostrados no portal:
Ressincronização manual. Requer ação do usuário para disparar a ressincronização manualmente e é necessário nas seguintes instâncias:
- A conta de armazenamento escolhida para a reproteção está ausente.
- O disco de replicação no dispositivo está ausente.
- A gravação de replicação excede a capacidade do disco de replicação no dispositivo.
  
  Dica
  
  Você também pode encontrar os motivos de ressincronização manual na folha de eventos para ajudá-lo a decidir se uma ressincronização manual é necessária.

Problemas conhecidos na automação do PowerShell

Se você deixar $failbackPolicyName e $failbackExtensionName vazio ou nulo, a nova proteção pode falhar. Veja os exemplos a seguir:

Sempre especifique o $failbackPolicyName e $failbackExtensionName, conforme mostrado no exemplo a seguir:

$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

Aviso do agente do serviço de mobilidade

Ao replicar várias VMs, você pode ver a integridade do item protegido alterada para Erro de aviso nos trabalhos de Recuperação de Site.

Essa mensagem de erro deve ser apenas um aviso e não é um problema de bloqueio para os processos reais de replicação ou failover.

Dica

Você pode verificar o estado da respectiva VM para garantir que ela esteja íntegra.

A exclusão da VM do dispositivo (origem) bloqueia a exclusão do cofre (destino)

Para excluir o cofre do Azure Site Recovery no destino, você deve primeiro remover todas as VMs protegidas. Se você excluir a VM do dispositivo primeiro, o cofre da Recuperação de Site bloqueará a exclusão dos recursos protegidos e a tentativa de excluir o próprio cofre também falhará. A exclusão do grupo de recursos também falha, e a única maneira de remover o cofre é excluindo a assinatura de usuário do Azure Stack Hub na qual o cofre é criado.

Para evitar esse problema, certifique-se de primeiro remover a proteção de todos os itens no cofre, antes de excluir a VM do dispositivo. Isso permite que o cofre conclua a limpeza de recursos no dispositivo (lado de origem). Depois que os itens protegidos forem removidos, você poderá excluir o cofre e remover a VM do dispositivo.

Compartilhar via