あまりに不安定なんで閉口していたのだけど、ここのところ安定させることに成功したらしく、落ちることがなくなった。

どうやったかについてちょっと解説。

まず一番大きかったのは、lennyのXenが何で落ちているかを発見することが出来たことだ。じゃ、落ちてた原因は何かと言えば、

ページング

だ。つまりswapが発生した途端に落ちていた。となれば解決はわかったもので、とにかくswapが起きないようにする。swapしたら負けとばかりに、諸々と調整する。具体的には、Apacheのプロセス数を調整して、swapが起きないようにすることと、swapoffにしておくことだ。これで半日に1度落ちるようなことはなくなった。

次にやったことは、/homeをクラス分けしたことだ。具体的には、

• 頻繁に更新が発生しているユーザ
• 頻繁に追記が発生しているユーザ
• 全く更新されないユーザ

に分けて、別々の仮想ボリュームを与えることにした。

以前は/homeはみな同じボリュームにしていたため、全く更新されないユーザの領域が頻繁に追記されているユーザのせいで壊れるということがあったのだが、クラス分けすることで壊れることはなくなった。おまけに、1つのボリュームが小さくなったから、fsckする時の時間も少なくて済むようになった。

このようにすることによって、頻繁に落ちたり復旧に時間がかかるということはなくなって、安定稼動するようになった。まぁswapをなくしたことで仮想空間が狭くなってしまったのだけど、落ちてしまうよりはずっといい。

まぁ、こんな工夫をしなくても落ちないというのが一番良いのではあるけれど。

Linuxは64bitも32bitも使いたいし、DebianもUbuntuも使いたい。そこでVMということになるのだけど、これもなかなか頭痛い。

元々ノートPCの方では「VMWareでLinuxを動かして、WindowsのXに貼りつけて動かす」ということをやっていた。ノートのWindowsを抜いてしまうと、いろいろ不便なことが多いし、かと言ってWindowsだけだと不便でしょうがなかったので、そうやることにしていた。

Xは試行錯誤の結果、Cygwinを入れて動かすのがリーズナブルだとわかっている。Windows上のXは各種あるのだけど、たいていは商用だし、Freeなものは結局CygwinのXを取り出したものだったりするので、あれこれ悩むよりもCygwinを入れてしまうのが手っ取り早い。

CygwinのX serverを入れてしまえば、XWin Serverというアイコンが出来るので、これをクリックするだけでxtermが動く。あとは、VMにsloginしてやればいい。

さて、そのVMなのだけど、最近は選択に迷うほどある。

隠れMS信者としては、MSのVMを使いたいと言うか、第一選択に思っていたのだけど、これでLinuxを動かすのはちょっと面倒なことがあるようで諦めることに。2004の時に使っていて悪くない感じではあったのだけど、知らぬ間に落ちてしまったりということもあって、信頼性には「？」だったということもある。そんなわけで、第一選択が早々に落選。

定番としてはVMWareがある。

VMWare serverはノートで常用していたのだけど、2.0になって管理コンソールがさっぱりわけわかになってしまった。CPUが2個使えるのは嬉しいんだけど、そういったわけのわからないところが嫌なので、敬遠して他の選択肢を探すことに。

そこで発見したのは、SunのVirtual Boxだ。製品でもあるけど、GPLでもあるので、いろいろ見通しがいい。何しろ「わからなかったらソースを見る」という手が使える。CPUが1つしか使えなさそうなのが困るのだけど、当座には我慢しておけばいい。

普通にVMイメージを作って動かす分にはどうとでもなるのだけど、元々使って動かしていたLinuxの環境を動かしたい。これが使えないことには、いろいろ不自由である。そこでいろいろ調べてみたら、「物理パーティションをゲストにする方法」というのがあるのを発見する。

方法はわかってしまえばどうということはなく、物理パーティションの情報を持った仮想パーティション定義ファイルを作ってやればいい。ヘルプの

9.10. Using a raw host hard disk from a guest

に詳しいことが書いてある。具体的には、

VBoxManage internalcommands createrawvmdk -filename /path/to/file.vmdk -rawdisk \\.\PhysicalDrive1 -register

のようにして、vmdkファイルを作る。どこに作るかと言えば、

C:\Users\<ユーザ名>\.VirtualBox\HardDisks

だ。ここにあるvdiファイル(仮想ディスクイメージ)とvmdkファイル(仮想パーティション定義ファイル)がゲストで使うことの出来るディスクイメージとなる。

これで元々Linuxの入っていたドライブ全体を仮想ディスクとして登録してやって、それを起動するようにしてやると、元々のLinux環境がまるっと動いてしまった。動いてしまえば、後はどうとでもなる。

ただ、ゲスト上ではなぜかディスクは「hdx」になってしまう。今時のLinuxでは、たいていのディスクは「sdx」になっているはずなので、この辺がうまく行かなくて起動エラーになる。これは慌てず騒がず「hdx」に書き換えてやればいい。

PS.

64bitのゲストを起動すると、「このプロセッサは64bitじゃないぞ」的なエラーを返したりしてたのだけど、BIOSをアップグレードすることで解決した。どうやら、CPUのフラグの初期化あたりがおかしかったらしい。

そんなわけで、Linux使いにとって不自由のない環境設定が必要だ。

Windowsを使っていろいろ気になることのうち、慣れることが難しいなと思う点は、

• Ctrlキーの位置
• キーバインド
• 日本語入力システム
• 仮想コンソール

だ。他のことは「まぁOSが違うんだからしょうがない」で我慢するとしても、これらだけはどうあっても我慢出来ない。これらも慣れてしまえば良いんではあるけど、何しろUNIXモガキから数えれば20年くらい使っている「環境」なので、なかなか譲れない。なので、これらをVista上でも実現することに。

Ctrlキーの位置

まず、Ctrlキーの位置の問題は、「Windows Server 2003 Resource Kit Tools」というのを使うことにした。XPまではKeyCtrlというのを使っていたのだけど、どうもVistaでは動かない模様。入れて動かそうとすると、「このバージョンには対応してねーぜ」という脅しが散々出て来るのだけど、そこで負けずに動かすと何とかなる。そうそうVistaでこういったのを動かすには「管理者で実行」というのをやらないといけないんだね。要するにsudoみたいなものか？

動かし方はなんとなくKeyCtrlと似た感じなのだけど、キーはDnDするようだ。最初はKeyCtrlよろしくクリックして「動かねーなー」とか思ってたんだけど^^;

キーバインド

キーバインドはやっぱりEmacsでないと不便だ。そこでXKeymacsを入れる。デフォルトの設定でもそれなりにEmacsしてくれる。後で述べるSKKIMEとの干渉やら、普段使いのショートカットとの整合からいくらか手を入れなきゃいけないけれど、まぁだいたいこれで十分。ちゃんと動けば、Gnome(GTK)のEmacsバインドよりもEmacsらしくさえなる。

日本語入力システム

私は普段skkを使っていたので、SKKIMEを入れる。これは私がゴチャゴチャ書いたものじゃなくて、

SKKIMEインストールメモ

を見ながらやるといい。このままやれば大丈夫。

これも、UIMのskkよりもずっと使いやすい。

仮想コンソール

標準のWindowsには、なぜか仮想コンソールがない。XPの時には「Microsoft PowerToys for Windows XP」のVirtual Desktop Managerを使っていた。

プレゼンで即座に画面を切り替え。画面分割ソフト「Virtual Desktop Manager」

ところが、これはVista用ではないので、「Vista/XP Virtual Desktop Manager」を入れることに。

Mac OSXのSpaces風のWindows向け仮想デスクトップ「Vista/XP Virtual Desktop Manager」

これで4つまでの仮想コンソールが使えるようになった。

もっとも、これが微妙にCygwin Xと相性が悪かったりするので、同種の他のものにしてみようかなと思っているところ。同種のソフトはいくつかあるようだ。

PS.

仮想コンソールには、結局Dexpotというのを使うことにした。これがXの仮想コンソールに一番近い動作をしているような気がするのと、仮想で作れるコンソールが多いのが嬉しい。

Xenはちょっとハマりどころがあるので、TIPS。

lennyのXenはVer 3.2.1が入っている。Xenの情報をネットで探すと、3.0以前のやら3.0のやらはいっぱいあるのだけど、3.2はあまりない。しかも、lennyはついこないだ出たばかりだから、そういったことでも情報は少ない。

なけなしの3.2の情報を探すと、いくつかのディレクティブが変更になっていて、

• ‘ramdisk’が’initrd’に
• ‘file:’が’aio:tap:’に
• ‘xenbr’が’eth’に

変更になったらしいことがわかる。そこで元々ある設定ファイルをこのように変更すると、

動かない

のだ。特に’file:’のは「rootになるものがないんで待ってる」という意味のメッセージが出て、5分くらい待った挙句に起動出来なくて失敗する。このパラメータあたりに問題があることは容易にわかるのだけど、「新しいXenではaio:tap:って書くんだよ」という情報ばかりが流れていて、わからずじまい。これはlennyでのbuildがおかしいとばかり思い込んでいた。なので、正式版のlennyが出たら直るものだと思って放置していた。

ところが、正式版のlennyでも動かない。

あれこれ試してからふと、「世間でlennyでやったという話があるのだから、一度インスタンスそのものを作って、そこで作られた設定ファイルを見ればいいじゃないか」と思い立った。こうすれば、何が悪いかわかる。

そうやって調べたところ、

• ‘ramdisk’はそのままでいい
• ‘file:’はそのままでいい
• ‘xenbr’が’eth’に

ということがわかった。どういった事情があるか知らないけど、3.0の設定とだいたい同じで良いようだ。

この他にtty絡みでちょっとハマる部分がある。

まず、インスタンスを起動する時に、

# xm create -c /etc/xen/instance.conf

のようにして、コンソール付きで起動すると、rcの処理がほぼ終わったところで、いきなりハングアップしているように見える。これはどうやらコンソールのデバイスの関係らしい。

これを回避するには、設定ファイルに

extra = 'xencons=tty'

と入れておいてやる。

これが正常に動いてsshでloginしようとすると、loginが蹴られる。どうやらptyがないらしい。これを回避するには、udevをインストールしてやる必要がある。

これで一応動くようになるのだけど、特殊なfs(nfsとか)を使おうとすると動いてくれない。よく見ると、initrdの中にないモジュールが全くない。カーネルが新しくなったので、あらためてlinux-module-xxxxをインストールしてやらなければならない。これで正常に動くようになる。

整理すると、

• 設定ファイルは3.0とほぼ互換
• 設定ファイルにextra=’xencons=tty’を加える
• udevとlinux-module-xxxをインスタンスに入れる

というあたりに気をつけると、うまく動くようになる。仮想ボリューム名も’hd’という名前から’xvd’に変更しておいた方がいい。絶対ではないようだけど。

参考として、うちでの現用の設定ファイルを書いておく。

kernel = "/boot/vmlinuz-xen"
ramdisk = "/boot/initrd.img-xen"
memory = 6144
name = "gaien-U1"
disk= [
    'file:/instance/U1/root.img,xvda1,w',
    'file:/homes/gaien-U1.img,xvda2,w',
    'file:/instance/U1/var.img,xvda3,w',
    'phy:sda1,xvda4,w',
    'phy:space/home,xvdb1,w',
    'file:/homes/gaien-U12.img,xvdb2,w'
]
root = "/dev/xvda1 ro"
vif = [ 'bridge=eth0','bridge=eth1' ]
extra = 'xencons=tty'

今回はあまりにカーネルがおかしくなるということもあって、早々にlennyにアップグレードしたのが原因だ。etchの時よりも酷いことに。

元々、ここの環境にいろいろと問題があるということは、既に何度も書いている。

Xenで仮想化しているのだけど、software RAID5 + lvmをdomain0で用意してやり、その仮想ボリュームをdomainUにブロックデバイスとして見せるようにしていた。これがあまりに障害が多く、毎週のように異常になっていたので、直接仮想ボリュームを見せるのではなく、ファイルにイメージを作って見せるようにした。これでかなり障害は減ったのだけど、それでも何事もないわけでもないので、早々にkernelを更新したいと思っていた。

折り良く、lennyがリリースしたので、アップグレードすることに。Xenのアップグレードはちょっとハマりどころがあるのだけど、それは別記事に。

そうやってkernel含め諸々が新しくなったのだけど、かなりの頻度でpanicになる。etchの最終版よりもタチが悪い。panicになったら、さらにお約束のようにファイルシステムは壊れてfsckするハメに。

ふと思い立って、NICを玄人志向のGbE-PCI2の2枚差しから、1枚減らして、オンボードのNIC(Marvell)と両方を使うようにしてみた。これでいくらかpanicは減ったのだが、相変らずpanicすることは同じ。

Hansがあーゆーことになったこともあって、新しいkernelになってもRaiserFSにはあまり期待は持てない。次にファイルシステムを復旧するようになったら、jfsにでもしてみようかと思っている。この前、jfsのことはいろいろ書いたけど、kernelが新しくなった時に期待出来るのは、こういった「生きている」モジュールだ。まぁそんなに期待してもいないけどｗ

そんなわけで、まだetch末期程度の安定度はlennyにはないので、安定しているものが欲しい人は、lennyは使わない方がいいと思う。

もう慣れてしまったので、落ちても大丈夫。ということを散々経験したところで会得した、今のところの多分間違いのないreiserfsの復旧方法を紹介する。

まずサーバが落ちた時のfsckなのだけど、reiserfsckのオプションは、

–fix-fixable

だけを知っておけばいい。これ以外のオプションはいらない。

オプションなしで起動した場合、–checkを指定したとみなされるのだけど、これでは何も修復してくれない。あくまでもチェックだけだ。だから、これは時間のムダでしかない。「復旧」は急ぐわけなので、異常を発見するためだけにfsckを走らせるのは馬鹿げている。なので、いきなり–fix-fixableで走らせる。

これで特に致命的なエラーが出なかったら、それで完了。普通にサーバを起動すればいい。

致命的っぽいメッセージが出て「復旧出来るのは–rebuild-treeだけだ」みたいなことを言われても、

これはスルー

だ。とは言え、復旧しないわけには行かないので、

1. 新しい領域を確保してmkfs
2. 元の領域を-r付きでmount(read only mount)
3. cp -aでまるっと新しい領域に複写
4. 古い領域を捨てて新しい領域を現用に

ということをやる。なぜなら、

–rebuild-treeは失敗したら何も出来なくなる

からだ。

運が良ければ–rebuild-treeで問題なく復旧出来るのだけど、運が悪いとfsckが異常終了してしまう。その時に出来るのは、–rebuild-tree付きのfsckだけだ。他のことは一切出来なくなってしまう。しかも、これはreiserfsckのバグのせいで、しばしば起きる。私も何度か経験していることは、ここで書いている。

そこで、–rebuild-treeが必要になったら、その領域は潔く捨ててしまう。

–fix-fixableが正常終了すれば、仮に致命的な問題があっても、read only mountは出来るようになる。逆に、–fix-fixableが終了してないと、read only mountは出来ない。生きているファイルを救出する時に、何かおかしなことが起きても困るので、最低限のfsckは完了してread only mountは出来るようにしておきたい。ということを合わせると、この手順しかないということになる。

–rebuild-treeはもう他に何の手もなくて、–fix-fixableした後にread only mountも出来ないとか、lost&foundにアホみたいに落ちてどうしようもないとか、そういった

本当にどうしようもない時に、一か八か

で使うオプションだと思っておいた方がいい。本当はもうちょっとマシな見方が出来るはずなんだけど、–rebuild-treeの失敗具合からすると、そう思っておいた方が良いようだ。

問題はこれを可能にするということは、ディスク領域が倍必要になってしまうということ。実際にはそうならないように、ディスク領域は分割しておいた方がいい。このためにはlvmを使うわけだけど、Debian etchでXenだと、どうも動きが微妙っぽいというところが、頭が痛い。ただ、–rebuild-treeに頼ると復旧不可能ということが起きかねないので、領域の使い回しを考えておくか、reiserfsを使うのを諦めるかすることになる。本当はreiserfsは捨ててしまいたいところなんだけど、意外にも安定で結構パフォーマンスが良いので、なかなか捨てられないのだよね。

まぁうちの使い方が、ソフトウェアRAID + LVM + Xen + JFSという使い方だからかも知れないけど。こう書くと変態的な構成に見えるけど、やってみればことさらに変わった構成ではないと思う。要するにXenの上でJFSを動かしているだけだし、RAIDやLVMなんてのも、仮想化する環境にはありがちの構成だろうし。てか、CPUを仮想化したら、ディスクも仮想化しとかないとメリット半減どころじゃないよ。仮想化環境のボリュームをファイルで構成する時も、そのファイルが載ってるボリュームはLVMにしといた方が、いろいろ都合がいい。だいたいsnap shotが取れるということだけでも、運用をいろいろ楽にする。

で、この組合せだと、高負荷をかけた時にJFSが破壊される。ズタズタって程じゃないけど、いくつかのファイルが飛んでファイルシステムがリードオンリーになるということが、突発的に発生する。何かをやらかしたとかではなく、突発的にだ。だから「高負荷をかけた時に」というのも正確じゃないかも知れない。何かの転みでファイルシステムがおかしくなる。

同じ構成でReiserはなんともない。

ReiserはHansがアレなことになってしまって、いろいろアレなことがあるのだけど、それでも今のところ結構タフに動いてくれている。mountする時に時間がかかるのだけど、途中で壊れるよりはずっといい。

XFSがどうかは試してない。また、最新のカーネルでどうなるかも試してない。LVMでない時にどうふるまうかもわからない。ただ、事実としてetchではLVM + JFSでは時々おかしくなる。Xenはあまりそういったあたりに関与しないから、多分Xenは関係ない。JFS自体はディストリビューションのカーネルモジュールに存在しているから、多分ボリュームがややこしいことでなければちゃんと動くのだろう(でなきゃリリースさせてないだろう)。

まーそれだけ。

PS.

冷静にもう1度考えてみたのだけど、LVMは関係ないはずだ。なぜなら、Xenの仮想環境に見えているのは、単なる仮想ブロックデバイスだけだから、LVMだろうがディスクだろうが同じことだ。ということは、要するに

etchではJFSを使うな

という結論になる。まぁいろいろ条件が絡むのかも知れないが、どうやらダメらしい。

「Google Gadgets for Linux」がオープンソースで登場

GoogleガジェットのLinux版が出たらしいので、入れてみた。ブツは、

google-gadgets-for-linux

にある。特に難しいこともなく、configureしてmake, make installで入る。

うちで動かす限り、ちょっとCPUを食い気味なのが気になるけど、許容範囲かな。とは言え、なんかバグバグしてる。Ver 1.0までダチョウアルゴリズムするのが吉。

いつも通り読んでいると、今月はちょっと異様な感じだった。何が異様かと言えば、「エンタープライズ」な特集が1つあること。多分これは日経コンピュータ編集部から移って来た森側さんの影響かなとちょっと思ったのだが、個人的にはなかなかいい。

かつていくつもあった「Linux雑誌」は、とうとう日経Linuxだけになってしまった。似たような本をゴチャゴチャ買わなくて済むのは結構なことなのだが、紙メディアによる情報源が1つになってしまうというのは、全ての情報がその情報源次第ということになってしまう。もちろんFOSSの情報はネットが一番速いのはあるけれど、速報性があまりいらない解説記事は、いまだに紙の方がわかりやすい。

ところが、しばらく前から日経Linuxは

Linuxをおもちゃにしたい初心者向け雑誌

になっていた。「日経」とついていながら、あまりビジネス色はないし、そういった方面の情報はあまりなかった。SoftwareDesignも技術情報については充実しているのだけど、どうも技術ベタベタ過ぎて「その領域ならネットの方がいいよ」という、ちょっと居場所間違えてる感があった。

そんなわけで、購買意欲をそそるような雑誌があまりなくて、「特集が面白かったら買うか」という程度になっていた。元より紙メディアが不況にあるわけなので、「読むべきものがないなぁ」というのはみんな共通のことではなかったかと思う。

でまぁ今月の日経Linuxはそういった「今までの」ものとはまるで違う、「異様」とさえ思えるくらい場違いな特集だった。でも、これが私の目には非常に良い方向転換に見える。なぜなら、他にはあまり「エンタープライズ」な記事がなくて、せいぜい「日経コンピュータ」くらいなものだったからだ。

もちろん今見ると、周囲の記事から浮き過ぎていて「異様」な感じさえする。だけど、もしこの方向にも舵が切れるなら、単なる「Linuxをおもちゃにしたい初心者向け雑誌」から「ビジネスを志向した雑誌」に変化することが出来る。

実はこれは「日経Linux」が創刊した時に期待していたことだ。何しろせっかく「日経」とついているのだから、やはりそういった方向を期待していた。それをどう「間違った」か初心者雑誌になってしまっていて、他の雑誌との差がなかった。結果的に最後まで残ったのだけど、他が生き延びていたら没個性なままだったと思う。それが「日経」らしい雑誌になろうとしていることで、評価したいと思う。

今回は全く綺麗な環境を作って、NBDを使って試してみた。

結論的にはやっぱり失敗。

空いているサーバが2台あるので、片方でNBD serverを動かし、それぞれからNBD clientでつながるようにし、OCFS2を両方で動かしてみた。

DebianはNBD serverが動いている方(以下ginza)がsid、動いてない方(以下shinbashi)がetch。ginzaはAthlon 64 E6000+、shinbashiはCore 2 DUO E8400だ。メモリは両方とも6GBなのだが、shinbashiはなぜか3GBしか認識してない。kernelはどちらも2.6.24.2。

という環境で、まずginza用の/etc/nbd-server/configを作る

[generic]
[export]
    exportname = /dev/sda4
    port = 12345
    authfile = /etc/nbd-server/allow

authfileは動作がおかしかったので、結局使わず。作らないと「どこからでもOK」になってしまうが、実験だから問題ない。

/etc/nbd-clientは共通で、

AUTO_GEN="n"
NBD_DEVICE[0]=/dev/nbd0
NBD_TYPE[0]=r
NBD_HOST[0]=192.168.2.27
NBD_PORT[0]=12345

この状態で双方から接続を試すと、それぞれのサーバ上の/dev/nbd0にginzaの/dev/sda4が見える。

OCFS2には/etc/ocfs2/cluster.confが必要なので作ってやるが、これはどのサーバにも共通の内容。

node:
        ip_port = 7777
        ip_address = 192.168.2.14
        number = 0
        name = kabigon
        cluster = ocfs2
（中略）
node:
        ip_port = 7777
        ip_address = 192.168.2.27
        number = 6
        name = ginza
        cluster = ocfs2

node:
        ip_port = 7777
        ip_address = 192.168.2.26
        number = 7
        name = shinbashi
        cluster = ocfs2

node:
        ip_port = 7777
        ip_address = 192.168.2.11
        number = 8
        name = shibuya
        cluster = ocfs2

cluster:
        node_count = 9
        name = ocfs2

てな感じ。

後は前にやったような手順で設定。ginzaで初期化して双方でmount出来るのを確認した。

程々のディレクトリをcp -aしても問題がないので(iSCSIだとこの時点でコケる)、耐久試験を行う。実験に使うのはこのサーバの/homeディレクトリ。このサーバには2000くらいのユーザがいて、500GB弱使っている。ちょうど/dev/sda4と同じくらいの大きさだ。

nfs mountしてcp -aを開始してそのまま寝て起きたら、双方rebootしていた orz

/ver/log/kern.logによると、開始3時間半くらい経過したところでrebootがかかったようだ。異常らしいものが記録されていないし、ginzaはすんなり再起動しているので(shinbashiはgrubでひっかかっていた)、panicにもならないで再起動したのだろう。だとするとiSCSIの時と同じ現象だ。

実験開始当時は双方からディレクトリの内容は見えているし、特に異常らしいものはなかったので、なんだかよくわからないところで何か起きている。

つーことで現在のところの結論は、「NBD + OCFS2はそこそこは動くけど耐久試験には耐えない」ということだな。OCFS2については、世間で「やってみました」的な情報はいくつかあるのだが、もしかして耐久試験をやってないんじゃないか？ 「動く」と言われるものをあれこれ試してこんなに動かないってのも珍しいような気がするが。それとも例によって私が根本的な間違いをしてるのだろうか？ node数を減らして試してみるかな。

PS.

複数からmountしないでshinbashiからだけmountしてcpしたら、無事全部コピー出来た。どうも協調動作する何かに問題があるようだ。

PS.2

/etc/ocfs2/cluster.confの記述を、実際に使っているnodeだけにしてみたのだが、やっぱり途中でコケる。OCFS2はいわゆるexperimentalな実装ではないはずなんだが、こんなに簡単にコケるというのが理解出来ない…