Migração de VMware para OpenShift com Cisco Isovalent, em ondas, mantendo seus endereços IP.
O Red Hat OpenShift Virtualization roda as suas máquinas virtuais atuais no Kubernetes, ao lado de contêineres. A Cisco Isovalent conecta as redes do vSphere e do OpenShift para que as aplicações migrem em ondas sem trocar de endereço IP. Os engenheiros sêniores da Ngenium avaliam o seu ambiente, projetam o destino em Cisco UCS, migram com o Migration Toolkit for Virtualization da Red Hat e protegem o resultado. Só serviços: você adquire a plataforma pelo seu parceiro ou distribuidor; nós fazemos a engenharia da migração.
Tudo entre um ambiente vSphere e uma plataforma OpenShift em operação.
Mover máquinas virtuais é a parte fácil. O que decide se uma migração dá certo é saber o que migra fácil e o que não, manter intacta a identidade de rede e reimplementar a intenção de segurança na nova plataforma.
Saiba o que migra fácil e o que não.
Inventário com RVTools e o OpenShift migration advisor gratuito da Red Hat, dependências das aplicações e um scorecard tipo semáforo: verde para VMs padrão de Windows e Linux, âmbar para discos grandes, clusters de disco compartilhado e GPU pass-through, repensar para recursos sem equivalente direto.
Uma plataforma que você consegue dimensionar e adquirir.
OpenShift Virtualization em Cisco UCS com gestão do ciclo de vida pelo Intersight, armazenamento com FlexPod e NetApp, FlashStack com Pure Storage ou OpenShift Data Foundation, e Cisco Unified Edge para filiais e plantas.
Migre hoje a VM 12 de 40 e mantenha o IP dela.
Cilium como rede do cluster com a Cisco Isovalent. O Private Networks dá às VMs redes isoladas no estilo VLAN; o Network Bridge conecta vSphere e OpenShift na camada 3, sem estender um domínio de camada 2, para que uma VM mantenha o endereço enquanto o resto do grupo espera.
A intenção do NSX, reimplementada, não copiada.
A base de regras atual classificada em necessárias, duplicadas, amplas demais e obsoletas, e depois reimplementada como políticas de rede do Cilium com modelos de aplicação reutilizáveis, com evidência de fluxos do Hubble antes e depois de cada virada.
Ondas controladas com o Red Hat MTV.
Mapeamentos de rede e de armazenamento, migração a quente ou a frio escolhida por carga, sequência por grupo de dependências, runbooks de virada e critérios de rollback. A migração a quente encurta a interrupção, mas não a elimina, e dizemos isso no primeiro dia.
Conclua a migração e depois aposente o VMware.
Validação pós-virada contra a linha de base de fluxos, modelos de políticas e monitoramento de fluxos exportados para o Splunk, padrões de backup e recuperação de desastres no OpenShift, e um plano para remover as dependências do bridge e desativar os hosts quando cada onda estiver estável.
Antes, durante, depois: um único time responsável.
Os mesmos engenheiros sêniores conduzem o trabalho do primeiro inventário ao último host desativado. Depois do go-live, a plataforma pode passar para operações de segurança gerenciadas por meio da nossa parceria estratégica com a Port53.
O que a sua equipe de VMware já conhece, no OpenShift.
- vCenter → o console web do OpenShift, com o Advanced Cluster Management para frotas
- Host ESXi → um nó de trabalho bare metal rodando KVM, provisionado pelo Intersight
- DRS e HA → o agendador, a saúde dos nós e as políticas de remoção, configurados por VM
- vMotion → migração ao vivo, sobre armazenamento compartilhado de leitura e gravação múltipla
- Port group e switch distribuído → uma network attachment definition com Cilium e Isovalent Private Networks
- Datastore → uma storage class e um persistent volume claim, mapeados um a um pelo MTV
- Firewall distribuído do NSX → políticas de rede do Cilium: a intenção é reimplementada, não convertida regra por regra
- VMware Tools → o agente convidado do QEMU, instalado durante ou depois da conversão
Por que os times recorrem à Ngenium.
- Só engenheiros sêniores — quem avalia o seu ambiente é quem conduz a virada.
- Só serviços — nunca revendemos hardware nem software e não temos margem de produto, então nossa orientação sobre migrar ou não, e o que migrar, segue o seu ambiente, não uma meta de vendas.
- Profundidade em redes e segurança — redes Cisco e Isovalent ao lado de Red Hat OpenShift, NetApp, Pure Storage e Splunk; a rede é onde as migrações de VMware costumam dar errado.
- Honestos sobre as concessões — a migração a quente ainda precisa de uma janela de virada, algumas cargas devem ficar ou ser reprojetadas, e operar duas plataformas custa dinheiro até a última onda.
Sobre a migração de VMware para OpenShift.
Nossas máquinas virtuais podem rodar no OpenShift sem virar contêineres?
Sim. O Red Hat OpenShift Virtualization roda máquinas virtuais em KVM, gerenciadas pelo OpenShift, ao lado de contêineres. Sistemas operacionais convidados e aplicações continuam como estão. A Red Hat também oferece a edição OpenShift Virtualization Engine como ponto de entrada só para VMs, que pode evoluir depois para a plataforma completa.
As aplicações vão manter seus endereços IP?
Podem manter. O Network Bridge da Cisco Isovalent conecta as redes do vSphere e do OpenShift na camada 3, sem estender um domínio de camada 2, para que uma VM mantenha o endereço ao migrar e as dependências continuem funcionando enquanto o resto do grupo espera. Validamos o projeto do bridge contra a matriz de suporte vigente durante a avaliação.
Quanta interrupção devemos esperar?
Alguma, para cada VM. A migração a quente copia os discos enquanto a VM continua rodando e depois desliga a origem para uma sincronização final na virada, o que encurta a interrupção, mas não a elimina. Registramos a tolerância à interrupção de cada aplicação na avaliação, escolhemos migração a quente ou a frio por carga e agendamos as viradas dentro das suas janelas de mudança.
A Ngenium vende OpenShift, Isovalent ou o hardware?
Não. A Ngenium é uma empresa só de serviços. Você adquire Red Hat OpenShift, Cisco Isovalent e Cisco UCS pelo seu parceiro ou distribuidor; a Ngenium avalia, projeta, migra e protege. Parceiros de canal da Cisco também nos chamam para entregar migrações aos seus clientes, inclusive em projetos white-label sob NDA.
O que não deveria migrar, ou deveria migrar por último?
VMs padrão de Windows e Linux em armazenamento compartilhado costumam migrar fácil. Discos grandes, clusters de disco compartilhado, GPU e PCI pass-through, cadeias longas de snapshots e convidados com condições especiais de software exigem mais planejamento, e recursos sem equivalente direto são reprojetados em vez de copiados. O scorecard de prontidão classifica cada grupo de cargas em verde, âmbar ou repensar antes de fazer um plano.
Planejando sair do VMware?
Fale com os engenheiros sêniores que avaliariam e migrariam o seu ambiente — não com um vendedor.