» UNIXのブログ記事

ZFSでzpoolを作成するとき、各デバイスまたはファイルに3種類の役割がある。
データ用、キャッシュ用、ログ用とあるが、zpool構成するときにそれぞれどのように使えるかまとめてみた。
 

検証に使ったのは取ったのはOpenSolarisのb131、zpoolバージョンは22だ。
 

デバイスの用途と構成・特徴一覧

ざっとこうなる。
 

zpool形式	data	cache	log
スパン	○	○	○
ミラー	○	×	○
RAIDZ	○	×	×
RAIDZ2	○	×	×
RAIDZ3	○	×	×
detach	条件付○	○	条件付○※
ファイルを指定	○	×	○

 

dataとlogは似ている

data用は取れる構成コンプリートなのは当たり前だが、detachには制限がある。
logも同様だが、完全なデータのコピーがないデバイスは取り外せない、すなわちミラー状態の片割れが唯一取り外しOKで他の構成ではそもそも取り外しができない。
 

もちろんreplaceは可能、順序的にはミラーしてdetachだから当然。
 

data、logともにmkfileで作成したファイルも指定OK。
raidzはdataのみ、dataもlogも後からattachでミラーリングデバイスを追加出来る。
 
 

---

追記※
Logは最新のコードでは取り外せるようになってると情報をいただきました。
http://twitter.com/hasegaw/status/15496202547
取り外せないことがひそかに疑問だったが、すっきりしました。
 
 

cacheは特殊

一方cacheは冗長構成が一切とれない、必要がないからだろう。
 

また、デバイスの追加削除に制限がない。中身はあくまでキャッシュにすぎなく、ヒットしない・読み込めない場合はさっさと諦めて削除すればよい。
 

もう少し触れておくと、cacheには十分に早いデバイスの割り当てが推奨されている。
ミラーをはじめ冗長な構成では読み取りストライピング効果も確かにあるが、書き込みのペナルティが大きいため不向きだ。
 

また、degradeな状態を想像するといいだろう。
cacheにそんな状態があっては本末転倒だ、リシルバさせる意味も全くない。
高速に動作し、そうできない状態は必要ないのがcacheだ。
 

ちなみにファイルは指定できない、「ディスクまたはディスクスライスを指定すべき」と断られる。
cacheへの割り当てデバイス、お勧めはやはりSSDだ。
 
 
 

という感じ。ではついでにZFS利用にあたって私からのTIPSを。
 
 
 

zpoolミラーは多面鏡

zpoolのミラーリングはRAID1ではない。いくつも複製対象が増やせるのだ。
2つでは何かと心配、というときは3つにすればいい。
 

ミラー台数を増やすたびにリード性能は向上し、ライトはが下がる。リード重視という環境は多かろうので覚えておくとよい。
 

3-Way Mirrorの図、attachで作る。もちろん4つ目5つ目を追加していく事もOK。
NAME STATE READ WRITE CKSUM
zfs ONLINE 0 0 0
mirror-0 ONLINE 0 0 0
c4t0d0p0 ONLINE 0 0 0
c4t0d0p1 ONLINE 0 0 0
c4t0d0p2 ONLINE 0 0 0
 

ZILは意外と役に立たない(そんな事は無いというお話を追記してます)

これは特に主観が大きいTIPSなので参考程度に。
(※追記：LOGを別にした場合はかなり勝手が変わります。)
 

ZIL、まあトランザクションログみたいなのだが、アトミック書き込み、CoWが身上のZFSではイマイチ存在が薄いように思う。
実際どういうケースで役に立つのか、あまり実感がわかないのにZIL有効だとパフォーマンスがものすごく落ちる。
 

結局のところ、HDDやストレージ側の障害にZILは無力である。
ライトキャッシュ有効のストレージ装置が気まぐれでキャッシュを捨てたとする、別デバイスに取ったZIL上では正常終了なのにデータはおかしい。
逆もそう、HDDが死んでZILごと失った場合もZFSのCoW特性から、ファイルシステム上特に不都合はない。
 

データの小さい破壊はZFS内でミラーやRAIDZ構成をとっておくことでチェックサムから復旧でき、そこでもやっぱりZILは関係ない。
 
 

さてZIL、有用かな？
 
 

---

さて、ZILに関して有識者の方からご助言をいただきました。Twitter:hasegaw さんより。
ってか、『Xen徹底入門』とか付箋バリバリなのでえらい驚きましたが(汗
 

ZILはRAID-Zの上NFSサーバにしたときには効果大。Logデバイスは最新のコードだと取り外し可能に
http://twitter.com/hasegaw/status/15496202547

 

NFSですか。実は具体的にどう効果がもたらされるのかイメージが・・・
多分非同期だからということが関係してくるんだろう、ちょっと考えておこう。
本文がZILを完全に批判しているようになっているので載せるところまでは早くしないと。
 

で、答えはこちら。
http://togetter.com/li/27626
親切丁寧に教えてもらっちゃいました、なるほどですねえ。
 

RAIDZはデータをストライプした全デバイスに書く

使用デバイスの台数から RAIDZ=RAID5、RAIDZ2=RAID6と思ってはいけない。
詳しくは書き込みホールの問題を調べたらわかるので割愛する。
 

で、余所ではあまり触れてないと思ったことについて。
データを全部に書くのでRAIDZにあまり一杯デバイスを並べると書き込みのペナルティが馬鹿にならなくなってくる。
 

よってRAIDZを構成するのは6-8デバイスにとどめておき、大容量を求めるならRAIDZ構成をたくさんストライピングするのが多分賢い。
 
 

単純なスパン構成でも、後から冗長化できる（１）

導入時にRAID0っぽい構成にして、後からマズイと思ったりしますか？
zfsだとattachしていくことで冗長構成にする事が可能だ。
 

たとえばこんなスパンボリューム。
NAME STATE READ WRITE CKSUM
zfs ONLINE 0 0 0
c4t0d0p0 ONLINE 0 0 0
c4t0d0p1 ONLINE 0 0 0
 

attachであれよと言う間にRAID1+0相当に。
NAME STATE READ WRITE CKSUM
zfs ONLINE 0 0 0
mirror-0 ONLINE 0 0 0
c4t0d0p0 ONLINE 0 0 0
c4t1d0p0 ONLINE 0 0 0
mirror-1 ONLINE 0 0 0
c4t0d0p1 ONLINE 0 0 0
c4t1d0p1 ONLINE 0 0 0
 

多少容量は犠牲になるが、RAID0相当の構成はすぐにRAID6以上の稼働率＆ハイパフォーマンスを誇るRAID1+0に進化させることができる。
これも覚えておいて損はないだろう。
 
 

単純なスパン構成でも、後から冗長化できる（２：追記）

追加するデバイスなんかネエヨ！って方のためには、copies プロパティの変更をお勧めする。
何が起こるかって言うと、ZFSが書き込むブロックのコピー保持数を指定できるのだ。
 

なのでコピー=2とすれば複数のデバイス間で同一のブロックを2つ持ってくれるというわけ、hadoopにもこんな機能あるね。
このように設定しよう。
 

# zfs get copies tank
NAME PROPERTY VALUE SOURCE
tank copies 1 default
 
# zfs set copies=2 tank
 
# zfs get copies tank
NAME PROPERTY VALUE SOURCE
tank copies 2 local
 

これで一応冗長構成になった、容量は半分になるけどな。
ミラーと違うのは、ミラーがどれだけデバイスを追加しても容量が大きくならないのと違い、デバイスを追加したらその半分だけ容量が増えていくことかな。
 
 

思いったったら即、実質ミラーリングが可能だ、

デバイスたくさんのZpool

悩むところだが、Log,cacheを入れたら・・・
 

logをミラー、cacheを複数、dataはRAIDZ以上の複数スパン(または1+0構成)がいいかなあ。
こんな感じ？あくまで一例ね。
NAME STATE READ WRITE CKSUM
tank ONLINE 0 0 0
raidz1-0 ONLINE 0 0 0
c4t0d0p0 ONLINE 0 0 0
c4t1d0p0 ONLINE 0 0 0
c4t2d0p0 ONLINE 0 0 0
c4t3d0p0 ONLINE 0 0 0
c4t4d0p0 ONLINE 0 0 0
raidz1-1 ONLINE 0 0 0
c4t0d0p1 ONLINE 0 0 0
c4t1d0p1 ONLINE 0 0 0
c4t2d0p1 ONLINE 0 0 0
c4t3d0p1 ONLINE 0 0 0
c4t4d0p1 ONLINE 0 0 0
raidz1-2 ONLINE 0 0 0
c4t0d0p2 ONLINE 0 0 0
c4t1d0p2 ONLINE 0 0 0
c4t2d0p2 ONLINE 0 0 0
c4t3d0p2 ONLINE 0 0 0
c4t4d0p2 ONLINE 0 0 0
raidz1-3 ONLINE 0 0 0
c4t0d0p3 ONLINE 0 0 0
c4t1d0p3 ONLINE 0 0 0
c4t2d0p3 ONLINE 0 0 0
c4t3d0p3 ONLINE 0 0 0
c4t4d0p3 ONLINE 0 0 0
logs
mirror-4 ONLINE 0 0 0
c4t0d0p4 ONLINE 0 0 0
c4t1d0p4 ONLINE 0 0 0
cache
c4t2d0p4 ONLINE 0 0 0
c4t3d0p4 ONLINE 0 0 0
c4t4d0p4 ONLINE 0 0 0
 
ちなみにこれ、コマンド一発で構築可能だ。

 
 
 

ZFS特集でした！

前略、Hyper-VにOpenSolarisをインストールしました。
しかしそれは本題ではなく、ZFS(Zpool)のバージョン21から有効になった、データのデデュプリケーションを試すのだ。
 
 

ちなみにHyper-VにOpenSolaris入れるにはメモリたっぷりいるよ、失敗する人は増やせばOK。
VirtualBoxでもいける、VirtualBoxの方が相性は良さそうな感じ。
 

ZFSのバージョンは22、『やっぱりSunがスキ！』よりテキストインストーラのbuild131だ。
 
 
 

じゃあリアルタイムのデデュープを試してみよう！
 

さて、makefileでファイルをつくり、それをデバイスとして"ddzfs"というZFSストレージプールを作りました。
"zfs set dedup=on ddzfs" で準備完了。プールじゃなくてファイルシステムが対象ね。
サイズは1GBだ。
 
 

1GBの領域に/dev/zeroをダンプして5GBのファイルを作るとどうなる？
こうなる。
 

※VirtualBoxに変わっているのは諸事情のため差し替えたので。
 

手抜きでごめんねぇ、キャプチャだ。
雰囲気は伝わるだろう、途中で言い逃れできないようなアハ体験が訪れていることがわかる？。
 
 

しかしリアルタイムで計算してデデュープしてる割にはよいスループット出てるやん。リハのHyper-Vでも60Mちょっとは出てたし。
完全仮想なことを考慮したらすごく早い気がする。
 
 

用途がファイルサーバならCPUなんていつだって遊んでいるから実用にも全然つかえるんじゃないか？
メールサーバでも効果が高そう、C.C.での同報メールなんかは文字通りカーボンコピーになるね。
※ブロック単位なので実際はちょっと違うが。
 
 
 

send&recvとか試してみたいことは山盛りだが、なんかもう理解の範疇を越えてきたな。
ZFSほか、新しいファイルシステムにはどんどん期待がもてるね。
 

タイトルのまんまなのだが、インストーラを起動して暫くしたらPanicで止まる。
 

 

panic[cpu0]/thread=fec20160: page_unlock: page fe09cc4b0 is not locked
って．．．
一体何がやつをそうさせるのか。
 

Windows版VirtualBoxでSolaris10を使いたかったら一個前の 05/09やそれより以前のバージョンは問題ないのでそちらで。
 

前回ext3・前々回NTFSとZFS＋iSCSIで色々やり、結果がなんだか中途半端だった上『LVMならきっと大丈夫さ！』なんて締めではイカンと思ったのでLVMではどうなったか簡単に書いておく。
 
終始オンラインとはいかなさそうだが、多少はスマートに出来たと思う。
 
 

LVMでもパーティションはさすがに壁

まずちょっと勘違いがあった、LVMのボリューム操作について。
 

物理ボリューム(PV) を
ボリュームグループ(VG) にまとめてそこから
論理ボリューム(LV) を切りだしたらその上にファイルシステムを作れる。
 

という所のPVが結構簡単にでかくできると思っていたんだよね、pvresize っていうコマンドあるし。
 

しかし実際は、
こんなパーティション構成でOSをインストールして、
 

sda1	sda4(ex)sd5	sda3	sda2
ext3	SWAP	ext3	LVM(LV00)
/boot	SWAP	/	/data (ext3)

 

ZFS側でケツを拡張してみたら、、、
 

sda1	sda4(ex)sd5	sda3	sda2	空き
ext3	SWAP	ext3	LVM(LV00)	←パーティションの壁
/boot	SWAP	/	/data	←パーティションの壁

 

となり、これでpvresizeを実行してもダメ。
なぜならパーティションに縛られているから、ってことは。
 
 

じゃあパーティションデーブルなんかイラネェや

とある考えのもと、もう一個環境を作った。
 

sda1	sda4(ex)sd5	sda3
ext3	SWAP	ext3
/boot	SWAP	/
sdb
LVM(LV00)
/data (ext3)

 

HDDは2つ、両方でもいいがiSCSIはsdbだ。
 

で、見たらわかるようにsdbを丸ごとPVにした。
通常見られる createpv では "/dev/sdb1" などパーティション上に作るが、fdiskもしてない状態で"/dev/sdb" にcreatepvしたらこうなる。
これならパーティションの壁を気にしなくていい、だってそんな物(＝パーティションテーブル)無いんだから。
 
 

この状態でZFSからiSCSIボリュームを拡張する、さすがにLinux側は再起動しないといけなかったが・・・
 

sdb
LVM(LV00)		空き(FreePV)
/data (ext3)		-

 

上がってきたLinux上では、きっちりとPVが未使用領域を確認していた、これでpvresize出来る。
 
なぜか自動で一発MAXまで割り当ててくれなかったので一度手動でちょっと大きく(※)したあともう一回pvresizeしたら自動でPVのサイズが最大まで拡張した。
※ここらへんちょっとアヤシイ動きといえるのではあるが。。。
 
 

VG内のPVがでっかくなったので、あとはLVを大きくして、中のファイルシステムを拡張すればOKと。
 
 

 
 

ちょっと感想

安易な思い付きってのはなかなか上手くいかないもんです・・・
もっと安全にしたいのであれば、ディスクを追加しPVをVGに入れたあとでリプレースするような感じ、LVMならリデュースかな？をするのがいいかと思います。すっごく普通ですが安全確実でしょう。
 

まあiSCSIディスクはZFS上だったおかげでスナップショットから生み出された幾重ものクローンと、send&recvにより量産されたボリュームを潰し放題と、こういう実験しやすいですね。
 
ついでにVirtualBoxならiSCSIを直接管理できるし、ってこれもSunだなぁ。
 
 

もう本家にならって「すっかりSunがスキ！(/sukkri/)」とでも改名したらどうかと思ったりもするが、Windowsだって大好きなので変えない。
 

前編、Windows NTFS編からの続きー

 
 

iSCSIターゲットのサイズを拡張して環境変えずに使ってしまおうという目論見のLinux編。
ZFS＋iSCSIについては前編に解説。
 

使ったのはCentOS5、事前に断っておきたい事ですが記事内では普通のパーティションテーブルに作ったext3を対象に拡張しちゃってますが、普通は初期構築の時点でLVMでやるべきだと思います。
 
追記：LVMやりました。
 

今回拡張に使ったlinuxの環境

すでに結構特殊と言えなくもないが、テストに使った環境について。
 

VIrtualBoxでiSCSIデバイスを管理下のディスクにして、そこに直接CentOS5をインストール。
パーティションはこんな感じ、"/"が一番後ろにあるのがズルいっちゃあズルい環境。

sda1	sda2	sda3
/boot	SWAP	/

 

最初は8GBのHDDにこれをインストールしました。
 
 

ZFSボリューム拡張してから起動してみる

稼働中に突然拡張、そういえばしなかったなぁ、やってみればよかった。
 
ということで 8GB ⇒ 16GB に増やしたディスクでLinux起動！

容量は……
 

 
 

増えた増えた(w
もう驚かないぞ。
 

と言ってもいきなり拡張とかできない、パーティションテーブルが変わってないからだ。
さてどうしたもんか。
 
 

パーティションのサイズを変える

変えちゃうかー、パーティションの大きさ。
 

では適当なLiveCDで起動する、今回は手元にあったCentOS5.3のLiveCD。

見た目区別つかんなぁ．．．LiveCDから起動してますよー
 

 
 

では操作するディスクに狙いを定め、とにかく "fdisk" と"e2label"コマンドで以下の通り！

1. "/"を削除 ＝ "/dev/sda3" のパーティション消滅

 

2. "/dev/sda3" を再作成、残り最大限割り当て
   ※開始シリンダは消去前と死んでも合わせろ！

 

3. タイプ指定 82 してテーブル書き込み

 

4. パーティションラベルに"/"指定

 

 

冒険のように見えますか？ そうですねこりゃあ大冒険です。
 
幸いlinuxのfdiskはパーティションのブートセクタを弄らないのか再作成するのか、このやり方でも後から中身を認識できちゃう。
 
Windows(DOS)のFDISKでやったら即死ですからね、一応HDD解析の鬼みたいな猛者にかかれば復旧の方法は有るみたいですが。
 
 
ではしれっと次に行きましょう。
 
 

ext3ファイルシステムを拡張する

パーティションの準備がすんだら、いよいよファイルシステムを拡張します。
 

シングルユーザで起動とか、甘っちょろいことなしに可能、そのためのコマンドをぶっ叩くまで。

"resize2fs" によって、パーティションの残り容量がちゃんと"/dev/sda3"に割り当てられます。
 

拡張完了めでたしめでたし。
ああ、結構時間かかるので気長に待ってね、たった8Gで10分くらい終わらなかったな。
 
 

あ、inodeとか？そういえば見てなかったな…(汗
いちいちリビルドみたいな事やってるから変わってるのかな。
 
 

LVMだとどうなるんだろう？

この記事の内容は、上手くいっているとはいえ色々なディスクの使用の掟などから完全に目をそむけている気がして正直お勧めはしません。
真っ当にやりたければボリュームマネージャにLVMを使用しておくべきかと思います。。。いやLVM使ってお願い。
 

さて、LVMといえど既存のディスクがいきなり拡張したらどうなるの？という質問をとある方より貰いましたが、実際問題ないと思っています。
後からできた領域は、実際最初からあって使用していなかった領域と同じ扱いになりそうです、16GBのディスクを買ってきて、8GBしかパーティション切らなかったイメージですかね。
 

最初に切ったパーティションの残り容量が0であろうが100GBであろうが、使い始めたらきっと関係ないでしょう。それがいざ拡張しようとしたときに突然現れた残り容量でも然り。
 
 

……と思うんですけどねぇ、実用のためには試してみないといけないなあ。
だれかやってみて！
 
追記：LVMやりました。
 
 
 

追記：なぜ後から拡張したいのか

だって後から容量を柔軟に追加できたら、シン・プロビジョニングが出来るじゃないですかー
今後TCO増加の重荷になりそうなストレージ関係は、裏を返せばコストを減らす事によってグリーンIT推進の原動力になる可能性も十分に秘めている、そこになんとか繋げたいんですよねー。
あとはZFSがデデュープを出来るようになれば・・・！
 

さあいつか役に立てばいいですが。
 

次のLinux ext3編とで前後編。
 

iSCSI経由でマウントしたドライブのサイズを変更して使うというお話。
 

ZFSでiSCSIターゲット

ZFS上にZFSボリュームと呼ばれる容量制限付きのボリュームを作成し、"shareiscsiプロパティ"をonにするとiSCSIターゲットとして利用できる。
 

お手軽高パフォーマンスで重宝するのだが、折角容量可変のZFSを固定容量で使っている気がして、少々もったいないと思っていた。
しかしそれが認識間違いだったのに気づいた、いくらでもサイズ変更出来てしまう。
 
 

iSCSIターゲット中のZFSボリュームをサイズ変更

ZFSボリュームは一応普通のZFSファイルシステムとは扱いが違い、独自のプロパティを色々もっているうえOSにマウントされないためzfsコマンド以外では通常見えない。
 

"zfs list"で見るとちゃんと予約したサイズを確保しているので固定だと思い込んでいたが、"clone" とか "send＆recv" とかすると利用中サイズが変わる。でもiSCSIでくっつけると見える上限は同じー。
 

おかしいと思ってzfsボリュームのプロパティ一覧をみると、 "volsize" とかいうのがある。
どれどれ・・・
 
# zfs get volsize ziscsi/sawa01
NAME PROPERTY VALUE SOURCE
ziscsidev/sawa01 volsize 8G

なるほどZFSボリュームのサイズは単なるプロパティの一つであり、ハードクォータみたいな物なのか。
すっかりファイルをブロックデバイス代わりに使うような感覚でいたよ。
 
 

じゃあ早速、"set" で変更を試みる。

# zfs set volsize=16G ziscsi/sawa01
(特に出力なし・・何か言ってよ！)
# zfs get volsize ziscsi/sawa01
NAME PROPERTY VALUE SOURCE
ziscsi/sawa01 volsize 16G -

おお、変わっちまった、、、
乗せていたNTFSどうなんのよ！？
 
 

ちなみにテストはSolaris10、Zpoolのバージョン15で。
 
 

サイズ変更の瞬間、Windowsでは

サンプルはXP、Vistaみたいにパーティションをゴリゴリいじれないのでどうなるんだろう。。
 
 

まず8Gの時のマウント状況、Microsoft iSCSIイニシエータでZドライブにくっつけ＆NTFSフォーマット。
 

※実際はSS取るために「8G⇒16G⇒8G」とやったZFSボリュームを使用(^^
 
 

これをZFS側で16Gに拡張するといったんLogoffされる、まあ安全な感じですね。
 

 
 

では、ログインしなおそう・・・
 

 
 

ディスクの管理を見てみる。
 

 

増えとるよー！うわー、あたりまえだけど生理的になんだか気持ち悪い。。。
 
 

後はまあ気を取り直して、適当にパーティション操作ソフトでいじるなり、Vista以降なら拡張するなりお好きなようにってところですね。
 

とりあえず手持ちで手っ取り早い方法としてダイナミックディスクにしてみる。
 

 

変換して追加、ちゃんと8GB ⇒ 16GB のボリュームになりましたね。
ダイナミックディスクって使ったことないけど、相手はZFS上の信頼できるデバイスなのでなんでもイイんです。
 
 

では後編のLinux(ext3ムリヤリ拡張)編に続くー
 
 

SunのVirtualBoxを使うと、HDDのイメージにiSCSIブロックデバイスを指定できる。
 

…と何処かで見たのでメニューを見るもそれらしき設定がない。。
ヘルプによるとコマンドラインでのみ対応のようだ、そのコマンドがこれ。
"VBoxManage" の "addiscsidisk" オプション
 

VBoxManage addiscsidisk --server <name>|<ip>
--target <target>
[--port <port>]
[--lun <lun>]
[--encodedlun </lun><lun>]
[--username <username>]
[--password <password>]
[--type normal|writethrough|immutable]
[--comment <comment>]
[--intnet]</comment></password></username></lun></port></target></ip></name>
 
使ったのはWindows版のVirtualBox3.ｘ
 
 

さっそく叩いてみた、192.168.0.1上のiSCSIターゲットを指定する。
 

C:\Program Files\Sun\VirtualBox>VBoxManage addiscsidisk --server 192.168.0.1 --target iqn.1986-03.com.sun:02:**********************************
VirtualBox Command Line Management Interface Version 3.0.8
(C) 2005-2009 Sun Microsystems, Inc.
All rights reserved.
 
iSCSI disk created. UUID: *******************************


出来た。
 
 

さて、ターゲット側で情報をみるとこんな感じ。
 

Target: zfs1/iscsidev/vboxtest
iSCSI Name: iqn.1986-03.com.sun:02:**********************************
Alias: iscsidev/vboxtest
Connections: 1
Initiator:
iSCSI Name: iqn.2008-04.com.sun.virtualbox.initiator
Alias: unknown
 

……イニシエータの名前変更できるようにしてくれないか？SUNよ。
簡易フィルタかけたいんだが。
 
 

それはさておき、これでVirtualBoxのメディアマネージャをみるとiSCSIのディスクがリストされているので、晴れてIDEなりSATAなりで接続する設定すればそれで完了だ。ゲストOSからは完全にローカルディスクとなる。