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

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

前回のおさらい

前回(第12回 )のOLTP編の検証では、HDD構成の場合はアクセス範囲(図:Data Access Range)の増加に伴ってキャッシュ ヒット率が減少し、HDDのI/O性能(IOPS)がボトルネックになるため、DBシステムの性能(図:Transaction/sec)が劣化しました。一方、SSD構成であれば、キャッシュ ヒット率の減少によりストレージI/Oが頻発しても、SSDのI/O性能(IOPS)がボトルネックにならないため、DBシステムの性能(図:Transaction/sec)が劣化しませんでした。これにより、EF550の高いIOPSを活用することで、OLTPシステムの性能が向上することを確認できました。


前回のおさらい


キャッシュ ヒット率が悪い場合は、DBサーバのメモリ追加や、DBチューニングを実施することで、キャッシュ ヒット率を改善するのがセオリーですが、それに加え、EF550の高いIOPSの活用による、キャッシュ ミスが頻発しても性能が劣化しないDBシステムを構築できるようになりました。このH/Wによるチューニングは、DBサーバのメモリ スロットが不足している場合、様々な要因によりSQLの書き換えが難しい場合などに有効です。

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


EF550によるバッチ処理の高速化

前回(第12回 )のOLTP編に続き、今回(第13回)は、バッチ処理編の検証結果をご紹介します。本検証では、EF550の高いスループット値を活用したバッチ処理の高速化を実現しました。これにより、EF550はOLTP処理性能の向上に加え、バッチ処理の高速化も両立できる製品であることを実証したいと思います。

検証環境の概念図

検証環境は前回(第12回 )と同じです。

検証環境の概念図


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


前回(第12回)の内容では、「16Gbps FCのススメ」と題して、FC環境においてEF550の高いスループット値を最大限引き出すためには、16Gbps FCでSANを構成するのがオススメとご紹介しました。今回(第13回)は、ブロケード コミュニケーションズ システムズの加藤さんとの共同執筆により、本検証結果について深掘りしてご紹介します。本検証では、16Gbps対応のFCスイッチであるBrocade 6505を使用しました。


フラッシュストレージに適したI/Oインターフェイス

EF550にはI/OインターフェイスとしてFC, SAS, iSCSI, InfiniBandの4種類が用意されており、様々な接続環境に対応しています。従来のHDDで構成されたストレージの場合、HDDの応答速度が性能に大きく影響しており、I/Oインターフェイスの種類による性能差は大きな問題点になりませんでした。しかしながら、EF550の様にHDDの代わりにSSD等のフラッシュデバイスを用いたストレージでは低遅延、高IOPS、高スループットを実現しているため、I/Oインターフェイスの性能が相対的に目立つようになります。従いまして、EF550の性能を十分に引き出すためには、I/Oインターフェイスの選択も重要な要素になります。

EF550はFCoE非対応


※ EF550はFCoE非対応

【SAS】EF550を直結で使う場合は低価格で容易な接続が可能です。拡張性が無いので、ごく小規模で低価格接続用と割り切るべきでしょう。

【iSCSI】10Gbps対応のEthernetスイッチがあれば、比較的低価格に拡張性のある接続が可能です。しかしながら、TCP/IPおよびiSCSIの処理は基本的にソフトウェア処理になるため、I/O負荷はそのままサーバCPU負荷につながります。Ethernetスイッチの性能にも影響されるため、ストレージ性能を求める場合は高性能スイッチと高性能サーバを用意する必要があります。この場合、iSCSIの利点である価格メリットが無くなります。他のプロトコルよりもプロトコルオーバーヘッドが大きいため、EF550の性能を100%引き出すのは難しいでしょう。


【FCoE】LAN/SAN統合インターフェイスがメリットのプロトコルです。ストレージ性能を最重要視するならば、LANとSANは分けるべきです。ストレージ性能よりもサーバのI/O統合によるメリットを重視する環境ではお薦めのインターフェイスです。

【InfiniBand】40Gbpsの帯域を有し、EF550のI/Oインターフェイスの中では一番広帯域なプロトコルです。アダプターとスイッチは専用のハードウェアが必要ですが、FCと比べて安価に機器を用意できます。しかしながら、ストレージプロトコルとしては他のプロトコルと比べてあまり一般的ではないため、HPC環境など限定された環境で真価を発揮するプロトコルです。InfiniBandを持つストレージはきわめて少ないため、他のストレージと組み合わせて階層化やレプリケーションなどの高度なサービスを実現するのは難しいでしょう。

【FC】I/O処理はHBAによるハードウェア処理になっているため、高IOPSを実現できます。また、最新16Gbps FCでは広帯域を提供しているので高スループットを提供できます。ストレージネットワークに最適化したプロトコルのため、プロトコルオーバーヘッドが最小で拡張性・接続性が高く、EF550をEシリーズストレージと組み合わせて運用するなど、柔軟なストレージサービスを実現できます。FCスイッチ自体はEthernetやInfiniBandスイッチよりも一般的に高価と思われていますが、価格/性能比を考慮した場合一番バランスがとれたプロトコルといえるでしょう。


バッチ処理 検証内容

HDD構成 と SSD 構成に対して 、以下の通り6種類のバッチ処理を実行し、性能の傾向を確認しました。

  1. 表を全件検索(TABLE FULL SCAN)
  2. 索引を全件検索(INDEX FULL SCAN)
  3. 索引を高速全件検索(INDEX FAST FULL SCAN)
  4. 索引のメンテナンス処理(CREATE INDEX)
  5. 表と表の結合処理(HASH JOIN)
  6. 大量データのwrite処理(INSERT APPEND)

バッチ処理 検証結果

次の図は、HDD構成(図:黄色の系列)とSSD構成(図:青色の系列)における6種類のバッチ処理の実行時間(図:Elapsed Time)です。

バッチ処理 検証結果


図中の黄色の系列(HDD構成)より青色の系列(SSD構成)の棒グラフが短いことから分かる通り、全てのバッチ処理の実行時間が、EF550の適用によって高速化しました。特に、6種類のバッチ処理のうち1番、3番、4番の高速化が目立ちます。以降、その要因を深掘りしてご紹介します。


バッチ処理実行中の待機イベント内訳と高速化の要因

次の図は、各バッチ処理実行中の待機イベントの内訳です。待機イベントとは、Oracle Databaseがどのような処理待ちで、時間がかかっていたかを表しています。

バッチ処理実行中の待機イベント内訳と高速化の要因


図中の各系列の説明は以下の通りです。

  • 「I/O」(青色):Oracle DatabaseがI/O処理待ちをしていた割合
  • 「CPU」(緑色):Oracle DatabaseがCPU処理をしていた割合
  • 「OTHER」(紫色):クラスタ間の通信など、その他の割合


上の図の通り、高速化が目立った1番、3番、4番のバッチ処理は「I/O」の割合が多くを占め、HDD構成と比べてSSD構成は、「I/O」の割合が減少しました。同時に「CPU」の割合が増加しました。これにより、EF550の適用によってバッチ処理実行中のI/Oボトルネックを改善し、CPUを活用したバッチ処理の高速化を実現できることを確認できました。


I/Oワークロードの種類とEF550の有効性

次の図に、各バッチ処理における「I/O」が、どのI/Oワークロードに分類されるかを示します。

I/Oワークロードの種類とEF550の有効性


高速化が目立った1番、3番、4番のバッチ処理のI/Oワークロードは「sequential read」でした。仮にI/Oワークロードが「random read」だった場合、高い「IOPS」を誇るフラッシュ製品を適用すれば大きな効果が期待できますが、「sequential read」の性能は「スループット」に大きく依存します。

  • random I/O:「IOPS」が重要
  • sequential I/O:「スループット」が重要

そのため、本検証におけるバッチ処理の高速化は、「IOPS」だけではなく、同時に高い「スループット」を誇るEF550だからこそ実現できた高速化と言えます。EF550の高い「スループット」の理由は、第10回 の内容をご参照ください。


考察 ~ バッチ処理 編 ~

EF550導入によるバッチ処理高速化のカギは、処理実行中の「I/O」の割合です。I/Oの割合が多く、I/OボトルネックになっているDBシステムにおいて、大きな効果が期待できます。DBシステムのバッチ処理における性能問題の要因は様々であり一概には言えませんが、一般的にI/Oがボトルネックになりがちです。I/Oワークロードの種類が「random」であっても「sequential」であっても、「IOPS」と「スループット」を両立するEF550であれば、大きな効果が期待できます。


Mr. Kato 加藤 春雄(かとう はるお)
ブロケード コミュニケーションズ システムズ株式会社
システムエンジニアリング本部 OEM SE部
シニア システムズエンジニア

工学院大学 工学部 電気工学科卒、日系システムインテグレーターを経て2006年に入社。以来 SAN製品の技術支援を中心に活動中。

Mr. Iwamoto 岩本 知博(いわもと ともひろ)
ネットアップ株式会社
ソリューション技術本部 パートナー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構成でドライブ障害時の性能維持とリビルド処理の高速化を実現 ~

第12回:Oracle Database環境でのEF550
の有効性
~ OLTP処理性能の向上と、バッチ処理の高速化を両立するEF550(OLTP編) ~
関連情報
 
 
Go further, faster TRUSTe
お問い合わせ   |   購入方法   |   フィードバック   |   採用情報  |   登録   |   プライバシーポリシー   |   © 2014 NetApp