NetApp Tech OnTap
NetApp Tech OnTap
   
【検証結果から理解するネットアップのフラッシュ技術】
第21回:オール フラッシュ製品POCのススメ その2
~ 一貫して高い性能を発揮できるか ~
シェアする NetAppオフィシャルFacebook

前回のおさらい

前回(第20回)では主に、ベンチマーク ツールとして使用する 「vdbench」 の設定ファイルについてご紹介しました。また、本測定を始める前に 「POC環境がオール フラッシュ製品の限界性能を引き出せるか」 を事前に確認するテストについてご紹介しました。

さて、今回はいよいよ、本測定のフェーズに入っていきたいと思います。

はじめに:NFS環境でのvdbenchベンチマークに関して

前回(第20回)は16Gbps FCで接続されたEF560を使用してベンチマークを実施し、SAN環境におけるvdbench設定ファイルの記述についてご紹介しました。今回は10GbE NFSで接続されたAll Flash FAS8040を使用してベンチマークを実施し、NAS(本環境はNFS)環境におけるvdbench設定ファイルの記述についてご紹介します。

NFS環境でvdbenchによるベンチマークを実行するには、前回(第20回)の手順に加えて、以下の手順が必要です。

  • NFSマウントしたディレクトリ上に、ddコマンドでファイルを作成する
    • /vol1、/vol2、/vol3、/vol4がNFSマウントしたボリューム
# dd if=/dev/zero of=/vol1/testfile_300GB bs=1024k count=300000
# dd if=/dev/zero of=/vol2/testfile_300GB bs=1024k count=300000
# dd if=/dev/zero of=/vol3/testfile_300GB bs=1024k count=300000
# dd if=/dev/zero of=/vol4/testfile_300GB bs=1024k count=300000
  • 設定ファイル内のStorage Definitionで作成したファイルを指定する
* ***********************
* Storage Definition
* ***********************
sd=sd1,lun=/vol1/testfile_300GB,size=290g,openflags=o_direct
sd=sd2,lun=/vol2/testfile_300GB,size=290g,openflags=o_direct
sd=sd3,lun=/vol3/testfile_300GB,size=290g,openflags=o_direct
sd=sd4,lun=/vol4/testfile_300GB,size=290g,openflags=o_direct

この手順により、NFS環境であっても、SAN環境と同じようにベンチマークを実行できます。

基礎性能の確認

まずは、以下の全てのデータが取得できる設定ファイルを作成します。

  • スレッド数によるRandom Read性能の推移:4KB、8KB、16KB、32KB
  • スレッド数によるRandom Write性能の推移:4KB、8KB、16KB、32KB
  • スレッド数によるSequential Read性能の推移:64KB、128KB、256KB
  • スレッド数によるSequential Write性能の推移:64KB、128KB、256KB
本環境では、以下の内容で設定ファイルを作成しました。

  • 設定ファイルのサンプル:基礎性能の確認用
* *******************
* Host Definition
* *******************
hd=hd1,system=srv1,user=root,shell=ssh,jvms=16
hd=hd2,system=srv2,user=root,shell=ssh,jvms=16
hd=hd3,system=srv3,user=root,shell=ssh,jvms=16
hd=hd4,system=srv4,user=root,shell=ssh,jvms=16
hd=hd5,system=srv5,user=root,shell=ssh,jvms=16

* ***********************
* Storage Definition
* ***********************
sd=sd1,lun=/vol1/testfile_300GB,size=290g,openflags=o_direct
sd=sd2,lun=/vol2/testfile_300GB,size=290g,openflags=o_direct
sd=sd3,lun=/vol3/testfile_300GB,size=290g,openflags=o_direct
sd=sd4,lun=/vol4/testfile_300GB,size=290g,openflags=o_direct

* ************************
* Workload Definition
* ************************
wd=wd1,sd=sd*,rdpct=100,seekpct=100
wd=wd2,sd=sd*,rdpct=0,seekpct=100
wd=wd3,sd=sd*,rdpct=100,seekpct=0.1
wd=wd4,sd=sd*,rdpct=0,seekpct=0.1

* ************************
* Run Definition
* ************************
rd=rd1,wd=wd1,iorate=max,elapsed=60,interval=1,forxfersize=(4k,8k,16k,32k),forthreads=(4-40,4)
rd=rd2,wd=wd2,iorate=max,elapsed=60,interval=1,forxfersize=(4k,8k,16k,32k),forthreads=(4-40,4)
rd=rd3,wd=wd3,iorate=max,elapsed=60,interval=1,forxfersize=(64k,128k,256k),forthreads=(1-10,1)
rd=rd4,wd=wd4,iorate=max,elapsed=60,interval=1,forxfersize=(64k,128k,256k),forthreads=(1-10,1)

この中で重要な点は、設定ファイル内Run Definitionの ”forthreads” で指定する最大スレッド数です。前回(第20回)の通り、事前に確認した、使用するベンチマーク環境における最大スレッド数(オール フラッシュ製品の限界性能を引き出せるスレッド数)を、本章の設定ファイル ”forthreads” で指定します。

Sequential I/Oは、Random I/Oと比較すると、少ないスレッド数で限界性能を引き出せる傾向があります。そのため、Sequential I/Oにおける最大スレッド数も事前に確認しておきましょう。

また、オール フラッシュ製品の導入実績が最も多いデータベースでは8KB、16KBのI/Oサイズが一般的で、デスクトップ仮想化(VDI)であれば16KBのI/Oサイズが一般的であるため、想定する用途に合わせてI/Oサイズを変更することも重要です。

Sequential I/Oは、Random I/O

世の中に公開されているオール フラッシュ製品の性能は、4KBのIOPSであることが多い傾向にあります。これは、I/Oサイズが小さいほうがIOPSは高い傾向があるためです。製品によっては、I/Oサイズが倍になるとIOPSが半分になることもあるため、カタログ スペックはあくまで参考値とし、実際にPOCで確認しましょう。

本環境では、各種ワークロードに対して、以下の通りスレッド数を指定しました。

  • Random Read:forthreads=(4-40,4)
    • 実行されるスレッド数:4、8、12、…40
  • Random Write:forthreads=(4-40,4)
    • 実行されるスレッド数:4、8、12、…40
  • Sequential Read:forthreads=(1-10,1)
    • 実行されるスレッド数:1、2、3、…10
  • Sequential Write:forthreads=(1-10,1)
    • 実行されるスレッド数:1、2、3、…10

本環境の設定ファイルを指定してvdbenchを実行すると、140分後には結果が出ます(1回あたりのテストが1分、計140パターン)。午前中に実行し、ランチから帰ってきた後に結果を考察するのに調度良いかもしれませんね。

さて、いよいよベンチマーク結果を見ていきましょう。次のグラフは、"totals.html" ファイルの内容をグラフ化したものです。

  • ベンチマーク結果:Random I/O

    ベンチマーク結果:Random I/O

  • ベンチマーク結果:Sequential I/O

    ベンチマーク結果:Sequential I/O

Random Read、Random Writeともに性能(IOPS)が頭打ちになっているため、限界性能まで引き出せていることが分かります。また、複数のベンチマーク結果(本検証では140パターン)をグラフ化することで、性能の 「傾向」 が見えてきます。例えばAll Flash FAS8040では、以下の傾向が分かりました。

  1. Writeの性能(IOPS)はReadの約半分
  2. I/Oサイズ = 8KB、16KBの性能(IOPS)は、4KBと比較して10% ~ 20% 程度減少

clustered Data ONTAP(All Flash FASのストレージOS)のブロック サイズは4KBですが、ベンチマーク結果の通り、I/Oサイズ = 8KB、16KBであってもIOPSが半減することはありません。

Read & Write混合ワークロード性能の確認

次に、ReadとWriteの混合ワークロードでベンチマークを実施してみましょう。本環境では、以下の全てのデータが取得できる設定ファイルを作成します。

  • Read:Write割合によるRandom I/O性能の推移:8KB、16KB
  • データベース、VDI用途を想定し、I/Oサイズ = 8KB、16KB
  • スレッド数は本環境の限界性能を引き出せる値とし、40スレッド
本環境では、以下の内容で設定ファイルを作成しました。
  • 設定ファイルのサンプル:Read & Write混合ワークロード性能の確認用
* *******************
* Host Definition
* *******************
hd=hd1,system=srv1,user=root,shell=ssh,jvms=16
hd=hd2,system=srv2,user=root,shell=ssh,jvms=16
hd=hd3,system=srv3,user=root,shell=ssh,jvms=16
hd=hd4,system=srv4,user=root,shell=ssh,jvms=16
hd=hd5,system=srv5,user=root,shell=ssh,jvms=16

* ***********************
* Storage Definition
* ***********************
sd=sd1,lun=/vol1/testfile_300GB,size=290g,openflags=o_direct
sd=sd2,lun=/vol2/testfile_300GB,size=290g,openflags=o_direct
sd=sd3,lun=/vol3/testfile_300GB,size=290g,openflags=o_direct
sd=sd4,lun=/vol4/testfile_300GB,size=290g,openflags=o_direct

* ************************
* Workload Definition
* ************************
wd=wd1,sd=sd*,rdpct=100,seekpct=100
wd=wd2,sd=sd*,rdpct=90,seekpct=100
wd=wd3,sd=sd*,rdpct=80,seekpct=100
wd=wd4,sd=sd*,rdpct=70,seekpct=100
wd=wd5,sd=sd*,rdpct=60,seekpct=100
wd=wd6,sd=sd*,rdpct=50,seekpct=100
wd=wd7,sd=sd*,rdpct=40,seekpct=100
wd=wd8,sd=sd*,rdpct=30,seekpct=100
wd=wd9,sd=sd*,rdpct=20,seekpct=100
wd=wd10,sd=sd*,rdpct=10,seekpct=100
wd=wd11,sd=sd*,rdpct=0,seekpct=100

* ************************
* Run Definition
* ************************
rd=rd1,wd=wd1,iorate=max,elapsed=60,interval=1,xfersize=8k,threads=40
rd=rd2,wd=wd2,iorate=max,elapsed=60,interval=1,xfersize=8k,threads=40
rd=rd3,wd=wd3,iorate=max,elapsed=60,interval=1,xfersize=8k,threads=40
rd=rd4,wd=wd4,iorate=max,elapsed=60,interval=1,xfersize=8k,threads=40
rd=rd5,wd=wd5,iorate=max,elapsed=60,interval=1,xfersize=8k,threads=40
rd=rd6,wd=wd6,iorate=max,elapsed=60,interval=1,xfersize=8k,threads=40
rd=rd7,wd=wd7,iorate=max,elapsed=60,interval=1,xfersize=8k,threads=40
rd=rd8,wd=wd8,iorate=max,elapsed=60,interval=1,xfersize=8k,threads=40
rd=rd9,wd=wd9,iorate=max,elapsed=60,interval=1,xfersize=8k,threads=40
rd=rd10,wd=wd10,iorate=max,elapsed=60,interval=1,xfersize=8k,threads=40
rd=rd11,wd=wd11,iorate=max,elapsed=60,interval=1,xfersize=8k,threads=40
rd=rd12,wd=wd1,iorate=max,elapsed=60,interval=1,xfersize=16k,threads=40
rd=rd13,wd=wd2,iorate=max,elapsed=60,interval=1,xfersize=16k,threads=40
rd=rd14,wd=wd3,iorate=max,elapsed=60,interval=1,xfersize=16k,threads=40
rd=rd15,wd=wd4,iorate=max,elapsed=60,interval=1,xfersize=16k,threads=40
rd=rd16,wd=wd5,iorate=max,elapsed=60,interval=1,xfersize=16k,threads=40
rd=rd17,wd=wd6,iorate=max,elapsed=60,interval=1,xfersize=16k,threads=40
rd=rd18,wd=wd7,iorate=max,elapsed=60,interval=1,xfersize=16k,threads=40
rd=rd19,wd=wd8,iorate=max,elapsed=60,interval=1,xfersize=16k,threads=40
rd=rd20,wd=wd9,iorate=max,elapsed=60,interval=1,xfersize=16k,threads=40
rd=rd21,wd=wd10,iorate=max,elapsed=60,interval=1,xfersize=16k,threads=40
rd=rd22,wd=wd11,iorate=max,elapsed=60,interval=1,xfersize=16k,threads=40

ReadとWriteの割合を調整する繰り返し用パラメータ(”for” が付くパラメータ)はないため、設定ファイル内のWorkload Definitionで定義した ”wd1 ~ wd11” を、Run Definitionでそれぞれ実行しましょう。

本環境の設定ファイルを指定してvdbenchを実行すると、22分後には結果が出ます(1回あたりのテストが1分、計22パターン)。

次のグラフは、"totals.html" ファイルの内容をグラフ化したものです。

  • ベンチマーク結果:Read & Write混合ワークロード

    ベンチマーク結果:Read & Write混合ワークロード

ベンチマーク結果から、All Flash FASは、Random Writeの割合が多いワークロードでも性能が高いことを確認できました(Random Write性能はRandom Read性能の約1/2)。一般的に、オール フラッシュ製品はRandom ReadとRandom Writeの性能に大きな差があります。極めて高いRandom Read性能を発揮する一方で、Random Write性能はその1/5程度になるケースも珍しくありません(それでも、HDDの性能と比較すれば非常に高い性能です)。例えば、VDIのようにRandom Writeの割合が多い環境でオール フラッシュ製品を適用する場合、Random Write割合が多いワークロードでベンチマークを実施することが重要です。

性能の一貫性を確認(ストレステスト)

今回の内容で最も重要なのが、このベンチマークです。フラッシュ(NAND)は、その構成上、性能が大きく変化する可能性があり、オールフラッシュ製品の落とし穴の1つです。フラッシュ(NAND)デバイスの特徴に関しては、第9回の内容をご確認ください。


書き込み量の増幅(Write Amplification)を可能な限り抑える仕組みを、各ベンダはファームウェアやストレージOSで実装していますが、それらの処理はホストからのI/Oと比較すると非常に重い処理です。

実システムでは、そのサービスを提供し続けるために、ストレージは長時間I/Oを続けます。長時間のホストI/Oが続いている状態で、Garbage Collectionによるスペア ブロックの作成処理がどこまで耐えられるのでしょうか。そんな疑問を払拭するためにも、長時間のベンチマークは非常に重要です。

ストレステストをするための設定ファイルを作成します。

  • 16KB Random I/O(Read 20%:Write 80%)、32スレッド
  • 上記のI/Oワークロードを12時間(43,200秒)続ける

本環境では、以下の内容で設定ファイルを作成しました。

  • 設定ファイルのサンプル:ストレステスト用
* *******************
* Host Definition
* *******************
hd=hd1,system=srv1,user=root,shell=ssh,jvms=16
hd=hd2,system=srv2,user=root,shell=ssh,jvms=16
hd=hd3,system=srv3,user=root,shell=ssh,jvms=16
hd=hd4,system=srv4,user=root,shell=ssh,jvms=16
hd=hd5,system=srv5,user=root,shell=ssh,jvms=16

* ***********************
* Storage Definition
* ***********************
sd=sd1,lun=/vol1/testfile_300GB,size=290g,openflags=o_direct
sd=sd2,lun=/vol2/testfile_300GB,size=290g,openflags=o_direct
sd=sd3,lun=/vol3/testfile_300GB,size=290g,openflags=o_direct
sd=sd4,lun=/vol4/testfile_300GB,size=290g,openflags=o_direct

* ************************
* Workload Definition
* ************************
wd=wd1,sd=sd*,rdpct=20,seekpct=100

* ************************
* Run Definition
* ************************
rd=rd1,wd=wd1,iorate=max,elapsed=43200,interval=1,forxfersize=16k,threads=32

この中で重要な点は、以下の2つです。

  1. ReadとWrite混合ワークロードにすること
  2. 実行時間(elapsed)の検討

1. に関しては、実ワークロードに近いReadとWriteの割合を設定すれば良いです。本環境では、VDI定常状態ワークロードを想定してRead:Write = 20:80の割合としました。I/Oサイズは16KBとしています。ネットアップ社としては、VDI環境おける平均I/Oサイズは16KBとしているためです。

2. に関しては、最適なテスト時間は、性能(IOPS)、搭載しているフラッシュ容量、製品の作りに依存するため、一概には言えません。しかし、一般的なベンチマーク環境であれば、12時間続ければ十分と考えています。例えば、本環境では400GB SSD x 23(x 1はスペア ドライブ)で、物理容量9.2TBを搭載しています。16KB Random I/O(Read 20%:Write 80%)の32スレッド時の性能が58,000 IOPSであるため、1時間で約3.2TB分のI/O量があります。12時間続ければ、38.4TBであるため、本環境で搭載したフラッシュの物理容量(9.2TB)に対して、4周以上していることになります。このような計算をした場合に、最低でも2周分のI/O量を続けることをお勧めします。また、VDI定常状態に限らず、業務時間である7~8時間のI/O負荷が続くことは一般的であり、寝る前にベンチマークを実行すれば、朝起きると結果が取得できている、ということで、12時間をお勧めしました(週末に60時間のベンチマークを流すのもアリです)。

  • ベンチマーク結果:ストレステスト

ベンチマーク結果:ストレステスト

ネットアップのオール フラッシュ製品(All Flash FAS、EFシリーズ)は、その高い性能を一貫して提供する 「安定性」 を優先しています。いくらピーク時の性能が高くても、経過時間によって性能が劣化する場合、長時間のワークロードが続く実システムに適用することは困難であるためです。

※ 注意事項

もし、前章のストレステストで経過時間による性能劣化が確認できた場合、それぞれの章(基礎性能の確認、Read & Write混合ワークロード性能の確認)で取得したベンチマーク結果には注意が必要です。設定ファイルのサンプルで指定した1回あたりのテスト時間は1分であるため、取得した結果はあくまでピーク時の性能に近いデータです。その場合、実システムで運用した場合の性能と大きく異なる可能性があることをご注意ください。

前章の検証結果の通り、ネットアップのオール フラッシュ製品は経過時間による性能劣化はありません。その場合は性能に一貫性があるため、1回あたりのテスト時間を1分として取得したデータにも妥当性があると言えます。

次回の内容

今回の内容では、オール フラッシュ製品の性能の一貫性を確認するためのvdbenchの設定ファイルについてご紹介しました。ご紹介した実行時間による性能への影響の他、オール フラッシュ製品にはまだまだ確認するべき落とし穴があります。次回の内容では、それらの落とし穴を確認するためには、どういったワークロードを、どういった設定ファイルでベンチマークすれば良いか、についてご紹介したいと思います。

岩本 知博 岩本 知博(いわもと ともひろ)
ネットアップ株式会社
システム技術本部 – コンサルティングSE部 - コンサルティングSE - Flashtronauts

会津大学大学院 コンピュータ理工学研究科卒、外資系データベース メーカを経て2012年パートナーSEとして入社。入社以来、パートナー支援とフラッシュ ソリューションおよびデータベース ソリューションを中心に活動。

【検証結果から理解するネットアップのフラッシュ技術】
  arrow バックナンバー

関連情報
関連情報
【検証結果から理解するネットアップのフラッシュ技術】
第1回:フラッシュ技術をリードするネットアップの
ポートフォリオとその棲み分け


第2回:バーチャル ストレージ ティアとオール
フラッシュ アレイでオーバーサイジングを解決


第3回:バーチャル ストレージ ティアの強み
~ Flash Cache と Flash Pool の検証結果~


第4回:Flash CacheとFlash Poolの特徴(詳細編)
~キャッシュ ヒット率とキャッシュの永続性に
ご注意を!!~


第5回: Flash Poolの特徴(応用編)
~マルチ ワークロード対応の最強の
ディスク プールを構成する~


第6回:NetApp Flash PoolとOracle Database Smart Flash Cache の検証結果から理解する サーバ側キャッシングソリューションの特徴

第7回:NetApp Flash PoolとOracle Database Smart Flash Cacheの組み合わせ
~DB統合の密度を極限まで高める~

第8回:検証結果から導かれるFlash Cache、Flash Pool、Database Smart Flash Cacheの特徴

第9回:フラッシュ デバイスの特徴(基本編)
~ フラッシュ デバイス構造から理解する
書き込み量の増幅を改善する仕組み ~


第10回: ネットアップのオール フラッシュ アレイ
「EF550 」ならではの強み ~ Why EF550 編 ~


第11回: NetApp EF550の高可用性を実現する機能「Dynamic Disk Pool」
~ シンプルなRAID構成でドライブ障害時の性能維持とリビルド処理の高速化を実現 ~


第12回:Oracle Database環境でのEF550
の有効性
~ OLTP処理性能の向上と、バッチ処理の高速化を両立するEF550(OLTP編) ~


第13回: Oracle Database環境でのEF550の有効性
~ OLTP処理性能の向上と、バッチ処理の高速化を
両立するEF550(バッチ処理編)~


第14回:【検証結果から理解するネットアップのフラッシュ技術】
FASシリーズをオール フラッシュ構成にするとどうなる?
高性能と大容量を実現するAll-Flash FASの登場


第15回:
All-Flash FASの価格性能比と価格容量比を極める
~ All-Flash FAS8060検証結果 ~


第17回:
速報! Data ONTAP 8.3RC1検証結果 ~ 8.2.2から8.3RC1での性能向上 ~


【番外編】 第18回:
Data ONTAP 8.3でエントリーモデルが大幅に性能向上!
~ 8.2.2から8.3RC1での性能向上 ~


第19回:
Flash Poolの効果を最大限引き出す
~AWAによる最適なキャッシュ サイズの見積もり~


【検証結果から理解するネットアップのフラッシュ技術】
第20回:オール フラッシュ製品POCのススメ

関連情報
 
Go further, faster TRUSTe
お問い合わせ   |   購入方法   |   フィードバック   |   採用情報  |   登録   |   プライバシーポリシー   |   © 2015 NetApp