CentOS 5 + UEK で ZFS on Linux を利用

CentOS 5 で運用しているサーバでも、ZFS on Linux を利用したかったのですが、カーネルのベースバージョンが古く、ビルドできないため諦めていました。もっと新しいバージョンのカーネルを自分でビルドすれば不可能ではないとしても、手間がかかり過ぎますし。

ところが、あまり着目していなかったオラクル社提供の OEL5 (Oracle Enterprise Linux 5) 向けの UEK (Unbreakable Enterprise Kernel) R2 なら、カーネルのベースバージョンが 3.0-stable であることを知り、それならビルドできるのではと、やってみました。
最終的には利用できるようになりましたが、いろいろとトラブルに直面しましたし、もし既に CentOS 5 で運用中で、どうしても ZFS を利用したいということでなければ、やめたほうが良いかと思います。難易度は少し高めではないかと。
わたしが遭遇したトラブルの数々です。

(1) kernel-uek パッケージだけ入れてみたが、UEK カーネル 2.6.39 が起動できない
(2) なんとか UEK カーネルが起動できたが、起動時にシステム時刻が狂う
(3) 起動時に udev のエラーが出る
(4) multipath が動作しなくなり、multipath + LVM のボリュームが正しく初期化できない
(5) CentOS 5 標準のカーネル 2.6.18 系では出ていなかった audit のメッセージが出まくる
(6) 肝心の ZFS のビルド時、dkms がエラーを吐く (ZFS の利用には支障ないようです)
(7) 監視で利用している munin が動かなくなった
(8) KVM ゲスト用にカーネルブートオプションで設定していた hugepage 数が、UEK カーネルではなぜか少し不足した
(9) KVM ゲストの一つが起動できない
(10) UEK カーネルにも ksmd は居るのだが、ksmctl start 出来ない

これらのうち (9) と (10) は未だ解決できておらず、かなりの手間ではありましたが、わたしの場合には、やってみて良かったという印象です。ZFS on Linux 0.6.2 が活用できるようになったのは勿論のこと、CentOS 5 標準カーネルでは提供されない機能（tickless 、zram 、ext4 の discard 、btrfs 等）も利用できるようになりましたので。
もし、当該サーバを CentOS 6 にバージョンアップするとしたら、今回の手間どころではなかったと思いますし、カーネルだけ最新装備にするという、オラクル社のアイデア・策略は、なかなか憎いことを・・・と思いました。

なお、CentOS 5 + UEK + ZFS on Linux 0.6.2 の性能を実験環境（ThinkPad T510）で測定してみたところ、同一マシンのマルチブート環境の CentOS 6 で測定した値と同程度でした。こちらの過去記事の CentOS 5 環境で、UEK の導入練習・試行をしてから、サーバに手をつけました。

2014-06-17追記
ZFS on Linux 0.6.3 がリリースされたので、CentOS 5 + UEK の環境でソース（.tar.gz）からビルドしてみたところ、まだ、ビルド可能でした。別記事で書きましたが、かなり性能アップしているので、迷わずアップデートがオススメかと思います。

kernel.pid_max の拡張

デスクトップ用途での Linux 利用では、不要と思いますが、少し大きなサーバ用途では pid の上限値を拡大しておいたほうが良いかもしれません。CentOS では /etc/sysctl.conf で設定します。

kernel.pid_max = 99999  ※デフォルト 32768、同時起動スレッド数も制限されるのでご注意を、、、

いくつまで拡張しておくかは用途次第ですが、pid を画面表示するようなツールで、くずれた表示の原因となるかもしれませんので、不足しなさそうなら、99999 (5桁、デフォルトの約3倍) にしておくと良いのではと思います。pid 管理はビットマップ方式で行われるので、pid_max を増やしてもメモリ消費はほとんどありません。
なお、最近のカーネルでは、サーバ規模に応じて自動的に拡張されるようなので、sysctl.conf に設定する前に、現在の値を確認したほうがいいです。それと、32bit 版では 32768 より大きい値は設定できません。いまどき、サーバで 32bit 版を使うことは少ないと思いますが。

2013-10-14追記
うろ覚えで”サーバ規模に応じて・・・”と書きましたが、CentOS 6 のカーネル 2.6.32-358.el6 を見てみたら、CPU 数が多い場合に拡張されるようになってました。kernel/pid.c の中です。CentOS 5 系のほうは、CPU 数に応じた自動拡張の処理は無いようでした。2.6.18-348.el5 参照。
CentOS 6 / RHEL6 のサーバ構築の際、闇雲に kernel.pid_max を設定すると、意図せず下方修正してしまうかもしれませんので、構築屋さんの方はお気をつけて。まあ、システム設計上下方修正な値で良いならよいわけでしょうけども。

2015-03-08追記
本日、マルチブート環境の FreeBSD 10.0 を 10.1 に upgrade したのですが、その際に、top を眺めていたら、FreeBSD の pid 範囲が 99999 までであるようでした。FreeBSD 付属の top では、どういう意図なのか last pid なる表示項目があり、そこを眺めていたら、99999 で wrap しました。トリビアですが、参考メモです。
補足：ZFS on Linux に強く興味を持っており、FreeBSD 実装との比較用に、マルチブート環境を作ってあります。なので、FreeBSD は殆ど使ってないです。現在は、デスクトップ利用なら CentOS 7 が最も使い易く感じています。systemd のおかげで起動が抜群に速いし。

2016-06-11追記
レッドハットのナレッジに、RHEL6 の pid_max 自動拡張の話しが説明してありましたので、リンク張っておきます。
https://access.redhat.com/solutions/28908
https://access.redhat.com/solutions/874023
CPU 数が 32 より大きいと、1024 x CPU 数 に拡張されますよと。

2019-01-30追記
kernel.pid_max が 99999 以下でないとマズいというソフトウェア (GUARDIANWALL) が実際にあった。
https://security-support.canon-its.jp/info_and_news/show/10?site_domain=GUARDIANWALL
まあ、明日は我が身と気を付けよう。