【検証結果から理解するネットアップのフラッシュ技術】
第3回 バーチャル ストレージ ティアの強み ～ Flash Cache と Flash Pool の検証結果～
前回のおさらい 第2回では、「バーチャル ストレージ ティアとオール フラッシュ アレイでオーバーサイジングを解決」と題して、ストレージに求められる要件である「容量」と「性能」の観点から、バーチャル ストレージ ティアとオール フラッシュ アレイの適用領域を、実際のサイジング結果を交えながら棲み分けました。 詳しくは第2回の内容（下記URL）をご参照ください。
バーチャル ストレージ ティア 第2回でのサイジング結果（4KB のランダム読み込みで 40,000 IOPS）から、フラッシュ デバイスは「価格性能比」で HDD に勝ると分かりました。 【サイジング結果】
ストレージに求められる2つの要件は、それぞれを得意とするデバイスで満たすことでコストを最適化できます。
さて、いよいよバーチャル ストレージ ティア（以降、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 のデータ移動は「スケジュール性」であり過去形です。VSTであれば、今、最もフラッシュ デバイスに配置したいデータ（今、売れている新譜）を「リアルタイム」にキャッシュするので、フラッシュ デバイスの費用対効果が最適化されます。 バーチャル ストレージ ティアを実現する3つの機能 ネットアップは、VSTを実現する機能を3つ提供しています。
各フラッシュ機能の特徴をまとめたものが下表になります。
以降では、各フラッシュ機能の特徴を、検証結果を交えながら深掘りしていきます。 Flash CacheとFlash Poolの検証結果 ここからは、Flash Cache と Flash Pool の特徴を把握するために実施した検証の結果を示します。今回の検証では、以下の3つの構成に対して同じ負荷を生成し、性能とリソース使用率の傾向を確認しました。
構成1. VST を使用せず HDD のみを使用した構成 なお、本検証では OLTP 系のワークロードを想定し、以下の2種類のトランザクションを生成しました。
ユーザ数の増加に伴う性能とリソース使用率の傾向（キャッシュ ヒット率が約100%の場合） 本検証では、データベース システムへの同時ユーザ数を増加させていくことで、Flash Cache を使用した構成と Flash Pool を使用した構成の限界性能、およびストレージ リソース使用率の傾向を確認しました。本検証で使用した負荷の設定は以下の通りです。
次のグラフは、ユーザ数の増加に伴うスループットの傾向（図1）と、ストレージのHDD、SSD使用率の傾向（図2）です。 図1. ユーザ数の増加に伴うスループットの傾向 図2. ユーザ数の増加に伴う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回：バーチャル ストレージ ティアとオール フラッシュ アレイでオーバーサイジングを解決  | ||||
 |
 |
| お問い合わせ | 購入方法 | フィードバック | 採用情報 | 登録 | プライバシーポリシー | © 2013 NetApp |
