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/sda
difere 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
fsck
nas 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/sda
cada servidor e depois usá-loe2resize
para 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
dd
no dispositivo de bloco bruto,/dev/sda
da origem ao destino (acimassh
), ou devo criar um layout de partição equivalente no destino e executardd
em 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ádd
necessá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.
linux
raid
migration
local-area-network
allquixotic
fonte
fonte
Respostas:
Isso é confuso, mas factível.
Presumo aqui que
/
está ligado/dev/sda3
e que/boot
está ligado/dev/sda1
.Reduza o sistema de arquivos no servidor antigo para o tamanho mínimo possível.
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).Copie os sistemas de arquivos
/
e/boot
.Como a partição no novo servidor será um pouco menor que a do servidor antigo, você receberá uma
No space left on device
mensagem falsa ao final disso. No entanto, como você encolheu o sistema de arquivos na etapa 1, isso não importa.Redimensione o sistema de arquivos no novo servidor para o tamanho da partição.
Instale o GRUB no novo disco.
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 ...
fonte
oldserver
eliminar a necessidade de copiar todo o espaço livre? Eu não me importo/boot
porque é muito pequeno, mas/
pelo menos eu poderia fazer isso, certo? Basta definir o setor final da partição para igual ao setor queresize2fs
define o final do setor FS. Bem, setor, bloco ... provavelmente bloco . Mas obrigado por isso! Isso é ótimo!/dev/sda3
para cerca de 1,3 TB e será copiado para uma partição no destino que espera armazenar cerca de 2,9 TB.Eu tinha
mkfs
novos sistemas de arquivos no novo servidor e depoisrsync
no 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.
fonte
partimage
pode fazer cópias não processadas com conhecimento do sistema de arquivos, mas não suportaext4
. Então lá vai o como uma opção ...rsync
está olhando mais agradável como uma opção, desde que ele preserva todos os controles de acesso discricionário (a lachmod
) e pode limpa copiar links simbólicos e arquivos de dispositivos ...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:
mdadm
com 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
vblade
ferramenta; no servidor de origem, você pode ver os dispositivos exportados após a instalaçãoaoe-tools
(executeaoe-discover
e procure/dev/ether/
por dispositivos).Em seguida, você deve criar o dispositivo raid1 no servidor de origem com sua unidade de origem :
Depois disso, você pode examinar o espelho recém-construído:
Neste ponto, você pode anexar com segurança a partição de destino exportada a esse espelho:
Depois, observe o progresso da sincronização:
Após a sincronização, basta parar o espelho:
mdadm --stop /dev/md0
no servidor de origem, finalize ovblade
processo 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),fonte
mdadm
? Estou usando RAID de hardware. E não tenho ideia do que é AOE e nunca usei o iSCSI. Não acho que meus servidores estejam no mesmo domínio de broadcast, apenas no mesmo datacenter. Há pelo menos um ou dois comutadores entre os servidores.nbd-server
enbd-client
pacotes).mdadm
é usado apenas para sincronizar dois dispositivos de bloco, nenhum metadado é gravado nobuild
modo, para que você possa usá-lo em cima de qualquer dispositivo de bloco (ele deve ser desmontado primeiro). O problema é que eu normalmente configuro um sistema novo em um mdadm raid1 degradado, mesmo que eu tenha um raide de hardware subjacente. Dessa forma, posso aplicar a técnica descrita sem precisar desmontar partições, reduzindo o tempo de inatividade da migração para um único tempo de reinicialização.