Esta é uma situação em que estou frequentemente:
Eu quero transferir 320 GB de dados do servidor de origem para o servidor de destino (especificamente, os dados de /dev/sda ).
Eu pesquisei essa questão on-line e testei vários comandos. Aquele que aparece com mais frequência é isto:
ssh [email protected] 'dd bs=16M if=/dev/sda | gzip' > backup_sda.gz
Este comando provou ser muito lento (durou uma hora, apenas obteve cerca de 80 GB através dos dados). Demorou cerca de 1 minuto e 22 segundos para o pacote de teste de 1 GB e acabou sendo duas vezes mais rápido quando não foi comprimido. Os resultados também podem ter sido distorcidos pelo fato de que o arquivo transferido é menor que a quantidade de RAM no sistema de origem.
Além disso (e isso foi testado em amostras de 1GB), estou recebendo problemas se eu usar o comando gzip e dd ; o arquivo resultante tem uma soma de verificação diferente quando extraído no destino, do que se for canalizado diretamente. Ainda estou tentando descobrir por que isso está acontecendo.
Como os servidores estão fisicamente próximos uns dos outros, e você mencionou nos comentários que você tem acesso físico a eles, a maneira mais rápida seria tirar o disco rígido do primeiro computador, coloque-o no segundo e transfira os arquivos pela conexão SATA.
netcat é ótimo para situações como essa em que a segurança não é um problema:
# on destination machine, create listener on port 9999
nc -l 9999 > /path/to/outfile
# on source machine, send to destination:9999
nc destination_host_or_ip 9999 < /dev/sda
# or dd if=/dev/sda | nc destination_host_or_ip 9999
Note que, se você estiver usando dd do GNU coreutils, você pode enviar SIGUSR1 para o processo e ele irá emitir progresso para stderr. Para BSD dd , use SIGINFO .
pv é ainda mais útil para relatar o progresso durante a cópia:
# on destination
nc -l 9999 | pv > /path/to/outfile
# on source
pv /dev/sda | nc destination_host_or_ip 9999
# or dd if=/dev/sda | pv | nc destination_host_or_ip 9999
Faça a compactação rápida .
lz4 é sua melhor opção aqui:
LZ4 is a very fast lossless compression algorithm, providing compression speed at 400 MB/s per core, scalable with multi-cores CPU. It also features an extremely fast decoder, with speed in multiple GB/s per core, typically reaching RAM speed limits on multi-core systems.
Preferencialmente não procura desnecessariamente.
Se houver muito espaço livre no dispositivo a partir do qual você copia e o dispositivo não foi zerado recentemente, mas todos os sistemas de arquivos de origem devem ser copiados, provavelmente valerá a pena para primeiro fazer algo como:
</dev/zero tee >empty empty1 empty2; sync; rm empty*
Mas isso depende do nível em que você deve ler a fonte. Geralmente, é desejável ler o dispositivo do início ao fim de seu arquivo de dispositivo /dev/ some_disk , porque a leitura no nível do sistema de arquivos geralmente envolverá a procura de retorno e retorno disco não sequencialmente. E então o seu comando de leitura deve ser algo como:
</dev/source_device lz4 | ...
No entanto, se o sistema de arquivos de origem não deve ser transferido inteiro, a leitura no nível do sistema de arquivos é inevitável e, portanto, você deve ajustar seu conteúdo de entrada em um fluxo. O pax é geralmente a melhor e mais simples solução nesse caso, mas você também pode considerar mksquashfs .
pax -r /source/tree[12] | lz4 | ...
mksquashfs /source/tree[12] /dev/fd/1 -comp lz4 | ...
Fazer não criptografar com ssh .
Assim, você deve usar netcat ( ou < como eu prefiro, o nmap projeto é mais capaz ncat ) para uma cópia de rede simples, como já foi sugerido em outros lugares:
### on tgt machine...
nc -l 9999 > out.lz4
### then on src machine...
... lz4 | nc tgt.local 9999
Existem várias limitações que podem limitar a velocidade de transferência.
Existe sobrecarga de rede inerente em um canal de 1 Gbps. Geralmente, isso reduz o throughput REAL para 900Mbps ou menos. Então você tem que lembrar que este é o tráfego bidirecional e você deve esperar significativamente menos do que 900Mbps.
Mesmo usando um "novo roteador", você tem certeza de que o roteador suporta 1Gbps? Nem todos os novos roteadores suportam 1Gbps. Além disso, a menos que seja um roteador de nível corporativo, você provavelmente perderá largura de banda de transmissão adicional para o roteador sendo ineficiente. Embora com base no que encontrei abaixo, parece que você está ficando acima de 100 Mbps.
Pode haver congestionamento na rede de outros dispositivos que compartilham sua rede. Você já tentou usar um cabo conectado diretamente como disse que era capaz de fazer?
Qual é a quantidade de IO do seu disco que você está usando? Provavelmente, você está sendo limitado, não pela rede, mas pela unidade de disco. A maioria dos HDs de 7200rpm terá apenas 40MB / s. Você está usando raid em tudo? Você está usando SSDs? O que você está usando no final remoto?
Sugiro usar o rsync se for esperado que ele seja executado novamente para backups. Você também pode scp, ftp (s), ou http usando um downloader como filezilla na outra ponta, pois ele irá paralelizar as conexões ssh / http / https / ftp. Isso pode aumentar a largura de banda, já que as outras soluções estão em um único canal. Um único pipe / thread ainda é limitado pelo fato de ser single-threaded, o que significa que pode até mesmo ser ligado à CPU.
Com o rsync, você retira uma grande parte da complexidade de sua solução, além de permitir a compactação, a preservação de permissão e permitir transferências parciais. Existem vários outros motivos, mas geralmente é o método de backup preferido (ou executa os sistemas de backup) de grandes empresas. O Commvault usa o rsync sob seu software como mecanismo de entrega para backups.
Com base no seu exemplo de 80 GB / h, você está ficando em torno de 177 Mbps (22,2 MB / s). Eu sinto que você poderia facilmente dobrar isso com o rsync em uma linha dedicada de ethernet entre as duas caixas, já que consegui fazer isso em meus próprios testes com o rsync sobre gigabit.
Nós lidamos com isso regularmente.
Os dois métodos principais que costumamos usar são:
cp ou rsync
O primeiro depende de o drive poder ser fisicamente realocado. Isso nem sempre é o caso.
O segundo funciona surpreendentemente bem. Geralmente, maximizamos uma conexão de 1gbps com facilidade com montagens diretas do NFS. Você não chegará a lugar algum próximo a isto com scp, dd sobre ssh, ou qualquer coisa similar (você frequentemente terá uma taxa máxima suspeitamente próxima a 100mpbs). Mesmo em processadores multicore muito rápidos, você terá um gargalo na taxa de transferência máxima de criptografia de um dos núcleos na mais lenta das duas máquinas, o que é deprimente e lento em comparação com o cp completo ou rsync em uma montagem de rede não criptografada. Ocasionalmente, você atingirá uma parede de iops por um tempo e ficará preso em torno de ~ 53MB / s, em vez dos mais típicos ~ 110MB / s, mas isso geralmente dura pouco, a menos que a origem ou destino seja realmente uma única unidade, então você pode acabar sendo limitado pela taxa sustentada da própria unidade (que varia o suficiente por razões aleatórias que você não vai saber até que você realmente tente) - meh.
O NFS pode ser um pouco chato de configurar se estiver em uma distro desconhecida, mas em geral foi o modo mais rápido de preencher os canos da forma mais completa possível. A última vez que fiz isso com mais de 10gbps eu nunca realmente descobri se isso maximizou a conexão, porque a transferência tinha acabado antes de eu voltar de pegar um café - então pode haver algum limite natural que você acerte lá. Se você tiver alguns dispositivos de rede entre a origem e o destino, poderá encontrar alguns ligeiros atrasos ou soluços do efeito furtivo da rede, mas geralmente isso funcionará em todo o escritório (sem o tráfego de outras pessoas) ou de uma extremidade do datacenter o outro (a menos que você tenha algum tipo de filtragem / inspeção ocorrendo internamente, caso em que todas as apostas estão desativadas ).
EDITAR
Eu notei algumas conversas sobre compressão ... não comprima a conexão. Isso vai atrasá-lo da mesma maneira que uma camada de criptografia. O afunilamento sempre será um único núcleo se você comprimir a conexão (e você nem estará obtendo uma utilização particularmente boa do barramento desse núcleo). A coisa mais lenta que você pode fazer na sua situação é usar um canal criptografado e comprimido entre dois computadores, um ao lado do outro, em uma conexão de 1gbps ou superior.
PROSPECÇÃO FUTURA
Este conselho está em meados de 2015. Isso quase certamente não será o caso por muitos anos a mais. Então pegue tudo com um pouco de sal, e se você encarar essa tarefa regularmente, experimente uma variedade de métodos em cargas reais ao invés de imaginar que você obterá algo próximo de ótimos teóricos, ou mesmo de compressão / criptografia taxas de transferência típicas para coisas como tráfego web, muito do qual é textual (protip: transferências em massa geralmente consistem principalmente de imagens, áudio, vídeo, arquivos de banco de dados, código binário, formatos de arquivo de escritório, etc. já compactado em sua própria maneira e beneficiam muito pouco de ser executado através de outra rotina de compactação, o tamanho do bloco de compressão é quase garantido que não se alinha com seus dados binários já compactados ...). / p>
Eu imagino que no futuro conceitos como o SCTP serão levados para um lugar mais interessante, onde as conexões ligadas (ou conexões de fibra canalizadas internamente por espectro) são típicas, e cada canal pode receber um fluxo independente dos outros. , e cada fluxo pode ser comprimido / criptografado em paralelo, etc. etc. Isso seria maravilhoso! Mas esse não é o caso hoje em 2015, e apesar de fantasiar e teorizar ser bom, a maioria de nós não tem clusters de armazenamento personalizados rodando dados de alimentação de câmara criogênica diretamente nas entranhas de um Blue Gene / Q gerando respostas para o Watson. Isso não é apenas realidade. Também não temos tempo para analisar exaustivamente nossa carga de dados para descobrir se a compactação é uma boa ideia ou não - a transferência em si terminaria antes de terminarmos nossa análise, independentemente de quão ruim o método escolhido tenha sido.
Mas ...
Os horários mudam e minha recomendação contra compactação e criptografia não será válida. Eu realmente adoraria que este conselho fosse anulado no caso típico muito em breve. Isso tornaria minha vida mais fácil.
Se você conseguir um primeiro passe de alguma forma (através do wire / sneakernet / whatever), você pode olhar para rsync com certas opções que podem acelerar muito as transferências subsequentes. Um bom caminho a percorrer seria:
rsync -varzP sourceFiles destination
As opções são: verboso, modo de arquivo, recursivo, compactar, progresso parcial
Adicionado por insistência do autor original em comentários à resposta de zackse, embora não tenha certeza de que seja o mais rápido em circunstâncias típicas.
bash tem uma sintaxe especial de redirecionamento:
Para saída: > /dev/tcp/ IP / porta
Para entrada: < /dev/tcp/ IP / porta
IP ban seja IP com ponto decimal ou um nome de host;
porta ban seja um número decimal ou um nome de porta de /etc/services .
Não há diretório /dev/tcp/ real. É um kludge sintático especial que comanda bash para criar um soquete TCP, conectá-lo ao destino especificado e, em seguida, fazer a mesma coisa que um redirecionamento de arquivo usual (ou seja, substituir o respectivo fluxo padrão pelo soquete usando dup2 (2 ).
Portanto, é possível transmitir dados de dd ou tar na máquina de origem diretamente via TCP. Ou, inversamente, para transmitir dados para tar ou algo parecido diretamente via TCP. Em qualquer caso, um netcat supérfluo é eliminado.
Existe uma inconsistência na sintaxe entre netcat clássico e netcat GNU . Usarei a sintaxe clássica a que estou acostumado. Substitua -lp por -l pelo GNU netcat.
Além disso, não tenho certeza se o GNU netcat aceita -q switch.
(nos moldes da resposta de zackse).
No destino:
nc -lp 9999 >disk_image
Na fonte:
dd if=/dev/sda >/dev/tcp/destination/9999
tar
No destino:
nc -lp 9999 >backup.tgz
Na fonte:
tar cz files or directories to be transferred >/dev/tcp/destination/9999
Substitua .tgz por .tbz e cz por cj para obter um arquivo bzip2 -compressed.
Também com tar .
No destino:
cd backups
tar x </dev/tcp/destination/9999
Na fonte:
tar c files or directories to be transferred |nc -q 1 -lp 9999
Ele funcionará sem -q 1 , mas o netcat ficará preso quando os dados forem finalizados. Veja tar (1) para explicação da sintaxe e ressalvas de tar . Se houver muitos arquivos com alta redundância (baixa entropia), a compactação (por exemplo, cz e xz em vez de c e x ) poderá ser tentada, mas se os arquivos forem típicos e a rede for rápido o suficiente, isso apenas retardaria o processo. Veja a resposta de mikeserv para detalhes sobre a compressão.
No destino:
cd backups
nc -lp 9999 |tar x
Na fonte:
tar c files or directories to be transferred >/dev/tcp/destination/9999
Tente as sugestões sobre conexões diretas e evite protocolos criptografados, como o ssh. Então, se você ainda quiser aproveitar cada passo do desempenho, leia: link para obter alguns conselhos sobre otimizar suas janelas TCP.
Eu usaria este script que eu escrevi que precisa do pacote socat .
Na máquina de origem:
tarnet -d wherefilesaretosend pass=none 12345 .
Na máquina de destino:
tarnet -d wherefilesaretogo pass=none sourceip/12345
Se o pacote vbuf (Debian, Ubuntu) estiver lá, o remetente do arquivo mostrará um progresso nos dados. O receptor de arquivos mostrará quais arquivos são recebidos.
A opção pass = pode ser usada onde os dados podem ser expostos (mais lentos).
Editar:
Use a opção -n para desativar a compactação, se a CPU for um gargalo.
Se o orçamento não é a principal preocupação, você pode tentar conectar as unidades com um "conector de unidade" do Intel Xeon E5 12 core. Esse conector geralmente é tão poderoso que você pode até mesmo executar o software do servidor atual nele. De ambos os servidores!
Esta pode parecer uma resposta divertida, mas você deve realmente considerar por que você está movendo os dados entre os servidores e se um grande com memória compartilhada e armazenamento pode fazer mais sentido.
Não tem certeza sobre as especificações atuais, mas a transferência lenta pode ser limitada pela velocidade do disco, não pela rede?
Se você se importa apenas com backups e não sobre um byte para cópia de byte do disco rígido, então eu recomendaria o backupPC. link É um pouco difícil configurar, mas é muito rápido.
Meu tempo de transferência inicial para cerca de 500G de dados foi de cerca de 3 horas. Os backups subsequentes acontecem em cerca de 20 segundos.
Se você não estiver interessado em fazer backups, mas estiver tentando sincronizar as coisas, o rsync ou o uníssono atenderá melhor às suas necessidades.
Um byte para cópia de byte de um disco rígido é geralmente uma idéia horrível para fins de backup (sem incrementos, sem espaço, unidade não pode estar em uso, você tem que fazer backup do "espaço vazio", e você tem que backup de lixo (como um arquivo de swap de 16G ou 200G de core dumps ou algo assim) .Usando rsync (ou backuppc ou outros) você pode criar "snapshots" no tempo para que você possa ir para o que seu sistema de arquivos parecia 30min atrás "com muito pouca sobrecarga.
Dito isto, se você realmente quiser transferir um byte para cópia de byte, seu problema estará na transferência e não na obtenção de dados da unidade. Com 400G de RAM, uma transferência de arquivo 320G vai demorar muito. O uso de protocolos que não são criptografados é uma opção, mas não importa, você simplesmente terá que ficar lá e esperar por várias horas (pela rede).
Além disso, se você for usar uma unidade intermediária, considere isto: Obtenha uma unidade externa (como um pacote ou uma unidade separada conectada a uma estação de encaixe) que use eSATA em vez de USB. Em seguida, em cada um dos dois computadores, instale uma placa com uma porta eSATA ou obtenha um cabo adaptador simples que leve uma das portas SATA internas para um conector eSATA externo. Em seguida, conecte a unidade no computador de origem, ligue a unidade e aguarde a montagem automática (você pode montá-la manualmente, mas se estiver fazendo isso repetidamente, é melhor colocá-la no arquivo fstab). Então copie; você estará escrevendo na mesma velocidade de uma unidade interna. Em seguida, desmonte a unidade, desligue-a, conecte-se a outro computador, ligue-a, aguarde a montagem automática e leia.
Recomendarei que você analise o agrupamento de NICs. Isso envolve o uso de várias conexões de rede em execução em paralelo. Supondo que você realmente precise de mais de 1 Gb de transferência, e que 10 Gb seja de custo proibitivo, 2 Gb fornecidos pela NIC-teaming seriam um custo menor, e seus computadores podem ter as portas extras.
FWIW, eu sempre usei isso:
tar -cpf - <source path> | ssh user@destserver "cd /; tar xf -"
A coisa sobre esse método é que ele manterá as permissões de arquivo / pasta entre máquinas (supondo que os mesmos usuários / grupos existam em ambos) (Também faço isso normalmente para copiar imagens de discos virtuais, já que posso usar um parâmetro -S para lidar com arquivos esparsos.)
Apenas testei isso entre dois servidores ocupados e gerenciei ~ 14GB em 216s (cerca de 64MB / s) - poderia fazer melhor entre máquinas dedicadas e / ou compressão ... YMMV
$ date; tar -cpf - Installers | ssh elvis "cd /home/elvis/tst; tar xf -"; date
Wed Sep 9 15:23:37 EDT 2015
Wed Sep 9 15:27:13 EDT 2015
$ du -s Installers
14211072 Installers
A menos que você queira fazer análise forense do sistema de arquivos, use um programa de despejo / restauração para o seu sistema de arquivos para evitar copiar o espaço livre que o FS não está usando. Dependendo do sistema de arquivos que você possui, isso geralmente preservará os metadados all , incluindo ctime . No entanto, os números de inode podem mudar, dependendo do sistema de arquivos (xfs, ext4, ufs ...).
O destino de restauração pode ser um arquivo no sistema de destino.
Se você quiser uma imagem de disco completo com a tabela de partições, você pode dd o primeiro 1M do disco para obter a tabela de partição / bootloaders / stuff, mas xfsdump as partições.
Eu não posso dizer a partir do seu info-dump que tipo de sistema de arquivos você realmente tem. Se é BSD UFS, então eu acho que tem um programa de despejo / restauração. Se é ZFS, bem IDK, pode haver algo.
Geralmente, discos de cópia completa são muito lentos para qualquer situação, exceto situações de recuperação. Você não pode fazer backups incrementais dessa maneira.
Você também pode configurar os sistemas para ter um armazenamento compartilhado!
Estou considerando que eles estão próximos um do outro e você provavelmente fará isso novamente & novamente ....
Que tal um cabo crossover ethernet? Em vez de depender de velocidades sem fio, você está limitado à velocidade com fio da NIC.
Aqui está uma pergunta semelhante com alguns exemplos desse tipo de solução.
Aparentemente, apenas um típico cabo ethernet será suficiente hoje em dia. Obviamente, quanto melhor sua placa de rede, mais rápida será a transferência.
Para resumir, se qualquer configuração de rede for necessária, ela deve ser limitada a simplesmente configurar IPs estáticos para seu servidor e um computador de backup com uma máscara de sub-rede 255.255.255.0
Boa sorte!
Editar:
@Khrystoph falou sobre isso em sua resposta
Várias pessoas recomendam que você pule o ssh porque a criptografia irá atrasá-lo. CPUs modernas podem na verdade ser rápidas o suficiente em 1GB, mas o OpenSSH tem problemas com sua implementação de janelas internas que podem atrasá-lo drasticamente.
Se você quiser fazer isso com o ssh, dê uma olhada em HPN SSH . Ele resolve os problemas de janelas e adiciona criptografia multithread. Infelizmente, você precisará reconstruir o ssh no cliente & servidor.
OK Eu tentei responder essa pergunta para dois computadores com "pipes muito grandes" (10Gbe) que estão "próximos" um do outro.
O problema que você encontra aqui é: a maioria das compressões irá afunilar na CPU, já que os canos são tão grandes.
desempenho para transferir arquivos de 10 GB (conexão de rede de 6 Gb [linode], dados não compressíveis):
$ time bbcp 10G root@$dest_ip:/dev/null
0m16.5s
iperf:
server: $ iperf3 -s -F /dev/null
client:
$ time iperf3 -c $dest_ip -F 10G -t 20 # -t needs to be greater than time to transfer complete file
0m13.44s
(30% cpu)
netcat (1.187 openbsd):
server: $ nc -l 1234 > /dev/null
client: $ time nc $dest_ip 1234 -q 0 < 10G
0m13.311s
(58% cpu)
scp:
$ time /usr/local/bin/scp 10G root@$dest_ip:/dev/null
1m31.616s
scp with hpn ssh patch (scp -- hpn patch on client only, so not a good test possibly):
1m32.707s
socat:
server:
$ socat -u TCP-LISTEN:9876,reuseaddr OPEN:/dev/null,creat,trunc
client:
$ time socat -u FILE:10G TCP:$dest_ip:9876
0m15.989s
E duas caixas no 10 Gbe, versões ligeiramente mais antigas do netcat (CentOS 6.7), arquivo de 10 GB:
nc: 0m18.706s (100% cpu, v1.84, no -q option
iperf3: 0m10.013s (100% cpu, but can go up to at least 20Gbe with 100% cpu so not sure it matters)
socat: 0m10.293s (88% cpu, possibly maxed out)
Então, em uma instância, o netcat usava menos cpu, na outra socat, então YMMV.
Com o netcat, se ele não tiver uma opção "-N -q 0", ele poderá transferir arquivos truncados, tenha cuidado ... outras opções, como "-w 10", também podem resultar em arquivos truncados.
O que está acontecendo em quase todos esses casos é que a CPU está sendo maximizada, não a rede. scp atinge o máximo de 230 MB / s, atrelando um núcleo a 100% de utilização.
O Iperf3 infelizmente cria arquivos corrompidos . Algumas versões do netcat parecem não transferir o arquivo inteiro, muito estranho. Especialmente versões mais antigas.
Diversos encantamentos de "gzip como um pipe para o netcat" ou "mbuffer" também pareciam maximizar a CPU com o gzip ou o mbuffer, portanto, não resultou em uma transferência mais rápida com esses tubos grandes. lz4 pode ajudar. Além disso, algumas das coisas sobre o gzip pipe que eu tentei resultaram em transferências corrompidas para arquivos muito grandes (> 4 GB), então tenha cuidado lá fora:)
Outra coisa que pode funcionar especialmente para maior latência (?) é ajustar as configurações do tcp. Aqui está um guia que menciona os valores sugeridos:
link e link (de outra resposta) possivelmente configurações de IRQ: link
sugestões do linode, adicione ao /etc/sysctl.conf:
net.core.rmem_max = 268435456
net.core.wmem_max = 268435456
net.ipv4.tcp_rmem = 4096 87380 134217728
net.ipv4.tcp_wmem = 4096 65536 134217728
net.core.netdev_max_backlog = 250000
net.ipv4.tcp_no_metrics_save = 1
net.core.default_qdisc = fq
Além disso, eles gostariam que você executasse:
/sbin/ifconfig eth0 txqueuelen 10000
vale a pena verificar novamente depois de fazer ajustes para garantir que as alterações também não causem danos.
Também vale a pena ajustar o tamanho da janela: link
Com a compressão de conexões lentas (er), pode ser útil. Se você tem canais grandes, a compactação muito rápida pode ajudar com dados prontamente compactáveis, ainda não tentei.
A resposta padrão para "sincronizar discos rígidos" é rsync os arquivos, que evita a transferência sempre que possível.
Tags backup networking dd file-transfer