koie blog : いってきた: 第10回 FreeBSD勉強会ストレージの管理: GEOM, UFS, ZFS 基礎後編

http://atnd.org/events/30273
資料: (そのうちuploadされるはず)
http://togetter.com/li/361800

トラブル

プロジェクターにスライドがでてこない。プロジェクターをリブートしたらうつった。

[2012-08-24 18:47]

ここ1年半くらのトラブルを経験したマシンがある。
半導体のことを大学で教えている。たいていツールはUNIXでしか動かない。半導体の先生は情報工学を学んでないのでボタンが3つ以上あるとつかえない。学生は自分でUNIXを学ばなければならない。
UNIXの伝統:デバイスは特殊ファイルとして見える。
GEOMで使いやすくした。

性能

記憶装置の性能: かかる時間=データ待ち時間+データ転送時間
USB3対応メモリ8GB(700円くらい)。60MB/sでつかえると書いてある。
まずカーネルの性能を知っておかないといけない: dd if=/dev/zero of=/dev/null s=1024x1024 bs=80
1024x1024と書くのがPOSIX的に正しい(ポータビリティが高い)
dd if=/dev/da2 of=/dev/da3 bs=1024x1024 count=80 → 8MB/s
dd if=/dev/da2 of=/dev/null .. 読むだけなら速いはず → 23.5MB/s
dd if=/dev/zero of=/dev/da3 .. → 12.4MB/s ?? 8MB/sじゃない!!
read:23.5MB/s + write:12.4MB/s = rw 8MB/s
デバイスの待ち時間ができるので遅くなる。
ddを2つ3つと並列で動かすと待ち時間が減るので速くなる。
データ転送速度とIOPS(処理遅延)に分けて評価すべし。
iostat: OSによって微妙にフォーマットが違う。
- iostat -x da2 -w 1
- svc_t: サービス待ち時間 (転送サイズが同じならほとんど変わらない:一定)
- カーネルソースコードが読めないときには統計情報から転送サイズを読み取るしかない。
測定データとIOPSと想定したアクセスパターンをつきあわせてみる。
家庭用一般向けの消費電力の少ないHDDは回転数は落して転送サイズは大きくして転送速度を稼いでいる。
アクセス時間 = 固定時間 + データ量依存時間: アプリケーションが最大負荷のときにiostatで統計をとる。
IOPS=1000なら1万i-nodeをアクセスするのに10秒かかる。(ls -lとかで差がでる)
- 1メール1ファイルのようなメールシステムとか。
キャッシュが効きやすいようなファイルレイアウトにするとか。
UFS_DIRHASH: vfs.ufs.dirhash_maxmemを大きくするとi-nodeキャッシュが改善する。
BSD系OSは64KiBが基本転送サイズ。これを大きくしてもそれほど性能がかわらないことが経験的に知られている。
dd bs=で1MiBで指定してもカーネルが64KiBに分割してしまう。
iostat の %b は利用率。100%になってないと限界までつかってない。
GEOM用のstatもある。ミラーしたときの末端のデバイスの性能だけではなくGEOMの性能も知りたい。

gmirrorの設定

システムディスクのハンドブックの記述はまちがっている。
まず1台(ada1)だけのミラーをつくってada0の内容をコピーする。そのあとリブートしてada0をミラーに組み入れる。これが一番安全。ダウンタイムが短かい。シングルユーザに落ちなくてもリモートからできる(ただし失敗したらアウトだが)。
パーティションの末尾に512Bのgmirrorの情報を書くが、空きがないとこまる。ディスクを使い切ることはめったにないが。(近いうちにちゃんとハンドブックに書くよ)
ハードディスクをホットスワップできるかはハードウェアの仕様できまる。
BIOSはミラーされてるかどうか知らないので、障害時にブートデバイスを変えないといけないかも。ソフトウェアRAIDなのでOSの世界から抜けるとミラーじゃなくなってしまう。
ルートパーティションだけにしちゃう一派 → CDROMもUSBメモリも使えないサーバがたまにある。そうなるとディスクをひっこぬくしかなくなる。
/ と /usr はreadonlyにして運用するというとはよくやる。書き込むのは/varのみに。そうしておくとミスオペ(rm -rf /)に耐えられる。
オススメ:
- / = 3GB
- swap = メインメモリ以上
- /var = 30GB
- /usr = 20GB
- /tmp = 1GBのメモリディスク
- 残り = サービスに必要な容量
クラッシュダンプはswapに書き出される。パニックしたときにファイルシステムは信用できない。

RAID0,1,3

アクセスパターンを再現できるツールをつかう。(最初に乱数でアクセスパターンを生成して、違う構成での性能を比較する。)
RAID3はRAID5とちがってパリティディスクが固定されて、ストリーミングのような連続書き込みが速くなる。
gmirrorにはreadのストライピングの戦略を選べる。
ソフトウェアRAIDは単発でつかったときに性能が上がるのか下がるのか。geomはそんなに悪くない。

HAST

GEOMベースでgmirrorの動きをするネットワーク越しに動作する。
VRRPやCARPと組み合せると片側だけでも動けるようになる。
/etc/hast.confに書く。両方のマシンに同じ設定ファイルを置く。
/dev/hast/〜にデバイスができる。
UCARP(ユーザランドのCARP実装)をHASTとつかうと便利。
実績はある。暗号化して共有するのもgeomでできる。

ZFS

従来: デバイス→ボリュームマネージャ→ファイルシステム
ZFS: ZPOOL→DMU→ZFS
- たくさんのデバイスがあったときにスケーラビリティを達成する。HDDが2台3台じゃ旨みがない。
- 堅牢性とかはおまけ。
- クラスタファイルシステムではない。
- 既存ファイルシステムの欠点(アカデミックなこととか)はたいていつぶしてある。
ZPOOLでできることは既存のボリュームマネージャとできることはかわってないが組み込まれているところがちがう。
ZPOOLの上にデータセットをつくれる。データセットとはファイルシステムとか。
geomがzpoolにおきかわったと見ればよい。
dnode: inodeみたいなもの。ZFSのデータセットを構成する。UFSとはちがって固定的な場所はない。
DMU: data management unit. dnodeを操作するカーネル部分。
VDEVラベル: L0,L1,L2,L3: スーパーブロック相当。1こ128KiB。前後512KiBをつぶせば認識されなくなる。
ラベル=ブートラベル、ZAPオブジェクト、UB0..127。
MOS(Meta Object Set): dnodeの配列がふくまれている。
リンクをつくるときはかならずコピーがつくられる→堅牢性のキャッチコピーはここから
tank : マトリクスから。
ファイルシステムもdnodeで管理してファイルとディレクトリもdnodeで管理するという二段になった点だけが違う。
コピー3とリンクの途中にログを入れるところが違うくらい。
CoW: 書き換えないでコピーする。でも欠点にもなる。
ZFSはUFS以上にリンクをたくさん辿るのでdnodeアクセス性能に敏感になる。複数のディスクに分散することで回避することになっている。
CoWだと書き込みも読み込みを伴うので書き込みつづけるということができない。
1つのファイルをランダムライトするようなアプリは遅くなる。原理的に回避不可能。書く前に読むアクセスパターンだらけなので性能が100%出ない。トランザクショングループにまとめて書く回数を減らすようにしているが、メモリ上にたくさん覚えておく必要がある。
tips
- amd64: メモリが使えないことのほかに、i386はアクセス効率(MMU)が悪い。
- vfs.zfs.vdev.cache.size=0: ほとんど効かないのでメモリのムダ。将来的にこの項目はなくなる予定。
- vfs.zfs.vdev.cache.bshiftは小さいIOをまとめる設定 (default 64Kib(16))。アクセスパターンによって変えるとよい。
- vfs.zfs.arc_meta_limitを設定してdnodeキャッシュを稼ぐ。データ量/(8KiB*128B)。ざっくり1TB=16GBくらい。
  - データアクセスが中心なのかfindするようなメタデータ中心なのかでちがってる。読む方はキャッシュを積めが改善する。

ZFS構築事例

allbsd.orgを生贄に。
IOPSをみる。
writeは5秒に1回になるように設定している。デフォルトは10〜15sだが性能が落ちるので短かくした。アプリによるので測ってみるしかない。IOPSに余裕があれば細かく書くようにすればよい。
120Mbps:内部向けファイルサーバとして
20Mbps:外向のサービス
パーソナルで使うくらいならチューニングしなくてもつかえる。
FreeBSD9以降は大きなトラブルはないとおもってよい。
たくさんのディスクを載せてなければ性能がおちる。

[2012-08-24 21:13]

QA

Q: GPTでパーティションをきった理由は
A: ブートできるように。p1だけをつかう。gmirrorをつかうときにサイズをあわせるためにそうしてただけ。
Q: SSDがつかわれるようになってきたが。
A: UFSにはハードディスク前提の最適化としてシリンダーグループがある。でもハードディスクの内部で順番に並んでるとは限らない。UFS2ではシリンダーグループはなくなった。SSD向けにファイルを消したときにTRIMが出るようになっている(UFSのみ)。ZFSもTRIM対応される予定。GEOMレベルで入るらしい。

ZFS: SUNが手を引いてOracleが2年以上ソースを出さなくなった。illumosに開発者が移動している。商用のデバイスをそのコードをつかって商売していて、FreeBSDに入ってきている。FreeBSDのコミュニティーに技術がたまってきているので突然消えたりしないので安心して。

[2012-08-24 21:24]