Planear a migração de recursos de IaaS do clássico para o Azure Resource Manager

  • Artigo

Aplica-se a: ✔️ VMs Linux VMs ✔️ Windows

Importante

Atualmente, cerca de 90% das VMs IaaS estão usando o Azure Resource Manager. A partir de 28 de fevereiro de 2020, as VMs clássicas foram preteridas e serão totalmente desativadas em 6 de setembro de 2023. Saiba mais sobre essa depreciação e como ela afeta você.

Embora o Azure Resource Manager ofereça vários recursos incríveis, é fundamental planejar sua jornada de migração para garantir que tudo corra bem. Gastar tempo no planejamento garantirá que você não encontre problemas durante a execução de atividades de migração.

Nota

As orientações a seguir foram fortemente contribuídas pela equipe de Consultoria ao Cliente do Azure e pelos arquitetos de Soluções na Nuvem que trabalham com clientes na migração de ambientes grandes. Como tal, este documento continuará a ser atualizado à medida que novos padrões de sucesso surgem, portanto, verifique de tempos em tempos para ver se há novas recomendações.

Existem quatro fases gerais da viagem de migração:

Fases de migração

Planear

Considerações técnicas e compensações

Dependendo do tamanho dos seus requisitos técnicos, geografias e práticas operacionais, convém considerar:

  1. Por que o Azure Resource Manager é desejado para sua organização? Quais são as razões comerciais para uma migração?
  2. Quais são as razões técnicas para o Azure Resource Manager? Quais (se houver) outros serviços do Azure você gostaria de usar?
  3. Qual aplicativo (ou conjuntos de máquinas virtuais) está incluído na migração?
  4. Quais cenários são suportados com a API de migração? Analise os recursos e configurações não suportados.
  5. Suas equipes operacionais agora darão suporte a aplicativos/VMs no Classic e no Azure Resource Manager?
  6. Como (se for o caso) o Azure Resource Manager altera seus processos de implantação, gerenciamento, monitoramento e relatórios de VM? Os scripts de implantação precisam ser atualizados?
  7. Quais são os planos de comunicação para alertar as partes interessadas (usuários finais, proprietários de aplicativos e proprietários de infraestrutura)?
  8. Dependendo da complexidade do ambiente, deve haver um período de manutenção em que o aplicativo não esteja disponível para usuários finais e proprietários de aplicativos? Se sim, durante quanto tempo?
  9. Qual é o plano de treinamento para garantir que as partes interessadas tenham conhecimento e proficiência no Gerenciador de Recursos do Azure?
  10. Qual é o plano de gerenciamento de programa ou de projeto para a migração?
  11. Quais são os cronogramas para a migração do Azure Resource Manager e outros roteiros de tecnologia relacionados? Estão perfeitamente alinhados?

Padrões de sucesso

Os clientes bem-sucedidos têm planos detalhados onde as questões anteriores são discutidas, documentadas e controladas. Garantir que os planos de migração sejam amplamente comunicados aos patrocinadores e partes interessadas. Equipar-se com conhecimento sobre suas opções de migração; É altamente recomendável ler este documento de migração definido abaixo.

Armadilhas a evitar

  • Falha no planeamento. Os passos tecnológicos desta migração estão comprovados e o resultado é previsível.
  • Suponha que a API de migração suportada pela plataforma será responsável por todos os cenários. Leia os recursos e configurações sem suporte para entender quais cenários são suportados.
  • Não planejar possíveis interrupções de aplicativos para usuários finais. Planeje buffer suficiente para avisar adequadamente os usuários finais sobre o tempo de aplicativo potencialmente indisponível.

Teste de laboratório

Replique seu ambiente e faça uma migração de teste

Nota

A replicação exata do seu ambiente existente é executada usando uma ferramenta contribuída pela comunidade que não é oficialmente suportada pelo Suporte da Microsoft. Portanto, é uma etapa opcional , mas é a melhor maneira de descobrir problemas sem tocar em seus ambientes de produção. Se usar uma ferramenta contribuída pela comunidade não for uma opção, leia sobre a recomendação Validar/Preparar/Abortar Execução Seca abaixo.

Realizar um teste de laboratório do seu cenário exato (computação, rede e armazenamento) é a melhor maneira de garantir uma migração suave. Tal contribuirá para assegurar:

  • Um laboratório totalmente separado ou um ambiente de não produção existente para testar. Recomendamos um laboratório totalmente separado que pode ser migrado repetidamente e pode ser modificado destrutivamente. Os scripts para coletar/hidratar metadados das assinaturas reais estão listados abaixo.

  • É uma boa ideia criar o laboratório em uma assinatura separada. A razão é que o laboratório será derrubado repetidamente, e ter uma assinatura separada e isolada reduzirá a chance de que algo real seja excluído acidentalmente.

    Isso pode ser feito usando a ferramenta AsmMetadataParser. Leia mais sobre esta ferramenta aqui

Padrões de sucesso

A seguir estão os problemas descobertos em muitas das migrações maiores. Esta não é uma lista exaustiva e você deve consultar os recursos e configurações sem suporte para obter mais detalhes. Você pode ou não encontrar esses problemas técnicos, mas se você resolvê-los antes de tentar a migração garantirá uma experiência mais suave.

  • Fazer uma Validar/Preparar/Abortar Execução Seca - Esta é talvez a etapa mais importante para garantir o sucesso da migração do Classic to Azure Resource Manager. A API de migração tem três etapas principais: Validar, Preparar e Confirmar. Validar irá ler o estado do seu ambiente clássico e retornar um resultado de todos os problemas. No entanto, como alguns problemas podem existir na pilha do Azure Resource Manager, o Validate não pegará tudo. A próxima etapa do processo de migração, Preparar, ajudará a expor esses problemas. Preparar moverá os metadados do Clássico para o Gerenciador de Recursos do Azure, mas não confirmará a mudança e não removerá ou alterará nada no lado Clássico. A execução seca envolve preparar a migração e, em seguida, abortar (não confirmar) a preparação das migrações. O objetivo de validar/preparar/abortar a execução seca é ver todos os metadados na pilha do Azure Resource Manager, examiná-los (programaticamente ou no Portal) e verificar se tudo migra corretamente e resolver problemas técnicos. Ele também lhe dará uma noção da duração da migração para que você possa planejar o tempo de inatividade de acordo. Uma validação/preparação/anulação não causa nenhum tempo de inatividade do usuário; portanto, não causa interrupções no uso do aplicativo.

    • Os itens abaixo precisarão ser resolvidos antes da corrida a seco, mas um teste de corrida a seco também eliminará com segurança essas etapas de preparação se elas forem perdidas. Durante a migração corporativa, descobrimos que a corrida seca é uma maneira segura e inestimável de garantir a prontidão da migração.
    • Quando a preparação estiver em execução, o plano de controle (operações de gerenciamento do Azure) será bloqueado para toda a rede virtual, portanto, nenhuma alteração pode ser feita nos metadados da VM durante a validação/preparação/anulação. Mas, caso contrário, qualquer função do aplicativo (RD, uso de VM, etc.) não será afetada. Os usuários das VMs não saberão que a execução seca está sendo executada.

  • Circuitos de rota expressa e VPN. Atualmente, os gateways de rota expressa com links de autorização não podem ser migrados sem tempo de inatividade. Para obter a solução alternativa, consulte Migrar circuitos de Rota Expressa e redes virtuais associadas do modelo de implantação clássico para o Resource Manager.

  • Extensões de VM - As extensões de máquina virtual são potencialmente um dos maiores obstáculos à migração de VMs em execução. A correção de extensões de VM pode levar de 1 a 2 dias, portanto, planeje de acordo. Um agente do Azure em funcionamento é necessário para relatar o status da Extensão de VM de VMs em execução. Se o status voltar como ruim para uma VM em execução, isso interromperá a migração. O agente em si não precisa estar funcionando para habilitar a migração, mas se existirem extensões na VM, será necessário um agente em funcionamento E conectividade com a Internet de saída (com DNS) para que a migração avance.

    • Se a conectividade com um servidor DNS for perdida durante a migração, todas as Extensões de VM, exceto BGInfo v1.*, precisarão primeiro ser removidas de cada VM antes da preparação da migração e, posteriormente, readicionadas novamente à VM após a migração do Azure Resource Manager. Isso é apenas para VMs que estão em execução. Se as VMs forem interrompidas deslocalizadas, as Extensões de VM não precisarão ser removidas. Observação: muitas extensões, como o diagnóstico do Azure e o monitoramento do Defender for Cloud, serão reinstaladas após a migração, portanto, removê-las não é um problema.

    • Além disso, certifique-se de que os Grupos de Segurança de Rede não estão restringindo o acesso de saída à Internet. Isso pode acontecer com algumas configurações de Grupos de Segurança de Rede. O acesso de saída à Internet (e DNS) é necessário para que as Extensões de VM sejam migradas para o Azure Resource Manager.

    • Existem duas versões da extensão BGInfo: v1 e v2. Se a VM foi criada usando o portal do Azure ou o PowerShell, a VM provavelmente terá a extensão v1 nela. Essa extensão não precisa ser removida e será ignorada (não migrada) pela API de migração. No entanto, se a VM clássica tiver sido criada com o novo portal do Azure, ela provavelmente terá a versão v2 baseada em JSON do BGInfo, que pode ser migrada para o Azure Resource Manager desde que o agente esteja funcionando e tenha acesso de saída à Internet (e DNS).

    • Opção de remediação 1. Se você souber que suas VMs não terão acesso de saída à Internet, um serviço DNS em funcionamento e agentes do Azure em funcionamento nas VMs, desinstale todas as extensões de VM como parte da migração antes de Preparar e reinstale as Extensões de VM após a migração.

    • Opção de reparação 2. Se as extensões de VM forem um obstáculo muito grande, outra opção é desligar/desalocar todas as VMs antes da migração. Migre as VMs desalocadas e reinicie-as no lado do Azure Resource Manager. O benefício aqui é que as extensões de VM serão migradas. A desvantagem é que todos os IPs virtuais voltados para o público serão perdidos (isso pode ser um não-starter) e, obviamente, as VMs serão desligadas, causando um impacto muito maior nos aplicativos de trabalho.

      Nota

      Se uma política do Microsoft Defender for Cloud estiver configurada em relação às VMs em execução que estão sendo migradas, a diretiva de segurança precisará ser interrompida antes de remover extensões, caso contrário, a extensão de monitoramento de segurança será reinstalada automaticamente na VM após removê-la.

  • Conjuntos de disponibilidade - Para que uma rede virtual (vNet) seja migrada para o Azure Resource Manager, as VMs contidas na implantação clássica (ou seja, serviço de nuvem) devem estar todas em um conjunto de disponibilidade ou as VMs não devem estar em nenhum conjunto de disponibilidade. Ter mais de uma disponibilidade definida no serviço de nuvem não é compatível com o Azure Resource Manager e interromperá a migração. Além disso, não pode haver algumas VMs em um conjunto de disponibilidade e algumas VMs não em um conjunto de disponibilidade. Para resolver isso, você precisará corrigir ou reorganizar seu serviço de nuvem. Planeje de acordo, pois isso pode ser demorado.

  • Implantações de Função Web/Trabalhador - Os Serviços de Nuvem que contêm funções Web e de trabalho não podem migrar para o Azure Resource Manager. As funções Web/de trabalho devem primeiro ser removidas da rede virtual antes que a migração possa ser iniciada. Uma solução típica é apenas mover instâncias de função Web/trabalho para uma rede virtual Clássica separada que também esteja vinculada a um circuito de Rota Expressa, ou migrar o código para Serviços de Aplicativo PaaS mais recentes (esta discussão está além do escopo deste documento). No primeiro caso de reimplantação, crie uma nova rede virtual clássica, mova/reimplante as funções Web/de trabalho para essa nova rede virtual e exclua as implantações da rede virtual que está sendo movida. Não são necessárias alterações de código. O novo recurso de Emparelhamento de Rede Virtual pode ser usado para emparelhar a rede virtual clássica que contém as funções Web/trabalhador e outras redes virtuais na mesma região do Azure, como a rede virtual que está sendo migrada (depois que a migração de rede virtual é concluída, pois as redes virtuais emparelhadas não podem ser migradas), fornecendo assim os mesmos recursos sem perda de desempenho e sem penalidades de latência/largura de banda. Dada a adição do Emparelhamento de Rede Virtual, as implantações de função Web/trabalhador agora podem ser facilmente atenuadas e não bloquear a migração para o Azure Resource Manager.

  • Cotas do Azure Resource Manager - as regiões do Azure têm cotas/limites separados para o Classic e o Azure Resource Manager. Mesmo que, em um cenário de migração, o novo hardware não esteja sendo consumido (estamos trocando VMs existentes do Classic para o Azure Resource Manager), as cotas do Azure Resource Manager ainda precisam estar em vigor com capacidade suficiente antes que a migração possa começar. Abaixo estão listados os principais limites que vimos causar problemas. Abra um tíquete de suporte de cota para aumentar os limites.

    Nota

    Esses limites precisam ser aumentados na mesma região do ambiente atual a ser migrado.

    • Interfaces de Rede

    • Balanceadores de Carga

    • IPs Públicos

    • IPs públicos estáticos

    • Núcleos

    • Grupos de Segurança de Rede

    • Tabelas de Rota

      Você pode verificar suas cotas atuais do Azure Resource Manager usando os seguintes comandos com a versão mais recente da CLI do Azure.

      Computação (núcleos, conjuntos de disponibilidade)

      az vm list-usage -l <azure-region> -o jsonc

      Rede (Redes Virtuais, IPs Públicos Estáticos, IPs Públicos, Grupos de Segurança de Rede, Interfaces de Rede, Balanceadores de Carga, Tabelas de Rotas)

      az network list-usages -l <azure-region> -o jsonc

      Armazenamento (Conta de armazenamento)

      az storage account show-usage

  • Limites de limitação da API do Azure Resource Manager - Se você tiver um ambiente grande o suficiente (por exemplo, > 400 VMs em uma VNET), poderá atingir os limites de limitação de API padrão para gravações (atualmente 1200 gravações/hora) no Azure Resource Manager. Antes de iniciar a migração, você deve criar um tíquete de suporte para aumentar esse limite para sua assinatura.

  • Status da VM com tempo limite de provisionamento - Se qualquer VM tiver o status de provisionamento expirado, isso precisará ser resolvido antes da migração. A única maneira de fazer isso é com o tempo de inatividade desprovisionando/reprovisionando a VM (exclua-a, mantenha o disco e recrie a VM).

  • Status da VM RoleStateUnknown - Se a migração for interrompida devido a uma mensagem de erro desconhecida de estado de função, inspecione a VM usando o portal e verifique se ela está em execução. Esse erro normalmente desaparece por conta própria (sem necessidade de correção) após alguns minutos e geralmente é um tipo transitório frequentemente visto durante as operações de início, parada e reinicialização de uma máquina virtual. Prática recomendada: tente novamente a migração após alguns minutos.

  • Cluster de malha não existe - Em alguns casos, determinadas VMs não podem ser migradas por vários motivos estranhos. Um desses casos conhecidos é se a VM foi criada recentemente (na última semana ou mais) e conseguiu um cluster do Azure que ainda não está equipado para cargas de trabalho do Azure Resource Manager. Você receberá um erro informando que o cluster de malha não existe e a VM não pode ser migrada. Esperar alguns dias geralmente resolverá esse problema específico, pois o cluster logo habilitará o Azure Resource Manager. No entanto, uma solução imediata é a stop-deallocate VM, continuar com a migração e iniciar o backup da VM no Azure Resource Manager após a migração.

Armadilhas a evitar

  • Não use atalhos e omita as migrações validar/preparar/abortar de execução seca.
  • A maioria, se não todos, dos seus possíveis problemas surgirão durante as etapas de validação/preparação/anulação.

Migração

Considerações técnicas e compensações

Agora você está pronto porque resolveu os problemas conhecidos com seu ambiente.

Para as migrações reais, você pode considerar:

  1. Planeje e agende a rede virtual (menor unidade de migração) com prioridade crescente. Faça as redes virtuais simples primeiro e progrida com as redes virtuais mais complicadas.
  2. A maioria dos clientes terá ambientes de não-produção e produção. Programe a produção por último.
  3. (OPCIONAL) Agende um tempo de inatividade de manutenção com bastante buffer para o caso de surgirem problemas inesperados.
  4. Comunique-se e alinhe-se com suas equipes de suporte caso surjam problemas.

Padrões de sucesso

A orientação técnica da seção Teste de laboratório acima deve ser considerada e mitigada antes de uma migração real. Com testes adequados, a migração é, na verdade, um não-evento. Para ambientes de produção, pode ser útil ter suporte adicional, como um parceiro confiável da Microsoft ou serviços Microsoft Premier.

Armadilhas a evitar

O não teste completo pode causar problemas e atraso na migração.

Além da migração

Considerações técnicas e compensações

Agora que você está no Gerenciador de Recursos do Azure, maximize a plataforma. Leia a visão geral do Azure Resource Manager para saber mais sobre benefícios adicionais.

Coisas a considerar:

  • Agregar a migração com outras atividades. A maioria dos clientes opta por uma janela de manutenção de aplicativos. Em caso afirmativo, convém usar esse tempo de inatividade para habilitar outros recursos do Azure Resource Manager, como criptografia e migração para Managed Disks.
  • Revisite as razões técnicas e comerciais do Azure Resource Manager; habilite os serviços adicionais disponíveis somente no Azure Resource Manager que se aplicam ao seu ambiente.
  • Modernize seu ambiente com serviços de PaaS.

Padrões de sucesso

Seja proposital sobre quais serviços você deseja habilitar agora no Azure Resource Manager. Muitos clientes acham o abaixo atraente para seus ambientes do Azure:

Armadilhas a evitar

Lembre-se por que você iniciou essa jornada de migração do Classic to Azure Resource Manager. Quais foram as razões originais do negócio? Conseguiu a razão do negócio?

Próximos passos