uyota 匠の一手

リアルタイムシステムで、大量のデータを取り扱う必要がある。また、無停止が条件なので、各種サーバ群は二重化してある。その動作検証の為にいくつかの構成を試していたのだ。今回、問題のある部分の OS は Solaris だ。

構成としては以下のようだ。Sun サーバに大量のデータが送られてくる。あるプロセス群が、データをネットワークから読み取り、ファイルに書き込む。それを別のプロセスが読み出し、データ形式を変換してからファイルに書き込む。なぜ、ネットワークから読んだものを、直接変換してから書き込まないのかと言うと、負荷の分散と障害時の復旧の為だ。

最初は、ソフトウェア構成の簡略化の為に Cluster File System (CFS) の導入を検討していた。一つのディスクデバイスを、複数のサーバからローカルディスクのようにマウント出来る代物だ。CFS は性能に難があるらしい。ファイルの書き出し手と読み込み手が同一上のサーバに無いと、性能が著しく劣化した。そのためにサーバ間のプロセスの調整が必要となった。

プロセス群を再配置し、処理速度を上げていくと、ファイルの読み出し手からファイルが破損していると警告するようになったのだ。ネットワークからデータを書き込んだファイルには、データの整合性を点検できる仕組みがあり、それがデータに異常を検知している。あるサーバ上で書き込まれたファイルを別のサーバから読み出すと一定の割合でデータが破損している様なのだ。

最初は他にも問題が顕著化していた CFS が疑われていた。試験を繰り返し、問題の再現性を起こせる状態のツールにたどり着いたらしい。検証実験をやっている張本人ではないので、いくつか曖昧なところはあるかもしれない。

まず、第一には書き込まれたファイル自体には問題がない事。つまり、一度ファイルシステムに書かれたファイルを元に第二次変換を施すと何も問題がない事。つまり、ファイル自体は問題なく書き込まれていると言うことになる。

そこで、ファイルが高速に書かれている状態を作り出して実験したらしい。cat を使って模擬実験だった。これでは、再現性はなかったらしい。最初は再現できるのは、他のシステムも含めたいくつかのシステムを繋ぐ必要があった。これまでの状況だと、ファイルシステム以外から来たデータをファイルに書き込み、それを読む別サーバ上のプロセスにて問題が起こるらしいとの事で、それなりの助言はした。その後、Sun サーバだけで再現できたと聞く。恐らく、再現検証のプログラムは内部的に疑似データを生成し、ファイルに書き込んでいると思う。これを聞く機会がなかった。

この問題は、同一サーバ上でファイルを読み出すと起きないとのことだった。そこで、同様な構成で CFS を一度停止し、NFS を用いて同じようなサーバ間のファイル配置を行なったところ、同じ問題が発生したとのことだ。Sun の NFS 上で、このようなデータの破損事故が起きたのは、少々驚きであった。

NFS と言えば、もう世に出て長くなるし、Solaris での NFS も様々な所で使われているはずである。Solaris 10 でも、Gigabit Ethernet が出て来て NFS の性能が追い付かないので、再実装したと言うが。Solaris 10 の NFS は事情があって、正式リリース前から使っていたが、特にこのような問題も聞いたこともない。バージョンも上がり、数々の変更や性能の向上が図られていると言え、既に、枯れた技術だと思っていたから、驚きもなおさらだっだ。

この様な症状だと、Solaris のキャッシュか何かに問題があるように見えるが、今のところは根底の問題は掴めていないらしい。Sun の人達も、原因探求中との事だが、当事者の一部ではないため、ここ数日の進展状況は詳しくはない。とりあえず、サーバの構成を変え直して、性能に問題が無いかを調べて備えるとのことだ。

Solaris の NFS 関連で、ファイル破損の情報などがあれば、是非教えて欲しい。