Technical deep dive on platform-supported migration from classic to Azure Resource Manager (Análise detalhada técnica sobre a migração suportada por plataforma da clássica para Azure Resource Manager)
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ê.
Vamos aprofundar a migração do modelo de implantação clássico do Azure para o modelo de implantação do Azure Resource Manager. Examinamos os recursos em um nível de recurso e recurso para ajudá-lo a entender como a plataforma Azure migra recursos entre os dois modelos de implantação. Para obter mais informações, leia o artigo de anúncio de serviço: Migração suportada pela plataforma de recursos IaaS do clássico para o Azure Resource Manager.
Migrar recursos IaaS do modelo de implantação clássico para o Azure Resource Manager
Primeiro, é importante entender a diferença entre operações de plano de dados e de plano de gerenciamento nos recursos de infraestrutura como serviço (IaaS).
- O plano de gerenciamento/controle descreve as chamadas que entram no plano de gerenciamento/controle ou na API para modificar recursos. Por exemplo, operações como criar uma VM, reiniciar uma VM e atualizar uma rede virtual com uma nova sub-rede gerem os recursos em execução. Eles não afetam diretamente a conexão com as VMs.
- O plano de dados (aplicativo) descreve o tempo de execução do próprio aplicativo e envolve a interação com instâncias que não passam pela API do Azure. Por exemplo, acessar seu site ou extrair dados de uma instância do SQL Server em execução ou de um servidor MongoDB são interações de plano de dados ou aplicativo. Outros exemplos incluem copiar um blob de uma conta de armazenamento e acessar um endereço IP público para usar o protocolo RDP (Remote Desktop Protocol) ou o Secure Shell (SSH) na máquina virtual. Estas operações mantêm a aplicação em execução em processos, redes e armazenamento.
O plano de dados é o mesmo entre o modelo de implantação clássico e as pilhas do Resource Manager. A diferença é que, durante o processo de migração, a Microsoft traduz a representação dos recursos do modelo de implantação clássico para o modelo da pilha do Resource Manager. Como resultado, você precisa usar novas ferramentas, APIs e SDKs para gerenciar seus recursos na pilha do Gerenciador de Recursos.
Nota
Em alguns cenários de migração, a plataforma Azure para, desaloca e reinicia as suas máquinas virtuais. Isso causa um breve tempo de inatividade do plano de dados.
A experiência de migração
Antes de iniciar a migração:
- Confirme que os recursos que quer migrar não utilizam funcionalidades ou configurações não suportadas. Normalmente, a plataforma deteta estes problemas e gera um erro.
- Se você tiver VMs que não estão em uma rede virtual, elas serão interrompidas e deslocadas como parte da operação de preparação. Se você não quiser perder o endereço IP público, considere reservar o endereço IP antes de acionar a operação de preparação. Se as VMs estiverem em uma rede virtual, elas não serão interrompidas e deslocalizadas.
- Planeie a migração para ocorrer fora do horário de expediente, de modo a poder dar resposta a falhas inesperadas que possam surgir.
- Transfira a configuração atual das suas VMs com o PowerShell, os comandos da interface de linha de comandos (CLI) ou as APIs REST, de modo a facilitar a validação após a fase de preparação estar concluída.
- Atualize seus scripts de automação e operacionalização para lidar com o modelo de implantação do Resource Manager antes de iniciar a migração. Opcionalmente, pode efetuar operações GET quando os recursos estão no estado pronto.
- Avalie as políticas de controle de acesso baseado em função do Azure (Azure RBAC) configuradas nos recursos IaaS no modelo de implantação clássico e planeje após a conclusão da migração.
O fluxo de trabalho de migração é o seguinte:
Nota
As operações descritas nas seções a seguir são todas idempotentes. Se você tiver um problema diferente de um recurso sem suporte ou um erro de configuração, tente novamente a operação de preparação, anulação ou confirmação. O Azure tenta a ação novamente.
Validar
A operação de validação é o primeiro passo do processo de migração. O objetivo desta etapa é analisar o estado dos recursos que você deseja migrar no modelo de implantação clássico. A operação avalia se os recursos são capazes de migração (sucesso ou fracasso).
Selecione a rede virtual ou um serviço de nuvem (se não estiver em uma rede virtual) que deseja validar para migração. Se o recurso não for capaz de migração, o Azure listará os motivos.
Verificações não feitas na operação de validação
A operação de validação analisa apenas o estado dos recursos no modelo de implantação clássico. Ele pode verificar todas as falhas e cenários sem suporte devido a várias configurações no modelo de implantação clássico. Não é possível verificar todos os problemas que a pilha do Azure Resource Manager pode impor aos recursos durante a migração. Esses problemas só são verificados quando os recursos passam por transformação na próxima etapa da migração (a operação de preparação). A tabela a seguir lista todos os problemas não verificados na operação de validação:
| Verificações de rede não estão na operação de validação |
|---|
| Uma rede virtual com gateways ER e VPN. |
| Uma conexão de gateway de rede virtual em um estado desconectado. |
| Todos os circuitos ER são pré-migrados para a pilha do Azure Resource Manager. |
| A cota do Azure Resource Manager verifica se há recursos de rede. Por exemplo: IP público estático, IP público dinâmico, balanceador de carga, grupos de segurança de rede, tabelas de rotas e interfaces de rede. |
| Todas as regras do balanceador de carga são válidas na implantação e na rede virtual. |
| IPs privados conflitantes entre VMs desalocadas por parada na mesma rede virtual. |
Preparar
A operação de preparação é o segundo passo do processo de migração. O objetivo desta etapa é simular a transformação dos recursos IaaS do modelo de implantação clássico para recursos do Resource Manager. Além disso, a operação de preparação apresenta isso lado a lado para você visualizar.
Nota
Seus recursos no modelo de implantação clássico não são modificados durante esta etapa. É uma etapa segura para executar se você estiver experimentando a migração.
Selecione a rede virtual ou o serviço de nuvem (se não for uma rede virtual) que deseja preparar para a migração.
- Se o recurso não for capaz de migração, o Azure interromperá o processo de migração e listará o motivo pelo qual a operação de preparação falhou.
- Se o recurso for capaz de migração, o Azure bloqueará as operações do plano de gerenciamento para os recursos em migração. Por exemplo, não pode adicionar um disco de dados a uma VM em migração.
Em seguida, o Azure inicia a migração de metadados do modelo de implantação clássico para o Gerenciador de Recursos para a migração de recursos.
Após a conclusão da operação de preparação, você tem a opção de visualizar os recursos no modelo de implantação clássico e no Gerenciador de Recursos. A plataforma Azure cria um nome de grupo de recursos, com o padrão cloud-service-name>-Migrated, para cada serviço cloud no modelo de implementação clássica.
Nota
Não é possível selecionar o nome de um grupo de recursos criado para recursos migrados (ou seja, "-Migrated"). No entanto, após a conclusão da migração, você pode usar o recurso de movimentação do Gerenciador de Recursos do Azure para mover recursos para qualquer grupo de recursos desejado. Para obter mais informações, consulte Mover recursos para um novo grupo de recursos ou subscrição.
As duas capturas de tela a seguir mostram o resultado após uma operação de preparação bem-sucedida. O primeiro mostra um grupo de recursos que contém o serviço de nuvem original. O segundo mostra o novo grupo de recursos "-Migrated" que contém os recursos equivalentes do Azure Resource Manager.
Aqui está uma visão dos bastidores de seus recursos após a conclusão da fase de preparação. Observe que o recurso no plano de dados é o mesmo. Ele é representado no plano de gerenciamento (modelo de implantação clássico) e no plano de controle (Gerenciador de Recursos).
Nota
As VMs que não estão em uma rede virtual no modelo de implantação clássico são interrompidas e desalocadas nesta fase da migração.
Verificação (manual ou com script)
Na etapa de verificação, você tem a opção de usar a configuração baixada anteriormente para validar se a migração parece correta. Como alternativa, você pode entrar no portal e verificar as propriedades e os recursos para validar se a migração de metadados parece boa.
Se estiver a migrar uma rede virtual, a maioria das configurações de máquinas virtuais não são reiniciadas. Para aplicativos nessas VMs, você pode validar se o aplicativo ainda está em execução.
Você pode testar seus scripts operacionais e de monitoramento para ver se as VMs estão funcionando conforme o esperado e se os scripts atualizados funcionam corretamente. Quando os recursos estão no estado pronto, só são suportadas operações OBTER.
Não há uma janela de tempo definida antes da qual você precisa confirmar a migração. Pode permanecer neste estado o tempo que quiser. Contudo, o plano de gestão é bloqueado para estes recursos enquanto não abortar ou consolidar.
Se vir erros, pode sempre abortar a migração e regressar ao modelo de implementação clássica. Depois de voltar, o Azure abre as operações do plano de gerenciamento nos recursos, para que você possa retomar as operações normais nessas VMs no modelo de implantação clássico.
Abortar
Esta é uma etapa opcional se você quiser reverter suas alterações para o modelo de implantação clássico e interromper a migração. Esta operação exclui os metadados do Resource Manager (criados na etapa de preparação) para seus recursos.
Nota
Esta operação não pode ser feita depois de ter acionado a operação de confirmação.
Consolidação
Depois de concluída a validação, pode consolidar a migração. Os recursos não aparecem mais no modelo de implantação clássico e estão disponíveis apenas no modelo de implantação do Resource Manager. Os recursos migrados só podem ser geridos no portal novo.
Nota
Esta é uma operação idempotent. Se falhar, tente novamente a operação. Se continuar a falhar, crie um ticket de suporte ou crie um fórum nas Perguntas e Respostas da Microsoft
Fluxograma de migração
Aqui está um fluxograma que mostra como proceder com a migração:
Tradução do modelo de implantação clássico para recursos do Resource Manager
Você pode encontrar o modelo de implantação clássico e as representações dos recursos do Resource Manager na tabela a seguir. Atualmente, não são suportadas outras funcionalidades e recursos.
| Representação clássica | Representação do Resource Manager | Notas |
|---|---|---|
| Nome do serviço de nuvem (Nome do serviço hospedado) | Nome DNS | Durante a migração, é criado um grupo de recursos novo para cada serviço cloud, com o padrão de nomenclatura <cloudservicename>-migrated. Este grupo de recursos contém todos os seus recursos. O nome do serviço cloud converte-se um nome DNS que está associado ao endereço IP público. |
| Máquina virtual | Máquina virtual | As propriedades específicas de cada VM são migradas sem alterações. Determinadas informações do osProfile, como o nome do computador, não são armazenadas no modelo de implantação clássico e permanecem vazias após a migração. |
| Recursos de disco ligados à VM | Discos implícitos ligados à VM | Os discos não são modelados como recursos de nível superior no modelo de implementação Resource Manager. São migrados como discos implícitos na VM. Atualmente, apenas os discos que estão ligados a uma VM são suportados. As VMs do Resource Manager agora podem usar contas de armazenamento no modelo de implantação clássico, o que permite que os discos sejam facilmente migrados sem atualizações. |
| Extensões de VMs | Extensões de VMs | Todas as extensões de recursos, exceto as extensões XML, são migradas do modelo de implementação clássica. |
| Certificados de máquinas virtuais | Certificados no Azure Key Vault | Se um serviço de nuvem contiver certificados de serviço, a migração criará um novo cofre de chaves do Azure por serviço de nuvem e moverá os certificados para o cofre de chaves. As VMs são atualizadas, de modo a fazerem referência aos certificados no cofre de chaves. Não exclua o cofre de chaves. Isso pode fazer com que a VM entre em um estado de falha. |
| Configuração WinRM | Configuração WinRM em osProfile | A configuração Gestão Remota do Windows é movida sem quaisquer alterações como parte da migração. |
| Propriedade Availability-set | Recurso Availability-set | A especificação do conjunto de disponibilidade é uma propriedade na VM no modelo de implantação clássico. Como parte da migração, os conjuntos de disponibilidade convertem-se num recurso de nível superior. As configurações seguintes não são suportadas: múltiplos conjuntos de disponibilidade por serviço cloud, um ou mais conjuntos de disponibilidade juntamente com VMs que não estão em nenhum conjunto de disponibilidade num serviço cloud. |
| Configuração de rede numa VM | Interface de rede primária | A configuração de rede numa VM é representada como o recurso de interface de rede primária após a migração. Nas VMs que não estão numa rede virtual, o endereço IP é alterado durante a migração. |
| Várias interfaces de rede numa VM | Interfaces de rede | Se uma VM tiver várias interfaces de rede associadas a ela, cada interface de rede se tornará um recurso de nível superior como parte da migração, juntamente com todas as propriedades. |
| Conjunto de pontos finais com balanceamento de carga | Balanceador de carga | No modelo de implementação clássica, a plataforma atribuía um balanceador de carga implícito a cada serviço cloud. Durante a migração, é criado um recurso de balanceador de carga novo e o conjunto de pontos finais com balanceamento de carga converte-se em regras de balanceador de carga. |
| Regras NAT de entrada | Regras NAT de entrada | Os pontos finais de entrada definidos na VM são convertidos em regras de tradução de endereços de rede de entrada no balanceador de carga durante a migração. |
| Endereço VIP | Endereço IP público com o nome DNS | O endereço IP virtual torna-se um endereço IP público e está associado ao balanceador de carga. Os IPs virtuais só podem ser migrados se lhes tiverem sido atribuídos pontos finais de entrada. Para manter o IP, você pode convertê-lo em IP reservado antes da migração. Haverá tempo de inatividade de cerca de 60 segundos durante esta mudança. |
| Rede virtual | Rede virtual | A rede virtual é migrada, com todas as propriedades, para o modelo de implementação Resource Manager. É criado um grupo de recursos novo com o nome -migrated. |
| IPs Reservados | Endereço IP público com o método de alocação estática | Os IPs Reservados associados ao balanceador de carga são migrados, juntamente com a migração do serviço cloud ou da máquina virtual. IPs reservados não associados podem ser migrados usando Move-AzureReservedIP. |
| Endereço IP público por VM | Endereço IP público com o método de alocação dinâmica | O endereço IP público associado à VM é convertido como um recurso de endereço IP público, com o método de alocação definido como dinâmico. |
| NSGs | NSGs | Os grupos de segurança de rede associados a uma máquina virtual ou sub-rede são clonados como parte da migração para o modelo de implantação do Resource Manager. O NSG no modelo de implementação clássica não é removido durante a migração. No entanto, as operações do plano de gestão para o NSG são bloqueadas enquanto a migração está em curso. NSGs não associados podem ser migrados usando Move-AzureNetworkSecurityGroup. |
| Servidores DNS | Servidores DNS | Os servidores DNS associados a uma rede virtual ou à VM são migrados como parte da migração de recursos correspondente, juntamente com todas as propriedades. |
| UDRs | UDRs | As rotas definidas pelo utilizador associadas a uma sub-rede são clonados como parte da migração para o modelo de implementação Resource Manager. O URD no modelo de implementação clássica não é removido durante a migração. As operações do plano de gestão para o UDR são bloqueadas enquanto a migração está em curso. UDRs não associados podem ser migrados usando Move-AzureRouteTable. |
| Propriedade de reencaminhamento de IPs na configuração de rede de uma VM | Propriedade de reencaminhamento de IPs na NIC | A propriedade de reencaminhamento de IPs numa VM é convertida numa propriedade na interface de rede durante a migração. |
| Balanceador de carga com vários IPs | Balanceador de carga com vários recursos de IP público | Cada IP público associado ao balanceador de carga é convertido em um recurso IP público e associado ao balanceador de carga após a migração. |
| Nomes DNS internos na VM | Nomes DNS internos na NIC | Durante a migração, os sufixos de DNS internos das VMs são migrados para uma propriedade só de leitura com o nome “InternalDomainNameSuffix” na NIC. O sufixo permanece inalterado após a migração, e a resolução da VM deve continuar a funcionar como anteriormente. |
| Gateway de rede virtual | Gateway de rede virtual | As propriedades do gateway de rede virtual são migradas inalteradas. O VIP associado ao gateway também não muda. |
| Site de rede local | Gateway de rede local | As propriedades do site de rede local são migradas inalteradas para um novo recurso chamado gateway de rede local. Isso representa prefixos de endereço locais e o IP do gateway remoto. |
| Referências de ligações | Connection | As referências de conectividade entre o gateway e o site de rede local na configuração de rede são representadas por um novo recurso chamado Conexão. Todas as propriedades de referência de conectividade em arquivos de configuração de rede são copiadas inalteradas para o recurso Conexão. A conectividade entre redes virtuais no modelo de implantação clássico é obtida através da criação de dois túneis IPsec para sites de rede local que representam as redes virtuais. Isso é transformado para o tipo de conexão de rede virtual para rede virtual no modelo do Resource Manager, sem a necessidade de gateways de rede local. |
Alterações à automatização e às ferramentas após a migração
Como parte da migração de seus recursos do modelo de implantação clássico para o modelo de implantação do Resource Manager, você deve atualizar sua automação ou ferramentas existentes para garantir que ele continue a funcionar após a migração.
Próximos passos
- Visão geral da migração com suporte de plataforma de recursos IaaS do clássico para o Azure Resource Manager
- Planear a migração de recursos de IaaS do clássico para o Azure Resource Manager
- Usar o PowerShell para migrar recursos IaaS do clássico para o Azure Resource Manager
- Usar a CLI para migrar recursos IaaS do clássico para o Azure Resource Manager
- Migrar o Gateway de VPN da implementação Clássica para o Resource Manager
- Migrar circuitos de Rota Expressa e redes virtuais associadas do modelo clássico para o modelo de implantação do Resource Manager
- Ferramentas da comunidade para ajudar na migração de recursos IaaS do clássico para o Azure Resource Manager
- Consultar os erros de migração mais comuns
- Analise as perguntas mais frequentes sobre a migração de recursos IaaS do clássico para o Azure Resource Manager