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
管
理
LAN
10G
NIC
10G
LANSW
10G
LANSW
10G
NIC
10G
NIC
10G
NIC
Bonding Bonding
RAC Interconnect
ＲＡＣインターコネクトは、
１０ＧｂｐｓのＮＩＣで冗長化
もちろんパブリック
ＬＡＮも冗長化必要
今後は１０Ｇ対応で
Ｉ/Ｏ性能を上げるため
ＬＵは分けて、ポートと
制御ＣＰＵにくくりつける
ＳＡＳインターフェースが
ボトルネックにならない
ＳＳＤ本数と経路を確保
Ctrl0 Ctrl1 Ctrl2 Ctrl3
8Gbps x 16
F
C
F
C
F
C
F
C
F
C
F
C
F
C
F
C
F
C
F
C
F
C
F
C
F
C
F
C
F
C
F
C
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
(ＨＤＤ)
先
後
キャッシュ
メモリー
バックアップや非常時の対応が必要
停電時
FLASHFLASH

２-４. ＳＳＤの寿命について
ＳＳＤの書き込み限界
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
SSD
SSD
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 PXSQL
PX PX PX PX PX PX
PXPX 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
OracleASM
DBサーバ
LU LU
LU LULU LU
RAID5
RAID5
SQL発行
パラレル化
FC
HUS130 #0
LU
Ctrl0
P P P P
LU
Ctrl1
P P P P
FC FC FC
OracleASM
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を使用している場合には、実際に大幅な性能向上が期待できます。
（旧環境）

５. まとめ
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

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

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

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

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

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

Mais de Insight Technology, Inc.

Mais de Insight Technology, Inc. (20)

Último

Último (11)

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