0
db tech showcase 東京 2013

フラッシュドライブで挑む
Oracle超高速化と信頼性の両立
2013/11/13
株式会社 日立製作所
ITプラットフォーム事業本部

© Hitachi, Ltd. 2013. All r...
Contents
1. 従来のシステムの問題点
2. フラッシュを使った高速化
3. フラッシュのシステムの信頼性
4. フラッシュドライブの活用
5. SSDとOracleの相性
6. RAC on SSD分析系SQLでの検証
7. 信頼性に...
0-1. DB高速化需要の高まり
 データの増加に伴い、処理時間が増加。これに伴い、

処理時間の短縮=DB高速化
が重要になりつつある。
DWHで抽出してる
データが少な過ぎると
言われているが、
増やせば時間がかかる

朝までかかる夜間
...
1.従来のシステムの問題点

© Hitachi, Ltd. 2013. All rights reserved.
1-1. H/Wの性能進化の不均衡
2005年を1とした時の性能推移
相対性能
25

24倍

8core

20
15
6core

10

10倍

5
2core

1

2005

2006

4倍

4core

HDD回転数
20...
1-2. 2005年と同じ構成のシステムでは
CPU,FC帯域,HDDの使用率の状況は
(%)

HDDの使用率は
OSの性能モニタでは
直接表示されない

100
90
80
70
60

HDDの使用率が
ボトルネックなのが
実は分かりにく...
1-3. HDDのデータリード処理の問題点

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

要求

データ

要求

データ

ャ

ト
シ

ー

要求

データ

ッ

レ
ュ

ジ

要求

東京

12:00

28°

大阪

14:00

...
1-4. HDD I/O性能基本データ

HDDはランダムアクセスが苦手
SAS 15,000回転/s, RAID5:4D+1P
ブロックサイズ:512KB, 多重度:8

リード帯域性能
シーケンシャル
ランダム

1
7.8

ライト帯域性...
1-5. ストレージのアクセス種別について

業務処理の1日のアクセス状況
IOPS必要

夜(バッチ処理)

昼(オンライン)

夜

業務処理では、昼間はIOPSが必要で夜間は帯域が必要となる。
IOPSはまさにHDDの回転数に依存する...
2.フラッシュを使った高速化

© Hitachi, Ltd. 2013. All rights reserved.
2-1. ストレージI/Oの高速化には

これからはFlashメモリー

USBメモリー
コンパクトフラッシュ

SDカード

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

 磁気記憶では無く、メモリーチップを使用して
い...
2-2. SSDの特性
SSDとは
HDD互換インターフェース(SATA/SAS)を装備
したFlashメモリー。パソコン用から始まり、今で
は信頼性の高いエンタープライズ用もある。

SLCとMLC
FlashにはSLCとMLCがあり、MLC...
2-3. SSDのパフォーマンス

HDDよりもかなり高速
ランダムWRITE (7D+1P, 8KB)のIOPS相対比較
SAS HDD

1

15

SSD

ランダムREAD (7D+1P, 8KB)のIOPS相対比較
SAS HDD
...
2-4. SSDに変えるとどうなるか

今までのシステム構成は
 サーバからFCケーブルが2本ストレージ
に接続されている。
 HDDはRAID構成で組まれている。
 サーバ1台(またはActive-Standby)の構成

★単純にHD...
2-5. 高速化を実現するハードウェア構成

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

サーバは2台以上で
Oracle RAC構成に
可用性と性能を両立
処理能力が上がるため、
RACインターコネクトは、
10Gの冗長構成が必要

...
2-6. 複数LUへのDB配置

高速化構成の副作用
各LUにアクセスするFCポートを
固定化しOSとFCのキューを一
致させオーバーヘッドを削減。
しかしLUが複数になると、どの
データをどのLUに割り当てるか
検討が必要になる。
検討...
2-7. サイズやアクセス頻度の偏りの無いASM

複数LUをまとめて管理
TableA

複数LUをうまく使うには、
Oracle ASMを使用すること
で対応が可能。
複数LUがストライピングされ、
全てのLUを均等に利用可能。

理...
2-8. そのシステムを実現したのがこの構成!
BladeSymphony BS2000
高信頼の日立ハイエンドブレードサーバ
10Gイーサネットファブリックスイッチ搭載可能
APサーバ、バックアップサーバ等も混載可能

I/Oスロット拡...
3.フラッシュのシステムの信頼性

© Hitachi, Ltd. 2013. All rights reserved.
3-1. SSDの寿命について
SSDの寿命とは
SSDはデータ書き込み時に電子が移動することで半導体が劣化し、書き込み回数上
限を決めている。200GBのSSDの場合3.6PBの書き込みが上限である。
※3.6PBは日立採用のSSDの場合

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

忘れがちなネットワークも重要
 SSDのシステムでは1Gbpsでは不足。10Gが必要
RACのインターコネクトは1Gでは不足。
1:1通信の場合Bondingでは帯域を増やせない。
直結は禁止なので2台...
3-3. サーバの信頼性

メーカーはどこでも一緒。では無い
障害発生頻度を減らすには
壊れやすい部品を使わない ⇒ 壊れ易いかどうか判別するプロセスが必要。
部品の個体差による不具合品を排除する ⇒ 部品受け入れ時と完成後にも検査する。
...
3-4. 障害発生頻度を極力減らすには

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

量産検査

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

■複合マージン試験
温度・電圧の組合せによる
過酷な環境による...
3-5. 万一の障害発生時に迅速な対応をするには

遠隔保守支援システムが自動通報を
~ユーザーエリア~
IP-VPN
フ
ァ
イ
ア

VPN
ルータ
ウ
ォ

監視通報装置

ー
ル

サポート
センタ
ユーザの負担作業
遠隔保守無
障害発...
4.フラッシュドライブの活用

© Hitachi, Ltd. 2013. All rights reserved.
4-1. エンタープライズ向けフラッシュストレージ

DBにはどのフラッシュが向いているのか
PCIフラッシュ

フラッシュアレイ装置
少~中容量の
シングルDBに
最適






中容量の
DWHに
最適

フラッシュストレージの中...
4-2. SANストレージの利点

バックアップ/DRとコストパフォーマンス
SSDでもボリュームコピーは必要

ストレージ間でのDR機能

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

 スト...
4-3. フラッシュの価格は今後どうなるのか

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

ビットコスト($/GB)

MLC SSDと
SAS HDDが
逆転する

数年後のリプレースにはSA...
4-4 日立ストレージのボリューム自動階層制御

HDDとのハイブリッドでも高速アクセス
仮想ボリューム
サーバから見せるLU。
容量は将来を見据えた大き
さに設定可能。
実データはプールの領域が
割り当てられる。

Tier1

Hit...
4-5. 日立自製フラッシュドライブ

大容量・超高速アクセス
HAF(Hitachi Accelerated Flash)
SANストレージに最適なフラッシュ
1.6TBの大容量、高信頼、高性能フラッシュメモリドライブ
レスポンス性能重視
適...
4-6. HAFのパフォーマンス

SSDよりもかなり高速

Hitachi Virtual Storage Platform(VSP)

ランダムWRITE (7D+1P, 8KB)のIOPS相対比較
SAS HDD

1

SSD
HAF
...
4-7. HAFのしくみ

フラッシュメモリの性能を最大限に引き出す構造
高速なランダム性能
• 高性能マルチコアプロセッサと多重アクセス制
御により高いスループット性能を実現
• 小さいデータは大容量DRAMに書き込むこと
で超高速なライト性...
4-8. HAFとSSD及びHDTとの棲み分け

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

HDT
パ

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

ォ

フ

ト

ス

マ

HAF
ン
ス

SSD
200GB/...
5.SSDとOracleの相性

© Hitachi, Ltd. 2013. All rights reserved.
5-1. SSD対HDDのI/O性能基本データ

シーケンシャルI/O (RAID5:4D+1P, ブロックサイズ:512KB, 多重度:1)
【READ】
SSD

【WRITE】
SSD

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

HDD

ラン...
5-2. 高速化したい業務は何?
Oracle DBで高速化したい業務は何か?
Oracleから見た
I/Oパターン

オンライン

バッチ処理

分析系業務

ランダムI/O

多い

普通

少ない

シーケンシャルI/O

あまりない

...
5-3. 分析系SQLのI/Oパターンは?
◆シーケンシャルリードの
SQL発行でストレージ側
(SSD)が受け取るI/Oパター
ンを調べてみた。

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

約6~7割がランダムI/O
...
5-4. パラレルクエリとは
シリアル実行では、1つのSQLに1つのコアが割り当てられる。
◆オンライン処理の場合
※多くのSQLが複数端末から発行される
SQL SQL SQL SQL SQL SQL

◆分析系処理の場合
※1本の重いSQL...
5-5. パラレルクエリ+ASMでI/Oはどうなる?
SQL発行

Parallel Query

多重

DBサーバ

パラレル化
SQL発行
FC

分割

ASM

FC
DBサーバ

FC

パラレル化
FC

FC

P

P

FC...
5-6. SSDとOracleの相性はとてもいい。

ランダムI/OではSSDは抜群の効果
だから
Oracle DBが発行するI/Oパターンと
SSDは、業務の性質によらず相性が良い。
(もちろん、I/O負荷が高いもの)

© Hitachi...
6.RAC on SSD分析系SQLでの検証

© Hitachi, Ltd. 2013. All rights reserved.
6-1. 検証構成

Oracle RAC on SSDの構成
ハードウェア
【サーバ】
Blade数: BS2000 × 2Blade
CPU: Xeon X5690 3.46GHz 6core×2
Memory: 96GB

【スト...
6-2. HDDとSSDでの比較

帯域とSQL処理時間を測定
I/Oが多く出る分析系DB処理を模擬した
SQLを使用
I/Oスループット及びSQLのレスポンスタイム
の合計を測定
PCサーバ+HDD搭載ストレージと比較。

比較機器
【...
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:...
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:...
6-5. リプレースが必要な古いUNIX環境との比較

2005年頃のシステムと比較してみた
比較機器

2005年当時のUnixサーバと比較

【サーバ】
機種:HA8500/310
CPU:Itanium 2 1.30GHz 1core×2...
7.信頼性に関する検証

© Hitachi, Ltd. 2013. All rights reserved.

46
7-1. RAC on SSDの可用性
「RAC on SSD」は、I/Oパスの冗長化により、パス障害やI/O機器障
害が発生した場合にも業務を継続できるよう可用性を高めている。
BS2000 サーバシャーシ
Blade #0
(P0)I/Oス...
7-2. FCケーブル抜線テスト

FCケーブル抜線テスト

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

P

P

P

テスト...
7-3. 稼動確認と性能比較

ケーブル抜いても停止すること無く連続稼働
 それぞれの場合のSQLレスポンスとI/Oスループットの推移
正常時
FCケーブル16本

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

①F...
まとめ

© Hitachi, Ltd. 2013. All rights reserved.
まとめ

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

 その鍵はSSD
HDD⇒SSDだけでは効果薄、通り道のネックを全部排除してSSDを生かす。
OracleDBのI/Oパターンは、SSDと相性がよい。
オンラインのみならず、...
他社商品名、商標等の引用に関する表示
• OracleとJavaは,Oracle Corporation 及びその子会社,関連会社の米国及びその他の国における登録商標で
す。
• Intel Xeonは,アメリカ合衆国およびその他の国におけるI...
[C13] フラッシュドライブで挑むOracle超高速化と信頼性の両立 by Masashi Fukui
[C13] フラッシュドライブで挑むOracle超高速化と信頼性の両立 by Masashi Fukui
Upcoming SlideShare
Loading in...5
×

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

1,311

Published on

0 Comments
3 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
1,311
On Slideshare
0
From Embeds
0
Number of Embeds
4
Actions
Shares
0
Downloads
36
Comments
0
Likes
3
Embeds 0
No embeds

No notes for slide

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

  1. 1. db tech showcase 東京 2013 フラッシュドライブで挑む Oracle超高速化と信頼性の両立 2013/11/13 株式会社 日立製作所 ITプラットフォーム事業本部 © Hitachi, Ltd. 2013. All rights reserved.
  2. 2. Contents 1. 従来のシステムの問題点 2. フラッシュを使った高速化 3. フラッシュのシステムの信頼性 4. フラッシュドライブの活用 5. SSDとOracleの相性 6. RAC on SSD分析系SQLでの検証 7. 信頼性に関する検証 © Hitachi, Ltd. 2013. All rights reserved.
  3. 3. 0-1. DB高速化需要の高まり  データの増加に伴い、処理時間が増加。これに伴い、 処理時間の短縮=DB高速化 が重要になりつつある。 DWHで抽出してる データが少な過ぎると 言われているが、 増やせば時間がかかる 朝までかかる夜間 バッチは、ハードを リプレースするだけで、 速くなるだろうか。 DB担当者 既存アプリは、今更 手を入れるなんて できないから DB自体を速くしないと 担当者のDB高速化の悩みは尽きない © Hitachi, Ltd. 2013. All rights reserved.
  4. 4. 1.従来のシステムの問題点 © Hitachi, Ltd. 2013. All rights reserved.
  5. 5. 1-1. H/Wの性能進化の不均衡 2005年を1とした時の性能推移 相対性能 25 24倍 8core 20 15 6core 10 10倍 5 2core 1 2005 2006 4倍 4core HDD回転数 2007 2008 2009 2010 2011 2012 1倍 ※CPU性能はSAP SDベンチ マークをベースにした値  CPU性能はコア数の増加と共に劇的に向上している。  CPU性能の伸びに比べ、HDD回転数やFC帯域は伸びていない システム構成は今でも2005年と同じ作りだが、それで良いのか © Hitachi, Ltd. 2013. All rights reserved. 5
  6. 6. 1-2. 2005年と同じ構成のシステムでは CPU,FC帯域,HDDの使用率の状況は (%) HDDの使用率は OSの性能モニタでは 直接表示されない 100 90 80 70 60 HDDの使用率が ボトルネックなのが 実は分かりにくい! 50 40 30 20 10 0 パーツ使用率のイメージ  HDDは常に稼働し続けており、ほぼ100%張りつきの状態。  CPUはあまり稼働率が上がらず、底辺を這っている様な状態。  FCの帯域はまだまだ余裕があるが、CPUよりは使われている状態。 HDDの高速化を行えば、CPUをもっと有効に使えるようになる © Hitachi, Ltd. 2013. All rights reserved.
  7. 7. 1-3. HDDのデータリード処理の問題点 円盤に書かれたデータが来るまで待つ 要求 データ 要求 データ ャ ト シ ー 要求 データ ッ レ ュ ジ 要求 東京 12:00 28° 大阪 14:00 32° 名古屋 14:00 35° 7/9 甲府 13:00 37° 7/9 ス 気温 7/8 キ 時間 7/8 データベース サーバ 都市 7/8 アプリケーション サーバ 日付 京都 14:00 36° データ  HDDは円盤にデータが記録されている。  円盤は1分間に15,000回転している。  目的のデータがヘッドまで来ると読み出せる。 例えば、 7/9の京都の最高気温が知りたい  ヘッドの移動(データのあるトラックまで移動)  回転待ち(最大1回転:1/15,000分=1/250秒) つまりHDDは1秒間に最悪250件しか読めないから遅い。 © Hitachi, Ltd. 2013. All rights reserved.
  8. 8. 1-4. HDD I/O性能基本データ HDDはランダムアクセスが苦手 SAS 15,000回転/s, RAID5:4D+1P ブロックサイズ:512KB, 多重度:8 リード帯域性能 シーケンシャル ランダム 1 7.8 ライト帯域性能 シーケンシャル ランダム 1 19 © Hitachi, Ltd. 2013. All rights reserved.
  9. 9. 1-5. ストレージのアクセス種別について 業務処理の1日のアクセス状況 IOPS必要 夜(バッチ処理) 昼(オンライン) 夜 業務処理では、昼間はIOPSが必要で夜間は帯域が必要となる。 IOPSはまさにHDDの回転数に依存するので、HDDの本数が少ないと厳しい。 HDDはランダムアクセスの帯域が出ない為、バッチがランダムなら性能が出ない。 HDDで構成している限り、目に見える性能改善は難しい! ※グラフはストレージアクセスイメージです。 © Hitachi, Ltd. 2013. All rights reserved.
  10. 10. 2.フラッシュを使った高速化 © Hitachi, Ltd. 2013. All rights reserved.
  11. 11. 2-1. ストレージI/Oの高速化には これからはFlashメモリー USBメモリー コンパクトフラッシュ SDカード ① 半導体なのでリード/ライトが速い CompactFlash  磁気記憶では無く、メモリーチップを使用して いる為、HDDより桁違いにリード/ライトが速い。 書  Flashの特徴として、ライトは上書きでは無く、 別の場所に書き、元の場所を無効化する。 ブロック内に無効領域が増えたらガーベッジ コレクションしてから消去する。 ② 容量がHDD並みとなってきた  HDD互換のSSDでは数100GB~1TB超の デバイスが製品化されてきており、価格はHDD より割高だが性能が必要な状況で採用される 様になってきた。 込 み 済 空 き 1ブロック 領 域 (消去単位) 容量 年代 © Hitachi, Ltd. 2013. All rights reserved.
  12. 12. 2-2. SSDの特性 SSDとは HDD互換インターフェース(SATA/SAS)を装備 したFlashメモリー。パソコン用から始まり、今で は信頼性の高いエンタープライズ用もある。 SLCとMLC FlashにはSLCとMLCがあり、MLCの方がビッ ト単価が安く大容量化に向いているが、短寿命等 の弱点もある。しかし技術進歩でMLCでも信頼 性が上がってきている。 データ保持時間 Flashは不揮発性ではあるが、電源が無い状態 で長期放置を行うと、微量ながらも電荷が減って いく為、データが失われることがある。MLCの場 合は、3ヵ月以内には通電することを推奨。 SLC 0 1 荷 電 MLC 00 01 10 (2) 11 (3) © Hitachi, Ltd. 2013. All rights reserved.
  13. 13. 2-3. SSDのパフォーマンス HDDよりもかなり高速 ランダムWRITE (7D+1P, 8KB)のIOPS相対比較 SAS HDD 1 15 SSD ランダムREAD (7D+1P, 8KB)のIOPS相対比較 SAS HDD SSD 1 61 ※性能・時間は構成/使用条件により異なる場合があります。 © Hitachi, Ltd. 2013. All rights reserved.
  14. 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. 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.
  16. 16. 2-6. 複数LUへのDB配置 高速化構成の副作用 各LUにアクセスするFCポートを 固定化しOSとFCのキューを一 致させオーバーヘッドを削減。 しかしLUが複数になると、どの データをどのLUに割り当てるか 検討が必要になる。 検討不十分だとLUのデータ占 有量が不揃いになったり、アクセ ス頻度が偏る。 最悪本番稼働後に配置の見直し や、テーブル分割などを実施し なければならなくなる。 サーバ TableC TableA TableD TableB HBA (FCカード) FC 利用率 100% 0% LU 使い 過ぎ ストレージ 少な 過ぎ © Hitachi, Ltd. 2013. All rights reserved.
  17. 17. 2-7. サイズやアクセス頻度の偏りの無いASM 複数LUをまとめて管理 TableA 複数LUをうまく使うには、 Oracle ASMを使用すること で対応が可能。 複数LUがストライピングされ、 全てのLUを均等に利用可能。 理想構成では全てSSDで統一 しており、最高のパフォーマン スを発揮可能。 TableC TableD HBA (FCカード) FC帯域も均等に利用でき、パ フォーマンスも向上。 遅いLUが混在していると性能 が引きずられ、DB全体が遅く なることがある。 TableB FC 利用率 100% 0% LU Oracle ASM 最高のパフォーマンス © Hitachi, Ltd. 2013. All rights reserved.
  18. 18. 2-8. そのシステムを実現したのがこの構成! BladeSymphony BS2000 高信頼の日立ハイエンドブレードサーバ 10Gイーサネットファブリックスイッチ搭載可能 APサーバ、バックアップサーバ等も混載可能 I/Oスロット拡張装置(IOドロワ) サーバ当たり8本のPCI-Eスロットを追加 独立した管理プロセッサが状態を監視 I/Oケーブル断でもサーバが落ちない可用性 8Gb/s×16 Hitachi Unified Storage 100 ・・・ 200/400/800GB SSD SSD搭載前提の高性能コントローラ搭載 帯域ネックになりにくい高速バックエンドパス ShadowImageやTrueCopyバックアップ機能 (筺体内ボリュームコピー) (筺体間コピー) データリードで 11GB/sの I/O処理を確認。 © Hitachi, Ltd. 2013. All rights reserved.
  19. 19. 3.フラッシュのシステムの信頼性 © Hitachi, Ltd. 2013. All rights reserved.
  20. 20. 3-1. SSDの寿命について SSDの寿命とは SSDはデータ書き込み時に電子が移動することで半導体が劣化し、書き込み回数上 限を決めている。200GBのSSDの場合3.6PBの書き込みが上限である。 ※3.6PBは日立採用のSSDの場合 SSDの書き込み限界 SSDではRAIDの場合、構成本数と書込み量で寿命が決まる SSD 1本の書き込み上限 (2D+1P)*4組での合計書込み上限 1日で書き込める容量 1秒で書き込める容量 値 3,600TB/5年 28,800TB/5年 備考 5年でこの値に達すると仮定 200GB×8本分=1.6TB 15,781GB/日 182MB/s 約16TB/日 ※寿命まで絶対故障しないということではありません 全容量1.6TBを1日10回全て書き替えても、5年間使えます。 上限値通知や対応も SSDの書き込み容量が寿命の90%(&95,96,97,98%)に達すると通知を出します。 更に99%になるとスペアへデータをコピーし、書き込みを継続するように備えます。 保守契約されていれば、万一期間内に寿命となったSSDは、無償交換します。 © Hitachi, Ltd. 2013. All rights reserved.
  21. 21. 3-2. ネットワークの可用性 忘れがちなネットワークも重要  SSDのシステムでは1Gbpsでは不足。10Gが必要 RACのインターコネクトは1Gでは不足。 1:1通信の場合Bondingでは帯域を増やせない。 直結は禁止なので2台のスイッチ(冗長)で接続 10G LAN  Port数は最低4port。もっと欲しい RACのインターコネクトとPublicで4port。 Active DataGuard専用Portも性能に有効 管理ネットワークも別セグメントで欲しい  Public LANの可用性は いくつ? 仮想LA スパニングツリーで構成するのが良いのか。 リンクアグリゲーション(LA)なら相性問題はまずない。 複数スイッチでのLA機能(vPC, vLAG, MLAG)が旬。 グループ LA(bond) © Hitachi, Ltd. 2013. All rights reserved.
  22. 22. 3-3. サーバの信頼性 メーカーはどこでも一緒。では無い 障害発生頻度を減らすには 壊れやすい部品を使わない ⇒ 壊れ易いかどうか判別するプロセスが必要。 部品の個体差による不具合品を排除する ⇒ 部品受け入れ時と完成後にも検査する。 万一の障害時の対応は 故障に対しては自動通報で迅速に対応。サービス拠点も日立なら全国至る所にある。 難しい問題切り分けや解析は、国内に技術者がいれば短期間で判明するもの。 © Hitachi, Ltd. 2013. All rights reserved.
  23. 23. 3-4. 障害発生頻度を極力減らすには 元々メインフレームでやっていた処理なんだけど... 開発検査 量産検査 ■外観検査 通電検査だけでは判ら ない異常を検出。 半田飛散 ■複合マージン試験 温度・電圧の組合せによる 過酷な環境による試験。 X線透視 観察装置 © Hitachi, Ltd. 2013. All rights reserved.
  24. 24. 3-5. 万一の障害発生時に迅速な対応をするには 遠隔保守支援システムが自動通報を ~ユーザーエリア~ IP-VPN フ ァ イ ア VPN ルータ ウ ォ 監視通報装置 ー ル サポート センタ ユーザの負担作業 遠隔保守無 障害発生 遠隔保守有 障害切分 電話受付&問診 駆けつけ ログ採取/解析 部品手配 保守作業 復旧 障害連絡 ログ解析 自動通報 駆けつけ 部品手配 保守作業 復旧 業務のダウン時間を短縮 © Hitachi, Ltd. 2013. All rights reserved.
  25. 25. 4.フラッシュドライブの活用 © Hitachi, Ltd. 2013. All rights reserved.
  26. 26. 4-1. エンタープライズ向けフラッシュストレージ DBにはどのフラッシュが向いているのか PCIフラッシュ フラッシュアレイ装置 少~中容量の シングルDBに 最適     中容量の DWHに 最適 フラッシュストレージの中では最も高速。 RAID構成はソフトウェアで実施。 共有ディスクとして使用できない。 稼働中のドライブ交換ができない。      PCIフラッシュの次に高速。 従来型ストレージと使い勝手同じ。 フラッシュデバイスのみで構成。 FCやInfiniBandインターフェース 共有ディスクとしても使用可能 従来型SANストレージ装置 中~大容量の OLTP/DWH に最適     SSDを搭載することで高速化。 DRAMキャッシュによるリード/ライトの高速化。 ストレージ内の各種オプション機能が豊富。 HDDとのハイブリッド構成による大容量化が可能。 © Hitachi, Ltd. 2013. All rights reserved.
  27. 27. 4-2. SANストレージの利点 バックアップ/DRとコストパフォーマンス SSDでもボリュームコピーは必要 ストレージ間でのDR機能  フルバックアップならボリュームコピーは必須。  回復時間を重要視するならこれが最適。  ストレージ機能による遠隔データ コピーによりDRサイト構築が容易。 DBサーバ 正VOL バックアップ サーバ 副VOL ハイブリッド・ドライブ対応  大容量かつコストパフォーマンスを追求するには、 HDD混載が解決策。  ボリュームコピーの副ボリュームにはHDDが最適。  ニアラインドライブを使用すれば、二次バックアップ やアーカイブ用途も。 © Hitachi, Ltd. 2013. All rights reserved.
  28. 28. 4-3. フラッシュの価格は今後どうなるのか ビットコストの動向 デバイス技術動向調査結果(日立調べ) 各デバイスのビットコスト推移予想 ビットコスト($/GB) MLC SSDと SAS HDDが 逆転する 数年後のリプレースにはSAS HDDは時代遅れとなる。 いつSSDを導入するか? 今でしょ! © Hitachi, Ltd. 2013. All rights reserved.
  29. 29. 4-4 日立ストレージのボリューム自動階層制御 HDDとのハイブリッドでも高速アクセス 仮想ボリューム サーバから見せるLU。 容量は将来を見据えた大き さに設定可能。 実データはプールの領域が 割り当てられる。 Tier1 Hitachi Dynamic Tiering Tier2 プール HDDやSSDからなる 物理ボリューム。 優先順位設定可能。 この例ではSSDを高い 優先順位に設定。 © Hitachi, Ltd. 2013. All rights reserved.
  30. 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. 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. 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.
  33. 33. 4-8. HAFとSSD及びHDTとの棲み分け DB容量とコストパフォーマンスで選択 コ HDT パ HDDとのハイブリッド により性能と容量の 最適なバランスを ー ォ フ ト ス マ HAF ン ス SSD 200GB/枚~ 数TBまでのDBに最適 1.6TB/枚 数TB以上のDBおよび 超高速性を求める場合 に最適 DB容量 © Hitachi, Ltd. 2013. All rights reserved.
  34. 34. 5.SSDとOracleの相性 © Hitachi, Ltd. 2013. All rights reserved.
  35. 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
  36. 36. 5-2. 高速化したい業務は何? Oracle DBで高速化したい業務は何か? Oracleから見た I/Oパターン オンライン バッチ処理 分析系業務 ランダムI/O 多い 普通 少ない シーケンシャルI/O あまりない 普通 多い より高速化の要望が強い シーケンシャルリードのSQLを多く擁するバッチ処理や 分析系業務ではSSDの効果をどう考えればよいか? © Hitachi, Ltd. 2013. All rights reserved. 35
  37. 37. 5-3. 分析系SQLのI/Oパターンは? ◆シーケンシャルリードの SQL発行でストレージ側 (SSD)が受け取るI/Oパター ンを調べてみた。 ◆ストレージ側が受け取るI/Oパターン(分析系のSQL22個) 約6~7割がランダムI/O シーケンシャルI/O ランダムI/O [分] その理由は Oracle Parallel Query © Hitachi, Ltd. 2013. All rights reserved. 36
  38. 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
  39. 39. 5-5. パラレルクエリ+ASMでI/Oはどうなる? SQL発行 Parallel Query 多重 DBサーバ パラレル化 SQL発行 FC 分割 ASM FC DBサーバ FC パラレル化 FC FC P P FC P FC P P Ctrl0 分割 RAID P P P P P P P P P LU LU LU LU LU LU LU LU Oracle ASM RAID5 LU LU LU Oracle ASM LU LU RAID5 LU P Ctrl1 LU 分割 P Ctrl1 Ctrl0 LU Drive(HDD/SSD) FC RAID5 RAID5 1ドライブに対する I/O要求が多重 /並列化し、 ランダムI/Oとなる。 HUS130 #0 #0 HUS130 © Hitachi, Ltd. 2013. All rights reserved. 38
  40. 40. 5-6. SSDとOracleの相性はとてもいい。 ランダムI/OではSSDは抜群の効果 だから Oracle DBが発行するI/Oパターンと SSDは、業務の性質によらず相性が良い。 (もちろん、I/O負荷が高いもの) © Hitachi, Ltd. 2013. All rights reserved. 39
  41. 41. 6.RAC on SSD分析系SQLでの検証 © Hitachi, Ltd. 2013. All rights reserved.
  42. 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.
  43. 43. 6-2. HDDとSSDでの比較 帯域とSQL処理時間を測定 I/Oが多く出る分析系DB処理を模擬した SQLを使用 I/Oスループット及びSQLのレスポンスタイム の合計を測定 PCサーバ+HDD搭載ストレージと比較。 比較機器 【サーバ】 機種:HA8000/RS210-hHM CPU:E5-2690×2 メモリー:96GB I/O: 6Gbps/port 4本(2本/台 × 2) 【ストレージ】 機種:BR1200×2台 HDD: 146GB (15,000rpm) × 16 (7D+1P × 2) ■ I/O帯域 (GB/s) ■ SQL処理時間 11.00 12 09:00 8.44 10 (mm:ss) 07:53 07:30 8 06:00 6 04:30 4 03:00 2 0.75 01:30 0 HDD(SQL性能) 01:19 SSD(SQL性能) SSD(dd性能) HDD 00:41 SSD(1ノード) SSD(2ノード) ※dd性能とは、OSのddコマンドにてI/O性能を測定した結果 I/O帯域、レスポンスとも、10倍以上は想定通り。 © Hitachi, Ltd. 2013. All rights reserved.
  44. 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. 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
  46. 46. 6-5. リプレースが必要な古いUNIX環境との比較 2005年頃のシステムと比較してみた 比較機器 2005年当時のUnixサーバと比較 【サーバ】 機種:HA8500/310 CPU:Itanium 2 1.30GHz 1core×2 メモリー:2GB I/O: FC-2Gbps/port 2本 【ストレージ】 機種:SANRISE9570 HDD: 146GB (15,000rpm) × 12 測定ケース 旧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倍高速 CPU性能の差(24倍)以上の改善があることが分かった。 © Hitachi, Ltd. 2013. All rights reserved.
  47. 47. 7.信頼性に関する検証 © Hitachi, Ltd. 2013. All rights reserved. 46
  48. 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. 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.
  50. 50. 7-3. 稼動確認と性能比較 ケーブル抜いても停止すること無く連続稼働  それぞれの場合のSQLレスポンスとI/Oスループットの推移 正常時 FCケーブル16本 最大Read帯域: MB/sec SQL 実行時間 : 13分59秒 ①FCパス1本抜線 FCケーブル15本 最大Read帯域: MB/sec SQL 実行時間: 14分14秒 ②I/Oドロワ片系障害 FCケーブル8本相当 最大Read帯域: MB/sec SQL 実行時間: 14分31秒 SQL実行時間に殆ど影響無し!帯域確保されているからこそ。 © Hitachi, Ltd. 2013. All rights reserved.
  51. 51. まとめ © Hitachi, Ltd. 2013. All rights reserved.
  52. 52. まとめ 高速化と信頼性を両立するDB高速化ソリューション  その鍵はSSD HDD⇒SSDだけでは効果薄、通り道のネックを全部排除してSSDを生かす。 OracleDBのI/Oパターンは、SSDと相性がよい。 オンラインのみならず、バッチ、分析処理の大幅な高速化を実現できる  オープンで信頼性の高いプラットフォーム オープンIAサーバを利用した通常のRAC構成。AP移行も安心。 通常のLinux/Windowsサーバ。バックアップ、監視ソフトも問題なし。 高信頼サーバ/ストレージと、あらゆる箇所の冗長構成でサービスを止めない。  実証された構成、でも柔軟な選択 構成選定やH/Wチューニングの手間をかけずに性能と信頼性を両立できる。 サーバCPU、メモリ量、SSD容量を処理内容に応じて調整できる。 Oracleライセンス/サポートを抑えられる様に少ないコア数でも構成できる。 © Hitachi, Ltd. 2013. All rights reserved. 51
  53. 53. 他社商品名、商標等の引用に関する表示 • OracleとJavaは,Oracle Corporation 及びその子会社,関連会社の米国及びその他の国における登録商標で す。 • Intel Xeonは,アメリカ合衆国およびその他の国におけるIntel Corporationの商標です。 • Linuxは,Linus Torvalds氏の日本およびその他の国における登録商標または商標です。 • その他、記載の会社名、製品名は、それぞれの会社の商標または登録商標です。 • 製品の改良により予告なく記載されている仕様が変更になることがあります。 © Hitachi, Ltd. 2013. All rights reserved. 52
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×