彷徨えるフジワラ

年がら年中さまよってます

OpenSolaris 勉強会 2012.06

東京 OpenSolaris 勉強会主催の 2012.06 勉強会に参加してきた。

いつもであれば、要約した発表資料を元に "Solaris Internals" の内容について話すのだけれど、そろそろ書き溜めた分が尽きるので、読み込みをしないといけないなぁ、などと思っていたら、さくらインターネットサービスの障害調査報告が発表された旨のニュースが飛び込んで来た。

つらつらと眺めていると:

仮想マシンにローカルディスクとして見せる領域は、ストレージサーバ上に確保した領域に NFS 経由でアクセスしている

というような情報がポロポロと出てくる。

実際に『さくらのクラウド』の内部アーキテクチャがどうなっているのか、詳細はわからないけれど、公開されている情報をベースに考えると、ユーザが確保した仮想ディスク毎に、ファイルシステム作成+exportが実施されているように読める。

物理的なクライアントは 1,000 台規模、契約ユーザ数と同数以上となる共有対象ファイルシステム数は 10,000 以上にはなると考えると、Solaris NFS のソースを読んだ身としては、明らかに適切性に欠けているとしか思えない。

オラクルの「Sun ZFS Storage Appliance」が利用されていることから、『ZFS は駄目だ!』的な言及を幾つか見たことがあったけど、それは違うんじゃねぇ?(あるいは、それ以前の問題じゃねぇ?)という思いがふつふつと。
ということで、ホットな話題でもあることなので、急遽お題目を変更して、大規模システムにおける Solaris NFS 実装の問題に関して話すことに。

急遽題目を変更しただけあって、予想通りというかなんというか、発表ギリギリになって、やっと資料が完成する始末…orz

# まぁ、直前に軽く風邪を引いたのも失敗だったのだけど…

発表的にはまぁまぁ好評だった模様で一安心だけど、『Solaris NFS 実装の問題』と言いつつ、結構な部分は『mountd 実装の問題』だったような気がしないでもないのは内緒(笑)。

但し、『線形走査が増えた場合に性能が劣化』というあたりは、参加者的には『本当?』という印象だった模様。っていうか、僕自身、実体験として経験していても、『二桁以上の要素の線形走査が発生すると、性能劣化の要因に成りえる』というのがイマイチ信じられない。

もっとも、単なる線形走査じゃなくて、strcmp() やら memcmp() で 32 バイトかそれ以上のメモリ比較を伴う線形走査なので、その辺も影響してくるかも?ということで、性能測定してみることに …… うーん、1,000 要素あっても 0.1 ミリ秒にもならんなぁ……

裏で大量の処理が併走しているファイルサーバと、デスクトップPC上での簡易ベンチとでは、キャッシュヒット的にもイコールコンディションでは無いけれど、それにしても 0.1 ミリ秒じゃぁねぇ。

んが、そこでハタと思い当たることが!

同じ事を2回書くのが面倒なので、興味のある方は、発表資料末尾に追記した『線形走査のコストに関する考察』をどうぞ(笑)。

あ、あと発表資料には書いてない対応策として『ハッシュテーブルサイズを大きくした独自カーネルモジュール/コマンドをビルドして使う』という手もあるので、切羽詰っている人はどうぞ(笑)。