NetApp Tech OnTap NetApp Logo NetApp Logo
NetApp Tech OnTap
     
【検証結果から理解するネットアップのフラッシュ技術】
第3回
バーチャル ストレージ ティアの強み ~ Flash Cache と Flash Pool の検証結果~
シェアする NetAppオフィシャルFacebook

前回のおさらい

第2回では、「バーチャル ストレージ ティアとオール フラッシュ アレイでオーバーサイジングを解決」と題して、ストレージに求められる要件である「容量」と「性能」の観点から、バーチャル ストレージ ティアとオール フラッシュ アレイの適用領域を、実際のサイジング結果を交えながら棲み分けました。

詳しくは第2回の内容(下記URL)をご参照ください。

http://www.netapp.com/jp/communities/tech-ontap/jp-201305-flash-page.aspx

   

バーチャル ストレージ ティア

第2回でのサイジング結果(4KB のランダム読み込みで 40,000 IOPS)から、フラッシュ デバイスは「価格性能比」で HDD に勝ると分かりました。

【サイジング結果】

  • SATA で性能を満たすための本数 ⇒ 40,000 / 75 = 534本
  • SAS で性能を満たすための本数 ⇒ 40,000 / 140 = 286本
  • SSD で性能を満たすための本数 ⇒ 40,000 / 8,000 = 5本

ストレージに求められる2つの要件は、それぞれを得意とするデバイスで満たすことでコストを最適化できます。

  • 容量要件は従来通り HDD で満たす
  • 性能要件はフラッシュ デバイスで満たす

さて、いよいよバーチャル ストレージ ティア(以降、VST)について深掘りしていきましょう。下図の左のイラストはあるファイルを表しています(SAN 環境に慣れている方は LUN でご想像いただいてもかまいません)。その中で良く使われるデータだけを赤色に染めています。この赤く染めた使用頻度が高いデータだけをフラッシュデバイスに配置することができれば、ほとんどの I/O がフラッシュ デバイスで行われ、HDD への I/O を最小化することができます。

では、「使用頻度が高いデータだけをどのようにフラッシュデバイスに配置するか」。そのアプローチが各ベンダーの腕の見せ所です。

バーチャル ストレージ ティアは「リアルタイム」かつ「全自動」

フラッシュ デバイス普及の前から、各ベンダー(ストレージ ベンダーに限らず)は、情報ライフサイクル管理(ILM)の考え方のもと、よく使用するデータは SAS に、あまり使用しないデータは SATA に配置する階層化アプローチを発信してきました。とは言え、よく使用されるデータを分析するには専門スキルが必要ですし、実際にデータを分割配置、運用するのは手間がかかります。そこで、ドライブの種類にフラッシュ デバイスを加えた上で、アクセス頻度の分析とデータの配置を出来るだけ自動化させたのが、自動ILM(下図の左イラスト)のアプローチです。

プライマリのドライブはSASなので、新規データはSASに格納されます。その後、ユーザ(または製品)がポリシー設定した一定の周期で、過去のアクセス頻度に合わせてフラッシュ デバイスまたはSATAへのデータ移動が行われます。

ネットアップは自動ILMのアプローチを採用せず、更に優れた階層化アプローチに注力しています。それがネットアップのVST(上図の右イラスト)です。

元々ストレージには、HDDから読み込んだデータを自動的にコントローラのメモリにキャッシュする、性能向上のための階層化(読み込みキャッシュ)が実装されています。VSTでは、フラッシュ デバイスをメモリとHDDの間に位置付け、キャッシュとして活用します。メモリだけではキャッシュしきれないデータをフラッシュ デバイスでフォローすることで、HDDへのI/Oが最小化され、大幅な性能向上が期待できます。

データの移動を伴う自動ILMに対して、メモリからキャッシュアウトされたデータをそのままフラッシュ デバイスに配置するだけで良いので、最小限のオーバーヘッドでフラッシュ デバイスを活用した階層化を実現できます。更に、アクセス頻度が高いデータの分析およびフラッシュ デバイスへの配置は、メモリにキャッシュされる動きと同様に、ストレージOS(Data ONTAP)によって自動的に行われます。ユーザによるポリシーの検討や設定は必要ありません。

もう1点、音楽業界の例にVSTの優位点をご紹介します。本記事を執筆している6月に発売された最新の新譜データは、それぞれのアプローチ(自動ILM / VST)の場合どのドライブに配置されているでしょうか。自動ILMはデータ移動のポリシー次第ではありますが、以下の通りになると考えられます。

  • 自動 ILM:プライマリのドライブであるSASに格納されている
    • フラッシュ デバイスに配置されているのは5月以前にアクセス頻度が高かったデータ(月末にデータを移動させるポリシーの例)
  • VST:既にフラッシュ デバイスにキャッシュされている
    • 6月の新譜データをリアルタイムにフラッシュ デバイスにキャッシュ

自動 ILM のデータ移動は「スケジュール性」であり過去形です。VSTであれば、今、最もフラッシュ デバイスに配置したいデータ(今、売れている新譜)を「リアルタイム」にキャッシュするので、フラッシュ デバイスの費用対効果が最適化されます。

バーチャル ストレージ ティアを実現する3つの機能

ネットアップは、VSTを実現する機能を3つ提供しています。

  • Flash Cache
    • FAS/V シリーズのコントローラ拡張スロットに、読み込みキャッシュとして PCI-e ベースのフラッシュ デバイスを組み込む事により VST を構成
  • Flash Pool
    • SATA または SAS で構成されたアグリゲートの中に、SSD の RAID グループをキャッシュとして組み込む事により VST を構成
  • Flash Accel
    • ネットアップが無償で提供するソフトウェアで、サーバに搭載したフラッシュ デバイスをキャッシュとして動作させる事により VST を構成

各フラッシュ機能の特徴をまとめたものが下表になります。

以降では、各フラッシュ機能の特徴を、検証結果を交えながら深掘りしていきます。

Flash CacheとFlash Poolの検証結果

ここからは、Flash Cache と Flash Pool の特徴を把握するために実施した検証の結果を示します。今回の検証では、以下の3つの構成に対して同じ負荷を生成し、性能とリソース使用率の傾向を確認しました。

構成1. VST を使用せず HDD のみを使用した構成
構成2. 1. の構成に Flash Cache を使用した構成
構成3. 1. の構成に Flash Pool を使用した構成

なお、本検証では OLTP 系のワークロードを想定し、以下の2種類のトランザクションを生成しました。

  • トランザクション1(以降TX1):SELECT のみ(読み込みのみ)
  • トランザクション2(以降TX2):SELECT、UPDATE、INSERT 混合(読み込みと書き込み)

ユーザ数の増加に伴う性能とリソース使用率の傾向(キャッシュ ヒット率が約100%の場合)

本検証では、データベース システムへの同時ユーザ数を増加させていくことで、Flash Cache を使用した構成と Flash Pool を使用した構成の限界性能、およびストレージ リソース使用率の傾向を確認しました。本検証で使用した負荷の設定は以下の通りです。

  • オンライン ショッピング サイトを想定した OLTP 系のワークロード
  • ユーザ数を100ユーザ単位で1,600ユーザまで増加
  • トランザクションの比率は TX1(読み込みのみ):TX2(読み込みと書き込み)= 50:50
  • Flash Cache、Flash Pool におけるキャッシュ ヒット率は約100%
    - キャッシュ領域のウォームアップを事前に実施済み

次のグラフは、ユーザ数の増加に伴うスループットの傾向(図1)と、ストレージのHDD、SSD使用率の傾向(図2)です。

図1. ユーザ数の増加に伴うスループットの傾向
ユーザ数の増加に伴うスループットの傾向

図2. ユーザ数の増加に伴うHDD、SSD使用率の傾向
ユーザ数の増加に伴うHDD、SSD使用率の傾向

VSTを使用せずHDDのみで構成した場合、100ユーザの時点でHDDがボトルネックになりユーザ数を増加させてもスループットが向上しませんでした。これに対して、Flash CacheまたはFlash Poolを使用したVST構成はHDDのボトルネックを改善し、ユーザ数を増加させた場合のスループットが向上しました。この結果から、Flash CacheまたはFlash Poolの使用はデータベース システムにおけるI/Oボトルネックを改善し、スループットを向上する効果があることを確認できました。

次に、HDD、SSD使用率の傾向を確認します。HDDのみの構成の場合は100ユーザ、Flash Cache を使用した構成の場合は800ユーザの時点でHDD使用率が100%に達しているのに対し、Flash Poolを使用した構成ではHDD使用率が大きく減少しました。一方で SSD 使用率が増加しています。この結果から、Flash Pool により SSD が書き込みキャッシュとして活用され、書き込み処理の負荷が HDD から SSD にオフロードされたことが伺えます。

次回の内容

今回の内容から、Flash Cache と Flash Pool の特徴が分かりました。次回は、Flash Pool の特徴を活用した、データベース統合の検証結果をご紹介したいと思います。

次回の内容

岩本 知博(いわもと ともひろ)

システム技術本部 パートナーSE 部 システムズエンジニア

ネットアップ株式会社

会津大学大学院 コンピュータ理工学研究科卒、外資系データベースメーカを経て 2012 年パートナーSEとして入社。入社以来、パートナー支援とフラッシュソリューションおよびデータベース ソリューションを中心に活動。写真は「ネットアップのソリューションを世の中に発信していくぞ!」という思いを込めて、VMware on NetApp 連載でお馴染みの大西さんと。

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


第2回:バーチャル ストレージ ティアとオール
フラッシュ アレイでオーバーサイジングを解決
関連情報
 
 
Go further, faster TRUSTe
お問い合わせ   |   購入方法   |   フィードバック   |   採用情報  |   登録   |   プライバシーポリシー   |   © 2013 NetApp