O que fazemos · Dados e web: Live migration e saída de hypervisor
Máquinas virtuais em execução movem-se entre hosts sem parar, e instalações inteiras saem do VMware ou de servidores KVM autónomos para a nossa private cloud com Oracle Linux Virtualization Manager (OLVM). Live quando é seguro ser live, como cópia fria verificada quando não é, e sempre com o original mantido intacto até o novo lado estar comprovado.
O que é
Três tipos de mudança sob uma única disciplina:
- Live migration: uma máquina virtual KVM em execução, memória e disco, movida entre hosts com uma pausa medida em milissegundos. É assim que fazemos manutenção de hosts e substituição de hardware sem agendar downtime da sua parte.
- Saídas de hypervisor: instalações VMware e hosts KVM autónomos movidos para OLVM, onde as VM arrancam a partir de storage all-flash de classe empresarial sobre fabrics Fibre Channel redundantes, com backup e monitorização desde o primeiro dia.
- Mudanças de site: ambientes inteiros relocalizados entre os nossos datacenters, mantendo os seus endereços e as suas identidades.
Como o construímos
Uma regra de decisão antes de um único byte se mover. Se a geração de CPU, a infraestrutura de rede por baixo e a versão do hypervisor se mantiverem compatíveis, a VM move-se live. Quando tudo muda ao mesmo tempo, não arriscamos: a VM é desligada, copiada, redefinida e arrancada a frio no destino, e a origem fica intocada como rollback.
Live migration como deve ser. Usamos o percurso de migração direto do libvirt com cópia de storage e auto-converge, para que até as VM mais ocupadas convirjam. O destino é preparado primeiro: storage pools, bridges e interfaces VLAN e, para layouts de disco invulgares, uma imagem pré-criada exatamente com o tamanho da origem.
Reconstruir o stateless, replicar o stateful. Numa saída, preferimos muitas vezes uma reconstrução limpa a partir de especificações medidas em produção. As camadas web e de aplicação são reconstruídas a partir da configuração; a base de dados move-se por replicação, pelo que a transição final (cutover) é uma promoção com segundos de diferença.
Um appliance de migração construído para o efeito. As conversões correm num servidor de migração dedicado com storage all-flash NVMe e SSD, ligado diretamente ao nosso fabric. Converte guests de outros hypervisors e transmite imagens de disco KVM diretamente para discos criados pela plataforma de destino, preservando endereços MAC, modo de firmware e tipo de máquina, para que a VM arranque à chegada.
Auditada contra a API, não contra as notas de construção. Cada VM é verificada contra o próprio virtualization manager (topologia de CPU, garantias de memória, interfaces de rede, rotas, discos, hostname) antes de qualquer dado se mover. As VM são dimensionadas corretamente e nunca recebem mais vCPU do que os núcleos de um socket de CPU.
Windows tratado. Os drivers e as guest tools são arrumados, as tools do hypervisor antigo removidas só depois de o disco de arranque correr em VirtIO, e o Active Directory e o licenciamento verificados depois da mudança.
Ensaios, calendário acordado. Cada conversão é ensaiada primeiro numa cópia. Se uma mudança puder tocar no seu tráfego, acordamos primeiro o momento consigo.
Do que o protege
- Downtime para manutenção de hosts, trabalhos de firmware ou substituição de hardware.
- Alterações de licenciamento das quais não tem saída.
- Uma migração que perde a origem antes de o destino funcionar.
- Uma mudança entre gerações de CPU que estraga um guest em silêncio.
- VM que chegam com a topologia errada, uma interface em falta ou um endereço perdido.
- Mudar os endereços de toda a sua instalação só para mudar de plataforma.
Na prática
Um load balancer, movido live. A VM de load balancer, muito ocupada, de uma editora de notícias foi migrada live entre hosts, com disco incluído, em 3 minutos e 5 segundos, com uma pausa de cerca de 300 milissegundos.
Um broadcaster nacional deixa o VMware. Reconstruímos a plataforma web de um broadcaster nacional do VMware para OLVM como VM corretamente dimensionadas, auditámos cada uma contra a API e movemos a base de dados por replicação. Um servidor de desenvolvimento passou pelo nosso appliance de migração e ficou pronto a arrancar em cerca de sete minutos e meio. O cutover ficou concluído há meses.
Um host KVM autónomo, importado. O servidor KVM autónomo de um cliente foi importado para OLVM a cerca de nove GiB por minuto, com todos os endereços intactos, porque o ensaio já tinha tratado da nomenclatura de interfaces do novo chipset virtual.
Uma instalação VDI mudou de país. Um ambiente de desktops virtuais mudou de Amesterdão para Atenas. Transportámos a sua subrede de gestão inteira pela nossa extensão de Layer 2, pelo que todos os desktop pools e entitlements passaram sem alterações, e todos os domain controllers foram verificados como saudáveis depois.
Porquê a EuroVPS
- Uma regra escrita para live versus frio, aplicada sempre.
- A origem mantida como rollback até o destino estar comprovado.
- Um appliance de migração dedicado, não um portátil e um fim de semana.
- Extensão de Layer 2 entre os nossos sites, para que mude sem alterar endereços.
- Cada VM auditada contra a API antes de os dados se moverem.
Perguntas frequentes
Conseguem mover as nossas VM sem as reconstruir? Sim, por conversão, com drivers e tools trocados numa ordem testada. Guardamos os originais até dar a sua aprovação.
As nossas VM mantêm os endereços IP? Podem. Com a extensão de Layer 2, os servidores mantêm os seus endereços e movem-se um de cada vez.
Quanto tempo fica a VM em pausa durante uma live migration? Normalmente uma fração de segundo no momento da comutação. As mudanças a frio entram numa janela acordada consigo.
E se algo correr mal a meio da mudança? A origem está inalterada. Voltamos atrás, descobrimos porquê e repetimos.
O que é o OLVM? Oracle Linux Virtualization Manager, gestão de classe empresarial para KVM standard. Sem lock-in proprietário.
A sair do VMware? Fale com um engenheiro.
O seu próximo parceiro de infraestrutura
Vamos analisar a sua infraestrutura.
Diga-nos o que executa hoje e o que precisa de melhorar. Um engenheiro vai analisar o seu pedido e ajudar a planear o passo seguinte.
+357 222 32280
Comecemos pela sua infraestrutura.
Um pouco de contexto ajuda-nos a começar a conversa certa.