Início / server / Perguntas / 721223
Accepted
lbanz
Asked: 2015-09-10 07:23:47 +0800 CST

Transfira 15 TB de arquivos minúsculos

  • 772

Estou arquivando dados de um servidor para outro. Inicialmente comecei um rsynctrabalho. Demorou 2 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 encerrar o trabalho, pois precisamos de um tempo de inatividade no novo servidor.

Foi acordado que vamos descompactá-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 através de ssh. Eu estava usando tare pigzmas ainda é muito lento.

Existe uma maneira melhor de fazer isso? Acho que ambos os servidores estão no Redhat. O servidor antigo é Ext4 e o novo é XFS.

Os tamanhos dos arquivos variam de alguns kb a poucos mb e há 24 milhões de jpegs em 5 TB. Então, estou supondo que cerca de 60-80 milhões por 15 TB.

editar: Depois de brincar com rsync, nc, tar, mbuffer e pigz por alguns dias. O gargalo será o disco IO. Como os dados são distribuídos em 500 discos SAS e cerca de 250 milhões de jpegs. No entanto, agora aprendi sobre todas essas ferramentas legais que posso usar no futuro.

linux

11 respostas

  1. Best Answer

    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, basta canalizar pvdepois pigz -d!

    • 66

  2. Eu ficaria com a solução rsync. O rsync moderno (3.0.0+) usa lista de arquivos incremental, portanto, não precisa criar uma lista completa antes da transferência. Portanto, reiniciá-lo não exigirá que você faça toda a transferência novamente em caso de problemas. Dividir a transferência por diretório de nível superior ou secundário otimizará isso ainda mais. (Eu usaria rsync -a -Pe acrescentaria --compressse sua rede for mais lenta que suas unidades.)

    • 21

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

    Duas razões:

    1. Nenhuma sobrecarga do sistema de arquivos, que é o principal culpado pelo desempenho
    2. Sem busca, você está olhando para leitura/gravação sequencial em ambos os lados
    • 15

  4. Se o servidor antigo estiver sendo desativado e os arquivos puderem ficar off-line por alguns minutos, geralmente é mais rápido apenas retirar as unidades da caixa antiga e conectá-las ao novo servidor, montá-las (voltar a ficar on-line agora) e copiar os arquivos aos discos nativos dos novos servidores.

    • 10

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

    • 3

  6. (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

  7. Já pensou no tênisnet? Com isso, quero dizer transferir tudo para a mesma unidade e, em seguida, mover fisicamente essa unidade.

    cerca de um mês atrá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 esta unidade serviria para isso. Você ainda teria que copiar todos os arquivos, mas como não tem latência de rede e provavelmente pode usar SATA ou uma técnica igualmente rápida, deve ser muito mais rápido.

    • 3

  8. Se houver alguma chance de obter uma alta taxa de sucesso durante a desduplicação, 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 seu hardware - verifique qual é o gargalo (CPU? rede? IO?). O pbzip2 abrangeria perfeitamente todas as CPUs, proporcionando melhor desempenho.

    • 2

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

    Tive grande sucesso usando o ZFS para armazenar milhões de arquivos, pois os inodes não são um problema.

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

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

    • 2

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

    • 1

relate perguntas