D23 SSDで挑むOracle超高速化と信頼性の両立 by Yuu Morinaka

© Hitachi, Ltd. 2013. All rights reserved.

ＳＳＤで挑むＯｒａｃｌｅ超高速化と信頼性の両立

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


ＤＢ高速化需要の高まり

データの増加に伴い、処理時間が増加。これに伴い、データベースシステム要件として、

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

ＤＢ担当者

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

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

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

既存アプリは、今更手を入れるなんてできないから

ＤＢ自体を速くしないと

ＤＷＨで抽出してるデータが少な過ぎると言われているが、

増やせば時間がかかる

1


Ｏｒａｃｌｅ高速化に必要な条件

オープンで信頼性の高いプラットフォームである多くの実績に基づくＩＡサーバとＳＡＮストレージでのＯｒａｃｌｅＲＡＣ構成。信頼性の高いハードを冗長構成化したＬｉｎｕｘ/Ｗｉｎｄｏｗｓサーバ。万が一のトラブルでもボリュームコピーバックアップから迅速に戻せる。

データ容量や処理内容に合わせてコスト調整できるＣＰＵコア数、メモリ量、ストレージ容量を予算に応じて調整できる。ＯｒａｃｌｅＥＥライセンスを抑えられる様に少ないコア数でも構成できる。コスト極小化の為、ＯｒａｃｌｅＳＥライセンスでも使える。

Ｉ/Ｏの多いバッチ処理を高速化できること月末/期末のバッチ処理が短時間で処理でき多重度も増やせる。ＤＷＨやＢＩのデータ抽出処理も高速化できる。もちろんオンライン処理のレスポンスも良くなる。

何を速くしたいのか。速ければ何でもよいのか。

2


１．高速化の話

3


１-１. ＤＢの高速化を実現する方法

簡単なものから難しいものまでいくつかある

ソフト的な要因ハード的な要因

CPU メモリー I/O

SQL

機能

パラメータ

構造

CPU/メモリがボトルネックなら最新サーバへのリプレースで、大きな性能向上が期待できるが、それはまれなケース。

ＩＯ、ストレージネックの場合は、それを解消すればCPU/メモリをもっと使え、大きく性能向上の可能性あり。

工数をかけずにＤＢを高速化する鍵はＩ/Ｏやストレージ

SQLで性能は大きく変わるが、変えられない(パッケージ利用、技術者不足)

技術者がいてもSQL文や構造の見直しは工数が膨大で難しい

パラメータチューニングは、実はほとんど効果なし

ストレージ

CPU メモリーＩ／Ｏ SQL 機能パラメータ構造ストレージ

性能への効果

変更の難易度

性能への効果

変更の難易度

リプレースなら難易度は全て同じ工数大

4

ＤＢが遅い原因


CPUの性能推移とI/Oの性能推移

1

10

20

相対性能

2004 2005 2006 2007 2008 2009 2010

5

15

2011

25

30

4倍

10倍

HDD回転数 1倍

4core

6core

2core

28倍

10core

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

ＣＰＵの性能の伸びに比べ、Ｉ／Ｏはそれ程伸びていない

特にストレージ性能に寄与するＨＤＤ回転数とＦＣ帯域は最悪

ストレージＩ/Ｏの高速化を行うことにより、性能は劇的に向上する可能性がある ※CPU性能はSAP SDベンチ

マークをベースにした値

5


容量

年代

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

高速化の鍵はFlashメモリー

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

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

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

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

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

6

書込み済

空き領域

１ブロック

(消去単位)


１-４. ＳＳＤの特性

ＳＬＣとＭＬＣ

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

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

も基幹系システムに利用できる信頼性を持つものが出てきている。

データ保持時間

Flashは電源が無くてもデータを保持する特性

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

ＳＳＤとは

HDD互換インターフェース(SATA/SAS)を装備したFlashメモリー。SDカードやUSBメモリーと同じNAND Flashを使用。


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

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

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

ＤＢ領域全てをＳＳＤ化すれば、なにも考えなくても速くなる！

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

ＰＣＩフラッシュ等で一部の領域を高速化する手法も最近の話題。

しかしバッチの場合は、どのデータに高速性が求められるかわからない。

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

ＩＯＰＳ必要

帯域必要

8


１-６. 高速化に必要なＳＳＤ前提システムの要件

サーバに必要な条件

ストレージに必要な条件

サーバからストレージまでのＩ／Ｏボトルネックを排除

性能と可用性を両立する為、２ノード以上のＯｒａｃｌｅＲＡＣ構成

Ｉ/ＯはＲＡＣで実績多いＦＣで、ＳＳＤ帯域合計に負けないポート数での接続

レイテンシーを極小化する為、ＦＣスイッチを介さず直接ストレージに接続

インターコネクトは１０ＧｂｐｓのＬＡＮが必要。クロスケーブル接続は禁止

ＳＳＤの帯域とＩＯＰＳに対応したストレージコントローラを搭載している

搭載しているＳＳＤのバス(ＳＡＳ)をロスなく伝達できるバックエンドの装備

特定プロセッサネックを発生させない為のプロセッサコアの最適配置機能

ＬＵの優先パスを最適に分散させ偏らない様にするＦＣパス制御機能

9


１-７. 検討したハードウェア構成

理想の構成はこれだ！

ストレージ

サーバ #0

サーバ #1 1G NIC

1G NIC

管理L

AN

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

10G NIC

10G NIC

Bonding

10G NIC

10G NIC

Bonding

Public LAN

LU LU

LU LU

LU LU

LU LU

ＳＳＤ帯域に負けない為ＦＣは１６ポートは必要ストレージ直結が良い

10


ストレージ

１-８. 複数ＬＵへのＤＢ配置

使い過ぎ

少な過ぎ

ＦＣ利用率

100%

0%

ＯＳのＩ/Ｏキューの分散の為、ＬＵを分けるのは一般的。

理想の構成ではＬＵにポートを専有させると性能は向上。

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

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

最悪本番稼働後に配置見直し等を実施しなければならなくなる。

高速化構成の副作用

ＬＵ

サーバ

ＨＢＡ (FCカード)

TableC TableA TableD TableB

11


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

ＬＵ

Oracle ASM

最高のパフォーマンス

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

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

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

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

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

ＦＣ利用率

100%

0%

ＨＢＡ (FCカード)

複数ＬＵをまとめて管理

TableA TableB TableC TableD

12


２．信頼性の話

13


２-１. データベースシステムには信頼性が重要

性能だけでは企業インフラには使えない

ハードウェアソフトウェア

部位信頼性のポイント

サーバスケールアップでは無く、

複数台を独立に動作させる

ネット

ワーク

NICは複数ポート必要

できればチップも分ける

サーバ/ストレージ間

複数FCカード搭載

直結で障害時切分け容易

ストレージ

/LU

コントローラ二重化

各LUパスの二重化

ボリュームコピー機能

部位信頼性のポイント

Oracle

RAC ２台を両現用で稼働

ネット

ワーク

Bondingによる冗長化

(Teaming/Windows)

FCパス

制御

Active-Activeやロード

バランスのパス制御

Backup ボリュームコピー先の

二次バックアップ

可用条件は障害時でも業務が継続できること優先で、縮退は許容する。

テストではＦＣパス半減でも動作継続し、性能もあまり落ちないことを確認。

14


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

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

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

10G LAN

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

ＰｕｂｌｉｃＬＡＮの可用性はスパニングツリーで構成するのが良いのか。リンクアグリゲーション(LA)なら相性問題はまずない。

複数スイッチでのＬＡ機能(vPC, vLAG, MLAG)が旬。

仮想LA

LA(bond)

グループ

15


ＤＢサーバ

正VOL (ＳＳＤ)

ストレージ

ＳＳＤでもボリュームコピーは必要ＤＲ機能もあればうれしい

16

２-３. ストレージの可用性確保

ストレージコントローラ

バックアップサーバ

ストレージコントローラはＤＢでは要。ファームウェア更新は無停止が必須。

キャッシュメモリーは実は不揮発性。停電時は電池バックアップだが最近はフラッシュに書き出すものもある。

＃０系ctrl

＃１系ctrl

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

フルバックアップならボリュームコピーは必須。副ボリュームはＨＤＤにしてコストダウン。

副VOL (ＨＤＤ)

先

後

キャッシュメモリー

バックアップや非常時の対応が必要

停電時

FLASH FLASH


２-４. ＳＳＤの寿命について

ＳＳＤの書き込み限界

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

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

地上デジタル放送(非圧縮1.5MB/s)を121番組同時録画を5年間続ける。

どの程度の書き込み量なのか ※寿命まで絶対故障しないということではありません

装置によっては通知や対応も

SSDの書き込み容量が寿命の90%に達すると、通知を出す装置あり。

更に99%になるとスペアへデータをコピーし、書き込みを継続するように備える機種も。

ＳＳＤの寿命とは

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

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

17

値備考

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

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

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

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


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

■複合マージン試験

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

半田飛散

開発検査量産検査

X線透視観察装置

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

18

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


遠隔保守有

～ユーザーエリア～

IP-VPN

サポートセンタ

監視通報装置

遠隔保守無

自動通報復旧

復旧

業務のダウン時間を短縮

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

部品手配

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

障害発生

ユーザの負担作業

障害連絡

19

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

ファイアウォール

VPN ルータ

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


２-７. 全てを満たすＯｒａｃｌｅ高速化モデルはこれ！

（２ブレード）

（×２台）

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

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

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

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

Ｉ/Ｏ処理を確認。

8Gb/s×16

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

Ｉ/Ｏスロット拡張装置（２ブレード用）

200/400/800GB SSD

・・・

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

20


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

21


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

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

22

HDD

SSD

HDD

SSD

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

【READ】【WRITE】

SSD

HDD

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

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

SSD

HDD

HDD

SSD

HDD

SSDSSD

HDD

SSD

HDD

【READ】【WRITE】

※HDDは10000rpm, SASディスク。数十倍の性能向上

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


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

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

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

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

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

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

より高速化の要望が強い

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

23


３-３. 分析系SQLのI/Oパターンは？

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

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

その理由は

Oracle Parallel Query（または業務並列化）

24

Screen Only


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

シリアル実行では、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も多重化されて発行される。

25

PX：Parallel Execution Process


３-５. パラレルクエリ＋ASMでI/Oはどうなる？

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

Ora

cle

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発行

パラレル化

26


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

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

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

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

だから

27


４．「RAC on SSD」分析系SQLでの検証の話

28


４-１. 検証構成

【サーバ】 Blade数： BS2000 × 2Blade CPU： Xeon X5690 3.46GHz 6core×2 Memory： 96GB インターフェース： FC FC通信速度： 8Gbps/port FCケーブル： 16本(8本/Blade × 2)

【ストレージ】台数： HUS130 × 2台 FC通信速度： 8Gbps/port FCケーブル： 16本(8本/台 × 2)

【DISK】 SSD： 200GB × 28 (14/台 × 2)

データベース情報

OS：Redhat Enterprise Linux 6.2

RDBMS：Oracle Database 11g Release2 (11.2.0.3)

DB構成：2ノード RAC構成

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

DBブロックサイズ：32K

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

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

分析系DB処理の一般的なベンチマークテストを使用

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

同サーバでのHDDを搭載した同等構成と比較する。

ハードウェア BS2000

HUS130

I/Oスロット拡張装置

29


４-２. 結果概要

■ I/Oスループット

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

■ SQLレスポンス（IO処理の重い10個）・約1/5倍に短縮

HDD構成から「RAC on SSD」への置き換えにより、

I/Oスループット11倍、レスポンスタイム1/5に短縮

0

2

4

6

8

10

12

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

0.75

8.44

11.00

00:00

01:26

02:53

04:19

05:46

07:12

08:38

HDD SSD

07:45

01：34

ところで、11GB/sとはどのくらいの性能なのでしょうか・・・？

01:30

03:00

04:30

06:00

07:30

09:00

(mm:ss) (GB/s)

FCパス14本の帯域を100％使用している状況と同じ、もしくはDVD 1枚を0.4秒で読み込むパフォーマンスです。たとえば1TBの表であれば1分半で読み込み完了します。

30


４-３. 旧環境（6～7年程度前のUnixモデル）との比較

【サーバ】日立Unixサーバ CPU：Itanium 2 1.30GHz 1core×2 Memory：2 GByte OS：HP-UX Itanium 11.23(64bit) Oracle: Oracle Database 10.2.0.5 【FCカード】ポート数：2Port × 1枚転送速度：2Gbps/port

【ストレージ】型名:SANRISE9570V インターフェース：FC ポート数： 2Port × 2枚通信速度：2Gbps/port 【DISK】 DISK数(HDD) ：12 (146GB * 12)

31

SANRISE9570V

Port#0 Port#1

Ctrl#1

Port#A Port#B

Ctrl#0

Port#A Port#B

日立Unixサーバ

8Gb/s×16

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

パラレル度 2 20

Partition数 16 24

圧縮無効有効

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

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

SQL実行時間合計 3:37:31 00:01:34

約138倍高速

最新モデルと旧環境では条件が大きく異なるため、単純な比較はできません。ただし、お客様の旧環境も同様に古いH/Wを使用している場合には、実際に大幅な性能向上が期待できます。

（旧環境）

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

５．まとめ


５. まとめ

33

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

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

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

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


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

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

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

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

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

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

34

Technology

D23 SSDで挑むOracle超高速化と信頼性の両立 by Yuu Morinaka