Transferir 15 TB de pequenos arquivos


79

Estou arquivando dados de um servidor para outro. Inicialmente, comecei um rsynctrabalho. Levou duas semanas para criar a lista de arquivos apenas para 5 TB de dados e outra semana para transferir 1 TB de dados.

Então tive que interromper o trabalho, pois precisamos de algum tempo de inatividade no novo servidor.

Foi acordado que iremos tará-lo, pois provavelmente não precisaremos acessá-lo novamente. Eu estava pensando em dividi-lo em pedaços de 500 GB. Depois tardisso, eu iria copiá-lo ssh. Eu estava usando tare pigzainda é muito lento.

Há uma melhor forma de fazê-lo? Eu acho que os dois servidores estão no Redhat. O servidor antigo é o Ext4 e o novo é o XFS.

Os tamanhos dos arquivos variam de alguns kb a poucos mb e existem 24 milhões de jpegs em 5 TB. Então, acho que entre 60 e 80 milhões por 15 TB.

edit: Depois de jogar com rsync, nc, tar, mbuffer e pigz por alguns dias. O gargalo será a E / S do disco. Como os dados são distribuídos por 500 discos SAS e cerca de 250 milhões de jpegs. No entanto, agora eu aprendi sobre todas essas boas ferramentas que eu posso usar no futuro.



2
Uma opção é criar os arquivos tar compactados em uma unidade externa e movê-los para o novo sistema. O disco extra acelerará a criação dos arquivos tar (não gravará nos discos existentes no sistema, possivelmente ao tentar ler 15 TB deles) e não amarrará o novo servidor.
Brian

4
Há uma melhor forma de fazê-lo? - Sim, a replicação DFS do Windows Server 2012 R2 prepararia isso em cerca de 10 horas . E sincronizaria as alterações e continuaria de onde parou após a reinicialização.
TessellatingHeckler

27
@TessellatingHeckler: então você sugere que o OP migre do Redhat para o Windows antes de arquivar?
Thomas Weller

12
@ThomasWeller Eles perguntaram "existe uma maneira melhor?", E existe. Não faço nenhuma recomendação de que eles usem da melhor maneira. Eles são livres para usar comandos em um canal que não pode se recuperar de interrupções, não verifica o conteúdo do arquivo, não pode relatar o status da cópia, não pode usar blocos copiados anteriormente para evitar a cópia de partes de arquivos, não tem implícito suporta cópias de baixa prioridade, não pode ser pausado, não menciona cópias de ACLs e precisa de alguém para permanecer conectado para executá-las. Qualquer outra pessoa que o acompanhe, no entanto, pode estar interessado - ou ser solicitado a dizer "x faz isso no Linux".
TessellatingHeckler

Respostas:


64

Eu tive resultados muito bons usando tar, pigz(gzip paralelo) e nc.

Máquina de origem:

tar -cf - -C /path/of/small/files . | pigz | nc -l 9876

Máquina de destino:

Extrair:

nc source_machine_ip 9876 | pigz -d | tar -xf - -C /put/stuff/here

Para manter o arquivo:

nc source_machine_ip 9876 > smallstuff.tar.gz

Se você quiser ver a taxa de transferência, apenas passe pvdepois pigz -d!


3
FYI, você pode substituir pigzcom gzipou removê-lo completamente, mas a velocidade será significativamente mais lento.
H0tw1r3 09/09/2015

10
Como isso pode ser aceito se o OP já tentou tare pigz? Eu não entendo ... #
9306 Thomas Weller

5
@ThomasWeller, onde você conseguiu que ele tentasse pigz? A partir da pergunta, parece que ele só tentou rsyncaté agora e estava pensando em usar tarpara dividir e agrupar os dados. Especialmente se ele não usou a opção -z/ --compressno rsync, pigzteoricamente poderia ajudar significativamente.
Doktor J

1
@ThomasWeller sim, de fato, eu já tentei tar e pigz, mas não nc. Eu estava usando ssh, então isso acrescentou muito mais sobrecarga.
Lbanz 10/09/2015

2
@lbanz que simplesmente significa que tarnão está produzindo dados com rapidez suficiente para pigzusar muita CPU para compactação. Ler muitos arquivos pequenos envolve muito mais syscalls, muito mais buscas em disco e muito mais sobrecarga do kernel do que ler o mesmo número de bytes de arquivos maiores, e parece que você está simplesmente engarrafando em um nível fundamental.
Hbbs

21

Eu me ateria à solução rsync. O rsync moderno (3.0.0+) usa a lista de arquivos incremental, portanto, não é necessário criar a lista completa antes da transferência. Portanto, reiniciar não exigirá a transferência completa novamente em caso de problemas. A divisão da transferência por diretório de primeiro ou segundo nível otimizará ainda mais isso. (Eu usaria rsync -a -Pe acrescentaria --compressse sua rede fosse mais lenta que suas unidades.)


Estou usando o rsync 2.6.8 no servidor antigo. Como é uma daquelas caixas em que não é permitido instalar / atualizar nada conforme declarado pelo fornecedor ou anula a garantia. Eu posso atualizá-lo e ver se é mais rápido.
Lbanz 10/09/2015

18
Encontre (ou construa) um binário rsync vinculado estaticamente e execute-o em sua casa. Espero que isso não estrague a garantia.
Fox

Que tal unison? Como isso se compara rsync?
Gwyneth Llewelyn

15

Configure uma VPN (se for a Internet), crie uma unidade virtual de algum formato no servidor remoto (torne ext4), monte-a no servidor remoto e monte-a no servidor local (usando um protocolo em nível de bloco como o iSCSI ) e use dd ou outra ferramenta em nível de bloco para fazer a transferência. Você pode copiar os arquivos da unidade virtual para a unidade real (XFS) conforme sua conveniência.

Duas razões:

  1. Sem sobrecarga do sistema de arquivos, que é o principal culpado pelo desempenho
  2. Sem procurar, você está olhando para leitura / gravação seqüencial nos dois lados

3
Ignorar o sistema de arquivos é bom. Copiar em nível de bloco de um sistema de arquivos montado para leitura e gravação é uma péssima idéia. Desmonte ou monte primeiro somente leitura.
JB.

Ter uma cópia de 15 TB também é uma porcaria. Isso significa que o novo servidor precisa mínimo 30.
Arthur Kay

3
Se o servidor estiver usando LVM, pode-se fazer uma captura instantânea somente leitura do sistema de arquivos e copiá-la. Sobrecarga de espaço apenas para as alterações no sistema de arquivos que ocorrem enquanto o instantâneo é lido.
liori 10/09/2015

9

Se o servidor antigo estiver sendo descomissionado e os arquivos puderem ficar offline por alguns minutos, geralmente será mais rápido retirar as unidades da caixa antiga e conectá-las ao novo servidor, montá-las (novamente on-line agora) e copiar os arquivos para os novos servidores discos nativos.


2
É cerca de 1PB de unidades de 2TB, por isso é demais.
Lbanz 10/09/2015

3

Use o mbuffer e, se estiver em uma rede segura, você pode evitar a etapa de criptografia.


3

(Muitas respostas diferentes podem funcionar. Aqui está outra.)

Gere a lista de arquivos com find -type f(isso deve terminar em algumas horas), divida-a em pequenos pedaços e transfira cada pedaço usando rsync --files-from=....


3

Você já considerou sneakernet? Com isso, quero dizer transferir tudo para a mesma unidade e depois movê-la fisicamente.

há cerca de um mês, a Samsung lançou uma unidade de 16 TB (tecnicamente, é 15,36 TB), que também é um SSD: http://www.theverge.com/2015/8/14/9153083/samsung-worlds-largest-hard -drive-16tb

Eu acho que essa unidade faria quase por isso. Você ainda teria que copiar todos os arquivos, mas como você não possui latência de rede e provavelmente pode usar SATA ou uma técnica igualmente rápida, deve ser bem mais rápido.


2

Se houver alguma chance de obter uma alta taxa de sucesso ao deduplicar, eu usaria algo como borgbackup ou Attic.

Caso contrário, verifique a solução netcat + tar + pbzip2 , adapte as opções de compactação de acordo com o seu hardware - verifique qual é o gargalo (CPU? Rede? IO?). O pbzip2 se estenderia muito bem em todas as CPUs, oferecendo melhor desempenho.


O lzma ( xz) descompacta mais rapidamente que o bzip2 e funciona bem na maioria das entradas. Infelizmente, xza opção multithread do ainda não foi implementada.
Pedro Cordes

Normalmente, o estágio de compactação precisa de mais potência do que a descompactação; portanto, se a CPU for o fator limitante, o pbzip2 resultaria em melhor desempenho geral. A descompressão não deve afetar o processo, se as duas máquinas forem semelhantes.
Neutrinus

Sim, o que quero dizer é que é uma pena que não exista um lzma multi-thread de fluxo único. Embora para este caso de uso, de transferir sistemas de arquivos inteiros de dados, pigzo prob. seja o compressor mais lento que você deseja usar. Ou até lz4. (Há uma lz4mtmulti-threaded-para-um-único-stream disponível Não passe muito eficiente (gera novos tópicos extremamente muitas vezes), mas não ter uma aceleração contínua.)
Peter Cordes

2

Você está usando o RedHat Linux, então isso não se aplicaria, mas como outra opção:

Eu tive muito sucesso usando o ZFS para armazenar milhões de arquivos, pois inodes não são um problema.

Se essa era uma opção para você, você poderia tirar instantâneos e usar o zfs para enviar atualizações incrementais. Eu tive muito sucesso usando esse método para transferir e arquivar dados.

O ZFS é principalmente um sistema de arquivos Solaris, mas pode ser encontrado nos illumos (fork de código aberto do OpenSolaris da Sun). Eu sei que também houve alguma sorte em usar o ZFS no BSD e Linux (usando o FUSE?) - mas não tenho experiência em tentar isso.


3
Houve uma porta Linux nativo não-FUSE do ZFS por um bom tempo agora: zfsonlinux.org
EEAA

1

Inicie um rsyncdaemon na máquina de destino. Isso acelerará muito o processo de transferência.


-1

Você pode fazer isso apenas com tar e ssh, assim:

tar zcf - <your files> | ssh <destination host> "cat > <your_file>.tar.gz"

Ou, se você deseja manter arquivos individuais:

tar zcf - <your files> | ssh <destination host> "tar zxf -"


1
Não será deduplicado, não há como retomar, compactando usando apenas uma CPU.
Neutrinus
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.