Xen movimento ao vivo

3

Estou pesquisando o XenServer da Citrix e (com 2 colegas) comparando-o com o VMware ESX e o Microsoft HyperV.

Em nossos testes, parece que a migração ao vivo do Xen está usando menos recursos do que o ESX da VMware e gostaria de saber por que isso acontece. Eu encontrou um artigo do ano passado que faz referência a um artigo de 2005, explicando o que realmente acontece com as páginas / memória durante a migração ao vivo.

Este é um extrato desse artigo sobre a transferência de memória:

Push phase- The source VM continues running while certain pages are pushed across the network to the new destination. To ensure consistency, pages modified during this process must be re-sent.

Stop-and-copy phase The source VM is stopped, pages are copied across to the destination VM, then the new VM is started.

Pull phase The new VM executes and, if it accesses a page that has not yet been copied, this page is faulted in ("pulled") across the network from the source VM.

Eu queria saber se a transferência de memória ainda acontece no mesmo moda como fez há 4 anos.

    
por Hofa 07.06.2009 / 16:51

1 resposta

5

Não sou especialista em migração do Xen e estou usando o servidor Xen de código aberto. Na minha experiência, o servidor Xen é muito eficiente com a migração desde que sua camada de armazenamento seja rápida - em nossa experiência, imagens de disco como arquivos em volume ocfs2 ou (godbidbis) montagem NFS eram muito mais lentas que dispositivos em bloco em uma SAN um volume de bloqueio compartilhado em uma montagem NFS. Nós não tivemos problemas com a corrupção do disco, mas tendemos a capturar instantaneamente as coisas (o estado do LVM2 e da VM) antes de iniciarmos a migração em um sistema muito ativo, só para ter certeza.

De acordo com o "Running Xen: Um Guia Prático para a Arte da Virtualização", de Matthews, Dow, e outros, Prentice Hall 2008, página 484,

The implementation of Xen's live migration involves the novel use of an iterative multipass algorithm that transfers the virtual machine guest memory in successive steps. After the source VM and the destination VM first negotiate to ensure resources are sufficient on the receiving machine, an initial pass over the guest's memory is performed with each page being transferred to the destination. On each successive iteration, only the guest memory that has been dirtied in the interim is sent. This process is executed until either the remaining number of dirty pages is sufficiently small enough(sic) that the remaining pages can be transmitted quickly or the number of dirty pages remaining to transfer in each pass is not decreasing. At that point, the system is actually quiesced and the final state sent to the new host and transfer of control to the new physical machine completed.

Parece que é semelhante à lista de etapas descrita acima, com a adição das iterações. Observe que a máquina pode estar fazendo E / S em dois locais com o estado atual da migração ativa.

Ao contrário do VMWare e do HyperV, o bom do XenServer é que há muitas pessoas que o rodaram e tentaram quebrá-lo dez vezes a partir do domingo, em ambientes de produção muito sérios. A migração ao vivo é nova para nós e nós não fazemos isso em um ambiente de produção porque temos preocupações de redundância (não triviais para escalar para n máquinas neste momento devido a ter nossas partições de dados compartilhados em volumes ocfs2), mas em nosso ambientes de teste, temos vindo a divertir máquinas saltitantes em todo o lugar.

    
por 08.06.2009 / 04:42