- 2012-12-07 19:05〜22:22
- 資料: http://people.allbsd.org/~hrs/FreeBSD/sato-FBSD20121207.pdf
- まとめ: http://togetter.com/li/419312
夕方に大きな地震があったが、ちょっとダイヤが乱れたくらいで、勉強会は開催。
ZFSの活用とチューニング
使い方(前半)
- FreeBSD9.0/9.1はチューニングしなくてもそこそこ性能はでる。アプリによっては性能が落ちるポイントがある。
- ZFSはハードディスクがいっぱいつながっているのが大前提。1台だとうれしいことはなにもない。
- ZFSは既存のファイルシステムのいいとこどりしている。トレードオフになっているところはCPUなどマシンパワーで解決する。
- zpool = ストレージプール = ブロックデバイスのあつまりに名前をつけたもの
- ZFSデータセット = ZPOOL上に構成できる名前空間 = ファイルシステム/ボリューム/スナップショット
- FreeBSDにはOpenSolarisのコードそのまま取り込まれた。ライセンスはBSDに近いものなので取り込んでも困ることはないもの。
- StoragePoolAllocator(SPL)のバージョンン: ミラーとか重複排除とかが関係。今は28。
- ZFS POSIX Layer(ZPL)のバージョン: ユーザからはあまりみえないが、カーネルとのAPI。今は5。
- この2つのバージョンで使える機能を判断する。
- OpenSolarisは虫の息...
- OpenSolarisはだんだんオープンじゃなくなってきている。もう1年半以上あたらしいコードが出てない。
- Nexenta: illumosをベースにしたストレージを出してた。ソフトだけで商売しようとしてる人たち。
- いろいろZFSのforkができたが、
- illumos projectがZFSのコードのとりまとめをしてくれそうな感じ。
- FreeBSDのZFSは9系か8.3以降を使うべし。それ以前は落とし穴がいっぱいある。
- マシンはamd64 RAM=4GB以上。1GBでは性能が出ないし止まってしまう可能性もある。
- ZFSの管理が簡単になるというのは、いままでコマンドラインでUFSをさわってた人にはあまり簡単になったとは思えないかも。
- FFSのスナップショットはつかいものにならないがZFSのはつかえる。
- jailの中からでもファイルシステムの安全に操作できるのがメリットの1つ。
- ZFSはライセンス汚染を避けるためにモジュールになっている。使おうとした瞬間にロードされる。明示的に設定しなくてもよい。
- zpool create pool da1 da2 でプールをつくったらすぐに/poolがつかえるようになってしまう。
- ストライピング幅は動的に決まる。
- zfsがマウントされるのは、プールが認識されたらすぐにマウントされる。/etc/fstabは見ない。
- zfs_enable=YESが評価されてプールが認識されるのは/etc/fstabを見るよりも前。
- zpool destroyでデータも全部消える。確認はない。
- "zfs create プール名/データセット名" でファイルシステムができる。ファイルシステムのサイズは指定されてないことに注意。複数ファイルシステムをつくったらシェアされる。
- データセットは階層構造をもっているが、マウントポイントの階層構造はそれとは関係なく設定できる。
- 設定は設定ファイルではなくプロパティにはいっているのでコマンドをバンバンたたいていく。(Solaris流儀)
- "zfs snapshot プール名/データセット名@スナップショット名" でスナップショットがつくれる。スナップショット名は自由に決められる。
- スナップショットをつくってもマウントポイント設定されない。ディスクの使用量USEDは0。スナップショットの一覧は "zfs list -t all" でみえる。
- スナップショットは "zfs set snapdir=visible" にしておくと.zfsの下にみえるようになる。
- "zfs rollback プール名/データセット名@スナップショット名" でスナップショット時点の内容に戻る。
- "zfs clone プール名/データセット名@スナップショット名 プール名/新データセット名" でファイルシステムの複製をつくれば容量をつかわずに複製がつくれる。(スナップショットは書き込みできないのでcloneする必要がある)。
- 微妙に設定がちがうシステムディレクトリをつくるときとか。jailで便利につかえる。
- クローンというデータセットがあるわけではなく、あくまでもファイルシステムとスナップショットの合わせ技でしかない。
- バックアップはzfs sendでできる。
- 従来のファイルシステムではスナップショットやチェックポイントをネイティブでもっているものは少ない。
- fileコマンドはsendの出力をしっているので、スナップショットの作成日などが表示される。
- zfs recvでリストアできる。zfs cloneとちがって本当の複製。
- "zfs send -p" でプロパティもバックアップされるがマウントポイントの設定も保存されてしまうので、
- "zfs recv -u" で自動マウントされれないようにすべし。(なんで自動マウントがデフォルトなのかは知らん。)
- zfs destroyはスナップショットがあると消せない。destroy -rでまるごと消せるが注意して。
- "zfs create -V サイズ プール名/データセット名" でボリュームがつくれる。"/dev/zvol/プール名/データセット名" として見える。
- ZFSをボリュームマネージャとしてつかうことができる。
- ボリューム上にファイルシステムをつくっておけばブートシーケンスで、ZFSが読み込まれたあとに/etc/fstabでマウントできる。
- send/recvもできる。つかってるブロックだけをバックアップできる。
- ディスクの中にストレージプールの情報が入っているが起動時に全部のディスクを読んでたら時間がかかるので、/boot/zfs/zpool.caccheにも書いてあるが、これが壊れていると起動できなくなる。(つくりなおすことは可能)
[2012-12-07 20:06]
休憩
いつもはぶっ通しでダレてくるので今回は途中で10分休憩を入れることに。
[2012-12-07 20:15]
使い方(後半)
- UNIXは設定ファイルの文化だがSolarisはコマンドで設定データベースをいじる文化になっていった。
- ファイルシステムはかならず2レベルにすること。プール名とおなじデータセットは使わない。スナップショットやバックアップをとるときにめんどくさい。
- zfs set mountpoint=none poolと設定すればマウントされなくなる。
- zfs recvのときにsendしたときと同じ場所に戻せないので困る。"zfs send pool@snap | zfs recv pool" はできない。"zfs send pool@snap | zfs recv pool/pool2" はできる。
- zfs send -Iでスナップショット間の差分バックアップができる。
- zfs sendでパスワードファイルもそのままはいってしまうので暗号化できる経路をつかうべし。
- zfs sendが遅い原因の1つはファイルシステムを読みながら出力するので連続的に出てこない。gzipはブロック単位に処理するのでsshにスムーズにデータが流れない原因になる。
- ddを二段接続してバッファリングしてgzipが暇にならないようにする→gzipの出力に隙間が空かないようにする。10%くらい性能がかわる。
- zfs diffでファイル単位で差分を抽出できる。スクリプトで処理するときに便利?
- ストレージプールの種類として「ストライププール」は公式にはそういう名前は書かれてないが便宜上そう呼ぶことに。
- ミラープールは中身が一致しているわけではない(俺:RAID1のような一致ではないという意味だとおもう)。どちらか1台が故障してもだいじょうぶ。
- 4台構成でミラーにしないんだったらダブルパリティのRAIDZ2にするのがおすすめ。2台壊れてもだいじょうぶ。
- とにかくZFSではプールは冗長構成にすべき。コピーをつくることで信頼性を担保しているので。
- ホットスペアも指定できる。指定しておけば自動的につかってくれる?
- zpool replaceで動作中にディスク交換できる。
- zpool addではプールの形式を変えないで追加される、zpool attachではミラーに構成を変えて追加される。
- zpool scrubはfsckのように一貫性をチェックするものでは「ない」。(やすいディスクなどで)ビットの反転などを検出するためのもの。
- dailyで動かす必要はない。zfsがアクセスしたときに自動修復してくれるので。アクセスされてないデータを強制的にアクセスするためのもの。
- scrubの頻度は機器の信頼度による。業務でつかうようなディスクなら1〜2ヶ月でok。エラーが検出されるようならコネクタとかメモリを疑ってみる。
- scrubは/etc/periodic.confで設定できる。いろいろ議論した結果デフォルト周期は35日。(ただし、デフォルトではscrubしない)
- zpool export/importは自動で読み込むかどうかの切り替え。
- 別のマシンに一時的にディスクをもっていってつないだ場合には/boot/zfs/zpool.cacheを書き換えて自動マウントされるようにはなってほしくない。
- FreeBSD9.1以降ではRootFS on ZFSはつかえるようになるはず。それ以前はいろいろ落とし穴があった。でも手動でやる必要がある。
- ひみつのgpart add -s 122 -t freebsd-boot..
- rpoolはroot poolの意味
- zpool.cacheを自分のファイルシステムの中につくらないといけないのと、CDROMブートだと書ける場所がないのがめんどうなところ。
- そのうちメニューを選んでできるようになるはずだが..
- おまじない zpool set cachefile="" rpool
- zpooltest.shでブートできるかチェックできる。ブートに失敗するとリカバリーがたいへんなので事前にチェック。
- システム更新したらとにかくzpooltest.shでチェックすべし。zpoolが読めないとヤバい。zpooltest.shが通ったら*たぶん*だいじょうぶ...
- 起動プールとデータのプールは分けておいた方が、管理が簡単。
[2012-12-07 21:03]
性能とチューニング
- ZFSはリンクをたくさんたどるがキャッシュ効いているはず、という仮定がおかれている。
- UFSとちがってZFSは複数のディスクをあつかうのでストライプが効くはず、という仮定もある。
- 書き込みは、ディスクのwrite backキャッシュが効くのにCoWのせいでランダムアクアセス読み込みが発生して、キャッシュがヒットしないと性能がぜんぜん出なくなる。
- ベンチマークだとZFSが瞬間的な性能が出ないせいで悪い値がでてしまう。
- disk 3本でベンチした例: gstripeは性能が出るのにzfsストライプだとディスク単体のIOPSしか出ない。原因は書き込みでも読み込みが入るため。
- ベンチマークはキャッシュが効かないように工夫されてるのでZFSでは性能評価は低くでる。
- 空き容量が20%を切ると性能が落ちる。ここをなんとかしようというのはないので、ディスクを追加すべし。
- 残り0%になると変な動作をする.. ファイルが消せなくなったり...
- zfs set atime=off: onだとデータ書き込まなくても読んだだけでスナップショットの容量が増えてしまうし、性能がガンガン落ちる。
- atimeが重要なアプリケーションもあるがzfsでは切った方がよさげ。
- zfs set compression=: データが主に圧縮される。デキストファイルでは効果があるがCPUをかなり喰うので要調整。圧縮する必要があるかも要検討。lzjbよりも圧縮率がよいlz4というのも検討されている。
- dedup(デダップ): ぜったいに使うな。メモリをくいまくる(対策なし)。一度onにするとoffにできない(データを書き直さないと元にもどらない)。使えてる人はだれもいない... 小さな規模なら動くけど、小さかったら意味ないし、圧縮の方がよっぽど小さくなる。
- メモリを喰うのは、おなじ内容のデータがどこにあるのか探すの時間がかかるのと、キャッシュを広くしなければいけないのが問題。メモリがたっぷりあれば別かもしれないが。トラブルがおこったときにも調査がたいへんになる。
- 小さいファイルのreadが多いワークロード(webサーバ): メタデータのキャッシュが効きているか? vfs.zfs.arc_meta_limitを大きくする。mmap/sendfileをつかうとzfsとbuffer cacheとで二重にキャッシュしてしまうので、アプリをmmap/sendfileを使わない設定にするのがよい。
- データベースなど固定レコード長もの: recordsize=を合わせておかないと128kBで書き込みされて無駄がでてベンチマーク結果がとんでもないことに。
- ファイルサーバ: スナップショットの数を減らすことで参照数管理のコストが減ってよい。
- L2ARCキャッシュでZFSのランダム読み込みを減らす。
- ZIL: 特に設定しないと各ディスクから少量ずつログ領域をもらってる。分離させて(slog)SSDに置くとよい。
- zfetch: パラメータが複雑。2プロセスの同時readによるストライド・パターンを検出してread回数を減らす。disableできないが基本設定で問題ないはず。
- vdev cache: 0にしとけ。シークの時間を減らす効果があるが、いまのデバイスはシーク時間が短かいので効果ない。負荷によらず0でよいが、古いディスクならチューニングする価値があるかもしれない。
- tgx: COWをまとめてIOを減らすためのしかけ。
- min_pending,max_pending: 忙しすぎたらwrite止め、暇そうだったら書くスレッショルド。
- 書き込みをグルーングしてフラグメンテーションを抑えるようになっているのでtxg.timeout=1にするとフラグメントしやすくなる。
- ベンチマークではなくて自分の負荷に対してトータルの性能がどうなっているか見ること。長いスパンで性能評価するとよい。
- インパルス的な書き込みとかストリーム的なワークロードに対してはtimeoutを短かくする効果があることも。
- 統計データをみるには zfs-mon, zfs-stats をつかう。
- allbsd.orgは細かいファイルアクセスが多いのでメタデータのキャッシュヒット率を上げないといけない。
- L2ARCはSSD 64GBだがあまりヒット率は高くない。でかいファイルが多いためか?
- wwwなどが入っているcvsrootはgzipの圧縮率はめいいっぱい上げて1/3に圧縮。他はあまり圧縮が効いてない。
- arc_meta_limitを上げてメタデータをキャッシュする。
- txg.timeoutを30秒に。
- NFSクライアントのキャッシュも有効期限を長く。
- チューニング結果UFSとおなじくらいの性能が出てる。
- チューニングのまとめ: webをみて試すよりもまず統計をとる。
[2012-12-07 21:56]
「NEC Express5800サーバ FreeBSDへの取り組みについて」
- タワーサーバは店舗とかデジタルサイネージとかにつかわれている(郵便局とか)
- 空調の電力を抑えるために35度→40度で動作サポート
- 電力的には外資よりも省電力らしい
- NECはストレージもスイッチも40度に対応してるよ。背面は50度くらいになって保守員はたいへん!なのでちょっと下げた方が..
冗長電源は分けて温度を下げるようにしてる(特許申請中)
- IPMIは古い設計なので
- IPMIはスタンバイ電源で動いているので、IPMIがハングすると電源をひっこぬくしかなかったが、BMCのリセットボタンを用意した!
- raidカードの情報をよめるようにしたり。
[2012-12-07 22:12]
[2012-12-07 22:14]
「FreeBSD勉強会」 by BSDコンサルティング(株) 後藤大地
- 講師はつらすぎてやってられないので、
- 参加費の八掛けを講師の方にお渡ししている。
- つまり、佐藤先生の睡眠時間を金で買っているということ!
- InfiniBandのドライバをゴニョゴニョしている。
- 7系をつかっている客も多いが、サポートしきれないので止めてほしい。9系への移行をサポートします!
[2012-12-07 22:22]
佐藤先生に質問
- Q: snapshotはunmountされない?
- A: ZFSとのインタフェイスを決めるときにそうしただけ。気にする必要はない。
- Q: raidzは2台以上とスライドにあったが2台で構築できる?
- A: 3台ないと構築はできない。
- Q: ホットスペアを指定すると、障害があったときに自動でディスクをreplaceしてくれる? (昔みたときはdevdにメッセージがとんでくるだけだったような気が)
- A: スペアのディスクを選んできて入れ替えるコードが入ったような気がする(うるおぼえ)。