Assicurarsi innanzitutto che il volume logico non sia montato. Se lo è e si desidera creare una "copia di riserva", creare prima un'istantanea e utilizzare invece questa:
lvcreate --snapshot --name transfer_snap --size 1G
Devo trasferire molti dati (7 TB) tra due server collegati da 1 Gbit, quindi avevo bisogno del modo più veloce possibile per farlo.
Dovresti usare SSH?
L'uso di ssh è fuori discussione, non a causa della sua crittografia (se si dispone di una CPU con supporto AES-NI, non fa molto male) ma a causa dei suoi buffer di rete. Quelli non stanno ridimensionando bene. Esiste una versione di Ssh con patch che risolve questo problema, ma poiché non ci sono pacchetti precompilati, non è molto conveniente.
Usando la compressione
Quando si trasferiscono immagini del disco non elaborate, è sempre consigliabile utilizzare la compressione. Ma non vuoi che la compressione diventi un collo di bottiglia. La maggior parte degli strumenti di compressione unix come gzip sono a thread singolo, quindi se la compressione satura una CPU, sarà un collo di bottiglia. Per questo motivo, utilizzo sempre pigz, una variante gzip che utilizza tutti i core della CPU per la compressione. E questo è necessario per farti salire e superare le velocità GBit.
Utilizzando la crittografia
Come detto prima, ssh è lento. Se hai una CPU AES-NI, questo non dovrebbe essere un collo di bottiglia. Quindi, invece di usare ssh, possiamo usare openssl direttamente.
costi
Per darti un'idea dell'impatto sulla velocità dei componenti, ecco i miei risultati. Queste sono le velocità di trasferimento tra due sistemi di produzione che leggono e scrivono in memoria. I risultati effettivi dipendono dalla velocità della rete, dalla velocità dell'HDD e dalla velocità della CPU di origine! Lo sto facendo per dimostrare che almeno non c'è un enorme calo delle prestazioni.
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
Conclusione: l'utilizzo della compressione offre un notevole aumento della velocità, in quanto riduce notevolmente le dimensioni dei dati. Ciò è ancora più importante se si hanno velocità di rete inferiori. Quando si utilizza la compressione, controllare l'utilizzo della CPU. se l'utilizzo viene massimizzato, puoi provare senza di esso. Utilizzando la compressione solo come un piccolo impatto sui sistemi AES-NI, imho solo perché ruba circa il 30-40% di cpu dalla compressione.
Utilizzando lo schermo
Se stai trasferendo molti dati come me, non vuoi che vengano interrotti da una disconnessione di rete del tuo client SSH, quindi è meglio avviarlo con lo schermo su entrambi i lati. Questa è solo una nota, non scriverò un tutorial sullo schermo qui.
Consente di copiare
Installa alcune dipendenze (sull'origine e sulla destinazione):
apt install pigz pv netcat-openbsd
quindi creare un volume sulla destinazione con le stesse dimensioni dell'origine. In caso di dubbi, utilizzare lvdisplay sull'origine per ottenere le dimensioni e creare l'obiettivo, ad esempio:
lvcreate -n lvname vgname -L 50G
quindi, preparare la destinazione per la ricezione dei dati:
nc -l -p 444 | openssl aes-256-cbc -d -salt -pass pass:asdkjn2hb | pigz -d | dd bs=16M of=/dev/vgname/lvname
e quando è pronto, avvia il trasferimento su Source:
pv -r -t -b -p -e /dev/vgname/lvname | pigz -1 | openssl aes-256-cbc -salt -pass pass:asdkjn2hb | nc <destip/host> 444 -q 1
Nota: se si trasferiscono i dati localmente o non si cura la crittografia, rimuovere la parte Openssl da entrambi i lati. Se ti interessa, asdkjn2hb è la chiave di crittografia, dovresti cambiarla.