ZFS

FreeBSDでのhostidについて

FreeBSD 10.2から11.0にあげたらブート時のzpool importが失敗してあせったが、どうやら/etc/rc.d/hostidに変更が入って、ブラックリストにのっているhostidは認めないということになっているようだ。私のところの環境でいうと/etc/hostidに00020003-0004-0005-0006-000700080009(これはkenv -q smbios.system.uuidで得られる値)が記録されていたのだが、そんないい加減な値はダメだってことでブート時にuuidgenで新しい値をつくられてしまったので、zpool importするときに

Solaris: WARNING: pool 'POOLNAME' could not be loaded as it was last accessed by another system (host: HOSTNAME hostid: 0xHOSTID). See: http://illumos.org/msg/ZFS-8000-EY

といわれてzpool importが失敗していた。

ルートディレクトリが含まれているプールzrootはうまくimportされていたのでfreebsd-updateがうまいことやってくれたのかなぁ(しらん)。

いってきた: 第13回 FreeBSD勉強会 「ZFS の活用とチューニング」

夕方に大きな地震があったが、ちょっとダイヤが乱れたくらいで、勉強会は開催。

DSC02563DSC02564DSC02569DSC02572DSC02571DSC02573

DSC02577

DSC02579DSC02580DSC02581

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分休憩を入れることに。

BlogPaint

[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は細かいファイルアクセスが多いのでメタデータのキャッシュヒット率を上げないといけない。DSC02590
    • 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への取り組みについて」DSC02591

  • タワーサーバは店舗とかデジタルサイネージとかにつかわれている(郵便局とか)
  • 空調の電力を抑えるために35度→40度で動作サポート
  • 電力的には外資よりも省電力らしい
  • NECはストレージもスイッチも40度に対応してるよ。背面は50度くらいになって保守員はたいへん!なのでちょっと下げた方が..

冗長電源は分けて温度を下げるようにしてる(特許申請中)

  • IPMIは古い設計なので
  • IPMIはスタンバイ電源で動いているので、IPMIがハングすると電源をひっこぬくしかなかったが、BMCのリセットボタンを用意した!
  • raidカードの情報をよめるようにしたり。

DSC02592DSC02595DSC02596DSC02599DSC02600DSC02601DSC02602DSC02603DSC02604DSC02605DSC02606DSC02607

[2012-12-07 22:12]

[2012-12-07 22:14]

「FreeBSD勉強会」 by BSDコンサルティング(株) 後藤大地DSC02611

  • 講師はつらすぎてやってられないので、
  • 参加費の八掛けを講師の方にお渡ししている。
  • つまり、佐藤先生の睡眠時間を金で買っているということ!
  • InfiniBandのドライバをゴニョゴニョしている。
  • 7系をつかっている客も多いが、サポートしきれないので止めてほしい。9系への移行をサポートします!

DSC02612DSC02613DSC02614BlogPaintDSC02616DSC02617DSC02618DSC02619

[2012-12-07 22:22]

佐藤先生に質問

  • Q: snapshotはunmountされない?
  • A: ZFSとのインタフェイスを決めるときにそうしただけ。気にする必要はない。
  • Q: raidzは2台以上とスライドにあったが2台で構築できる?
  • A: 3台ないと構築はできない。
  • Q: ホットスペアを指定すると、障害があったときに自動でディスクをreplaceしてくれる? (昔みたときはdevdにメッセージがとんでくるだけだったような気が)
  • A: スペアのディスクを選んできて入れ替えるコードが入ったような気がする(うるおぼえ)。

懇親会 〜23:15

DSC02631DSC02632DSC02633DSC02634DSC02635

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

DSC08001DSC08002DSC08005

トラブル

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

DSC08006DSC08008DSC08009DSC08010

[2012-08-24 18:47]DSC08013

  • ここ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構築事例

DSC08014DSC08015DSC08016DSC08017DSC08018DSC08019DSC08020DSC08021DSC08022DSC08023DSC08024DSC08025DSC08026DSC08027DSC08028DSC08029DSC08030DSC08031DSC08032DSC08033DSC08034DSC08035

  • 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]

DSC08036

懇親会。ワイン白+赤+日本酒+つまみ。

DSC08037

[2012-08-25 11:00]

Q: scrubするとパフォーマンスが落ちるんですが。

A: scrubする必要はない。periodicに入ってしまったが必要ない。

いってきた: 第9回FreeBSD勉強会 ストレージの管理: GEOM, UFS, ZFS

DSC06029DSC06031DSC06032DSC06001DSC06004DSC06009DSC06017

第9回FreeBSD勉強会 ストレージの管理: GEOM, UFS, ZFS / 佐藤広生

DSC06002DSC06003

DSC06019

GEOM

  • 一次元の配列のように見える。
  • GEOMを回避してストレージにアクセスできない。どうやっても通る。
  • /dev/ada0とか1バイト単位でアクセスできるようになっている。FreeBSDではcdev,bdevの区別をすてた。ブロックデバイスはない。
  • デバイスノード → コンシューマ → プロバイダ → ディスクノード
  • プロバイダとコンシューマはペアになる。
  • ストレージデバイスがつながれたらGEOMの構造が自動でつくられる。伝統的なUNIXと同じように見えるようになっている。
  • BSDラベルのなかにBSDラベルをきっても対応できるらしい。
  • sysctl kern.geom.confdot でgraphviz形式でダンプできる。
  • mirror classは勝手には作られないが、デバイスの最後のブロックにgmirror(8)で書き込むとカーネルがちら見して、設定を読んでミラークラスをつくってくれる。→ tasting と呼ばれている。
  • mirror/mymirrorという名前でもいいけど、UNIX likeなgm0とかにおちついた。
  • ミラーのprimaryの指定は後から変更できるが、基本はlabelの先頭のやつ。
  • ストレージを切り離すにはgmirror forgetという分かりにくい。
  • gmirrorはGENERICに入ってないのでgmirror loadしないといけない。loader.confに入れてブート時に読み込まれるようにしておくこと。
  • 基本的に専用コマンドでGEOMメタデータを書き込む。
  • ZFSを実現するためにGEOMをくみあわせてつかっている(が表にはみえてこない)。

ファイルシステム

  • マウントポイントはディレクトリ基本だが、一部のOSではNFSなどファイル単位でマウントできるものもある。
  • mdconfig -a -t swap -u 0 -s 10m でメモリデバイスをつくる。本当にシステムのメモリが枯渇すると落ちるので注意。
  • UFSはinode領域はディスクの真中あたりに置いてあって先頭に置くよりも平均的にはアクセスが速くなる。
  • inode=2がルートディレクトリ。
  • カーネルをアップデートしても落ちるケースはスーパーブロックやinodeが壊れているかもしれない。
  • ファイルシステムが壊れてたらmountするとパニックしちゃうのでfsckが終わるまでmountできないようになっている。
  • fsckは未使用ブロックの解放をおこなうがメモリがたくさん要る。ディスク1GBに対して0.5MBのメモリが必要。
  • fsckはswaponの前なので注意。
  • inodeを非同期で書き込むと速くなるが信頼性が落ちる。FreeBSDは遅いといわれると悲しい→softupdatesが開発された。
  • softupdatesは削除は参照されないようにしてからブロックを消す。追加はブロックをつくってから参照をいれる。
  • softupdatesを有効にしてても未使用ブロック管理の回収でfsckが必要になる。fsckの時間は短かくならないが損傷の可能性は低くなる。
  • ジャーナリングでメタデータ操作の手順を記録する→復旧時にリプレイすればok。リプレイは何度やっても同じ結果になる。fsckの時間はほぼなくなったが、電源断で戻る幅がおおきくなった。やってないことになる量が増えたということ。10分とか15分とかのオーダで戻る。
  • 現状ジャーナリングを有効にるとdump -Lがつかえなくなる。改修中。
  • Q バグは9.1で直る? A: リリース前にレポートしてほしい、リリース直後は疲弊していてメールをよみとばしてしまう傾向が..
  • Q dragonflyのhammerは移植されるか? A: hammer FSはVFSの改造が入っているのでもってくるのはむつかしい。fuseの形で動かせるが、FreeBSDにもってきてても性能が出ない。技術的に難しい。hammer2でOSもかきかわってきているので。

[2012-07-20 20:37]

FreeBSDとCloudCore VPSと私 / 小原聖健

  • 自宅に置く電気代よりも安いよ。
  • たくさん購入すると安くなるよ。
  • そのうち新しいメニューが出るよ。

[2012-07-20 20:42]

FreeBSD勉強会 / 後藤大地

  • portsはバージョン管理されていないのでどんどん新しくなってしまう、古いバージョンにセキュリティパッチだけあてるサービス。
  • RedHatのような動作検証サポート。検証結果だけでなくてプログラム自体を提供するとか。

懇親会

~22:50

日本酒がいっぱいならんでました。

DSC06034

DSC06038DSC06046

次回以降

ZFS L2ARCをとりはずした

L2ARCとして使っていたSSDを取り外した。

取り外す前にsmartの値をみてみたら、書き込み量が読み込みより数倍多いことがわかる。

L2ARCの挙動としてはオンメモリのARCから押し出されたものをどんどん書き込むので、まさにそのとおりになっている。

L2ARCの書き込み単位は大きく読み出し単位は小さいというのもみえてくる。この特性はNAND Flashの性質にぴったり。

ID# ATTRIBUTE_NAME            RAW_VALUE
  1 Raw_Read_Error_Rate       6
  9 Power_On_Hours            7520
 12 Power_Cycle_Count         52
184 Initial_Bad_Block_Count   123
195 Program_Failure_Blk_Ct    0
196 Erase_Failure_Blk_Ct      0
197 Read_Failure_Blk_Ct       0
198 Read_Sectors_Tot_Ct       3839845191
199 Write_Sectors_Tot_Ct      11750223536
200 Read_Commands_Tot_Ct      148228624
201 Write_Commands_Tot_Ct     41284400
202 Error_Bits_Flash_Tot_Ct   3642321
203 Corr_Read_Errors_Tot_Ct   3504621
204 Bad_Block_Full_Flag       0
205 Max_PE_Count_Spec         10000
206 Min_Erase_Count           824
207 Max_Erase_Count           1803
208 Average_Erase_Count       979
209 Remaining_Lifetime_Perc   91
211 SATA_Error_Ct_CRC         0
212 SATA_Error_Ct_Handshake   0
213 Indilinx_Internal         0

Write_Sectors_Tot_Ct/Read_Sectors_Tot_Ct = 3.06
Write_Commands_Tot_Ct/Read_Commands_Tot_Ct = 0.278
Write_Sectors_Tot_Ct/Write_Commands_Tot_Ct = 284   (142KiB/access)
Read_Sectors_Tot_Ct/Read_Commands_Tot_Ct = 25.9048 (13KiB/access)

手順:

  1. zpool remove tank dev 論理的に取り外し
  2. 電源offしてケーブルの取り外し
  3. ブート

arc_summaryの結果をみてると、L2ARCがなくなるとそのぶんをオンメモリのARCが肥大するようで1〜2GBくらいサイズが大きい。

koie

記事検索
月別アーカイブ
アクセスカウンター

    タグ絞り込み検索
    ギャラリー
    • 今日の練習 2018-11-15
    • 今日の練習 2018-11-15
    • 今日の練習 2018-11-13
    • 今日の練習 2018-11-11
    • 今日の練習 2018-11-11
    • 今日の練習 2018-11-10
    Amazon
    楽天市場
    adby google
    LINE読者登録QRコード
    LINE読者登録QRコード
    • ライブドアブログ