Mais conteúdo relacionado
Semelhante a [C13] フラッシュドライブで挑むOracle超高速化と信頼性の両立 by Masashi Fukui (20)
Mais de Insight Technology, Inc. (20)
[C13] フラッシュドライブで挑むOracle超高速化と信頼性の両立 by Masashi Fukui
- 1. db tech showcase 東京 2013
フラッシュドライブで挑む
Oracle超高速化と信頼性の両立
2013/11/13
株式会社 日立製作所
ITプラットフォーム事業本部
© Hitachi, Ltd. 2013. All rights reserved.
- 14. 2-4. SSDに変えるとどうなるか
今までのシステム構成は
サーバからFCケーブルが2本ストレージ
に接続されている。
HDDはRAID構成で組まれている。
サーバ1台(またはActive-Standby)の構成
★単純にHDDをSSDに
置き換えただけだと...
ストレージの内部バス帯域限界を超える。
コントローラーの処理性能が不足する
FCポートの帯域限界を超える
I/O待ちが無くなりCPUが忙しくなる
サーバ
P
P
P
P
P
P
コントローラ
P
P
P
P
コントローラ
RAID構成
ストレージ
せっかくのSSDの高速性が、今までの構成では引き出せない!
© Hitachi, Ltd. 2013. All rights reserved.
- 15. 2-5. 高速化を実現するハードウェア構成
ボトルネックを極力排除する
Public LAN
サーバは2台以上で
Oracle RAC構成に
可用性と性能を両立
処理能力が上がるため、
RACインターコネクトは、
10Gの冗長構成が必要
RAC Interconnect
10G
LANSW
1G
NIC
1G
NIC
10G
NIC
Bonding
10G
NIC
Bonding
10G
NIC
F
C
F
C
F
C
F
C
1G
NIC
Bonding
1G
NIC
Bonding
サーバ
F
C
F
C
処理性能ネックを回避
する為にSSD数に
応じたコントローラ数を
F
C
F
C
F
C
F
C
F
C
F
C
F
C
F
C
F
C
8Gbps x 16
P
内部バスがボトルネック
にならない様なSSDの
スロット配置を行う
10G
NIC
サーバ
F
C
FCはSSDの数に応じ
帯域を確保できる本数
並列性と可用性に効果
10G
LANSW
P
P
Ctrl0
P
P
P
P
P
P
Ctrl1
P
P
Ctrl2
P
P
P
P
P
Ctrl3
ストレージ
これが理想のSSDシステム
© Hitachi, Ltd. 2013. All rights reserved.
- 30. 4-5. 日立自製フラッシュドライブ
大容量・超高速アクセス
HAF(Hitachi Accelerated Flash)
SANストレージに最適なフラッシュ
1.6TBの大容量、高信頼、高性能フラッシュメモリドライブ
レスポンス性能重視
適用拡大
キャッシュメモリ
フラッシュドライブ
SAS HDD
SATA/
NL-SAS HDD
ビットコスト重視
SSD(Solid State Drive)<他社OEM品>
高性能
HAF(Hitachi Accelerated Flash)<日立製>
高性能
高信頼
高機能
コストパフォーマンス
大容量/スケーラビリティ
日立はストレージシステムとフラッシュドライブの両方を自製
© Hitachi, Ltd. 2013. All rights reserved.
- 31. 4-6. HAFのパフォーマンス
SSDよりもかなり高速
Hitachi Virtual Storage Platform(VSP)
ランダムWRITE (7D+1P, 8KB)のIOPS相対比較
SAS HDD
1
SSD
HAF
ランダムREAD (7D+1P, 8KB)のIOPS相対比較
SAS HDD
1
SSD
HAF
※性能・時間は構成/使用条件により異なる場合があります。
HAFはVSPでFlash accelerationを適用した場合の値です。
© Hitachi, Ltd. 2013. All rights reserved.
- 32. 4-7. HAFのしくみ
フラッシュメモリの性能を最大限に引き出す構造
高速なランダム性能
• 高性能マルチコアプロセッサと多重アクセス制
御により高いスループット性能を実現
• 小さいデータは大容量DRAMに書き込むこと
で超高速なライト性能を実現
インターフェース
専用フラッシュ
コントローラ
大容量
DRAM
フラッシュメモリの長寿命化
• 高性能プロセッサによる書き込み回数平準化
などによりフラッシュメモリの耐久性向上
M
M
M
M
M
M
M
M
スケーラビリティ/コストパフォーマンス
C
C
C
C
C
C
C
C
• 多数のフラッシュメモリの制御を効率化すること
で、大容量/スケーラビリティを実現し、コストパ
フォーマンスを向上
リ
モ
メ
ュ
シ
ッ
ラ
フ
L
MLC フラッシュメモリ
リ
モ
メ
ュ
シ
ッ
ラ
フ
L
MLC フラッシュメモリ
リ
モ
メ
ュ
シ
ッ
ラ
フ
L
MLC フラッシュメモリ
リ
モ
メ
ュ
シ
ッ
ラ
フ
MLC フラッシュメモリ
リ
モ
メ
ュ
シ
ッ
ラ
フ
MLC フラッシュメモリ
リ
モ
メ
ュ
シ
ッ
ラ
フ
L
リ
モ
メ
ュ
シ
ッ
ラ
フ
MLC フラッシュメモリ
L
L
MLC フラッシュメモリ
リ
モ
メ
ュ
シ
ッ
ラ
MLC フラッシュメモリ
L
フ
L
高信頼/高機能
• ストレージコントローラと連携した高信頼/高機
能(定期データチェック/回復機能、高速LDEV
フォーマット機能、ゼロデータ圧縮機能など)
© Hitachi, Ltd. 2013. All rights reserved.
- 35. 5-1. SSD対HDDのI/O性能基本データ
シーケンシャルI/O (RAID5:4D+1P, ブロックサイズ:512KB, 多重度:1)
【READ】
SSD
【WRITE】
SSD
性能差はあまり大きくない
HDD
HDD
ランダムI/O(RAID5:4D+1P, ブロックサイズ:4KB, 多重度:32)
【READ】
【WRITE】
SSD
SSD
HDD
HDD
※性能値は構成/使用条件により異なります。
※HDDは10000rpm, SASディスク。
SSDはランダムI/Oで抜群の効果。
一方でシーケンシャルI/Oでは投資効果が薄い
© Hitachi, Ltd. 2013. All rights reserved.
34
- 38. 5-4. パラレルクエリとは
シリアル実行では、1つのSQLに1つのコアが割り当てられる。
◆オンライン処理の場合
※多くのSQLが複数端末から発行される
SQL SQL SQL SQL SQL SQL
◆分析系処理の場合
※1本の重いSQLが流れる
PX:Parallel Execution Process
SQL
SQL PX PX PX PX PX
Parallel
Query
PX
SQL SQL SQL SQL SQL SQL
マルチコアが活用できない。
CPUネック。
PX PX PX PX PX
マルチコアを有効活用。
CPUネックが解消され
ディスク速度に依存。
マルチコアサーバでバッチ処理や分析系処理を行う場合、
Parallel Queryはレスポンス向上に有効。
さて、ランダムvsシーケンシャルの話は・・・
Parallel Queryでは、I/Oも多重化されて発行される。
© Hitachi, Ltd. 2013. All rights reserved.
37
- 42. 6-1. 検証構成
Oracle RAC on SSDの構成
ハードウェア
【サーバ】
Blade数: BS2000 × 2Blade
CPU: Xeon X5690 3.46GHz 6core×2
Memory: 96GB
【ストレージI/O】
インターフェース: FC
FCケーブル: 16本 (8本/Blade × 2)
FC通信速度: 8Gbps/port
【ストレージ】
台数: HUS130(基本筺体+拡張筺体) × 2台
SSD: 200GB × 28 (6D+1P × 4組)
8Gb/s×16
データベース情報
OS:Redhat Enterprise Linux 6.2
DB:Oracle Database 11g Release2 (11.2.0.3)
・・・
200GB SSD
DB構成:2ノード RAC構成
DBサイズ:150GB, 及び350GB
DBブロックサイズ:32K
DBキャッシュサイズ:48GB
© Hitachi, Ltd. 2013. All rights reserved.
- 44. read
1000
900
800
700
600
500
400
300
200
100
0
50
45
40
35
30
25
20
15
10
5
0
write性能(MB/sec)
I/O性能(iostat) HDD
0:17:15
I/O性能が頭打ち
© Hitachi, Ltd. 2013. All rights reserved.
0:17:15
0:16:30
0:15:45
0:15:00
0:14:15
0:13:30
0:12:45
0:12:00
0:11:15
0:10:30
0:09:45
0:09:00
0:08:15
0:07:30
0:06:45
0:06:00
0:05:15
0:04:30
0:03:45
0:03:00
0:02:15
0:01:30
0:00:45
0:00:00
実行時のI/OとCPUの状況
0:16:30
使用率(%)
・800MB弱でI/Oネックとなる。
・CPUは余裕がある
0:15:45
0:15:00
0:14:15
0:13:30
0:12:45
0:12:00
0:11:15
0:10:30
0:09:45
0:09:00
0:08:15
0:07:30
0:06:45
0:06:00
0:05:15
0:04:30
0:03:45
0:03:00
0:02:15
0:01:30
0:00:45
0:00:00
read性能(MB/sec)
6-3. OS統計情報(HDD構成)
CPU利用状況 Parallel 20
CPU利用状況 HDD
100
90
80
70
60
50
40
30
20
10
0
時間(hh:mi:ss)
cpu
※1ノードでSQL実施
※DBサイズは150GB
時間(hh:mi:ss)
write
43
- 45. 6-4. OS統計情報(RAC on SSD)
実行時のI/OとCPUの状況
CPU利用状況 「RAC on SSD」
0:12:40
0:12:00
0:11:20
0:10:40
0:10:00
0:09:20
0:08:40
0:08:00
0:07:20
0:06:40
0:06:00
0:05:20
0:04:40
0:04:00
0:03:20
0:02:40
0:02:00
0:01:20
0:00:40
100
90
80
70
60
50
40
30
20
10
0
0:00:00
使用率(%)
・約
MB/sのI/O性能
・ I/Oにはまだ余裕がある状況
・ CPUはほとんど使えている。
時間(hh:mi:ss)
時間(h:mm:ss)
CPU
I/O性能(iostat) 「RAC on SSD」
700
9000
最大I/O性能
8000
※2ノードでSQL実施
※DBサイズを350Gに拡張。
600
6000
5000
400
4000
300
3000
200
write性能(MB/sec)
500
(150GのままではI/O負荷が少な
かったため)
2000
100
時間(hh:mi:ss)
sum(read)
0:12:40
0:12:00
0:11:20
0:10:40
0:10:00
0:09:20
0:08:40
0:08:00
0:07:20
0:06:40
0:06:00
0:05:20
0:04:40
0:04:00
0:03:20
0:02:40
0:02:00
0:01:20
0
0:00:40
1000
0:00:00
read性能(MB/sec)
7000
0
sum(write)
© Hitachi, Ltd. 2013. All rights reserved.
44
- 48. 7-1. RAC on SSDの可用性
「RAC on SSD」は、I/Oパスの冗長化により、パス障害やI/O機器障
害が発生した場合にも業務を継続できるよう可用性を高めている。
BS2000 サーバシャーシ
Blade #0
(P0)I/Oスロット拡張装置接続ボード
サーバシャーシ
接続ポート#0
Blade #1
(P1)I/Oスロット拡張装置接続ボード
サーバシャーシ
接続ポート#1
I/Oモジュール#0
(P2)I/Oスロット拡張装置接続ボード
サーバシャーシ
接続ポート#0
I/Oスロット
拡張装置
Expander(1:4モード)
(P3)I/Oスロット拡張装置接続ボード
サーバシャーシ
接続ポート#1
I/Oモジュール#1
Expander(1:4モード)
#0(Blade#0)
#1(Blade#0)
#2(Blade#1)
#3(Blade#1)
#8(Blade#0)
#9(Blade#0)
#10(Blade#1)
#11(Blade#1)
日立8GFC
日立8GFC
日立8GFC
日立8GFC
日立8GFC
日立8GFC
日立8GFC
日立8GFC
P0
P1
0A
0B
P0
0C
P1
0D
P0
P1
1A
Ctrl #0
LU1
LU2
1B
P1
10
1C
P0
0A
1D
LU3
LU4
…
LU5
LU6
LU7
P1
0B
P0
0C
P1
0D
LU8
LU11 LU12 LU13 LU14
…
…
SSD(RAID5)
SSD(RAID5)
HUS130
P0
P1
1A
P0
1B
1C
P1
1D
Ctrl #1
Ctrl #0
Ctrl #1
SSD(RAID5)
HUS130
P0
LU15 LU16 LU17 LU18
…
SSD(RAID5)
© Hitachi, Ltd. 2013. All rights reserved.
47
- 49. 7-2. FCケーブル抜線テスト
FCケーブル抜線テスト
Blade数: BS2000 × 2Blade
CPU: Xeon X5690(6core)×2/Blade
Memory: 96GB/Blade
P
P
P
テストツール、およびテスト内容
R3ブレード #1
R3ブレード #0
P
F
C
F
C
IOドロワ
P
F
C
F
C
F
C
F
C
F
C
BS2000
I/Oケーブルの本数が増えることで
障害発生確率は多少なりとも増加。
ケーブル障害でも耐えうる構成である
が、性能に与える影響を調査する。
F
C
P
P
F
C
F
C
P
F
C
F
C
F
C
F
C
F
C
F
C
分析系DB処理の一般的なベンチマーク
からI/O不可の高いSQLを実行。
OS稼働時にケーブルを抜いてから測
定を実施。
SQLのレスポンスタイムの合計、及び
I/Oスループットを測定。
① FCケーブルを1本抜いた状態
② IOドロワ片系障害としてドロワケー
ブルを抜いてFC8本分繋がらない
状態の確認
FCケーブル
8Gbps×16本
A B C D
A B C D
A B C D
A B C D
Ctrl0
Ctrl1
Ctrl0
Ctrl1
HUS基本筺体
HUS基本筺体
HUS拡張筺体
HUS拡張筺体
HUS130(基本筺体+拡張筺体) × 2台
SSD: 200GB × 28本 (6D+1P) ×4組)
© Hitachi, Ltd. 2013. All rights reserved.
- 53. 他社商品名、商標等の引用に関する表示
• OracleとJavaは,Oracle Corporation 及びその子会社,関連会社の米国及びその他の国における登録商標で
す。
• Intel Xeonは,アメリカ合衆国およびその他の国におけるIntel Corporationの商標です。
• Linuxは,Linus Torvalds氏の日本およびその他の国における登録商標または商標です。
• その他、記載の会社名、製品名は、それぞれの会社の商標または登録商標です。
• 製品の改良により予告なく記載されている仕様が変更になることがあります。
© Hitachi, Ltd. 2013. All rights reserved.
52