[C13] フラッシュドライブで挑むOracle超高速化と信頼性の両立 by Masashi Fukui

© Hitachi, Ltd. 2013. All rights reserved.

株式会社日立製作所ＩＴプラットフォーム事業本部

2013/11/13

フラッシュドライブで挑むＯｒａｃｌｅ超高速化と信頼性の両立

db tech showcase 東京 2013


１. 従来のシステムの問題点

２. フラッシュを使った高速化

３. フラッシュのシステムの信頼性

Contents

４. フラッシュドライブの活用

５. ＳＳＤとＯｒａｃｌｅの相性

６. ＲＡＣｏｎＳＳＤ分析系ＳＱＬでの検証

７. 信頼性に関する検証


データの増加に伴い、処理時間が増加。これに伴い、

処理時間の短縮＝ＤＢ高速化が重要になりつつある。

ＤＢ担当者

担当者のＤＢ高速化の悩みは尽きない

朝までかかる夜間バッチは、ハードを

リプレースするだけで、速くなるだろうか。

既存アプリは、今更手を入れるなんて

できないからＤＢ自体を速くしないと

ＤＷＨで抽出してるデータが少な過ぎると

言われているが、増やせば時間がかかる

０-１. ＤＢ高速化需要の高まり


１．従来のシステムの問題点


1

10

20

相対性能

2005 2006 2007 2008 2009 2010 2011

5

15

2012

25

10倍

HDD回転数 1倍

ＣＰＵ性能はコア数の増加と共に劇的に向上している。

ＣＰＵ性能の伸びに比べ、ＨＤＤ回転数やＦＣ帯域は伸びていない

システム構成は今でも２００５年と同じ作りだが、それで良いのか

※CPU性能はSAP SDベンチマークをベースにした値

4倍 4core

6core

2core

24倍 8core

２００５年を１とした時の性能推移

１-１. Ｈ／Ｗの性能進化の不均衡

5


100

90

80

70

60

50

40

30

20

10

0

(%)

ＣＰＵ，ＦＣ帯域，ＨＤＤの使用率の状況は

ＨＤＤは常に稼働し続けており、ほぼ１００％張りつきの状態。

ＣＰＵはあまり稼働率が上がらず、底辺を這っている様な状態。

ＦＣの帯域はまだまだ余裕があるが、ＣＰＵよりは使われている状態。

ＨＤＤの高速化を行えば、ＣＰＵをもっと有効に使えるようになる

ＨＤＤの使用率はＯＳの性能モニタでは

直接表示されない

ＨＤＤの使用率がボトルネックなのが実は分かりにくい！

パーツ使用率のイメージ

１-２. ２００５年と同じ構成のシステムでは


ストレージ

キャッシュ

円盤に書かれたデータが来るまで待つ

データ

要求

日付都市時間気温

7/8 東京 12:00 28°

7/8 大阪 14:00 32°

7/8 名古屋 14:00 35°

7/9 甲府 13:00 37°

7/9 京都 14:00 36°

ＨＤＤは円盤にデータが記録されている。

円盤は１分間に15,000回転している。

目的のデータがヘッドまで来ると読み出せる。

例えば、 7/9の京都の最高気温が知りたい

ヘッドの移動(データのあるトラックまで移動)

回転待ち(最大1回転：1/15,000分＝1/250秒)

アプリケーションサーバ

データベースサーバ

要求

データ

要求要求

データデータ

つまりＨＤＤは１秒間に最悪250件しか読めないから遅い。

１-３. ＨＤＤのデータリード処理の問題点


１-４. ＨＤＤＩ/Ｏ性能基本データ

ＨＤＤはランダムアクセスが苦手

SAS 15,000回転/s, RAID5:4D+1P

ブロックサイズ：512KB, 多重度：8

1 7.8

リード帯域性能

シーケンシャル

ランダム

1 19

ライト帯域性能

シーケンシャル

ランダム


昼(オンライン) 夜夜(バッチ処理)

業務処理の１日のアクセス状況

ＨＤＤで構成している限り、目に見える性能改善は難しい！

業務処理では、昼間はＩＯＰＳが必要で夜間は帯域が必要となる。

ＩＯＰＳはまさにＨＤＤの回転数に依存するので、ＨＤＤの本数が少ないと厳しい。

ＨＤＤはランダムアクセスの帯域が出ない為、バッチがランダムなら性能が出ない。

※グラフはストレージアクセスイメージです。

ＩＯＰＳ必要

１-５. ストレージのアクセス種別について


２．フラッシュを使った高速化


容量

年代

これからはFlashメモリー

① 半導体なのでリード/ライトが速い

磁気記憶では無く、メモリーチップを使用している為、ＨＤＤより桁違いにリード/ライトが速い。

Ｆｌａｓｈの特徴として、ライトは上書きでは無く、別の場所に書き、元の場所を無効化する。ブロック内に無効領域が増えたらガーベッジコレクションしてから消去する。

② 容量がＨＤＤ並みとなってきた

ＨＤＤ互換のＳＳＤでは数１００ＧＢ～１ＴＢ超のデバイスが製品化されてきており、価格はＨＤＤより割高だが性能が必要な状況で採用される様になってきた。

書込み済

空き領域

１ブロック

(消去単位)

SDカード

USBメモリー

コンパクトフラッシュ

CompactFlash

２-１. ストレージＩ／Ｏの高速化には


SLC

0

ＳＬＣとＭＬＣ

FlashにはSLCとMLCがあり、MLCの方がビッ

ト単価が安く大容量化に向いているが、短寿命等の弱点もある。しかし技術進歩でMLCでも信頼性が上がってきている。

データ保持時間

Flashは不揮発性ではあるが、電源が無い状態

で長期放置を行うと、微量ながらも電荷が減っていく為、データが失われることがある。MLCの場合は、3ヵ月以内には通電することを推奨。

ＳＳＤとは

HDD互換インターフェース(SATA/SAS)を装備したFlashメモリー。パソコン用から始まり、今では信頼性の高いエンタープライズ用もある。

1

MLC

11 (3)

01

10 (2)

00

電荷

２-２. ＳＳＤの特性


1

※性能・時間は構成/使用条件により異なる場合があります。

ランダムWRITE (7D+1P, 8KB)のＩＯＰＳ相対比較

１５

ランダムREAD (7D+1P, 8KB)のＩＯＰＳ相対比較

６１

２-３. ＳＳＤのパフォーマンス

ＨＤＤよりもかなり高速

1

SSD

SAS HDD

SSD

SAS HDD


ストレージ

サーバ

P

P

今までのシステム構成は

サーバからＦＣケーブルが２本ストレージに接続されている。

ＨＤＤはＲＡＩＤ構成で組まれている。

サーバ１台(またはActive-Standby)の構成

★単純にＨＤＤをＳＳＤに置き換えただけだと...

コントローラコントローラ

P P P P P P P P

RAID構成

ストレージの内部バス帯域限界を超える。

コントローラーの処理性能が不足する

ＦＣポートの帯域限界を超える

Ｉ/Ｏ待ちが無くなりＣＰＵが忙しくなる

せっかくのＳＳＤの高速性が、今までの構成では引き出せない！

２-４. ＳＳＤに変えるとどうなるか


ボトルネックを極力排除する

ストレージ

サーバ

サーバ

10G NIC

10G LANSW

10G LANSW

10G NIC

10G NIC

10G NIC

Bonding Bonding

RAC Interconnect

Ctrl0 Ctrl1 Ctrl2 Ctrl3

8Gbps x 16

FC

FC

FC

FC

FC

FC

FC

FC

FC

FC

FC

FC

FC

FC

FC

FC

P P P P P P P P P P P P P P P P

1G NIC

1G NIC

Bonding

1G NIC

1G NIC

Bonding

Public LAN

サーバは２台以上でＯｒａｃｌｅＲＡＣ構成に可用性と性能を両立

処理性能ネックを回避する為にＳＳＤ数に

応じたコントローラ数を

処理能力が上がるため、ＲＡＣインターコネクトは、１０Ｇの冗長構成が必要

内部バスがボトルネックにならない様なＳＳＤの

スロット配置を行う

ＦＣはＳＳＤの数に応じ帯域を確保できる本数並列性と可用性に効果

これが理想のＳＳＤシステム

２-５. 高速化を実現するハードウェア構成


ストレージ使い過ぎ

少な過ぎ

ＦＣ利用率

100%

0%

各ＬＵにアクセスするＦＣポートを固定化しＯＳとＦＣのキューを一致させオーバーヘッドを削減。

しかしＬＵが複数になると、どのデータをどのＬＵに割り当てるか検討が必要になる。

検討不十分だとＬＵのデータ占有量が不揃いになったり、アクセス頻度が偏る。

最悪本番稼働後に配置の見直しや、テーブル分割などを実施しなければならなくなる。

高速化構成の副作用

ＬＵ

サーバ

ＨＢＡ (FCカード)

TableC TableA TableD TableB

２-６. 複数ＬＵへのＤＢ配置


ＬＵ

Oracle ASM

最高のパフォーマンス

複数ＬＵをうまく使うには、ＯｒａｃｌｅＡＳＭを使用することで対応が可能。

複数ＬＵがストライピングされ、全てのＬＵを均等に利用可能。

ＦＣ帯域も均等に利用でき、パフォーマンスも向上。

遅いＬＵが混在していると性能が引きずられ、ＤＢ全体が遅くなることがある。

理想構成では全てＳＳＤで統一しており、最高のパフォーマンスを発揮可能。

ＦＣ利用率

100%

0%

ＨＢＡ (FCカード)

複数ＬＵをまとめて管理

TableA TableB TableC TableD

２-７. サイズやアクセス頻度の偏りの無いＡＳＭ


高信頼の日立ハイエンドブレードサーバ１０Ｇイーサネットファブリックスイッチ搭載可能ＡＰサーバ、バックアップサーバ等も混載可能

サーバ当たり８本のＰＣＩ-Ｅスロットを追加独立した管理プロセッサが状態を監視Ｉ/Ｏケーブル断でもサーバが落ちない可用性

ＳＳＤ搭載前提の高性能コントローラ搭載帯域ネックになりにくい高速バックエンドパスＳｈａｄｏｗＩｍａｇｅやＴｒｕｅＣｏｐｙバックアップ機能 (筺体内ボリュームコピー) (筺体間コピー)

データリードで１１ＧＢ/ｓの

Ｉ/Ｏ処理を確認。

8Gb/s×16

ＢｌａｄｅＳｙｍｐｈｏｎｙＢＳ２０００

Ｉ/Ｏスロット拡張装置(ＩＯドロワ)

200/400/800GB SSD

・・・

ＨｉｔａｃｈｉＵｎｉｆｉｅｄＳｔｏｒａｇｅ１００

２-８. そのシステムを実現したのがこの構成！


３．フラッシュのシステムの信頼性


ＳＳＤの書き込み限界

SSDではRAIDの場合、構成本数と書込み量で寿命が決まる

全容量1.6TBを1日10回全て書き替えても、5年間使えます。

※寿命まで絶対故障しないということではありません

上限値通知や対応も

SSDの書き込み容量が寿命の90%(＆95,96,97,98%)に達すると通知を出します。更に99%になるとスペアへデータをコピーし、書き込みを継続するように備えます。保守契約されていれば、万一期間内に寿命となったＳＳＤは、無償交換します。

ＳＳＤの寿命とは

SSDはデータ書き込み時に電子が移動することで半導体が劣化し、書き込み回数上限を決めている。200GBのSSDの場合3.6PBの書き込みが上限である。

※3.6PBは日立採用のSSDの場合

値備考

SSD 1本の書き込み上限 3,600TB/5年 5年でこの値に達すると仮定

(2D+1P)*4組での合計書込み上限 28,800TB/5年 200GB×8本分＝1.6TB

1日で書き込める容量 15,781GB/日約16TB/日

1秒で書き込める容量 182MB/s

３-１. ＳＳＤの寿命について


３-２. ネットワークの可用性

忘れがちなネットワークも重要

ＳＳＤのシステムでは１Ｇｂｐｓでは不足。１０Ｇが必要ＲＡＣのインターコネクトは１Ｇでは不足。１：１通信の場合Ｂｏｎｄｉｎｇでは帯域を増やせない。直結は禁止なので２台のスイッチ(冗長)で接続

10G LAN

Ｐｏｒｔ数は最低４ｐｏｒｔ。もっと欲しいＲＡＣのインターコネクトとＰｕｂｌｉｃで４ｐｏｒｔ。ＡｃｔｉｖｅＤａｔａＧｕａｒｄ専用Ｐｏｒｔも性能に有効管理ネットワークも別セグメントで欲しいいくつ？

ＰｕｂｌｉｃＬＡＮの可用性はスパニングツリーで構成するのが良いのか。リンクアグリゲーション(LA)なら相性問題はまずない。複数スイッチでのＬＡ機能(vPC, vLAG, MLAG)が旬。

仮想LA

LA(bond)

グループ


メーカーはどこでも一緒。では無い

障害発生頻度を減らすには

壊れやすい部品を使わない ⇒ 壊れ易いかどうか判別するプロセスが必要。部品の個体差による不具合品を排除する ⇒ 部品受け入れ時と完成後にも検査する。

万一の障害時の対応は

故障に対しては自動通報で迅速に対応。サービス拠点も日立なら全国至る所にある。難しい問題切り分けや解析は、国内に技術者がいれば短期間で判明するもの。

３-３. サーバの信頼性


温度・電圧の組合せによる過酷な環境による試験。

■複合マージン試験

■外観検査通電検査だけでは判らない異常を検出。

半田飛散

開発検査量産検査

X線透視観察装置

元々メインフレームでやっていた処理なんだけど...

３-４. 障害発生頻度を極力減らすには


遠隔保守有

～ユーザーエリア～

IP-VPN

サポートセンタ

監視通報装置

遠隔保守無

自動通報復旧

復旧

業務のダウン時間を短縮

ログ解析保守作業駆けつけ

部品手配

電話受付&問診ログ採取/解析保守作業部品手配駆けつけ障害切分

障害発生

ユーザの負担作業

障害連絡

３-５. 万一の障害発生時に迅速な対応をするには

ファイアウォール

VPN ルータ

遠隔保守支援システムが自動通報を


４．フラッシュドライブの活用


ＰＣＩフラッシュフラッシュアレイ装置

ＰＣＩフラッシュの次に高速。従来型ストレージと使い勝手同じ。フラッシュデバイスのみで構成。ＦＣやＩｎｆｉｎｉＢａｎｄインターフェース共有ディスクとしても使用可能

フラッシュストレージの中では最も高速。 RAID構成はソフトウェアで実施。共有ディスクとして使用できない。稼働中のドライブ交換ができない。

ＤＢにはどのフラッシュが向いているのか

従来型ＳＡＮストレージ装置

ＳＳＤを搭載することで高速化。ＤＲＡＭキャッシュによるリード/ライトの高速化。ストレージ内の各種オプション機能が豊富。ＨＤＤとのハイブリッド構成による大容量化が可能。

４-１. エンタープライズ向けフラッシュストレージ

少～中容量のシングルＤＢに

最適

中容量のＤＷＨに

最適

中～大容量のＯＬＴＰ/ＤＷＨ

に最適


ＤＢサーバ

正VOL

ＳＳＤでもボリュームコピーは必要ストレージ間でのＤＲ機能

バックアップサーバ

ストレージ機能による遠隔データコピーによりＤＲサイト構築が容易。

フルバックアップならボリュームコピーは必須。回復時間を重要視するならこれが最適。

副VOL

バックアップ／ＤＲとコストパフォーマンス

ハイブリッド・ドライブ対応

大容量かつコストパフォーマンスを追求するには、ＨＤＤ混載が解決策。

ボリュームコピーの副ボリュームにはＨＤＤが最適。

ニアラインドライブを使用すれば、二次バックアップやアーカイブ用途も。

４-２. ＳＡＮストレージの利点


４-３. フラッシュの価格は今後どうなるのか

ビットコストの動向デバイス技術動向調査結果（日立調べ）各デバイスのビットコスト推移予想

ビッ

トコ

スト(＄

/Ｇ

Ｂ) ＭＬＣＳＳＤと

ＳＡＳＨＤＤが逆転する

数年後のリプレースにはＳＡＳＨＤＤは時代遅れとなる。

いつＳＳＤを導入するか？今でしょ！


仮想ボリューム

サーバから見せるＬＵ。

容量は将来を見据えた大きさに設定可能。

実データはプールの領域が割り当てられる。

ＨＤＤとのハイブリッドでも高速アクセス Hitachi Dynamic Tiering

Tier1 Tier2

プール

ＨＤＤやＳＳＤからなる物理ボリューム。

優先順位設定可能。

この例ではＳＳＤを高い優先順位に設定。

４-４日立ストレージのボリューム自動階層制御


高性能

SSD(Solid State Drive)<他社OEM品>

SATA/ NL-SAS HDD

SAS HDD

キャッシュメモリレスポンス性能重視

ビットコスト重視

フラッシュドライブ適用拡大

HAF(Hitachi Accelerated Flash)<日立製>

大容量/スケーラビリティ

コストパフォーマンス

高信頼高機能高性能

HAF(Hitachi Accelerated Flash) ＳＡＮストレージに最適なフラッシュ

日立はストレージシステムとフラッシュドライブの両方を自製

４-５. 日立自製フラッシュドライブ

大容量・超高速アクセス

１.６ＴＢの大容量、高信頼、高性能フラッシュメモリドライブ


HAF

SSD

SAS HDD 1

※性能・時間は構成/使用条件により異なる場合があります。

HAFはVSPでFlash accelerationを適用した場合の値です。

ランダムWRITE (7D+1P, 8KB)のＩＯＰＳ相対比較

ランダムREAD (7D+1P, 8KB)のＩＯＰＳ相対比較

４-６. ＨＡＦのパフォーマンス

ＳＳＤよりもかなり高速

SSD

SAS HDD 1

HAF

Hitachi Virtual Storage Platform(VSP)


大容量 DRAM

インターフェース

専用フラッシュコントローラ

MLC フ

ラッ

シュ

メモ

リ

ＭＬＣフラッシュメモリ

MLC フ

ラッ

シュ

メモ

リ


MLC フ

ラッ

シュ

メモ

リ


MLC フ

ラッ

シュ

メモ

リ


MLC フ

ラッ

シュ

メモ

リ


MLC フ

ラッ

シュ

メモ

リ


MLC フ

ラッ

シュ

メモ

リ


MLC フ

ラッ

シュ

メモ

リ


高速なランダム性能 •高性能マルチコアプロセッサと多重アクセス制御により高いスループット性能を実現

•小さいデータは大容量ＤＲＡＭに書き込むことで超高速なライト性能を実現

フラッシュメモリの長寿命化 • 高性能プロセッサによる書き込み回数平準化などによりフラッシュメモリの耐久性向上

スケーラビリティ/コストパフォーマンス • 多数のフラッシュメモリの制御を効率化することで、大容量/スケーラビリティを実現し、コストパフォーマンスを向上

高信頼/高機能 • ストレージコントローラと連携した高信頼/高機能(定期データチェック/回復機能、高速LDEVフォーマット機能、ゼロデータ圧縮機能など)

４-７. ＨＡＦのしくみ

フラッシュメモリの性能を最大限に引き出す構造


HAF

数ＴＢ以上のＤＢおよび超高速性を求める場合に最適

１.６ＴＢ/枚 SSD

数ＴＢまでのＤＢに最適

２００ＧＢ/枚～

４-８. ＨＡＦとＳＳＤ及びＨＤＴとの棲み分け

ＤＢ容量とコストパフォーマンスで選択

コストパフォーマンス

ＤＢ容量

HDT ＨＤＤとのハイブリッドにより性能と容量の最適なバランスを


５．ＳＳＤとＯｒａｃｌｅの相性


SSDはランダムI/Oで抜群の効果。一方でシーケンシャルI/Oでは投資効果が薄い

５-１. ＳＳＤ対ＨＤＤのＩ/Ｏ性能基本データ

34

※性能値は構成/使用条件により異なります。

【READ】【WRITE】

SSD

HDD

シーケンシャルI/O （RAID5:4D+1P, ブロックサイズ：512KB, 多重度：1）

ランダムI/O（RAID5:4D+1P, ブロックサイズ：4KB, 多重度：32）

SSD

HDD

SSD

HDD

SSD

HDD

【READ】【WRITE】

※HDDは10000rpm, SASディスク。

性能差はあまり大きくない


Oracle DBで高速化したい業務は何か？

Oracleから見た I/Oパターン

オンラインバッチ処理分析系業務

ランダムI/O 多い普通少ない

シーケンシャルI/O あまりない普通多い

より高速化の要望が強い

シーケンシャルリードのSQLを多く擁するバッチ処理や分析系業務ではSSDの効果をどう考えればよいか？

35

５-２. 高速化したい業務は何？


[分]

◆ストレージ側が受け取るI/Oパターン（分析系のSQL22個）

シーケンシャルI/O

◆シーケンシャルリードのSQL発行でストレージ側（SSD）が受け取るI/Oパターンを調べてみた。

約6～7割がランダムI/O

その理由は

Oracle Parallel Query

５-３. 分析系ＳＱＬのＩ/Ｏパターンは？

36

ランダムI/O


シリアル実行では、1つのSQLに1つのコアが割り当てられる。

◆オンライン処理の場合 ※多くのSQLが複数端末から発行される

SQL SQL SQL SQL SQL SQL

SQL SQL SQL SQL SQL SQL

SQL

◆分析系処理の場合 ※1本の重いSQLが流れる

Parallel Query

PX PX SQL

PX PX PX PX PX PX

PX PX PX

マルチコアが活用できない。 CPUネック。

マルチコアを有効活用。 CPUネックが解消されディスク速度に依存。

マルチコアサーバでバッチ処理や分析系処理を行う場合、 Parallel Queryはレスポンス向上に有効。

さて、ランダムvsシーケンシャルの話は・・・

Parallel Queryでは、I/Oも多重化されて発行される。

５-４. パラレルクエリとは

37

PX：Parallel Execution Process


Parallel Query

ASM

RAID

分割

分割

分割

Drive（HDD/SSD）

１ドライブに対する I/O要求が多重／並列化し、ランダムI/Oとなる。

多重

FC

HUS130 #0

LU

Ctrl0

P P P P

LU

Ctrl1

P P P P

FC FC FC

Oracle A

SM

DBサーバ

LU LU

LU LU LU LU

RAID5

RAID5

SQL発行

パラレル化

FC

HUS130 #0

LU

Ctrl0

P P P P

LU

Ctrl1

P P P P

FC FC FC

Oracle A

SM

DBサーバ

LU LU

LU LULU LU

RAID5

RAID5

SQL発行

パラレル化

５-５. パラレルクエリ＋ＡＳＭでＩ/Ｏはどうなる？

38


Oracle DBが発行するI/Oパターンと SSDは、業務の性質によらず相性が良い。

（もちろん、I/O負荷が高いもの）

ランダムI/OではSSDは抜群の効果

だから

５-６. ＳＳＤとＯｒａｃｌｅの相性はとてもいい。

39


６．ＲＡＣｏｎＳＳＤ分析系ＳＱＬでの検証


【サーバ】 Blade数： BS2000 × 2Blade CPU： Xeon X5690 3.46GHz 6core×2 Memory： 96GB

【ストレージ】台数： HUS130(基本筺体＋拡張筺体) × 2台 SSD： 200GB × 28 (6D+1P × 4組)

データベース情報

OS：Redhat Enterprise Linux 6.2

DB：Oracle Database 11g Release2 (11.2.0.3)

DB構成：2ノード RAC構成

DBサイズ：150GB, 及び350GB

DBブロックサイズ：32K

DBキャッシュサイズ：48GB

ハードウェア

8Gb/s×16

200GB SSD

・・・

ＯｒａｃｌｅＲＡＣｏｎＳＳＤの構成

【ストレージＩ／Ｏ】インターフェース： FC FCケーブル： 16本 (8本/Blade × 2) FC通信速度： 8Gbps/port

６-１. 検証構成


■ Ｉ／Ｏ帯域

※dd性能とは、OSのddコマンドにてI/O性能を測定した結果

■ ＳＱＬ処理時間

0

2

4

6

8

10

12

HDD(SQL性能) SSD(SQL性能) SSD(dd性能)

0.75

8.44

11.00 (GB/s)

６-２. ＨＤＤとＳＳＤでの比較

07：53

01：19

01:30

03:00

04:30

06:00

07:30

09:00

(mm:ss)

HDD SSD（1ノード）

00：41

SSD（2ノード）

Ｉ／Ｏが多く出る分析系DB処理を模擬したＳＱＬを使用

I/Oスループット及びSQLのレスポンスタイムの合計を測定

ＰＣサーバ＋HDD搭載ストレージと比較。

【サーバ】機種：HA8000/RS210-hHM ＣＰＵ：E5-2690×2 メモリー：96GB Ｉ/Ｏ：６Gbps/port 4本（2本/台 × 2）【ストレージ】機種：ＢＲ１２００×２台ＨＤＤ： 146GB (15,000rpm) × 16 (7D+1P × 2)

帯域とＳＱＬ処理時間を測定比較機器

Ｉ／Ｏ帯域、レスポンスとも、１０倍以上は想定通り。

© Hitachi, Ltd. 2013. All rights reserved. 43

実行時のI/OとCPUの状況 CPU利用状況 Parallel 20

0102030405060708090

100

0:0

0:0

0

0:0

0:4

5

0:0

1:3

0

0:0

2:1

5

0:0

3:0

0

0:0

3:4

5

0:0

4:3

0

0:0

5:1

5

0:0

6:0

0

0:0

6:4

5

0:0

7:3

0

0:0

8:1

5

0:0

9:0

0

0:0

9:4

5

0:1

0:3

0

0:1

1:1

5

0:1

2:0

0

0:1

2:4

5

0:1

3:3

0

0:1

4:1

5

0:1

5:0

0

0:1

5:4

5

0:1

6:3

0

0:1

7:1

5

時間(hh:mi:ss)

使用

率(%

)

cpuI/O性能(iostat) HDD

0

100

200

300

400

500

600

700

800

900

1000

0:0

0:0

0

0:0

0:4

5

0:0

1:3

0

0:0

2:1

5

0:0

3:0

0

0:0

3:4

5

0:0

4:3

0

0:0

5:1

5

0:0

6:0

0

0:0

6:4

5

0:0

7:3

0

0:0

8:1

5

0:0

9:0

0

0:0

9:4

5

0:1

0:3

0

0:1

1:1

5

0:1

2:0

0

0:1

2:4

5

0:1

3:3

0

0:1

4:1

5

0:1

5:0

0

0:1

5:4

5

0:1

6:3

0

0:1

7:1

5時間(hh:mi:ss)

read

性能

(MB

/se

c)

0

5

10

15

20

25

30

35

40

45

50

write

性能

(MB

/se

c)

read write

I/O性能が頭打ち

・800MB弱でI/Oネックとなる。・CPUは余裕がある

※1ノードでSQL実施 ※DBサイズは150GB

CPU利用状況 HDD

６-３. ＯＳ統計情報(ＨＤＤ構成)


実行時のI/OとCPUの状況

・約 MB/sのI/O性能・ I/Oにはまだ余裕がある状況・ CPUはほとんど使えている。

※2ノードでSQL実施 ※DBサイズを350Gに拡張。 (150GのままではI/O負荷が少なかったため)

時間(h:mm:ss)

0

100

200

300

400

500

600

700

0

1000

2000

3000

4000

5000

6000

7000

8000

9000

0:0

0:0

0

0:0

0:4

0

0:0

1:2

0

0:0

2:0

0

0:0

2:4

0

0:0

3:2

0

0:0

4:0

0

0:0

4:4

0

0:0

5:2

0

0:0

6:0

0

0:0

6:4

0

0:0

7:2

0

0:0

8:0

0

0:0

8:4

0

0:0

9:2

0

0:1

0:0

0

0:1

0:4

0

0:1

1:2

0

0:1

2:0

0

0:1

2:4

0

write

性能

(MB

/se

c)

read

性能

(MB

/se

c)

時間(hh:mi:ss)

I/O性能(iostat) 「RAC on SSD」

sum(read) sum(write)

0 10 20 30 40 50 60 70 80 90

100

0:0

0:0

0

0:0

0:4

0

0:0

1:2

0

0:0

2:0

0

0:0

2:4

0

0:0

3:2

0

0:0

4:0

0

0:0

4:4

0

0:0

5:2

0

0:0

6:0

0

0:0

6:4

0

0:0

7:2

0

0:0

8:0

0

0:0

8:4

0

0:0

9:2

0

0:1

0:0

0

0:1

0:4

0

0:1

1:2

0

0:1

2:0

0

0:1

2:4

0

使用

率(%

)

時間(hh:mi:ss)

CPU利用状況「RAC on SSD」

CPU

最大I/O性能

６-４. ＯＳ統計情報(ＲＡＣｏｎＳＳＤ)


６-５. リプレースが必要な古いＵＮＩＸ環境との比較

測定ケース旧UNIX環境「RAC on SSD」

1ノード「RAC on SSD」

2ノード

パラレル度 2 24 24

Partition数 16 24 24

圧縮無効有効有効

物理メモリ（搭載） 2GB 96GB 96GB

メモリ（Oracle割当） 1GB 45GB 45GB

SQL実行時間合計

約165倍高速約318倍高速

２００５年頃のシステムと比較してみた

2005年当時のUnixサーバと比較【サーバ】機種：HA8500/310 ＣＰＵ：Itanium 2 1.30GHz 1core×2 メモリー：2GB Ｉ/Ｏ： FC-2Gbps/port 2本【ストレージ】機種：SANRISE9570 ＨＤＤ： 146GB (15,000rpm) × 12

比較機器

ＣＰＵ性能の差(24倍)以上の改善があることが分かった。


７．信頼性に関する検証


I/Oスロット拡張装置

#1(Blade#0)

日立8GFC

P0 P1

（P0)I/Oスロット拡張装置接続ボード

日立8GFC

P0 P1

Expander(1：4モード）

P1

#11(Blade#1)

日立8GFC

P0

#10(Blade#1)

日立8GFC

P0 P1

Expander(1：4モード）

10

I/Oモジュール#1

Blade #0

#3(Blade#1)

日立8GFC

P1

#2(Blade#1)

日立8GFC

P0 P1 P1

#9(Blade#0)

日立8GFC

P0

#8(Blade#0)

日立8GFC

P0 P1

BS2000 サーバシャーシ

（P1)I/Oスロット拡張装置接続ボード（P2)I/Oスロット拡張装置接続ボード

Blade #1

（P3)I/Oスロット拡張装置接続ボード

#0(Blade#0)

サーバシャーシ接続ポート#1


I/Oモジュール#0 サーバシャーシ接続ポート#1


P0

Ctrl #1

1A 1B 1C 1D

Ctrl #0

0A 0B 0C 0D

Ctrl #1

1A 1B 1C 1D

Ctrl #0

0A 0B 0C 0D

LU1 LU2 LU3 LU4 LU5 LU6 LU7 LU8 LU11 LU12 LU13 LU14 LU15 LU16 LU17 LU18

「RAC on SSD」は、I/Oパスの冗長化により、パス障害やI/O機器障害が発生した場合にも業務を継続できるよう可用性を高めている。

SSD(RAID5)

… SSD(RAID5)

… SSD(RAID5)

… SSD(RAID5)

…

HUS130 HUS130

７-１. ＲＡＣｏｎＳＳＤの可用性


HUS基本筺体

Ctrl0

A B C D

Ctrl1

A B C D

HUS基本筺体

Ctrl0

A B C D

Ctrl1

A B C D

IOドロワ P

P

P

P

BS

2000

HUS拡張筺体 HUS拡張筺体

FC

FC

FC

FC

FC

FC

FC

FC

FC

FC

FC

FC

FC

FC

FC

FC

R3ブレード #0

P

P

R3ブレード #1

P

P

ＦＣケーブル抜線テスト

① ＦＣケーブルを１本抜いた状態 ② ＩＯドロワ片系障害としてドロワケー

ブルを抜いてＦＣ８本分繋がらない状態の確認

テストツール、およびテスト内容

分析系DB処理の一般的なベンチマークからＩ／Ｏ不可の高いＳＱＬを実行。

ＯＳ稼働時にケーブルを抜いてから測定を実施。

SQLのレスポンスタイムの合計、及びI/Oスループットを測定。

Ｉ／Ｏケーブルの本数が増えることで障害発生確率は多少なりとも増加。

ケーブル障害でも耐えうる構成であるが、性能に与える影響を調査する。

Blade数： BS2000 × 2Blade CPU： Xeon X5690(6core)×2/Blade Memory： 96GB/Blade

HUS130(基本筺体＋拡張筺体) × 2台 SSD： 200GB × 28本 (6D+1P) ×4組)

FCケーブル 8Gbps×16本

７-２. ＦＣケーブル抜線テスト


②Ｉ/Ｏドロワ片系障害ＦＣケーブル８本相当

最大Read帯域: MB/sec SQL 実行時間: 14分31秒

正常時ＦＣケーブル１６本

最大Read帯域: MB/sec SQL 実行時間 : 13分59秒

①ＦＣパス1本抜線ＦＣケーブル１５本

最大Read帯域: MB/sec SQL 実行時間: 14分14秒

それぞれの場合のＳＱＬレスポンスとＩ/Ｏスループットの推移

ケーブル抜いても停止すること無く連続稼働

ＳＱＬ実行時間に殆ど影響無し！帯域確保されているからこそ。

７-３. 稼動確認と性能比較


まとめ


オープンで信頼性の高いプラットフォームオープンＩＡサーバを利用した通常のＲＡＣ構成。AP移行も安心。通常のＬｉｎｕｘ／Ｗｉｎｄｏｗｓサーバ。バックアップ、監視ソフトも問題なし。高信頼サーバ／ストレージと、あらゆる箇所の冗長構成でサービスを止めない。

実証された構成、でも柔軟な選択構成選定やH/Wチューニングの手間をかけずに性能と信頼性を両立できる。サーバＣＰＵ、メモリ量、ＳＳＤ容量を処理内容に応じて調整できる。Ｏｒａｃｌｅライセンス／サポートを抑えられる様に少ないコア数でも構成できる。

その鍵はSSD HDD⇒SSDだけでは効果薄、通り道のネックを全部排除してSSDを生かす。 OracleDBのI/Oパターンは、SSDと相性がよい。オンラインのみならず、バッチ、分析処理の大幅な高速化を実現できる

高速化と信頼性を両立するDB高速化ソリューション

まとめ


• OracleとJavaは，Oracle Corporation 及びその子会社，関連会社の米国及びその他の国における登録商標です。

• Intel Xeonは，アメリカ合衆国およびその他の国におけるIntel Corporationの商標です。

• Linuxは，Linus Torvalds氏の日本およびその他の国における登録商標または商標です。

• その他、記載の会社名、製品名は、それぞれの会社の商標または登録商標です。

• 製品の改良により予告なく記載されている仕様が変更になることがあります。

他社商品名、商標等の引用に関する表示

52

Documents

[C13] フラッシュドライブで挑むOracle超高速化と信頼性の両立 by Masashi Fukui