Downloaded 51 times
![確認・変更方法
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](https://image.slidesharecdn.com/osc-do2011-110614005415-phpapp01/85/Osc2011-Do-20-320.jpg)
Osc2011 Do
- 1. 自宅SAN友の会 サーバ仮想化のためのストレージシステム入門 今更聞けないストレージの基本 1 Origine Uploaded by Angelina :) http://www.flickr.com/photos/angelinawb/1085267480/
- 2. 自己紹介 はら かずひさ Twitter：kazuhisya 横浜市民 普段は某社で仮想化関連技術を軸に、 社内講師やら技術検証、御用聞きなんかしてます。 OSC出没率高し 2
- 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.
- 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.
- 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 BackedWrite Ｃａche – バッテリーバックアップ付きライトキャッ シュ • ＲＡＩＤコントローラーに付けるキャッシュ装置 • 耐障害性を維持しつつ、書き込み性能を上げる事 が出来る • RAIDカードとＨＤＤ本体の間で働く • エントリークラスで128～512ＭＢ程度はある – キャッシュに乗り切るサイズであれば、ＯＳ 側からfsync() などの同期書き込みが実行さ れても、キャッシュに高速に保存できる(その 29 後よしなに実ＨＤＤに書かれる)
- 30. ＢＢＷＣ • その後よしなに実ＨＤＤに書かれる？ –よしなに、とは • デバドラに依存するが • アクセス効率が良くなるように • ある程度まとまった単位で書かれる – ある程度まとまった単位 • シーケンシャルに読める可能性が高い • Ｄｉｓｋの回転、つまりコミット待ち発生を抑え ることが出来る 30
- 31. ＢＢＷＣを使うとき気にすること • Q. ＢＢＷＣを使う時、ＨＤＤ自体のキャッシュはどう なるの？ • A. ＨＤＤ側のキャッシュはＯＦＦにしておくこと – ＲＡＩＤコントローラーのコマンドでＯＦＦに出来る – arcconfやＢＩＯＳなどでどうぞ • Q. なんでＨＤＤ側のキャッシュはＯＦＦの方がいい の？ • A. HDD側のキャッシュにはバッテリー乗っていない よ！ キャッシュ書ききる前に電源落ちたら、他も巻き 31
- 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