1. 自宅SAN友の会
サーバ仮想化のためのストレージシステム入門
今更聞けないストレージの基本
1
Origine Uploaded by Angelina :) http://www.flickr.com/photos/angelinawb/1085267480/

2. 自己紹介
はら かずひさ
Twitter：kazuhisya
横浜市民
普段は某社で仮想化関連技術を軸に、
社内講師やら技術検証、御用聞きなんかしてます。
OSC出没率高し
2

3. ストレージってなんだっけ
SANを始める前の基礎情報
3

4. ストレージって何だっけ
• ストレージ
– 単に『ストレージ』といった場合、いろいろ意味がある
• DASストレージだとか
• NASストレージだとか
• SANストレージだとか
• 胃腸薬だとか
– 凄く乱暴な言い方をすると
• 基本的に永続利用の(メモリと違って再起動しても消えないよ)
– 補助記憶装置だとか二次記憶装置とかとも言う
• ハードディスク
• SSD
• もしくは上記を束ねたやつを、OSやらアプリやらから、何かしらの
形で使えるようにしたもの
4

5. 最近の流行
兎にも角にも、SSD
5

6. SSDがやっぱ速い、とは言え・・・
• オールSSDでサービスを組むようになるに
は、まだ時間が掛かると思われる
– それなりに高額
– 安いやつは信頼性が・・・
– 容量の問題
• いずれ解決される・・・ハズ？
6

7. ここから本題
わりかし一般的に業務で使われる
HDDのチューニング
7
Origine Uploaded by autumn_bliss http://www.flickr.com/photos/autumn_bliss/198493795/

8. HDDの性能指標
• アクセスに掛かる時間
– 下記3つをあわせた時間
• シーク待ち時間
• 回転待ち時間
• 転送時間
– 実は基本情報に出てくる
8

9. ハードディスクの見方
• 大きさ • I/F
– 3.5 / 2.5 / 1.8インチなど – 接続する線の形式(線とは限らな
– サーバでは主に3.5、時々2.5イン いけど・・・)
チ – サーバでは、SAS、もしくは
SATA2が一般的
• 回転数 • ディスク枚数
– 回転毎分 (rotation per minute) – 円盤の枚数
– 1分間に、何回円盤をまわせるか
• シークタイム
• キャッシュ – ディスクヘッドが円盤の目的の部
– 円盤から読み出したデータを一時 分に移動するのに要する時間
的に記憶したり – これが短いほど、一般的には速い
– 書き込むデータを円盤に書く前に HDDということになる
一時的に置いたりする
– 多い方が速い！とは限らないので
注意
9

10. インターフェースの話
• 要は線の話(PIC-Exとかもあるけど)
– 繋ぐ形式によって、限界が制限される
• これに制限されるHDDは割と稀(SSDは簡単に超えたりする)
– たとえば
• SATA(Serial Advanced Technology Attachment)
– SATA-150: 1.2 Gbit/s (150 MB/s)
– SATA-300: 2.4 Gbit/s (300 MB/s)
– SATA-600: 4.8 Gbit/s (600 MB/s)
– SATA-300(SATA2とも言う)がデスクトップPCやエントリー
サーバに多い
• SAS(Serial Attached SCSI)
– SAS 1.0: 3.0 Gbit/s (300 MB/s)
– SAS 2.0: 6.0 Gbit/s (600 MB/s)
10

11. ディスクアクセスの時間の感覚をつかむ
• ざっくりアクセスに掛か
る時間の感覚
– CPU: 8ns(ナノセック)
– メモリ: 50ns
– NIC: 0.1ms (ミリセック)
– HDD: 5ms
• かなりいい加減な数字
• それでもCPUやメモリに比べ
て10～100万倍オーダーで
遅い
– シークタイムが 5msだと
すると、1秒当たり200回
アクセスできる 11

12. シーケンシャルとランダムアクセス
• シーケンシャルアクセス
– データを特定箇所から順に読み/書きする
– つまり円盤を普通にまわし、順繰りに読み書きすれば
よろしい
– アクセスしやすいので速い(≒カタログスペック)
• ランダムアクセス
– 読み書きしたいデータの場所をインデックスなどの位
置情報をもとに割り出し、直接その場所にアクセスす
る方法
– つまり目的の箇所を探し出して、違うところは読み飛
ばさなければならない
– 要は遅い 12

13. シーケンシャルとランダムアクセス
シーケンシャルアクセス ランダムアクセス
13

14. 回転待ち時間
• 回転待ち時間を求める
– シークタイムはカタログスペックに載ってい
る
– 回転待ち時間は？
– 基本情報の対策本とかに載ってるよ！
– 例: 7200rpmのSATA
• 7200 / 60秒 = 120回転
• 半回転だとざっくり240回/秒アクセスできる
– アクセス、というは物理的な意味
14

15. HDD単体での性能
• シークタイム、回転待ち時間が特に重要
– 要は
• シークタイムが短く
• 回転数が多い
– ものを選べ、ということ
• Why？
– A. どんなに頑張っても、H/Wの限界性能以上
はOSやミドルをいじっても出すことは出来な
いから
• あんましエコではない
15

16. そんなに単純じゃない現実
I/Oスケジューラーも、ファイルシステムも、
あるんだよ
16

17. Linux Kernel
I/Oスケジューラ
17

18. Linux KernelのI/Oスケジューラ
• I/Oスケジューラってなんぞ
– HDD(ブロックデバイス)に対して、アクセス
要求が来るたびに、正直に都度アクセスする
のではなく、シーク待ちや回転待ちを最小化
するよう、並び替えたりキューイングする機
能
18

19. 種類
• メジャーどころで３種類
– cfq (Completely Fair Queuing)
• RHEL系はこれがデフォルト
• 特定プロセスにI/O要求が偏るのを防ぎ、他のプロセスにも
I/Oが振り分けられるように調整
– deadline
• 読み/書きのI/Oをバランスよく処理する(≠プロセス単位)
• 他のスケジューラは、読み/書きでは区別していない
• 仮想化やDBサーバでお勧め(KVMの推奨スケジューラ)
– noop
• 『I/O要求を物理Disk上に配置する』こと以外は特に行わな
い
• スケジューリングをしない、という事(＝スケジューリング
のオーバーヘッドが発生しない)
• 自前でスケジューリングできるDBや、H/Wで行えるタイプ
のストレージやSSDを使うとき有利 19

20. 確認・変更方法
1. 確認方法
# cat /sys/block/sda/queue/scheduler
noop [deadline] cfq
[ ]でくくられているのが今のスケジューラ
2. 変更(一時的)
# echo noop > /sys/block/sda/queue/scheduler
3. 変更(永続)
• grub.conf の kernel行 に elevator=deadline を追記
20

21. Linux
ファイルシステム
21

22. Linuxのファイルシステム
• よく使われるメジャーどころ
– ext系
• ext2: 最近はあまり見ない
• ext3: 大体これが多い、RHEL5デフォルト
• ext4: 最近だとこちら、RHEL6デフォルト、後方互換性が高い
– XFS
• RHEL５だとオプション扱い(別料金)
• ファイルレベルでなく、FSそのもにダイレクトアクセスできる(高
速)
– btrfs
• Solaris ZFSの対抗馬的なモダンFS(スナップショットなど)
• 非常によろしい、らしいけど商用で使うにはまだ時期尚早(?)
– 他にも
• JFS, ReiseFSなども
• btrfs, NILFS2, Cephなど、最近はFSまわりは活発 22

23. ジャーナリングファイルシステム
• ext3, ext4, XFS…
– ジャーナリングファイルシステム
• ファイルシステム上のメタデータを書き換え処理
（トランザクション）単位で管理・保持する事が
できる
• 書き換え中に電源断や処理中断が発生し、ファイ
ル構成情報に矛盾が発生した場合でも、素早く検
査/修復処理を行うことが出来る
– ext2にはジャーナルがない
23

24. ext3のジャージャーナリング方式
• 基本的には3種類
– writeback
• メタデータのみをジャーナリング対象とする
• ジャーナリング順は保障されない
• ファイル消失は防げるが、データ消失リスクはある
– 全て更新か、全く更新が無いか、しか判別できない
• 最も高速
• いつの間にかデフォルトになった模様
– orderd
• メタデータのみをジャーナリング対象とする
• ジャーナリング順を保障する
• writebackよりも若干信頼性が高い
– journal
• 実データもジャーナリング対象とする
• fsync() や fdatasync() を発行した所までは完全に保障される
• 最も低速 24

25. ext系チューニング
• 代表的なチューニング項目(マウントオプション)
– dir_index
• DBのインディックスとほぼ同じ働き
• ファイル数が多すぎるとパフォーマンスの逆転現象が起こりうる
– noatime
• 最終アクセス時刻の記録を止める
– 作成時刻、更新時刻、アクセス時刻
• 更新時刻がアクセス時刻を追い越す罠
– 特定のアプリケーションで不具合あり
– relatime(kernel 2.6.20～)
• 更新時刻(mtime)やファイル属性の修正時刻(ctime)が、最終アクセ
ス時刻を追い越したときに、atimeを修正する
• noatimeよりもお勧め、デフォルトで有効になるディストリが多い
– discard
• ext4,SSD用オプション
• RHEL5.6 + ext3 では使えた
• ATAデバイスにはTRIMコマンド、SCSIデバイスにはUNMAPコマン 25
ドを発行する

26. RAIDのおはなし
一般
26

27. RAIDの話
• RAID
– ハードウェアRAID
• いわゆるカードもの PCI-Express接続とか
• マザーボードの機能として付いてるものも
– 廉価版は、ソフトウェアRAIDな場合も・・・
• 専用のコントローラーが処理する
• ライトキャッシュ(BBWC)が付いている事が結構あ
る
– ソフトウェアRAID
• 一般的にはOS側で束ねるRAID
• CPUが処理する
27

28. RAIDのおはなし
BBWC
28

29. BBWC
• Battery Backed Write Ｃａche
– バッテリーバックアップ付きライトキャッ
シュ
• ＲＡＩＤコントローラーに付けるキャッシュ装置
• 耐障害性を維持しつつ、書き込み性能を上げる事
が出来る
• RAIDカードとＨＤＤ本体の間で働く
• エントリークラスで128～512ＭＢ程度はある
– キャッシュに乗り切るサイズであれば、ＯＳ
側からfsync() などの同期書き込みが実行さ
れても、キャッシュに高速に保存できる(その
29
後よしなに実ＨＤＤに書かれる)

30. ＢＢＷＣ
• その後よしなに実ＨＤＤに書かれる？
– よしなに、とは
• デバドラに依存するが
• アクセス効率が良くなるように
• ある程度まとまった単位で書かれる
– ある程度まとまった単位
• シーケンシャルに読める可能性が高い
• Ｄｉｓｋの回転、つまりコミット待ち発生を抑え
ることが出来る
30

31. ＢＢＷＣを使うとき気にすること
• Q. ＢＢＷＣを使う時、ＨＤＤ自体のキャッシュはどう
なるの？
• A. ＨＤＤ側のキャッシュはＯＦＦにしておくこと
– ＲＡＩＤコントローラーのコマンドでＯＦＦに出来る
– arcconfやＢＩＯＳなどでどうぞ
• Q. なんでＨＤＤ側のキャッシュはＯＦＦの方がいい
の？
• A. HDD側のキャッシュにはバッテリー乗っていない
よ！ キャッシュ書ききる前に電源落ちたら、他も巻き 31

32. RAIDのおはなし
ストライピングサイズ
32

33. ストライピングサイズ
• ストライピングサイズ/チャンクサイズ
– 複数のＤｉｓｋにストライプする際のデータ
分割単位、のこと
– 通常4kb～1MB程度の範囲
33

34. ストライピングサイズ
• ストライピングサイズが小さすぎると・・・
– 1ブロックが複数ディスクに跨って配置されてしまう
– 1ブロックを読み出すのに、複数アクセスする必要が
ある
– 複数アクセスを同時に行うから、速いのでは？
• 1ＨＤＤ / s あたりのランダムアクセスできる回数には上限
がある
• スループットが下がる
• 1ブロックの読み込みは、1アクセスで済ませるべき
• ストライピングサイズが大きすぎると・・・
– こんどはシーケンシャルが遅くなる
34
• 分散読み込みできないから

35. ストライピングサイズの勘所
• 要はどの数値にするのがいいか
• 残念ながら要件次第
– シーケンシャルアクセスが多い
• 若干小さめに取る
– 例えば、4KB, 16KBなど
– ランダムアクセスが多い
• ブロックサイズより大幅に多く取る
– 例えば256ＫＢ, 512ＫＢなど
35

36. おわりに
36

37. おわりに
• 他にも考えることは、もっともっとあります
– RAIDレベルは？NCQは？キューザイズは？etc…
• なので
– H/Wを良く知ろう
• 限界性能を知る
– Blogのコピペも良いけど、”何故そうなのか”も考
えてみる
• ドラスティックにパフォーマンスに変化が出るような
ものには、得てしてデメリットもあるものです
37

38. まとめ
• 慣れないことを本番環境でいきなりやるのはつらい
• 懐具合と相談すれば、わりかしそれっぽい環境はできる
• もちろんどう考えてもできないものある
• 特にLinux周りのスキルはコストをあまりかけずとも習得
しやすい
• というわけで、主に自宅で(←SAN友の趣旨)検証し
てみましょう
38

39. おわり
続きは懇親会で！
39