Mais conteúdo relacionado Semelhante a [db tech showcase Tokyo 2016] D24: データベース環境における検証結果から理解する失敗しないフラッシュ活用法 第三章 ~データベースアプリケーションに影響なしに、オンライン運用を続けるには~ by ピュア・ストレージ・ジャパン株式会社 岩本 知博 (20) Mais de Insight Technology, Inc. (20) [db tech showcase Tokyo 2016] D24: データベース環境における検証結果から理解する失敗しないフラッシュ活用法 第三章 ~データベースアプリケーションに影響なしに、オンライン運用を続けるには~ by ピュア・ストレージ・ジャパン株式会社 岩本 知博1. 1| © 2016 Pure Storage Inc.
データベース環境における検証結果から理解する
失敗しないフラッシュ活⽤法 第三章
〜 データベース アプリケーションに影響なしに
オンライン運⽤を続けるには 〜
ピュア・ストレージ・ジャパン株式会社
岩本 知博
2. 2| © 2016 Pure Storage Inc.
本⽇の内容
5 分で分かる Pure Storage①
OLTP ワークロードと Pure Storage②
バックアップと Pure Storage③
まとめ④
3. 3| © 2016 Pure Storage Inc.
5 分で分かる? PURE STORAGE
4. 4| © 2016 Pure Storage Inc.
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%
5. 5| © 2016 Pure Storage Inc.
DB 環境で⼈気の理由
1 2 3
⼀貫して⾼い性能を維持
障害 / メンテナンス時の
性能劣化なし
IOPS と
帯域幅の両⽴
6. 6| © 2016 Pure Storage Inc.
DB 環境で⼈気の理由
1 2 3
⼀貫して⾼い性能を維持
障害 / メンテナンス時の
性能影響なし
IOPS と
帯域幅の両⽴
オール フラッシュであれば、⼩サイズ(4KB 〜 8KB)での IOPS は⾼くて
当たり前。Pure Storage であれば、可変⻑ブロックにより⾼い帯域幅も実現。
7. 7| © 2016 Pure Storage Inc.
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 バックアップ
を速くするには 帯域幅 が必要
8. 8| © 2016 Pure Storage Inc.
Pure Storage の I/O 性能
モデル名 //m10 //m20 //m50 //m70
パフォーマンス • 最⼤ 100,000 IOPS(32K)
• 平均遅延 1 ミリ秒未満
• 最⼤ 3GB/s の帯域幅
• 最⼤ 150,000 IOPS(32K)
• 平均遅延 1 ミリ秒未満
• 最⼤ 5GB/s の帯域幅
• 最⼤ 220,000 IOPS(32K)
• 平均遅延 1 ミリ秒未満
• 最⼤ 7GB/s の帯域幅
• 最⼤ 300,000 IOPS(32K)
• 平均遅延 1 ミリ秒未満
• 最⼤ 9GB/s の帯域幅
容量
※ 削減率 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 レプリケーション
• 2 x 1GbE マネージメント
• 8 〜 12 x 8Gbps / 16Gbps FC
or 10GbE iSCSI
• FC、iSCSI 混在可
• 2 x10GbE レプリケーション
• 2 x 1GbE マネージメント
• 8 〜 12 x 8Gbps / 16Gbps FC
or 10GbE iSCSI
• FC、iSCSI 混在可
• 2 x10GbE レプリケーション
• 2 x 1GbE マネージメント
物理仕様 • 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
9. 9| © 2016 Pure Storage Inc.
DB 環境で⼈気の理由
1 2 3
⼀貫して⾼い性能を維持
障害 / メンテナンス時の
性能影響なし
IOPS と
帯域幅の両⽴
SSD 障害時の影響を最⼩化するために、SSD に最適なデータ配置を実装(RAID-
3D)。SSD 復旧時もリビルドが発⽣しないため性能影響なし。
メンテナンス時の影響を最⼩化するために、Primary - Secondary コントローラ
アーキテクチャに最適化。切替時間も数ミリ秒〜数秒で完了。
10. 10| © 2016 Pure Storage Inc.
障害時の性能劣化なし
FC ケーブル抜線
NVRAM 障害 SSD ⼆重障害
SSD 単⼀障害
11. 11| © 2016 Pure Storage Inc.
障害時の性能劣化なし
コントローラ障害
OS アップグレード
13. 13| © 2016 Pure Storage Inc.
環境 @ 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
14. 14| © 2016 Pure Storage Inc.
デモの内容
SSD モジュール NVRAM
(書き込みキャッシュ)
//m コントローラ
15. 15| © 2016 Pure Storage Inc.
DB 環境で⼈気の理由
1 2 3
HDD(SAS)並の GB 単価
cMLC / TLC
Pure Storage は GB 単価に優れる cMLC / TLC SSD を既に採⽤。今後の技術進
化により⼤容量化が期待できるのも cMLC / TLC である。
安価な SSD に対し、Pure Storage OS(Purity)独⾃のデータ書き込み、ガーベ
ッジ コレクションで⻑寿命化を実現。
インライン
重複排除
インライン
圧縮
16. 16| © 2016 Pure Storage Inc.
そのストレージは最新の SSD を使えるか
Source: http://www.storagereview.com/toshiba_px04s_enterprise_ssd_review
17. 17| © 2016 Pure Storage Inc.
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 に⼤きく依存する
寿命の計算⽅法
18. 18| © 2016 Pure Storage Inc.
デュアル SSD ⽅式のメリット
• スロットあたりの密度(容量、性能)を向上
• ⼤容量のフラッシュ モジュールを
低コストで実現
ユーザから⾒れば SSD x 1 モジュール
• フラッシュ モジュールの単⼀障害は、同⼀
RAID グループの 2 重障害にならない
(ストレージ OS で、別 RAID グループと
して管理)
→ SSD モジュール x 2 障害まで OK
SSD x 2 in 1 モジュール:P/E サイクルを 2 倍に
SSD
19. 19| © 2016 Pure Storage Inc.
n 書き込みワークロードの違いにより、WAF は⼤きく変化する → 同じ SSD でも、
搭載するストレージの書き込みアーキテクチャによって WAF は⼤きく変化する →
ストレージの書き込みアーキテクチャによって SSD 寿命は⼤きく変化する
ストレージ OS と WAF(Write Amplification Factor)
% 18 18 % 18
1832101.8154
846352
1 .0 /
201
20. 20| © 2016 Pure Storage Inc.
ストレージ 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”(相対値)倍に伸びる
21. 21| © 2016 Pure Storage Inc.
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 の⻑寿命化
22. 22| © 2016 Pure Storage Inc.
DB 環境で⼈気の理由
1 2 3
HDD(SAS)並の GB 単価
cMLC / TLC
Purity 独⾃のアーキテクチャにより、他社を圧倒する重複排除率、圧縮率を実現。
データ削減率が⾼いほど GB 単価も下がり、耐久性も向上。
インライン
重複排除
インライン
圧縮
23. 23| © 2016 Pure Storage Inc.
HDD(SAS)並の価格を実現するには
データ削減率 3 〜 5 倍なら…
GB 単価は 1/3 〜 1/5
HDD 並の GB 単価を実現!
フラッシュは SAS より数倍⾼い
ココが重要
24. 24| © 2016 Pure Storage Inc.
DB 環境のデータ削減率は 3 〜 5 倍の実績
削減率(圧縮x重複排除)
VSI VDIDB
25. 25| © 2016 Pure Storage Inc.
検証結果: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)
プレゼンテーションのみ
26. 26| © 2016 Pure Storage Inc.
安⼼してください オーバーヘッドはありません
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 倍
性能影響を考慮した⾯倒な検討事項なし
(ただでさえ⾼い性能が、更に向上します)
27. 27| © 2016 Pure Storage Inc.
DB 環境で⼈気の理由
1 2 3
極めてシンプル
シンプルな
ストレージ設計
シンプルな
運⽤管理
容量 / 性能
拡張もシンプル
28. 28| © 2016 Pure Storage Inc.
DB 環境で⼈気の理由
1 2 3
極めてシンプル
シンプルな
ストレージ設計
シンプルな
運⽤管理
容量 / 性能
拡張もシンプル
29. 29| © 2016 Pure Storage Inc.
シンプルなストレージ設計
+DG_DATA
LUN
Pure Storage
Controller : Primary
Controller : Secondary
RAID-3D
+DG_FRA
LUN
必要なもの
• LUN サイズ
• ホストとの接続(マルチパス)
不要になるもの
• HDD / LUN レイアウト
• RAID 設計
• 性能を引き出すための
複数 LUN 作成
• コントローラ縮退稼働の考慮
• etc
30. 30| © 2016 Pure Storage Inc.
DB 環境で⼈気の理由
1 2 3
極めてシンプル
シンプルな
ストレージ設計
シンプルな
運⽤管理
容量 / 性能
拡張もシンプル
31. 31| © 2016 Pure Storage Inc.
シンプルな運⽤管理
CloudAssist
ユーザ パートナー
Pure
Storage
Web ブラウザから管理 IP にアクセスし
性能、容量を確認(最⼤ 1 年)
クラウド上のデータから過去
(1 年以上前)の稼働状況および
将来の傾向予測を確認
PURE1 Manage
GUI 管理ツール
34. 34| © 2016 Pure Storage Inc.
DB 環境で⼈気の理由
1 2 3
極めてシンプル
シンプルな
ストレージ設計
シンプルな
運⽤管理
容量 / 性能
拡張もシンプル
35. 35| © 2016 Pure Storage Inc.
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
36. 36| © 2016 Pure Storage Inc.
容量拡張がシンプル:ケーブルを繋げるだけ
容量拡張:もちろんオンライン、更に性能影響なし
//m シャーシ
拡張シェルフ
38. 38| © 2016 Pure Storage Inc.
性能拡張もシンプル:10 年以上使っていただくために
コントローラ
モジュール
2 HA コントローラ
m10 / m20 / m50 / m70
3 年ごとに、無償 で最新の
コントローラをお届け!!
(Forever Flash プログラム)
39. 39| © 2016 Pure Storage Inc.
サービスに影響なしで オンライン コントローラ交換
Pure Storage
m20 Controller : Primary
m20 Controller : Secondary m50 Controller
1. セカンダリを上位モデルのコントローラと⼊替
Pure Storage
m20 Controller : Secondary
m50 Controller : Primary
2. コントローラのロールを切替 3. もう⽚⽅のコントローラも⼊替
Pure Storage
m50 Controller : Primary
m50 Controller : Secondary
41. 41| © 2016 Pure Storage Inc.
容量も性能も 3U で性能
ラックスペース & 消費電⼒
//m20
//m50
//m70
//m next…
性能
ラックスペース & 消費電⼒
Pure
Storage
A 社
フットプリント消費なし、データ再配置も不要
42. 42| © 2016 Pure Storage Inc.
本⽇の内容
5 分で分かる Pure Storage①
OLTP ワークロードと Pure Storage②
バックアップと Pure Storage③
まとめ④
43. 43| © 2016 Pure Storage Inc.
従来の OLTP 環境
Buffer Hit % ≒ 100%
アクセス範囲
性能
キャッシュ ヒット率が命 ⼤容量メモリを積めば安⼼?
…ではない!
44. 44| © 2016 Pure Storage Inc.
メモリ上に
データがない
メモリ
サイズ不⾜
従来の OLTP 環境
キャッシュにヒットしないケースは沢⼭ある…
メンテナンス後
遅くなる
メモリ スロット
に空きがない
新製品への
アクセスが遅い
予測を超える
ピークがきた
45. 45| © 2016 Pure Storage Inc.
OLTP 環境で使⽤される Oracle Database 機能
パーティション OLTP 表圧縮
• 表と索引のパーティション化
による、ヒット率の向上
• パーティション単位のメンテ
ナンスによる運⽤コスト削減
• メモリ使⽤量の節約による
ヒット率の向上
• ストレージ容量の節約
ヒット率を⾼めて性能向上!
46. 46| © 2016 Pure Storage Inc.
OLTP 表圧縮
• メモリ使⽤量の節約による
ヒット率の向上
• ストレージ容量の節約
OLTP 環境で使⽤される Oracle Database 機能
パーティション
• 表と索引のパーティション化
による、ヒット率の向上
• パーティション単位のメンテ
ナンスによる運⽤コスト削減
ヒット率を⾼めて性能向上!
47. 47| © 2016 Pure Storage Inc.
メモリ上に
データがない
メモリ
サイズ不⾜
従来の OLTP 環境
メンテナンス後
遅くなる
メモリ スロット
に空きがない
新製品への
アクセスが遅い
予測を超える
ピークがきた
✔ ✔
Oracle Database 機能により、ヒット率を⾼めて性能向上!
48. 48| © 2016 Pure Storage Inc.
メモリ上に
データがない
メモリ
サイズ不⾜
Pure Storage であれば
キャッシュにヒットしなくても良い DB システムを実現できる!
メンテナンス後
遅くなる
メモリ スロット
に空きがない
新製品への
アクセスが遅い
予測を超える
ピークがきた
✔ ✔
✔ ✔
49. 49| © 2016 Pure Storage Inc.
ここで、よくある話
フラッシュは速いと⾔っても
CPU、メモリに⽐べれば
遅いよね?
オールフラッシュは IOPS 命!
100 万 IOPS 欲しい!
サーバ サイド フラッシュ
ならもっと速い!
50. 50| © 2016 Pure Storage Inc.
検証環境
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
51. 51| © 2016 Pure Storage Inc.
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)
52. 52| © 2016 Pure Storage Inc.
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
53. 53| © 2016 Pure Storage Inc.
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
5GB 10GB 15GB 20GB 25GB 30GB 35GB 40GB 45GB 50GB
DBServerCPUUtilization(%)
Working Set Size (GB)
CPU node 1: ON CPU node 2: ON
CPU node 1: OFF CPU node 2: OFF
54. 54| © 2016 Pure Storage Inc.
ご参考
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 環境
55. 55| © 2016 Pure Storage Inc.
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
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
5GB 10GB 15GB 20GB 25GB 30GB 35GB 40GB 45GB 50GB
DBServerCPUUtilization(%)
Working Set Size (GB)
CPU node 1: ON CPU node 2: ON
CPU node 1: OFF CPU node 2: OFF
56. 56| © 2016 Pure Storage Inc.
Oracle ボトルネック
パーティション ON / OFF による影響
ON:WSS = 5GB
ON:WSS = 50GB
OFF:WSS = 5GB
OFF:WSS = 50GB
57. 57| © 2016 Pure Storage Inc.
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
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
5GB 10GB 15GB 20GB 25GB 30GB 35GB 40GB 45GB 50GB
DBServerCPUUtilization(%)
Working Set Size (GB)
CPU node 1: ON CPU node 2: ON
CPU node 1: OFF CPU node 2: OFF
16 CPU 使い切っているときの
Pure Storage の I/O 統計は?
58. 58| © 2016 Pure Storage Inc.
Pure Storage:I/O 統計
59. 59| © 2016 Pure Storage Inc.
Pure Storage:I/O 統計
11,160 IOPS
60. 60| © 2016 Pure Storage Inc.
Oracle Database:AWR レポート
61. 61| © 2016 Pure Storage Inc.
本⽇の内容
5 分で分かる Pure Storage①
OLTP ワークロードと Pure Storage②
バックアップと Pure Storage③
まとめ④
62. 62| © 2016 Pure Storage Inc.
Pure Storage のスナップショット
• DBサイズに関わらず⼀瞬でバックア
ップ / リストア
• メタデータをコピーするだけ(デ
ータ本体はそのまま)
• バックアップ領域の容量も最⼩限
(変更分のみ)
• バック アップ モードへの移⾏が必要
Oracle Database の RMAN
• Oracle がほぼ⾃動化してくれるので、
⾮常にシンプルで、DBA としては使
い易い
• 静⽌点の考慮も不要
• バックアップ領域の削減や差分バッ
クアップを考え出すと…
Oracle のオンライン バックアップを考える
63. 63| © 2016 Pure Storage Inc.
Pure Storage のスナップショット
• DBサイズに関わらず⼀瞬でバックア
ップ / リストア
• メタデータをコピーするだけ(デ
ータ本体はそのまま)
• バックアップ領域の容量も最⼩限
(変更分のみ)
• バック アップ モードへの移⾏が必要
Oracle Database の RMAN
• Oracle がほぼ⾃動化してくれるので、
⾮常にシンプルで、DBA としては使
い易い
• 静⽌点の考慮も不要
• バックアップ領域の削減や差分バッ
クアップを考え出すと…
スナップショットによるバックアップ
64. 64| © 2016 Pure Storage Inc.
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)のアカウントが必要
スナップショットによるバックアップ
65. 65| © 2016 Pure Storage Inc.
n スクリプトの作成や連携ツールの
インストールが不要に!
スナップショットによる
バックアップ
66. 66| © 2016 Pure Storage Inc.
RMAN の検討事項
RMAN バックアップ
⽇ ⽉ ⽕ ⽔ …
フル 差分 差分 差分
RMAN による圧縮の検討
• Basic
• Low / Medium / High
(EE オプション)
バックアップ⾼速化機能の検討
• ⾼速増分バックアップ(EE)
• マルチ チャネル、マルチ セクション
による並列化(EE)
リカバリ時間短縮のための検討
• 増分更新バックアップの検討
67. 67| © 2016 Pure Storage Inc.
Pure Storage で RMAN 効率化
フル バックアップを 差分 バックアップに
RMAN バックアップ
(FULL)
⽉ ⽕ ⽔ …
容量増加は差分だけ
• インライン重複排除が効果を発揮
(削減率を考慮するとイメージコピー
がオススメ)
シンプルな RMAN 運⽤
• リストアは 1 回だけ
• 差分増分、累積増分、増分更新バック
アップ等の検討不要
• RMAN 圧縮の検討不要
68. 68| © 2016 Pure Storage Inc.
【検証結果】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)
69. 69| © 2016 Pure Storage Inc.
【検証結果】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)
70. 70| © 2016 Pure Storage Inc.
【検証結果】RMAN フル バックアップ:1 チャネル時
BackupSetImageCopy
帯域幅 600 MB/sec 平均 I/O サイズ:512 KB
イメージ コピー:シリアル処理でもそこそこの性能
71. 71| © 2016 Pure Storage Inc.
本⽇の内容
5 分で分かる Pure Storage①
OLTP ワークロードと Pure Storage②
バックアップと Pure Storage③
まとめ④
72. 72| © 2016 Pure Storage Inc.
DB 環境で⼈気の理由
1 2 3
⼀貫して⾼い
性能を維持
HDD(SAS)並の
GB 単価
極めて
シンプル
OLTP ワークロード
キャッシュ ヒット / ミス
からの解放
バックアップ
スナップショットはもちろん
RMAN 効率化と⾼速化
73. 73| © 2016 Pure Storage Inc.
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
74. 74| © 2016 Pure Storage Inc.
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
75. 75| © 2016 Pure Storage Inc.
DB on Pure Storage シリーズはじめました
https://www.youtube.com/channel/UCDmM7wvEXQjoNpBpFM_mCWg
Pure Storage Japan YouTube 検索