[db tech showcase Tokyo 2016] D24: データベース環境における検証結果から理解する失敗しないフラッシュ活用法第三章～データベースアプリケーションに影響なしに、オンライン運用を続けるには～ by ピュア・ストレージ・ジャパン株式会社岩本知博

1| © 2016 Pure Storage Inc.
データベース環境における検証結果から理解する
失敗しないフラッシュ活⽤法第三章
〜データベースアプリケーションに影響なしに
オンライン運⽤を続けるには〜
ピュア・ストレージ・ジャパン株式会社
岩本知博

本⽇の内容
5 分で分かる Pure Storage①
OLTP ワークロードと Pure Storage②
バックアップと Pure Storage③
まとめ④

5 分で分かる？ PURE STORAGE

DB 環境で⼈気の Pure Storage
Oracle MSFT -
SQL Server
Epic &
EMR
SAP Exchange NoSQL,
Mongo,
MySQL
IBM SAS VMware Hyper-V XenServer OpenStack View Citrix
Existing Business New Business
DB / Apps
44 %
VSI
32%
VDI
24%

DB 環境で⼈気の理由
1 2 3
⼀貫して⾼い性能を維持
障害 / メンテナンス時の
性能劣化なし
IOPS と
帯域幅の両⽴

1 2 3
性能影響なし
IOPS と
帯域幅の両⽴
オールフラッシュであれば、⼩サイズ（4KB 〜 8KB）での IOPS は⾼くて
当たり前。Pure Storage であれば、可変⻑ブロックにより⾼い帯域幅も実現。

IOPS と帯域幅の両⽴
0
100,000
200,000
300,000
400,000
500,000
600,000
700,000
800,000
900,000
1,000,000
IOPS
4KB に最適化された
フラッシュ製品
4KB 8KB 16KB 32KB 64KB
IOPS
帯域幅
バッチ処理や RMAN バックアップ
を速くするには帯域幅が必要

Pure Storage の I/O 性能
モデル名 //m10 //m20 //m50 //m70
パフォーマンス • 最⼤ 100,000 IOPS（32K）
• 平均遅延 1 ミリ秒未満
• 最⼤ 3GB/s の帯域幅
• 最⼤ 150,000 IOPS（32K）
• 最⼤ 220,000 IOPS（32K）
• 最⼤ 300,000 IOPS（32K）
容量
※ 削減率 5 倍を想定
• 物理容量 5 〜 10TB
• 有効容量 12.5 〜 25TB ※
• ベースシャーシ構成
• 物理容量 5 〜 40TB
• 有効容量 15 〜 120TB ※
• ベースシャーシ構成
• 物理容量 30 〜 88TB
• 有効容量 60 〜 192TB ※
• ベースシャーシ + 拡張シェルフ
• 物理容量 44 〜 136TB
• 有効容量 132 〜 408TB ※
• ベースシャーシ + 拡張シェルフ
接続仕様 • 4 x 16Gbps FC
or 10GbE iSCSI
• FC、iSCSI 選択
• 2 x 1GbE レプリケーション
• 2 x 1GbE マネージメント
• 8 〜 12 x 8Gbps FC
or 10GbE iSCSI
• FC、iSCSI 混在可
• 2 x 10GbE レプリケーション
• 8 〜 12 x 8Gbps / 16Gbps FC
or 10GbE iSCSI
• 2 x10GbE レプリケーション
• 8 〜 12 x 8Gbps / 16Gbps FC
or 10GbE iSCSI
• 2 x10GbE レプリケーション
物理仕様 • 3U
• 610W（100 or 200V 電源）
• 47.6kg
• 3U
• 742W（100 or 200V 電源）
• 49.9kg
• 3U +
拡張シェルフあたり 2U（最⼤7U）
• 1007 〜 1447W（200V 電源）
• 49.9kg +
拡張シェルフあたり 19.9kg
• 5U +
拡張シェルフあたり 2U（最⼤11U）
• 1439 〜 2099（200V 電源）
• 70.7Kg +
拡張シェルフあたり 19.9kg
8

1 2 3
性能影響なし
IOPS と
帯域幅の両⽴
SSD 障害時の影響を最⼩化するために、SSD に最適なデータ配置を実装（RAID-
3D）。SSD 復旧時もリビルドが発⽣しないため性能影響なし。
メンテナンス時の影響を最⼩化するために、Primary - Secondary コントローラ
アーキテクチャに最適化。切替時間も数ミリ秒〜数秒で完了。

障害時の性能劣化なし
FC ケーブル抜線
NVRAM 障害 SSD ⼆重障害
SSD 単⼀障害

障害時の性能劣化なし
コントローラ障害
OS アップグレード

Demonstration

環境 @ Tokyo Office
iSCSI スイッチ
10GbE iSCSI x 4
DB サーバ
DB クライアント
DB サーバ
CPU：8コア
メモリ：20GB
Buffer Cache：10GB
Pure Storage
FlashArray //m20
5TB モデル
CPU：8コア
メモリ：20GB
Buffer Cache：10GBRAC
Swingbench
1TB
Order Entry スキーマ
約 1TB

デモの内容
SSD モジュール NVRAM
（書き込みキャッシュ）
//m コントローラ

1 2 3
HDD（SAS）並の GB 単価
cMLC / TLC
Pure Storage は GB 単価に優れる cMLC / TLC SSD を既に採⽤。今後の技術進
化により⼤容量化が期待できるのも cMLC / TLC である。
安価な SSD に対し、Pure Storage OS（Purity）独⾃のデータ書き込み、ガーベ
ッジコレクションで⻑寿命化を実現。
インライン
重複排除
インライン
圧縮

そのストレージは最新の SSD を使えるか
Source: http://www.storagereview.com/toshiba_px04s_enterprise_ssd_review

n SSD の寿命については、以下の計算式で定義されている
年 = （容量 x「P/E サイクル数」）/（1 ⽇あたりの書き込み数 x「WAF」）/ 365
n SSD の寿命に関わるキーワード → 次ページで解説
• P / E（プログラム / 消去）サイクル：書き込み耐久性
• P / E サイクルは SSD のスペックに依存
• WAF（Write Amplification Factor）：書き込み増幅量
• WAF はホストからの I/O ワークロード、ストレージ OS の書き込み⽅に依存
※ SSD の寿命は P / E サイクルはもちろん、WAF に⼤きく依存する
寿命の計算⽅法

デュアル SSD ⽅式のメリット
• スロットあたりの密度（容量、性能）を向上
• ⼤容量のフラッシュモジュールを
低コストで実現
ユーザから⾒れば SSD x 1 モジュール
• フラッシュモジュールの単⼀障害は、同⼀
RAID グループの 2 重障害にならない
（ストレージ OS で、別 RAID グループと
して管理）
→ SSD モジュール x 2 障害まで OK
SSD x 2 in 1 モジュール：P/E サイクルを 2 倍に
SSD

n 書き込みワークロードの違いにより、WAF は⼤きく変化する → 同じ SSD でも、
搭載するストレージの書き込みアーキテクチャによって WAF は⼤きく変化する →
ストレージの書き込みアーキテクチャによって SSD 寿命は⼤きく変化する
ストレージ OS と WAF（Write Amplification Factor）
% 18 18 % 18
1832101.8154
846352
1 .0 /
201

ストレージ OS と WAF（Write Amplification Factor）
% 18 18 % 18
1832101.8154
846352
1 .0 /
201
4KB 単位で書き込みするストレージでは WAF は “24.05”
になり、耐⽤期間（寿命）を “1”（相対値）とする
8KB 単位で書き込みするストレージでも WAF は “13.42”
になり、耐⽤期間（寿命）の向上は “1.16”（相対値）程度
MB 単位で書き込みすることで WAF は僅か “3.48” になり、
耐⽤期間（寿命）は “2.54”（相対値）倍に伸びる

n 年 = （容量 x「P/E サイクル数」）/（1 ⽇あたりの書き込み数 x「WAF」）/ 365
n 100,000 IOPS（8KB read 70% write 30%）の例
n （1.83TB x 14,000）/（0.44TB/day x 3.48）/ 365 = 45.88年
• 1.83TB：1 SSD モジュール（3D SSD）容量
• 14,000：P/E サイクル（3D SSD）
• 0.44TB/day：1 ⽇あたりの書き込み数
• 1 ⽇あたりの書き込み数 / 1 SSD モジュール（1.83TB）：0.44TB/day
• 19.28TB/day on 44 SSD モジュール（20 + 24）
• 100,000 IOPS 8KB read 70% write 30% = 234MB/sec
• 234MB/sec x 24h（86,400sec）= 19.28TB/day
• 3.48：WAF
Pure Storage による低コスト SSD の⻑寿命化

1 2 3
HDD（SAS）並の GB 単価
cMLC / TLC
Purity 独⾃のアーキテクチャにより、他社を圧倒する重複排除率、圧縮率を実現。
データ削減率が⾼いほど GB 単価も下がり、耐久性も向上。
インライン
重複排除
インライン
圧縮

HDD（SAS）並の価格を実現するには
データ削減率 3 〜 5 倍なら…
GB 単価は 1/3 〜 1/5
HDD 並の GB 単価を実現！
フラッシュは SAS より数倍⾼い
ココが重要

DB 環境のデータ削減率は 3 〜 5 倍の実績
削減率（圧縮x重複排除）
VSI VDIDB

検証結果：Pure Storage の圧倒的なデータ削減率
0.00
1.00
2.00
3.00
4.00
5.00
6.00
0
200
400
600
800
1000
1200
データ削減
機能なし
Pure Storage
//m シリーズ
A 社 B 社 C 社 D 社
データ削減率
DBサイズ（GB）
プレゼンテーションのみ

安⼼してくださいオーバーヘッドはありません
1.0
0.8
1.4
1.0
0.0
0.2
0.4
0.6
0.8
1.0
1.2
1.4
8KB Read 8KB Write
IOPS（相対値）
圧縮率 1 倍
圧縮率 4 倍
性能影響を考慮した⾯倒な検討事項なし
（ただでさえ⾼い性能が、更に向上します）

1 2 3
極めてシンプル
シンプルな
ストレージ設計
シンプルな
運⽤管理
容量 / 性能
拡張もシンプル

1 2 3
シンプルな
シンプルな
運⽤管理
容量 / 性能

シンプルなストレージ設計
+DG_DATA
LUN
Pure Storage
Controller : Primary
Controller : Secondary
RAID-3D
+DG_FRA
LUN
必要なもの
• LUN サイズ
• ホストとの接続（マルチパス）
不要になるもの
• HDD / LUN レイアウト
• RAID 設計
• 性能を引き出すための
複数 LUN 作成
• コントローラ縮退稼働の考慮
• etc

1 2 3
シンプルな
シンプルな
運⽤管理
容量 / 性能

シンプルな運⽤管理
CloudAssist
ユーザパートナー
Pure
Storage
Web ブラウザから管理 IP にアクセスし
性能、容量を確認（最⼤ 1 年）
クラウド上のデータから過去
（1 年以上前）の稼働状況および
将来の傾向予測を確認
PURE1 Manage
GUI 管理ツール

1 2 3
シンプルな
シンプルな
運⽤管理
容量 / 性能

RAID-3D
容量拡張がシンプル
group group
RAID-3D RAID-3D
group group
group group
group group
group group
group group
容量拡張：もちろんオンライン、更に性能影響なし
group group group group
group group
group group
group group
group group

容量拡張がシンプル：ケーブルを繋げるだけ
容量拡張：もちろんオンライン、更に性能影響なし
//m シャーシ
拡張シェルフ

性能拡張もシンプル：10 年以上使っていただくために
コントローラ
モジュール
2 HA コントローラ
m10 / m20 / m50 / m70
3 年ごとに、無償で最新の
コントローラをお届け！！
（Forever Flash プログラム）

サービスに影響なしでオンラインコントローラ交換
Pure Storage
m20 Controller : Primary
m20 Controller : Secondary m50 Controller
1. セカンダリを上位モデルのコントローラと⼊替
Pure Storage
m20 Controller : Secondary
2. コントローラのロールを切替 3. もう⽚⽅のコントローラも⼊替
Pure Storage
m50 Controller : Secondary

容量も性能も 3U で性能
ラックスペース & 消費電⼒
//m20
//m50
//m70
//m next…
性能
ラックスペース & 消費電⼒
Pure
Storage
A 社
フットプリント消費なし、データ再配置も不要

本⽇の内容
まとめ④

従来の OLTP 環境
Buffer Hit % ≒ 100%
アクセス範囲
性能
キャッシュヒット率が命⼤容量メモリを積めば安⼼？
…ではない！

メモリ上に
データがない
メモリ
サイズ不⾜
キャッシュにヒットしないケースは沢⼭ある…
メンテナンス後
遅くなる
メモリスロット
に空きがない
新製品への
アクセスが遅い
予測を超える
ピークがきた

OLTP 環境で使⽤される Oracle Database 機能
パーティション OLTP 表圧縮
• 表と索引のパーティション化
による、ヒット率の向上
• パーティション単位のメンテ
ナンスによる運⽤コスト削減
• メモリ使⽤量の節約による
ヒット率の向上
• ストレージ容量の節約
ヒット率を⾼めて性能向上！

OLTP 表圧縮
• メモリ使⽤量の節約による
ヒット率の向上
• ストレージ容量の節約
OLTP 環境で使⽤される Oracle Database 機能
パーティション
• 表と索引のパーティション化
による、ヒット率の向上
• パーティション単位のメンテ
ナンスによる運⽤コスト削減
ヒット率を⾼めて性能向上！

メモリ上に
データがない
メモリ
サイズ不⾜
遅くなる
に空きがない
新製品への
予測を超える
ピークがきた
✔ ✔
Oracle Database 機能により、ヒット率を⾼めて性能向上！

メモリ上に
データがない
メモリ
サイズ不⾜
Pure Storage であれば
キャッシュにヒットしなくても良い DB システムを実現できる！
遅くなる
に空きがない
新製品への
予測を超える
ピークがきた
✔ ✔
✔ ✔

ここで、よくある話
フラッシュは速いと⾔っても
CPU、メモリに⽐べれば
遅いよね？
オールフラッシュは IOPS 命！
100 万 IOPS 欲しい！
サーバサイドフラッシュ
ならもっと速い！

検証環境
FC スイッチ
8Gbps FC x 4
DB サーバ
DB クライアント
DB サーバ
CPU：8コア
メモリ：48GB
Buffer Cache：10GB
Pure Storage
FlashArray //m20
10TB モデル
CPU：8コア
メモリ：48GB
Buffer Cache：10GBRAC

Pure Storage
検証環境
DB #1
1.5 TB
DB #2
1.5TB
LUN
ASM diskgroup
パーティション ON パーティション OFF
DB #2
1.5 TB
LUN
ASM diskgroup
SSD x 40（10TB）

LUN
Pure Storage
【ご参考】本環境でのデータ削減率
DB #2
1.5TB
LUN
ASM diskgroup
パーティション ON パーティション OFF
DB #2
1.5 TB
ASM diskgroup
SSD x 40（10TB）
185
GB
160
GB
DB #1
1.5 TB削減率
8:1
削減率
9:1

n パーティション ON / OFF ともに、キャッシュミスが多発してもヒット率が
⾼い性能と同等であることを確認
OLTP ワークロード：中負荷
0.0
2.5
5.0
7.5
10.0
12.5
15.0
17.5
20.0
22.5
25.0
0
100
200
300
400
500
600
700
800
900
1,000
5GB 10GB 15GB 20GB 25GB 30GB 35GB 40GB 45GB 50GB
DBResponseTime(ms)
DBTransactions/sec
Working Set Size (GB)
TPS: ON TPS: OFF RESP: ON RESP: OFF
0
10
20
30
40
50
60
70
80
90
100
DBServerCPUUtilization(%)
CPU node 1: ON CPU node 2: ON
CPU node 1: OFF CPU node 2: OFF

ご参考
n SQL を処理するのは CPU（I/O ベンチマークツールは⼤きく異なる）
n フラッシュで I/O 待ちを減らし、CPU を使う時間を⻑くする
n ボトルネックは、ストレージ I/O からDB サーバ CPU に
n IOPS より latency が重視
I/O系待機DB CPU DB CPU I/O系待機
I/O系
待機
DB CPU DB CPU
I/O系
待機
I/O系
待機
DB CPU DB CPU
I/O系
待機
HDD 環境
AFA 環境

n パーティション OFF の場合、Oracle レイヤでボトルネックが発⽣し、性能
が頭打ち
OLTP ワークロード：⾼負荷
0.0
20.0
40.0
60.0
80.0
100.0
120.0
140.0
160.0
180.0
200.0
220.0
0
300
600
900
1,200
1,500
1,800
2,100
2,400
2,700
3,000
3,300
DBResponseTime(ms)
DBTransactions/sec
0
10
20
30
40
50
60
70
80
90
100

Oracle ボトルネック
パーティション ON / OFF による影響
ON：WSS = 5GB
ON：WSS = 50GB
OFF：WSS = 5GB
OFF：WSS = 50GB

n パーティション OFF の場合、Oracle レイヤでボトルネックが発⽣し、性能
が頭打ち
OLTP ワークロード：⾼負荷
0.0
20.0
40.0
60.0
80.0
100.0
120.0
140.0
160.0
180.0
200.0
220.0
0
300
600
900
1,200
1,500
1,800
2,100
2,400
2,700
3,000
3,300
DBResponseTime(ms)
DBTransactions/sec
0
10
20
30
40
50
60
70
80
90
100
16 CPU 使い切っているときの
Pure Storage の I/O 統計は？

Pure Storage：I/O 統計

Pure Storage：I/O 統計
11,160 IOPS

Oracle Database：AWR レポート

本⽇の内容
まとめ④

Pure Storage のスナップショット
• DBサイズに関わらず⼀瞬でバックア
ップ / リストア
• メタデータをコピーするだけ（デ
ータ本体はそのまま）
• バックアップ領域の容量も最⼩限
（変更分のみ）
• バックアップモードへの移⾏が必要
Oracle Database の RMAN
• Oracle がほぼ⾃動化してくれるので、
⾮常にシンプルで、DBA としては使
い易い
• 静⽌点の考慮も不要
• バックアップ領域の削減や差分バッ
クアップを考え出すと…
Oracle のオンラインバックアップを考える

Pure Storage のスナップショット
• DBサイズに関わらず⼀瞬でバックア
ップ / リストア
• メタデータをコピーするだけ（デ
ータ本体はそのまま）
• バックアップ領域の容量も最⼩限
（変更分のみ）
• バックアップモードへの移⾏が必要
Oracle Database の RMAN
• Oracle がほぼ⾃動化してくれるので、
⾮常にシンプルで、DBA としては使
い易い
• 静⽌点の考慮も不要
• バックアップ領域の削減や差分バッ
クアップを考え出すと…
スナップショットによるバックアップ

n Good News！：Oracle Database 12c からバックアップモードへの移⾏が不要に！
• MOD ID 604683.1 の内容を準拠する必要あり
→ Pure Storage のスナップショットはもちろん準拠しています
• Database crash consistent at the point of the snapshot
• Write ordering is preserved for each file within a snapshot
• Snapshot stores the time at which a snapshot is completed
n ご参考
• MOS ID 604683.1：Supported Backup, Restore and Recovery Operations
using Third Party Snapshot Technologies
• SR 3-12340033401 : Supported Oracle Database version of third party
Snapshot without backup mode (Doc ID 604683.1)
※ My Oracle Support（MOS）のアカウントが必要
スナップショットによるバックアップ

n スクリプトの作成や連携ツールの
インストールが不要に！
スナップショットによる
バックアップ

RMAN の検討事項
RMAN バックアップ
⽇⽉⽕⽔ …
フル差分差分差分
RMAN による圧縮の検討
• Basic
• Low / Medium / High
（EE オプション）
バックアップ⾼速化機能の検討
• ⾼速増分バックアップ（EE）
• マルチチャネル、マルチセクション
による並列化（EE）
リカバリ時間短縮のための検討
• 増分更新バックアップの検討

Pure Storage で RMAN 効率化
フルバックアップを差分バックアップに
RMAN バックアップ
（FULL）
⽉⽕⽔ …
容量増加は差分だけ
• インライン重複排除が効果を発揮
（削減率を考慮するとイメージコピー
がオススメ）
シンプルな RMAN 運⽤
• リストアは 1 回だけ
• 差分増分、累積増分、増分更新バック
アップ等の検討不要
• RMAN 圧縮の検討不要

【検証結果】RMAN フルバックアップ：1.5TB DB
0:21:16
0:25:03
0:32:52
0:48:13
0:12:37
0:13:41
0:17:38
1:29:22
0:00:00 0:14:24 0:28:48 0:43:12 0:57:36 1:12:00 1:26:24 1:40:48
8 channel
4 channel
2 channel
1 channel
8 channel
4 channel
2 channel
1 channel
ImageCopyBackupSet
Elapsed Time (hh:mm:ss)

【検証結果】RMAN フルバックアップ：1 チャネル時
BackupSetImageCopy
帯域幅 600 MB/sec 平均 I/O サイズ：512 KB
イメージコピー：シリアル処理でもそこそこの性能

本⽇の内容
まとめ④

1 2 3
⼀貫して⾼い
性能を維持
HDD（SAS）並の
GB 単価
極めて
シンプル
OLTP ワークロード
キャッシュヒット / ミス
からの解放
バックアップ
スナップショットはもちろん
RMAN 効率化と⾼速化

Pure Storage //m10
容量から考える DB 統合
最⼩構成
有効容量：9 〜 15 TB
（物理容量：5TB）
7 万 IOPS 〜 10 万 IOPS
RAID-3D
512G
512G
1TB
2TB
1TB
1,000 IOPS 5,000 IOPS 10,000 IOPS
2,000 IOPS 5,000 IOPS → 合計 23,000 IOPS / 7 万 IOPS 〜 10 万 IOPS
→ 合計 5 TB / 9 〜 15 TB

DB on Pure Storage シリーズはじめました
https://www.youtube.com/channel/UCDmM7wvEXQjoNpBpFM_mCWg
Pure Storage Japan YouTube 検索

つづく

More Related Content

What's hot (20)

Viewers also liked (20)

More from Insight Technology, Inc. (20)