[db tech showcase tokyo 2014] d24:...

データベース環境での検証結果から理解する失敗しないフラッシュ活用法

2014/11/12

ネットアップ株式会社パートナー SE 部

システムズエンジニア岩本知博

© 2014 NetApp, Inc. All rights reserved. NetApp Proprietary – Limited Use Only1

アジェンダ

はじめに：フラッシュデバイスの特徴

価格性能比から導かれる EF550 活用法 EF550 概要とキーポイント

各種ワークロードのおける EF550 ベンチマーク

Oracle Database 環境での EF550 活用法 Oracle Database 環境での EF550 性能検証

「OLTP 編」と「バッチ処理編」

考察：失敗しない EF550 活用法


© 2014 NetApp, Inc. All rights reserved. NetApp Confidential - Limited Use Only

はじめに

All Flash Array が DB 環境で活用される理由性能要件と容量要件のバランス


1.001.65

2.302.94

3.584.23

2.83

4.35

6.96

0

50,000

100,000

150,000

200,000

250,000

300,000

350,000

400,000

450,000

500,000

0.0

1.0

2.0

3.0

4.0

5.0

6.0

7.0

8.0

14TB 28TB 42TB 56TB 70TB 84TB 4.8TB 9.6TB 19.2TB

600GB

SAS x 24

600GB

SAS x 48

600GB

SAS x 72

600GB

SAS x 96

600GB

SAS x 120

600GB

SAS x 144

400GB

SSD x 12

800GB

SSD x 12

1.6TB

SSD x 12

I/O

性能（４

KB

Ran

dom

Read

IO

PS）

参考価格（相対値）

参考価格 IOPS


フラッシュデバイスの特徴

フラッシュの構造と write 処理

フラッシュは HDD のように直接上書きできない

write 処理は「ページ」単位（read 処理も同様）

ページが「未使用」状態でない場合は消去（erase）処理が必要

消去（erase）処理は「ブロック」単位


block

page

page

page

page

page

page

cell cell

Write Amplification


page 0

page 1

page 2

page 3

…

書き込み対象

1. キャッシュ領域（DRAM）にコピー

2. DRAM 上で新規データを挿入

3. データを消去

新規データ

NAND

DRAM

書き込み対象

Write Amplification


page 0

page 1

page 2

page 3

…

書き込み対象

1. キャッシュ領域（DRAM）にコピー

2. DRAM 上で新規データを挿入

3. データを消去

新規データ

NAND

DRAM

4. 新規データ反映済みのブロックを書き込み

書き込み対象

新規データ

フラッシュの特徴

Write Amplification 係数（WAF）：本来、書き込みたいデータ量に対して、実際の書き込み量がどれくらい増えるかを表す係数

WAF が高くなると write 性能が劣化し、書き込み回数の上限（寿命）に達し易くなる

WAF の増幅を改善する代表的な技術1. Wear Leveling

2. Over Provisioning（スペアブロック）

3. Garbage Collection


フラッシュの寿命を最大化する仕組みWear Leveling（摩耗平準化）


controller

指定されたアドレスを変換することでブロックの摩耗を平準化

特定ブロックに書き込みが集中

controller

Wear Leveling なし Wear Leveling あり

block

block

※ 色が濃いほど摩耗が激しい

Over Provisioning

全体容量の中から一定の割合を「スペアブロック」として確保するスペアブロックは「未使用」（消去済み）の状態

スペアブロックは実効容量にカウントされない

書き込み回数が少ないスペアブロックを優先して Wear Leveling で書き込むのが基本的なアルゴリズム

いかに新しいスペアブロックを確保するか

⇒ Garbage Collection


Garbage Collection


page 0

page 1

page 2

page 3

…

page 0

page 1

page 2

page 3

…

2. 有効ページがないブロックを消去1. 有効（使用中）ページを集約

有効（使用中）ページ無効ページ未使用

スペアブロックとして使用可能

フラッシュの特性まとめ

WAF の増幅を改善する代表的な技術 Wear Leveling

Over Provisioning（スペアブロック）

Garbage Collection

⇒ これらの技術を組み合わせることは非常に複雑で、write 性能、寿命の最大化は各フラッシュベンダ次第



NetApp の考え方

0

2

4

6

8

10

12

1 2 3 4 5 6 7 8 9 101112131415161718192021222324

レイテンシ

時間

アプローチの違いによるレイテンシへの影響（イメージ図）

アプローチA

アプローチB

NetApp の考え方

フラッシュデバイスに求めるものは何か？ write 処理のおいて：

ピーク時の IOPS / レイテンシの一貫性 ⇒ NetApp の選択


NetApp の SSD 保守対応

SSD の保守契約期間は 5 年まで対応可能保守契約期間中に SSD が故障（書き込み回数上限含

む）⇒（無償）交換可能

NetApp プラットフォームは SSD の書き込み回数を監視しており、寿命が近づくとアラートが発生 ⇒（無償）交換可能

5 年の保守契約期間の妥当性特定のワークロードをかけ続けた場合に、書き込み回数の上限

に達する年数のデータが SSD ベンダより提供されている

ワーストケースと言える random write only で約 5 年



価格性能比から導かれる EF550 活用法


EF550 概要とキーポイント

EF550 主な仕様


ベースモデル400GB / 800GB / 1.6TB SSDx 6 ドライブ～ 120 ドライブ

フォームファクタ 2U / 24 ドライブシェルフ

I/O インターフェイス

（オプション）

16Gb FC×8 / 6Gb SAS×8

10Gb iSCSI×8 / 40Gb IB×4

ストレージ OS SANtricity® 11.10

データ保護機能スナップショット非同期レプリケーションオンラインボリュームコピー

SAN ストレージです

あらゆるワークロードに対応できる EF550EF550 性能


I/O ワークロード EF550

random disk read（4KB）400,000 ～

450,000 IOPS

random disk write（4KB） 75,000 IOPS

sequential disk read（512KB） 12 GB/s

sequential disk write（512KB） 6 GB/s

あらゆるワークロードに対応できる EF550EF550 性能


I/O ワークロード EF550

random disk read（4KB）400,000 ～

450,000 IOPS

random disk write（4KB） 75,000 IOPS

sequential disk read（512KB） 12 GB/s

sequential disk write（512KB） 6 GB/s

IOPS だけではなく

スループットも高い

EF550 のキーポイント


エンタープライズに相応しい信頼性

スナップショット

E-Series へのレプリケーション

715,000 台を超える導入実績と

99.99991% の稼働率（※E-Series）

冗長構成

オンラインメンテナンス

集約密度（2U）

【性能の両立】450,000 IOPS と 12GB/s スループット

1ms 以下の低レンテンシを維持

【柔軟な容量】400GB / 800GB / 1.6TB

x 6 ～ 120 ドライブ

Dynamic Disk Pools（DDP）

RAID6 をベースとして、「シンプル」に 11 ～何百というドライブを 1 つのプールで管理ドライブの効率活用：「データ、パリティ、スペア」領域をプール

内の全ドライブに分散

効率的なパリティ演算が可能になるドライブ構成を検討する必要はない

ドライブ障害からの高速復旧：従来の RAID グループのリビルドより最大 10 倍の処理速度


Dynamic Disk Pools（DDP）


data

data

data

P parity

data

data

Q parity

data

P parity

data

P parity

Q parity

data

Q parity

data

data

data

data

空き領域を従来のホットスペア領域をして活用

全てのドライブがアクティブ（アイドル状態のドライブがない）

data

data

data

P parity

data

data

Q parity

data

P parity

data

P parity

Q parity

data

Q parity

data

Hot

Spare

DD

PR

AID

6

ドライブ障害時の動きDynamic Disk Pools（DDP）


data

data

data

data

data

data

P parity

data

data

Q parity

data

P parity

data

P parity

Q parity

data

Q parity

data

ホットスペア

data

data

data

P parity

data

data

Q parity

data

P parity

data

P parity

Q parity

data

Q parity

data

data

data

data

data data data

DD

PR

AID

6

ドライブ障害時の動きDynamic Disk Pools（DDP）


data

data

data

data

data

data

P parity

data

data

Q parity

data

P parity

data

P parity

Q parity

data

Q parity

data

ホットスペア

data

data

data

P parity

data

data

Q parity

data

P parity

data

P parity

Q parity

data

Q parity

data

data

data

data

data data data

DD

PR

AID

6

再構成されたデータは全ドライブの空き領域に配置される再構成が完了したデータから順次にアクセス可能

再構成されたデータの書き込み処理がホットスペアに集中するため、ボトルネックになりがち


各種ワークロードにおけるEF550 ベンチマーク

検証目的

SSD と HDD の「価格性能比」を I/O ワークロード、RAID 構成ごとに確認し、EF550 活用法を導き出す指針とする

I/O ワークロード random read / write sequential read / write

RAID 構成 RAID10 / RAID5 / Dynamic Disk Pool（DDP）※ DDP：RAID6 をベースとした新しい RAID 技術

read cache：off※ 最大性能ではなく、ドライブ性能の傾向を確認


検証環境 - 1/2


EF550

controller #2

controller #1

server #1

FC switch（16Gbps）Brocade 6505

server #2 server #3

SSD x 24 drives

【ストレージ（EF550）】read cache：offwrite cache：on（CME）※ 検証項目に合わせて、内蔵ドライブx 24 を SSD または HDD に入れ替え

【サーバ】CPU：8 コア（HyperThreading）- Intel Xeon E5620 @ 2.40GHzメモリ：8GB16Gbps 対応 Brocade HBA を搭載ベンチマークツール：fio-2.1.416Gbps FC x 6

16Gbps FC x 8

fio fio fio

EF550

HDD x 24 drives

controller #2

controller #1

SSD x 12 または HDD x 12 で構成されたボリュームグループ（RAIDグループ）に対して同じ負荷を生成アクティブなコントローラは 1 つ

※ 検証結果の値を 2 倍することで、EF550 筐体の性能値となる（コントローラ x 2、SSD x 24）

検証環境 - 2/2


controller #2

controller #1

x 12 drives

LUN

ownership

SSD

volume group（RAID group）

controller #2

controller #1

x 12 drives

LUN

ownership

HDD

volume group（RAID group）

検証内容

検証で使用した I/O ワークロード（fio の設定） Random I/O（8KB）：

read 比率：100, 90, 80, …, 10, 0

sequential I/O（1MB）：read only / write only

EF550 の RAID 構成 RAID10 / RAID5 / Dynamic Disk Pool（DDP）


検証結果


プレゼンテーションのみ


価格性能比の算出と EF550 活用法の考察

SSD と HDD の性能差



価格性能比の算出



価格性能比から導かれる EF550 活用法


【Random I/O】SSD は価格性能比で HDD に勝る

Random Read で約 10 倍、Random Write でも約 4 倍の価格性能比を誇る

【Sequential I/O】価格性能比では HDD に分があるがSSD は十分なスループットを誇る

SSD の領域

HDD の領域

EF550 の領域

混合されたワークロード


Oracle Database 環境での EF550 活用法

なぜデータベースシステム？

あるデータベースシステムの 1 日

日中：オンライントランザクション処理（OLTP）

夜間：バッチ処理、バックアップ、メンテナンス

各処理において高い性能を実現するには

OLTP

⇒ Random I/O

⇒ 「IOPS」が重要

バッチ処理、バックアップ、メンテナンス

⇒ Sequential I/O がボトルネックになりがち

⇒「スループット」が重要



Oracle Database 環境でのEF550 性能検証

検証の目的

基礎ベンチマーク検証結果から、Oracle Database をEF550 上で稼働させることで、高い IOPS とスループットを同時に実現できることを実証する

オンライントランザクション処理（OLTP）性能の向上を確認する⇒ IOPS 系ワークロード

バッチ処理の高速化を確認する⇒ （一般的に）スループット系ワークロード


検証環境の概念図


LAN

EF550

controller #2

controller #1

server #1

FC switch（16Gbps）Brocade 6505

server #2 server #3

16Gbps FC x 6

16Gbps FC x 8

server #1 server #2 server #3 server #4

Oracle Database 12c（Oracle RAC)

12 ドライブで構成された RAID グループ x 2 作成

それぞれの RAID グループから LUN x 1 を作成し、Oracle ASM で束ねる（LUN のオーナーシップは両コントローラに分散）

EF550 ストレージ構成


EF550

RAID group

controller #1

SSD x 12

RAID10（6+6）

RAID group

controller #2

SSD x 12

RAID10（6+6）

Oracle ASM

EF550

RAID group

controller #1

HDD x 12

RAID10（6+6）

RAID group

controller #2

HDD x 12

RAID10（6+6）

Oracle ASM

LUN LUN LUN LUN

【SSD 構成】【HDD 構成】


Oracle Database 環境でのEF550 性能検証～ OLTP 編～

OLTP 検証内容

SSD と HDD 構成に対して Web ショッピングサイトを想定したワークロードを生成し、性能の傾向を確認

トランザクションの定義トランザクション 1（TX1）：

read のみ（SELECT のみ）トランザクション 2（TX2）：

read と write（SELECT, UPDATE, INSERT 混合）

ワークロードの設定トランザクション比率は TX1：TX2 = 50：50 アクセスするデータ量を 10, 20, …, 100GB まで増加


OLTP 検証結果


0

10

20

30

40

50

60

70

80

90

100

0

400

800

1200

1600

2000

2400

2800

3200

3600

4000

1 10 20 30 40 50 60 70 80 90 100

DB

Serv

er

CP

U U

tilizati

on

(%)

Tra

nsacti

on

/sec

Data Access Range (GB)

TPS: SSD TPS: HDD CPU: SSD CPU: HDD

【HDD 構成】ヒット率の減少に伴い性能が劣化

OLTP 検証結果


0

10

20

30

40

50

60

70

80

90

100

0

400

800

1200

1600

2000

2400

2800

3200

3600

4000

1 10 20 30 40 50 60 70 80 90 100

DB

Serv

er

CP

U U

tilizati

on

(%)

Tra

nsacti

on

/sec



DB サーバにおけるキャッシュヒット率が高い理想の状態

【SSD 構成】ヒット率が減少しても高い性能を維持


OLTP 検証結果


0

10

20

30

40

50

60

70

80

90

100

0

400

800

1200

1600

2000

2400

2800

3200

3600

4000

1 10 20 30 40 50 60 70 80 90 100

DB

Serv

er

CP

U U

tilizati

on

(%)

Tra

nsacti

on

/sec



DB サーバにおけるキャッシュヒット率が高い理想の状態


【SSD 構成】ヒット率が減少しても高い性能を維持

性能向上のカギは（DB サーバにおける）「キャッシュヒット率」


Oracle Database 環境でのEF550 性能検証～バッチ処理編～

バッチ処理検証内容

SSD と HDD 構成に対して以下のバッチ処理を実行し、性能の傾向を確認

1. 表を全件検索

2. 索引を全件検索

3. 索引を高速全件検索

4. 索引のメンテナンス処理

5. 表と表の結合処理

6. 大量データの write 処理（データローディング）


大規模な表の read 処理※ 以下 3 通りの実行計画で確認

検証結果（バッチ処理）


0:04:45

0:01:40

0:06:42

0:00:36

0:04:47

0:03:30

0:05:09

0:01:52

0:27:24

0:04:06

0:06:57

0:23:24

0:00:00 0:07:12 0:14:24 0:21:36 0:28:48

6. 大量データの write 処理

5. 複数の表の結合処理



2. 索引を検索


Elapsed Time (mm:ss)

HDD SSD

検証結果（バッチ処理）：Oracle 用語版


0:04:45

0:01:40

0:06:42

0:00:36

0:04:47

0:03:30

0:05:09

0:01:52

0:27:24

0:04:06

0:06:57

0:23:24

0:00:00 0:07:12 0:14:24 0:21:36 0:28:48

6. INSERT (APPEND)

5. JOIN (HASH)

4. CREATE INDEX

3. INDEX FAST FULL SCAN

2. INDEX FULL SCAN

1. TABLE FULL SCAN

Elapsed Time (mm:ss)

HDD SSD


30

28

79

90

41

96

70

53

8

10

34

3

0% 20% 40% 60% 80% 100%





2. 索引を検索


バッチ処理実行中の待機イベント内訳（%）

40

19

44

67

31

76

60

58

35

33

43

24

0% 20% 40% 60% 80% 100%





2. 索引を検索


I/O CPU OTHER

SSD 構成

HDD 構成


30

28

79

90

41

96

70

53

8

10

34

3

0% 20% 40% 60% 80% 100%





2. 索引を検索



40

19

44

67

31

76

60

58

35

33

43

24

0% 20% 40% 60% 80% 100%





2. 索引を検索


I/O CPU OTHER

高速化が目立った処理は、HDD 構成で「I/O」の割合が高い

SSD 構成

I/O が高速化することで「I/O」の割合が減少し、

「（サーバ）CPU」割合が増加

HDD 構成


30

28

79

90

41

96

70

53

8

10

34

3

0% 20% 40% 60% 80% 100%





2. 索引を検索



40

19

44

67

31

76

60

58

35

33

43

24

0% 20% 40% 60% 80% 100%





2. 索引を検索


I/O CPU OTHER

SSD 構成

HDD 構成

高速化が目立った処理は、HDD 構成で「I/O」の割合が高い

I/O が高速化することで「I/O」の割合が減少し、

「（サーバ）CPU」割合が増加

高速化のカギはバッチ処理実行中の

「I/O」の割合


40

19

44

67

31

76

60

58

35

33

43

24

0% 20% 40% 60% 80% 100%





2. 索引を検索


I/O CPU OTHER

30

28

79

90

41

96

70

53

8

10

34

3

0% 20% 40% 60% 80% 100%





2. 索引を検索



SSD 構成

HDD 構成

sequential read

random read

sequential read

sequential read

random read

sequential write

sequential read

random read

sequential read

sequential read

random read

sequential write

各 I/O の種類を分類すると

EF550 が持つ高いスループットより高速化を実現

高速化のカギは「スループット」

Oracle on EF550 検証結果のまとめ


高い IOPS とスループットを同時に実現できる EF550

オンライントランザクション処理（OLTP）性能を向上バッチ処理の高速化を実現


【考察】失敗しない EF550 活用法

考察：OLTP

OLTP 性能向上のカギは「キャッシュヒット率」キャッシュヒット率が悪ければ、OLTP 性能向上が大きく期待で

きる

キャッシュヒット率が減少する要因物理メモリ不足やデータベース設計ミス

ユーザ数、データ量の増加による同時にアクセスするデータ量の増加

統合化（物理 / 仮想）による物理メモリの分割


キャッシュヒット率の改善考察：OLTP

セオリー：DB サーバーへのメモリー追加 / DB チューニングによるキャッシュヒット率の改善

新たな選択肢：EF550 の高い IOPS を活用して、キャッシュミスが頻発しても性能が劣化しない DB システムを構築


考察：バッチ処理

バッチ処理高速化のカギは、処理中の「I/O 割合」と「I/O 種類」

「I/O 割合」が高ければ高速化が期待できる

「I/O 種類」と、他社 All Flash Array（AFA）製品と比較したEF550 の導入効果（価格性能比）

※ ★ が多いほど高い

random read：IOPS ⇒ ★★★

random write：IOPS ⇒ ★★

sequential read：スループット ⇒ ★★★★★

sequential write：スループット ⇒ ★★★★


こんなケースは EF550考察：OLTP とバッチ処理

既存システムの DB をそのまま稼働させるだけで、高い性能を発揮したいケース（フラッシュで楽をする）

IOPS もスループットも両方欲しい

DB サーバーのメモリースロットが不足している場合

DB チューニングに必要な工数が心配

SQL の書き換えが難しい場合



参考資料

参考資料

テクニカルレポート：Oracle データベース環境におけるオールフラッシュアレイ NetApp EF550 の有効性～ OLTP 処理性能の向上とバッチ処理の高速化を両⽴するEF550 ～http://www.netapp.com/jp/system/pdf-reader.aspx?m=tr-4344.pdf

技術ブログ（連載）：検証結果から理解するネットアップのフラッシュ技術http://www.netapp.com/jp/communities/tech-ontap/archive/flash-archive.aspx

Oracle DB 環境に最適な Storage 選定の勘所http://www.netapp.com/jp/communities/tech-ontap/tot-201406-openworld-jp.aspx



Thank you

[db tech showcase tokyo 2014] d24:...

Technology