Name：井谷 寛
Title：ネットアップ合同会社 システム技術本部 ソリューション アーキテクト部 ソリューションアーキテクト
October, 2020
はじめに
前回のブログ「データの同期速度(1)テストの目的とテスト環境」では前提となる環境情報を掲載しました。今回はNFS＋スモールファイル、次回はNFS＋ラージファイル環境でのデータ同期速度をご紹介していきます。
NFS＋スモールファイルのテストパターン
スモールファイル(953GiB、1952万3812ファイル、195万3125ディレクトリ)に対して以下のパターンでテストを実施しました。
| (1) rsync x1 SAS |
| (2) Cloud Sync Data Broker x1 SAS |
| (3) Cloud Sync Data Broker x1 SSD |
| (4) Cloud Sync Data Broker x2 SAS |
| (5) XCP x1 --parallel 指定なし(=7) SAS |
| (6) XCP x1 --parallel 指定なし(=7) SSD |
| (7) XCP x1 --parallel 11 SSD |
| (8) XCP x1 CPU core 8 --parallel 22 SSD |
| (9) XCP x2 (SAS x2) |
| (10) XCP x4 (SAS x2 + SSD x2) |
| (11) XCP x5 (SAS x3 + SSD x2) |
基本的に1つのテストは1つのディスクシェルフ(SASは18D+2P, SSDは21D+2P)に対して実行しております。
NFS＋スモールファイルのテスト結果 （rsync vs Cloud Sync）
まず最初にrysncとCloud Syncを比較しました。
(1)と(2)はストレージもサーバーも全く同じ条件で、ツールだけが異なります。このときのrsyncの実行コマンドは以下の通りです。（ソースとターゲットの両方をサーバにマウントしています。）
rsync -avh /mnt/FAS8040_hfc1/ /mnt/AFF8080_hfc1/ --progress
(2)と(3)はどちらもCloud Syncを利用していますが、ソースのメディアタイプ（SAS or SSD）に違いがあります。性能差が無いため、ストレージネックではないと考えられます。
※Cloud SyncはSaaSサービスのため、WebUIでコピー設定を行います。
※Cloud Syncはコントロールプレーンとなり、オンプレミスもしくはクラウドにデータブローカーサーバ（データ転送用サーバ）を立ててCloud Syncと連携することでデータ同期を行います。
(4)は(2)のCloud Syncにデータブローカーを1台追加して、1つのFlexVolumeに対して並列度を上げて計測しました。SASディスクから読み出していますが、(2)と比べてリニアに性能が上がっているため、SAS側にまだボトルネックは発生していません。
※データブローカーサーバーはrsyncサーバーと同じサーバにインストールしたため、rsyncとOS環境などの条件は同じです。
rsyncは小さなファイルにはかなり苦戦していることがわかります。Cloud Syncはrsyncの約2.5倍の速度が出ていますが、これはCloud Syncが1サーバ内で複数のプロセスを起動して並列処理する（デフォルトで4プロセス）ためと考えられます。詳細なデータは取得しませんでしたが、試しに2台のサーバでそれぞれ異なるのサブディレクトリを指定して2並列でrsyncを実行したところ、全体速度は約1.5倍向上しました。しかし、それでもCloud Syncの1台分に及ばないため、ツールボトルネックと判断してそれ以上の計測を中断しました。
953GiBのスモールファイルの同期時間は、rsyncでは約40時間、Cloud Syncはデータブローカー1台で16時間28分、データブローカー2台で8時間25分、データブローカー3台で5時間40分になりました。
このテストでインフラの観点では以下の点を確認していますが、いずれも余裕があり、ボトルネックはありませんでした。
- ストレージ（FAS8040、AFF8080）
CPU負荷、DISK負荷（utilization, 転送レート）、NIC利用帯域 - 同期サーバ
CPU負荷、CPU idle比率、CPU load average
NFS＋スモールファイルのテスト結果（XCP）
ここからはNetApp XCPを使ったテスト結果となります。
(5)はrsyncを実行した仮想サーバと同じサーバでXCPを使ってデータ同期したときの値です。rsyncやCloud SyncとOS環境は同じであるため、XCPが効率的に転送していることがわかります。この(5)を実行中の読み出し元のSAS DISKのUtilizationは90～100％であり、ソースが限界に近付いているようでした。すべてのデータ（953GiB）の同期に約1時間40分かかりました。
(6)はソースをSSDに変更しましたが、性能向上はわずかでした。SSDのDISK Utilizationは1-4％と低く、他にボトルネックも見当たらないため、XCPサーバ1台の限界に近づいていると考えられます。しかしXCPサーバーのCPU使用率は(5)と同様に低く、4コア合計でのCPU idleが40-70％の間を推移していたので、ロードアベレージは高いもののもう少し負荷をかけてみることにしました。
(6)のXCPサーバのCPU負荷状況
(7)は同じサーバを使って--parallelを11に増やしたときのものです。これにより起動するxcpプロセスが増えることで1.5倍ほど速くなることを期待しました。しかし結果としてほとんど差が無く、CPU ildeは(6)より少し減って50％前後でした。CPU Load averageは(6)も(7)も2.00～3.30の間を推移していました。
(8)は仮想サーバ自身のCPUを2倍の8 coreに増やして再起動し、--parallelも大幅に増やしたのですが、逆に少し性能が落ちる結果となりました。ちなみにこの--parallelオプションはCPUコア数 x2 -1が適切な値であることがテスト後に判明しました。（8 coreは--parallel 15が最適。）この点は製品マニュアルに記載が無いので注意が必要です。
(5)のパターンではSASディスクのネックに近づいて（DISK Utilが100％）いましたが、(6)～(8)はソースがSSDのためストレージ側に大きなボトルネックは見当たらず、CPUもNICも十分に余裕がありました。
※(5)のSASディスク構成：SAS 450GB x20本 (RAID-DP, 18Disk 2Parity)
※(6)-(8)のSSDディスク構成：SSD 400GB x24本 (RAID-DP, 21Disk 2Parity構成)
そして(6)のパターンではSSDディスク構成で180MB/s程度でしたが、DISK、CPU、NICともにボトルネックが無かったため、この50KBのスモールファイル環境におけるXCPのサーバ1台の限界はこのあたりのようです。
この検証で使ったXCPの実行パラメータは以下の通りです。
ノーマル：xcp copy 192.168.55.184:/hfc1 192.168.55.181:/hfc1
パラレル：xcp copy --parallel 11 192.168.55.184:/hfc1 192.168.55.181:/hfc1
パラレル：xcp copy --parallel 22 192.168.55.184:/hfc1 192.168.55.181:/hfc1
(5)のパターンでXCPを実行中のソース(FAS8040)の負荷は以下の通りです。
（※見やすくするため、Tape Read/Write列やCP(CP_Ty, CP_Ph)列を削っています）
（※クリックで拡大します）
（※クリックで拡大します）
XCPサーバ1台によるデータ同期ではFAS8040のCPUコア別の負荷に余裕があり、コントローラ性能を使い切れていないことがわかります。
ここまでのテストでXCPサーバ1台当たりの限界がわかったところで、XCPサーバを増やしてテストをしました。ソースのデータを複数用意して、ストレージコントローラーとディスクシェルフも別々になるように分散させ、次の2点について確認を行いました。1点目はソースのデータとXCPサーバを複数準備すれば、比例してコントローラやディスクの上限まで性能が出せるか、2点目はスモールファイルが書き込まれるAFF8080側でスモールファイル特有のボトルネックが発生しないか、となります。
※ (8)は比較用
(9)は2台のXCPサーバで計測しており、1台目のXCPサーバがコントローラAのSAS DISK、2台目のXCPサーバがコントローラBのSAS DISKをそれぞれREADしています。そしてグラフは2台分の転送レートを足し算しています。ターゲットはAFF8080の片方のコントローラ1台で2台分のWriteを受けています。(当然2倍の性能が期待できます。)
(10)は4台のXCPサーバでデータ同期をしています。スモールファイルを4つのFlexVolumeに複製し、以下のような配置で同時にデータをREADしたところ、XCPサーバ1台あたり約150MiB/sの性能となりました。
XCPサーバ1 FAS8040コントローラAのSASアグリゲートからREAD
XCPサーバ2 FAS8040コントローラAのSSDアグリゲートからREAD
XCPサーバ3 FAS8040コントローラBのSASアグリゲートからREAD
XCPサーバ4 FAS8040コントローラBのSSDアグリゲートからREAD
このときのソース（FAS8040）のCPU負荷はコントローラA、Bともに25～35％程度でしたが、ターゲット（AFF8080）は1つのコントローラで4つのWRITEを受けて、CPU 70-85%程度、DISK Utilizationは20％弱でした。ターゲット側のsysstat -mの結果をみても、CPUコア別の負荷は均等に分散されています。
AFF8080の負荷状況
（※クリックで拡大します）
ようやくAFF8080の性能ネックが見えてきましたが、さらに追加のXCPサーバを用意しても受けきれる状況でした。
(11)は5台目のXCPサーバを立てた時の結果です。しかし本来であれば750MiB/sは出るはずですが、仮想サーバを増やしすぎてESXi内でメモリ不足 (64GB x5VM > ESXi物理メモリ)に直面し、サーバネックになっていました。（サーバ内部にボトルネックが発生した場合の参考データとして記載しています。）
NFS+スモールファイルの差分検出時間
差分同期にかかる時間は差分検出時間とデータ転送時間の合計になりますが、データの転送時間は掛け算することで予測が出来るため、ここでは差分検出時間に着目しました。
SASディスク上の953GiBのスモールファイルに対してそれぞれのツールで一度フル同期をかけたあとに、変更がされていない状態でもう一度データ同期を実行して2回目の同期時間をグラフ化したものが以下となります。
(1)はrsyncをサーバ1台で実行した結果です。
(2)のCloud Syncは1つのデータソースに対して3台のデータブローカーが同時に差分検出を行った結果です。
(3)はXCPをサーバ1台で実行した結果です。
NFS+スモールファイルのまとめ
NFS＋スモールファイル環境ではXCPを使って高速な転送ができることが確認できました。またCloud Syncもデータブローカーを増やせば性能が向上することもわかりました。rsyncはスモールファイルはあまり得意ではありませんでしたが、ラージファイル環境ではrsyncの帯域制限機能やネットワーク圧縮機能などが活躍する場面もあるかもしれません。（ツール別の機能差は別途ブログにまとめる予定です。）
また、多数のスモールファイルがある環境でのボトルネックポイントを確認できました。
- 同期ツール別の1台あたりの性能
- ソース・ストレージ(FAS8040)のREAD性能
- SASアグリゲート(18D+2P) x1シェルフのボトルネック
- コントローラCPUのボトルネック
- ターゲット・ストレージ(AFF8080)のWRITE性能
- コントローラCPUのボトルネック
NFS＋スモールファイルでは、NICの10Gbpsの帯域ネックになるまで性能を出すことはできませんでしたが、次回のNFS+ラージファイルのブログではNICロードバランスについても言及いたします。
実際のユーザ環境ではファイルサイズやディレクトリの深さは様々ですが、大量のファイルがある環境（約2000万ファイル/1TB）のデータ同期にかかる時間をイメージいただけたかと思います。このようなファイルシステムの10倍のファイル数と容量があっても、XCPを使えば24時間以内にフル同期が終わることが期待できます。
NFS+スモールファイル検証の補足事項
今回、ツールを使って大量のファイルをストレージに生成しましたが、ファイル数が多すぎてVolumeに対して以下の設定変更を行いました。
::> vol modify -vserver SVM_NAME -volume VOL_NAME -files 30000000
これによりinode不足を防ぎ、多数のファイルを書き込めるようにしました。
また、NFSやSMBのアクセスが必ず最適パスになるように、コントローラー単位に1つのNFS/SMB用のIPを割り振り、テストする際はIPの指定を変えることでコントローラを明示的に使い分けるようにしました。
Cloud Syncの特徴について
最後にNetApp Cloud Syncの宣伝をさせてください。Cloud Syncはクラウドプロバイダーやストレージベンダーに依存しないデータ同期・移行ツールです。NFS to NFSやSMB to SMBだけではなくNFS to S3やS3 to SMB、GCS to Azure BLOBなど異なるストレージ間でデータを同期できるため、マルチクラウド環境でデータの移動にご利用いただけます。
※Cloud Syncでサポートされるデータ同期パターン
上記のマニュアルを表にしたものが以下ですが、最新情報は上記URLにアップデートされますので都度ご確認ください。。
また、Cloud SyncはAWSのDataSyncとよく比較されますが、Cloud Syncのほうがクラウドの縛りが無いことと、同期するデータ量は課金に影響しないことが強みです。
機能比較もございますので、クラウド間のデータ移行だけでなくオンプレとのデータ移行の際にもCloud Syncをご検討ください。
機能比較の詳細：https://cloud.netapp.com/cloud-sync-comparison
問い合わせ：https://www.netapp.com/ja/company/contact-us/
次回
次回は「データの同期速度(3) NFS+ラージファイル」の検証結果を見ていきたいと思います。
rsyncは少しは性能が出せるかもしれませんので、お楽しみに。
