Migrar cargas de trabalho para Solução VMware no Azure

Este artigo fornece diretrizes para ajudar os tomadores de decisão a definir sua estratégia de migração para Solução VMware no Azure, incluindo fases de planejamento, execução e desativação.

Diagrama mostrando o processo do Microsoft Cloud Adoption Framework para adoção de Solução VMware no Azure.

Solução VMware no Azure fornece um caminho estruturado para migrar cargas de trabalho baseadas em VMware para Azure com alteração mínima do aplicativo. O sucesso depende de mais do que mover máquinas virtuais. As organizações precisam de políticas de migração claras, critérios de avaliação de carga de trabalho, padrões de validação e controles de execução que reduzam o risco, mantêm a continuidade operacional e dão suporte a objetivos de plataforma de longo prazo.

Recomendação: Defina sua estratégia de migração, abordagem de avaliação de carga de trabalho, sequência de migração e requisitos de validação antes de migrar cargas de trabalho para Solução VMware no Azure.

1. Planejamento de migração

Antes de projetar qualquer coisa, crie uma imagem clara do que você migra, em qual ordem e por quê. Use a metodologia Cloud Adoption Framework Plano para avaliar sua propriedade. O Solução VMware no Azure é mais adequado para uma abordagem de rehost, quando é necessária uma interrupção mínima e não há necessidade de modernização no curto prazo. Não é o ambiente certo para todos os aplicativos, e é na fase de planejamento que você decide isso.

1.1 Descoberta e inventário

Migrações para Azure examina seu ambiente do vSphere local e cria um inventário de máquinas virtuais, seu uso de recursos e suas dependências. Esses dados informam o dimensionamento (quantos hosts e qual tipo de host) e o planejamento de ondas (quais cargas de trabalho se movem juntas). Migrações para Azure não executa a mudança para Solução VMware no Azure. Ele fornece a evidência para dimensionar e sequenciar o projeto.

1.2 Estratégia de migração

O Solução VMware no Azure oferece suporte principalmente à abordagem de realocação. Aplicações que precisam de um tratamento de refatoração ou de rearquitetura podem ser mais bem atendidas pela computação nativa do Azure. Registre essas decisões para que o plano reflita escolhas deliberadas em vez de padrões. Consulte Selecionar uma estratégia de migração de nuvem.

1.3 Avaliação da carga de trabalho

Nem toda carga de trabalho é um candidato igualmente adequado para Solução VMware no Azure. Antes de atribuir cargas de trabalho a ondas de migração, avalie seus requisitos técnicos, dependências operacionais e ajuste de plataforma. Uma avaliação estruturada ajuda a identificar os riscos antecipadamente, validar a adequação e garantir que os planos de migração reflitam as prioridades de negócios em vez de suposições.

1.3.1 Requisitos

Antes de atribuir uma carga de trabalho a uma onda de migração, avalie os requisitos técnicos, operacionais e de negócios que influenciam seu sucesso em Solução VMware no Azure. Essa avaliação ajuda você a determinar a adequação da plataforma, identificar possíveis desafios de migração e fornecer as informações necessárias para decisões de dimensionamento, sequenciamento e preparação. Ao avaliar cada carga de trabalho, concentre-se em:

  • Requisitos de desempenho: Entenda as demandas de CPU, memória, IOPS de armazenamento e taxa de transferência de rede. Mapeie esses requisitos para os SKUs de host do Solução VMware no Azure e para as políticas de armazenamento do vSAN, incluindo a configuração de RAID e as configurações de FTT (falhas toleradas).

  • Dependências do aplicativo: Identifique com quais sistemas cada carga de trabalho se comunica. As dependências determinam o planejamento de ondas de migração e se os sistemas dependentes precisam se mover juntos.

  • Requisitos de compatibilidade: Confirme se há suporte para sistemas operacionais convidados e softwares de terceiros em Solução VMware no Azure. A maioria das cargas de trabalho executadas no vSphere no local pode ser executada no Solução VMware no Azure sem modificações, mas valide em vez de presumir e garanta que sua abordagem de reversão seja testada para migrações com problemas.

  • Requisitos de rede: Documente os segmentos de rede, endereços IP, configurações de DNS e regras de firewall que cada carga de trabalho requer. Identifique cargas de trabalho sensíveis à latência e verifique se a arquitetura de rede é otimizada para dar suporte às suas demandas.

1.3.2 Tratamento de carga de trabalho

A avaliação da carga de trabalho identifica o que uma carga de trabalho precisa. O tratamento de carga de trabalho determina qual ação deve ser tomada. Os tomadores de decisão devem avaliar se cada aplicativo pertence a Solução VMware no Azure, se ele deve permanecer local ou se partes do aplicativo são melhor atendidas por serviços nativos de Azure. Para cada carga de trabalho, determine:

  • Se a carga de trabalho deve estar ali. Cargas de trabalho que já funcionam bem no vSphere são candidatos naturais, especialmente aqueles sem plano de modernização de curto prazo. Para uma carga de trabalho que está caminhando para a aposentadoria ou para substituição por uma solução SaaS, avalie se migrá-la agrega valor ou se ela deve permanecer onde está até o fim de sua vida útil.

  • Se cada camada pertence a ela. Uma carga de trabalho geralmente tem mais de uma camada, como um front-end da Web e um banco de dados. Você pode executar as máquinas virtuais do aplicativo no Solução VMware no Azure e conectá-las a serviços de dados nativos de Azure, como Banco de Dados SQL do Azure. Essa configuração oferece benefícios de banco de dados gerenciado junto com suas cargas de trabalho do VMware e reduz os custos de host e licença do VMware.

1.4 Preparação para a migração

Defina os requisitos mínimos operacionais, de desempenho, de segurança e de governança que cada carga de trabalho deve atender antes de aprová-la para uso em produção.

Aplique uma estrutura de validação consistente em todas as ondas de migração. A estrutura deve definir as verificações necessárias, os critérios de aprovação e as evidências que as equipes devem fornecer antes da aprovação da transição. No mínimo, valide:

  • Status da replicação do HCX

  • Roteabilidade do segmento NSX

  • Integridade do host ESXi

  • Alcance de identidade e autenticação a partir do segmento de destino

  • Integridade dos serviços de suporte, como backup e monitoramento

Decida se as equipes devem capturar métricas de desempenho de linha de base do ambiente de origem antes da migração. Essas medidas fornecem um ponto de referência para validar o desempenho pós-migração e identificar regressões.

Antes da migração, exija que as equipes determinem se registros DNS externos, configurações do balanceador de carga, endpoints da aplicação ou outras dependências de conectividade precisam ser atualizados. Inclua todas as alterações necessárias no plano de transição da onda para reduzir o risco de interrupção dos serviços.

1,5 sequência de migração do Solução VMware no Azure

O sequenciamento de migração determina quais cargas de trabalho se movem para Solução VMware no Azure primeiro, segundo e assim por diante. Um bom planejamento de ondas reduz o risco e evita interrupções desnecessárias.

  • Agrupar por dependência: Use os dados de dependência da descoberta para localizar conjuntos de máquinas virtuais que funcionam em conjunto, como um servidor de aplicativos e seu banco de dados. Mova-os na mesma onda para que o tráfego não atravesse a rede para cada solicitação quando uma parte ainda aguarda no local.

  • Mapeie as regras existentes: Documente todas as regras de afinidade ou antiafinidade do seu ambiente on-premises e planeje como reproduzi-las. Solução VMware no Azure políticas de posicionamento impõem a afinidade entre máquina virtual e host, o que é importante para atender a restrições de licenciamento, como as do SQL Server, e a requisitos rigorosos de desempenho.

  • Sequência por risco: Comece com cargas de trabalho de menor risco, como sistemas de não produção ou aplicativos com poucas dependências. Sua equipe cria confiança com o processo antes de assumir aplicativos críticos aos negócios. Mova para cargas de trabalho de maior complexidade à medida que a experiência aumenta.

  • Alinhe-se aos planos de extensão da rede: Defina sua sequência com base na topologia da sua rede local. Quando vários aplicativos compartilham um segmento de rede, migre-os na mesma onda ou em ondas consecutivas. Em seguida, você pode migrar o segmento rapidamente para uma rede nativa da Solução VMware no Azure e remover a extensão temporária.

1.6 Ferramentas de migração

Use o VMware HCX para mover cargas de trabalho para Solução VMware no Azure com interrupção mínima. O HCX Enterprise é incluído sem custo adicional e instala por padrão, o que desbloqueia opções como vMotion Assistido por Replicação e Rede Otimizada para Mobilidade. Você não precisa usar o HCX e também pode trazer cargas de trabalho físicas usando uma solução de migração de parceiros.

1.6.1 Abordagem de migração

O vMotion move uma carga de trabalho em execução sem tempo de inatividade e, na Geração 2, ela geralmente executa mais rápido do que os métodos em massa. A migração em massa e assistida por replicação pode ser mais lenta na geração 2 hoje, portanto, planeje janelas mais longas e agende ondas adequadamente. Consulte as considerações sobre o design da nuvem privada de Geração 2 do Solução VMware no Azure.

1.6.2 Governança de extensão de rede

Algumas equipes tratam a extensão de rede como um design permanente. Não, não é. Mantenha as extensões abertas apenas para a janela de migração. A extensão de rede HCX estende uma rede local para Solução VMware no Azure na Camada 2, o que permite que as cargas de trabalho mantenham seus endereços existentes durante a mudança. Essa abordagem evita reconfigurar os aplicativos logo de início e envolve trade-offs que um tomador de decisão deve gerenciar.

  • Dependência local. Uma rede estendida geralmente mantém seu gateway no local, portanto a carga de trabalho ainda depende do local de origem após ser movida.

  • Roteamento ineficiente. O tráfego pode ir até o ambiente local e voltar, um padrão conhecido como tromboning, o que aumenta a latência e os pontos de falha.

Defina uma política firme. Estenda uma rede somente quando uma carga de trabalho não puder alterar seu endereço e remova cada extensão quando suas cargas de trabalho forem movidas. Avalie sua rede local primeiro para saber quais segmentos precisam de extensão e por quanto tempo. Essa avaliação alimenta seu plano de onda e sua linha do tempo de extensão. A Rede Otimizada para Mobilidade pode reduzir o tromboning em casos específicos, portanto, confirme as configurações com suporte antes de habilitá-la. Consulte Configurar a extensão de rede HCX.

2. Preparação da migração

A sequência de implantação a seguir reflete as dependências entre estágios. Cada etapa pressupõe que a etapa anterior seja concluída e validada.

  1. Zona de destino da plataforma: Verifique se todos os serviços de rede, identidade, segurança e monitoramento centralizados necessários estão prontos para integração com cargas de trabalho Azure VMware. Aplique as linhas de base de governança e segurança por meio de Azure Policy à hierarquia do grupo de gerenciamento que ajudam você a alcançar seus requisitos de conformidade. A Geração 2 é implantada na sua rede virtual; portanto, uma política de linha de base que aplica regras rígidas a grupos de segurança de rede ou tabelas de rotas pode bloquear a implantação. Remova essas políticas específicas da rede virtual da nuvem privada antes de implantar e aplica-las novamente depois. Planeje essa exceção em sua linha de base para que a governança não parasse a distribuição.

  2. Zonas de destino da carga de trabalho: Coloque as zonas de destino da carga de trabalho (assinaturas) no grupo de gerenciamento correto, online ou interno ("Corp").

  3. Intervalos de endereços IP: Reserve um bloco de endereços mínimo de /22 para a nuvem privada. Na Geração 2, reserve também mais dois blocos /24 para gerenciamento e uplink do HCX. Confirme se nenhum desses intervalos se sobrepõe ao espaço de endereços do ambiente local, do Azure ou de outras nuvens. Você não pode corrigir facilmente essa condição após a implantação. Confira as considerações de design da Geração 2.

  4. Solicitação de cota: Solicite a cota com antecedência, pois a alocação pode levar até cinco dias úteis. Solicite capacidade suficiente para comportar o crescimento e a recuperação de desastres, como redundância N+1, que consiste em um host a mais do que a carga de trabalho exige. Confirme a licença portátil do VMware Cloud Foundation que novas implantações exigem. Consulte cota do host de solicitação.

  5. Solução VMware no Azure implantação da nuvem privada: Provisione a nuvem privada de Geração 2 na sua rede virtual do Azure. Consulte Criar uma nuvem privada de Geração 2.

  6. Configuração de identidade e rede: Emparelhe a rede de nuvem privada ao hub e estabeleça conectividade local. Conecte o vCenter Server à fonte de identidade externa para que os administradores entrem com contas gerenciadas em vez de credenciais internas compartilhadas.

  7. Monitoramento e gerenciamento: Envie os logs para sua solução de gerenciamento de logs e configure alertas de Integridade do Serviço. Integre máquinas virtuais convidadas ao Azure Arc para que você possa governá-las com as mesmas ferramentas do Azure que usa em outros ambientes.

  8. Instalação do HCX: Instale o HCX e teste a conectividade site a site antes de iniciar a primeira onda.

3. Execução de migração

Defina o que significa "feito" antes de cada onda. Uma etapa é concluída quando a carga de trabalho é validada, a extensão da rede é removida e a aplicação está saudável em seu estado permanente.

Defina os critérios de reversão antes de cada onda e teste o caminho de reversão antes de migrar os sistemas de produção. O HCX dá suporte à migração reversa e a abordagem exata depende do tipo de migração usado. Os critérios de sucesso da onda incluem:

  1. Todas as máquinas virtuais na onda são executadas em Solução VMware no Azure e não dependem mais da extensão de rede para o tráfego de produção.

  2. Cada aplicativo é acessível por seus usuários e seus sistemas dependentes.

  3. Cada máquina virtual aparece em suas ferramentas de monitoramento sem avisos ou erros.

  4. O rollback não é mais necessário e você pode encerrá-lo formalmente.

  5. O desempenho do aplicativo iguala ou supera o valor de referência.

  6. As cargas de trabalho atendem aos requisitos de segurança e conformidade.

  7. A carga de trabalho foi incorporada com êxito às soluções de backup e recuperação de desastres.

4. Avaliação da migração e desativação

A migração não termina quando as cargas de trabalho são ativadas no Solução VMware no Azure. Valide que as cargas de trabalho operam corretamente em seu novo ambiente, confirme que os ajustes temporários para a migração foram removidos e desative formalmente a infraestrutura de origem. Manter sua infraestrutura on-premises como está pode resultar em dependências desconhecidas e não documentadas. Um processo de avaliação e encerramento disciplinado garante que a organização realize os benefícios esperados da migração sem carregar custos operacionais ou riscos desnecessários.

4.1 Prontidão para produção pós-entrada em operação

Exigir critérios pós-transição que confirmem que a carga de trabalho se comporte como esperado. Verifique a acessibilidade da rede e a resolução de nomes. Verifique a função de aplicativo e a comunicação com sistemas dependentes. Depois que cada máquina virtual é movida, confirme que ela é iniciada, que seus recursos correspondem ao plano e se a política de armazenamento correta se aplica. Compare o desempenho com a linha de base de pré-migração.

Decida sua política de paridade. A decisão principal é se uma carga de trabalho migrada deve atingir a paridade total com o estado local antes de chamá-la de pronta para produção ou se você permite desvios temporários. Muitas organizações exigem paridade imediata de desempenho para sistemas voltados para o cliente, mas concedem aos aplicativos internos um curto período de estabilização com um prazo de correção fixo.

4.2 Validação de conectividade

Valide a conectividade de ponta a ponta entre o Solução VMware no Azure, o Azure, o ambiente local, a internet e a resolução de nomes. Execute testes de fumaça do aplicativo para confirmar se a carga de trabalho atende à sua finalidade. Confirme se os registros de nome externo ou as configurações do balanceador de carga precisam de atualizações como parte da substituição.

Se você criou uma instância secundária de Solução VMware no Azure para recuperação de desastre, verifique se ela é acessível tanto da instância primária quanto de clientes ou serviços de suporte que precisam se conectar a ela se estiver ativado.

4.3 Dissolução de extensão de rede

Quando cada carga de trabalho em um segmento estendido for movida, remova a extensão HCX Layer 2 e confirme se o gateway nativo de Solução VMware no Azure é roteado corretamente. Não deixe uma extensão em vigor por mais tempo do que a migração precisa.

4.4 Desativar ambiente de origem

O descomissionamento libera formalmente a capacidade de origem, as licenças e a cobertura operacional. Trate-a como uma entrega governada em vez de uma tarefa de limpeza. Se você deixar de fazer o descomissionamento, continuará pagando por infraestrutura ociosa e ficará exposto a riscos de segurança. Use Desativar cargas de trabalho de origem após a migração para a nuvem para definir a ordem das operações, o período de retenção dos backups de origem, as aprovações necessárias para desligar os sistemas de origem e os critérios para a recuperação de licenças e hardware.

Próximas Etapas 

Design da carga de trabalho:

  • Last updated on