性能に差が有るサーバー間でデータコピーするとき、rsync、robocopyコマンドはどのマシンで動かすと性能が出ますか？

Question

顧客のサーバーリプレースなどで古いサーバー（＝数年前のサーバーでCPU,Disk I/O性能が低い）から新しいサーバーにファイルをコピーします。
− よく有るケース　500万ファイル以上／トータルサイズ2TB以上

ファイルコピーに24時間以上かかることも結構あります。
社内で似た環境を創りだすのが難しく、以下の知見をお持ちでしたら
知恵を貸して頂けると嬉しいです。

1. 新、旧　どちらのサーバーでコマンドを動かすと効率がいいのか？

[想像]CPU,I/Oともに性能が低い旧サーバーがボトルネックになると考えられるので、旧サーバーで動かしたほうが良い。
2. rsyncのデーモンモード、compressなど転送効率が上がりそうなオプションは有効か？
3. robocopyに転送効率につながるオプションは有るか？

今の対策としては日付など条件付きで何回かに分けてコピーし、最後に完全同期させています。
顧客の本番環境なので中々思い切った事が出来ませんが、以下も試したいなぁ。試したこと有る方います？社内SEな方なら試したことあるかな。

1. 新旧サーバー間　LAN直結（ネットワーク利用率を上げる）
2. ジャンボフレームにして（パケットの効率を上げる）
3. OS標準外のコマンドでいいのがあれば（Windowsだとfastcopy？）
4. tarやzipで固めてファイル数少なくして転送する。（ファイルを固める／展開するオーバーヘッドや余分なファイル領域を考えると非現実的）
5. USB-HDDにコピー（かえって遅い？）

Answer 1

何がボトルネックになるのかは環境によりけりで一概に言えません。必ずしもディスクI/Oだけが問題になるわけではなく、CPUやメモリ容量、ネットワーク速度なども要因になります。そのため、どんな場合でもうまくいくという方法は存在しません。基本的には移行のリハーサルを行い、本番での時間を予測し、予定時間を超えるようであれば、手法の変更を試みると言うことの繰り返しになります。

それらを踏まえて、いくつかの指針を書きます。

1. rsyncやrobocopyはシングルスレッドなので、処理するディレクトリをわける。

こんな感じのツリー構成になっていたとしましょう。

sample
├── a
│   ├── a0
│   └── a1
├── b
│   └── b0
└── c

実際はaディレクトリの中にもより多くのファイルやディレクトリがあるとします。rsyncやデフォルトオプションでのrubocopyはシングルスレッドであるため、これらを一つ一つ辿っていくことになります。つまり、aを見て、一覧を出して、a0をコピーして、次にa1をコピーしてと一つ一つです。しかし、これらの処理は、ディスクIOの処理とリストの比較と言った処理、また、ファイルを転送したり、それに伴って圧縮・展開や暗号化・復号化(設定している場合)等の処理があります。ディスクIOの処理中はCPUはほとんど使いませんし、逆に他の処理中はCPUばかり使ってディスクIOを使いません。つまり、一つ一つのリソースを見ると使ったり、使わなかったりを繰り返し、非常に無駄が多いことになります。そこで、もし、ディスクIOを行っていない処理の間に他のディレクトリやファイルを読みに行っていたらどうでしょうか？そうすれば、リソースを無駄なく限界まで使って、これ以上は無理と言うこと頃まで出来るはずです。

ということで、処理を分散させることで全体の速度を上がる場合があります。例えば、一番上のトップだけを対象にするのではなく、トップ配下のディレクトリそれぞれわけてrsyncやrobocopyを走らせると言うことです。もし、とても大きなディレクトリがあるのであれば、そのサブディレクトリをさらに分けると言うことも必要になるでしょう。ただ、余りに分けすぎると逆に重くなる場合があります。一度に走らせる数を限定する、小さい物は順番に実行する、等の工夫が必要です。

また、最新のWindowsでのrobocopyでは/MTというマルチスレッドオプションがあります。これは上記のような分散処理をrobocopyが自動的に行ってくれるという物です。ただ、旧Windowsのバージョンには不具合があるようですので、Windows 10やWindows Server 2016以外では使用しない方が良いでしょう。

2. ネットワークがネックならデータを圧縮する。

コピー先が遠隔地にあって、回線が細いVPN経由になるといった場合に有効です。ただし、CPUを多く使いますので、遅いマシンでは必ずしも速くなるとは限りません。

3. マシンを分ける。

ファイルサーバー同士の移行であれば、ファイルサーバー上で実行するのではなく、同期用のマシンを別に用意します。1.の分散処理と合わせて、それらマシン一つ一つでそれぞれ別のディレクトリについて同期を行うという手法です。ファイルサーバーはSMBやNFSの処理に専念できるため、ほぼディスクIOに従った速度が出ることになります。ネックはネットワークですが、1Gpbsのそれなりのスイッチで接続していれば、十分なことが多いです。

4. CPUの負荷が高い処理は新しいマシンで行う。

同期のメインはディレクトリ内のエントリーを比較し、どれをコピーをするのかという処理になります。単純な処理ではありますが、ディレクトリ数が多い場合はバカに出来ないほどの高負荷です。ですので、rsyncやrobocopyの本体は新しいマシンで行う方が良いでしょう。ただ、そこそこの速度のマシンをベット用意できるのであれば、3.の選択肢も考慮に入れるべきです。

5. ファイルサーバーの機能が速いとは限らない。

NetAppのDataOnTapですとsnapmirrorというボリューム間をコピーする専用の機能があるのですが、ぶっちゃけ、バージョンが違うと制限があったり、最初の同期に数日かかると出たり、分割して出来なかったり、ダメだったら初めからだったりと、計画的に使わないと使える物ではありませんでした。事実、私は一度、急遽サーバーを5台作ってrsyncでコピーするに切り替えたことがあります。

選択肢の一つとして利用するのはありでも、絶対大丈夫だと思ってはいけません。

6. リトライを繰り返さない。

robocopyでよくあるのはアクセス権やファイル名が壊れたためにコピーできないファイルが存在すると言うことです。間隔をあけて何度かリトライして諦めるのですが、このデファルト値が30秒間隔で100万回です。たいていの場合、翌朝来たら終わっていると思ったら、リトライを繰り返していただけだったと言うがオチです。/R:nと/W:nは必ず変更してください。本番でこれを忘れると確実に間に合いません。

なお、コピーできないデータは利用者と相談し、削除するなり、リネームするなりして、事前に正常なデータにしておきます。

7. ダウンタイム0を目指す。

現在のファイルシステムにもよりますが、リアルタイム同期という機能がある物もあります。うまく使いこなせばダウンタイム0で移行できます。

8. ACLのコピー忘れに注意。

リハーサルで、適当なファイルについてACLを確認しておくことをお勧めします。オプションの指定漏れは洒落になりません。

9. スナップショットまでコピーしてしまう。

ファイルシステムの設定によってはスナップショット領域が見えてしまって、そのままコピーしてしまう場合があります。除外するようにしましょう。

10. 大事なのは全てがコピーされたことをどうやって保証するか。

rsyncやrobocopyがエラー無く終わったというログを残すことが第一です。しかし、rsyncやrobocopyにバグがないという保証はありません。また、よくあるのは、オプションミスでコピー漏れが発生していたと言うことです。

そのため、別の方法で確実にコピーされたことを担保する必要があります。

• ディレクトリやファイル数。
  Windowsであれば簡単に確認できます。
• ファイルの合計サイズ
  こちらもWindowsであれば簡単に確認できます。ディスク上のサイズは必ずしも一致しないことに注意してください。
• ls -lなどの結果
  カレントディレクトリやオプションをうまく調整すればdiffで単純比較できます。ただ、OSのバージョンによって微妙に異なる場合があり、ある程度加工してから比較となる場合もあります。加工する技術が無ければ、Excelに貼り付けて比較している人もいました。
• caclesなどの結果
  上と同じです。

---

とりあえず、これぐらいでしょうか。他にも細かいことがたくさんあったような気がします。

ぶっちゃけ、2TB級のデータ移行となると少なくない工数を見積もり、経験がある人間を配置します。何も知らさない新人に任せるような仕事ではありません。不安であるなら、お金がかかってもインフラ専門のSEを別途用意すべきです。

Comments

[oikashinoa]

深夜に有用な情報を頂きありがとうございます。
5時から読んて返信の準備してましたが出張の時間が来てしまいました。夜に返答する予定です。

[oikashinoa]

深夜に返信いただきありがとうございました。

`raccyさん`が書かれているようにリハーサル→本番の流れを組んで作業しています。
顧客環境／本稼働中／他システムへの影響／予算も有り、性能調査などは殆どの場合許可いただけませんでした。

本当は詳しい手順、システムなど書ければいいのですが…一般的なことしか書いてません。（申し訳ないです。お察し下さい。）

1. rsyncやrobocopyはシングルスレッドなので、処理するディレクトリをわける。
基本2多重になるように設計してます。（発想は`raccyさん`が書かれているとおり）
多重度をどこまであげれるかは時間的制約も有り、測定出来ていません。

`robocopy/MTオプション`ですか。ログ関係のバグと、コマンドは旧サーバーで動かしたほうがよいのでは？との考えで避けていたのですが一考有りますね。

2. ネットワークがネックならデータを圧縮する。
テラ単位のデータ量なので、LAN内でのコピーでも効果が有るかもと考えています。
画像、動画など圧縮率が期待できないファイルが少ない時は考えてみます。（調査出来る時間が…）

3. マシンを分ける。
旧サーバー　→　｛複数の同期用サーバー｝　→　新サーバー　という流れということでしょうか？
旧→同期用は効率上がりますが、同期用→新の工程が増えるのであまりメリットがないと考えていました。

4. CPUの負荷が高い処理は新しいマシンで行う。
性能が低い旧サーバーはDiskI/Oに関する処理に専念させるということですね。
旧サーバー側でコマンドを動かせば、遅い（はずの）Diskへのアクセスのレスポンスが上がるだろうと考えていました。（新サーバーでコマンドを動かすとワンテンポ遅くなるのでは？）

5. リトライを繰り返さない。
/R:nと/W:nは変更してます。（０か１）
運がいいのか`アクセス権やファイル名が壊れたためにコピーできないファイル`には遭遇する機会はありませんでした。
- No10に書かれているようにログ、ファイル数、ファイルの合計サイズでチェックしてます。

7. ダウンタイム0を目指す。
`リアルタイム同期`ですか？サーバーリプレースが目的なので旧サーバーOSも
サポートしているなら検討してもいいかも…
ただ、OS標準でサポートしているものってあります？Windows/Linuxともに軽く調べてみましたが見つからず。

8. ACLのコピー忘れに注意。
洒落にならないですね。想定しているACLの確認はしています。

9. スナップショットまでコピーしてしまう。
これは考慮してないですね。うれしい観点です。

10. 大事なのは全てがコピーされたことをどうやって保証するか。
エビデンスの観点も有り、ログなどで確認してます（何をしているかはNo6）

色々と教えていただきありがとうございました。

[shinobu_osaka]

下記は当然なんですが…。
USB-HDD とありますので、そういうことをしてもよいのでしたら、
eSATAかUSB3.0、なければいっその事直接SATAでHDDをつないで、
ファイルコピーしてしまうのが、ちょっとした小テクを使ったネットワーク経由より
はるかに高速なのではないかと…。

[sysjojo]

> また、最新のWindowsでのrobocopyでは/MTというマルチスレッドオプションがあります。これは上記のような分散処理をrobocopyが自動的に行ってくれるという物です。
3年くらい前ですが、StorageServer 2008からStorageServer2012に引っ越しするのに、2012側からマルチスレッドオプションを使ったら、2008側がついてこれずに余計に時間がかかったのでやめました。マルチスレッド化はコピー元がどこまで耐えれるか、が大きいかと。

経験上、サイズよりも数がネックになることの方が多い気がします。小っちゃいファイルがたくさんあるディレクトリは固めて持ってくる方が確実に早いです。

[oikashinoa]

shinobu_osakaさま

> USB-HDD とありますので、そういうことをしてもよいのでしたら、
> eSATAかUSB3.0、なければいっその事直接SATAでHDDをつないで、
> ファイルコピーしてしまうのが、ちょっとした小テクを使ったネットワーク経由より
> はるかに高速なのではないかと…。
個人PCならやってしまうんですけどね。データセンター内、サーバーラックに
入っているサーバーを分解しだしたら警備員が飛んできそうです。
そもそも媒体持ち込むのすら手続きが大変だし…

アイディアとしては有るんですが、仕事で試すに至ってません。
また、ネットワーク越しより3倍近く早くないと採用には至りません。
（HDDに吸いだして、HDDから書き出してって考えたら3倍速は欲しい）

sysjojoさま

> 経験上、サイズよりも数がネックになることの方が多い気がします。
わたしもそんな気がしてまして、tarとかで固めたいなぁと。

> 小っちゃいファイルがたくさんあるディレクトリは固めて持ってくる方が確実に早いです。
固める、展開する　時間を含んでも早いです？それならDisk領域が空いていればやってもいいかな。

日程的にお客様本番環境でリハーサルは一回しか出来ないんで…
もう少し確実に早そうてなってからHDDに書いたりtarで固めたりって試したいです。

[sysjojo]

>> 小っちゃいファイルがたくさんあるディレクトリは固めて持ってくる方が確実に早いです。
>固める、展開する　時間を含んでも早いです？それならDisk領域が空いていればやってもいいかな。

あくまで私が作業した環境の話ですが、圧縮・展開までの時間を含めても固めた方が早かったです。
但し権限まわりをチェックしたりする必要もあるので、厳密にアクセス制限しないといけないディレクトリでは固めない方が効率的なこともあるかと。

> 日程的にお客様本番環境でリハーサルは一回しか出来ないんで…

私が行った際は、事前に検証環境でバッチを準備してバッチごとに所要時間を測って計画を立てたり、新サーバーを非公開で並行運用させて最後の差分同期だけ旧サーバーをアクセス制限する、など事前にいろいろとできたのであまり参考にならないと思いますが、私は24時間やそこらじゃ終わらない気がします。

移行後のチェックも事前にスクリプトなどを組んでチェックできる部分もありますが、最終的には人の目でチェックが必要なところもあるので複数人で分担して作業しました。
ファイルサーバーならバックアップがありそうな気がするので、バックアップデータを新サーバーに事前に戻させてもらえば、大半のデータはコピー不要になりそうな気もしますが、私はやったことないですね・・・
Windows同士で使えるバージョンであれば、ファイルサーバー移行ツールを使ったりもできますが、これもrobocopyと同じでダメなケースがあるので、事前に検証できないのはつらいですね。

[shinobu_osaka]

データセンター内ならUSBHDDとか持ち込みもアウトでしょ…。
というより事前にテストできず検証環境用意できず本番前にリハーサル１回だと、
作業時間の予測はできるかもですが作業時間の最適化は無理な案件ではないかと…。

[oikashinoa]

sysjojoさま

>>> 小っちゃいファイルがたくさんあるディレクトリは固めて持ってくる方が確実に早いです。
>>固める、展開する　時間を含んでも早いです？それならDisk領域が空いていればやってもいいかな。
>但し権限まわりをチェックしたりする必要もあるので、厳密にアクセス制限しないといけないディレクトリでは固めない方が効率的なこともあるかと。
チェック方法が大変なのと、今サーバーに無いもの（ソフト、ハードともに）を使おうとすると
影響ないのかエビデンスを求められたりするんで…どないせぇっちゅうねん。

>> 日程的にお客様本番環境でリハーサルは一回しか出来ないんで…
>私は24時間やそこらじゃ終わらない気がします。
サンプルの例では31時間かかりました(^^;)

>バックアップデータを新サーバーに事前に戻させてもらえば
他ベンダーがやっていたり、グループ内の部署がやっていたとしても
手を回してもらえないことが多々有ります（同時に同じ案件で作業しているので。）
私ではないですが他の人間がこの手を使ったことは有ります。

>ファイルサーバー移行ツールを使ったりもできますが、
制約が多すぎるのでrobocopy、rsync以外に中々　手が出せていない状況です。

shinobu_osakaさま

>データセンター内ならUSBHDDとか持ち込みもアウトでしょ…。
お客様に購入して頂いて、データセンター内に備品として使用する（＝DCから持ち出さない）
ならOKなんですけどね。我々の作業だけのために買うのは昨今難しいです。

>検証環境用意できず本番前にリハーサル１回だと、
>作業時間の予測はできるかもですが作業時間の最適化は無理な案件ではないかと…。
リハが２回有るんならチャレンジするんですけどね。
手法を試すのは難しいので、robocopy/rsyncで改善できないか検討している次第です。

…みんな小手先って言うけど、３１時間のコピーが３０時間になるだけでも後工程が楽になるんですよ。

[sysjojo]

＞サンプルの例では31時間かかりました(^^;)
サンプルででも１回通しでできているなら、コピー時間がかかってるフォルダだけ、小手先のことを考えて２４時間に納める、とか。

サンプルはあくまでサンプルで全量ではない、ということであれば並行運用するような策を提案するなりした方が私は無難な気が（＾＾；

[sysjojo]

タグで"Linux"、"Windows"とつけられているということはLinux搭載のNASからWindows Storage ServerのNASとかだったりするのかな？と想像するのですがコピー先、コピー元を明記されると、追加の情報出てきませんかね？コピー元にUSB-HDDつけてバックアップできるような機種なら事前に付けておいて、リハーサル以降でそのHDDを外してコピー先に持ってくとかもできそうですし。

[oikashinoa]

sysjojoさま

サンプル という言葉に語弊がありましたか？
質問欄に書いてました、実際に行った実環境での結果です。
あとリハーサル時は現行環境と本番環境は平行稼働です。

あと質問事項に記載の通り、今回の件はサーバーのお話です。が、nasに外付けHDD付けれる機種有るんですね。別機種に付け替えは管理領域壊されそうとか怖いイメージが湧きました。

[sysjojo]

失礼しました。サーバーリプレースとありますね。
Linuxのファイルサーバーって昔のNASのイメージが強かったので。

並行稼動期間があるのであれば、その間で移してしまうこともできると思いますが、「リハーサル時は」ということは、その時だけ、ってことなんでしょうね（＾＾；

[oikashinoa]

リハーサル環境構築時にファイルば全部コピーします。
本番作業時の所要時間測定
仕組みとして、全ファイルが必要

本番時は差分コピー可能なところは差分してます

[oikashinoa]

業務で試そうとしているうちに時間が経ってしましました…
raccyさん、aoimeさん、YouheiSakuraiさん、shinobu_osakaさん、sysjojoさんに感謝です。

色々試してきたことも溜まってきており、今時点での対策を纏めておきます。

発想を広げたくあえて書かなかった部分も加え、想定している環境は以下となっております。
1. 古いサーバー>新しいサーバーへデータコピー
　1. 中間的なサーバーは設置不可
　2. 物理→物理、物理→仮想、仮想→仮想、仮想→パブリッククラウド 何れのケースも有る
2. 顧客の本番環境、同一LAN内
　1. 本番環境なのでLAN線抜き際しは禁止(直結できない)
　3. セグメントが異なるケースは有る
　4. パブリッククラウドへの移行はWAN経由
3. 古いサーバー・新しいサーバーの、DBなどミドルウェアより下位レイヤーは変更不可
　1. ジャンボフレームにするとかネットワーク設定はNG
　2. DiskImageで移行するのは担当者にお願いする必要あり
　3. USB-HDD、NASなどの使用は基本NG(交渉すれば通る可能性あり)
4. 500万ファイル以上／トータルサイズ2TB以上
　1. DBのインスタンス(ファイル数 少、トータスサイズ小)
　2. テキスト、イメージファイル、動画etcのファイル(ファイル数 、トータスサイズ 大)
5. リハーサル、本番を行う
　1. 後工程も時間必要なので、金曜夜から開始してデータ移行を24時間以内に終わらる必要あり(連休に日程を組んで、データコピーに48時間まで余裕もつ事もある)

今時点での対策は以下です。本番、稼働中での作業なので思い切ったことはしてません。
1. 2-4多重でファイルコピー
　1. フォルダー単位で、コピーコマンドを多重実行する
　2. robocopyの/MT(マルチスレッドオプション)は怖いので使わない
　3. 多重度を上げ過ぎると他のシステムにも影響出るのでやり過ぎない
2. コマンドは新サーバーで動かす
　1. CPU負荷が高い処理をは新しいサーバーで処理させる
　2. リハーサルのコピー結果に対して差分コピーして短縮する(差分コピー時の負荷を考えると新サーバーで動かすのが妥当)
3. データ圧縮はしない
　1. テキスト、画像・動画などどのような割合で使っているか調査できないの(時間がない)で、圧縮は不用意なトラブルを避けるため使わない
　2. ”tarなどでアーカイブして新サーバーで展開”も余計な工程が増えるので行わない(…ただし早いはずなので、時間的制約によっては検討の余地有り)
4. リトライオプションは適切に
　1. robocopyの/R:nと/W:nは1に変更
　2. rsyncは…スイッチ名忘れた
5. コピーコマンド実行結果をログに出力し、確認
　1. ファイルコピースキップがないか確認
　2. ファイル数、フォルダサイズを確認
　3. …内容まで保証しろって言われたら、certUtil.exeかmd5sumで比較ってところですかね

今後の予定
1. パーミッションや所有者はコピー対象とせず、コピー完了後に上書きする
　1. ファイル数の多さがコピー時間に影響していると思われるので、効果があるかも
　2. タイムスタンプは保持する
2. オンプレ→パブリッククラウドへの移行などWAN回線使うときは、圧縮オプションを使ってみる
　1. 無難にImageまるごと移行(クラウドベンダーによってImageサイズに上限が有るので要確認)
　　1. Disk持ち込みサービスが確実だが、リードタイムが長いので使いづらい
　2. robocopy ... オプションあるのか？
　3. rsyncだと --compress

一旦BAを決めますが、なにか有益な情報が有れば随時更新します。

Answer 2

新旧サーバー間　LAN直結（ネットワーク利用率を上げる）
ジャンボフレームにして（パケットの効率を上げる）

は実運用でやったことがありましたが効果はいまいちでした。小手先で頑張るよりもオフライン（CDブート等）でPartImage等を使ったパーティション単位のバックアップ・リストアが速いし信頼性もあると思います。そういった意味でファイル単位ではなくパーティション単位であれば「USB-HDDにコピー」は意外と良い結果につながると思います。

Comments

[oikashinoa]

YouheiSakuraiさま

>>新旧サーバー間　LAN直結（ネットワーク利用率を上げる）
>>ジャンボフレームにして（パケットの効率を上げる）
>は実運用でやったことがありましたが効果はいまいちでした。
そうなんですか。意外でした。

>パーティション単位のバックアップ・リストアが速いし
OSの更改も同時なのと、バックアップしやすいようなパーティション構成に
なっていないことが多いのです。

Answer 3

新旧サーバー間　LAN直結（ネットワーク利用率を上げる）

2TB のデータを古いサーバから新しいサーバへrobocopyしたことがあります。
以下で倍以上早くなりました。
・LAN直結
・新しいサーバでrobocopy実施

いろいろと制限があるなかで、できるだけ標準の仕様やコマンドのまま効率を上げることを考えたら、
上記にたどり着いた感じです。
tarやzipなどの圧縮はCPUに負荷がかかり、圧縮、解凍時間を考えたら非効率かなと思います。

Comments

[oikashinoa]

回答有難うございます。
> 圧縮、解凍時間を考えたら非効率かなと思います。

想像通り、手間が増えるばかりで非効率そうでした。

当たり前ですが顧客環境に一時的にでも手を入れるのは難しく、小手先でのスピードアップですがもうひとつアイディアが有るので、改善したのならここで共有したいと思います。