ZFS

しばらくFreeBSD 9.0Rマシンで、raidz (1TB×5) + raidz (2TB×4)で合計11TBのプールで運用していたが、 先日2TB×4のうちの1台が死んだので、あわてて移行処理を始めることにする。 合計11TBのプールなので、これを下回るHDD構成は却下である。 サーバのM/BがASUS P8Z68-V PROなので、SATAは合計8ポート。1台はシステムとzfs logとcacheを兼ねるSSDで使う。そしてMarvell SATAの2ポートはあまり使いたくない。 ということでほぼ自動的に3TB×5のraidz構成とする。今回のHDDはSeagate ST3000DM001。 なにしろ総勢HDDは5+3+5で15台なので、1台のPCでは移行できない。余剰していたCore2Extreme QX9650マシンにFreeBSD9.0Rを新規に入れて移行処理に使う。 移行元:現サーバ(KONA) 1TB×5+2TB×4 移行先:旧サーバ(TUNA) 3TB×5 こんな構成。 んで、移行手順。 まずTUNA側sshd設定をいじって、KONAからsshで入れるようにしておく。今回はどーせ移行にしか使わないのでrootで入れるような極悪設定ににした。つまり、/etc/ssh/sshd_configにPermitRootLogin yes PasswordAuthentication yes と書いた。ひどいね。 TUNAで新poolを作る。gnop経由で4Kセクタ考慮してzpoolを作らせる。深く考えたくなかったのでこのへんのgnop_aftをそのままいただいて、ada1.nop～ada5.nopを作らせてから、zpool create tank raidz ada1.nop ada2.nop ada3.nop ada4.nop ada5.nopとした。 次にKONAでsnapshotを取る。zfs snapshot -r tank@date ‘+%Y%m%d-%H%M’`ちなみに"tank"は単にpoolの名前である。 そしたらrootでzfs send -vR tank@20120606-0800 | ssh root@tuna zfs recv -vdF tankとしてしばらく待つ。 今回はsend/recvにすごく時間がかかったので、4.が終わったらもう一度snapshotを撮ってsend/recvする。2回目はインクリメンタルでよいのですぐ終わる。zfs send -vR -i tank@20120606-0800 tank@20120607-0800 | ssh root@tuna zfs recv -vdF tankという感じ。 最後にTUNAでzpool export tankして、KONAでimportするのだが、古いpoolも新しいpoolも名前がtankなので文句を言われる。zpool importするとリストとidが出てくるので、zpool import (importしたい新しいtankのid)とすると無事importされる。 7.importするとgnop経由でなくなるが、zdb -C tank | grep ashiftとするとashift:12だったのでこのままでいいよね、たぶん。 とにかく4.が長い。6TBほど使っているpoolをGbE経由で転送するのだからそりゃ遅いよね……。 ...

こんなこと書いてた矢先にこれだよ! 最近2回ほどエラーが出てofflineになっていたHDDだが、ついに今朝、下記のような状態になった。dmesgにも該当のHDDが見えてないので、いよいよ死んだのかもしれない。 raidz1-2を構成する4台は、2010年6月に買ったBarracuda LP ST32000542ASなので、WD10EACSとWD10EADS混成のraidz1-0と比べると新しいのだが、さきにこっちが壊れますか……。 S.M.A.R.T情報的にはクロだが、一応seatools for dosで全域0fillをかけてどうなるか見てみよう。 pool: tank state: DEGRADED status: One or more devices could not be opened. Sufficient replicas exist for the pool to continue functioning in a degraded state. action: Attach the missing device and online it using 'zpool online'. see: http://www.sun.com/msg/ZFS-8000-2Q scan: resilvered 5.06M in 0h0m with 0 errors on Mon May 21 18:35:28 2012 config: NAME STATE READ WRITE CKSUM tank DEGRADED 0 0 0 raidz1-0 ONLINE 0 0 0 ada1 ONLINE 0 0 0 ada2 ONLINE 0 0 0 ada3 ONLINE 0 0 0 ada4 ONLINE 0 0 0 ada5 ONLINE 0 0 0 raidz1-2 DEGRADED 0 0 0 da0 ONLINE 0 0 0 da1 ONLINE 0 0 0 17433172425356801835 UNAVAIL 0 0 0 was /dev/da2 da2 ONLINE 0 0 0 logs gpt/zfs-log ONLINE 0 0 0 cache gpt/zfs-cache ONLINE 0 0 0 errors: No known data errors それにしてもZFSは楽だね。 ...

うちのFreeBSD 9.0マシン、KONAはeSATAを拡張するために、RocketRAID2314をつけていて、こいつにSeagate Barracuda LP ST32000542AS×4がぶらさがっている。 んで、RocketRAIDのBIOSを書きかえてLegacy Modeで使っているので、ほぼ単なるSATA拡張ボードになっているのだが、一点問題がある。SATAコマンドでエラーが出ると、RocketRAIDオンボードのブザーが鳴ってしまうのだ。 ZFS上のraidzなので1台死んでも耐えられるのだが、ブザーが鳴るのが耐えられなくて結局すぐにリブートすることになる。raidzがデグレード状態というのは冗長性がない状態なのですぐ対応しなきゃいけない状態ではあるのだが、ブザーの騒音のせいで即刻対応しなければいけないというのは自宅サーバとしてはちょっと困る。ZFSはzpoolコマンドで状態を確認できるのでRAIDボードのブザーなんていらんのである。この話とは別の話ではあるが、やはりZFSにはRAIDコントローラはいらんということなのだろうな。 まあ、そもそも現状のWD10EACS/EADS混成×5+ST32000542AS×4というHDD9台体制がイマイチなので、3TBのHDDを5台くらい買って古いHDDとRocketRAIDは予備に引退させたいところだ。その方が省エネだしね。

FreeBSD 9.0R上のVirtualBoxで運用している WHS2011だが、どうもバックアップDBが壊れて各PCのバックアップが止まってることが多かった。 まあ、気付くたびにDB修復をしていたのだが、どうもそれも失敗しだしたのでちょっと調べてみた。DB修復中のメモリ使用量をタスクマネージャーで眺めていたら、修復プロセスのメモリ使用量が2GBちかくなっていたので、仮想マシンに渡すメモリを2GBから3GBに変更してみた。そしてたら、修復も成功するようになったし、その後DBの破損もない。WHS2011は仮想メモリONになってるのだが、仮想マシン上で動かす場合は、2GBだけではちょっとツラいのかもしれない(もしかしたらportsのVirtualBox 4.1.8の問題だったのかもしれないが)。 メモリ16GBのうち仮想マシンに3GBも持っていかれるとZFSのARCが小さくなるじゃないか、と思ってしまったので、8GBのDDR3 DIMMがもうちょっと安くなったらメモリ32GBにしようと強く思ったのだった。 ちなみに電気代そこそこ下がったので、WHSの仮想マシン化の意味はあったようだ。 (4/8追記) 今のところ3GBあげていれば安定しているように見える。まぁ、WHS2011は64bit専用だし、それくらいはあげるべきなんだろう、きっと。

とりあえず、約1ヶ月ほどだけれど、Windows Home Server 2011は、FreeBSD 9.0RのVirtualBoxの上で安定してい動いてくれているようで、当初のサーバ統合の目的は達成できたようだ。 次のフェーズとしては、 一度断念したWHS2011のサーババックアップの有効化にトライする。 zpoolの1TB×5のHDDたちが大変古いので、信頼性の上での速度の上でもリプレースしたい というあたりに手をつけたいね。今3TBのHDDを5台買うと6万円以上するのでちょっと躊躇するので、タイ洪水の影響が減るである夏ボのあたりで2.に手をつけるとして、まずは1.かな。

こんなこと呟いてたが、まあ、ちょっとやる気になったので作業してみた。 8.2R->9.0Rでメジャーバージョンが上がっているけど、普通のworld更新と同じ手順で問題はなかった。 /usr/src[をRELENG_9_に更新 念のためにmergemaster -UPiFp make buildworld buldkernel 問題ない感じだったのでmake installkernel 再起動してシングルユーザモードにする make installworld mergemaster -UPiF もいちど再起動 で、おしまい。zpool upgradeはちょっと様子を見てからやろう。

まずはLULLIを止めて、古いCPUとM/Bとグラフィックカードを外し、新しいCPUとM/Bを入れた。入れるのはCore i7 2600Kの内蔵GPUを使う分だけ楽なのだが、SATAケーブルの配線に予想通り難儀した。見た目のわりに中身が狭すぎるよP182……。 なんとか組み入れられたので、ソフト的な準備を行う。統合サーバは当然のようにFreeBSDで運用する。ぶっちゃけKONAの環境そのままでいいのだが、せっかくSSDが余ってるので、rootとZFSのZILとL2ARCをそこに置きたいのでそういう作業を行う。 まずはKONAを止めて、SSDをつなぐ。あ、SSDは事前にSecure Eraseしたよ。 gpart create -s GPT ad6 gpart add -b 40 -s 128 -t freebsd-boot ad6 gpart bootcode -b /boot/pmbr -p /boot/gptboot -i 1 ad6 gpart add -s 1G -t freebsd-ufs -l root ad6 6.KONAの/をdumpして、SSD側でrestore。 という感じだったはず。ブートのHDDがad4なので、SSDはad6。なぜ4KセクタHDDでもないのに4K境界に合わせて-b 40なのか？とか、なぜZFS rootにしない？とか、そもそもrootに1GBもいるか？という話もあるがまあ気にするな :-) 5.でrootと名前をつけたので、以降は/dev/gpt/rootで扱えるのが楽。そのためにgptにしたのさ。 ちなみにroot以外は全部zfsのpoolに入っているので、HDDと共に新マシンに移動してもらう。 で、/dev/gpt/rootをどっかにマウントして、/boot/loader.confと/etc/fstabをふにふにする。KONAのAHCI無効で使ってのだけど、新マシンはAHCIで使おう!ってことでloader.confにahci_load="YES"を追加。fstabの方は/dev/gpt/rootを/にマウントするよう変更しておしまい。 以降は新マシンで作業。 SSDともともとKONAについてたIntel CTとRocket RAID 2314と外付けHDD4台を新マシンに移行。 新マシンをSSDから起動 (外付けHDDはda0-3で変わってないので普通に起動する)。 1TB×5で新規にraidz1なpoolを作る。 zpool create tank-new raidz1 ada1 ada2 ada3 ada4 ada5 だったかな。 KONAのZFS構成と同じになるようにひとつひとつ新poolでzfs createする。 旧poolの各FSでsnapshotを取る。 zfs snapwhot -r tank/pub@nowのような感じ。(@nowとか名前適当すぎだよね :-p) 旧poolの各FSからそのsnapshotをsendして、新poolでrecvする。 zfs send -vR tank/pub@now | zfs recv -vdF tank-newのような風味。 全部コピーが終わったら旧poolをexportして外す。 新poolもexportして、旧ZFSと同じ名前でimport (zpool import tank-new tankみたいな) ちなみに、旧poolは過去の事情があって(2TB+2TB)×2のmirrorなのだ。4台あるならraidz1にしたいよね？ということで作りなおすに1TB×5のraidz1に新規に移行してみたのだった。 ...