SCP失敗

[Axcela]

VMwareホスト間で、バックアップを取ったゲストOSのコピーをしていますが、かなりの頻度でSCPが lost connection で失敗します。

コピーしているゲストOSは2TByteありますが、シンプロビジョニングしているため実際の使用領域は300GByteほどしかありません。

SCPはシックとしてコピーしているようですが。

SCPで使用しているコマンドは下記のとおりです。

     scp -Crv  LOCALDIR/GESTBACKUP root@TARGETSVR:$DATADIR

ホスト間は1Gbpsのネットワークで直接接続しています。

使用しているESXiは下記です。

     VMware ESXi 5.5.0 build-1331820

SCPの失敗だけでなく、SCPの速度そのものも非常に遅い状況です。

何か解決策があれば、ご教授ください。

宜しくお願いいたします。

[OptimusP]

Storage は IP Storage (NFS / iSCSI) を使われています？

共有部分があるようでしたら、物理 NIC を足してみる、物理スイッチを分けるなど試してみてはいかがでしょう。

[Axcela]

ストレージは自腹のHDDです。

といっても、HP DL120のP440アレイコントローラでSAS HDD3本をRAID-5構成にしていますが。

NICもユーザサービス用とは別のバックアップ専用NICです。

このNICをHUBを使用せずに直接サーバー同士で接続しており、1Gbpsで通信しています。

[OptimusP]

ホスト 2台構成で互いのローカルデータストアにバックアップを取るような構成ですね。

vSAN も使ってはいない、と。

SCP は同じタイミングで多重で動いたりしているのでしょうか？

[Axcela]

フォローありがとうございます。

SCPは多重では動いていません。

SCPのサーバー側(受け取り側)はバックアップ機なので、殆ど負荷は無い状況です。

SCPのクライアント側(送り側)はゲストOSが動いているので、そこそこ負荷はありますが、クリティカルな状況ではありません。

何かログ等やトレースなど原因を突き止める方法があるといいのですが。

[OptimusP]

英語で、古いものも含んでいて恐縮ですが

切り分けの参考になるでしょうか。

File copy performance in Service Console

Poor performance when copying/cloning a VM disk

Really slow FTP/SFTP/SCP to/From ESX

ゲストOS の中から試してみるのも一案かと。

[Axcela]

情報ありがとうございます。

パフォーマンスに関してはあまり参考にはなりませんでした。

>> ゲストOS の中から試してみるのも一案かと

ゲストOSからVMFS上のファイルにアクセスする方法はあるのでしょうか？

また、パフォーマンスよりも問題なのが、せっかく数時間もかかってコピーしている最中に lost connection で失敗してしまう事です。

SCPコマンドで-vオプションを付けて詳細を吐き出させても、”Write failed: Invalid argument”というメッセージ以外に、これといった情報もありません。

ESXiがNFSをサポートしてくれると一番いいのですが・・・

[OptimusP]

構成を変更できるかどうかわかりませんが、Linux ゲスト内から

scp -3 で

>     -3 Copies between two remote hosts are transferred through the local host. Without this option the data is copied directly between the two remote hosts. Note that this option disables the progress meter.

ゲストを通るようにしてみる、とか、 Windows ゲストで Converter/OVF を利用してみる、とか。

他に思いつくところでは、この際、VDP のような Backup Software を利用してみる、とか。

[gowatana]

こんにちは。

scp (ssh) でのファイル転送のパフォーマンスが悪く途中失敗してしまうとのことですが、
ssh 以外の通信でも時間がかかるのかが気になりました。

バックアップ専用NICは、送信元/先のESXi同士でケーブル直結しているとのことですが、

たとえば下記のようなことことでネットワーク構成に問題がないか分かりそうだと思います。

• vCenterがあるのであれば、1Gを経由するクローンやコールドマイグレーションをためしてみる。
• 双方のESXi上のゲストOSで、バックアップ専用NICを使ったポートグループで通信してみる。
• 双方のESXiで「esxtop → n キー」や「ethtool -S vmnicX」などでカウンタを見てみる。
• iLOなどからNIC故障がないか確認してみる。

ssh 以外でも問題がありそうであれば、設定を見直したり、ケーブルを交換してみたりといった対処で改善するかもしれません。

あと、ESXi自体がNFSでデータストア提供することはできませんが、
バックアップ先ESXi上にWindows/LinuxゲストなどでNFSサーバを構築して

バックアップ元ESXiでバックアップ専用NICに構成したvmkポートからデータストアとしてマウントして vmkfstoolsでコピー をしてみるのはどうでしょうか。

この場合、コピーしたVMDKファイルはThinになります。

そして、バックアップ先ESXiでそのVMDKファイルからVM起動するときには、ゲストNFSをバックアップ先ESXiでもマウントすることになります。

以上です。参考になりますでしょうか。

[Axcela]

皆様、助言ありがとうございます。

同じ様なESXi2台構成が複数組あり、どれも同じような状況なので、ハードウェア故障などは考えられません。

色々SCPの転送テストをしてみました。

　　別HW　ホストーゲスト間 100%  732MB  22.2MB/s   00:33

　　同HW　ホストーゲスト間 100%  732MB  21.5MB/s   00:34

　　別HW　ゲストーゲスト間 100%  732MB 104.5MB/s   00:07

　　別HW　ホストーホスト間 100%  732MB  36.6MB/s   00:20

　　別HW　ホストーホスト間 100%  732MB  30.5MB/s   00:24 外部Linux経由

　　ホストー単独LINUX間　　 100%  732MB  40.7MB/s   00:18

　　ゲストー単独LINUX間　　 100%  732MB  56.3MB/s   00:13

ちなみに、ホストは１Gbpsですが、ゲストは100Mbpsです。

この結果を見るとESXのSCPのパフォーマンスが悪いのがわかります。

SCPの暗号化/複合化はCPUがそれ程上昇していないので、VMFSのI/Oパフォーマンスがあまり良くないように見えます。