Mover um Volume Lógico diretamente de um servidor para outro através da rede?

11

Eu tenho uma máquina host KVM com várias VMs. Cada VM usa um volume lógico no host. Eu preciso copiar os LVs para outra máquina host.

Normalmente, eu usaria algo como:

dd if=/the/logical-volume of=/some/path/machine.dd

Para transformar o LV em um arquivo de imagem e usar o SCP para movê-lo. Em seguida, use o DD para copiar o arquivo de volta para um novo LV no novo host.

O problema com esse método é que você precisa do dobro do espaço em disco que a VM usa nas duas máquinas. ie. um LV de 5 GB usa 5 GB de espaço para o LV e a cópia dd também usa 5 GB adicionais de espaço para a imagem. Isso é bom para pequenos LVs, mas e se (como é o meu caso) você tem um LV de 500GB para uma grande VM? A nova máquina host tem um disco rígido de 1TB, por isso não pode conter um arquivo de imagem de 500GB dd e ter um volume lógico de 500GB para copiar para e ter espaço para o host OS e espaço para outros convidados menores.

O que eu gostaria de fazer é algo como:

dd if=/dev/mygroup-mylv of=192.168.1.103/dev/newvgroup-newlv

Em outras palavras, copie os dados diretamente de um volume lógico para o outro através da rede e pule o arquivo de imagem intermediário.

Isso é possível?

    
por Nick 09.02.2012 / 02:16

5 respostas

21

Claro, é claro que é possível.

dd if=/dev/mygroup-mylv | ssh 192.168.1.103 dd of=/dev/newvgroup-newlv

Boom.

Faça um favor a si mesmo e use algo maior que o tamanho padrão do bloco. Talvez adicione bs = 4M (leitura / escrita em blocos de 4 MB). Você pode ver que há alguns detalhes sobre os blocos nos comentários; Se isso é algo que você está fazendo com bastante frequência, tire um tempinho para experimentar algumas vezes diferentes com blocos diferentes e veja por si mesmo o que faz com que você tenha as melhores taxas de transferência.

Respondendo a uma das perguntas dos comentários:

Você pode enviar a transferência por meio de pv para obter estatísticas sobre a transferência. É muito melhor do que a saída que você recebe do envio de sinais para dd .

Eu também direi que enquanto claro que usar o netcat - ou qualquer outra coisa que não imponha a sobrecarga da criptografia - será mais eficiente, eu geralmente acho que a velocidade adicional vem com alguma perda de conveniência. A menos que eu esteja se movendo em torno de conjuntos de dados realmente grandes, eu costumo ficar com o ssh apesar da sobrecarga porque na maioria dos casos tudo já está configurado para o Just Work.

    
por 09.02.2012 / 02:27
17

Aqui está uma versão otimizada, que mostra o progresso usando pv e usa BS para trechos maiores e também usa gzip para reduzir o tráfego da rede.

Isso é perfeito ao mover os dados entre conexões lentas, como servidores de internet. Eu recomendo rodar o comando dentro de uma tela ou sessão tmux. Dessa forma, a conexão ssh ao host de onde você executa o comando pode ser desconectada sem problemas.

$ dd if=/dev/volumegroupname/logicalvolume bs=4096 | pv | gzip | \
    ssh [email protected] 'gzip -d | dd of=/dev/volumegroupname/logicalvolume  bs=4096'
    
por 12.06.2013 / 14:52
3

Que tal usar um velho amigo para fazer isso? NetCat.

No sistema que está perdendo o tipo de volume lógico

  • $ dd if = / dev / [diretório] / [nome do volume] | nc -l [qualquer porta de alto número]

Em seguida, no sistema de recebimento. tipo

  • $ nc -w 10 [ip ou nome] [porta] | dd de = / dev / [diretório / [nome do volume]

Voila. Sim, alguns irão reclamar que o netcat é UDP. Então, se sua LAN tem perda de pacotes, você realmente precisa consertar a LAN IMHO.

Traduzindo, orgin caixa dd este arquivo e canaliza para nc (netcat) que vai escutar desta porta. No sistema de recebimento, o netcat irá esperar 10 segundos se ele não receber nenhum dado antes de fechar para [ip ou nome] em [port], então canalizar os dados para dd para escrevê-lo.

    
por 13.06.2013 / 18:32
1

Primeiro eu tiraria um instantâneo do lv:

lvcreate --snapshot --name my_shot --size <thesize> /dev/<name of vg>/<name of lv>

Depois disso, você precisa criar um novo lv no novo host (por exemplo, usando lvcreate) com o mesmo tamanho. Então você pode copiar diretamente os dados para o novo host. Aqui está o meu exemplo do comando copy:

dd if=/dev/vg0/my_shot bs=4096 | pv | ssh root@some_host -C 'dd of=/dev/vg1/<created lv> bs=4096'

Eu usei o procedimento para copiar uma máquina virtual mantida proxmox para outro host. O volume lógico continha vários LVs adicionais que eram mantidos pela própria VM.

    
por 16.07.2016 / 17:14
1

Primeiro, verifique se o volume lógico não está montado. Se estiver e você quiser fazer uma "cópia quente", crie um instantâneo primeiro e use isso: lvcreate --snapshot --name transfer_snap --size 1G

Eu tenho que transferir muitos dados (7 TB) entre dois Servidores conectados de 1Gbit, então eu precisava da maneira mais rápida possível de fazê-lo.

Você deve usar o SSH?

O uso do ssh está fora de questão, não por causa de sua criptografia (se você tem uma CPU com suporte a AES-NI, não atrapalha muito), mas por causa de seus buffers de rede. Aqueles que não estão escalando bem. Existe uma versão do Ssh corrigida que resolve este problema, mas como não existem pacotes pré-compilados, não é muito conveniente.

Usando compactação

Ao transferir imagens brutas de disco, é sempre aconselhável usar a compactação. Mas você não quer que a compactação se torne um gargalo. A maioria das ferramentas de compactação unix, como o gzip, são de thread único, portanto, se a compactação saturar uma CPU, será um gargalo. Por essa razão, eu sempre uso o pigz, uma variante do gzip que usa todos os núcleos do processador para compactação. E isso é necessário de você querer ir acima e acima das velocidades GBit.

Usando criptografia

Como dito antes, o ssh é lento. Se você tem uma CPU AES-NI, isso não deve ser um gargalo. Então, ao invés de usar o ssh, podemos usar o openssl diretamente.

Velocidades

Para lhe dar uma ideia do impacto na velocidade dos componentes, aqui estão os meus resultados. Essas são velocidades de transferência entre dois sistemas de produção, lendo e gravando na memória. Seus resultados reais dependem da velocidade da rede, da velocidade do disco rígido e da velocidade da CPU da fonte! Estou fazendo isso para mostrar que pelo menos não há queda no desempenho. %código% Conclusão: usar a compactação dá uma aceleração perceptível, pois reduz muito o tamanho dos dados. Isso é ainda mais importante se você tiver velocidades de rede mais lentas. Ao usar a compactação, observe o uso de sua CPU. Se o uso for maximizado, você pode tentar sem ele. Usando a compressão como um pequeno impacto nos sistemas AES-NI, apenas porque rouba cerca de 30 a 40% da CPU da compressão.

Usando a tela

Se você está transferindo muitos dados como eu, você não quer que ele seja interrompido por uma desconexão de rede do seu cliente ssh, então é melhor começar com a tela em ambos os lados. Esta é apenas uma nota, não vou escrever um tutorial de tela aqui.

Deixa a cópia

Instale algumas dependências (na origem e no destino): Simple nc dd: 5033164800 bytes (5.0 GB, 4.7 GiB) copied, 47.3576 s, 106 MB/s +pigz compression level 1 (speed gain depends on actual data): network traffic: 2.52GiB 5033164800 bytes (5.0 GB, 4.7 GiB) copied, 38.8045 s, 130 MB/s +pigz compression level 5: network traffic: 2.43GiB 5033164800 bytes (5.0 GB, 4.7 GiB) copied, 44.4623 s, 113 MB/s +compression level 1 + openssl encryption: network traffic: 2.52GiB 5033164800 bytes (5.0 GB, 4.7 GiB) copied, 43.1163 s, 117 MB/s

crie um volume no destino com o mesmo tamanho da fonte. Se não tiver certeza, use o lvdisplay na fonte para obter o tamanho e criar o alvo, por exemplo: apt install pigz pv netcat-openbsd

em seguida, prepare o destino para receber os dados:

lvcreate -n lvname vgname -L 50G

e quando estiver pronto, inicie a transferência na fonte:

nc -l -p 444 | openssl aes-256-cbc -d -salt -pass pass:asdkjn2hb | pigz -d | dd bs=16M of=/dev/vgname/lvname

Nota: Se você estiver transferindo os dados localmente ou não se importar com a criptografia, basta remover a parte Openssl de ambos os lados. Se você se importa, asdkjn2hb é a chave de criptografia, você deve alterá-lo.

    
por 10.07.2018 / 10:33

Tags