Nota
O acesso a esta página requer autorização. Pode tentar iniciar sessão ou alterar os diretórios.
O acesso a esta página requer autorização. Pode tentar alterar os diretórios.
Este artigo fornece orientações para ajudar os decisores a definir a sua estratégia de migração para o Solução VMware no Azure, incluindo as fases de planeamento, execução e desativação.
O Solução VMware no Azure fornece um caminho estruturado para migrar cargas de trabalho baseadas em VMware para o Azure com alterações mínimas na aplicação. O sucesso depende de mais do que mover máquinas virtuais. As organizações precisam de políticas claras de migração, critérios de avaliação de carga de trabalho, padrões de validação e controlos de execução que reduzam riscos, mantenham a continuidade operacional e apoiem os objetivos de longo prazo da plataforma.
Recomendação: Defina a 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 o Solução VMware no Azure.
1. Planeamento da migração
Antes de desenhares qualquer coisa, constrói uma imagem clara do que migras, em que ordem e porquê. Use a metodologia Cloud Adoption Framework Plan para avaliar o seu património. O Solução VMware no Azure encaixa-se melhor numa abordagem de realojamento, onde precisa de mínima interrupção e sem modernização a curto prazo. Não é o local certo para todas as aplicações, e é na fase de planeamento que decide.
1.1 Descoberta e inventário
O Azure Migrate analisa o seu ambiente vSphere local e constrói um inventário das máquinas virtuais, do seu uso de recursos e das suas dependências. Estes dados informam tanto o dimensionamento (quantos hosts e que tipo de host) como o planeamento de ondas (quais as cargas de trabalho que se movem em conjunto). O Azure Migrate não realiza a transferência para o Solução VMware no Azure. Dá-te a evidência para dimensionar e sequenciar o projeto.
1.2 Estratégia de migração
A Solução VMware no Azure suporta principalmente a abordagem rehost. Aplicações que necessitem de um tratamento de refatoração ou rearquitetura podem ser melhor servidas por computação nativa do Azure. Registe estas decisões de modo a que o plano reflita escolhas deliberadas em vez de incumprimentos. Veja Selecionar uma estratégia de migração para a cloud.
1.3 Avaliação da carga de trabalho
Nem todas as cargas de trabalho são igualmente adequadas para o Solução VMware no Azure. Antes de atribuir cargas de trabalho às ondas de migração, avalie os seus requisitos técnicos, dependências operacionais e adequação à plataforma. Uma avaliação estruturada ajuda-o a identificar riscos precocemente, validar a adequação e garantir que os planos de migração refletem prioridades empresariais em vez de pressupostos.
1.3.1 Requisitos
Antes de atribuir uma carga de trabalho a uma vaga de migração, avalie os requisitos técnicos, operacionais e de negócio que influenciam o seu sucesso no Solução VMware no Azure. Esta avaliação ajuda-o a determinar a adequação da plataforma, identificar potenciais desafios de migração e fornecer a informação necessária para decisões de dimensionamento, sequenciação e prontidão. Ao avaliar cada carga de trabalho, foque-se em:
Requisitos de desempenho: Compreenda as necessidades de CPU, memória, IOPS de armazenamento e débito de rede. Mapeie estes requisitos para SKUs do host Solução VMware no Azure e políticas de armazenamento vSAN, incluindo configuração RAID e definições de falhas a tolerar (FTT).
Dependências da aplicação: Identifique com que sistemas cada carga de trabalho comunica. As dependências determinam o planeamento da sua vaga de migração e se os sistemas dependentes precisam de se mover em conjunto.
Requisitos de compatibilidade: Confirme que sistemas operativos convidados e software de terceiros são suportados no Solução VMware no Azure. A maioria das cargas de trabalho executadas em vSphere no local é executada no Solução VMware no Azure sem modificações, mas valide em vez de presumir e certifique-se de testar a sua abordagem de reversão para migrações problemáticas.
Requisitos de rede: Documente os segmentos de rede, endereços IP, configurações DNS e regras de firewall que cada carga de trabalho exige. Identificar cargas de trabalho sensíveis à latência e garantir que a arquitetura de rede está otimizada para suportar as suas exigências.
1.3.2 Tratamento da carga de trabalho
A avaliação da carga de trabalho identifica o que uma carga de trabalho precisa. O tratamento da carga de trabalho determina que ação tomar. Os decisores devem avaliar se cada aplicação pertence ao Solução VMware no Azure, se deve permanecer on-premises ou se partes da aplicação são melhor servidas por serviços nativos do Azure. Para cada carga de trabalho, determine:
Se a carga de trabalho pertence a esse lugar. Cargas de trabalho que já correm bem no vSphere são candidatos naturais, especialmente aquelas sem plano de modernização a curto prazo. Para uma carga de trabalho prestes a ser descontinuada ou substituída por uma solução SaaS, pondere se migrá-la acrescenta valor ou se deve manter-se onde está até ao fim de vida.
Se todas as camadas devem estar ali. Uma carga de trabalho frequentemente tem mais do que um nível, como uma interface web e uma base de dados. Pode executar as máquinas virtuais da aplicação no Solução VMware no Azure e ligá-las a serviços de dados nativos do Azure, como o Base de Dados SQL do Azure. Essa configuração oferece-lhe as vantagens de uma base de dados gerida a par das suas cargas de trabalho no VMware e reduz os custos do seu host e do licenciamento VMware.
1.4 Prontidão para a migração
Defina os requisitos mínimos operacionais, de desempenho, segurança e governação que cada carga de trabalho deve cumprir antes de ser aprovado para uso em produção.
Aplique uma estrutura de validação consistente em cada vaga de migração. O quadro deve definir as verificações obrigatórias, os critérios de aprovação e as evidências que as equipas devem apresentar antes da aprovação da transição. No mínimo, valide:
Estado de funcionamento da replicação do HCX
Rotatividade de segmentos NSX
Saúde do hospedeiro ESXi
Acessibilidade da identidade e da autenticação a partir do segmento-alvo
Saúde dos serviços de apoio, como backup e monitorização
Decida se as equipas devem captar métricas de desempenho base do ambiente de origem antes da migração. Estas medições fornecem um ponto de referência para validar o desempenho pós-migração e identificar regressões.
Antes da comutação, exija que as equipas determinem se os registos DNS externos, as configurações dos balanceadores de carga, os pontos finais das aplicações ou outras dependências de conectividade requerem atualizações. Incluir todas as alterações necessárias no plano de transição de ondas para reduzir o risco de interrupção do serviço.
1.5 Sequência de migração do Solução VMware no Azure
A sequenciação de migração determina quais cargas de trabalho passam para o Solução VMware no Azure primeiro, segundo, e assim sucessivamente. Um bom planeamento de ondas reduz o risco e evita perturbações desnecessárias.
Agrupar por dependência: Utilize os dados de dependência da descoberta para encontrar conjuntos de máquinas virtuais que trabalham em estreita, como um servidor de aplicações e a sua base de dados. Mova-os na mesma vaga para que o tráfego não tenha de atravessar a rede a cada pedido quando um componente ainda permanece nas instalações.
Mapear as regras existentes: Documente quaisquer regras de afinidade ou anti-afinidade do seu ambiente local e planeie como as reproduzir. As políticas de colocação do Solução VMware no Azure impõem a afinidade entre máquina virtual e host, o que é importante para restrições de licenciamento como o SQL Server e para necessidades rigorosas de desempenho.
Sequência por risco: Comece com cargas de trabalho de menor risco, como sistemas não de produção ou aplicações com poucas dependências. A sua equipa constrói confiança no processo antes de este assumir aplicações críticas para o negócio. Mude para cargas de trabalho de maior complexidade à medida que ganha experiência.
Alinhe com os planos de extensão da rede: Baseie a sequência na estrutura da sua rede no local. Quando várias aplicações partilham um segmento de rede, migre-as na mesma onda ou em ondas consecutivas. Depois, pode cortar o segmento para uma rede nativa do Solução VMware no Azure rapidamente e remover a extensão temporária.
1.6 Ferramentas de migração
Use o VMware HCX para mover cargas de trabalho para o Solução VMware no Azure com o mínimo de interrupções. O HCX Enterprise está incluído sem custos adicionais e instala-se por defeito, desbloqueando opções como Replication Assisted vMotion e Mobility Optimized Networking. Não precisas de usar HCX, e também podes 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, geralmente funciona mais rápido do que os métodos em massa. A migração assistida por replicação e a migração em massa podem ser mais lentas na Geração 2 atualmente, por isso planeie janelas mais longas e agende as fases em conformidade. Consulte as considerações de design de cloud privada do Solução VMware no Azure Geração 2.
1.6.2 Governação da extensão da rede
Algumas equipas tratam a extensão da rede como um design permanente. Não é. Mantém as extensões abertas apenas durante a janela de migração. A extensão de rede HCX estende uma rede on-premises para o Solução VMware no Azure na Camada 2, o que permite que as cargas de trabalho mantenham os seus endereços existentes durante a mudança. Este design evita reconfigurar as aplicações desde o início e implica compromissos que o decisor deve governar.
Dependência local. Uma rede alargada normalmente mantém o seu gateway on-premises, pelo que a carga de trabalho ainda depende do local de origem após a sua mudança.
Encaminhamento ineficiente. O tráfego pode voltar ao ambiente local e regressar, um padrão conhecido como “tromboning”, o que aumenta a latência e os pontos de falha.
Defina uma política firme. Estende uma rede apenas quando uma carga de trabalho não pode alterar o seu endereço, e remove todas as extensões quando as cargas de trabalho mudarem. Avalie primeiro a sua rede local para saber quais os segmentos que precisam de extensão e por quanto tempo. Essa avaliação serve de base tanto ao seu plano de implementação por fases como ao cronograma da extensão. A rede otimizada para mobilidade pode reduzir o tromboning em casos específicos, por isso confirme as configurações suportadas antes de a ativar. Veja Configurar extensão de rede HCX.
2. Preparação para a migração
A sequência de implementação seguinte reflete as dependências entre estágios. Cada passo assume que o passo anterior está completo e validado.
Zona de aterragem da plataforma: Garanta que todos os serviços centralizados de redes, identidade, segurança e monitorização necessários estão prontos para se integrar com as cargas de trabalho do Azure VMware. Aplique as linhas de base de governação e segurança via Azure Policy à hierarquia do seu grupo de gestão que o ajudam a cumprir os seus requisitos de conformidade. A Geração 2 implementa-se na sua rede virtual, por isso uma linha de base de política que impõe regras rigorosas sobre grupos de segurança de rede ou tabelas de roteamento pode bloquear a implementação. Remova essas políticas específicas da rede virtual da nuvem privada antes de implementar, e depois volte a aplicá-las. Planeie esta exceção na sua linha de base para que a governação não atrase o lançamento.
Zonas de aterragem da carga de trabalho: Coloque as suas zonas de aterragem da carga de trabalho (subscrições) no grupo de gestão correto, online ou interno ("Corp").
Intervalos de endereços IP: Reserve, no mínimo, um bloco de endereços /22 para a nuvem privada. Na Geração 2, reserve também dois blocos /24 adicionais para gestão do HCX e uplink. Confirme que nenhum destes intervalos se sobrepõe ao seu espaço de endereços on-premises, Azure ou outro espaço de endereços na cloud. Não é possível corrigir facilmente esta condição após a implantação. Ver considerações de design da Geração 2.
Pedido de quota: Solicite a quota antecipadamente, pois a alocação pode demorar até cinco dias úteis. Peça capacidade suficiente para crescimento e recuperação após desastre, como a redundância N+1, que corresponde a um anfitrião além do necessário para a carga de trabalho. Confirme a licença Portable VMware Cloud Foundation que as novas implementações exigem. Ver Solicitar quota de anfitrião.
Implementação da cloud privada do Solução VMware no Azure: Aprovisione a cloud privada de Geração 2 na respetiva rede virtual do Azure. Veja Criar uma nuvem privada de Geração 2.
Configuração de rede e identidade: Associe a rede de cloud privada ao seu hub e estabeleça conectividade local. Ligue o vCenter Server à sua fonte de identidade externa para que os administradores iniciem sessão com contas geridas em vez de credenciais integradas partilhadas.
Monitorização e gestão: Encaminhe os registos para a sua solução de gestão de registos e configure alertas de Saúde do Serviço. Integra as máquinas virtuais convidadas através do Azure Arc para poderes governá-las com as mesmas ferramentas do Azure que usas noutros locais.
Instalação do HCX: Instale o HCX e teste a conectividade entre sites antes de iniciar a primeira fase.
3. Execução da migração
Defina o que significa "feito" antes de cada onda. Uma onda está completa quando a carga de trabalho é validada, a extensão da rede é removida e a aplicação está saudável no seu estado permanente.
Defina critérios de reversão antes de cada fase e teste o procedimento de reversão antes de migrar os sistemas de produção. O HCX suporta migração reversa, e a abordagem exata depende do tipo de migração que usaste. Os critérios de sucesso das ondas incluem:
Todas as máquinas virtuais da onda correm no Solução VMware no Azure e já não dependem da extensão de rede para tráfego de produção.
Cada aplicação é acessível pelos seus utilizadores e pelos seus sistemas dependentes.
Todas as máquinas virtuais aparecem nas suas ferramentas de monitorização sem avisos ou erros.
O rollback já não é necessário e podes formalmente encerrá-lo.
O desempenho da aplicação iguala ou supera a linha base.
As cargas de trabalho cumprem os seus requisitos de segurança e conformidade.
A carga de trabalho foi integrada com sucesso em 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. Validar que as cargas de trabalho funcionam corretamente no novo ambiente, confirmar que as adaptações temporárias da migração foram removidas e desativar formalmente a infraestrutura de origem. Manter a sua infraestrutura nas instalações pode resultar em dependências não detetadas e não documentadas. Uma avaliação disciplinada e um processo de desativação garantem que a organização realiza os benefícios esperados da migração sem acarretar custos ou riscos operacionais desnecessários.
4.1 Prontidão de produção pós-transição
Impor critérios pós-transição que confirmem que a carga de trabalho se comporta como esperado. Verifique a acessibilidade da rede e a resolução dos nomes. Verifique a função da aplicação e a comunicação com os sistemas dependentes. Depois de cada máquina virtual se mover, confirme que arranca, que os seus recursos correspondem ao plano e que a política de armazenamento correta se aplica. Compare o desempenho com a linha base pré-migração.
Decida a sua política de paridade. A decisão-chave é se uma carga de trabalho migrada deve atingir a paridade total com o estado on-premises antes de a considerar pronta para produção, ou se permite desvios temporários. Muitas organizações exigem paridade de desempenho imediata para sistemas de contacto com o cliente, mas concedem às aplicações internas um curto período de estabilização com um prazo fixo de remediação.
4.2 Validação de conectividade
Valide a conectividade de ponta a ponta na Solução VMware no Azure, no Azure, no local, na internet e na resolução de nomes. Execute testes de fumaça da aplicação para confirmar que a carga de trabalho cumpre o seu propósito. Confirme se os registos de nomes externos ou as definições do balanceador de carga precisam de ser atualizados no âmbito da transição.
Se construiu uma instância secundária do Solução VMware no Azure para recuperação de desastres, certifique-se de que é acessível tanto a partir da instância principal como de quaisquer clientes ou serviços de suporte que precisem de se ligar a ela caso esteja ativada.
4.3 Dissolução da extensão da rede
Quando todas as cargas de trabalho de um segmento estendido tiverem sido movidas, remova a extensão de camada 2 do HCX e confirme que o gateway nativo do Solução VMware no Azure encaminha corretamente. Não mantenha uma extensão instalada durante mais tempo do que o necessário para a migração.
4.4 Desativar o ambiente de origem
O descomissionamento libera formalmente a capacidade de origem, licenças e cobertura operacional. Trate-a como uma entrega governada em vez de uma tarefa de limpeza. Se não fizer a desativação, paga por infraestrutura inativa e fica exposto a riscos de segurança. Utilize Desativar cargas de trabalho de origem após a migração para a cloud para definir a ordem das operações, o período de retenção das cópias de segurança de origem, as aprovações necessárias para desligar os sistemas de origem e os critérios para recuperar licenças e hardware.
Passos seguintes
Design da carga de trabalho: