Migrar imagem bruta do disco pela LAN

Question

Aqui está minha situação:

• Dois servidores dedicados no mesmo datacenter com gigabit ethernet entre eles.
• Ambos os servidores dedicados inicializaram em um ambiente de recuperação baseado no Debian Squeeze com ferramentas extras e utilitários adicionados. Também muito espaço tmp (32GB de RAM em ambas as caixas) para baixar software, instalar pacotes e / ou compilar conforme necessário.
• Ambos os servidores dedicados têm aproximadamente 3 TB de espaço utilizável.
• O servidor de "origem" tem 4 discos de 1,5 TB no Hardware RAID-10 com um controlador de porta Adaptec 4.
• O servidor de "destino" tem 2 discos de 3 TB no Hardware RAID-1 com um controlador de porta Adaptec 2 - a mesma geração que o outro, mas um número diferente de portas.
• O número de blocos utilizáveis em /dev/sda difere em menos de 10 MB, mas a matriz do servidor de destino é, por algum motivo, alguns megas menor.
• Ambos os arrays RAID são configurados para usar toda a superfície do disco de todos os discos constituintes para criar um único volume RAID.
• O sistema operacional inicializa no modo MBR; não é utilizada a inicialização do UEFI.

O que eu quero fazer:

• Copie, na camada de bloco, toda a imagem do sistema operacional (isso consiste apenas no gerenciador de inicialização GRUB2 na tabela de partição GPT, na partição / boot e na partição /) do servidor de "origem" para o servidor de "destino". li>
• 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 de destino, a menos que eu esteja descompactando a imagem do disco no disco rígido enquanto a cópia está ocorrendo . A conexão ethernet gigabit entre os servidores é confiável o suficiente para me sentir confortável com isso, e é claro que vou executar fsck em ambas as extremidades (origem e destino) para verificar se o sistema de arquivos está OK antes e depois da 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 ela for copiada, ela seja redimensionada para caber no tamanho apenas um pouco menor do disco de destino.
• Quando a cópia for bem-sucedida, monte cada volume e corrija referências a IPs estáticos para refletir os IPs do novo servidor. (Pode fazer isso muito bem sem qualquer ajuda adicional)

Minhas perguntas:

• Devo primeiro calcular a diferença (em bytes) entre o tamanho de /dev/sda em cada servidor e, em seguida, usar e2resize para reduzir não destrutivamente o tamanho da partição / no lado da fonte para que caiba no espaço do lado do destino?
• Devo executar dd no dispositivo de bloco bruto, /dev/sda da origem para o destino (acima de ssh ), ou devo criar um layout de partição equivalente no destino e executar dd em cada partição ? Observe que manipular uma partição por vez me deixa o problema do carregador de inicialização, mas se eu não fizer isso uma partição de cada vez, dd precisará saber para parar de transferir dados depois de ter escrito quantos bytes destino pode manter (o que esperamos que "feche" o final da partição / no último bloco, que é logicamente "à direita de" todas as outras partições no layout da partição da origem).

Alguns poucos. especificidades:

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

Answer 1

Isso é confuso, mas factível.

Presumo que / esteja em /dev/sda3 e que /boot esteja em /dev/sda1 .

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

   oldserver # resize2fs -M /dev/sda3
   

2. Particione o novo disco do servidor com uma partição /boot , swapspace e nova / de tamanho idêntico (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 mensagem No space left on device espúria no final disso. No entanto, desde que 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. Conclua o resto de seus ajustes (endereço IP, etc.).

Provavelmente você pode encontrar uma maneira de evitar a cópia do espaço livre da partição, mas provavelmente levará mais tempo para você pesquisar do que simplesmente copiar tudo ...

    

Answer 2

Eu tinha mkfs filesystems novos no novo servidor, então rsync eles do 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 nenhum motivo para não usar esse método. Você teria que executar novamente o GRUB, mas isso não deveria ser um desafio.

Explicar uma cópia bruta que reconhece o sistema de arquivos me levaria um tempo, então, a menos que você comente por que minha solução de rsync não funciona, vou me poupar da digitação.

    

Answer 3

Se você REALMENTE quiser 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 tempo de inatividade mínimo envolvido.

O problema é que você pode criar um espelho degradado no servidor de origem, com a partição de dados sendo a única metade ativa do espelho, depois 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 que ele comece a reconstrução. Aguarde até que a reconstrução esteja concluída, pare o seu espelho, remova o dispositivo exportado AOE e você está OK.

Seguem alguns detalhes mais detalhados (vou tentar resumir).

Componentes:

• mdadm com seu modo build (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ções no seu servidor de destino e, em seguida, reduzir a partição de origem para que ela caiba no destino. Você pode instalar facilmente o GRUB no seu novo MBR; sincronizar apenas as partições sobre a tabela de partições recém-criada é um pouco menos propenso a erros.

No lado do recebimento, você precisa exportar sua partição com a ferramenta vblade , no servidor de origem você pode ver os dispositivos exportados após instalar o aoe-tools (executar aoe-discover e depois ver /dev/ether/ nos dispositivos).

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

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

Depois disso, você pode examinar o espelho recém-criado:

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 conclusão da sincronização, basta parar o espelho: mdadm --stop /dev/md0 no servidor de origem, terminar vblade process no servidor de destino, instalar o GRUB no segundo servidor, alterar seus endereços IP, etc.

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

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

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