Compartilhar via

Problemas conhecidos - Azure Site Recovery no Azure Stack Hub

  • Artigo

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.

    Captura de tela do portal do Azure mostrando erro máximo de disco.

  • 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.

    Captura de tela do portal do Azure mostrando erros de gravação de disco.

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

  1. 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.

  2. 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.

  3. 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.

  4. 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:

    Captura de tela de exemplo do Visualizador de Eventos para o Azure Site Recovery.

    Captura de tela de exemplo dos logs do Azure Site Recovery.

    Encontre o aviso mais recente para identificar o problema.

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

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

    Captura de tela de exemplo da versão do Kernel Linux.

    Para obter mais informações sobre versões de kernel Linux com suporte, consulte Matriz de suporte do Azure para Azure.

  2. 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.

  3. 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.

    Captura de tela de exemplo de uma verificação de versão do kernel do Ubuntu VM.

  4. 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".

      Captura de tela de exemplo de uma reversão de versão do kernel do Ubuntu VM.

    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.

  5. 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:

    Captura de tela de exemplo da verificação de atualização do agente de mobilidade.

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:

    Captura de tela de exemplo da ressincronização automática no portal Usuários.

  • 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:

    Captura de tela de exemplo de uma VM falhou ao executar erro de operação.

    Captura de tela de exemplo do segundo erro de operação em uma VM diferente.

  • 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.

Captura de tela de exemplo do aviso de alteração de integridade do item protegido.

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.

Próximas etapas