Xen: Converta a imagem para lvm com tempo de inatividade mínimo

Question

Minhas metas:

• Converta todas as minhas DomUs de baseadas em imagem para baseadas em lvm
• Tempo de inatividade mínimo
• Impacto mínimo no desempenho em outras DomUs / Dom0

Meu plano / configuração:

Todas as minhas imagens estão em um grande volume lvm, todos os lvs para a nova configuração são criados com o sistema de arquivos (ext3 / ext4). Então, meu trabalho é fazer isso para todas as máquinas:

1. faça um instantâneo da grande imagem-lv
2. monte este instantâneo (por exemplo, em /tmp/img_snap/ )
3. montar a imagem em loopback (por exemplo, em /tmp/convert_src/ )
4. monte o novo lv (por exemplo, em /tmp/convert_dest )
5. rsync de /tmp/convert_src a /tmp/convert_dest
6. desmontar tudo
7. remova o instantâneo-lv
8. desligar o DomU
9. execute as etapas de 1 a 7 novamente
10. altere as configurações do disco na configuração do DomU
11. acenda o domU novamente

As etapas de 1 a 7 já estão no script, portanto, na etapa 9, só posso ativar esse script novamente. Isso significa um pouco de sobrecarga porque o instantâneo-lv não é necessário, mas estou bem ciente disso.

Devido ao fato de que a máquina original pode ser executada até a etapa 8 (e a etapa 9 deve copiar apenas o delta), o tempo de inatividade deve ser mínimo. Eu também renice e ionice do (s) processo (s) de rsync para que o impacto em todos os outros sistemas seja mínimo. Ou então eu pensei ...

• Debian lenny
• Xen 3.2 do debian
• HP ML350 G5 com seu controlador SmartArray (iirc: e220?)
• unidades conectadas via SATA

Perguntas / problemas:

• Essa abordagem é aprovada e testada com imagens pequenas, mas tenho algumas imagens grandes com 400 GB +. Isso leva séculos. Existem melhores abordagens?
• Às vezes - eu não sei exatamente o porquê - a carga do Dom0 aumenta muito, a máquina fica "presa" e eu recebo mensagens como INFO: task loop27:23352 blocked for more than 120 seconds , INFO: task pdflush:7329 blocked for more than 120 seconds. , ... e suas chamadas e outras coisas. Por que / quando? Eu não consigo descobrir um padrão? Há muito IO, também CPU? E acima de tudo: Por que os meus processos rsync não são bloqueados - renomei ( renice 20 -p $(pidof rsync) ) e ionizou ( ionice -c2 -n7 -p$pid ) eles - esses processos não deveriam ser os primeiros a serem bloqueados?
• Geralmente alguma sugestão e ideias de melhoria?

Answer 1

O rsync é uma ferramenta muito boa. Se você usá-lo, use as opções "-aSH --delete" para obter um destino idêntico (os carimbos ctime dos soft-links terão a hora atual).

De sua escrita, eu entendo que o tempo necessário para o rsync parece ser o seu principal problema, enquanto o desligamento / inicialização do DomUs é muito rápido (incluindo seus aplicativos, eu suponho).

Eu vejo outro problema em seu instantâneo de seu grande LV mantendo todas as suas Domus em execução. Se você tiver muitas solicitações de gravação, seu instantâneo será preenchido rapidamente - e o instantâneo diminuirá a velocidade das DomUs durante gravações.

Nesta situação, eu escolheria uma abordagem diferente: Use uma invasão de software 1 para espelhar suas imagens para seus novos LVs.

Se você quiser, pode combinar isso com snapshot / rsync para reduzir a quantidade de dados que precisam ser movidos. Mas IMHO o tempo necessário para obter aquele resolvido e com script não vale o esforço.

Então aqui está o plano - em ambos os casos você precisa de dispositivos de bloco (montar suas imagens em loopback):

A) Usando o md (configurado via mdadm) Escreva um script para:

1. Shut down DomU
2. Loopback-Mount the DomUs image
3. Create a degraded md-raid-1-device with that image
4. Boot up your DomU with "phy:mdN" as new disk device
5. Raise number of raid1-members from 1 to 2
6. add your target LV
7. Change the setup of your DomU so it will use the phy:vgX/lvY in the future
8. If the mirror is complete, restart your DomU with the new setup

Com o plano A, você tem duas paralisações com duração de uma reinicialização do DomU. O espelhamento ocorrerá em segundo plano o mais rápido possível.

Drawback: Todos os dados serão sincronizados (espelho RAW, não baseado no sistema de arquivos)

Você poderia contornar isso criando o md-raid1 com (--assume clean) sem degradação. Mas isso será complicado (você precisará do rsync para obter seus dados para o LV e espelhar o delta usando o md-bitmap).

B) Usando o drbd (configurado via /etc/drbd.conf) Se você planeja mudar para drbd no futuro, você deve seguir este caminho. Eu não testei isso, mas não consigo ver uma razão pela qual o drbd não deve espelhar entre 127.0.0.1 e 127.0.0.2; -)

Eu não testei isso, mas deve funcionar - e é mais complicado do que o plano A.

Retirada: complicada, não testada.

Mas: Se você quiser mudar para o drbd de qualquer maneira, você pode preparar seu DomU dessa maneira. Execute em modo desconectado até que seu cluster esteja pronto, então conecte, sincronize via IP e inicie a migração ao vivo ...