Share via


Problemas conhecidos – Azure Site Recovery no Azure Stack Hub

Cuidado

Este artigo faz referência ao CentOS, uma distribuição do Linux que está se aproximando do status de Fim da Vida Útil (EOL). Considere seu uso e plano adequadamente. Para obter mais informações, consulte as diretrizes de Fim da Vida Útil do CentOS.

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 e limitações conhecidos atuais no Azure Site Recovery no Azure Stack Hub.

O tamanho máximo do disco com suporte é de 1022 GB

Quando você protege uma VM, o Azure Site Recovery precisa adicionar mais 1 GB 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 por Site Recovery deve ser igual ou menor que 1022.

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

  • Habilitar a proteção é bem-sucedido, pois um disco de semente de apenas 1 GB é criado e pronto para uso. Não há nenhum erro nesta etapa.

  • A replicação é bloqueada em xx% Sincronizada e, após um tempo, a integridade da replicação torna-se crítica com o erro AzStackToAzStackSourceAgentDiskSourceAgentSlowResyncProgressOnPremToAzure. O erro ocorre porque durante a replicação, Site Recovery tenta redimensionar o disco de semente para 1024 GB e gravar nele. Essa operação falha, pois o Azure Stack Hub não dá suporte a discos de 1024 GB.

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

  • O disco de semente criado para esse disco (na assinatura de destino) ainda tem 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 de portal do Azure mostrando erros de disco de gravação.

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 feito e a VM tiver todos os discos menores ou iguais a 1022 GB, você poderá habilitar a proteção usando o Azure Site Recovery.

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

  1. Verifique se a VM dispositivo tem slots de disco de dados suficientes, pois os discos réplica para nova proteção são anexados ao dispositivo.

  2. O número inicial permitido de discos que estão sendo protegidos novamente ao mesmo tempo é 31. O tamanho padrão do dispositivo criado a partir do item do marketplace é Standard_DS4_v2, que dá suporte a até 32 discos de dados, e o próprio dispositivo 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 a reproteção em grupos menores para garantir que o número de discos protegidos novamente ao mesmo tempo não exceda o número máximo de discos de dados aos quais o dispositivo dá suporte.
    • Aumente o tamanho da VM Site Recovery dispositivo do Azure.

    Observação

    Não testamos e validamos SKUs de VM grandes para a VM dispositivo.

  4. Se você estiver tentando proteger novamente uma VM, mas não houver slots suficientes no dispositivo para manter os discos de replicação, será exibida a mensagem de erro Um erro interno. Você pode marcar o número de discos de dados atualmente no dispositivo ou entrar no dispositivo, ir para Visualizador de Eventos e abrir logs para Site Recovery do Azure em Logs de Aplicativos e Serviços:

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

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

    Encontre o aviso mais recente para identificar o problema.

Não há suporte para a versão do kernel da VM do Linux

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

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

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

  2. Com uma versão de kernel com suporte, 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 ter suporte. Para evitar uma atualização devido a uma reinicialização de 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 sem suporte, marcar para 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
    • RedHat/CentOS/RHEL: rpm -qa kernel

    A imagem a seguir mostra um exemplo em uma VM do Ubuntu na versão 5.4.0-1103-azure, que não tem suporte. Depois que o comando for executado, você poderá 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 com suporte.

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

  4. Reverta para uma versão de kernel com suporte usando estas etapas:

    1. Primeiro, faça uma cópia de /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 Ubuntu>Ubuntu, com Linux 5.4.0-1077-azure".

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

    3. Selecione Salvar para salvar o arquivo e, em seguida, selecione Sair.

    4. Execute sudo update-grub para atualizar o grub.

    5. Por fim, reinicie a VM e continue com a reversão para uma versão de kernel com suporte.

  5. Se você não tiver uma versão antiga do kernel para a qual poderá reverter, aguarde a atualização do agente de mobilidade para que o kernel possa ter suporte. A atualização será concluída automaticamente, se estiver pronta, e você poderá marcar a versão no portal para confirmar:

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

A ressincronização manual de nova proteção ainda não tem suporte

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 exigem uma ressincronização, o que significa que uma nova replicação inicial é disparada para sincronizar todas as alterações.

Há 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 de Ressincronização automática no portal usuários.

  • Ressincronização manual. Requer a 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 nova proteçã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ê sair $failbackPolicyName e $failbackExtensionName estiver vazio ou nulo, a nova proteção poderá falhar. Veja os exemplos a seguir:

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

    Captura de tela de exemplo do erro de segunda 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 serviço Mobilidade

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

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 marcar o estado da respectiva VM para garantir que ela esteja íntegra.

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

Para excluir o cofre de Site Recovery do Azure no destino, primeiro você deve remover todas as VMs protegidas. Se você excluir o dispositivo VM primeiro, o cofre Site Recovery bloqueará a exclusão dos recursos protegidos e tentar excluir o cofre em si 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, primeiro remova a proteção de todos os itens no cofre antes de excluir o dispositivo VM. Isso permite que o cofre conclua a limpeza de recursos no dispositivo (lado da origem). Depois que os itens protegidos forem removidos, você poderá excluir o cofre e remover o dispositivo VM.

Próximas etapas