#目次
- この記事のサマリー
- 環境
- 構成上の留意点
- テスト結果 - 構成別の性能差 (CVOのsysstat結果を記載)
- テストする際の考慮点
- まとめと雑談
- 関連情報
#1. この記事のサマリー
- いくつか条件を変えてクラウドへのデータ移行性能をテストした結果を一覧表にしています。
- 移行先はクラウドインスタンス上で動作するNetApp CVO(Cloud Volumes ONTAP)です。
- 移行にONTAPのSnapMirrorを使わず、ツールで上抜きコピーしています。
- 既存で存在する技術レポート(TR-4383)にはCVOの単体性能が書かれていますので、参考にしてください。
TR-4383 Performance Characterization of NetApp Cloud Volumes ONTAP for Amazon Web Services
https://www.netapp.com/pdf.html?item=/media/9088-tr4383pdf.pdf - このQiita記事ではTR-4383に記載されていないDirect Connect経由の性能測定をしており、また、CVOに割り当てるEBSストレージの容量・数・タイプを変えて計測しています。
- NFS to NFSを前提に計測しましたが、CIFS to CIFSでもそれほど大きな違いはありませんでした。
- 環境の詳細を以下に記載しますが、まず最初に1GのDirect Connectを使った際にはネットワーク回線ネックがあらわれて、10Gに切り替えた後は移行先のEBSストレージの性能ネックが見えてきました。そして最後にCVOが動作するインスタンスタイプ起因のボトルネックがありました。
- 回線はDirect Connectを使ったためストレージ間の遅延は2ms程度でした。
- 10GのAWS Direct Connect回線は非常に高速で、受け側のストレージが十分に高性能であれば24時間で50TB以上のデータをクラウドに移行することも可能です。AWSへのアップロードの回線コストは固定費として1時間で約$2.361/時間(東京リージョン、2021年4月時点)となり、24時間使っても7000円未満です。(Equinixデータセンターの利用料は別。)
価格表:https://aws.amazon.com/jp/directconnect/pricing/ - インターネットVPN(Nuro Biz回線, インターネットVPN1Gbps)を使ったパターンも~~今後テスト予定です。~~テストしました。
■AWSと1GbpsでインターネットVPN接続してデータ移行性能を計測してみた (NetApp FAS -> CVO)
https://qiita.com/kan_itani/items/8dc4f0995833df54ab59
#2. 環境
-
移行元ストレージ (設置先:Equinixデータセンター、大手町TY4)
- NetApp FAS8040 (ONTAP9.1) / DS2246 (SSD x24本)
-
移行先ストレージ (AWS東京リージョン)
- NetApp CVO (Cloud Volumes ONTAP, ONTAP 9.9.0)
- CVOのHA構成: 無し(=Single Node)
- CVOのインスタンスタイプ:m5.xlarge / r5.2xlarge / r5.12xlarge
- CVOにアタッチするEBS:gp2(SSD) / st1(HDD)
※ CVOにアタッチしたEBSボリュームはRAID-0でストライプされて利用されます。
※ 同じタイプの同じサイズのEBSをそのRAID内に入れることができます。
※ 既存のRAID-0内に後からEBSを追加することもできますが、すでにDISK使用率が高い場合は後から追加したEBSにWriteが偏るため、性能面でのメリットはあまりありません。
-
ネットワーク回線
- Equinixデータセンター経由のAWS Direct Connect接続 (1Gbps/10Gbps)
※ Direct ConnectのMTUは1500
- Equinixデータセンター経由のAWS Direct Connect接続 (1Gbps/10Gbps)
-
データ移行ツール
(1) NetApp XCP (ホストインストール型ソフトウェア)
(2) NetApp Cloud Sync (SaaSサービス)
※ ラージファイルをテストデータに使ったため性能差があまりなく、以下はXCPでの結果を記載しています。
※ XCPをインストールしたサーバは4コア32GBで、このサーバネックにならないようにサイジングしています。
#3. 構成上の留意点
- 回線速度を使いきれるように移行元データはSSD上に配置しました。
- 事前にオンプレ to オンプレでデータ移行を試し、移行元で1000MBytes/s以上の読み出し性能が出せることを確認しています。
- ボトルネックはDirect Connect回線、もしくはクラウド上のインスタンスとなる構成としました。
- MTUを9000にするともう少し性能が出るかもしれませんが、デフォルトのまま試しています。
#4. テスト結果 - 構成別の性能差 (CVOのsysstat結果を記載)
No. | インスタンス | 回線速度 | EBS構成(gp2 or st1) | 転送レート(bytes/s) | CPU使用率(CVO) | 備考 |
---|---|---|---|---|---|---|
(1) | m5.xlarge | 1Gbps | gp2 500GB x1 | 120 MB/s | 50-70% | 1Gbps回線ネック。gp2のバーストクレジットが無くなるとさらに半分程度まで性能が落ちる |
(2) | m5.xlarge | 10Gbps | st1 1TB x2 | 250-300 MB/s | 60-70% | EBSネック。st1のバーストクレジットが無くなるとそのボリュームサイズ本来の速度になる |
(3) | m5.xlarge | 10Gbps | gp2 1TB x4 | 未テスト | 未テスト | CVOのCPUネックになる可能性大 |
(4) | r5.2xlarge | 10Gbps | gp2 8TB x1 | 260 MB/s | 30-45% | EBSネック |
(5) | r5.2xlarge | 10Gbps | gp2 1TB x4 | 580 MB/S | 65-75% | r5.2xlargeインスタンスのEBS 帯域幅ネック。AWSのマニュアルでは最大4,750Mbps(≒593MB/s)と記載有 |
(6) | r5.2xlarge | 10Gbps | st1 1TB x4 | 250-300 MB/s | 30-45% | st1を4つ束ねても性能向上しない。平均250 MB/s程度。 |
(7) | r5.12xlarge | 10Gbps | gp2 2TB x2 | 530 MB/s | 10-14% | CPU負荷は低く、EBSネック |
(8) | r5.12xlarge | 10Gbps | gp2 1TB x4 | 680-720 MB/s | 16-17% | EBSネック。r5.12xlargeのEBS帯域幅は9,500Mbpsのため、gp2 1TB x8にすれば1187MB/s(≒9500Mbps)まで出る可能性有り、10Gbpsを使い切れると想定 |
-
(1) m5.xlarge(1G, gp1 500GB x1の性能)
-
(2) m5.xlarge(10G, st1 1TB x2の性能)
-
(3) m5.xlarge(10G, gp2 1TB x4の性能)
- CVOのsysstat結果
- 未テスト
- XCPデータ移行ツールの表示
- 未テスト
- CVOのsysstat結果
-
(4) r5.2xlarge(10G, gp2 8TB x1の性能)
-
(5) r5.2xlarge(10G, gp2 1TB x4の性能)
-
(6) r5.2xlarge(10G, st1 1TB x4の性能)
-
(7) r5.12xlarge(10G, gp2 2TB x2の性能)
-
(8) r5.12xlarge(10G, gp2 1TB x4の性能)
#5. テストする際の考慮点
-
EBSのサイズとバーストクレジットに注意
EBSはディスクタイプとそのサイズによってベースの性能とバースト性能が異なるため、最初は高速に転送できても1時間後には低速になることもあります。
以下の**「I/O クレジットおよびバーストパフォーマンス」**が参考になりますが、
【Amazon EBS ボリュームの種類】
https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/ebs-volume-types.html#EBSVolumeTypes_considerations- 汎用SSDボリューム(gp2)の場合の性能
とても長いので、クラスメソッドさんのブログをおすすめします。(シンプルでわかりやすい)
https://dev.classmethod.jp/articles/ebs-gp2-burstbalance/
- 汎用SSDボリューム(gp2)の場合の性能
-
CVOは割り当てられたEBSをRAID-0でストライプしますが、8TBのgp2ボリューム1つの構成と、1TBのgp2ボリュームを4つストライプする構成では後者の方が性能が出ました。サイジングする際には容量だけでなくEBSの本数も考慮して構築してみてください。
-
EBS単体の性能だけでなく、インスタンスタイプ毎に制限があるため、以下の**「ネットワーク帯域幅」と「EBS帯域幅」**を確認の上、自分で利用するEC2インスタンスを選択することをお勧めします。
【Amazon EC2インスタンスタイプ】
https://aws.amazon.com/jp/ec2/instance-types/
インスタンスの最大性能を超えるEBSを割り当てても性能が出ないので、容量と性能のバランスを考えてEBSのタイプ(gp2/io2/st1/sc1)を選択することでコストを下げることができます。 -
st1のEBSは2個、4個と本数を増やしても、性能はリニアに向上しませんでした。AWSのマニュアルには、
「1 TiB の st1 ボリュームの場合、バーストスループットは 250 MiB/秒に制限され、バケットのクレジットは 40 MiB/秒で最大 1 TiB 分まで累積されます。」と記載されており、また、「バーストスループットの範囲は、31 MiB/秒~500 MiB/秒 (上限) です。次に示すように、この上限には 2 TiB で到達します。」 と記載されています。そのためst1 1TB x4で性能がリニアに上がらないのは、CVO側の何らかの内部の動作に起因している可能性を疑っていますが、新しいことがわかったら追記します。(CVOが4つのEBSを同時にストライプせずに1つずつ利用しているような挙動をしている場合、st1を2TBで割り当てることで500MiB/sの性能が出る可能性があります。)
#6. まとめと雑談
- 今回はあまり細かいチューニングを行わず、簡単なGUI操作で出来る範囲の設定変更でデータ移行性能を計測してみました。
- 移行元の単一ボリュームを1つだけ転送して測定しましたが、複数のボリュームを同時並列で移行すればさらに性能が期待できます。
- 今回はAWSにデータ移行しましたが、GCPのCVOへの移行はとても魅力的な選択肢となります。オンプレミスのデータストアをGCPのCVOに移行すれば、そのデータはGCVE(Google Cloud VMware Engine)からデータストアとして利用することができます。GCVEの内蔵のvSAN領域を使わなくても良くなり、オンプレミスの仮想基盤の引っ越し先としてGoogle Cloudは有力な選択肢となります。
- 移行ツールのXCPは汎用的に使えるツールで、移行元のストレージのメーカーやタイプも選びません。
- この検証は以下の環境を利用しました。NetAppソリューションを検討されているお客様はどなたでもご利用できますので、ご興味のある方はNetApp担当営業、もしくはNetAppパートナーまでお問い合わせください。
#7. 関連情報
- NetApp Cloud Volumes ONTAP紹介・設定動画
https://www.youtube.com/playlist?list=PL2CVZPvKXD1_eOPuQmZzspNG2tmuswrYd - NetApp XCPの紹介
https://www.slideshare.net/kanitani35/netapp-xcp - XCPを使ったオンプレ to オンプレデータ移行性能(rsyncとの比較)
https://www.storage-channel.jp/blog/nfs-small-file.html - AWS Direct Connectユーザーガイド
https://docs.aws.amazon.com/ja_jp/directconnect/latest/UserGuide/dc-ug.pdf - Direct Connect価格表
https://aws.amazon.com/jp/directconnect/pricing/ - AWSと1GbpsでインターネットVPN接続してデータ移行性能を計測してみた (NetApp FAS -> CVO)
https://qiita.com/kan_itani/items/8dc4f0995833df54ab59