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
まあ、明日は我が身と気を付けよう。

Btrfs の resize

別記事で Btrfs 化について書きましたが、実験環境とは別に 20G のパーティションに別途 Fedora19 をインストール済みでしたので、これを 10G に縮小する操作を行ってみました。Btrfs は未だ開発途上という状況なので、最悪の場合は、ぶっ壊れるかもねという心象がありますが、まあ、壊れてもさしてダメージが無い環境なので。

縮小操作は、man btrfs の通りで、いたって簡単でした。

# btrfs filesystem resize 9g /

システムデータしか入ってないこともあり、処理は殆ど一瞬で終わりました。サイズ指定は、いったん 9g にしていますが、パーティションを 10G に縮小後に、パーティションサイズまで resize するために、適当に 1G ほど余裕をとりました。
パーティション縮小は fdisk -u で行い、システム再起動後に次のように操作を行いました。

# btrfs filesystem resize max /
Resize '/' of 'max'

# df
Filesystem     1K-blocks    Used Available Use% Mounted on
/dev/sda10      10240000 2441692   6037316  29% /
devtmpfs         4011116       0   4011116   0% /dev
tmpfs            4017612     156   4017456   1% /dev/shm
tmpfs            4017612     780   4016832   1% /run
tmpfs            4017612       0   4017612   0% /sys/fs/cgroup
tmpfs            4017612      44   4017568   1% /tmp

# btrfs filesystem balance /
Done, had to relocate 7 out of 7 chunks

# df
Filesystem     1K-blocks    Used Available Use% Mounted on
/dev/sda10      10240000 2442728   7569272  25% /
devtmpfs         4011116       0   4011116   0% /dev
tmpfs            4017612     156   4017456   1% /dev/shm
tmpfs            4017612     780   4016832   1% /run
tmpfs            4017612       0   4017612   0% /sys/fs/cgroup
tmpfs            4017612      48   4017564   1% /tmp

balance という操作が肝で、これを行わないと、空きが少なく見えます（たぶん、balance しなくても、逼迫してくれば使われるのかな??）。

2019-11-16追記
Btrfs raid1 のサイズ拡張を行ったのですが、前述の balance 操作ではダメでした。検索してみると、先人の方がおられましたのでメモ。
https://qiita.com/takaki@github/items/5d96d80dc78b09ea600b
明示的に devid を指定することで、うまくいきました。実施した環境は CentOS7 です。
man btrfs-filesystem を読んでみると、デフォルトの devid は 1 であると記載あるようです。むしろ、devid 指定必須のほうが、分かり易いのではと思ってしまった。先人の方の情報に辿りつくまで、無駄に時間を使ってしまいました。最初から man をちゃんと読めばよかったというのもありますが。