【検証結果から理解するネットアップのフラッシュ技術】 第12回 Oracle Database環境でのEF550の有効性 ~ OLTP処理性能の向上と、バッチ処理の高速化を両立するEF550(OLTP編)~
NetApp Tech OnTap
NetApp Tech OnTap
   
【検証結果から理解するネットアップのフラッシュ技術】
第12回
Oracle Database環境でのEF550の有効性 ~ OLTP処理性能の向上と、バッチ処理の高速化を両立するEF550(OLTP編)~

シェアする NetAppオフィシャルFacebook

はじめに

今回の内容から、Oracle Database環境でのEF550検証結果についてご紹介したいと思います。「OLTP処理性能の向上編」と「バッチ処理の高速化編」の2回に分けて、今回(第12回)はOLTP編をご紹介します。


検証環境の概念図

次の図は本検証環境の概念図です。

検証環境の概念図


  • DBクライアント:4台のサーバをDBクライアントとしました。
  • DBサーバ:3台のDBサーバにOracle Database 12cをインストールし、3ノードのクラスタ(Oracle RAC)を構成しました。また、各サーバには16Gbps FCのHBAを搭載しました。
  • サーバ~ストレージ間の接続:16Gbps FCによるSANを構築しました。3ノードからなるDBサーバのHBA(16Gbps FC)とEF550コントローラのHIC(16Gbps FC)間は、16Gbps FCスイッチのBrocade 6505で接続しました。

16Gbps FCのススメ

第10回 の内容では、EF550は450,000 IOPSという「IOPS」に加え、12GB/secという高い「スループット」値を両立した製品であることをお伝えしました。

FC環境において高いスループット値が求められる場合、16Gbps FCでSANを構成するのがオススメです。EF550は8つのFCポートを搭載しています。例えば8Gbps FCの場合、8つのFCポートをGB/secに換算すると、1GB/sec x 8ポートで最大でも8GB/secのFC帯域であるため、最大12GB/secというEF550の高いスループットを最大限引き出すことができません(※実際には8GB/secより低いFC帯域となるでしょう)。16Gbps FCであれば、最大でその倍となる16GB/secのFC帯域を確保できるので、EF550のスループットを12GB/secまで引き出せると考えられます。


EF550ストレージ構成

EF550のストレージ構成は以下の通りです。

  • 12ドライブで構成されたRAIDグループ2つを作成
  • それぞれのRAIDグループからLUNを1つ作成し、Oracle ASMで束ねる
  • LUNのオーナーシップは両コントローラに分散

EF550ストレージ構成


EFシリーズでは、コントローラはLUNに対してオーナーシップを持ち、そのLUNに対するI/O処理を担当します(コントローラ障害時には、もう一方のコントローラがLUNのオーナーシップを引き継ぎます)。偶数個のLUNを作成し、両コントローラにオーナーシップを均等に分散させることで、両コントローラがactive / activeになり、EF550の高い性能(IOPS / スループット)を最大限引き出せます。


OLTP 検証内容 

SSD構成 と HDD 構成に対して Web ショッピング サイトを想定したワークロードを生成し、DBシステム性能の傾向を確認しました。本検証で使用した負荷の設定は以下の通りです。

  • トランザクションの定義
    • トランザクション 1(TX1):read のみ(SELECT のみ)
    • トランザクション 2(TX2):read と write(SELECT, UPDATE, INSERT 混合)
  • ワークロードの設定
    • トランザクション比率は TX1:TX2 = 50:50
    • アクセスするデータ量を 10, 20, …, 100GB まで増加

OLTP 検証結果

次の図は、アクセスするデータ量(図:Data Access Range)の増加に伴う性能(図:Transaction/sec)の傾向と、DBサーバのCPU使用率の傾向(図:DB Server CPU Utilization)です。

OLTP検証結果



OLTP検証結果

  • 黄色の系列(HDD構成):棒グラフがHDD構成の性能(系列:TPS)、折れ線グラフがHDD構成のDBサーバCPU使用率(系列:CPU)を示します。
  • 青色の系列(SSD構成):棒グラフがSSD構成の性能(系列:TPS)、折れ線グラフがSSD構成のDBサーバCPU使用率(系列:CPU)を示します。

Data Access Range(以降、アクセス範囲)= 1GBの場合、DBサーバの物理メモリ(Oracle Databaseのバッファ キャッシュ)キャッシュ ヒット率がほぼ100%であり、ストレージI/Oが発生していない理想のOLTPシステムと言えます。アクセス範囲の増加に伴い、キャッシュ ヒット率が減少し、ストレージI/Oが頻発します。HDD構成の場合、HDDのI/O性能(IOPS)がボトルネックになり、DBシステムの性能(TPS)が劣化しました。一方、SSD構成であれば、キャッシュ ヒット率の減少によりストレージI/Oが頻発しても、SSDのI/O性能(IOPS)がボトルネックにならないため、DBシステムの性能が劣化しませんでした。これにより、EF550の高いIOPSを活用することで、OLTPシステムの性能が向上することを確認できました。


考察 ~ OLTP編 ~

EF550導入によるOLTPシステム性能向上のカギはDBサーバにおける「キャッシュ ヒット率」です。キャッシュ ヒット率が悪くI/O性能がボトルネックになっているDBシステムにおいて、大きな効果が期待できます。キャッシュ ヒット率が悪い場合は、DBサーバのメモリ追加や、DBチューニングを実施することで、キャッシュ ヒット率を改善するのがセオリーですが、それに加え、EF550の高いIOPSの活用による、キャッシュ ミスが頻発しても性能が劣化しないDBシステムを構築できるようになりました。このH/Wによるチューニングは、DBサーバのメモリ スロットが不足している場合、様々な要因によりSQLの書き換えが難しい場合などに有効です。


次回の内容

次回は、EF550の高いスループット値を活用したバッチ処理の高速化についての検証結果をご紹介したいと思います。


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

会津大学大学院 コンピュータ理工学研究科卒、外資系データベース メーカを経て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構成でドライブ障害時の性能維持とリビルド処理の高速化を実現 ~
関連情報
 
 
Go further, faster TRUSTe
お問い合わせ   |   購入方法   |   フィードバック   |   採用情報  |   登録   |   プライバシーポリシー   |   © 2014 NetApp