Migrar imagem de disco bruto pela LAN

Aqui está a minha situação:

• Dois servidores dedicados no mesmo datacenter com Ethernet de gigabit entre eles.
• Ambos os servidores dedicados foram inicializados em um ambiente de resgate baseado no Debian Squeeze, com ferramentas e utilitários extras adicionados. Também há bastante espaço tmp (32 GB de RAM nas duas caixas) para baixar software, instalar pacotes e / ou compilar conforme necessário.
• Ambos os servidores dedicados têm aproximadamente 3 TB de espaço útil.
• O servidor "origem" possui discos de 4 x 1,5 TB no Hardware RAID-10 com um controlador de porta Adaptec 4.
• O servidor "destino" possui discos de 2 x 3 TB no Hardware RAID-1 com um controlador de porta Adaptec 2 - mesma geração que a outra, mas número diferente de portas.
• O número de blocos utilizáveis /dev/sdadifere em menos de 10 MB, mas a matriz do servidor de destino é, por algum motivo, alguns megas menor.
• As duas matrizes RAID são configuradas para usar toda a superfície do disco de todos os discos constituintes para criar um único volume RAID.
• O sistema operacional é inicializado no modo MBR; nenhuma inicialização UEFI é usada.

O que eu quero fazer:

• Copie, na camada de bloco, toda a imagem do sistema operacional (isso consiste apenas no carregador de inicialização GRUB2 na tabela de partições GPT, / partição de inicialização e / partição) do servidor "de origem" para o servidor "de destino".
• Se possível , a cópia deve ocorrer "ao vivo": isso significa que não tenho espaço suficiente para armazenar um arquivo adequado da imagem do disco no lado do destino, a menos que esteja descompactando a imagem do disco no disco rígido como a cópia está acontecendo . A conexão Ethernet de gigabit entre os servidores é confiável o suficiente para que eu me sinta confortável com isso e, é claro, executarei fscknas duas extremidades (origem e destino) para verificar se o sistema de arquivos está correto antes e após a transferência.
• Se possível , não transfira blocos pela rede, que não são usados ​​pelos sistemas de arquivos constituintes em cada partição (todas as partições são formatadas como ext4). Isso ocorre porque mais de 50% do disco "de origem" é espaço livre na /partição.
• Ajuste o tamanho da /partição para que, quando copiada, ela seja redimensionada para caber no tamanho um pouco menor do disco de destino.
• Quando a cópia for bem-sucedida, monte cada volume e corrija as referências aos IPs estáticos para refletir os IPs do novo servidor. (Pode fazer isso muito bem sem mais ajuda)

Minhas perguntas:

• Devo primeiro calcular a diferença (em bytes) entre o tamanho de /dev/sdacada servidor e depois usá-lo e2resizepara reduzir de maneira não destrutiva o tamanho da /partição no lado de origem, para que ela caiba no espaço do lado de destino?
• Devo executar ddno dispositivo de bloco bruto, /dev/sdada origem ao destino (acima ssh), ou devo criar um layout de partição equivalente no destino e executar ddem cada partição ? Observe que lidar com uma partição de cada vez me deixa com o problema do gerenciador de inicialização, mas se eu não fizer uma partição de cada vez, será ddnecessário interromper a transferência de dados depois de escrever tantos bytes quanto o destino puder conter (que, esperamos, "feche" o final da /partição no último bloco, logicamente "à direita de" todas as outras partições no layout da partição da fonte).

Alguns misc. especificidades:

• O sistema operacional host na caixa de origem é o Ubuntu Server 12.04 executando vários convidados OpenVZ
• Como as duas caixas são inicializadas no resgate, o acesso direto ao disco é possível sem esperar nenhuma alteração nos dados subjacentes pelo sistema operacional em execução.

Isso é confuso, mas factível.

Presumo aqui que /está ligado /dev/sda3e que /bootestá ligado /dev/sda1.

1. Reduza o sistema de arquivos no servidor antigo para o tamanho mínimo possível.

   oldserver # resize2fs -M /dev/sda3
   

2. Particione o disco do novo servidor com um tamanho idêntico /boot, espaço de troca e nova /partição (e qualquer outra coisa que você precise).

   newserver # parted /dev/sda
   

3. Copie os sistemas de arquivos /e /boot.

   oldserver # dd if=/dev/sda1 | ssh root@newserver "dd of=/dev/sda1"
   oldserver # dd if=/dev/sda3 | ssh root@newserver "dd of=/dev/sda3"
   

   Como a partição no novo servidor será um pouco menor que a do servidor antigo, você receberá uma No space left on devicemensagem falsa ao final disso. No entanto, como você encolheu o sistema de arquivos na etapa 1, isso não importa.

4. Redimensione o sistema de arquivos no novo servidor para o tamanho da partição.

   newserver # resize2fs /dev/sda3
   

5. Instale o GRUB no novo disco.

   newserver # mount /dev/sda3 /mnt
   newserver # mount /dev/sda1 /mnt/boot
   newserver # mount -o bind /dev /mnt/dev
   newserver # mount -o proc proc /mnt/proc
   newserver # chroot /mnt /bin/bash
   
   newserver(chroot) # grub-install /dev/sda
   newserver(chroot) # exit
   

6. Finalize o restante de suas correções (endereço IP etc.).

Você provavelmente pode encontrar uma maneira de evitar copiar o espaço livre da partição, mas provavelmente levará mais tempo para pesquisar do que apenas copiar tudo ...

Eu tinha mkfsnovos sistemas de arquivos no novo servidor e depois rsyncno servidor antigo. Isso é reinicializável, consistente e cada arquivo é facilmente verificável individualmente. Onde você está descartando seções não utilizadas do sistema de arquivos (não uma cópia forense), não vejo motivo para não usar esse método. Você precisaria executar novamente o GRUB, mas isso não deve ser um desafio.

Explicar uma cópia não processada que esteja ciente do sistema de arquivos levaria um tempo, então, a menos que você comente o porquê de minha solução rsync não funcionar, vou me poupar da digitação.

Se você REALMENTE deseja transferir dados em um nível de dispositivo de bloco, posso pensar em um truque bastante útil que eu estava usando para migrar servidores com um tempo de inatividade mínimo envolvido.

O problema é que você pode criar um espelho degradado no servidor de origem, com sua partição de dados sendo a única metade ativa do espelho, e exportar a partição de destino do segundo servidor via AOE (suponho que ambos os servidores estejam no mesmo domínio de broadcast). No servidor de origem, você conecta o dispositivo de bloco de rede ao seu espelho degradado para iniciar a reconstrução. Aguarde a conclusão da reconstrução, pare o espelho, remova o dispositivo exportado pelo AOE e você estará bem.

Um pouco mais de detalhes a seguir (vou tentar ser breve).

Componentes:

• mdadmcom seu modo de construção (espelho ad-hoc sem metadados);
• vblade para exportar dispositivo de bloco como dispositivo de rede AOE;
• aoe-tools para importar o dispositivo de bloco de rede AOE.

Você precisa criar uma tabela de partição no servidor de destino e encolher a partição de origem para que ela caiba no destino. Você pode instalar facilmente o GRUB no seu novo MBR; sincronizar apenas partições sobre a tabela de partições recém-criada é um pouco menos propenso a erros.

No lado de recebimento, você precisa exportar sua partição com a vbladeferramenta; no servidor de origem, você pode ver os dispositivos exportados após a instalação aoe-tools(execute aoe-discovere procure /dev/ether/por dispositivos).

Em seguida, você deve criar o dispositivo raid1 no servidor de origem com sua unidade de origem :

mdadm --build /dev/md0 -n2 -l1 --force /dev/sda

Depois disso, você pode examinar o espelho recém-construído:

mdadm --detail /dev/md0
cat /proc/mdstat

Neste ponto, você pode anexar com segurança a partição de destino exportada a esse espelho:

mdadm /dev/md0 --add /dev/ether/eX.Y

Depois, observe o progresso da sincronização:

watch -n5 cat /proc/mdstat

Após a sincronização, basta parar o espelho: mdadm --stop /dev/md0no servidor de origem, finalize o vbladeprocesso no servidor de destino, instale o GRUB no segundo servidor, altere seus endereços IP etc.

Na verdade, com esse truque, é possível mover o servidor entre caixas quase ao vivo, com tempo de inatividade apenas para reiniciar as caixas sincronizadas.

Por motivos de desempenho, também sugiro que você aumente a MTU do seu link (ou configure uma VLAN separada com jumbo-frames ativados, se possível).

Observe que você também pode usar algo como nbd-server/ nbd-client(ou até iSCSI, se você desejar) como uma alternativa ao AOE, mas o AOE ( vblade+ aoe-tools) tem uma interface muito simples e um ótimo desempenho (sem sobrecarga de TCP / IP),