しばらく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経由で転送するのだからそりゃ遅いよね……。
(6/9追記)こうなった。壊れた時の構成と比べると大分シンプルに。
[http://nekomimist.hatenablog.com/entry/2012/05/id/284:embed:cite]
pool: tank
state: ONLINE
scan: resilvered 12.8G in 0h16m with 0 errors on Fri Jun 8 20:01:30 2012
config:
NAME STATE READ WRITE CKSUM
tank ONLINE 0 0 0
raidz1-0 ONLINE 0 0 0
ada1 ONLINE 0 0 0
ada2 ONLINE 0 0 0
ada3 ONLINE 0 0 0
ada5 ONLINE 0 0 0
ada4 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
resilverのログが出ているのはちょっとしたポカミスのせい。