Post on 30-Jun-2015
© Hitachi, Ltd. 2013. All rights reserved.
SSDで挑むOracle超高速化と信頼性の両立
株式会社 日立製作所 ITプラットフォーム事業本部
© Hitachi, Ltd. 2013. All rights reserved.
DB高速化需要の高まり
データの増加に伴い、処理時間が増加。これに伴い、データベースシステム要件として、
処理時間の短縮=DB高速化 が重要になりつつある。
DB担当者
担当者のDB高速化の悩みは尽きない
朝までかかる夜間 バッチは、ハードを
リプレースするだけで、 速くなるだろうか。
既存アプリは、今更 手を入れるなんて できないから
DB自体を速くしないと
DWHで抽出してる データが少な過ぎると 言われているが、
増やせば時間がかかる
1
© Hitachi, Ltd. 2013. All rights reserved.
Oracle高速化に必要な条件
オープンで信頼性の高いプラットフォームである 多くの実績に基づくIAサーバとSANストレージでのOracle RAC構成。 信頼性の高いハードを冗長構成化したLinux/Windowsサーバ。 万が一のトラブルでもボリュームコピーバックアップから迅速に戻せる。
データ容量や処理内容に合わせてコスト調整できる CPUコア数、メモリ量、ストレージ容量を予算に応じて調整できる。 Oracle EEライセンスを抑えられる様に少ないコア数でも構成できる。 コスト極小化の為、Oracle SEライセンスでも使える。
I/Oの多いバッチ処理を高速化できること 月末/期末のバッチ処理が短時間で処理でき多重度も増やせる。 DWHやBIのデータ抽出処理も高速化できる。 もちろんオンライン処理のレスポンスも良くなる。
何を速くしたいのか。速ければ何でもよいのか。
2
© Hitachi, Ltd. 2013. All rights reserved.
1.高速化の話
3
© Hitachi, Ltd. 2013. All rights reserved.
1-1. DBの高速化を実現する方法
簡単なものから難しいものまでいくつかある
ソフト的な要因 ハード的な要因
CPU メモリー I/O
SQL
機能
パラメータ
構造
CPU/メモリがボトルネックなら最新サーバへのリプレースで、大きな性能向上が期待できるが、それはまれなケース。
IO、ストレージネックの場合は、 それを解消すればCPU/メモリをもっと使え、大きく性能向上の可能性あり。
工数をかけずにDBを高速化する鍵はI/Oやストレージ
SQLで性能は大きく変わるが、変えられない(パッケージ利用、技術者不足)
技術者がいてもSQL文や構造の見直しは工数が膨大で難しい
パラメータチューニングは、実はほとんど効果なし
ストレージ
CPU メモリー I/O SQL 機能 パラメータ 構造 ストレージ
性能への効果
変更の難易度
性能への効果
変更の難易度
リプレースなら難易度は全て同じ 工数大
4
DBが遅い原因
© Hitachi, Ltd. 2013. All rights reserved.
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
1-2. H/Wの性能進化の不均衡
CPUの性能の伸びに比べ、I/Oはそれ程伸びていない
特にストレージ性能に寄与するHDD回転数とFC帯域は最悪
ストレージI/Oの高速化を行うことにより、 性能は劇的に向上する可能性がある ※CPU性能はSAP SDベンチ
マークをベースにした値
5
© Hitachi, Ltd. 2013. All rights reserved.
容量
年代
1-3. ストレージI/Oの高速化には
高速化の鍵はFlashメモリー
① 半導体なのでリード/ライトが速い
磁気記憶では無く、メモリーチップを使用して いる為、HDDより桁違いにリード/ライトが速い。
Flashの特徴として、ライトは上書きでは無く別の場所に書き、元の場所を無効化する。ブロック内に無効領域が増えたらガーベッジコレクションしてから消去する。
② 容量がHDD並みとなってきた
HDD互換のSSDでは数100GB~1TB超のデバイスが製品化されてきており、価格はHDDより割高だが性能が必要な状況で採用される様になってきた。
6
書込み済
空き領域
1ブロック
(消去単位)
© Hitachi, Ltd. 2013. All rights reserved.
1-4. SSDの特性
SLCとMLC
FlashにはSLCとMLCがあり、MLCの方がビッ
ト単価が安く大容量化に向いているが、短寿命等の弱点もある。しかし最近の技術進歩でMLCで
も基幹系システムに利用できる信頼性を持つものが出てきている。
データ保持時間
Flashは電源が無くてもデータを保持する特性
があるが、電源が無い状態で長期放置を行うと、微量ながらも電荷が減っていく為、データが失われることがある。MLCの場合は、3ヵ月以内には通電することを推奨。
SSDとは
HDD互換インターフェース(SATA/SAS)を装備したFlashメモリー。SDカードやUSBメモリーと同じNAND Flashを使用。
© Hitachi, Ltd. 2013. All rights reserved.
昼(オンライン) 夜 夜(バッチ処理)
1-5. ストレージのアクセス種別について
業務処理の1日のアクセス状況
DB領域全てをSSD化すれば、なにも考えなくても速くなる!
業務処理では、昼間はIOPSが必要で夜間は帯域が必要となる。
PCIフラッシュ等で一部の領域を高速化する手法も最近の話題。
しかしバッチの場合は、どのデータに高速性が求められるかわからない。
※グラフはストレージアクセスイメージです。
IOPS必要
帯域必要
8
© Hitachi, Ltd. 2013. All rights reserved.
1-6. 高速化に必要なSSD前提システムの要件
サーバに必要な条件
ストレージに必要な条件
サーバからストレージまでのI/Oボトルネックを排除
性能と可用性を両立する為、2ノード以上のOracle RAC構成
I/OはRACで実績多いFCで、SSD帯域合計に負けないポート数での接続
レイテンシーを極小化する為、FCスイッチを介さず直接ストレージに接続
インターコネクトは10GbpsのLANが必要。クロスケーブル接続は禁止
SSDの帯域とIOPSに対応したストレージコントローラを搭載している
搭載しているSSDのバス(SAS)をロスなく伝達できるバックエンドの装備
特定プロセッサネックを発生させない為のプロセッサコアの最適配置機能
LUの優先パスを最適に分散させ偏らない様にするFCパス制御機能
9
© Hitachi, Ltd. 2013. All rights reserved.
1-7. 検討したハードウェア構成
理想の構成はこれだ!
ストレージ
サーバ #0
サーバ #1 1G NIC
1G NIC
管理L
AN
10G NIC
10G LANSW
10G LANSW
10G NIC
10G NIC
10G NIC
Bonding Bonding
RAC Interconnect
RACインターコネクトは、10GbpsのNICで冗長化
もちろんパブリック LANも冗長化必要 今後は10G対応で
I/O性能を上げるため LUは分けて、ポートと 制御CPUにくくりつける
SASインターフェースが ボトルネックにならない SSD本数と経路を確保
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
SSD帯域に負けない為 FCは16ポートは必要 ストレージ直結が良い
10
© Hitachi, Ltd. 2013. All rights reserved.
ストレージ
1-8. 複数LUへのDB配置
使い過ぎ
少な過ぎ
FC 利用率
100%
0%
OSのI/Oキューの分散の為、LUを分けるのは一般的。
理想の構成ではLUにポートを専有させると性能は向上。
LUが複数あるとどのデータをどのLUに割り当てるか検討が必要
検討不十分だとLUのデータ占有量が不揃いになったり、アクセス頻度が偏る。
最悪本番稼働後に配置見直し等を実施しなければならなくなる。
高速化構成の副作用
LU
サーバ
HBA (FCカード)
TableC TableA TableD TableB
11
© Hitachi, Ltd. 2013. All rights reserved.
1-9. サイズやアクセス頻度の偏りの無いASM
LU
Oracle ASM
最高のパフォーマンス
複数LUをうまく使うには、 Oracle ASMを使用することで対応が可能。
複数LUがストライピングされ、全てのLUを均等に利用可能。
FC帯域も均等に利用でき、パフォーマンスも向上。
遅いLUが混在していると性能が引きずられ、DB全体が遅くなることがある。
理想構成では全てSSDで統一しており、最高のパフォーマンスを発揮可能。
FC 利用率
100%
0%
HBA (FCカード)
複数LUをまとめて管理
TableA TableB TableC TableD
12
© Hitachi, Ltd. 2013. All rights reserved.
2.信頼性の話
13
© Hitachi, Ltd. 2013. All rights reserved.
2-1. データベースシステムには信頼性が重要
性能だけでは企業インフラには使えない
ハードウェア ソフトウェア
部位 信頼性のポイント
サーバ スケールアップでは無く、
複数台を独立に動作させる
ネット
ワーク
NICは複数ポート必要
できればチップも分ける
サーバ/ストレージ間
複数FCカード搭載
直結で障害時切分け容易
ストレージ
/LU
コントローラ二重化
各LUパスの二重化
ボリュームコピー機能
部位 信頼性のポイント
Oracle
RAC 2台を両現用で稼働
ネット
ワーク
Bondingによる冗長化
(Teaming/Windows)
FCパス
制御
Active-Activeやロード
バランスのパス制御
Backup ボリュームコピー先の
二次バックアップ
可用条件は障害時でも業務が継続できること優先で、縮退は許容する。
テストではFCパス半減でも動作継続し、性能もあまり落ちないことを確認。
14
© Hitachi, Ltd. 2013. All rights reserved.
2-2. ネットワークの可用性
忘れがちなネットワークも重要
SSDのシステムでは1Gbpsでは不足。10Gが必要 RACのインターコネクトは1Gでは不足。 1:1通信の場合Bondingでは帯域を増やせない。 直結は禁止なので2台のスイッチ(冗長)で接続
10G LAN
Port数は最低4port。もっと欲しい RACのインターコネクトとPublicで4port。 Active DataGuard専用Portも性能に有効 管理ネットワークも別セグメントで欲しい いくつ?
Public LANの可用性は スパニングツリーで構成するのが良いのか。 リンクアグリゲーション(LA)なら相性問題はまずない。
複数スイッチでのLA機能(vPC, vLAG, MLAG)が旬。
仮想LA
LA(bond)
グループ
15
© Hitachi, Ltd. 2013. All rights reserved.
DBサーバ
正VOL (SSD)
ストレージ
SSDでもボリュームコピーは必要 DR機能もあればうれしい
16
2-3. ストレージの可用性確保
ストレージコントローラ
バックアップ サーバ
ストレージコントローラはDBでは要。ファームウェア更新は無停止が必須。
キャッシュメモリーは実は不揮発性。停電時は電池バックアップだが最近はフラッシュに書き出すものもある。
#0系ctrl
#1系ctrl
ストレージ機能による遠隔データ コピーによりDRサイト構築が容易に。
フルバックアップならボリュームコピーは必須。副ボリュームはHDDにしてコストダウン。
副VOL (HDD)
先
後
キャッシュ メモリー
バックアップや非常時の対応が必要
停電時
FLASH FLASH
© Hitachi, Ltd. 2013. All rights reserved.
2-4. SSDの寿命について
SSDの書き込み限界
SSDではRAIDの場合、構成本数と書込み量で寿命が決まる
全容量1.6TBを1日10回全て書き替えても、5年間使えます。
地上デジタル放送(非圧縮1.5MB/s)を121番組同時録画を5年間続ける。
どの程度の書き込み量なのか ※寿命まで絶対故障しないということではありません
装置によっては通知や対応も
SSDの書き込み容量が寿命の90%に達すると、通知を出す装置あり。
更に99%になるとスペアへデータをコピーし、書き込みを継続するように備える機種も。
SSDの寿命とは
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
© Hitachi, Ltd. 2013. All rights reserved.
温度・電圧の組合せによる過酷な環境による試験。
■複合マージン試験
■外観検査 通電検査だけでは判らない異常を検出。
半田飛散
開発検査 量産検査
X線透視 観察装置
2-5. 障害発生頻度を極力減らすには
18
元々メインフレームでやっていた処理なんだけど...
© Hitachi, Ltd. 2013. All rights reserved.
遠隔保守有
~ユーザーエリア~
IP-VPN
サポートセンタ
監視通報装置
遠隔保守無
自動通報 復旧
復旧
業務のダウン時間を短縮
ログ解析 保守作業 駆けつけ
部品手配
電話受付&問診 ログ採取/解析 保守作業 部品手配 駆けつけ 障害切分
障害発生
ユーザの負担作業
障害連絡
19
2-6. 万一の障害発生時に迅速な対応をするには
ファイアウォール
VPN ルータ
遠隔保守支援システムが自動通報を
© Hitachi, Ltd. 2013. All rights reserved.
2-7. 全てを満たすOracle高速化モデルはこれ!
(2ブレード)
(×2台)
高信頼の日立ハイエンドブレードサーバ 10Gイーサネットファブリックスイッチ搭載可能 APサーバ、バックアップサーバ等も混載可能
サーバ当たり8本のPCI-Eスロットを追加 独立した管理プロセッサが状態を監視 I/Oケーブル断でもサーバが落ちない可用性
SSD搭載前提の高性能コントローラ搭載 帯域ネックになりにくい高速バックエンドパス ShadowImageやTrueCopyバックアップ機能 (筺体内ボリュームコピー) (筺体間コピー)
データリードで 11GB/sの
I/O処理を確認。
8Gb/s×16
BladeSymphony BS2000
I/Oスロット拡張装置 (2ブレード用)
200/400/800GB SSD
・・・
Hitachi Unified Storage 130
20
© Hitachi, Ltd. 2013. All rights reserved.
3.SSDとOracleの相性の話
21
© Hitachi, Ltd. 2013. All rights reserved.
3-1. SSD/HDD IO性能基本データ
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ディスク。 数十倍の性能向上
性能差はあまり大きくない
© Hitachi, Ltd. 2013. All rights reserved.
3-2. 高速化したい業務は何?
Oracle DBで高速化したい業務は何か?
Oracleから見た I/Oパターン
オンライン バッチ処理 分析系業務
ランダムI/O 多い 普通 少ない
シーケンシャルI/O あまりない 普通 多い
より高速化の要望が強い
シーケンシャルリードのSQLを多く擁するバッチ処理や 分析系業務ではSSDの効果をどう考えればよいか?
23
© Hitachi, Ltd. 2013. All rights reserved.
3-3. 分析系SQLのI/Oパターンは?
◆ストレージ側が受け取るI/Oパターン(分析系のSQL22個) ◆シーケンシャルリードのSQL発行でストレージ側(SSD)が受け取るI/Oパターンを調べてみた。
約6~7割がランダムI/O
その理由は
Oracle Parallel Query(または業務並列化)
24
Screen Only
© Hitachi, Ltd. 2013. All rights reserved.
3-4. パラレルクエリとは
シリアル実行では、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
© Hitachi, Ltd. 2013. All rights reserved.
3-5. パラレルクエリ+ASMでI/Oはどうなる?
Parallel Query
ASM
RAID
分割
分割
分割
Drive(HDD/SSD)
1ドライブに対する 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
© Hitachi, Ltd. 2013. All rights reserved.
3-6. SSDとOracleの相性はとてもいい。
Oracle DBが発行するI/Oパターンと SSDは、業務の性質によらず相性が良い。
(もちろん、I/O負荷が高いもの)
ランダムI/OではSSDは抜群の効果
だから
27
© Hitachi, Ltd. 2013. All rights reserved.
4.「RAC on SSD」分析系SQLでの検証の話
28
© Hitachi, Ltd. 2013. All rights reserved.
4-1. 検証構成
【サーバ】 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
© Hitachi, Ltd. 2013. All rights reserved.
4-2. 結果概要
■ 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
© Hitachi, Ltd. 2013. All rights reserved.
4-3. 旧環境(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
5.まとめ
© Hitachi, Ltd. 2013. All rights reserved.
5. まとめ
33
オープンで信頼性の高いプラットフォーム オープンIAサーバを利用した通常のRAC構成。AP移行も安心。 通常のLinux/Windowsサーバ。バックアップ、監視ソフトも問題なし。 高信頼サーバ/ストレージと、あらゆる箇所の冗長構成でサービスを止めない。
実証された構成、でも柔軟な選択 構成選定やH/Wチューニングの手間をかけずに性能と信頼性を両立できる。 サーバCPU、メモリ量、SSD容量を処理内容に応じて調整できる。 Oracleライセンス/サポートを抑えられる様に少ないコア数でも構成できる。
その鍵はSSD HDD⇒SSDだけでは効果薄、通り道のネックを全部排除してSSDを生かす。 OracleDBのI/Oパターンは、SSDと相性がよい。 オンラインのみならず、バッチ、分析処理の大幅な高速化を実現できる
高速化と信頼性を両立するDB高速化ソリューション
© Hitachi, Ltd. 2013. All rights reserved.
• OracleとJavaは,Oracle Corporation 及びその子会社,関連会社の米国及びその他の国における登録商標です。
• Intel Xeonは,アメリカ合衆国およびその他の国におけるIntel Corporationの商標です。
• Linuxは,Linus Torvalds氏の日本およびその他の国における登録商標または商標です。
• その他、記載の会社名、製品名は、それぞれの会社の商標または登録商標です。
• 製品の改良により予告なく記載されている仕様が変更になることがあります。
他社商品名、商標等の引用に関する表示
34