NetApp Tech OnTap
NetApp Tech OnTap
   
【検証結果から理解するネットアップのフラッシュ技術】
第19回:
Flash Poolの効果を最大限引き出す
~AWAによる最適なキャッシュ サイズの見積もり~
シェアする NetAppオフィシャルFacebook


ここ数回分の本連載(検証結果から理解するネットアップのフラッシュ技術)では、オール フラッシュ ストレージ(EF-Series、All-Flash FAS)をメインにご紹介してきました。

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

次のグラフ(図 1)は、フラッシュ ストレージの利用(利用予定)用途の回答率です。
  • グラフ値(%)の意味:フラッシュ ストレージを利用(利用予定)している494社の回答率
  • Source:IDC Japan, 2014 年 12 月 「2014 年 国内企業のストレージ利用実態に関する
    調査(2014 年 12 月調査版):次世代ストレージがもたらす IT インフラの変革」(J15550601)

図 1. フラッシュ ストレージの利用(利用予定)用途:494 社

フラッシュ ストレージの利用(利用予定)用途:494 社

「特定のデータを長期に保存」と「ブートドライブとして利用」をオール フラッシュ構成、「ILM」と「データ キャッシュ」をハイブリッド構成(フラッシュとHDD混在)とすると、2014年でオール フラッシュ構成が浸透してきたことを感じます。一方、フラッシュ利用(利用予定)で最も多いのは「データ キャッシュ」であり(ILMに8%勝る)、ネットアップのFlash Cache / Flash Poolは有用であると言えます。

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

そこで今回(第19回)は、Flash Poolの効果を最大限引き出すためのサイジングツールであるData ONTAPの機能「Automated Workload Analyzer(AWA)」をご紹介したいと思います。

Flash PoolとAll-Flash FAS(SSDアグリゲート)

次のグラフは、SSD x 4をFlash Poolで構成、またはAll-Flash FAS(SSDアグリゲート)で構成したときの検証結果です。検証環境は以下の通りです。

  • FASモデル:FAS3220AE(負荷をかける対象は1コントローラのみ)
  • OSバージョン:clustered Data ONTAP 8.2.1
  • ドライブ:DS2246 200GB SSD x 12、DS2246 900GB SAS x 12
  • アグリゲート構成
    • SSDアグリゲート(2D2P)
    • Flash Pool(SSD:2D2P、SAS9D2P)
    • HDDのみのアグリゲート(SAS9D2P)

図 2. 検証結果とFlash PoolとAll-Flash FAS

検証結果とFlash PoolとAll-Flash FAS

HDDのみのアグリゲートでは、書き込みの割合が多くなるほど性能が高くなるData ONTAPならではの特性が確認できました(図中:黄色の折れ線グラフ)。SSDアグリゲート(All-Flash FAS)であれば、読み込みと書き込みの割合に関わらず、FASコントローラの限界性能まで引き出すことができました(図中:赤色の折れ線グラフ)。必要なデータをSSDに格納することができれば、(ほぼ)確実にFASコントローラの性能を最大限に引き出すことが可能であり、性能トラブルの可能性を最小化できることがAll-Flash FASの優位性と言えます。

※ FAS3220は1世代前のモデルです。最新のFAS8000で必要なSSD数の検証結果と考察は、第15回の内容をご参照ください。

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

一方、必要なデータをSSDに格納しきれない場合は、Flash Pool(またはFlash Cache)が有効です。Flash Pool環境では、全データから必要なブロックだけが、リアルタイムにSSDにキャッシュされます。もちろん、メモリでのキャッシュのアーキテクチャと同様、全自動で行われ、ユーザが特別な設定をする必要はありません。Flash Poolを使用した場合、ユーザが考慮しなければならないことは、大きく2つが挙げられます。

  • 実システムのワークロード分析:現行ワークロードはキャッシュ向きのワークロードなのか?
  • Flash Poolキャッシュ サイズの検討:アクセス頻度が高いブロックを全てキャッシュするために必要なキャッシュ サイズは?

図中の青色の折れ線グラフは、Flash Poolにおけるキャッシュ ヒット率が限りなく高い、理想の性能(IOPS)です。一方、仮に全くFlash Poolが効かなかった場合はHDDの性能(IOPS)になるため、図中で言えば黄色の折れ線グラフになります。結果、実システムのワークロードを分析し、それに対する最適なキャッシュ サイズを確保することで、All-Flash FAS(SSDアグリゲート)並の性能に近付けることが可能になるため、前述の2つの要素を把握することが非常に重要と言えます。

Automated Workload Analyzer(AWA)

Data ONTAPは、Flash Poolの最適なキャッシュ サイズを見積もるためのサイジング ツール「Automated Workload Analyzer(以降、AWA)」という機能を搭載しています。

  • Automated Workload Analyzer(AWA)
    • Data ONTAP 8.2.1以降のバージョンで使用可能
    • 7-Mode、clustered Data ONTAPともに使用可能

AWAを使用することで、実システムに対するワークロードをバックグラウンド監視し、Flash Poolアルゴリズムをシュミレートすることで、最適なキャッシュ サイズと予測されるヒット率を見積もることが可能です。AWA実行によるFASシステムへのオーバーヘッドは極めて小さく、実行手順もシンプルなため、是非ご活用ください。

AWA実行手順

AWAの実行は非常にシンプルで、Data ONTAPにログインし、以下の手順でCLIを実行します。

  • advanced以上の権限が必要
  • clustered Data ONTAPの場合、CLIはNodeshellを使用

1. アグリゲートを指定してAWA有効化

cdot-01*> wafl awa start <aggrname>
AWA started.


2. AWAサマリを表示

  • "-l " で期間の指定が可能
cdot-01*> wafl awa print <aggrname>


3. AWAを停止

  • AWAサマリも表示される
  • 3. でAWA停止後、2. AWAサマリの表示も可能
cdot-01*> wafl awa stop <aggrname>


AWAサマリ:解析結果の表示

次の出力結果は、I/Oサイズが4KB、100% Random Readの負荷がかかっているときにサンプリングしたAWAサマリです。

図 3:AWAサマリ(I/Oサイズ = 4KB、100% Random Read)

AWAサマリ(I/Oサイズ = 4KB、100% Random Read)

「Cacheable Read(%)」は100%であり、今回のワークロードはFlash Poolを使用することで全てキャッシュ可能であることが分かります。そして、全て(100%)キャッシュさせるには、「Max Projected Cache Size」の通り、123.962GB必要なことも分かります。今回のワークロードは100% Random Readであるため、単純にキャッシュ サイズを大きくすれば全てキャッシュさせることが可能です。

次の出力結果は、I/Oサイズが4KB、50% Random Read & 50% Random Writeの負荷がかかっているときにサンプリングしたAWAサマリです。

図 4:AWAサマリ(I/Oサイズ = 4KB、50% Random Read & 50% Random Write)

AWAサマリ(I/Oサイズ = 4KB、50% Random Read & 50% Random Write)

「Cacheable Write(%)」は94.318%であり、Flash Poolを使用することで、書き込み処理の約94%をキャッシュ可能であることが分かります。上書きしたデータは、その後読み込む可能性が高い傾向(特に、データベース)にあるため、Flash Poolでは、書き込み処理のうち上書きデータをキャッシュします(デフォルト、変更可能)。通常であれば、分析するのが難しい上書き処理についても、Flash Poolでは自動的に判別、キャッシュされ、その後の読み込み処理を高速化できます。

次回の内容

今回(第19回)の内容では、Flash Poolの効果を最大限引き出すために、AWAを使用して最適なキャッシュ サイズを見積もる方法をご紹介しました。一方、オール フラッシュ構成は、キャッシュ ヒット / ミスからでさえ解放され、システムにおけるI/O性能の最大性能を引き出し、性能トラブルの可能性を最小化できる優位性があります。次回は、最新の市場動向から、コストの肥大化なしにオール フラッシュ構成を活用する方法をご紹介したいと思います。



Author 岩本 知博(いわもと ともひろ)
ネットアップ株式会社
ソリューション技術本部 - パートナーSE部
- システムズ エンジニア - Flashtronauts

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

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

関連情報
関連情報
【検証結果から理解するネットアップのフラッシュ技術】
第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での性能向上 ~

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