Category Archives: zfs

FreeBSD 10インストーラからのzfs on rootを試してみたよー

Pocket

 

FreeBSD 10.0-RELEASEから、インストールの際にファイルシステムとしてZFSが選べるようになる。
システムの置かれるファイルシステムをZFSにする、ということは、今までも出来ないことはなかったけど、そりゃもう面倒な手順を経る必要があった。
それがインストールの時の選択ひとつで出来るようになったというのは、けっこうすごいこと。

また、システムをZFSに置けると、まずパーティションの切り方に悩まなくて済む。
あとで/varが足らないとか/usr/localがとかそういったことが無くなる。

そのうえで、システムまるごとzfsのアドバンテージを満喫できる。
まるまるスナップショット取れたりするからね。

ただ、2012/10/10現在、いまだテスト中のところであり、10.0-BETA1あたりに入るかも、という状態。(2013/10/15追記; 10.0-BETA1に入ってました)
そんな状態で試してみた顛末を記す。

なお一次情報は以下の通り。

 

インストーラでのzfs on rootを試す

前提:FreeBSD 10.0-ALPHA5, zfsbootonly.2013-10-09.isoをvirtualboxで試しています。
注意: 先述の通りテストの真っ最中なので、下記の内容が変わる可能性は十分にあります。

Allan Jude氏のページからインストーラをダウンロードする。
通常通り起動し、10.0になっても相変わらず愛想のかけらもないメニューを選択して進むと、以下の通りフォーマットのところでZFSが選べる。

 

menu001

ZFSを選ぶとこのように。

menu002

使うディスクを選び、進む。

menu003

あとは通常通り。

 

unameはこの通り。

 

カーネルモジュールがこのように組み込まれている。

 

 

ディスクの内容はこのように。

 

No tags for this post.

ZFS scrubを過信してはいけません。

Pocket

ZFS運用を始めてはや数か月。なんの問題もなく使っておりますが、

 「scrubって定期的にやるといいらしいよ」

 「なんかね、fsckみたいなこと、やってくれるらしいよ」

などという話を聞いた。

全くそんなことやってないので、慌てて調べてみた。

結論として、やっといた方がいいけど、なんか「fsckみたいな」と表現するのはおかしいよな、との理解に至った次第。

ZFSのおさらい

ZFSのキモのひとつは、セルフヒーリングにある。

格納されているデータに対して、強力なチェックサムを持っていて、不整合があっても勝手に修復する。

勝手に、というのはどういうことかというと、不整合を見つけ「次第」、つまりアクセスしたファイルに不整合があったらその場で修復してしまう、というところ。

だから、http://docs.oracle.com/cd/E19253-01/819-6260/gbbxi/index.html のとおり

データの不一致が ZFS 構成内のディスク上で発生するとすれば、それはハードウェア障害が発生した場合か、ZFS ソフトウェアにバグが存在する場合だけ

なので、ZFSソフトウェアバグはさておき、論理的なデータ不一致の発生リスクについてはとくに手だて不要というわけだ。

ハードウェア障害ならもうそこは物理的なディスクの冗長でなんとかせい、ということになる。

言い換えると、ZFS上のファイルにアクセスできない場合には、もうこれは尋常ではない障害が起こっているということであり、あなたはヘビーな状況下にいるということである。(その場合はこちら。)

http://docs.oracle.com/cd/E19253-01/819-6260/gbctt/index.html

じゃあscrubってなによ

そういった仕組みを踏まえてscrubというツール。

これは、上述の「不整合があったら修復する」というのを全データに対して行うだけ。

…ということは。

scrubをすれば全データのチェックはする。するけれども、そもそもscrubしてようがしてまいが、そんなことはお構いなしに、個々のファイルにアクセスしたらそのときに不整合チェックはされる。

カブってるじゃないか。

むしろscrub頻繁にやったらディスクに無用な負荷かけないか?

となるとscrubのメリットは何か。

http://docs.oracle.com/cd/E19253-01/819-6260/gbbyd/index.html

ZFS では、すべての不一致を定期的にチェックする機構が用意されています。この 機能は「スクラブ」と呼ばれ、メモリーやほかのシステム内で、ハードウェアまたはソフトウェア障害が発生する前にエラーを検出および回避する手段として一 般的に使用されます。

定期的にスクラブを実行すると、システム上のすべてのディスクへの継続的な入出力が保証されます。

スクラブを行なっているときまたは必要なファイルにアクセスしているときにエラーが発生した場合には、そのエラーが内部でログに記録されるので、そのプールで認識されているすべてのエラーの概要をすぐに確認できます。

とのこと。

「scrubすれば不整合があっても修復される」というのは、まあ間違ってはいないけど、むしろscrubの主目的はそこよりも、障害の予兆をつかむことにあると理解している。

たとえば。

scrubの定期的な実行をしないとする。

するとデータ不整合チェックは、個々のファイルアクセス契機で行われる。

不整合があればその都度、解消されるだろうし、解消されない場合には、ヘビーな状況だとして障害復旧を行うだろう。

しかし、滅多にアクセスしないファイルで致命的な、おそらく物理的な障害が発生し、影響が徐々に広がっていくような場合、このスタイルでは検知が遅れる可能性がある。

それを防ぐには、定期的にscrubで全ファイルをチェックし、「そのプールで認識されているすべてのエラーの概要」も定期的にチェックすればよい。

結果、「ハードウェアまたはソフトウェア障害が発生する前にエラーを検出および回避」できる可能性が高くなる、と。

scrubの使い方

というわけで使ってみた。まあコマンド例はいくらでもあるから淡々と。

このpoolに対して実行。

(すぐプロンプトが返ってくる)

えっ66時間かかるの?

(いまだに冗長化してないのが恥ずかしい。今回scrub調べてほんとに危ないのでディスク買わねばと思った)

OKOK。

なお、エラーが発生すれば、このstatusのほかに、syslogに表示されるし、たとえばFreeBSDならroot宛のメールにZFS poolsの状態も記載される。こんな感じに;

Checking status of zfs pools:

all pools are healthy

vaultに対するログにもきっちりと(こういうとこZFSって素敵だ)

なお、scrubの停止は-sコマンドで。

No tags for this post.

ZFSの重複ファイル節約機能dedupがすげえ(ただしメモリ大尽に限る)

Pocket

最初にお断りするが、十分なメモリ、あるいはSSDをお持ちでない方は帰っていただいて結構です。

 

Dedupとは

ZFSにはdedupという機能がある。

その機能を有効にすると、例えばここに1GBのファイルが一つあるとして、それをコピーしても、場所が同じpool内である限り、1GBのディスクしか消費しない。

 

何それただのハードリンクと思うのは早い。

 

仮に同一のファイルA, Bがあるとする。いずれも1GB。

ハードリンクすればディスク消費量は1GBだ。

さてここで、ファイルBの一部、1bitだけを変えたいとする。

もはやハードリンクはできず、別個のファイルとして扱うことになる。

したがってディスク消費は2GB。

 

ではdedupだとどうなるか。

1bit違う1GBのファイル二つがあっても、なんと1GBと128KBだけしかディスクを消費しないという驚きの仕組み。

 

どういうことかというと、dedupはファイルが同じかどうかをブロックごとに判断するということ。

先の例でいえば、異なる1bitを含むブロック分だけを追加で確保し、それ以外はファイルAと同じものを使う。

なお、ZFSでブロックサイズは512B~128KB。

つまり大目に見積もっても1GBと128KBだけの消費でよいわけ。

 

種明かし:テーブルと大量のメモリ

なぜそんなことができるのか。

ZFSはプール上にあるデータのすべてのブロックのハッシュをメモリ上に持っている。

あるファイルをディスクに書き込む前に、ファイルをブロックに分解しハッシュテーブルと照合、書き込み要否を判断するという仕組み。

 

問題はメモリ上に置くテーブルのサイズだ。

dedupを有効に使うには、テーブルを置けるほど十分なメモリが必要になる。

しかし、のちほど見積もりをするが、数TBのディスクを考えるとメモリで賄うのは少々厳しい。

当然、メモリをこればっかりに使うわけにもいかないのだし。

もちろん、テーブルをハードディスクに置くことはできるが、ファイルを書き込むたびにディスク上のハッシュテーブルを参照することになる。

つまりすっごく遅くなる。

よろしい。ならばSSDだ。

とはいえ、Dedupの目的がディスクの容量節約ならば、安いHDDケチってメモリ、SSD無理して買うのも本末転倒という話になってくる。

月並みだけど、よく考えた方がいいよね。

 

Dedupの見積もり。

では仮に2TBのデータが詰まったZFSでDedupしたら、どれくらいのメモリが必要か。

ハッシュテーブルは1ブロックにつき320Bytes。

zfsのブロックサイズは512Bから128KBで可変。

ざっくり64KBとみなす。

では計算。

 

2TB=1024 * 1024 * 1024 * 2 = 2147,483,648KB。

2TB/64KB=33,554,432 blocks

2TBは33,554,432 blocks。

1blockあたり320Bytesなので、かければテーブルに必要なサイズが出る。

 

33,554,432 blocks * 320 Bytes = 10,737,418,240 = 10GBytes

 

はい解散。

と言いたくなるレベルですな。

念のため記載するが、上記は2TBのデータを使っているときのdedupテーブルの試算。

2TBのプールに100bytes程度のファイル一つ置いただけなら、ハッシュテーブルは320Bytes程度。

 

Dedupの活きる道

そもそも2TB全部にDedupするのが間違いであった。

Dedupを活かしたいなら、扱うファイルで決めるのも手。

ざっくり言えばオフィスドキュメント、仮想マシンイメージなど、重複が見込まれるファイルを多く保管するディレクトリに対してのみDedupするとよいでしょう。

一方で動画などはあまり有効ではないでしょう。

なお、プールでDedupするとどれくらい得か、というのは調べることができる。

zdbにプール名を与えてやればいい。

一番下に重複具合が表示される。以下の例では1.06。あまり意味はないってことですな。

ちなみに、あるプールに同一のファイルを3つだけ置くとここが3.00になる。

DedupのONのしかた

まあzfs set dedup=ONとかすればいいんだけど、現状使う予定もないので詳しく調べてない。

No tags for this post.

ZFS優しすぎ涙がでた。

Pocket

前口上

試しにZFSを使ってみて(VMware Playerで気軽に試せるようになったとは、なんと便利な世の中か)本当に驚いた。

ディスク繋いでzpoolコマンド一発ですぐ使える。パーティションに頭を悩ませる必要もない。RAIDだって楽勝。ディレクトリごとに圧縮することもできるし、気が変わったら、いつでも止めることもできる。スナップショットも早い。

実は、何年か前にZFSについて調べたときはまだまだバギーな印象だったのと、ZFSを使えるようなパワフルマシンがなく保留にしてたんだけど、すごく損した気分。

いままで幾たび、fdiskやnewfs失敗してひどい目にあったことか。電子の海に消えたデータを思う。

 

そしてRAID。ソフトRAIDで言えばlvmも有名だが、俺にはもうコマンドが複雑すぎて覚えられない(lv…が論理ボリュームを、pv…が物理ボリュームを扱うんだって?)。

これはすごく危険。

だってソフトRAID含め、こういったディスクを扱うコマンドを使うのは、初期設定と、問題の発生したとき。

俺みたいなオッチョコチョイが、問題が発生して焦っているときに、コマンドが複雑だと二次災害を引き起こすんだって。

…正直に言うと実際に引き起こした。

 

ZFSならとにかくzpool、zfsさえ覚えておけばいいのだ。

 

ZFS

宅鯖ではZFSを使いたいからFreeBSDを選んだ。

そして、いろいろwebを渉猟するにi386でZFSは辛そうなのでamd64とし、下記の通りzpoolのバージョンもどーんと上がっているので, 9.0-RELEASEを入れた。メジャーバージョンの最初はちょっと不安ではあるけれど。

ZFSのバージョン

8.2+ – zpool v15

9.0+ – zpool v28

あとは、特に難しいこともなく、2.5Tのディスク1本買ってきて、つないで、領域作って、こんな感じ。

作業ログは後述。

 

ディスク1本なので、RAIDも組まず、圧縮もせず(データがjpg写真とか自炊本、自炊DVD、CDとか圧縮の効かないものばかりだから)。

あんなに煽っておいてアレだが、だってまだディスク高いし・・。

 

チューニング

ただまあ、ここを見てチューニングだけはしておいた。

http://wiki.freebsd.org/ZFSTuningGuide

 

/boot/loader.confにおけるチューニング

1行目

ZFSのprefetchを無効にすると全体的にスピードが向上する。

ただし読み書きが頻繁に発生する状態だとシステムが遅くなる傾向あり。

なお、4GB以上のメモリが実装されているとデフォルトで0になるとのこと。

2行目

txgが何の意味か分からないけど(task queue?)、こうしておくとスループットが上がる上に、システムが極端に遅くなる問題が改善される。

(In my case 50-100% CPU is used by ZFS with *no* disk activity during the pauses then a burst of rapid disk activity and then another pause. なんて言ってる)

なお、これはZFS v28からはデフォルト。

 

/etc/sysctl.confにおける設定

1行目でvnodes数の上限をデフォルトの約200000(a little over 200,000)から増やす。

2行目でTXG write limitの値を減らす。デフォルト値は知らん。

4GBメモリなら256MB、と書いてあるので、2GBを積んでる俺は128MBにした。

なお、ZFS v28より前ではvfs.zfs.txg.write_limit_overrideとのこと。

そのほかの設定:periodic script

/etc/periodic/daily/404.status-zfsにスクリプトがある。

有効にすると、毎日zpoolの状態をしらべて、daily output, security outputでメールしてくれる。

そうそう、root宛のメールは転送設定しておくと便利。

 

/etc/periodic.confに以下を追記しておけばOK

 

以下は作業ログ

作業ログ

ディスクをつないで起動、dmesgで確認

ada1が新しく繋いだディスク。

ここにZFS用のpoolを作成する。

 

無事完成。

なんと勝手にマウントまでしてくれる。これですぐ使える。

2.5Tなのに数秒程度で完了。

ビクビクしながらfdiskしたりnewfsしたりする必要がない。電卓も要らない(そういう時代もあったのです)。

衝撃的です。

コマンドが簡単なうえに、早いというのは、重ねて言うけど障害復旧に極めて有利な点。

大きなディスクをnewfsするときの、遅々として進まないカウンタを見てジリジリしたことのある人なら共感してくれるはず。

 

なお、この状態では/etc/fstabに何も書き込まれていないので、再起動すればマウントは外れる。

 

ではこのpoolからディレクトリを切り出す。

itunes用と、通常の共有ディレクトリ用の二つを作る。

 

 

これらを/export配下に移動させる。

これが既存の考えにはない動作。頭の中でファイルシステムに対する考え方がグニョっとなるのを俺は感じたよ。

 

そしたら/etc/fstabに書き込んでおしまい。

昔はデバイス名を書き込んでいた場所にZFSのディスクプールを書くわけですな。

afpでファイルをコピーしているのだが、あまり負荷はかかっていない模様。

ZFSはリソース食いと聞いてたのでコワゴワコピーしたんだけど、まあ100Mbpsのネットワーク越しですしな。

そのほか

重大な作業をするときは必ず-nオプションを付けること。

ドライランと呼ばれるもので、実際の作業はせずに結果をシミュレートできる。

 

ストレージプールを作業するときには明示的にexportすること。

exportすれば、未書き込みのデータがすべて処理され、システムから削除される。

そこで引数なしでimportを実行すると、import可能な、言い換えるとexport済みのプールが表示される。

No tags for this post.