tags: OpenIndiana

Migrate file server from OpenIndiana to NAS4Free

OpenIndiana is my good friend for the past several years. It works nicely, but I’ve decided to move on it to NAS4Free.

Reason

To catch it up current hardware especially 4k block device such as recent 4TB HDD, SSD, and so on. Yes, I know that OI supports 4k devices to set ashift=12, but I cannot make good result. In addition, I seem that the development of opened solaris eco-system goes more shrink and slow than before. I believe that OpenIndiana and Illumos is fabulous and well sophisticated operating system even now, but I also have to take it suit for current hardware in order for me to choose most cost effective hardware. I need actively working development community in addition to well stabilized operating system. So, I decided to choose another way.

ZFS

Fortunately, ZFS of OpenIndiana can be moved to FreeBSD with zpool export and import. So, I’m going to seek some nice FreeBSD distribution for some file server work and found that NAS4Free is good choise for me.

NAS4Free on HP Microserver

I’ve booted NAS4Free 9.2.0.1 from cdrom and installed into 2gb usb stick. It works super easily and perfect. After installation, I’ve imported exported zpool from OpenIndiana and NAS4Free detects and synchronizes it into its repository. I’ve add CIFS and NFS services on the gui and it can be configured super easy and just works !

After

NAS4Free works so far, so good. I’ll watch it and do additional works(some resource monitoring) for the future. Enjoy !

Sharing NFSv4 between solaris server and linux client

When you’ve mount NFSv4 filesystem from linux client to solaris server, you may experience user and group goes “nobody”.

First, check proper export setting.

1
share -F nfs -o rw,sec=sys,root=@xxx.xxx.xxx.xxx/24 /filesystem

According to man page of share_nfs, you have to specify proper security and hostname or range of ip address. If you want to set it to ip address, do not forget to set “@” in front of ip address. Otherwise these character is identified as hostname. Again, read man page of share_nfs carefully !

Next, check /etc/idmapd.conf in client.

1
2
[General]
Domain = mydomain

You may set your domain name, I think.

Finally, check the service setting. You also have to proper setting for mount.

1
2
3
rpcbind        	0:off	1:off	2:on	3:on	4:on	5:on	6:off
rpcgssd        	0:off	1:off	2:off	3:on	4:on	5:on	6:off
rpcidmapd      	0:off	1:off	2:off	3:on	4:on	5:on	6:off

Enjoy.

今日はflybackのバックアップを整理するスクリプトを作った

flybackはとっても便利だ。少ない容量で大量の期間のバックアップを作成することができる。通常バックアップというと、フルバックアップと差分バックアップで、1週間に一度フル、毎日差分、となると、1週間(7日)のバックアップを維持しようとすると、バックアップ元の2.6倍くらいの容量を確保しておく(異論あるかもしれない。俺は職場でそんなふうに教えられた)ようなところが、同じ容量でより多くの、しかも完全なバックアップを持つことができる。 マイコミジャーナル:あのTime MachineをLinuxで? - バックアップツール「FlyBack」が登場 上の記事を読んでFlybackを使い始めてはや3、4年になるが、確かにより頻繁にバックアップでき、より長期間保存できる。今の所バックアップ元をホームディレクトリ(約3G)、バックアップ先を250Gに指定しているが、ほぼ15〜20ヶ月ほどの2時間ごとのバックアップにさかのぼることができる。しかもどの地点にも更新されていないものも含めて全てのファイルがあり、cpコマンドやtarコマンドなどで簡単にリストアすることができる。すごい。 ただ唯一の欠点は、過去のバックアップの削除は完全に手動になってしまう所。更新されていないファイルはハードリンクになるので、削除しても削除しても容量が減らず、どこまで削除していいかわからないので、今まではえいやで2、3ヶ月まとめて削除していた。ただFlybackのインスパイヤ元のTimemachineはその辺りも考慮されていて、過去のバックアップは適宜間引いて残すようにしている。過去1ヶ月のものは1日おき、それ以前は1週間おき、という感じに。 やっぱりFlybackでも同じことをしたいなあというのが動機。 で、作った。perlスクリプト(ダウンロード)。 注意事項:ある程度テストはしていますが完全に動作する保証はありません。あなたの大切なバックアップが消えても何ら責任は取れません。未実装の機能が若干あります。 cronから実行することを想定してます。コマンドパスはOpenIndiana想定なので環境に合わせて適宜変えていただきたい。Perlモジュールについては各自なんとかしていただきたい。Flyback使ってる人が何人いるのかわからないけど、誰かが便利だなあと思ってくれるとうれしい。

今日はHP MicroserverのIPMIデータをmuninで見れるようにした

この前の話の続き。

で、munin-nodeはプラグインでいろんな機能をつけているのでIPMIとかあるんじゃねとか思ったらデフォルトでプラグインが用意されている。がイマイチよくわかんないのでスルーして他のものを探す。ぐぐったらこんなページがあったので、設定もいろいろできそうだしこれでいこうと。先に書いておくと、スクリプトの中ではOpenIPMI使うように書いてあるが、OpenIndianaデフォルトのipmitoolでいけました。

まずモジュールをダウンロードして所定の場所におく(ウチの場合は/usr/local/munin/lib/plugins)。chmodで実行権限をつけておく。

1
2
# ls -l ipmitool_sensor_-v3
-rwxr-xr-x 1 root root 17026 2011-02-20 19:05 ipmitool_sensor_-v3

次に/usr/local/munin/etc/pluginsからシンボリックリンクを張る。こんな感じに。

1
2
3
# ls -l ipmitool_sensor_*
lrwxrwxrwx 1 root root 37 2011-02-20 19:12 ipmitool_sensor_fan -> ../../lib/plugins/ipmitool_sensor_-v3
lrwxrwxrwx 1 root root 37 2011-02-20 19:12 ipmitool_sensor_temp -> ../../lib/plugins/ipmitool_sensor_-v3

で、スクリプトのなかを見ながら設定ファイル(/usr/local/munin/etc/plugin-conf.d/munin-node)を書く。以下のような感じ。

1
2
3
4
[ipmitool_sensor*]
user root
timeout 20
env.ipmitool_options -I lanplus -H <IPMIのIPアドレス> -U admin -f /root/ipmipassword sensor

パスワードのファイル(/root/ipmipassword)にはIPMIにアクセスするためのパスワードが平文で入ってる

で、munin-nodeを再起動する。

1
2
3
4
# ps -ef|grep munin-node
 root 19046     1   0 19:35:14 ?           0:00 /usr/bin/perl -wT /usr/local/munin/sbin/munin-node
# kill 19046
# /usr/local/munin/sbin/munin-node

で、しばらく待ってるとグラフが出てくる。なんか出てこなかったらmunin-nodeのホスト上のログファイル(/var/log/munin/munin-node.logとか)を見て各自なんとかする。

Enjoy !

今日はHP Microserverにリモートマネジメントカードを追加した

最近家のサーバの状態をmuninで見始めた。いろいろなリソースの状況が見れてそれはそれでとても便利なのだが、ファイルサーバであるHP MicroserverについてはOSがOpenIndianaということもあってか勝手が違う。

※muninがどういうものかについてはここを参照。一言でいうと監視の中でも「リソース監視」をしてくれるプログラム。まだできてないけどSNMPとも連携できるらしい。出力のサンプルをアップロード(.mht形式)しておいた。こんなんを見るですよ。

特に欲しかったのはディスクや筐体の温度の情報だったのだけど、Linuxではlm-sensorsでさくっと取れるんだが、OpenIndianaでは取れない。いろいろ調べているとどうやらOpenIndiana(OpenSolaris系)ではそのへんはBCMやIPMIでなんとかせよ、ということであった。

ということで、HP DirectPlus(法人のお客様(従業員500名未満))でリモートマネジメントカードを購入。税込¥8,400でした。入金後1週間ほどで手元に来る。

開けると簡単な取付説明書(英語)、安全のしおり、カード本体が入っている。

ボードはこんな感じ。EthernetのコントローラがBroadcomのチップ、IPMIのコントローラとしてASpeed AST2150がついている(ここにそこはかとない不安を感じる・・・)。コネクタとしてはEthernetのコネクタと、VGAのコネクタがついている。

とりあえずこれでとりつけはできるんだけど、事前にMicroServerのUser’s Guide(PDF)とMaintenance and Service Guide(PDF)をダウンロードしておいた方がよい

じゃあMicroserverをシャットダウンする。

まず裏側のPCIブラケットを固定しているレバーを外す。絵で見るとなんかよくわかんなかったので動画で取っといた。レバーを外したら、マイナスドライバーを使って内側のPCIブラケットのねじを外し、ブラケットを引き抜く。

ここにビデオが表示されます。Firefox3.5以降で対応

次に前面を開けて、ベースボードを引き出す。引き出し方はややこしいのでマニュアルを見ながら各自なんとかする。

ベースボードの内側のPCIスロットにマネジメントカードを取り付ける。

取り付けたらベースボードを筐体に入れる。入れ方もこれまたややこしい。各自知恵と勇気でなんとかすることを推奨するが、俺的コツとしては、(1)ベースボードを入れたら背面のコネクタの穴から指を入れて、ベースボードのUSBコネクタに引っ掛けながら気持ち持ち上げるようにして、各コネクタが穴から出るようにする(2)じわじわとボードを入れながらじわじわと各コネクタを接続していく(3)SASファンアウトコネクタは一見入ったように見えて入ってないややこしい(4)最後にベースボードのねじを締めるときはケーブルでねじを押さえたり引っかかってたりしてないか確認しながらやる、という感じです。

PCIブラケットのねじを締めて、レバーを元に戻す。

ここにビデオが表示されます。Firefox3.5以降で対応

で、Ethernetケーブル2本、USBキーボード、VGAケーブルを「リモートマネジメントカード側に!!(超重要)」差して、電源ON。BIOSに入って"IPMI Configuration"を選ぶ。

IPアドレスを決めて、Save & Exitで保存する。

とりあえずOSは起動しているので、今度はIPMIを見ることをやる。使っているのはMacなので、どうやらSafari, Firefoxではブラウザの管理インターフェイスがうまく使えないらしい。Operaならメディア・リダイレクションを除いてうまく動くらしいのでOperaで先ほどBIOSで設定したIPアドレスを開く。

果たして上手く動いた。Remote KVMもとりあえずは動いているように見える。

じゃあ次はホストOSのOpenIndianaからセンサー情報を取ってみる。OpenIndianaにはipmitoolパッケージ(pkg:/system/ipmi/ipmitool)を入れておく。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
root@saba:~# ipmitool -I lanplus -H <リモートマネジメントカードのIPアドレス> -U admin sensor
Password: 
Watchdog         | 0x0        | discrete   | 0x0080| na        | na        | na        | na        | na        | na        
CPU_THEMAL       | 34.000     | degrees C  | ok    | na        | na        | na        | 105.000   | 110.000   | na        
NB_THERMAL       | 36.000     | degrees C  | ok    | na        | na        | na        | 100.000   | 105.000   | na        
SEL Rate         | 1.000      | messages   | ok    | na        | na        | na        | 75.000    | 90.000    | 99.000    
AMBIENT_THERMAL  | 25.000     | degrees C  | ok    | na        | na        | na        | 40.000    | 45.000    | na        
EvtLogDisabled   | 0x0        | discrete   | 0x0080| na        | na        | na        | na        | na        | na        
System Event     | 0x0        | discrete   | 0x0080| na        | na        | na        | na        | na        | na        
SYS_FAN          | 1200.000   | RPM        | ok    | na        | 0.000     | 500.000   | na        | na        | na        
CPU Thermtrip    | 0x0        | discrete   | 0x0080| na        | na        | na        | na        | na        | na        
Sys Pwr Monitor  | 0x0        | discrete   | 0x0080| na        | na        | na        | na        | na        | na

次はこの情報をmunin-nodeに取り込めばいいんだけどここまで。 Enjoy Microserver!

今日はHP microserverのディスクに番号を振った

なぜかHP microserverのディスクにはスロット番号が記載されていない。これだとディスクが壊れた時にどの番号でfailしているかわからなくて悲しい思いをするのでディスク番号をシールで貼った。 ・・・のはいいんだけど、一度抜いたディスクを差しても/deviceにエントリが作られないのでzfs replaceが効かず泣く泣く再起動。再起動後resilvringし始めるものの、CPUの能力が低すぎて、ユーザランドのサービスがまともに反応しないという落ちつき。家のPCはあらかたsambaで接続しているので軒並み接続が切れる。ちなみにNFSサービスはカーネルでやっているのか比較的接続できる(重いことには変わりない)。 家の中で結構いろいろなものをOpenIndianaのストレージに紐づけてるのでresilveringできるまでのあいだほとんど何もできないというのは辛いなあ。 (1/23追記:)上は間違いだった。変更したはずのresolv.confの設定が再起動後元に戻っていたことが原因だった。なんで戻っちゃうんだろう・・・ (1/27追記:)nwamを有効にしていたからだった・・・。でもまだdisableしてない

今日はOpenIndianaでsambaをサービスで動かした

この前の話の続き。前からやってたけどどうせならきれいに動かしたかったからいろいろ頑張ってみた。

1. sambaをmakeする

普通にソースコードをゲットしてmakeすれば動く。すげー。コマンドにするとこんな感じ

1
2
3
4
5
6
7
8
9
# pkg install developer/gcc-3
# wget http://www.samba.org/samba/ftp/samba-latest.tar.gz
# gtar xzvf samba-latest.tar.gz
# cd samba-3.5.6
# cd source3
# sh ./autogen.sh
# ./configure
# gmake
# gmake install

このままだと/usr/local/sambaの下に各種バイナリがインストールされる。実行するためにはライブラリパスを追加してあげる必要がある。ここを参考に設定した。具体的なコマンドは以下のような感じ。

1
2
3
# crle -c /var/ld/ld.config -l /lib:/usr/lib
# crle -u -l /usr/local/samba/lib
# crle -v  (←確認)

で、/usr/local/samba/var/smb.confファイルを心の赴くままに作る。/etc/samba/smb.confじゃないところに注意。

動くかどうかテスト。

1
2
3
# /usr/local/samba/sbin/smbd -D
# /usr/local/samba/sbin/winbindd -D
# /usr/local/samba/sbin/nmbd -D

ログは/usr/local/samba/varの下にできている。うまく動けばok。

2. サービスとして自動起動するようにする

とりあえず動いたものの、毎回手動で起動するのは億劫だし起動するのを忘れてなんで繋がらないの?とアワアワするのも大変なので、自動起動するように設定する。

知ってる人にはアレだけど、OpenIndiana(OpenSolaris)の起動シーケンスはLinuxのお作法とは違うので合わせるように書く。

まず起動・停止スクリプトを書く。こんな感じに。できたらスクリプト単体でstart/stopしてちゃんと動けばOK。

で、そのスクリプトを呼び出すようにmanifestファイルを書く。こんな感じに。

manifestファイルが書けたらfmri(?)に取り込む。以下のような感じ。

1
2
3
# svccfg
> import /usr/local/samba/var/samba.xml
> exit

ちゃんと取り込めてるか確認。

1
2
# svcs -a|grep samba
disabled       14:58:21 svc:/local/network/samba:default

ちゃんと起動、停止できるか確認。

1
2
3
4
# svcadm enable svc:/local/network/samba:default
# svcs -xv (なにも出なければOK)
# svcadm disable svc:/local/network/samba:default
# svcs -xv (なにも出なければOK)

Enjoy!

今日でkvm環境への移行が完了した

いままでOpenSolaris+VirtualBox環境でやってたけど、2個以上VM立てると時計が進まなくなったりしてたので、ストレージはOpenIndiana、いろんなサーバはCentOS,KVMでやってみることにして、今日ほぼ元の状態まで戻した。KVM超いい。3つほどVM立ててもメモリぜんぜん食わないし時計はちゃんと進むし.iSCSIでやってみたかったけどなんかよくわかんないので今後の課題かな・・・。あとはOpenIndianaでSambaがちゃんと動けばパフォーマンスもいいのでちょっと動向をウォッチしつつとりあえず放置かなあ・・・。

今日はCOMSTARに挑戦するもよくわかんないこと多くて疲れた

OpenIndianaのZFSボリュームをSambaでクライアントにマウントさせたい→pkg install service/network/samba→smb.confをOpenSolarisから持ってくる→svcadm enable svc:/network/samba:default→smbpasswd -a なまえ→smbpasswd -e なまえ→動かないorz ということでLinuxでSambaやるべ→家の仮想サーバのrootディスクはiSCSIでやるぜ→zfs create→sbdadm create-lu→stmfadm add-view→itadm create-target→CentOSからiscsiadm -m discovery -t sendtarget→見えるぜ→iscsiadm -m node IQN –login→できたぜ→virt-install→OpenIndianaのZFSボリュームをzfs set sharenfs=on→Linux(CentOS)でマウント→yum install samba→OpenSolarisで使ってた設定ファイルを持ってくる。→service smb start→動くじゃん・・・まあいいか使えれば・・・→他のサーバも同じように作るべ→作った→CentOSでls -l /dev/disk/by-path→う〜んどっちがどっちのディスクなのかよくわかんね(わかるけど)。しかも2個目のはLUN0とLUN1の2つ見えてるし。→ところでどっちのLUがどっちのIQNに繋がってるの?→わかんね・・・ という流れ。OpenIndianaでSambaがちゃんと動く&仮想サーバのrootディスクをiSCSIにしない、ということでシンプルになるんだろうか、と書きながら思った。COMSTAR使ってみたいんだけどなあ・・・よくわかんないなぁ・・・

年をまたいでzfs send/receiveでファイルサーバをバックアップしてみた

結構ややこしい。慣れたり考え方を理解すれば楽勝だけど。ハマりポイントとしては以下のような感じか。

  • zfs sendできるのはスナップショットだけ。ライブのファイルシステムをコピーすることはできない。考えてみれば当然か。(コピー中にファイルシステムが変更されるとストリームとライブの整合性が失われる)
  • 2回目以降増分をzfs receiveするためには、受信側のライブファイルシステムが前回受信したスナップショットから変更されていてはいけない。これも考えてみればあたりまえ。ZFSは枝分かれスナップショットをサポートしていない(スナップショットからcloneしてpromoteすることで別ファイルシステムとすることはできるけど)。ロールバックでスナップショットに戻ることは可能。もちろんロールバックすると変更分は消える。

でも理屈が通っててわかると本当に気分がいい。ZFSがますます好きになった!順番に手順を書く。もっぱら将来の自分用に。

1. <送信側>スナップショットを取る

1
2
3
4
# zfs snapshot ore_no_tank@backup
# zfs list -t snapshot
NAME                                           USED  AVAIL  REFER  MOUNTPOINT
ore_no_tank@backup                                0      -  3.18T  -

詳細はOracleのZFS管理ガイドを見ればわかるが、REFERはそのファイルシステムが参照しているプール内のブロック(?)で、USEDは変更等の理由によりそのスナップショットから変更され、プール内のブロックを消費している量を指す。たぶん。

2. <送信側/受信側>zfs sendでスナップショットを送信する

スナップショットを送信する。ここではrootアカウントでやってるが、pfexecでやった方がいいのかもしれない。rootでのsshログインを許容するためにはユーザーロールを変更する(rolemod -K type=normal root)ことと、/etc/ssh/sshd_configでPermitRootLoginをyesにして、svcadm restart svc:/network/ssh:defaultする。(セキュリティが弱くなるのでちょう注意。作業が終わったら戻す方がいいよ)

1
# zfs send ore_no_tank@backup | ssh 192.168.xxx.xxx zfs receive -F ore_no_tank

-Fオプションで受信側のファイルシステムを強制的に置き換える。これ以降は受信側のファイルシステムには手で変更をくわえないようにする。といってもスナップショットにロールバックすれば元に戻るので。

送信後に受信側を見てみると、スナップショットも含めてコピーされていることがわかる。(zfs list -t snapshotしたときにUSEDに149Kのカウントされているのはスナップショット以降の変更分も一緒に受信しちゃってるのかもしれない。後ろの手順でやっている通り、一回zfs rollbackしておいたほうがいいかも)

1
2
3
4
5
6
# zfs list
NAME                       USED  AVAIL  REFER  MOUNTPOINT
ore_no_tank               3.41T  1.93T  3.18T  /ore_no_tank
# zfs list -t snapshot
NAME                             USED  AVAIL  REFER  MOUNTPOINT
ore_no_tank@backup               149K      -  3.18T  -

3. <送信側>再度スナップショット(増分スナップショット)を取る

容量が大きいファイルシステムや、複数で共有しているファイルシステムの場合、zfs send/receiveでコピーしている間にもいろいろファイルが作られたり消されたりする。その度にファイルシステム全体をコピーし直すのではいつまでたってもバックアップ先がバックアップ元と同期せずバックアップの意味がない。再度スナップショットを取って、差分だけバックアップ先に送るようにすればより頻繁にデータをバックアップできるチャンスが増え、より最新のデータに復元できたり、より精度高くデータを復元できる可能性が高まる。(例えば”先週のデータ”ではなくて、”昨日の15:30時点のデータ”とか)

送信側で再度スナップショットを取る。

1
2
3
4
5
# zfs snapshot ore_no_tank@backup2
# zfs list -t snapshot
NAME                                           USED  AVAIL  REFER  MOUNTPOINT
ore_no_tank@backup                            8.68G      -  3.18T  -
ore_no_tank@backup2                               0      -  3.18T  -

前回スナップショットを取ってから、8.68GB分の変更が発生していることがわかる。

4. <送信側/受信側>zfs sendで増分のみを送信する

再度スナップショットを送信する。送信側で"-i"オプションで増分計算元を指定していることと、受信側で"-F"オプションを外していることに注意。

1
# zfs send -i ore_no_tank@backup ore_no_tank@backup2 | ssh 192.168.xxx.xxx zfs recv ore_no_tank

増分を送信後に受信側の状態は以下のようになっている。増分のスナップショットが正しく展開されている。

1
2
3
4
5
6
7
# zfs list
NAME                       USED  AVAIL  REFER  MOUNTPOINT
ore_no_tank               3.42T  1.92T  3.18T  /ore_no_tank
# zfs list -t snapshot
NAME                             USED  AVAIL  REFER  MOUNTPOINT
ore_no_tank@backup                  8.67G      -  3.18T  -
ore_no_tank@backup2                     0      -  3.18T  -

zfs send/receiveした時に以下のようなエラーが出たら、受信側のファイルシステムが変更されている。zfs rollbackでスナップショットに戻ることで解決できる。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
<送信側>
# zfs send -i ore_no_tank@backup ore_no_tank@backup2 | ssh 192.168.xxx.xxx zfs receive ore_no_tank
cannot receive incremental stream: destination storage has been modified
since most recent snapshot
<受信側>
# zfs list -t snapshot
NAME                             USED  AVAIL  REFER  MOUNTPOINT
ore_no_tank@backup               149K      -  3.18T  -
# zfs rollback ore_no_tank@backup
# zfs list -t snapshot
NAME                             USED  AVAIL  REFER  MOUNTPOINT
ore_no_tank@backup              1.50K      -  3.18T  -
<送信側>
# zfs send -i ore_no_tank@backup ore_no_tank@backup2 | ssh 192.168.xxx.xxx zfs receive ore_no_tank
# (←成功したので何も出ない)

Happy ZFS !

openindiana.org

http://openindiana.org/ 出るべくして出たという感じ [9/11 0:29追記]・・・と思ったけどページ見るとほとんど何もないし誰がやってるかもわからないしライセンスも不明だし怪しい。全ては13日になってみないとわかんないなこりゃ