論理ボリュームをネットワーク経由でサーバー間で直接移動しますか？
KVM複数のVMが搭載されたホストマシンがあります。各VMはホスト上の論理ボリュームを使用します。LVを別のホストマシンにコピーする必要があります。
通常、私は次のようなものを使用します：
dd if=/the/logical-volume of=/some/path/machine.dd
LVをイメージファイルに変換し、SCPを使用して移動します。次に、DDを使用して、ファイルを新しいホストの新しいLVにコピーします。
この方法の問題は、VMが両方のマシンで使用する場合の2倍のディスク容量が必要です。つまり、5GBのLVはLVに5GBの容量を使用し、ddコピーも追加で使用します。イメージ用に5 GBのスペース。これは小さなLVには問題ありませんが、（私の場合のように）大きなVM用に500 GBのLVがある場合はどうですか？新しいホストマシンには1 TBのハードドライブがあるため、 500GB ddイメージファイルandにコピーする500GBの論理ボリュームがありますandホストOS用のスペースがありますand他の小さなゲスト用のスペースがあります。
私がしたいことは次のようなものです：
dd if=/dev/mygroup-mylv of=192.168.1.103/dev/newvgroup-newlv
つまり、ネットワークを介して、ある論理ボリュームから別の論理ボリュームにデータを直接コピーし、中間イメージファイルをスキップします。
これは可能ですか？
もちろん、それは可能です。
dd if=/dev/mygroup-mylv | ssh 192.168.1.103 dd of=/dev/newvgroup-newlv
ブーム。
ただし、自分でお願いし、デフォルトのブロックサイズよりも大きいものを使用してください。おそらくbs = 4M（4 MBのチャンクで読み取り/書き込み）を追加します。コメントで、ブロック化についての問題点がいくつか見られます。これがかなり頻繁に行う作業である場合は、少し時間をかけて、異なるブロックサイズで数回試し、最高の転送速度が得られるものを確認してください。
コメントからの質問の1つに答える：
pv を介して転送をパイプ処理して、転送に関する統計を取得できます。これは、ddに信号を送信することで得られる出力よりもはるかに優れています。
もちろん、netcat（または暗号化のオーバーヘッドを課さないその他のもの）を使用する方が効率的ですが、通常、速度が上がると利便性がいくらか失われます。非常に大きなデータセットを移動するのでない限り、ほとんどの場合、すべてが既にJust Workに設定されているため、オーバーヘッドにもかかわらず、通常はsshを使い続けます。
これは最適化されたバージョンで、pvを使用して進行状況を示し、大きなチャンクにはBSを使用し、ネットワークトラフィックを削減するためにgzipも使用します。
これは、インターネットサーバーなどの低速接続間でデータを移動する場合に最適です。画面またはtmuxセッション内でコマンドを実行することをお勧めします。これにより、コマンドを実行するホストへのssh接続を問題なく切断できます。
$ dd if=/dev/volumegroupname/logicalvolume bs=4096 | pv | gzip | \
ssh [email protected] 'gzip -d | dd of=/dev/volumegroupname/logicalvolume bs=4096'
これを行うために古い友達を使用するのはどうでしょう。 NetCat。
論理ボリュームタイプを失っているシステム上
$ dd if=/dev/[directory]/[volume-name] | nc -l [any high number port]
次に、受信システムで。タイプ
$ nc -w 10 [ip or name] [port] | dd of=/dev/[directory/[volume name]
このファイルを翻訳して元のボックスに追加し、このポートをリッスンするnc（netcat）にパイプします。受信システムでは、netcatが[ポート]の[IPまたは名前]を閉じる前にデータを取得しない場合は10秒間待機し、そのデータをddにパイプして書き込みます。
まず、論理ボリュームがマウントされていないことを確認します。それが「ホットコピー」を作成したい場合は、最初にスナップショットを作成し、代わりにこれを使用してください：_lvcreate --snapshot --name transfer_snap --size 1G_
1Gビットに接続された2つのサーバー間で大量のデータ（7TB）を転送する必要があるため、できるだけ高速な方法が必要でした。
SSHを使用する必要がありますか？
Sshの使用は問題です。暗号化のためではなく（AES-NIをサポートするCPUを使用している場合、それほど問題にはなりません）、ネットワークバッファーのためです。それらはうまくスケーリングしていません。この問題に対処する パッチを当てたSshバージョン がありますが、プリコンパイル済みパッケージがないため、あまり便利ではありません。
圧縮の使用
生のディスクイメージを転送するときは、常に圧縮を使用することをお勧めします。ただし、圧縮がボトルネックになることは望ましくありません。 gzipのようなほとんどのUNIX圧縮ツールはシングルスレッドなので、圧縮によって1つのCPUが飽和すると、ボトルネックになります。そのため、私は常にすべてのCPUコアを圧縮に使用するgzipバリアントであるpigzを使用しています。そして、これはあなたがGBit速度以上に行きたいのであれば必要です。
暗号化の使用
前述のように、sshは低速です。 AES-NI CPUを使用している場合、これがボトルネックになることはありません。したがって、sshを使用する代わりに、opensslを直接使用できます。
スピード
コンポーネントの速度への影響のアイデアを提供するために、これが私の結果です。これらは、メモリの読み取りと書き込みを行う2つのプロダクションシステム間の転送速度です。実際の結果は、ネットワーク速度、HDD速度、ソースCPU速度に依存します！これを行うことで、少なくともパフォーマンスが大幅に低下することはありません。 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結論：圧縮を使用すると、データサイズが大幅に削減されるため、顕著なスピードアップが得られます。ネットワーク速度が遅い場合、これはさらに重要です。圧縮を使用するときは、CPUの使用状況に注意してください。使用量が限界に達した場合は、それなしで試すことができます。 AES-NIシステムへの小さな影響としてのみ圧縮を使用すると、imhoは圧縮から約30〜40％のCPUを奪うだけです。
画面の使用
私のように大量のデータを転送する場合は、sshクライアントのネットワーク切断によってデータが中断されることを望まないため、両側の画面から開始することをお勧めします。これは単なるメモです。ここでは画面チュートリアルを記述しません。
コピーしましょう
いくつかの依存関係をインストールします（ソースと宛先に）：_apt install pigz pv netcat-openbsd_
次に、ソースと同じサイズのボリュームを宛先に作成します。不明な場合は、ソースでlvdisplayを使用してサイズを取得し、ターゲットを作成します。つまり、_lvcreate -n lvname vgname -L 50G_
次に、データを受信するための宛先を準備します。
_nc -l -p 444 | openssl aes-256-cbc -d -salt -pass pass:asdkjn2hb | pigz -d | dd bs=16M of=/dev/vgname/lvname_
準備ができたら、ソースで転送を開始します。
_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_
注：データをローカルに転送する場合、または暗号化を気にしない場合は、Opensslパーツを両側から削除するだけです。気になる場合は、asdkjn2hbが暗号化キーなので、変更する必要があります。
まず、lvのスナップショットを撮ります。
lvcreate --snapshot --name my_shot --size <thesize> /dev/<name of vg>/<name of lv>
その後、同じサイズで新しいホストに（lvcreateを使用してなど）新しいlvを作成する必要があります。その後、データを新しいホストに直接コピーできます。これがコピーコマンドの私の例です。
dd if=/dev/vg0/my_shot bs=4096 | pv | ssh root@some_Host -C 'dd of=/dev/vg1/<created lv> bs=4096'
手順を使用して、維持されたproxmox pve VM=を別のホストにコピーしました。論理ボリュームには、VM自体によって維持された追加のLVがいくつか含まれていました。