NetApp Tech OnTap NetApp Logo NetApp Logo
NetApp Tech OnTap
     
【検証結果から理解するネットアップのフラッシュ技術】
第6回
NetApp Flash PoolとOracle Database Smart Flash Cacheの検証結果から理解するサーバ側キャッシングソリューションの特徴
シェアする NetAppオフィシャルFacebook

前回のおさらい

第5回「Flash Poolの特徴(応用編)~マルチ ワークロード対応の最強のディスク プールを構成する~」の検証では、Flash Poolの使用によりストレージ リソースの使用率が最適化され、OLTP系のデータベースに加えてDWH / BI系のデータベースを、同じアグリゲート上に統合可能となることが確認できました。

検証環境の概念図

Flash Poolを利用することで、コストの大幅な増大やストレージ構成の複雑性を伴わずに、多様なワークロードのデータベース統合を実現することができます。

詳しくは第5回の内容をご参照ください。

はじめに

今回までの「検証結果から理解するネットアップのフラッシュ技術」連載では、ネットアップのVSTの中でもFlash CacheとFlash Poolの検証結果といった、ストレージ側のキャッシングソリューションを中心にご紹介してきました。今回(第6回)からは、サーバ側のキャッシングソリューションも含めてその特徴を確認し、活用方法をご紹介していきたいと思います。

本検証で使用したサーバ側のキャッシングソリューション

本検証では、サーバ側のキャッシングソリューションとしてDatabase Smart Flash Cacheを使用しました。現時点(2013年9月)において、ネットアップVSTのサーバ側キャッシングソリューションであるFlash Accelは、仮想化環境用途のソリューションであるため、本検証ではFlash Accelを使用していません。

Database Smart Flash Cache

Database Smart Flash CacheはOracle Database 11g Release 2 Enterprise Editionで実装された、フラッシュ デバイスをバッファ キャッシュの拡張領域として使用する機能 (使用可能なOSはOracle LinuxとSolaris)です。本機能を使用すると、バッファ キャッシュをレベル1のキャッシュとした場合、フラッシュ デバイスはレベル2のキャッシュとして位置付けられ、Oracleのキャッシュ領域が拡張されます。バッファ キャッシュからキャッシュ アウトされたデータ ブロックは自動的にDatabase Smart Flash Cacheの領域に配置されます(図5)。これにより、従来ではバッファ キャッシュのサイズ不足が原因でHDDから読み込んでいたデータ ブロックを、フラッシュ デバイスから高速に読み込むことが可能になります。

Database Smart Flash Cache

図1. Database Smart Flash Cache

バッファ キャッシュのサイズ不足に対しては、一般的にメモリを追加するアプローチが有効です。しかしながら、昨今、同時ユーザ数やデータ量の肥大化が原因となり、全てのデータをメモリ上で処理することが高コストかつ困難になってきました。フラッシュ デバイスであれば、メモリだけでは達成できない大規模なキャッシュ領域を比較的安価に確保することができます。

注意点として、Database Smart Flash Cacheでは、その領域にキャッシュしたブロックへのポインタとなるメタデータをバッファ キャッシュ上に確保します。そのため、データベース インスタンスの再起動によってバッファ キャッシュ上のメタ データがクリアされた場合、Database Smart Flash Cache上にキャッシュされたデータも無効化されてしまいます。

Database Smart Flash Cacheの検証結果

本検証では、Database Smart Flash Cacheの特徴を把握するために、以下の2つの構成に対して同じ負荷を生成し、性能とリソース使用率の傾向を確認しました。

1. Flash Poolを使用した構成
2. 1の構成にDatabase Smart Flash Cacheを併せて使用した構成

Flash Poolと比較したDatabase Smart Flash Cacheの傾向

サーバ側のキャッシング ソリューションであるDatabase Smart Flash Cacheの特徴を把握するために、機能の有無によるスループットへの影響と、サーバ / ストレージのリソース使用率の変化を確認しました。使用した負荷の設定は以下の通りです。

  • オンライン ショッピング サイトを想定したOLTP系のワークロード
  • ユーザ数を40ユーザ単位で400ユーザまで増加
  • トランザクションの比率は以下の2種類
    • TX1(読み込みのみ):TX2(読み込みと書き込み)= 100:0
    • TX1(読み込みのみ):TX2(読み込みと書き込み)= 0:100
  • Flash Pool、Database Smart Flash Cacheにおけるキャッシュ ヒット率は約100%

次のグラフは、ユーザ数の増加に伴うスループットとデータベース サーバのCPU使用率の推移(図2、図4)、ストレージ リソース使用率の推移(図3、図5)です。

ユーザ数の増加に伴うスループットとDBサーバのCPU使用率の推移(TX1:TX2=100:0)

図2. ユーザ数の増加に伴うスループットとDBサーバのCPU使用率の推移(TX1:TX2=100:0)

ユーザ数の増加に伴うストレージ リソース使用率の推移(TX1:TX2=100:0)

図3. ユーザ数の増加に伴うストレージ リソース使用率の推移(TX1:TX2=100:0)

ユーザ数の増加に伴うスループットとDBサーバのCPU使用率の推移(TX1:TX2=0:100)

図4. ユーザ数の増加に伴うスループットとDBサーバのCPU使用率の推移(TX1:TX2=0:100)

ユーザ数の増加に伴うストレージ リソース使用率の推移(TX1:TX2=0:100)

図5. ユーザ数の増加に伴うストレージ リソース使用率の推移(TX1:TX2=0:100)

図2と図4のグラフから、データベース サーバのCPU使用率に空きがある場合、Flash Poolを使用した構成よりDatabase Smart Flash Cacheを使用した構成のスループットが高いことを確認できましたが、その差はごく僅かと言えます。これに対してCPU使用率が最大値に到達している場合は、その差が逆転しました。これはDatabase Smart Flash Cacheを使用した構成のCPU使用率のほうが高い値を推移していることから分かるとおり、より少ないユーザ数の時点でCPUがボトルネックになったためです。

次に、図3と図5のグラフから、Flash Poolを使用した構成に対してDatabase Smart Flash Cacheを使用した構成のストレージ リソース使用率が大きく減少することが確認できました。この結果から、 Database Smart Flash Cacheはデータベース サーバ側のリソースを使用することが分かります。また、書き込み処理を含む場合(図5)、 Database Smart Flash Cacheによりストレージ リソース使用率が大きく減少しましたが、最小化はされませんでした。この結果から、 Database Smart Flash Cacheは読み込みキャッシュの用途であるため、書き込み処理はストレージまで到達することが分かります。

本項の検証結果から、 Database Smart Flash Cacheにより読み込み処理をストレージ側からデータベース サーバ側にオフロード可能であることが確認できました。

Database Smart Flash Cacheを使用する上での注意点

前章の検証結果では、Database Smart Flash Cacheを使用した構成はFlash Poolを使用した構成と比較して、限界性能で劣る結果になりました。理由としては、使用したデータベース サーバのCPUスペックがストレージと比較して相対的に低く、データベース サーバのCPUがボトルネックになったためでした(図2、図4)。また、Database Smart Flash Cache使用時はデータベース サーバのCPU使用率は、非使用時と比較して高い値を推移しました。そのため、より低いユーザ数の時点でデータベース サーバのCPUがボトルネックになり、性能が頭打ちになりました。この結果から、ストレージと比較して、より高いスペックのデータベース サーバであれば、性能差は逆転し、より高いスループットが期待できたと考えられます。

Database Smart Flash Cacheを使用することで、ストレージ性能に依存することなくより高い性能を期待することが可能になりますが、どこまでの性能向上を実現できるかはフラッシュ デバイスを搭載したサーバのスペック次第であるため、 Database Smart Flash Cacheの性能を最大限引き出すためには、高性能なサーバが必要と言えます。

次に、前章の検証結果(図5)のとおり、Database Smart Flash Cacheは読み込みキャッシュの用途であるため、書き込み処理はストレージまで到達します。そのため、Database Smart Flash Cacheを使用する場合でも、書き込み処理によって求められる性能要件をストレージ側で満たす必要があると言えます。

また、Database Smart Flash Cacheの領域上のデータは非永続であるため、計画停止 / 障害に起因したデータベース インスタンスの再起動が発生すると、キャッシュされたデータが無効化され、データベース システムの性能は大幅に劣化します。このとき、Flash Poolも合わせて使用していれば、高速なFlash Poolから読み込むことが可能であるため、性能劣化を防ぐことが可能です。更に、短い時間でDatabase Smart Flash Cache領域のウォームアップを完了させることが可能になります。

次回の内容

次回は、Database Smart Flashとストレージ側のキャッシングソリューション(Flash Pool / Flash Cache)を組み合わせることで、従来は統合できなかった極めてI/O負荷が高いデータベース統合が可能になることを、検証結果を交えながらご紹介したいと思います。

jp-201308-flash-page

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




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

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


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

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

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

第5回: Flash Poolの特徴(応用編)
~マルチ ワークロード対応の最強の
ディスク プールを構成する~
関連情報
 
 
Go further, faster TRUSTe
お問い合わせ   |   購入方法   |   フィードバック   |   採用情報  |   登録   |   プライバシーポリシー   |   © 2013 NetApp