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

  • Artigo

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

Importante

Atualmente, cerca de 90% das VMs IaaS estão a utilizar o Azure Resource Manager. A partir de 28 de fevereiro de 2020, as VMs clássicas foram preteridas e serão totalmente descontinuadas a 1 de setembro de 2023. Saiba mais sobre esta preterição e como a afeta.

Embora o Azure Resource Manager ofereça inúmeras funcionalidades fantásticas, é fundamental planear o seu percurso de migração para garantir que as coisas correm bem. Gastar tempo no planeamento irá garantir que não encontra problemas durante a execução de atividades de migração.

Nota

A seguinte documentação de orientação foi fortemente contribuida pela equipa de Aconselhamento de Clientes do Azure e pelos arquitetos da Cloud Solution que trabalham com clientes na migração de ambientes grandes. Como tal, este documento continuará a ser atualizado à medida que surgem novos padrões de sucesso, por isso, verifique de vez em quando para ver se existem novas recomendações.

Existem quatro fases gerais do percurso de migração:

Fases de migração

Planear

Considerações técnicas e compromissos

Consoante o tamanho dos seus requisitos técnicos, geografias e práticas operacionais, recomendamos que considere:

  1. Porque é que o Azure Resource Manager deseja para a sua organização? Quais são os motivos comerciais para uma migração?
  2. Quais são os motivos técnicos para o Azure Resource Manager? Quais (se existirem) serviços adicionais do Azure que gostaria de tirar partido?
  3. Que aplicação (ou conjuntos de máquinas virtuais) está incluída na migração?
  4. Que cenários são suportados com a API de migração? Reveja as funcionalidades e configurações não suportadas.
  5. As suas equipas operacionais irão agora suportar aplicações/VMs no clássico e no Azure Resource Manager?
  6. Como é que o Azure Resource Manager altera os processos de implementação, gestão, monitorização e relatórios da VM? Os scripts de implementação precisam de ser atualizados?
  7. Qual é o plano de comunicações para alertar os intervenientes (utilizadores finais, proprietários de aplicações e proprietários de infraestruturas)?
  8. Consoante a complexidade do ambiente, deve existir um período de manutenção em que a aplicação não está disponível para os utilizadores finais e para os proprietários da aplicação? Se sim, por quanto tempo?
  9. Qual é o plano de formação para garantir que os intervenientes são conhecedores e proficientes no Azure Resource Manager?
  10. Qual é o plano de gestão de programas ou de gestão de projetos para a migração?
  11. Quais são as linhas cronológicas para a migração do Azure Resource Manager e outros mapas de objetivos tecnológicos relacionados? Estão alinhados da melhor forma?

Padrões de sucesso

Os clientes com êxito têm planos detalhados onde as perguntas anteriores são discutidas, documentadas e regidas. Certifique-se de que os planos de migração são amplamente comunicados aos patrocinadores e intervenientes. Equipar-se com conhecimentos sobre as suas opções de migração; A leitura através deste conjunto de documentos de migração abaixo é altamente recomendada.

Armadilhas a evitar

  • Falha ao planear. Os passos tecnológicos desta migração são comprovados e o resultado é previsível.
  • Assunção de que a API de migração suportada pela plataforma terá em conta todos os cenários. Leia as funcionalidades e configurações não suportadas para compreender que cenários são suportados.
  • Não está a planear uma possível indisponibilidade da aplicação para os utilizadores finais. Planeie memória intermédia suficiente para avisar adequadamente os utilizadores finais sobre o tempo de aplicação potencialmente indisponível.

Teste de Laboratório

Replicar o seu ambiente e fazer uma migração de teste

Nota

A replicação exata do seu ambiente existente é executada através de uma ferramenta com contribuição para a comunidade que não é oficialmente suportada pelo Suporte da Microsoft. Portanto, é um passo opcional , mas é a melhor forma de descobrir problemas sem tocar nos seus ambientes de produção. Se a utilização de uma ferramenta com contribuição para a comunidade não for uma opção, leia sobre a recomendação Validar/Preparar/Abortar a Execução a Seco abaixo.

Realizar um teste de laboratório do seu cenário exato (computação, rede e armazenamento) é a melhor forma de garantir uma migração sem problemas. Isto ajudará a garantir:

  • Um laboratório totalmente separado ou um ambiente de não produção existente para testar. Recomendamos um laboratório totalmente separado que possa ser migrado repetidamente e que possa ser modificado de forma destrutiva. Os scripts para recolher/hidratar metadados das subscrições reais estão listados abaixo.

  • É uma boa ideia criar o laboratório numa subscrição separada. O motivo é que o laboratório será desativado repetidamente e ter uma subscrição separada e isolada reduzirá a probabilidade de algo real ser eliminado acidentalmente.

    Isto pode ser conseguido com a ferramenta AsmMetadataParser. Leia mais sobre esta ferramenta aqui

Padrões de sucesso

Seguem-se problemas detetados em muitas das migrações maiores. Esta não é uma lista exaustiva e deve consultar as funcionalidades e configurações não suportadas para obter mais detalhes. Pode ou não encontrar estes problemas técnicos, mas se resolver estes problemas antes de tentar a migração, garantirá uma experiência mais suave.

  • Efetuar uma Validação/Preparação/Abortar a Execução a Seco – este é talvez o passo mais importante para garantir o sucesso da migração clássica para o Azure Resource Manager. A API de migração tem três passos principais: Validar, Preparar e Consolidar. Validar irá ler o estado do seu ambiente clássico e devolver um resultado de todos os problemas. No entanto, como podem existir alguns problemas na pilha de Resource Manager do Azure, Validar não irá detetar tudo. O próximo passo no processo de migração, Preparar, ajudará a expor esses problemas. A preparação irá mover os metadados do clássico para o Azure Resource Manager, mas não consolidará a movimentação e não removerá nem alterará nada no lado Clássico. A execução a seco envolve preparar a migração e, em seguida, abortar (não consolidar) a preparação das migrações. O objetivo de validar/preparar/abortar a execução a seco é ver todos os metadados na pilha de Resource Manager do Azure, examiná-lo (programaticamente ou no Portal) e verificar se tudo migra corretamente e resolver problemas técnicos. Também lhe dará uma noção da duração da migração para que possa planear o período de indisponibilidade em conformidade. Uma validação/preparação/abortação não causa qualquer período de indisponibilidade do utilizador; Por conseguinte, não é problemático para a utilização da aplicação.

    • Os itens abaixo terão de ser resolvidos antes da execução a seco, mas um teste de teste a seco também removerá estes passos de preparação em segurança se não forem executados. Durante a migração empresarial, descobrimos que a execução a seco é uma forma segura e inestimável de garantir a preparação da migração.
    • Quando a preparação estiver em execução, o plano de controlo (operações de gestão do Azure) será bloqueado para toda a rede virtual, pelo que não podem ser efetuadas alterações aos metadados da VM durante a validação/preparação/abortação. Contudo, caso contrário, qualquer função da aplicação (RD, utilização da VM, etc.) não será afetada. Os utilizadores das VMs não saberão que o teste está a ser executado.

  • Circuitos e VPN do Express Route. Atualmente, os Gateways do ExpressRoute com ligações de autorização não podem ser migrados sem tempo de inatividade. Para obter a solução, veja Migrate ExpressRoute circuits and associated virtual networks from the classic to the Resource Manager deployment model (Migrar circuitos do ExpressRoute e redes virtuais associadas do modelo clássico para o modelo de implementação do 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 remediação das Extensões de VM pode demorar mais de 1 a 2 dias, pelo que planeie em conformidade. É necessário um agente do Azure em funcionamento para comunicar o estado da Extensão da VM das VMs em execução. Se o estado voltar a ser tão mau para uma VM em execução, esta ação irá interromper a migração. O próprio agente não precisa de estar a funcionar para ativar a migração, mas se existirem extensões na VM, será necessário um agente operacional e uma conectividade internet de saída (com DNS) para que a migração avance.

    • Se a conectividade a um servidor DNS for perdida durante a migração, todas as Extensões de VM exceto BGInfo v1.* têm de ser removidas primeiro de todas as VMs antes da preparação da migração e, posteriormente, voltar a ser adicionadas à VM após a migração do Azure Resource Manager. Isto destina-se apenas a VMs em execução. Se as VMs forem paradas desalocadas, as Extensões de VM não precisam de ser removidas. Nota: Muitas extensões, como os diagnósticos do Azure e a monitorização do Defender para a Cloud, serão reinstaladas após a migração, pelo que removê-las não é um problema.

    • Além disso, certifique-se de que os Grupos de Segurança de Rede não estão a restringir o acesso de saída à Internet. Isto pode acontecer com algumas configurações de Grupos de Segurança de Rede. O acesso à Internet de saída (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 tiver sido criada com o portal do Azure ou o PowerShell, é provável que a VM tenha a extensão v1. Esta extensão não precisa de 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, 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 a funcionar e tenha acesso à Internet (e DNS) de saída.

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

    • Opção de Remediação 2. Se as extensões de VM forem demasiado grandes, outra opção é encerrar/desalocar todas as VMs antes da migração. Migre as VMs desalocadas e, em seguida, reinicie-as no lado Resource Manager do Azure. O benefício aqui é que as extensões de VM serão migradas. A desvantagem é que todos os IPs Virtuais destinados ao público serão perdidos (pode não ser um arranque) e, obviamente, as VMs serão encerradas causando um impacto muito maior nas aplicações de trabalho.

      Nota

      Se for configurada uma Microsoft Defender para a política da Cloud relativamente às VMs em execução que estão a ser migradas, a política de segurança tem de ser interrompida antes de remover as extensões. Caso contrário, a extensão de monitorização de segurança será reinstalada automaticamente na VM depois de a remover.

  • Conjuntos de Disponibilidade – para que uma rede virtual (vNet) seja migrada para o Azure Resource Manager, as VMs contidas na implementação clássica (ou seja, o serviço cloud) têm de estar todas num conjunto de disponibilidade ou as VMs não devem estar todas num conjunto de disponibilidade. Ter mais do que um conjunto de disponibilidade no serviço cloud não é compatível com o Azure Resource Manager e irá interromper a migração. Além disso, não pode haver algumas VMs num conjunto de disponibilidade e algumas VMs não estão num conjunto de disponibilidade. Para resolver este problema, terá de remediar ou remodelar o seu serviço cloud. Planeie em conformidade, uma vez que pode ser moroso.

  • Implementações de Funções web/de trabalho - Serviços Cloud que contenham funções web e de trabalho não podem migrar para o Azure Resource Manager. As funções web/de trabalho têm primeiro de ser removidas da rede virtual antes de a migração poder ser iniciada. Uma solução típica é apenas mover instâncias de função web/de trabalho para uma rede virtual Clássica separada que também esteja ligada a um circuito do ExpressRoute ou migrar o código para os Serviços de Aplicações PaaS mais recentes (este debate está fora do âmbito deste documento). No caso de reimplementação anterior, crie uma nova rede virtual Clássica, mova/reimplemente as funções web/de trabalho para essa nova rede virtual e, em seguida, elimine as implementações da rede virtual que está a ser movida. Não são necessárias alterações de código. A nova capacidade de Peering de Rede Virtual pode ser utilizada para ligar em conjunto a rede virtual clássica que contém as funções web/de trabalho e outras redes virtuais na mesma região do Azure, como a rede virtual que está a ser migrada (após a conclusão da migração da rede virtual, uma vez que não é possível migrar redes virtuais em modo de peering), fornecendo assim as mesmas capacidades sem perda de desempenho e sem penalizações de latência/largura de banda. Dada a adição de Rede Virtual Peering, as implementações de funções web/de trabalho podem agora ser facilmente mitigadas e não bloquear a migração para o Azure Resource Manager.

  • Quotas de Resource Manager do Azure – as regiões do Azure têm quotas/limites separados para as Resource Manager Clássicas e do Azure. Apesar de, num cenário de migração, o novo hardware não estar a ser consumido (estamos a trocar VMs existentes do clássico para o Azure Resource Manager), o Azure Resource Manager quotas ainda têm de estar implementadas com capacidade suficiente antes de a migração poder começar. Abaixo encontram-se os principais limites que temos visto causar problemas. Abra um pedido de suporte de quota para aumentar os limites.

    Nota

    Estes limites têm de ser aumentados na mesma região que o seu ambiente atual a ser migrado.

    • Interfaces de Rede

    • Balanceador de Carga

    • IPs públicos

    • IPs Públicos Estáticos

    • Núcleos

    • Grupos de Segurança de Rede

    • Tabelas de Rota

      Pode verificar as quotas atuais do Azure Resource Manager com os seguintes comandos com a versão mais recente da CLI do Azure.

      Compute(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

      Storage(Conta de Armazenamento)

      az storage account show-usage

  • Limites de limitação da API do Azure Resource Manager – se tiver um ambiente suficientemente grande (por exemplo, > 400 VMs numa VNET), poderá atingir os limites de limitação de API predefinidos para escritas (atualmente 1200 escritas/hora) no Azure Resource Manager. Antes de iniciar a migração, deve criar um pedido de suporte para aumentar este limite para a sua subscrição.

  • Estado da VM com Tempo Limite excedido do Aprovisionamento – se alguma VM tiver o estado do aprovisionamento excedido, esta situação tem de ser resolvida antes da migração. A única forma de o fazer é com o tempo de inatividade ao desaprovisionar/reaprovisionar a VM (eliminá-la, manter o disco e recriar a VM).

  • RoleStateUnknown Estado da VM – se a migração parar devido a uma mensagem de erro desconhecida de estado de função, inspecione a VM com o portal e certifique-se de que está em execução. Normalmente, este erro desaparece por si só (não é necessária remediação) após alguns minutos e é, muitas vezes, um tipo transitório visto frequentemente durante as operações de início, paragem e reinício da Máquina Virtual. Prática recomendada: tente novamente a migração após alguns minutos.

  • O Cluster de Recursos de Infraestrutura não existe – em alguns casos, determinadas VMs não podem ser migradas por vários motivos estranhos. Um destes casos conhecidos é se a VM foi criada recentemente (na última semana ou assim) e aterrou um cluster do Azure que ainda não está equipado para cargas de trabalho do Azure Resource Manager. Receberá um erro a indicar que o cluster de recursos de infraestrutura não existe e que a VM não pode ser migrada. Normalmente, aguardar alguns dias resolverá este problema específico, uma vez que o cluster irá ativar o Azure Resource Manager em breve. No entanto, uma solução imediata é para a stop-deallocate VM e, em seguida, avançar com a migração e iniciar a cópia de segurança da VM no Azure Resource Manager após a migração.

Armadilhas a evitar

  • Não atalhos e omita as migrações validar/preparar/abortar a execução a seco.
  • A maioria, se não todos, dos seus potenciais problemas surgirão durante os passos de validação/preparação/abortação.

Migração

Considerações técnicas e compromissos

Agora, está pronto porque já trabalhou nos problemas conhecidos com o seu ambiente.

Para as migrações reais, pode considerar:

  1. Planeie e agende a rede virtual (a unidade de migração mais pequena) com prioridade crescente. Efetue primeiro as redes virtuais simples e progrida com as redes virtuais mais complicadas.
  2. A maioria dos clientes terá ambientes de não produção e produção. Agende a produção por último.
  3. (OPCIONAL) Agende um período de indisponibilidade de manutenção com muita memória intermédia no caso de surgirem problemas inesperados.
  4. Comunique e alinhe-se com as suas equipas de suporte no caso de surgirem problemas.

Padrões de sucesso

As orientações técnicas da secção Teste de Laboratório acima devem ser consideradas e mitigadas antes de uma migração real. Com testes adequados, a migração não é um evento. Para ambientes de produção, pode ser útil ter suporte adicional, como um parceiro fidedigno da Microsoft ou serviços Premier da Microsoft.

Armadilhas a evitar

Os testes não completos podem causar problemas e atrasos na migração.

Além da Migração

Considerações técnicas e compromissos

Agora que está no Azure Resource Manager, maximize a plataforma. Leia a descrição geral do Azure Resource Manager para saber mais sobre os benefícios adicionais.

Aspetos a considerar:

  • Agrupar a migração com outras atividades. A maioria dos clientes opta por uma janela de manutenção de aplicações. Se for o caso, poderá querer utilizar este período de indisponibilidade para ativar outras capacidades de Resource Manager do Azure, como encriptação e migração para Managed Disks.
  • Reveja os motivos técnicos e comerciais do Azure Resource Manager; ative os serviços adicionais disponíveis apenas no Azure Resource Manager que se aplica ao seu ambiente.
  • Modernizar o seu ambiente com os serviços PaaS.

Padrões de sucesso

Tenha a finalidade de saber quais os serviços que pretende agora ativar no Azure Resource Manager. Muitos clientes consideram as opções abaixo apelativas para os seus ambientes do Azure:

Armadilhas a evitar

Lembre-se do motivo pelo qual iniciou este percurso de migração clássico para o Azure Resource Manager. Quais foram as razões comerciais originais? Conseguiu o motivo comercial?

Passos seguintes