Como funciona o vMotion?

Padrão

Você com certeza já utilizou ou ouviu falar do VMware vMotion. Mesmo não trabalhando diretamente com VMware, essa palavra já deve ter passado pelos seus ouvidos em uma sala de infraestrutura. Obs.: Nesse post vou tratar especificamente do vMotion em sua forma básica. Storage vMotion, cold migration, long-distance vMotion e etc, estão fora do escopo.

Essa feature, além de ser um dos carros-chefe da VMware, é uma obra-prima de engenharia. Sua utilização é simples, intuitiva e seu funcionamento é extremamente eficiente. Eu como sou muito curioso, resolvi estudar a fundo como essa belezinha funciona. Se você, assim como eu, se interessa em entender o funcionamento de tudo, com certeza vai curtir esse post.

Comercialmente, o vMotion é anunciado como uma funcionalidade que permite a movimentação de máquinas virtuais entre hosts de forma online e sem interrupção. O vMotion, aliado ao DRS, FT e DPM, provê uma infraestrutura extremamente robusta. É possível efetuar manutenções programadas em seu ambiente com nenhum impacto ao negócio. Os usuários que consomem uma aplicação não percebem que uma máquina virtual está sendo movimentada de um host para outro em background. Que sonho, hein?

Mas, como já diria o grande sábio:

Como a virtualização já se tornou bastante difundida nas áreas de infraestrutura, podendo considerar até que se tornou um commodity, o vMotion passou a ser uma verdade absoluta, facilitando, e muito, a vida dos sysadmins.

O vMotion está sempre sendo melhorado pela VMware. Eu, pessoalmente, já fiz testes com migrações massivas, chegando até a ultrapassar a quantidade máxima de migrações simultâneas recomendas pela VMware, e NUNCA tive problema.

A partir da versão 5.1, existe a possibilidade de migrar máquinas virtuais mesmo sem um storage compartilhado. Na versão 6.0, foi introduzido o long-distance vMotion, permitindo a migração de máquinas virtuais até entre continentes.

Vamos dar início ao entendimento do que acontece por trás dessa imagem:

Primeiramente, é preciso garantir que a máquina virtual pode ser hospedada no host de destino. Antes de efetivamente migrar a VM, o vCenter faz uma série de checagens para garantir o sucesso da migração. Dentre elas: checar se os hosts de origem e destino possuem datastore em comum, checar se a máquina está em processo de instalação do VMware Tools, checar se o host de destino possui capacidade suficiente para hospedar a VM, checar se a VM está obstruindo uma regra de afinidade do DRS, checar se o host de destino possui uma interface vmkernel de vMotion, dentre outros checks.

Após atender a todos os pré-requisitos e disparar a migração, imediatamente o vCenter inicia uma VM “sombra” no host de destino e reserva os recursos necessários para a VM ser executada.

Obviamente, quando você faz um vMotion, você precisa mover a VM de um host para outro. Porém, a VM possui uma série de “estados” associados a ela. Sua VM possui vCPUs, periféricos virtuais e algum tipo de associação com rede e storage físicos. Portanto, é preciso mover isso de alguma forma. A VMware chama esse processo de checkpoint infrastructure que é embutido no ESXi e é utilizado também em outras funcionalidades como suspend/resume. A idéia é verificar o estado geral de todos os dispositivos da VM e salvá-lo de uma forma que possa ser transferido do host de destino para o host de origem “destrinchar” esse arquivo e recuperar completamente o estado original da VM.

O próximo passo é entender como funciona a movimentação dos discos virtuais. Como você já deve saber, o vMotion considera que os hosts de origem e destino possuem um datastore compartilhado (apesar de ser possível efetuar vMotion sem storage compartilhado, estamos abordando apenas o vMotion tradicional). Portanto, como o datastore é compartilhado entre os hosts, no processo de vMotion, basta efetuar a troca do ownership do VMDK de um host para outro. Bem fácil.

O processo de movimentação da rede da VM também é fácil. Tudo que precisa ser feito é “destrinchar” o device state efetuado pelo checkpoint infrastructure no host de destino. A partir daí, um pacote do tipo RARP (reverse ARP) é enviado ao switch para que ele saiba que a VM foi movimentada e para onde ele precisa enviar os novos pacotes.

Agora vem a parte mais interessante. Como o vMotion faz a migração de memória das máquinas virtuais?

Durante o processo de vMotion, a máquina de origem fica totalmente operacional pois, afinal de contas, essa é a intenção do vMotion, manter o estado da máquina virtual independente do host que irá hospedá-la. Levando em conta que os dois hosts possuam a interface vmkernel de vMotion, a memória da máquina virtual de origem é trafegada via rede e transferida para a máquina virtual de destino.

Porém, durante a migração, sua máquina continua manipulando a memória.

Para isso, depois que toda a memória foi movimentada, é disparado um processo de verificação do conteúdo de memória da máquina virtual. Esse processo se repete até não haver mais nenhum conteúdo de memória diferente entre VM de origem e VM de destino. Esse processo é chamado de iterative pre-copy. A partir do momento em que a velocidade de cópia (que depende da largura de banda de sua rede) for maior que a velocidade com que a máquina virtual está escrevendo em memória, o processo de movimentação de memória finalizará com sucesso. Por isso é importante que você utilize NICs de 10 GbE 🙂

iterative precopy in vMotion

Se pudéssemos resumir o processo de vMotion passo a passo, abstraindo em alto nível, teríamos o seguinte:

FUNCIONAMENTO DO VMWARE VMOTION

  1. Uma máquina virtual “sombra” é criada no host de destino. Lembrando que ambos os hosts possuem acesso a um datastore VMFS em comum.
  2. Através do checkpoint infrastructure, device state da máquina virtual é salvo.
  3. Inicia-se o processo de pre-copy de memória. O conteúdo de memória da máquina virtual de origem é transferido para a máquina virtual de destino. Enquanto a máquina virtual continua executando, seu conteúdo de memória é escrito em um bitmap provisório no host de origem.
  4. Inicia-se novamente uma verificação no conteúdo de memória para verificar as diferenças ocorridas durante a migração. Esse processo se repete até não haver nenhuma diferença entre as duas VMs. Quando não há mais nada a ser transferido, o host de destino destrincha o device state da máquina virtual de origem e replica na máquina virtual de destino. O vMotion troca o acesso ao VMDK do host de origem para o host de destino, pausa as vCPUs na VM de origem e inicia na VM de destino.
  5. Como o estado da rede já foi transferido dentro do device state, por último basta que o host ESXi envie um pacote RARP (reverse ARP) à rede física para que o tráfego seja direcionado para o novo host ao invés do antigo.

Porém, existem alguns fatores que podem afetar ou até impedir o vMotion:

  • Quanto mais carga o SO possui, mais ele escreve em memória. Isso fará com que o processo de vMotion demore muito mais. Se a velocidade com que a VM escreve em memória for maior do que sua rede consegue transferir, provavelmente o vMotion falhará.
  • O vMotion só é efetuado caso todos os pré-requisitos sejam atendidos. Se ele verificar que o host de origem não possui capacidade suficiente para suportar a VM, provavelmente falhará. Porém, é importante notar que se ele falhar no meio do processo, não há nenhum impacto sobre a VM.

Espero que você tenha lido até aqui. Se você leu tudo até aqui foi porque o assunto realmente te interessou, yey 🙂

Grande abraço!

Meu nome é Pedro Calixto e sou apaixonado por tecnologia. O intuito desse blog é compartilhar um pouco do meu conhecimento/experiência, com uma linguagem fácil e acessível para todo mundo.

Um comentário sobre “Como funciona o vMotion?

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *