ZFS、デバイスの用途をまとめ。それとTIPS。

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のdeduplicationを試そう

前略、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ほか、新しいファイルシステムにはどんどん期待がもてるね。
 

Windows版のVirtualBoxに、Solaris10の10/09は入らんようだ

タイトルのまんまなのだが、インストーラを起動して暫くしたらPanicで止まる。
 
[caption id="attachment_1576" align="alignnone" width="728" caption="画像：Solaris10 10/09 in VirtualBox"][/caption]
 

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


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

続・ZFS上のiSCSIターゲットをサイズ変更、今度はLVM

前回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を追加してLVを拡張するのみでもOK、というかそれが普通。
iSCSIディスクも拡張するより、もう一個作って接続するほうが真っ当なやり方でしょう。

 
 

ちょっと感想

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

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

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

ZFS上のiSCSIターゲットをサイズ変更、ディスクを拡張して使う(Linux ext3編)

前編、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起動！

容量は……
 
[caption id="attachment_1561" align="alignnone" width="728" caption="画像：増やしたHDDでまず起動"][/caption]
 
 


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

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

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

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

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


見た目区別つかんなぁ．．．LiveCDから起動してますよー
 
[caption id="attachment_1562" align="alignnone" width="728" caption="画像：LiveCDからパーティション操作"][/caption]
 
 

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

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

 

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

 

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

 

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

 

 

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

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

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

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


"resize2fs" によって、パーティションの残り容量がちゃんと"/dev/sda3"に割り当てられます。
 
[caption id="attachment_1563" align="alignnone" width="728" caption="画像：ext3ファイルシステム拡張"][/caption]
拡張完了めでたしめでたし。
ああ、結構時間かかるので気長に待ってね、たった8Gで10分くらい終わらなかったな。
 
 


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

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

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

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

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

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

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

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

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

ZFS上のiSCSIターゲットをサイズ変更、ディスクを拡張して使う(Windows NTFS編)

次の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フォーマット。
 
[caption id="attachment_1553" align="alignnone" width="553" caption="画像：8GBのiSCSIディスク"][/caption]
[caption id="attachment_1554" align="alignnone" width="469" caption="画像：8GBのiSCSIディスク(2)"][/caption]
※実際はSS取るために「8G⇒16G⇒8G」とやったZFSボリュームを使用(^^
 
 



これをZFS側で16Gに拡張するといったんLogoffされる、まあ安全な感じですね。
 
[caption id="attachment_1556" align="alignnone" width="553" caption="画像：iSCSI自動切断"][/caption]
 
 

では、ログインしなおそう・・・
 
[caption id="attachment_1555" align="alignnone" width="408" caption="画像：MSのWIndows用iSCSIイニシエータ"][/caption]
 
 

ディスクの管理を見てみる。
 
[caption id="attachment_1558" align="alignnone" width="553" caption="画像：16GBのiSCSIディスク"][/caption]
 


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

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

とりあえず手持ちで手っ取り早い方法としてダイナミックディスクにしてみる。
 
[caption id="attachment_1559" align="alignnone" width="553" caption="画像：ダイナミックのシンプルボリューム"][/caption]
 

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

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

VirtualBoxでiSCSI起動(iSCSIデバイスをローカルディスク扱い)

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からは完全にローカルディスクとなる。
 

MBRと"/boot"をバックアップして障害に備える、CentOSでiSCSI活用(後編)

前編からの続き。
"/boot"だけバックアップした場合の戻し方。
 
 

"boot"だけ残せばよい理由と残す理由

前回記事の起動シーケンスから分かる通り、grubはstage2まで起動してしまえばファイルシステムをバッチリ理解できる。
逆に言うと、stage1.5まではHDDのセクタがそろってない環境にはそのまま戻せない、ということにもなる。
 

grubのstage2は"/boot"にあるので、そこになんとか繋ぐように配置すれば起動までこぎ着けそうな気もするが、そんな心配もいらないので諦めよう。
 

そう、MBRからstage2まで辿るのが難しくなった場合、素直にCDブートのgrubを使えばいい、
>> grub公式のgrub bootableCD作成方法
これはファイルシステムを大概理解できるナイスツール、必携だ。
 

grubさえ立ち上げれば、ext3の領域を読んでくれる = initrdやカーネルを指定してOSを起動することができ、ゆっくりgrub-install実施で元通りとできる。
 
 

ローカルをまっさらなHDDと交換してみる

前回作成したiSCSIを"/"領域にした環境で、ローカルディスクが爆破されたと仮定して"/boot"だけある環境から復旧してみよう。
 

まず適当なLiveCDを用意する。
CentOS5の奴なんかいいんじゃないだろうか、nfsマウント出来るしyumで少々のツールなら追加できる。
実は初期状態では重要なdump&restoreがないが、『yum install dump』で追加OKだ。
 

ではCD起動してからやること。。

1. fdiskでhddを編集開始、まあ大体 "/dev/sda" だろう
   わからなかったら"fdisk -l"

 

2. nコマンドで"/boot"用に100Mくらい、SWAPように適当に2048MBくらい確保

 

3. tコマンドでSWAPスペースのタイプを82に変更

 

4. aコマンドで"/boot"予定スペースの起動フラグON

 

5. wコマンドでパーティションテーブル書き込み、fdiskおわり

 

6. "/boot"のところにファイルシステム作成
   # mkfs.ext3 -L /boot /dev/sda1

 

7. ついでにSWAPも
   # mkswap -L SWAP-sda2 /dev/sdb2

 


と、ここまでやったら"/mnt" あたりに "/dev/sda1"をマウントして、tarでもrestoreでも好きな方法で旧環境の"/boot"を戻そう。
もってくる方法は特に問わない、なんでもいい。
 
 

以上で ローカルディスクの"/boot"は復活した。
ちなみにfdiskはこんな感じに仕上がった。
Device Boot Start End Blocks Id System
/dev/sda1 * 1 32 257008+ 83 Linux
/dev/sda2 33 282 2008125 82 Linux swap / Solaris
 
 

CDからgrubで起動しよう

"/boot"が使えるようになったので、CD起動にしたgrubを使ってみよう。
 

起動したらとりあえずこれだ、
grub>
 

どうしろと言うのか迷うかも知れないが、とりあえずファイルシステムのルートになるパーティションを指定しよう。
途中まで入れたらTABで補完OK。
grub> root (
Possible disks are: fd0 hd0 cd

使えそうなデバイスを見せてくれる、もちろんhd0を選びさらにTAB

grub> root (hd0,
Possible partitions are:
Partition num: 0, Filesystem type is ext2fs, partition type 0x83
Partition num: 1, Filesystem type is unknown, partition type 0x82

パーティションを教えてくれる、さっき自分で作ったのだからどちらかなんて自明。


grub> root (hd0,0)
Filesystem type is ext2fs, partition type 0x83

選択した領域に"/boot"があったらマウントしてくれる。
 

さああとはinitrd とカーネルを指定するだけだ．．．って
これがハードル高いと思う日もあるかもしれない。
 

でもそんなことはないんだ、"/boot"はマウントされてるんだよね？
 
 

コンフィグ見りゃいいじゃん。
 

grub> cat /grub/grub.conf
# grub.conf generated by anaconda
#
# Note that you do not have to rerun grub after making changes to this file
# NOTICE: You have a /boot partition. This means that
# all kernel and initrd paths are relative to /boot/, eg.
# root (hd0,0)
# kernel /vmlinuz-version ro root=/dev/hda3
# initrd /initrd-version.img
#boot=/dev/hda
default=0
timeout=5
splashimage=(hd0,0)/grub/splash.xpm.gz
hiddenmenu
title CentOS (2.6.18-128.el5)
root (hd0,0)
kernel /vmlinuz-2.6.18-128.el5 ro root=LABEL=/
initrd /initrd-2.6.18-128.el5.img
 

grubはcat出来る、これは死ぬほど助かる。
 
さあさっさと下記を入力して、bootコマンドを叩くのだ。
"kernel /vmlinuz-2.6.18-128.el5 ro root=LABEL=/"
"initrd /initrd-2.6.18-128.el5.img"
 
 

さすれば起動する、破壊前の環境そのままだ。
あとは起動後に"grub-install" をしてあげるだけ。
# grub-install --root-directory=/ /dev/sdb
色々理由があって上記になる。
 
 

おまけ、initrdのinit抜いてみた

と、言うことで今回環境のバックアップはおしまい。
結局、/bootのdumpとddと両方採ってるけどね。
 

今度はHDDの代わりにUSBメモリを使ってみようっと。
 
 

さて、"/"からiSCSIってinitrdは何しとるんだと思うじゃない、
なので展開してみた、なるほどねー。
 
長いのでトップでは切っちゃうが。

MBRと"/boot"をバックアップして障害に備える、CentOSでiSCSI活用(前編)

CentOS5のインストーラは、iSCSIのデバイスを認識できるのでので、このような環境を作ってみた。
"/boot"をローカルに置き、ほかは全部iSCSI。
 

用途	場所	dev?
/boot	ローカルディスク	/sdb1
SWAP	ローカルディスク	/sdb2
/	iSCSI	/sda1

 

図でみるとこんな感じだ。
 

[caption id="attachment_1516" align="alignnone" width="348" caption="画像：Linux+iSCSI"][/caption]
 


NICがiSCSI起動に対応していれば、しょっぱなからiSCSIいけたものを。。。
だがこれはこれで面白い環境なので気にいっている。
 


しかしこの環境、"/"はiSCSI経由、ZFSの上にいてるので大分堅牢になっている、データの消失は皆無といってよく、パフォーマンスも申し分ない。
ただ、ローカルディスクが1台なのだ。これがぶっ壊れたらさあどうすんのよと思ったので色々試してみた。
 
 


結論から言うと「/boot をdumpでダンプしておく」または「ddでMBRから/bootの領域までを全部書き出しておく。」というやり方で復旧が可能となる。
あ、あとはgrubのCDboot環境かな。
 

せっかくなのでそこに至る過程を述べておこう、まあ今回は結局のところgrubが何やってるかを調べたと同義かなあ。
 
 

通常起動で"/"をiSCSIでマウントするまでの過程

とりあえずこの環境がどのようなプロセスをたどって起動されるか、これがよくわからんようでは安心して眠れない。
ということで簡潔にブートプロセスを追ってみよう。
 

1. PCが起動される
    


2. ローカルHDDが認識され、MBR(第1セクタ)にあるgrubのステージ1が読み込まれる、MBRにはパーティションテーブルもある
    


3. grubのstage1はstage1.5を読むためにある。次のセクタを読むようにstage1は終了し、第2セクタより始まるstage1.5を読む
    


4. stage1.5が読み込まれる、これは"/boot"のファイルシステム(ext3)に合わせたものが入っている
    


5. ext3を理解するstage1.5は、"/boot/grub"にあるgrubのstage2をちゃんとファイルシステム上のファイルとして認識、読み込み
    


6. stage2に制御が移ったら、hdd上のinitrdを実行することが出来る
    


7. initrdはiSCSIのドライバを利用できる、ここでiSCSIデバイスをマウントする
    


8. マウントされたiSCSIデバイスからラベルが"/"のパーティションを見つける
    


9. "switchroot"!、iSCSIのデバイスは見事"/"としてマウントされ、Linuxの起動シーケンスは続く
    

 

簡潔．．．どうにか簡潔か。
最初に見つけるのをまよったのはstage1.5の場所、MBRと/bootの間であるHDDの第2セクタから第63セクタは使われているんだなあ。
 

さて、この環境が起動するプロセスはよくわかっただろうか。
iSCSIの辺りは"initrd"を展開すると、initスクリプトに全部書いてあるので、見てみるといいだろう。
 
 

hddの基本構造が同じなら、ddだけでいい

さて、grubがしてくれることは判った。
 

ということで、最初に出した環境をローカルディスクの破壊から救うということは、grubのstage1から1.5 と、stage2,initrdとカーネルイメージが入った"/boot"をちゃんと復旧できるようにするということにほかならない。
 

それならそこまでそのままダンプしちゃえばいいんだ、HDDの構造が一緒のもの※に換装する場合に限るが。
※現行なら、1セクタが512バイトで、かつシリンダあたりのセクタ数が63のものになるだろう。大体そうだよね、vhdですらそうしている。

ちなみにmbrのバックアップについて、ddで512バイト書き出して、446バイト(stage1)を戻せ！と書いてある記事などあるが、ありゃあ不十分な嘘っぱちだ。
マジックナンバーがあるからな、512バイト中ケツの2バイトも戻してやらんことには話にならん。

 
 

それじゃあローカルのhddの情報を見てみる、復旧の検証用に作ったほうなので容量が変だけど。
 

# hdparm -g /dev/sdb1
 
/dev/sdb1:
geometry = 60801/255/63, sectors = 530082, start = 63
# hdparm -g /dev/sdb2
 
/dev/sdb2:
geometry = 60801/255/63, sectors = 8385930, start = 530145
 

このケースでは"/boot"にええと、512MBとったんだっけ？SWAPには256MBくらいとった。本番はもうちょっとSWAP多目。
 

この場合、/sdb の1から63セクタが1シリンダ目(=/bootより前の領域)なので、/bootは63から始まっていて、SWAPの/sdb2は530145セクタ目から始まっているというのが判る。
ってことで、530145セクタ までddで出しちゃえばいい、これで狙った範囲は丸ごと取得できる。SWAPはどうでもいい。
 

こんな感じ。
dd if=/dev/sdb of=./mbr_boot count=530145
bs=512はデフォルトなので省略。
あとは書き出した"mbr_boot"をどこかに保管しておけばいい。
ローカルのhddがぶっ壊れてしまった場合、とっておいたイメージを書き戻すだけでいい。
dd if=./mbr_boot of=/dev/sda
かな、復旧中はiSCSI多分関係ないからsdaだ、復旧には適当なCDブートのLinuxでも使おう。
 
 

これでこの環境は起動するようになる、簡単だ。
 
 

mbrと/bootだけ戻したら起動するんだが、SWAPがおかしくなったりする。インストール時に設定したのみだと特に。
こんな感じ
# swapon -a
swapon: cannot find ther device dor LABEL=SWAP-sda2

 

mkswapするだけで元通りだ、SWAPスペースにはddする価値はないのであえて放っておいた。
 

#mkswap -L SWAP-sda2 /dev/sdb2
Settiong up swapspace version 1, size = 271426 kb
LABEL=SWAP-sda2, no uuid
 
#swapon -a
これで元どおりの環境が復活する。
 
 



さて、冒頭で述べた"/boot"だけ バックアップしておくという手段は結構復旧に手間がかかるが、hddの構造に依存しないのでとっておくべき。
次の記事で/bootだけdumpしてる際の復活方法を書いておきたいが、まあ大体わかるよね？
 
 

後編に続く
 
 

おまけ：復旧につかうツール

CentOSのLiveCDとか結構いいと思う、初期状態でNFSが使えるのでファイルを持ってくるのに便利だし、dump&restoreとかもyumですぐ導入できる。
もちろんddは使える。
 

あとはgrubの起動CDは作っておいたほうがいいだろう
ブータブルなGrubは重宝すると思う、作り方は公式に。
>> grub公式のgrub bootableCD作成方法
 

Solaris10、iscsitgtd が突然起動しない

zfsで作った領域をiSCSIのターゲットにでもしようかと、しばらく止めてたiscsitgtを起動してみた。
 

$svcs iscsitgt
maintenance 20:47:28 svc:/system/iscsitgt:default

え。
 
一応治ったのでエントリ。
 
 


起動しない原因を突き止めるべく、"/var/svc/log/system-iscsitgt:default.log"のログを見てみる。
 
/lib/svc/method/svc-iscsitgt: smf_zonename: 見つかりません。
/lib/svc/method/svc-iscsitgt: smf_is_nonglobalzone: 見つかりません。
Failed to start iSCSI daemon
 
え。
 
not found?
しばらく前は問題無かったのになあ。
それ以降にローカルゾーンを作ったり消したりはしたので、ゾーン関係かと思いもしたが、zonename 関連のログは正常起動の時も同じものだった。単にゾーンの有無で直接関係はないだろう。
 
 


仕方がないので SMF(Service Management Facility)から起動するスクリプトを追ってみると、結局"/usr/sbin/iscsitgtd" を直接叩いていることが分かった。
 

実行してみると。

$/usr/sbin/iscsitgtd
$echo $?
96
 

む、何だよ終了コード96て。
起動スクリプト的にはこれが0でないと「Failed to start iSCSI daemon」とログに出力。
まあ実際そうなんだから仕方ないか。
 
 

原因を突き止めるべく、とりあえずトレース。
WEBも調べたが有力な手掛かりはすぐには引っかからなかった、珍しいのかな。
 

$truss /usr/sbin/iscsitgtd
--snip--
open("/etc/iscsi//config.xml", O_RDONLY) Err#2 ENOENT
--snip--
 

おっとこれかな。
 

？？こないだまで設定ファイルは
"/etc/iscsi/target_config.xml" こうじゃなかったか。
中身を見ても変哲もないほぼ空っぽのXML。
 
 


少し考えた末、config.xmlの名前にファイルコピーして再チャレンジ。
 

$svcadm enable iscsitgt
$svcs iscsitgt
STATE STIME FMRI
online 21:10:35 svc:/system/iscsitgt:default
 


起動したね。(svcadmの-vはいつも忘れるなあ)
 

そのあとがまた謎で、"/etc/iscsi/" を見たら "target_config.xml" も "config.xml" も無くなっており、backupというディレクトリに突っ込まれていた。
 
 

どういうことだ一体・・・仕様変更なのかな。
するのはいいが止まっちゃうのは勘弁してよね。
 

Solaris10、zshのコマンド補完設定ファイル置き場

メモエントリ
 

気づいたら solaris10 にはzfsが入っている。
zfsやzpoolのコマンド補完でも定義してみようかと思って補完ファイルの置き場を探す、"$fpath" がそうなのか。
 
 

# echo $fpath
/usr/sfw/share/zsh/site-functions /usr/sfw/share/zsh/4.2.1/functions/Completion /usr/sfw/share/zsh/4.2.1/functions/Completion/AIX /usr/sfw/share/zsh/4.2.1/functions/Completion/BSD /usr/sfw/share/zsh/4.2.1/functions/Completion/Base /usr/sfw/share/zsh/4.2.1/functions/Completion/Cygwin /usr/sfw/share/zsh/4.2.1/functions/Completion/Debian /usr/sfw/share/zsh/4.2.1/functions/Completion/Linux /usr/sfw/share/zsh/4.2.1/functions/Completion/Mandrake /usr/sfw/share/zsh/4.2.1/functions/Completion/Redhat /usr/sfw/share/zsh/4.2.1/functions/Completion/Unix /usr/sfw/share/zsh/4.2.1/functions/Completion/X /usr/sfw/share/zsh/4.2.1/functions/Completion/Zsh /usr/sfw/share/zsh/4.2.1/functions/MIME /usr/sfw/share/zsh/4.2.1/functions/Misc /usr/sfw/share/zsh/4.2.1/functions/Prompts /usr/sfw/share/zsh/4.2.1/functions/TCP /usr/sfw/share/zsh/4.2.1/functions/Zftp /usr/sfw/share/zsh/4.2.1/functions/Zle
 

って多いなおい！
ローカル物は "/usr/sfw/share/zsh/site-functions" あたりに置くのかな？
 

---

追記
 
"/usr/sfw/share/zsh/site-functions" は違うかな？ファイルを置くとbashが変な動きになる。。
 

[root(xterm)@solaris1 site-functions]# ls
create destroy
[root(xterm)@solaris1 site-functions]# zpool (TAB)
create destroy
[root(xterm)@solaris1 site-functions]# zpool

なんか補完してくれてる。。。今bashなんだけどなぁ。
他のコマンドでもTABが全部 "create or destroy" になるので使えないし。

echoで改行やらTAB文字出力

メモエントリ
 

echo で改行したりTAB文字、要はちょっとだけエスケープ処理したいときー。
$'\n' やら $'\t' やらと$のあとシングルクォートで囲んであげる。
 

例えばこんな使い方、リダイレクトで hosts.allow へ。
# echo sshd: 127. 192.168. : allow$'\n'sshd: ALL: deny
sshd: 127. 192.168. : allow
sshd: ALL: deny
 
 

-e オプションで全体的にエスケープ有効にすれば シングルクォートだけでOK ⇒ '\n'
 

今更ながら。
 

cron で サービス監視ワンライナー

linuxやUNIXサーバで、取り合えず起動していて欲しいサービスがある場合。
堅くやりたければ daemontools や monitやらを使い、nagiosなどで外部から監視させたい。
 
そこまで不要だけどとりあえず、って時は cron にやらせるのも手軽でアリ。
nagios プラグインと組み合わせることで意外と柔軟な設定もできる。
 
 

では linux版、pidofを使ってみる。
*/10 * * * * root /sbin/pidof hoge > /dev/null || /sbin/service hoge start
 

たとえばこんなの。10分おきにpidof を叩いて、正常終了しなかったら実行の "||" を使って エラーがあれば通知(デフォルトならroot宛)もしてくれる。
 
 


ちょっと応用して、Nagios の check_procs プラグインを使ってプロセスの状態による動作設定をしてみる。

# /usr/local/nagios/libexec/check_procs -w 1:10 -a 'httpd'
PROCS OK: 9 processes with args 'httpd'


check_procs の結果コードは 正常終了が0・Warningが1を返すので、そのまま "&&" や "||" に渡せばOK。
例ではhttpd のプロセス数が 1から10 の間に入ってないとWarning だ。
 
 

ほかにも、check_http で応答が悪かったら、再起動するなり止めるなりするという使い方もできそうだ。
(止める場合は、適当にsleep コマンドをはさんで再開なども)
 

Solarisでも使える、(check_procはコンフィグオプションがややこしいが動作はする)、その場合は service を svcadmに変えればよい。
 
 

で、用があるので IRCプロキシの tiarra を監視した。
*/15 * * * * root /usr/local/nagios/libexec/check_procs -w 1:5 -a 'tiarra' >/dev/null || /usr/bin/screen -d -m /usr/l
ocal/tiarra/tiarra --config=/usr/local/tiarra/tiarra.conf
 

tiarra は daemon で動かしたかったんだけど、制御端末からうまく切り離せなかったので断念。 daemon 関数で普通に呼ぶだけじゃ無理なんかな？
 
ってことで、15分おきに tiarra 関連プロセス数が 1-5 の間にあるかチェック、無かったらscreen のデタッチ退却モードで tiarra を動作させるという仕組みで作成。
 

軽くテストはしたので多分動くと思うが、、まだ事故でtiarraが止まってないのでどうなるか。
 
 

プラグインでなくても、「ps -eo 'comm args」の出力辺りから何とかできないかなあ。
 

Solaris10、sdの番号割当をリセットする

Solars10を使っていて、某SCSIのディスクデバイスをつけたりはずしたりしていたら、インスタンス番号※が徐々に増えていった。
※sd00 の 00部分
 

sd90 を超えてきたので、いくらなんでも気持ち悪いと思い、リセットすることにした。
 
 


確認のため、"/etc/path_to_inst" を見るとずらずらとインスタンス定義振られているのがわかる。
 

さてどうしたものかと、マニュアルをちらちら読んでもリセットのやり方がよくわからん。。。
"devfsadm -C" ? ーCオプションはクリアとあるが、"path_to_inst" は特に変化無し。
 
 

で、「Open Solaris and Solaris 10 Forums」見つけた情報。
http://www.solarisforums.com/e107_plugins/forum/forum_viewtopic.php?421
 

消せってか、こいつはシンプル。
 
 

という事で、"/etc/path_to_inst" のバックアップを取った後、中身を空っぽにして再起動してみた。
 

起動中に現れたメッセージには。。。
--snip--
WARNING: /etc/path_to_inst empty or not found
NOTICE: rebuilding device instance data
--snip--
 

OK、うまくいった。
このファイルがおかしいと、平気でSolarisが起動不能に陥るので十分に注意が必要だ。
(失敗したら？OpenSolarisとかをCD起動して、バックアップから直してあげればOK、…多分)
 

かくしてsd90～のデバイスたちはsd1,sd2に若返りするさせることが出来た。
ついでにZFSのデバイスとしては、SD番号が変わるのに何の問題も無い。GUIDがあるから。

Solaris10にNRPEを仕込んでNagiosからやりたい放題

メモエントリ
 


Solaris10にNRPEを入れる際、ちまちまと調べながら、とりあえず動作 ⇒ SSLで動作 ⇒ inetd 経由で動作 ⇒ TCPラッパー追加
とようやく完成にこぎつけたが手順残すの面倒だと思っていたら、WEBにあった。
 

Configuring Nagios Plugins & NRPE on Solaris 10 < < UtahSysAdmin.com
 

あれをカットしなくてもできるとか、 inetadm の使い方とかとても参考になった。
 

wget で取得した内容を標準出力

メモエントリ
 

wget -O - 'http://sawano.members.icraft.jp/'

wget の "-O" オプションは、取得した内容を引数に指定したファイルに保存する。
 

このとき ファイル指定の変わりに "-" ハイフン一丁指定してあげると、標準出力にでてくる。
 
 

ちょいと man を引用
-O file
--output-document=file
The documents will not be written to the appropriate files, but all will be concatenated
together and written to file. If - is used as file, documents will be printed to standard
output, disabling link conversion. (Use ./- to print to a file literally named -.)
 
Note that a combination with -k is only well-defined for downloading a single document.

 

使いどころは限定的、動作確認とか。

ZFSのミラー状態ストレージプールを、リプレースで拡張する

ZFSは柔軟な拡張も売り、というからには当然このくらいできるだろ？
ということを実験してみた。
 
 

ZFSのストレージプールは、デバイスを適当にAddしていくだけで容量が増えていく。
ではミラーリングで作られたプールはどうなの？
 

ミラーリングのストレージプールを用意する

Solaris10で実験、ZFSのバージョンは 10 ね。
まずは "mkfile" コマンドで 512MB と、1024MB のファイルを それぞれ2つずつ作成。
 

$mkfile 512m /zdev/512M-1
・・・

ファイルがそろった。

$find /zdev -type f | xargs du -h
512M /zdev/512M-1
512M /zdev/512M-2
1.0G /zdev/1024M-1
1.0G /zdev/1024M-2

 

では 512MB のほうを使ってZFSストレージプールを作成しよう。もちろん "mirror" オプションを忘れずに。

$zpool create m512 mirror /zdev/512M-1 /zdev/512M-2

 

$zpool status m512
プール: m512
状態: ONLINE
スクラブ: 何も要求されませんでした
構成:
 
NAME STATE READ WRITE CKSUM
m512 ONLINE 0 0 0
mirror ONLINE 0 0 0
/zdev/512M-1 ONLINE 0 0 0
/zdev/512M-2 ONLINE 0 0 0
 
エラー: 既知のデータエラーはありません
 
$zfs list m512
NAME USED AVAIL REFER MOUNTPOINT
m512 89.5K 472M 1K /m512

m512 という 472MBのプールができました、ちょっと減るのはメタ情報領域がいるから。
ちなみにZpool名の初めの文字には 0-9 が使えない、デバイスの最低サイズは64MBから。
 
 

ミラーリング拡張方法の説明

デバイスとして 512MBのファイルが2つ使われているストレージプールに対して、中身のデバイスを 1024MBのファイル2つに 置き換えてしまうという作戦。
 
ZFSストレージプールでは、既存ものと同一か、より容量が大きいものであればデバイスの置き換えが可能なのだ。そして置き換えで発生した余剰サイズは無駄にならない、再計算されちゃんと最大容量が使用される。
 
 

デバイスを順繰りに置き換えていく

では リプレースしてみよう。
まずは 512MB のうち1つを 1024MB に置き換え。

$zpool replace m512 /zdev/512M-1 /zdev/1024M-1
 
$zpool status m512
プール: m512
状態: ONLINE
スクラブ: Mon Apr ** **:**:** 2009
上で 0 エラーが発生した 0h0m のあとの resilver completed構成:
 
NAME STATE READ WRITE CKSUM
m512 ONLINE 0 0 0
mirror ONLINE 0 0 0
replacing ONLINE 0 0 0
/zdev/512M-1 ONLINE 0 0 0
/zdev/1024M-1 ONLINE 0 0 0
/zdev/512M-2 ONLINE 0 0 0
 
エラー: 既知のデータエラーはありません

リプレースというステータスを経て、めでたく置き換わる。所要時間はZFS上のファイル容量に比例するかな。
 

$zpool status m512
プール: m512
状態: ONLINE
スクラブ: Mon Apr ** **:**:** 2009
上で 0 エラーが発生した 0h0m のあとの resilver completed構成:
 
NAME STATE READ WRITE CKSUM
m512 ONLINE 0 0 0
mirror ONLINE 0 0 0
/zdev/1024M-1 ONLINE 0 0 0
/zdev/512M-2 ONLINE 0 0 0
 
エラー: 既知のデータエラーはありません
 
$zfs list m512
NAME USED AVAIL REFER MOUNTPOINT
m512 106K 472M 18K /m512

OK、この状態でサイズが拡張しないのはミラーとして当然な。
ではもう一丁。

$zpool status m512
プール: m512
状態: ONLINE
スクラブ: Mon Apr ** **:**:** 2009
上で 0 エラーが発生した 0h0m のあとの resilver completed構成:
 
NAME STATE READ WRITE CKSUM
m512 ONLINE 0 0 0
mirror ONLINE 0 0 0
/zdev/1024M-1 ONLINE 0 0 0
/zdev/1024M-2 ONLINE 0 0 0
 
エラー: 既知のデータエラーはありません

と、完全にミラーリングのデバイスを置き換えることに成功。ここまで完全Online、ファイルアクセスの停止は無し。
 
 

サイズを確認しよう １

512MB 2つで組んだミラーは、生まれ変わるまでもなく今や1024MB 2つとなった。もちろん間にデグレード状態も挟まないぞ。
 

さあZFSのサイズを確認しよう

$zfs list m512
NAME USED AVAIL REFER MOUNTPOINT
m512 106K 472M 18K /m512

あれー？ 変わってないや。
 
ミラーは拡張できないの？いやそうでもない、次でやりかたを。
 
 

サイズを確認しよう ２

この状態からサイズ拡張をさせるには、確認できた手順で2通りある。※サーバの再起動はしてないので未確認
 

■エクスポート＆インポート

$zpool export m512
$zpool import -d /zdev/ m512

これはまあ確実だ、もともとZFSではサイズなんて後から付いてくるものだから。
 

■もう一度デバイス操作

$zpool replace m512 /zdev/1024M-1 /zdev/1024M-3

この例では1024MBファイルの3つ目をつくってデバイスの置き換えをもう一度やっている、これでサイズの再計算がおこなわれるのか、使用可能サイズが拡張される。
ミラー中の片割れをデタッチ＆アタッチでもいいかもしれない。
 


どちらかをやったあとにサイズを確認しよう。

$zfs list m512
NAME USED AVAIL REFER MOUNTPOINT
m512 112K 984M 18K /m512

ほら拡張している。
 
 

おわりに

なんでこの実験をしたかということを少し。
社内向けファイルサーバとしてZFSが使える環境を考えたのがきっかけ。容量の追加によるストレージ拡張は社内共用サーバとしてよく課題に上げられるので、それをZFSが楽にしてくれないかと考えた。
 

Solaris＋ZFS は CIFS をサポートしているので、ADサーバがある環境には容易に突っ込むことができるだろう。ミラーであれば構築時にいろいろ融通がきくうえ、拡張が自由となればさぞ柔軟性も高かろう。
(※ZFSのiSCSIも面白いんだが、拡張に不向き)
 
弾さえ用意すれば幾らでも容量を拡張してくれるファイルサーバって素敵やん？
 

ただ、Solarisを運用する気になるか、という点では敷居がちょっと高いのかな。マニュアル充実なので、まとまった時間さえとれればと思いますが。
 

find で古いファイルを消す

メモエントリ
 

linux サーバ運用で、古いログやファイルをfindで洗い出す時、 mtime, mmin などのオプションを使う。
あとは exec に渡して消すなり tar で固めるなりと、好きに料理すると良い。
 

#!/bin/bash
del_oldlog(){
# $1 directory path
# $2 days
find $1 -type f -name \* -mtime +$2 -exec rm -f {} \;
}
del_oldlog $1 $2

mtime で指定する値は、狙い通りにするのはちょっとややこしい、man を見るとよい。
(追記：daystart オプションで扱いやすくなる)
 
 


ちなみにfindだけでやるより、exec の代わりに パイプで xargs に投げた方が処理的に軽いみたい。
#!/bin/bash
del_oldlog(){
# $1 directory path
# $2 days
find $1 -type f -name \* -mtime +$2 | xargs rm -f
}
del_oldlog $1 $2


量が多いと思ったらこちらを優先したい。
 
 

---

4.26追記：(はてブにツッコミがあったので)
findコマンドのうち、IEEE Std 1003.2(POSIX.2) の仕様にそっているものでは
"-delete" オプションというのが使えるらしい。
他、"-exec" では ；(セミコロン) でなく ＋(プラス) で閉じると xargs のようにまとめてコマンド実行してくれる模様。
例としては FreeBSD でつかえる find とか。

sendmail の .forward で、メールの任意の行をログに出力

以前のネタ、sendmail で リレーするメールの DATA 部分をログに記録する の局地限定仕様版。
全アカウントの全メールをログに書き出しているとさすがに大変なので、ピンポイントで調査する時になど向け。
 

要点だけ言うと、 .forward にコマンドなりスクリプトなりを書いて、必要なものだけログに出力してしまおうという話。
 
 


例えば 特定のメールアドレスに送られてくるメールの Subject だけを記録したいという場合。
 

該当アカウントのホームディレクトリにある ".forward" ファイルを編集する、なければ作る。
"|grep '^Subject\:'>>/tmp/testlog.txt"
\{バックスラッシュ＋元のアドレスという行}


と記述しておけば "Subject:" で始まる行だけログに記録できる、記録先はパーミッションのあるところなら何でもOK。
ちなみに２行目がないとメール消えちゃうので注意。
 
 

結局、標準出力を処理するだけなので単純だ、他の情報も grep のところで簡単な正規表現で出来るはず。
貰ったメールの内容を条件に、ログ記録以外で色々やりたいなら シェル やら perl やらでスクリプト書けばOK。
 

もし出来ない場合は smrsh などが原因ちゃうかな、ログを見たら良いと思う。
さらにSendmailに限った話でもないけど、試したのがSendmailだったからで、大体のMTAで似たようなこと出来るはず。
 

Solaris10からシリアルケーブルでターミナル接続

メモエントリ
 

Solarisマシンにシリアルケーブル(RS-232C の9ピン)を差して使う時、コンソールからやるには tip コマンドを使う。
 

ボーレート38400 の機器に接続する場合こんな感じ。
# tip -38400 /dev/term/a
 

"/dev/term/a" は環境によって "/dev/term/b" だったりするだろう。
 

ストップビットなどの調整は man を参照、エイリアスが作りたかったら "/etc/remote" を編集する、COMポートは1つ標準でエイリアスが用意されている。
 

-- snip --
hardwire:\
:dv=/dev/term/b:br#9600:el=^C^S^Q^U^D:ie=%$:oe=^D:
-- snip --

# tip hardwire
とやれば上記の設定で接続してくれる、個別設定をするには、上記の設定行をコピーして適当な名前をつけて編集すればいいだろう。hw34800 とか。
 

ターミナルを抜けたければ、"~⇒." チルダを押して、ピリオド。
デフォルトではチルダがエスケープシーケンスになってるので、シェルに抜けたり色々コマンド実行可能、man 参照。
 

ちょっと追記：と思いきや、相手機器によっては "~⇒." による切断が出来んな。何でだろう？