Name：井谷 寛
Title：ネットアップ合同会社 システム技術本部 ソリューション アーキテクト部 ソリューションアーキテクト
October, 2020
はじめに
異機種ストレージ間のデータ移行、もしくはクラウドへのデータ同期・移行において、その時間の見積もりには苦労します。転送レートに関する情報はネットを探してもあまり見当たりません。そこでこのブログシリーズでは実際に環境を準備し、4つのデータ同期ツール（rsync, robocopy, NetApp XCP, NetApp Cloud Sync）を使って比較を行いました。
このテストでは最大性能を計測することが目的ではなく、実案件で発生しうるであろう初期のボトルネックがどこにあるか、またそれをどのように解消するかに主眼を置いています。ツールの優劣を決めるのではなく、用途によって使い分ける判断材料になれば幸いです。
ブログのシリーズの後半では、日本のネットアップに常設しているハイブリッド・マルチクラウドラボを利用してAWSもしくはAzureとプライベート接続（Direct Connect / Express Route）をした際のデータ同期速度も掲載する予定です。
このブログはデータの同期速度に主眼を置いていますが、それぞれのツールの紹介や機能に関する情報、セットアップ手順や操作方法に関するブログ（以下の2)と3)）も今後リリースされる予定なのでご期待ください。
|
技術要素の分類 |
|
|---|---|
|
1.)データの同期速度 |
ツール別のデータ同期速度の比較情報 （本ブログの範囲） |
|
2.)メタデータの移行 |
ファイルの日付や権限、スパースファイル対応可否などの同期・移行ツール機能に関する情報 |
|
3.)データ同期の操作方法 |
各種ツールの特徴とセットアップ・操作手順についての情報 |
検証環境概要
同期元のストレージはミドルレンジのFAS8040 (ONTAP9.1)、データ同期先にAFF8080 (ONTAP9.7) を用意しました。仮想サーバはテスト内容に応じてLinuxとWindowsを使い分けています。
(1) オンプレ to オンプレ
（※クリックで拡大します）
(2) オンプレ to クラウド
クラウド側の詳細な環境は今後のブログに記載予定です。
（※クリックで拡大します）
ここから先はオンプレ to オンプレの環境について記載します。
少し細かい内容となるため、とりあえず性能の結果だけを確認したい人は「データの同期速度(2) NFSとスモールファイル」や「データの同期速度(3) NFSとラージファイル」をご覧ください。
ストレージ物理構成 (オンプレ to オンプレ)
ソース：FAS8040 (HA) – ONTAP 9.1 P20
ディスクシェルフ
DS2246(1) SAS 450GB x24 for Controller A (RAID-DP, 18Disk 2Parity構成)
DS2246(2) SAS 450GB x24 for Controller A (RAID-DP, 18Disk 2Parity構成)
DS2246(3) SSD 400GB x24 for Controller A (RAID-DP, 21Disk 2Parity構成)
DS2246(4) SAS 450GB x24 for Controller B (RAID-DP, 18Disk 2Parity構成)
DS2246(5) SAS 450GB x24 for Controller B (RAID-DP, 18Disk 2Parity構成)
DS2246(6) SSD 400GB x24 for Controller B (RAID-DP, 21Disk 2Parity構成)
NIC構成
NFS/SMB通信用NIC：10GbE x3 / controller, 10GbE x6 / HA pair
インターフェースグループ（NICチーミング）の設定
SR-8040::> ifgrp show -node SR-8040-01 -ifgrp a0a -instance
Node: SR-8040-01
Interface Group Name: a0a
Distribution Function: ip
Create Policy: multimode_lacp
MAC Address: 02:a0:98:54:08:2a
Port Participation: full
Network Ports: e0e, e0g, e3b
Up Ports: e0e, e0g, e3b
Down Ports: -
ターゲット：AFF8080 (HA) – ONTAP 9.7P6
ディスクシェルフ
DS2246(1) SSD 800GB x 24 for Controller A and B (ADP, 21D 2P / Controller)
NIC構成
NFS/SMB 通信用NIC：10GbE x2 / controller, 10GbE x4 / HA pair
インターフェースグループ（NICチーミング）設定
SR-AFF8080::> ifgrp show -node SR-AFF8080-01 -ifgrp a0a
Node: SR-AFF8080-01
Interface Group Name: a0a
Distribution Function: ip
Create Policy: multimode_lacp
MAC Address: 02:a0:98:9b:ad:83
Port Participation: full
Network Ports: e0e, e0g
Up Ports: e0e, e0g
Down Ports: -
コントローラ性能上限 （ストレージサイジングツールのNetApp Fusion v1.9.0を利用）
ソース：FAS8040 (HA)
コントローラあたりのNFS READ性能：約2000MBytes/s以上
※ 32KBシーケンシャルREAD 100％の場合
※ HAペアはその2倍
ターゲット：FAS8080 (HA)
コントローラあたりのNFS WRITE性能：約2200MBytes/s以上
※32KBシーケンシャルWRITE 100%の場合
※HAペアはその2倍
サーバ（データ同期ツールが動作するサーバ）
ESXiサーバ （物理）
24コア220GB memory, 物理NIC 40GbE x2 を1台
仮想サーバ （※ 必要に応じて1台～5台でテストしています。）
CentOS 7.5
スペック：4コア 64GB
導入ソフト：vmware-tools, rsync(v3.1.2 protocol version 31),
NetApp XCP(v1.6.1), NetApp Cloud Sync Data Broker(v1.3.0)
※ Cloud Sync Data Brokerは2020年9月に性能向上のアップデートが入っていますが、2020年8月時点のバージョンでテストしています。
https://docs.netapp.com/us-en/cloudsync/reference_new_cloud_sync.html
その他：SELinuxとFirewalldを無効化。
以下のOSカーネルパラメータチューニングを実施。(/etc/sysctl.conf)
net.core.rmem_default = 1342177
net.core.rmem_max = 16777216
net.core.rmem_max = 16777216
net.core.wmem_default = 1342177
net.core.wmem_max = 16777216
net.ipv4.tcp_rmem = 4096 1342177 16777216
net.ipv4.tcp_wmem = 4096 1342177 16777216
net.core.netdev_max_backlog = 300000
net.ipv4.tcp_fin_timeout = 10
※ 反映にsysctl -pを実施。
Windows Server 2016
スペック：4コア 32GB
導入ソフト：vmware-tools, robocopy(プリインストール), NetApp XCP(v1.6.1)
その他：Windows Defenderを無効化 （グループポリシー設定）
※ Windows Defenderを停止しないと、以下のようにAntimalwareがCPUを消費し、性能が出ない場合があります。
ネットワーク構成
Cisco Nexus 93180YC (1/10/25Gbps x48, 40/100Gbps x6) にすべての機器を直結。
※ ESXiサーバのみ40GbEポートを利用、それ以外は10GbE。
データ同期に使われるすべてのサーバ・ストレージNICはMTU9000に設定。
テストデータについて
(1)スモールファイル
データサイズ：953GiB（1952万3812ファイル、195万3125ディレクトリ）
データ生成ツール：VDbench
ディレクトリ構造とファイルの種類：
- 重複排除・圧縮の効かない50KBのファイルをvdbenchで生成
- ファイルサーバ共有の下に4つのディレクトリ（hfc1～hfc4）を作成し、それぞれその下に8階層までディレクトリを作成。各ディレクトリには50KBのファイルを10個配置。
(2)ラージファイル
データサイズ：1.08TiB （11604ファイル、1542ディレクトリ）
データ生成ツール：利用せず
ディレクトリ構造とファイルの種類：
- ネットアップ社内ラボのファイルサーバのデータを利用。
- ISOファイルやソフトウェアのインストール前のexeファイルなど大きなファイルで構成される。
想定されるボトルネック
データの同期速度はソースの読み出し性能とターゲットの書き込み性能が大きく影響しますが、ここではもう少しネックについて深掘りしたいと思います。
性能に影響を与える要素は以下が考えられます。
■ 読み出し性能
a)ファイルのサイズ（ラージファイル or スモールファイル）
b)ファイルシステムとNASプロトコルオーバーヘッド
c)ディスクタイプ（SATA/SAS/SSD）とその本数、RAIDの種類
d)ディスクからストレージコントローラ間の帯域幅（SAS/FCの帯域とパス数）
e)コントローラのCPU性能
f)データを転送する先のNICの帯域とポート数、負荷分散方式
■ データ同期ツールの動作するサーバ
a) データ受信NICの帯域とポート数、負荷分散方式
b) サーバのCPU性能／データ同期ツールのマルチスレッド動作可否
c) データ送信NICの帯域とポート数、負荷分散方式
■ 書き込み性能
a)データを受信する先のNICの帯域とポート数、負荷分散方式
b)ファイルシステムとNASプロトコルオーバーヘッド
c)コントローラのCPU性能
d)ディスクからストレージコントローラ間の帯域幅（SAS/FCの帯域とパス数）
e)書き込み先のディスクタイプ（SATA/SAS/SSD）とその本数、RAIDの種類
f)書き込み時のファイルのサイズ（ラージファイル or スモールファイル）
小さなファイルの転送オーバーヘッドが大きいことはよく知られていますが、ファイルシステムの種類(ntfs, ext3/4, xfs, ReiserFS)が多数の小さなファイルに強いかどうかも大事な要素です。インフラ基盤全体の負荷が低いにも関わらず性能が出ない場合は、ファイルシステムやプロトコルのボトルネックを疑う必要があります。
また、当然ですがRAIDを構成するディスクの種類と本数も重要です。同じ本数であればSATAよりSSDの方が高速で、また本数が多ければ多いほど性能は上がります。しかしもしコントローラCPUやNIC、あるいはファイルシステムがボトルネックになっている場合はSSDの本数がいくら多くても意味がありません。
今回は環境全体のボトルネック箇所を確認しながら複数のテストパターンを実施しました。
テスト環境のサマリー
テスト環境の詳細については各テスト結果の前半に記載しますが、大まかに以下のような条件でテストを実施しました。
|
|
スモールファイル |
ラージファイル |
|---|---|---|
|
ファイル数/ディレクトリ数 |
953GiB, |
1.08TiB, |
|
プロトコル |
NFSv3 / SMB |
NFSv3 / SMB |
|
利用するツール |
NFS: |
同左 |
|
ACL等の権限移行 |
ONで計測 (一部のテストでOFF) |
ONで計測(一部のテストでOFF) |
|
移行前後のデータ比較機能 |
OFFで実施 |
OFFで実施 |
|
差分検出のスキャン時間 |
計測する |
計測しない |
|
データ同期の並列度 |
様々なパターンを実施(後述) |
同左 |
次回
次回のブログ「データの同期速度(2)NFS+スモールファイル」では実際のデータ同期性能を記載したいと思います。
