oracle direct seminar … · flashデバイスの検討 • 「今まで dram, hdd, tape...

<Insert Picture Here>

Oracle Direct Seminar

ZFS 第四弾！実際のシステムでより有効活用するには？

日本オラクル株式会社　

Copyright© 2010, Oracle. All rights reserved. 2

以下の事項は、弊社の一般的な製品の方向性に関する概要を説明するものです。また、情報提供を唯一の目的とするものであり、いかなる契約にも組み込むことはできません。以下の事項は、マテリアルやコード、機能を提供することをコミットメント（確約）するものではないため、購買決定を行う際の判断材料になさらないで下さい。オラクル製品に関して記載されている機能の開発、リリースおよび時期については、弊社の裁量により決定されます。

OracleとJavaは、Oracle Corporation 及びその子会社、関連会社の米国及びその他の国における登録商標です。文中の社名、商品名等は各社の商標または登録商標である場合があります。


スピーカー自己紹介

• 学生時代• JDK 1.1でPrologの推論機構を実装し検索エンジンの真似ごと

• 1998年4月(日本)サン・マイクロシステムズ入社• ふと気づけば社会人13年目

• ほぼずっとSE (Sはシステム?セールス?)• 主にSolaris、開発環境、Sun Rayシンクライアント

• 今は主に通信事業者様担当

• 1年だけサポートエンジニア• Java VMの解析

• Solarisエバンジェリスト(宣教師?!)• 最近は特にZFSの宣伝係としての出番増


本日の内容

• 前回までのおさらい• 第一弾「超入門ファイルシステムって何だ？」

• 第二弾「ZFS はどうすごい？」

• 第三弾「ZFS をどう活用すればいい？」

• ZFSを実際のシステムでより有効活用するには• ストレージサーバーの準備

• ストレージプール構成の検討

• ファイルシステム属性値の検討

!


前回までのおさらい


結局のところファイルシステムとは

• どのセクタにどうデータを書くか

• 開発者の腕(?)の見せどころ• 容量をうまく使えるか

• 安全か

• 便利か

• 高速か

• 管理しやすいか

第一弾「超入門ファイルシステムって何だ？」


既存ファイルシステムの問題点

• 拡張性

• 堅牢性

• 機能

• 性能

• 管理性

第一弾「超入門ファイルシステムって何だ？」


ZFS: 革新的ファイルシステム

ZFS 1 ZFS 2 ZFS 3

機能•スナップショット•リモートコピー•バックアップ•ファイル共有

Storage Pool

管理性•極めて簡素

•プール構造•ボリューム管理の統合

拡張性•事実上無制限

•プール容量•ファイルシステム容量•ファイル数•ディレクトリ数

堅牢性•Copy-on-Write•トランザクション•End-to-Endチェックサム•write-hole排除•自己修復

性能•Hybridストレージプール•Read-modify-writeの排除•入出力のパイプライン処理

追加費用無オープンソース

第二弾「ZFS はどうすごい？」


ZFS: 広範なインフラ向けソリューションの理想的なストレージ基盤

データベースDWH

webインフラストラクチャコンテンツ

マネジメント

デスクトップ統合仮想化

デスクトップ用ファイルサービス /

インフラストラクチャ

NASEメールなどアーカイブ

ハイパフォーマンスコンピューティング

バックアップデータ

プロテクション

事業継続災害対策

クラウドコンピューティング

/ ストレージ

• 多くの機能を低コストで、多くの応用例、多くの事例

第三弾「ZFS をどう活用すればいい？」


7720

7420

73207120

Sun ZFS ストレージアプライアンス• Unified Storage / Sun ZFS Storage 7000• Solaris ベースの NAS ヘッド

• オープンアーキテクチャ

• データ形式、プロトコル(NFS, FTP, WebDAV, iSCSI,CIFS, FC, IB, NDMP, ..)

• オープンソースソフトウェア採用

• 追加ライセンス費用無

• ZFS と Flash (SSD)

• Hybridストレージプール

• DTrace Analytics

• リアルタイム

• システム性能確認

• 容量プランニング

• 課題特定

〜120TB 〜192TB

〜1152TB(〜480TB/rack)

〜720TB/rack

DTrace Analytics

第三弾「ZFS をどう活用すればいい？」


実際のシステムでより有効活用するには



• ストレージサーバーの準備



• 注意

• あくまで一般論であり、全ての要件に見合うわけではないのでご注意ください



• ストレージサーバーの準備• アプライアンスか手作りか

• 動作OS

• サーバー検討項目

• 外付けストレージ検討項目

• よく利用される機器



• 注意



アプライアンスか手作りか

• アプライアンス(Sun ZFS Storage 7000シリーズ)• 設定が簡単かつ多くの要件にも見合う

• Dashboard、Analytics (DTrace)などツールもストレージとして必要十分なものを実装

• Solaris 11 Express に準じた開発速度 (重複排除機能も搭載)

• ただし、管理ツール (GUI/コマンド) からできることしかできない

• RAIDグループあたりのディスク本数など設定不能 (不要)

• コストと工数の兼ね合いからこちらで十分な要件も多い

• 「十分検討された決め打ち」なので逆に細かい調整が不要

• 手作り• より柔軟にZFSの機能を使いたい

• (本資料は主にこちらをテーマに扱いますがアプライアンスの内部構造理解として参考になります)

!

!


ZFSが動作するOS

• Solaris• SPARC、x86/x64• ZFSは64-bitカーネルで使用するのが望ましい

• Oracle Solaris 10、Solaris 11 Express 2010.11 (Oracle によるサポート有)

• OpenSolaris Communityベースの各 distro (distro ごとのサポートポリシー)

• Solaris以外• FreeBSD, Linux/FUSE, MacOS X (Apple としては2009/10でプロジェクトdiscon)

• できれば最新リリース・パッチを用意• ZFSは堅牢だが、進化も続いている

• 試すだけであれば仮想環境 (VirtualBox等)上の Solaris でも可• Sun ZFS ストレージアプライアンスの VirtualBox用シミュレータもあります

• (本資料は主にSolaris上での構成を検討します)

!

!

!


サーバー側検討項目

• CPU (clock, core, ..)• 強力なほど良い

• トランザクション、ネットワーク、キャッシュ、チェックサム、重複排除、圧縮、暗号化、..

• HW accelerationが見込まれる

• チェックサム、重複排除、暗号化

• メモリ• 速くて多いほど良い

• ARC

• 高速Flashデバイス• 負荷要件によっては望ましい

• 主にL2ARC、ZIL(slog)用

• ネットワーク• 速く、多く、接続性

• GbE, 10GbE, InfiniBand

• IPマルチパス、リンク集約

• サイト設計も検討

• サービスプロトコル• NFS, CIFS, FTP, iSCSI, FC,

SRP, iSER, ..

• boot/rootディスク• ZFS rootにするか

• ディスクとの接続• 内蔵

• 外付け

!

!


ZFS rootにするかしないか• すると管理・運用上の利点が多い• snapshotを使用してboot環境のupdate/rollbackが容易

• クリティカルなパッチ適用時などに有用

• cloneによるboot環境作成でOSのLiveUpgradeも容易

• ZFSのみ管理すればよい

• rootがUFSだとUFSキャッシュも使われる

• Solaris 11 Express はZFS rootのみ

• Solaris 10では10/08から• 新規インストール時

• CUIインストーラから

• UFS rootからアップグレード

• 別パーティションにプールを作成

• ブート環境作成

• Live Upgrade

• ミラー構成時はbootblockのコピーが必要(CR#6668666)• (Solaris 11 Expressでは修正済)

!

!

!


外付けストレージ使用時の検討項目

• サーバーとの接続• HBA、HCA、コントローラ数

• HW RAIDではない方がZFSの効果が出しやすい

• SATA, SAS, FC/SAN, IB, Ethernet

• ディスクドライブ• 種別 SATA/SAS/FC

• 単体速度、容量

• 本数、RAIDレベル

• 可用性、性能、容量

• HA構成• Oracle Solaris Cluster / Open HA Cluster によるfailover HA-ZFS

ZFSストレージプール

RG RGfailover

node A node B

HA-ZFS!


Flashデバイスの検討• 「今まで DRAM, HDD, tape だったので Flash って馴染み無い」• ケータイ、デジカメ、USB メモリなどでかなり使われている

• 「Flash なら知っているが遅いのでは？壊れやすいのでは？」• エンタープライズ向けFlashは性能も信頼性も十分かつ日々向上

• 厳選 OEM 製品や、技術パートナーと共同開発したOracle 製品は自信あり

• HDD と違って可動部分が無くエンタープライズ Flash のMTBF は HDD より長い

• 「Flash って書込寿命あるよね？」• エンタープライズ向けフラッシュは、ウェアレベリングなどの各種機構 (詳細は公開できないものも多い)

を実装し、各セルの書込回数寿命には簡単には到達しない

• SLCのものは書込回数寿命も MLC のものより大きい

• ZFS なら書込回数の寿命に到達してもデータ損失しない (第二弾参照)

• 「Flash が速いのはわかったが、HW-RAID のキャッシュ (DRAM 等) よりは遅いよね？」• 弊社製 F20, F5100 はDRAMを搭載しておりスーパーキャパシタで電力を供給

• スーパーキャパシタ+Flashはバッテリーバックアップと同様のことをより少ない消費電力で実現

• 停電時は DRAM 上の dirty データをスーパーキャパシタで Flash に書き込む

• Oracle製Flashは4KB単位のI/Oで最も高性能• L2ARC、slogでまるごと使う場合は特に気にしないでよい

Enterprise SSD (3.5”/2.5” FF)

Sun Flash Accelerator F20(PCI-Express Card)

Sun Storage F5100(外部ストレージ)

!

!


よくご検討いただいているマシン

• アプライアンス• Sun ZFS ストレージアプライアンス• 強力なCPU、多メモリ、高拡張性、Enterprise Flash搭載可能• Sun ZFS Storage 7120 (max: 1x 4core, 24GB, SAS-2 120TB, Flash 0+96GB)

• Sun ZFS Storage 7320 (max: 2x 4core, 72GB, SAS-2 192TB, Flash 2TB+288GB)

• Sun ZFS Storage 7420 (max: 4x 8core, 512GB, SAS-2 1.15PB, Flash 2TB+1.7TB)

• 7320 と 7420 はコントローラ冗長化構成が可能

• 内蔵ドライブ数が多いマシン• Sun Fire X シリーズ x64 サーバー• 強力なCPU、多メモリ、高拡張性、Enterprise Flash搭載可能、多くの内蔵ドライブ• Sun Fire X4270 M2 (max: 2x 6core, 144GB, 12x 3.5”, 4x GbE, 6x PCIe2, 2U)

• Sun Fire X4270 M2 (max: 2x 6core, 144GB, 24x 2.5”, 4x GbE, 6x PCIe2, 2U)

S7120 S7320 S7420

X4270 M2 (3.5” HDDモデル ) X4270 M2 (2.5” HDDモデル )

読込ログ

!

! !




• ストレージプール構成の検討• 使用デバイス

• RAIDレイアウト

• Hybrid ストレージプール (キャッシュ、ログ)

• ホットスペア


• 注意



おさらい: ファイルシステム作成手順

1.プールにストレージを登録 zpool create tank cXtXdX ...

2.プールからファイルシステム切出 zfs create tank/home

3. (省略可) 属性値設定 zfs set <attr>=<value> tank/home

• 3ステップで構成可能

• ZFS用語解説「データセット」• ファイルシステム、スナップショット、LUN、クローン等

• zfs creat で作るもの

• 属性値適用の単位

/ (root)

usr opt tank

Storage Pool: tank

ZFS

home

home作成時に自動でマウント

プール名

ファイルシステム名

!


プール作成: zpool create

• 書式• zpool create <pool_name> vdev vdev ...

• vdev: Virtual DEVice (物理デバイスをまとめた論理グループ)

• [layout] <device> ... : RAIDグループ

• [cache] <device> ... : 二次読込キャッシュデバイス (L2ARC)

• [log] [layout] <device> ... : ログデバイス (slog)

• [spare] <device> ... : ホットスペア

• 使用デバイスの検討

• RAID レイアウトの検討• layout: mirror, raidz/z2/z3, 指定無: ストライプ

• キャッシュの検討

• ログの検討

• ホットスペアの検討

!


プールに含めることができるデバイス

• ホストからディスクとして見えるデバイス• DAS HDD、Flash、HW-RAID LUN、FC-SAN、iSCSI

• 推奨は1ドライブ(丸ごと)単位• 全ドライブ同一容量が管理上最もよい

• HW-RAIDとの組み合わせは要相性テスト

• Solaris Volume Managerのボリューム

• ramdisk (ramdiskadm -aで作成)

• パーティション• ドライブ丸ごとと比べて可用性が低い

• Note PCなどHDD内でOSやファイルシステムを分ける必要がある場合

• ZFS rootは現在パーティションで構成• 1ドライブ1パーティションなら可用性は問題無し

• ファイル(mkfile などで作成)• テスト用 (cacheには指定不可だがlofiadm -aすればcacheに設定可)

!


サポートするRAIDレベル

• RAID 0

• RAID 1(+0)• 2面、3面、..

(SZS7000は3面まで)

• RAID-Z(+0)• RAID 5の拡張

• シングルパリティ

• RAID-Z2(+0)• RAID-6の拡張

• ダブルパリティ

• RAID-Z3(+0)• トリプルパリティ

c1t0d0

Storage Pool

c1t1d0 c1t2d0 c1t3d0

RAID 0

D1 D2 D3

D4

RAID 1(+0)

c1t0d0

Storage Pool


D1 D1 D2 D2

RAID-Z(+0 も可能)

c1t0d0

Storage Pool


D1 D2 D3 P

c1t0d0

Storage Pool


RAID-Z2(+0も可能)

D1 D2 P1 P2

D D

DD

vdev vdev

vdevvdev

! ! !


RAIDレイアウトの検討

• プール=あるRAID特性(性能や冗長性)の容量のまとまり• 24ディスクドライブのプール例

• 同一本数で同一RAIDレベルのグループを後から追加可能

vdev数 x 1 vdev内本数 RAID 0 RAID 1(+0)

2面ミラーRAID 1(+0)3面ミラー

RAID-Z( 5+0)≒

RAID-Z2( 6+0)≒

RAID-Z3

1x 24本 - - 1x (23D+1P) 1x (22D+2P) 1x (21D+3P)

2x 12本 - - - 2x (11D+1P) 2x (10D+2P) 2x (9D+3P)

3x 8本 - - - 3x (7D+1P) 3x (6D+2P) 3x (5D+3P)

4x 6本 - - - 4x (5D+1P) 4x (4D+2P) 4x (3D+3P)

6x 4本 - - - 6x (3D+1P) 6x (2D+2P) -

8x 3本 - - 8x (1D+1D+1D) 8x (2D+1P) - -

12x 2本 - 12x (1D+1D) - 12x (1D+1P) - -

24x 1本 24x (1D) - - - - -

:あまり意味をなさない

! ! !

!


容量について

• 使用量80%を越えないように設計、運用• 越えるとファイルシステムの内部処理の割合が多くなる

• セクタの割り当て、quota処理など

• 容量計算(データ用1 vdev が同一容量ドライブN本のとき)• raw容量

= データ用vdev数 x vdev内データドライブ数 x ドライブ容量

• vdev内データドライブ数= N (ストライプ), N-1(RAID-Z), N-2(Z2), N-3(Z3), N/2(ミラー)

• GBとGiBの違い

• GB= 1000x 1000x 1000、GiB= 1024x 1024x 1024

• ざっと実効容量(TB) = raw容量(TB) x 0.98

• snapshot/cloneなどでの使用量

• 差分しか容量を消費しない

• システム要件次第だが一般にかなり少なくできる

2TB HDD x3 の RAID-Z グループが 4グループ → 4 x 2 x 2TB = 16TB

2TB HDD x3 の RAID-Z グループ → 3 - 1 = 2

!

!

!


高速なRAID再同期 (resilver (resync,rebuild,reconstruct))• ディスク障害時のオンライン再同期処理• 通常のRAID管理ソフトウェア• ディスクのどこが使用中か認識できない

• ドライブ全体に及ぶ再同期

使用中再同期

未使用 ×

• ZFS• ディスクのどこが使用中か認識されている

• 使用中部分のみで最小限のアクセスで再同期

• メタデータをたどりつつチェックサムも確認しsilent data corruptionを修復

• 一時障害の際は実行されなかったトランザクション分のみの修復で完了

• uberblockからトップダウンに修復

• 2 HDD目の故障・修復時に1 HDD目の修復完了分までが正データとして使える

• RAID管理とファイルシステムが統合されている利点

• 冗長性が低くなっている時間を短くできる可能性大

使用中再同期

未使用

!!

!!

!


double/triple parity (RAID-Z2/Z3)の必要性

• 近年のドライブ単体の信頼性(URE / bit read)• SATA-II 1014〜1015, SAS 1015〜1016, FC: 1015〜1016

• 1TB SATA-II HDD 1ドライブ故障時• RAID 5 (3D+1P) 再構成失敗率

• 1- (1-8/1014)1000x1000x1000x1000x3〜1- (1-8/1015)1000x1000x1000x1000x3

= 0.213372139 〜 0.023714290

• RAID 6 (10D+2P) 再構成失敗率

• {1- (1-8/1014)1000x1000x1000x1000x10 } x {1- (1-8/1014)10}〜 {1- (1-8/1015)1000x1000x1000x1000x10} x {1- (1-8/1015)10}= 0.000000000 〜 0.000000000

• ドライブ単体の大容量化とストライプ幅を大きくしたい要求への対応

1バイト読込成功確率

RAID再構築に必要な読込数

(K) (M) (G) (T) (本数)

参考: 近似計算

x << 1 のとき

(1-x)n 1- nx≒

2-20% !

ほぼ0% !

HDD単体容量本数

HDD信頼性


RAID-Z/Z2/Z3グループ構成ドライブ数

• 可用性と容量の兼ね合いから• RAID-Z

• 1グループは3 (2D+1P) から4 (3D+1P)ドライブ

• RAID-Z2

• 1グループは5 (3D+2P) から13 (11D+2P)ドライブ

• RAID-Z3

• 1グループは8ドライブ(5D+3P) 以上

• 性能面の考慮• 1グループ3-10ドライブくらい

• ランダムリードが多く読込キャッシュ(一次、二次) が少ないときは少なくして 1 zpool 内にできるだけRAID-Z/Z2/Z3グループ数を多くする

• RAID-Z/Z2/Z3 は1 RAID グループに1 FSBが書き込まれるため

• (Solaris 11 Expressではメタデータの一部がミラーされ高速化)

zpool

3D+2P3D+2P

3D+2P 3D+2P

I/O

FSB FSB FSB FSB

!

!


ストライプ幅自動調節でフルストライプライト

P0 D0 D2 D4 D6

P1 D1 D3 D5 D7

P0 D0 D1 D2 P0

D0 D1 D2 P0 D0

P0 D0 D4 D8 D11

P1 D1 D5 D9 D12

P2 D2 D6 D10 D13

P3 D3 D7 P0 D0

D1 D2 D3 X P0

D0 D1 X . . .

HDD1 HDD2 HDD3 HDD4 HDD5

大きな書き込み

小さな書き込み

• 1 RAID グループに 1 FSBが分散して書き込まれる

ストライプ幅自動調節

書き込むブロックサイズ

(FSB: 512B-128KB)によって伸縮

LBA (Logical Block Address)

0

1

2

3

4

5

6

7

8

:

FSB: File System Block

1 RAID グループ

1 RAID グループに1 FSBを分散して書き込む

利点

write-holeの排除read-modify-writeの排除

堅牢性重視!


小さなランダムリード時の注意点

pool

600 FSBPSのread要求

各HDDに240 FSBPSのread要求

small I/OはFSBPS=IOPSとみなせる

各HDDから

200 FSBPSのread return

• シーケンシャルリード/ライト、ランダムライト時はこの注意点は該当しない

各vdevに300 FSBPSのread要求

vdev

1 HDD 200 IOPSとすると

各vdevから



600 x ( 1 / 2 )

300 x (4/5)

250 x 2

RAID-Z構成時

4D + 1P

均等に分散しているとして

vdev


200 x (5/4)均等に分散

しているとして

平均的には約 200 FSBPSとして計算する

平均的には約 200 x2 = 400 FSBPS

として計算する、つまり1HDDのIOPS x vdev数(1)

(2)

(3)

(4)

(5)

(6)

(7)

!>


性能重視ならミラー構成

pool

800 FSBPSのread要求

各HDDに200 FSBPSのread要求

small I/OはFSBPS=IOPSとみなせる

各HDDから


• read要求をミラーの片側ずつに分散できる

各vdevに400 FSBPSのread要求

vdev

1 HDD 200 IOPSとすると

各vdevから



600 x ( 1 / 2 )

400 x (1/2)

ミラー構成時


vdev

vdevへのread要求はほぼ均等分割される

200 x 2

400 x 2 1HDDのIOPS x HDD数(1)

(2)

(3)

(4)

(5)

(6)

(7)

!=


参考: SZS7000管理画面のRAID構成• RAIDレベルとストライプ幅(wide/narrow)のみ選択可能• グループ内ドライブ数やストライプ幅は指定不能 (不要)

• Disk Shelf (24 ドライブ) x9台(計216 ドライブ)、うち1台目にLogzilla (SSD)1個の例 (Storage 7410)

• 構成内容はSZS7000容量計算ツール (要SZS7000実機 or シミュレータ)で

• http://blogs.sun.com/rdm/entry/capacity_sizing_on_7x20• (S7x10(上の表)と7x20でHDD搭載可能数が異なるので注意)

15x (12D+2P)+5S

105x (1D+1P)+5S

52x (3D+1P)+7S215x 1D70x (1D+1D+1D)+5S

8x (23D+3P)+7S4x (49D+3P)+7S

!

!


どのRAIDレベルか

• 同じドライブ数での大まかな性能• ストライプ = ミラー > RAID-Z > Z2 > Z3

• 同じドライブ数での大まかな可用性• 3面ミラー ≧ Z3 > 2面ミラー ≧ Z2 > Z > ストライプ = 冗長性無し

• RAID-Z3はどの3本が故障してもよいが3面ミラーは特定の3本が故障するとRAID障害

• 4面以上のミラーはまず不要

• 同じドライブ数での大まかな容量• ストライプ > RAID-Z3 > Z2 > Z > ミラー

• 1グループあたりのドライブ数によっては Z > Z2 > Z3

• 性能と可用性を考慮し、可能ならミラー構成を選択

• RAID-Z/Z2/Z3を選択する場合• ランダムリードで必要なIOPSからプール内に何グループ作るかを検討

18 HDD 1 group 可用性考慮

RAID-Z 17D+1P 6x (2D+P)

RAID-Z2 16D+2P 2x (7D+2P)

RAID-Z3 15D+3P 1x (15D+3P)

! !


Hybrid ストレージプール

• デバイスの価格、速度、容量をバランスよく• DRAM

• Flash(SSD)

• HDD

!


一次キャッシュ(ARC)について• DRAMを使用

• 読込時にも書込時にも使われる• シーケンシャルI/Oの際はスキップされる

• 使用量 (標準設定時)• 最大: 物理メモリ-1GB (or 物理メモリの7/8)

• 最小: 物理メモリの約1/8

• 通常はチューニング不要• 他アプリ等のメモリを奪うことはしないため

• 物理メモリ使用量がある程度決まっているアプリ等との共存時は制限する方がよい• 他のアプリ等との兼ね合いを見て

使用量を大きくしすぎない対応はなされている(CR#6488341)

• アプリのキャッシュ機構との兼ね合いによってはオフにすることも検討(primarycache属性: データセット単位で設定可能)

• 重複排除利用時の注意点あり (後述)

!

!


読込二次キャッシュ(L2ARC)検討項目• ランダムリード性能に大きく貢献

• 複数デバイス構成時、ミラー構成はできずストライプのみ

• 書込中のデバイスからは読込を行えないので

• ARCから除去される(あふれた)データが格納される

• 重複排除の管理テーブルも同様に格納される

• シーケンシャルリード時はそもそもARCに載らないので使われない

• dirtyデータは格納されない

• ウォームアップ時間を考慮

• かつてより性能は改善されている

• リブートで内容を保持できない(今後の拡張点)

• ARCより大きい方がバランスよく性能が出る

• 頻繁に使用されるデータ分をカバーする量が望ましい

• 1レコードあたり256バイトのメタデータ

• このメタデータはARCに置かれる

• recordsize=8KでL2ARC 100GBにARC約5GB

• アプリのキャッシュ機構との兼ね合いによってはオフにすることも検討(secondarycache属性: データセット単位で設定可能)

!

!


書込ログ(ZIL)検討項目

• 同期書込時のみ使用される• O_DSYNC, O_SYNC, fsync(), forcedirectio, ..

• sync属性で同期書込の扱いをデータセット単位で変更できる(Solaris 11 Express)

• ログデバイス非指定時はプール内に形成• トランザクションコミットでログはすぐ削除される

• ログデバイス指定時 (= slog: separate log)• 複数構成時はミラー、ストライプが可能

• ストライプでもSPoFにはならない (「ZFS 第二弾」参照)

• できれば高速メディア(Flash等)を指定する

• immediate_write_sz (32KB)を超える書込の扱い

• slog→メタデータ、データともslogに書く

• non slog→メタデータはZILに書き、データはコミットまで待つ

• 属性値でバイアスを設定可(throughput/latency)(後述)

!

挙動が大きく異なる!

!


ホットスペア

• ディスク障害時に自動で使用ディスク切替• 可用性を考えると設定する方がよい

• スペアディスク数• ストレージ筐体内に1〜数本

• コントローラを分散

• プール間で共有可能

• SZS7000では共有できない

• スペアに切り替わった際のディスク配置も考える

• デバイスリプレイスで戻せる

• SZS7000ではHDD本数とRAIDレベルから決まる (考慮不要)

• スペアディスク• 基本的にはプールのデータディスクと同一のもの

• セクタ数単位で容量が同じかそれ以上

!





• ファイルシステム属性値の検討• ZFSとチューニング

• 属性値一覧

• ネットワークでの共有プロトコル

• DBで使う場合の目安

• 注意



ファイルシステムの切り出し: zfs create

ファイルシステム1ファイルシステム2

ファイルシステム3

StoragePool

/ (root)

usr opt export

homeファイルシステム4

一般にはデータセットの切出


ファイルシステム (データセット)

• ディレクトリのように操作できる• ユーザーやプロジェクトごとに個別ファイルシステムを作成

• きめ細かい管理を実現

StoragePool

11-15 △△

16-20 □□

1-10 ○○

!

!


属性値設定: zfs set <attr>=<value>• 容量予約

• 容量制限

• マウントポイント

• 共有の設定 (NFS, iSCSI, CIFS)

• 圧縮の有効化(lzjb, gzip-[1-9])

• 重複排除 (Solaris 11 Express, SZS7000)

• 暗号化 (Solaris 11 Expressのみ)

• 等

Storage Pool

ZFSuser1用

ファイルシステムの容量を

1GB以内に制限

user2用ファイルシステムの

容量を5GB分確保

属性値はディスクに書かれる

cool!

new!


ZFSとチューニング

• チューニング不要であることが開発目標

• ただし必要な場合もある

• 属性値は設定以後(の書込)に適用される• zfs create 時に設定しておくのが望ましい

• 暗号化ポリシーは作成時のみ設定可能で下位に継承される(変更不可)

• データセット単位で属性値を変える• ユーザーごと、プロジェクトごと、特性ごと

• ただし作りすぎると性能インパクト+管理負荷

• ユーザー数が非常に多い場合のquota等• ファイルシステムで分けるよりuserquota/groupquotaなどで対応

•

!

!


データセット属性値 (Solaris 10 9/10)NAME PROPERTY VALUE SOURCEtank type filesystem -tank creation (水) 12月 1 14:17 2010 　-tank used 72K -tank available 63.4M -tank referenced 21K -tank compressratio 1.00x -tank mounted yes -tank quota none defaulttank reservation none defaulttank recordsize 128K defaulttank mountpoint /tank defaulttank sharenfs off defaulttank checksum on defaulttank compression off defaulttank atime on defaulttank devices on defaulttank exec on defaulttank setuid on defaulttank readonly off defaulttank zoned off defaulttank snapdir hidden defaulttank aclmode groupmask default

赤い文字はSolaris 11 Express 2010.11 では無い属性


データセット属性値 (Solaris 10 9/10)(続き)NAME PROPERTY VALUE SOURCEtank aclinherit restricted defaulttank canmount on defaulttank shareiscsi off defaulttank xattr on defaulttank copies 1 defaulttank version 4 -tank utf8only off -tank normalization none -tank casesensitivity sensitive -tank vscan off defaulttank nbmand off defaulttank sharesmb off defaulttank refquota none defaulttank refreservation none defaulttank primarycache all defaulttank secondarycache all defaulttank usedbysnapshots 0 -tank usedbydataset 21K -tank usedbychildren 51K -tank usedbyrefreservation 0 -tank logbias latency default

赤い文字はSolaris 11 Express 2010.11 では無い属性


プール属性値 (Solaris 10 9/10)NAME PROPERTY VALUE SOURCEtank size 95.5M -tank capacity 0% -tank altroot - defaulttank health ONLINE -tank guid 14420412883469840728 defaulttank version 22 defaulttank bootfs - defaulttank delegation on defaulttank autoreplace off defaulttank cachefile - defaulttank failmode wait defaulttank listsnapshots on defaulttank autoexpand off defaulttank free 95.4M -tank allocated 106K -

new!


データセット属性値 (Solaris 11 Express 2010.11)NAME PROPERTY VALUE SOURCEtank type filesystem -tank creation 水 12月 1 14:12 2010 -tank used 70K -tank available 63.4M -tank referenced 31K -tank compressratio 1.00x -tank mounted yes -tank quota none defaulttank reservation none defaulttank recordsize 128K defaulttank mountpoint /tank defaulttank sharenfs off defaulttank checksum on defaulttank compression off defaulttank atime on defaulttank devices on defaulttank exec on defaulttank setuid on defaulttank readonly off defaulttank zoned off defaulttank snapdir hidden defaulttank aclinherit restricted defaulttank canmount on defaulttank xattr on defaulttank copies 1 default


データセット属性値 (Solaris 11 Express 2010.11)(続き)NAME PROPERTY VALUE SOURCEtank version 5 -tank utf8only off -tank normalization none -tank casesensitivity sensitive -tank vscan off defaulttank nbmand off defaulttank sharesmb off defaulttank refquota none defaulttank refreservation none defaulttank primarycache all defaulttank secondarycache all defaulttank usedbysnapshots 0 -tank usedbydataset 31K -tank usedbychildren 39K -tank usedbyrefreservation 0 -tank logbias latency defaulttank dedup off defaulttank mlslabel none defaulttank sync standard defaulttank encryption off -tank keysource none defaulttank keystatus none -tank rekeydate - defaulttank rstchown on default

青い文字はSolaris 10 9/10から追加された属性

new!


プール属性値 (Solaris 11 Express 2010.11)NAME PROPERTY VALUE SOURCEtank size 195M -tank capacity 0% -tank altroot - defaulttank health ONLINE -tank guid 17439480805113476651 defaulttank version 31 defaulttank bootfs - defaulttank delegation on defaulttank autoreplace off defaulttank cachefile - defaulttank failmode wait defaulttank listsnapshots off defaulttank autoexpand off defaulttank dedupditto 0 defaulttank dedupratio 1.00x -tank free 195M -tank allocated 324K -tank readonly off -

青い文字はSolaris 10 9/10から追加された属性


ZFSのバージョン% zpool upgrade -v (略)VER DESCRIPTION--- --------------------------------------------------- 1 Initial ZFS version 2 Ditto blocks (replicated metadata) 3 Hot spares and double parity RAID-Z 4 zpool history 5 Compression using the gzip algorithm 6 bootfs pool property 7 Separate intent log devices 8 Delegated administration 9 refquota and refreservation properties 10 Cache devices 11 Improved scrub performance 12 Snapshot properties 13 snapused property 14 passthrough-x aclinherit 15 user/group space accounting 16 stmf property support 17 Triple-parity RAID-Z 18 Snapshot user holds 19 Log device removal 20 Compression using zle (zero-length encoding) 21 Deduplication 22 Received properties

23 Slim ZIL 24 System attributes 25 Improved scrub stats 26 Improved snapshot deletion performance 27 Improved snapshot creation performance 28 Multiple vdev replacements 29 RAID-Z/mirror hybrid allocator 30 Encryption 31 Improved 'zfs list' performance

Solaris 10 9/10 (ただし重複排除はできない)

Solaris 11 Express 2010.11

ZFSのバージョン (機能追加で大抵プールのバージョンが上がる)

• プールのバージョン zpool get version

• ファイルシステムのバージョン zfs get version

• 新機能使用にはアップグレードが必要 (zpool/zfs upgrade)

バージョン間の互換性にも注意

• import対象プールのバージョンをサポートしている必要あり

• LiveUpgradeなどブート環境(BE)を切り替えるような利用時

• 新BEにてプールをアップグレードすると古いBEから起動できなくなる

• 新BEで十分テストしてからプールをアップグレード

• (SZS7000のdeferred updateも同様)

!


重複排除の注意点• Solaris 10 9/10では利用できない

• データセット属性値で有効にした後の書込をオンライン(オンザフライ)で重複排除• 有効にする前に書き込まれたデータは重複排除されない

• 重複判定にCPU、ARC (あふれたらL2ARC、次いでHDD) を消費• # zdb -S <zpool> (事前見積り) (zdb -DD <zpool> で事後確認)

• 重複排除の有効性: dedup ratio > 1.0 (容量節約率の計算はプール単位)

• 重複排除テーブル (DDT) のサイズ: 約 250 bytes x allocated block数

• 大まかな見積り:recordsize=128KB、重複無しの20TBデータ → DDT 32GBrecordsize=8KB、重複無しの1TBデータ → DDT 32GB

• ARCをあふれる場合はL2ARCが非常に効く(典型的なランダムリード)

• チェックサムによるブロック単位での重複判定 (SHA256)

• コリジョン発生確率 2-256 10≒ -77、verifyはさらにbyte単位で比較

• cloneとの組み合わせも検討

• 重複ブロックが多いことが確実でも丸ごとcloneして差分管理する方が有効な場面

• 仮想マシンイメージファイルはclone、パッチ適用時はdedup、等

• 圧縮や暗号化との同時使用も可能

• 書込時: 圧縮→暗号化→チェックサム(重複排除)

!

!

ここにあふれると性能低下!

! !


使用容量プロパティ

• データセットの詳細容量• usedbychildren

• usedbydataset

• usedbyrefreservation

• usedysnapshots

• zfs listでスナップショットも表示させたい場合• プールのlistsnaps属性

# zfs list -o spaceNAME AVAIL USED USEDSNAP USEDDS USEDREFRESERV USEDCHILDrpool 27.0G 6.27G 20.5K 97K 0 6.27Grpool/ROOT 27.0G 4.73G 0 21K 0 4.73Grpool/ROOT/zfsBE 27.0G 4.73G 97.5M 4.63G 0 0rpool/dump 27.0G 1.00G 16K 1.00G 0 0rpool/export 27.0G 60K 16K 23K 0 21Krpool/export/home 27.0G 21K 0 21K 0 0rpool/swap 27.5G 553M 0 41.5M 512M 0

合計

!


共有プロトコルごとのtips

• NFS• sharenfs 属性で設定

• 同期書込が必要な場合はクライアント側でforcedirectio

• Solaris の NFSはカーネル内実装

• NFSv3かNFSv4が使用可能

• CIFS• Solaris 10はSamba経由• sharesmbプロパティはあるが使用不能

• Solaris 11 Express はカーネル内実装CIFSでsharesmb可能• SZS7000も同様

• iSCSI• 基本的に書込は同期となる• 高速デバイスによるslogが効果的

!

!

!


共有プロトコルごとのtips(続き)• iSCSI (続き)• Solaris 10のiSCSI targetはユーザーランド実装 (shareiscsi で設定)

• Solaris 11 ExpressのCOMSTAR port providerはカーネル内実装• SZS7000も同様

• WCE (Write Cache Enabled) 設定

• HDDやHW-RAIDのWCEとより良く協調可能 (Solaris 11 Express)

• 設定手順 (shareiscsiでは設定できない)(→参考情報にリンクあり)

• stmfadm create-lu: backing store を logical unit provider に登録

• itadm create-target: COMSTAR iSCSI port provider に紐付け

• 性能が出ない場合はinitiatorへのログインパラメータの変更も検討• ImmediateDate=yes

• InitialR2T=no

• FirstBurstLength=128K

• MaxRecvDataSegmentLength=128K

• MaxConnections=4 など

!

!


ネットワークでの共有、分散• IPMP• 障害の迂回、出力負荷分散

• 障害検知

• リンク状態の監視

• 検査用アドレスへの検査信号

• リンク集約 (LACPによる)• ポリシーによって使用ポート設定可能

• L2: MACアドレスのハッシュ値

• L3: IP アドレスのハッシュ値

• L4: IPアドレス+ポート番号などのハッシュ値

• L2やL3のみでもクライアント数が多いと均等分散

• クライアントが少ない場合はL2,L3,L4の組み合わせをポリシーとすると均等分散できることが多い

• source aware routing (Solaris 11 Express、SZS7000)• パケットのソースアドレスに応じたインターフェースからの送出

• iSCSI MC/S (Multiple Connection per Session)(Solaris 11 Express)• 1 iSCSI セッション内で複数のコネクションを確立可能

hash(MAC,IP,Port) = ??

0 1 2 3

SolarisのLACP実装(ポリシーにL2,L3,L4を指定したとき)

!


ZFSでデータベースを使う場合

• 一般• データベースの

• 使用する固定ブロックサイズをZFSのrecordsizeと揃える• そもそもrecordsizeとは

• recordsize以上の書込はrecordsize単位で複数のFSBに分割

• recordsize以下の書込はその書込サイズのFSBになる

• 物理メモリ使用量分はARCが使わないように絞る

• slogの書込バイアスプロパティ設定

• より堅牢性重視(redoログなど)

• logbias=latency

• 他に堅牢性をより重視するものがある(テーブルなど)

• logbias=throughput

• 参考情報: www.SolarisInternals.COMのZFS for Databases

!

!

!


ZFSでOracle DBを使う場合の目安

• データファイル• recordsize=8K、logbias=throughput

• redoログ• recordsize=128K、logbias=latency

• インデックス• recordsize=8K-32K、logbias=latency

• バッファキャッシュ(SGA)を大きめにとる場合• primarycache=none,secondarycache=none

• ログライタ• primarycache=none

• 参考情報 : blogs.sun.com/roch/entry/synchronous_write_bias_property

!


ZFSでMySQLを使う場合の目安

• ストレージエンジンごとに異なる

• MyISAM• InnoDBのようなI/O処理機構は無い

• 性能はファイルシステムやストレージに依存

• InnoDB• 様々なI/O処理機構がZFSと重複• 負荷要件により適した方を採用。以下は一般的目安

• slogで高速デバイスを用いる

• recordsize=16K

• ZFS prefetch無効化

• ARCの制限

• InnoDBのダブルライトバッファ無効化

• 参考情報: blogs.sun.com/realneel

!

!


これでもうまくいかない場合

• 負荷要件の精査• ベンチマークツールの負荷と実際の負荷の類似性はどうか

• 何がボトルネックしているのか調査• arcstat, arc_summary.pl, dimstat, vmstat, iostat, netstat, kstat,

DTrace, mdb, SZS7000ならAnalytics

• 禁断(?!)の「Evil Tuning Guide」(www.SolarisInternals.COM)• チェックサムを停止

• ARCサイズを絞る

• 先読みを停止

• デバイスI/O並列度変更

• キャッシュのフラッシュ

• ZILを停止

• メタデータ圧縮しない

これらチューニングの効果を見て

内部で起きていることを検討・確認

他にとるべき方法が無いか検討する材料

!

Solarisには多くのツール!

!


運用管理について

• 障害対応• Solaris ZFSマニュアル

• www.SolarisInternals.COM

• Trouble Shooting Guide

• Oracle Universityコース

• バックアップ• www.SolarisInternals.COM

• ZFS Best Practice Guide

• ZFS in the Trenches

• http://blogs.sun.com/video/entry/zfs_in_the_trenches_ben

• コマンドtips• L2ARCはadd/remove可

• slogはadd/attach/detach可

• データ用ドライブはmirrorのみdetach可

• attachはattach先を指定

• device replaceは1引数版と2引数版がある

• scrub ≠ fsck• scrubはチェックサムの確認

• diff (Solaris 11 Express)• あるsnapshotにrollbackしてよいかの

判断が容易に

• split

• ミラー構成プールを分割

!

!


今回のまとめ

• ZFSサーバーを手作り• 標準設定でも一般的な要件には十分対応可能

• 多様な要件に応えるための柔軟なチューニングポイント

• 実際のシステムでより有効活用するには

• 容量、負荷、可用性、利用方法の要件をできるだけしっかり見積り検討項目を注意点に考慮しながら検討、判断

• 検討項目

• ストレージサーバー

• ストレージプール構成

• ファイルシステム属性値

• 次回「ZFS コマンド実践」(予定)

!


今回分の参考情報

• http://www.solarisinternals.com/• ZFS Best Practice Guide

• ZFS for Databases

• ZFS Configuration Guide

• ZFS Trouble Shooting Guide

• ZFS Evil Tuning Guide

• blogs.sun.com/• bonwick, roch, realneel,

perrin,mrbenchmark, timthomas, ..

• fishworks, mws, bmc, ahl, breadan, ..

• Solaris 11 Express iSCSI設定• http://wikis.sun.com/display/OpenSolarisInfo/

How+to+Configure+iSCSI+Target+Ports

• http://www.slideshare.net/satokaz/comstar-comstar

• SZS7000情報• http://www.oracle.com/us/

products/servers-storage/storage/unified-storage/index.html

• ホワイトペーパー

• Oracle、MySQL等

• SZS7000シミュレータ

• ZFS第一弾、第二弾、第三弾


ZFS シリーズ共通参考情報

• 参考情報リンク集

• 解説記事、アーキテクチャ、ソースツアー、デモ、マニュアル、構築時の参考情報、blog、事例、書籍

• Oracle Universityコース• Solaris 10 ZFS管理 (SA-2290-S10)

• ZFSの機能、プールとファイルシステム管理、スナップショットとクローンの操作、ACL、トラブルシューティング

hiroa blog zfs 検索からリンクしました!


OTN×OTN×ダイセミ　でスキルアップダイセミ　でスキルアップ !!!!

Oracle Technology Network(OTN)を御活用下さい。

・一般的な技術問題解決方法などを知りたい！・セミナ資料など技術コンテンツがほしい！

http://www.oracle.com/technology/global/jp/index.html (日本)http://www.oracle.com/technetwork/index.html (global)

過去のセミナ資料、動画コンテンツはOTNの「OTNセミナーオンデマンドコンテンツ」へ

http://www.oracle.com/technology/global/jp/ondemand/otn-seminar/index.html

※ダイセミ事務局にダイセミ資料を請求頂いても、お受けできない可能性がございますので予めご了承ください。　　ダイセミ資料はOTNコンテンツ　オン　デマンドか、セミナ実施時間内にダウンロード頂くようお願い致します。

Solaris技術情報はこちらに統合！「System Admin and Developers」(global)

※日本サイトは現在統合作業中です。旧 SDC のコンテンツは http://www.oracle.com/technology/global/jp/sdn/solaris/index.html よりアクセス可能です。


OTNOTNセミナー　オンデマンド　コンテンツセミナー　オンデマンド　コンテンツダイセミで実施された技術コンテンツを動画で配信中!!

ダイセミのライブ感はそのままに、お好きな時間で受講頂けます。

※掲載のコンテンツ内容は予告なく変更になる可能性があります。　期間限定での配信コンテンツも含まれております。お早めにダウンロード頂くことをお勧めいたします。

OTN　オンデマンド

最新情報つぶやき中　oracletechnetjp・人気コンテンツは？・お勧め情報　・公開予告　　など


Oracle エンジニアのための技術情報サイト

オラクルエンジニア通信http://blogs.oracle.com/oracle4engineer/

• 技術資料• ダイセミの過去資料や製品ホワイトペーパー、スキルアップ資料などを多様な方法で検索できます

• キーワード検索、レベル別、カテゴリ別、製品・機能別

• コラム• オラクル製品に関する技術コラムを毎週お届けします

• 決してニッチではなく、誰もが明日から使える技術の「あ、そうだったんだ！」をお届けします

オラクルエンジニア通信

最新情報つぶやき中

　oracletechnetjp

こんな資料が人気です 5ヶ月連続で「RAC/ASMインストール資料」が第一位。根強い人気のチュートリアル系コンテンツですが、新たに「Oracle Enterprise Managerインストール資料」が第四位にランクインしました。

パフォーマンス・チューニング　コンテンツを集めた特集ページも好評です。

http://blogs.oracle.com/oracle4engineer/


■パフォーマンス診断サービス•Webシステム　ボトルネック診断サービス•データベースパフォーマンス診断サービス

オラクル社のエンジニアが直接ご支援しますお気軽にご活用ください !

オラクル　無償支援検索

NEW ■システム構成診断サービス•Oracle Database構成相談サービス•サーバー統合支援サービス•仮想化アセスメントサービス•メインフレーム資産活用相談サービス•BI EEアセスメントサービス•簡易業務診断サービス

■バージョンアップ支援サービス•Oracle Databaseバージョンアップ支援サービス•Weblogic Serverバージョンアップ支援サービス•Oracle Developer/2000(Froms/Reports)Webアップグレード相談サービス

■移行支援サービス•SQL Serverからの移行支援サービス•DB2からの移行支援サービス•Sybaseからの移行支援サービス•MySQLからの移行支援サービス•Postgre SQLからの移行支援サービス•Accessからの移行支援サービス•Oracle Application ServerからWeblogicへ移行支援サービス

ITプロジェクト全般に渡る無償支援サービス

Oracle Direct Conciergeサービス

NEW

NEW


http://www.oracle.co.jp/inq_pl/INQUIRY/quest?rid=28

Oracle Direct 検索

あなたにいちばん近いオラクル

Oracle Directまずはお問合せくださいまずはお問合せください

Web問い合わせフォームフリーダイヤル専用お問い合わせフォームにてご相談内容を承ります。

※フォームの入力には、Oracle Direct Seminar申込時と同じ　ログインが必要となります。※こちらから詳細確認のお電話を差し上げる場合がありますので、　ご登録されている連絡先が最新のものになっているか、　ご確認下さい。

0120－155－096　※月曜~金曜　9:00~12:00、13:00~18:00

　　（祝日および年末年始除く）

システムの検討・構築から運用まで、ITプロジェクト全般の相談窓口としてご支援いたします。

システム構成やライセンス/購入方法などお気軽にお問い合わせ下さい。

http://www.oracle.co.jp/inq_pl/INQUIRY/quest?rid=28

oracle direct seminar … · flashデバイスの検討 • 「今まで dram, hdd, tape...

Documents