クラウド基盤で使うストレージの役割や考慮点

高野 勝Microsoft MVP

–File System Storage

Cloud OS Tech Day June 2014

自己紹介

•氏名：高野 勝（たかの まさる）

•仕事：ストレージベンダーSE 今年は顧客担当がメインの傍らMicrosoft 製品との連携機能や検証等も実施

•Microsoft MVP – File System Storage

2

本日のアジェンダ

•ストレージとは• 役割、種類

• ストレージ導入のメリット

•ストレージサイジング• 容量

• パフォーマンス

• 既存環境の調査

•さらに進んだストレージの使い方や機能• ストレージの仮想化

• 仮想ディスクの変換

• クラウド環境でのストレージデザイン3

ストレージとは

4

ストレージの役割

•ストレージ• 直訳すると“倉庫”

• データの置き場となるディスクを指すことが多い

5

ストレージの種類

•DAS• ダイレクト・アタッチド・ストレージ

• いわゆるローカルディスク

• SAN型• ストレージ・エリア・ネットワーク

• ファイバチャネルやIP-SAN（iSCSI, FCIP, IFCPなど)で構成

•NAS型• ネットワーク・アタッチド・ストレージ

• CIFSやNFSで構成される6

ストレージ導入のメリット

•ディスク容量の共有化• 各サーバー用にストレージを用意すると、ストレージの使用率が各システムでばらつき非効率になる

• ディスクをプールからVolumeを切り出して使うことで空き領域を効率的に使うことができる（空き領域の共有）

7

使用率40% 使用率80%使用率20% 使用率95%

ディスクプール

拡張

オンラインで瞬時に拡張・

縮小

Volume

vol1 vol2 vol3vol4

切り出したVolume毎に拡大/縮小できるので空き領域を共有できる各サーバーで使用率が異なり調整できない

ストレージ導入のメリット

•ディスクIOの共有• 各サーバー毎にRAIDを構成するとローカルディスクのIOに引きづられてパフォーマンスが出ない

– 近年のサーバートレンド（Blade化、1Uを並べる方式）はサーバー自身に搭載できるディスクが少ないので、この傾向が顕著

8

SAS SATA SSD SAS

ディスクプール

ディスク（RAID）

vol1 vol2 vol3vol4

全てのVolumeは全Diskを使ったストライプの恩恵を受けられる各サーバー個別のIOのしか出せない

ストレージ導入のメリット

•バックアップ環境の統一• 各サーバー用にバックアップ環境を作ると運用が大変

– テープ交換

– バックアップ、リストア手順が環境ごとに違う

– バックアップメディアがばらばら

– データの遠隔地保管はどうする？

• データをストレージに置くことで一括でバックアップ＆転送ができる

9LTO DAT バックアップソ

フトでNASへVSS Snapshot取得

遠隔地へデータ転送

ストレージサイジング

10

容量のサイジング

•データ格納領域• 必要な容量を算出

• アプリケーションで必要な容量

– データベース容量

– ログ容量

• 容量だけでなく、データ特性やIO性能にも気を配る

11

容量のサイジング

•シンプロビジョニング• 容量のオーバーコミット

• 監視は必須

12

1TBの物理容量

実際に使用している領域

150GB

見た目のボリュームサイズ

10TB

②必要な容量をプールから自動的に割り当てる

ディスクプール 850GB

①データ書き込み

5GBのデータ

5GBのスペース

③使用量 155GB

③残り容量845GB

容量のサイジング

•重複排除• 重複したデータを排除することでストレージの使用ブロックを開放する

• ブロック方式/ファイル方式、固定長/可変長などの方式により効果が若干違う

• 重複排除してもクライアントからの見た目は何も変わらない

• 仮想化環境ではOS領域に設定すると効果大

• 映像、画層、音声データにはあまり効果が無い

• 効果の目安：ファイルサーバーで20%～30%ダウン

13

容量のサイジング

•バックアップデータ格納領域• Snapshotの仕組みを理解する

• 基本的な考え方は“増分”

• 「世代数」ではなくて「保持期間に起きる更新データ量」で計算する

• たくさん取ったほうがお得（リストアできる場所が多くなる）14

Snapshot-1を作成

ファイルを変更C→C’

Snapshot-1

A B C

File.txt

Ⅰ

File.txt

A B C

File.txt

Snapshot-1Ⅱ

File.txt

A B C

File.txt

C’

Ⅲ File.txt

A B C

File.txt

C’

Snapshot-1

File.txt

B’

Snapshot-2

Ⅳ

パフォーマンスのサイジング

•ストレージのパフォーマンスを決める要因• ヘッドスピード

• インターフェーススピード

• ディスクスピード

• この3つの中で一番遅いものがストレージとしての性能となる

15

ディスクスピードを決める要因

•ディスクの種類• SATA・・・安価で大容量、スピードちょっと遅い、信頼性低め

– 75IOPS/本 程度

• SAS・・・データ置き場としては一般的

– 145IOPS/本 程度

• SSD・・・超高速、ただしまだ高い

– 20,000 IOPS/本 程度

•ディスク本数• ストライプ処理・・・複数のディスクへ同時に書き込み/読み込みを並列に行うことで処理性能を上げる

• それほど大きくない領域にIOが必要な場合は1本のディスクサイズをわざと小さいモデルと選択するのも有効（案外GB単価は変わらない）

16

ディスクスピードを決める要因

•キャッシュの利用• SSDをキャッシュにすることでホットデータをSSDに乗せてしまう技術

• 特定のIOが集中する事がわかっている時は非常に効果が高い

– 例：VDI・・・朝PCを一気に起動する場合

• キャッシュを刺す場所

– ストレージのヘッド

– サーバー

17

その他の考慮点

• RAID方式の決定• RAID５ ディスク１本までの障害に対応。２本死んだら終了

• RAID６ ディスク２本までの障害に対応。３本死んだら終了

• データロストの多くがディスク障害のリビルド中にもう１本障害が発生したことに起因する

•リビルド時間の目安• SATA・・・１TBで約９時間

• SAS・・・900GBで約5時間

• SSD・・・200GBで約0.3時間（18分）

18

レイテンシ

•レイテンシ• データ転送において、データを要求してから実際に送られてくるまでの待ち時間のこと

• システムによっては結構重要な要素

• VDI環境でのレイテンシの目安

– 20ms 快適

– 50ms 画面がカクカクする場合も

– 100ms 使い物になりません

19

既存環境の調査

•Windows Serverの場合• ServerのIOはTypeperf.exe(Windows 2003以降で標準搭載）

• 何が取得可能かは typeperf -q またはtypeperf –qxで照会可能

• 30秒間隔で1日分、typeperf.csvに出力するには、– typeperf.exe “PhysicalDisk(*)\*” –o typeperf.csv –si 30 –sc 2881

– これで1日分、30秒間隔で全ドライブの物理ディスクの情報が取れる。

– 特定のドライブに絞るなら “\PhysicalDisk(0 C:)\”のようにドライブ番号とドライブレターを指定できる

20

既存環境の調査

•Windows Serverの場合• サンプリング周期（-siと-sc）指定のツボ

• 長期的な傾向としては30秒周期でサンプリングする

– 最低でも1日、可能なら処理が重い日を狙って取得する

– 1日ごとに区切って毎日取得しても負荷はそんなにかからない

• 短期的な傾向は1秒単位でサンプリングする

– 重い時がわかっていて、そこで使えば、能力の限界やHot spotがわかる

21

既存環境の調査

•何を見るべき？• Current Disk Queue Lengthと Avg Disk Queue Length

– ディスクにたまっている未処理の要求数。 2以下が望ましい。 （継続的に4を超えている状態は明らかに能力が不足している。）

• Disk Time (Disk Read TimeやDisk Write Timeも参考にする）

– ディスクの処理時間

– DBのバッチ処理などは処理時間に響くのでぐっと短く

• Disk ReadとDisk Write

– ディスクのI/O回数、すなわちIOPSだが、Windowsは8-32KB、大きくて100KBぐらいのサイズで書き込むことが多く、ちなみにNetAppのIOは4KB単位

22

既存環境の調査

•何を見るべき？• Disk Write Bytes/SecとDisk Read Bytes/Sec, Disk Bytes/Sec

– ディスクの転送量。すなわちMB/Secをみる

– Read/Writeの比にも注意しておくべき。

• %Idle time

– 逆算して利用率を確かめる。 快適に使えるのは利用率20%ぐらいまでで、そこからは要求が衝突しはじめ、急速に混み始める。

23

既存環境の調査

•クライアントの場合• クライアントはOS：12 IOPS + APP : 8 IOPS で20 IOPSが一応の目安

• Typeperfも使用可能なので特殊なアプリケーションを使っている場合は環境をチェック（WindowsXP以降）

•Unix/Linuxの場合• IostatでIO情報が取得可能

24

さらに進んだストレージの使い方や機能

25

ストレージの仮想化

•NetApp Clustered ONTAP• 仮想化することで物理依存から脱却

• 新機能盛りだくさん

26

SVM - A SVM - CSVM - B

C C1 C2 C3A A1 A3

A2

Vse

rver

B B1 B2 B3

Vse

rverR

R

R

Cluster ＝ ストレージ（FAS/Vシリーズ）のリソースプール

物理レイヤー

論理レイヤー

A3

A

A1 A2

C

C1 C2 C3B B1 B2 B3

R R R

LIF LIF LIF LIF LIF LIF LIF LIF

Transparent volume move

•オンラインVolume移動

27

B

CA2

A3

C1 A1

B1

B2

A

R

C2

LUN

LUNLUN

A B C

A1A2

A3B1 B2

C1

R

LUN LUN

中断のないアクセス

バックグラウンドで差分コピー

トラフィックが少ないタイミングで切り替え

クラスタ内のどの場所でも任意のアグリゲート間で、オンライ

ンでボリュームを移動

重複排除、圧縮、ミラー関係、

Snapshotなどは変更なし

NFS / CIFS / iSCSI /FC / FCoE

HA HA

Transparent volume moveの適用シナリオ

•ストレージの階層化

28

HA

C1

LUNLUN

B2

B

C

LUN B1

NFS / CIFS / iSCSI / FC / FCoE

高パフォーマンスストレージ

HA

AA1

A3

R

A2

低コストストレージ

ストレージの階層化

–ディスクのコストとパフォーマンスに合わせたデータ管理

–同じ共有リソースプール内で複数の種別のディスクを管理

– Flash Cache/FlashPool：自動インテリジェント・キャッシング

–エントリモデルとミッドレンジモデル、異なる世代、他社ストレージなど、様々なストレージを混在可能

–データの"鮮度"に応じて、アクセス性能をダイナミックに変更可能

–クライアント側の変更は必要なし

Transparent volume moveの適用シナリオ

•機器リプレースへの対応

29

手法

影響を受けるボリュームとLUNを確認

システムを停止することなくボリュームを移動

テクノロジ更新の実施

ノードの強化とクラスタの再統合

新しいノードにボリュームを戻す

上記手順を繰り返す

B2

AB

A1 A3

RC

LUN

A2

B1C1LUNLUN

QoS（Quality of Service)

30

利用用途

– マルチテナント環境における高負荷ユーザの抑制

– クラウド環境におけるサービスメニューの提供

– モンスターVMへの対処

今まで

Vol A Vol B Vol C

高負荷

高負荷な一部の領域に他の領域が影響を受ける

低負荷 低負荷

Performance

QoS

中負荷

上限値(IOPS,MB/sec)を設けることで、均一なリソース利用が可能

特定のSVM、ボリューム、LUN、ファイルだけ制限を設けることも可能

中負荷 中負荷

QoS ポリシー5000 IOPS上限

0

5000

10000

Performance

Vol A Vol B Vol C

ODX

• ODXの機能

• WindowsのCopy Offload機能により、ストレージにコピー処理をオフロードし、コピーを高速化すると共にホストのリソース利用率を削減

• クラスタ内でのボリューム間およびノード間コピーに対応

• CIFS/LUNに対応

• 異なるプロトコル間でも使用可能

• 利用用途

• Hyper-V環境での巨大なVHDファイルコピー

• ビデオファイルなど巨大なファイルのコピー

ファイルコピー操作

SVM

Windows 2012

Windows 2012

実際のデータ移動処理

SMB3.0

• SMB3.0

• ファイルサーバーストレージに仮想

マシンファイルを配置

• SMBフェイルオーバー構成が可能に

• ボリュームの運用もストレージにオ

フロード

(拡大/縮小/追加/削除が自由に)

• 共有フォルダに格納したVHD を他の

Hyper-V から簡単にマウント可能

• VSS for SMB の機能により整合点の

あるバックアップ作成も容易Storage Pool

VHDVHD

VHDVHD

VHDVHD

Snapshot

copies

Snapshot

copies

Snapshot

copies

Hyper-V Hyper-V Hyper-V

VHDVHD

VHDVHD

VHDVHD

VHDVHD

VHDVHD

VHDVHD

リモートVSS でバックアップ

仮想ディスクの変換

•NetApp Shiftスクリプト• VmwareのVMDKをHyper-V形式のVHDXに簡単変換

• クローン技術を使っているので元のVMDKもそのまま保持可能

• デモ動画も公開中https://communities.netapp.com/community/netapp-blogs/netapp_japan/blog/2014/04/13/shiftdemo

33

クラウド環境のストレージデザイン

•要件ベースの考慮点• マルチテナント

– 必要なケース：セキュリティ、IPスペース、Windowsドメイン

• 領域とIOベースの割り当て

– 容量とIOPSの組み合わせ

• バックアップ間隔、遠隔地転送はオプションで

•最初から大きすぎるサイジングをしない• 増え方の予想は非常に困難

• 後から変更しやすいようにしておく

34

ストレージ業界の今後

35

SSDの行方

• SSDはSASディスクにとって代われるか• SAS , SATA時代からSSD, SATA時代へ変わる？

36

37

Q & A

38

Thank You!