リモートファイルシステムを使ってRAID-1を構成できるChiron FS
LinuxカーネルはRAID-1の実行をソフトウェアでサポートしている。RAID-1では、1つのファイルシステムを2台以上のディスク装置で保持するため、障害が発生しても最後のディスクさえ生き残っていればすべてのデータを復旧できる。すばらしい仕組みだが、メモリや電源ユニットなど、ほかのハードウェアコンポーネントが故障した場合にはやはり貴重なデータが失われる可能性がある。だが Chiron FS を使えば、ネットワーク上の2台のマシンが持つディスクで1つのRAID-1を構成でき、一方のマシンがダウンしてもファイルシステムにアクセスし続けることができる。
RAID-1構成が維持された状態で一方のマシンに障害が発生した場合でも、ネットワーク接続が無事であれば、障害で破損したファイルがChiron FSによって他方のマシンに複製（レプリケーション）されるおそれがある。だが、2台のローコストPCとネットワーク接続だけでファイルシステムを冗長化できることを考えれば、この程度のリスクは受け入れざるを得ないだろう。ただし、ほかのソリューションと組み合わせて、データのセキュリティ性と可用性を高めることは可能だ。
Chiron FSを使うにあたっての主な要件は、RAID-1を構成する場所がLinuxカーネルによってファイルシステムとしてマウントできることだ。たとえば、ローカルにマウントされたext3ファイルシステムと、NFSまたはsshfs経由でバックアップ用マシンからマウントされたXFSファイルシステムがあれば、Chiron FSを使って双方のファイルシステムで同じ内容を保持できる。
Chiron FSは、openSUSE 10.3の1-Clickインストールに対応しているが、FedoraやUbuntuのリポジトリには収録されていない。だがChiron FSのダウンロードページに行けば、Ubuntu HardyおよびGutsy用とFedora 8用の各種パッケージが手に入る。ここではChiron FSのバージョン1.0.0のソースを64ビット版Fedora 8マシンでビルドした。インストールには、標準的な「./configure; make; sudo make install」の手順を用いる。
以下に、Chiron FSの設定方法と簡単な使い方を示す。まず、冗長化するファイルシステム用のディレクトリを作成する。この例では「local-disk-filesystem」と同じディスク上に「my-other-server-filesystem」を作成しているが、このディレクトリはNFSマウントされたファイルシステム上でも簡単に作成できる。Chiron FSに「--fsname」引数は必要ないが、できればファイルシステムにわかりやすい名前を付けておくに越したことはない。続いて、Chiron FSによる「~/my-chiron」ディレクトリにファイルを作成し、そのレプリカである「/tmp/chiron-testing/my-other-server-filesystem」にも同じファイルができていることを確認している。
$ mkdir /tmp/chiron-testing $ cd /tmp/chiron-testing $ mkdir local-disk-filesystem $ mkdir my-other-server-filesystem $ mkdir ~/my-chiron $ chironfs --fsname chiron-testing /tmp/chiron-testing/local-disk-filesystem=/tmp/chiron-testing/my-other-server-filesystem ~/my-chiron $ df ~/my-chiron Filesystem 1K-blocks Used Available Use% Mounted on chiron-testing 15997880 10769840 4402288 71% /home/ben/my-chiron $ date > ~/my-chiron/test1 $ cat ~/my-chiron/test1 Thu May 29 15:17:30 EST 2008 $ cat /tmp/chiron-testing/my-other-server-filesystem/test1 Thu May 29 15:17:30 EST 2008 ... $ fusermount -u ~/my-chiron
Chiron FSを使うときには、レプリカのファイルシステム（上記の例では「/tmp/chiron-testing」内の2つのディレクトリ）を隠蔽して直接アクセスできないようにしておくとよい。そうすれば、間違ってそれらにアクセスして、結果としてデータのレプリケーションをし損なわずに済む。
Chiron FSはログを記録する機能を備えているほか、低速なファイルシステムもサポートしている。ロギングによって、レプリカファイルシステムの問題にいち早く気付き、最後に残ったレプリカが正しく動作せずにデータがすべての失われるという事態になる前に対策を打つことができる。またChiron FSは、読み取り要求を受け取ると、ラウンドロビン・アルゴリズムを使ってレプリカの1つからデータを取得するが、特定のレプリカがほかよりもアクセスに時間がかかる場合にはその旨をChiron FSに伝えることができる。すると、Chiron FSはそのレプリカについてはデータの読み取りアクセスを避け、ファイルシステムのすべての更新内容のレプリケーションだけを行う。このオプションが役立つのは、Chiron FSをオフサイトバックアップに使う場合である。速度とコストの面で不利なサイト外のレプリカからのデータの読み取りを避けながら、ファイルシステムの変更部分をサイト外にレプリケーションできるからだ。
また「/etc/fstab」を使ってChiron FSをマウントするような設定も行える。以下に示す設定では、「/data」というファイルシステムを作成し、そのデータをローカルの「/noaccess/local-mirror」ファイルシステムと、NFS接続されたマシンp1上の「/p1export」ファイルシステムの双方にレプリケーションする。このfstabファイルの記述で「/p1export」の前にあるコロン（：）は、そのファイルシステムがアクセス速度の低いレプリカファイルシステムであることを示している。そのため、Chiron FSはこのNFSファイルシステムからは読み取りを行わない。また、Chiron FSはFUSEベースのファイルシステムなので、最初にChiron FSをマウントしたユーザ以外のユーザからのアクセスを許可するには、「allow_other」オプションを指定する必要がある。
# cat /etc/fstab ... p1:/p1export /p1export nfs defaults 0 0 chironfs#:/p1export=/noaccess/local-mirror /data fuse allow_other,log=/var/log/chironfs.log 0 0 ... # mount /data ...
パフォーマンス
NFSレプリカが1つだけの上記の設定を用いて、ベンチマーク評価を行った。このテストでは、Chiron FSを実行しているマシンと別のマシン「p1」の両方をIntel Core 2 Quad Q6600 CPU上の仮想マシンとして動作させる。この物理マシンはハードウェア仮想化の機能を持つため、仮想マシン内部の実行パフォーマンスを示す数値は主として2台の仮想マシン間のネットワーク接続の影響を受けることになる。どちらの仮想マシンも同じ物理ハードウェア上で動作するので、理論的には、仮想化によって実際より高いパフォーマンスが得られると考えられる。また、仮想マシン内におけるファイルシステムへのローカルなアクセスとNFS経由のアクセスを数値で比較すると、このベンチマーク評価にはネットワーク利用の有無が大きく影響することがわかる。ただし、すべてのテストを同じ仮想マシン上で実行すれば、それらのパフォーマンスの相対比較によって、実環境におけるパフォーマンスの違いがだいたい予測できるはずだ。
テストではまず「/noaccess/raw」を使って、Chiron FSによってレプリカが格納されるのと同じファイルシステムにこのマシンがどれくらい速くアクセスできるかを測定する。続いて、「/noaccess」内の2つのローカルレプリカで構成された「/data-localonly」を使って測定を行う。Chiron FSによってこの「/data-localonly」というファイルシステムを用意したのは、ベンチマーク評価から仮想ネットワーク接続の要因を取り除くためである。さらに、ネットワークを利用した場合のChiron FSの評価には「/p1export」にマウントされたNFS共有フォルダを用いる。以下に、評価の結果を示す。
| ファイルシステム | 構成(ローカル/NFS) | 展開(秒) | 削除(秒) |
| /noaccess/raw | ローカルのカーネルファイルシステム x 1 | 20 | 0.6 |
| /data-localonly | ローカルのカーネルファイルシステム x 2 | 42 | 5.4 |
| /p1export | NFSファイルシステム x 1 | 90 | 20 |
| /data | ローカルのカーネルファイルシステム x 1 およびNFSファイルシステム x 1 | 150 | 25 |
ご覧のように、Chiron FSによる「/data-localonly」でのファイル展開には、それぞれのローカルファイルシステムをそのまま使った場合の2倍近い時間がかかった。また、NFSファイルシステムではローカルファイルシステムに比べてアクセス速度がかなり低下する。NFSによるこのパフォーマンス低下はChiron FSの「/data」にも影響しており、ローカルファイルシステムとNFSファイルシステムそれぞれの単独のアクセス時間を足し合わせた値よりも多くの時間がかかっている。これらの結果から、低速なレプリカファイルシステムが1つでもあるとChiron FS全体のパフォーマンスが著しく低下することがわかる。
続いて、レプリカの一方（ここではNFSファイルシステム）が他方（ローカルファイルシステム）よりも低速であることをコロン（：）オプションによって明示的にChiron FSに伝えた場合の効果を確認するために、Linuxカーネルのtarballを展開しておき、「/data」と「/noaccess/local-mirror」の両ディレクトリからそれらのファイルを参照する評価も行った。なお、コロンオプションは読み取りのパフォーマンスにしか影響しないはずである。書き込みのほうは、その性質上、すべてのレプリカに対して実行しないとデータの整合性を維持できないからだ。こちらのテストでは、Chiron FSである「/data」ディレクトリがローカルファイルシステム「/noaccess/local-mirror」とNFSファイルシステム「/p1export」で構成されている。「/data」でのtarballの作成には30秒近くかかったのに対し、「/noaccess/local-mirror」の場合は6秒ほどしかかからなかった。また、NFSファイルシステム（/p1export）上で直接tarballを作成してもやはり30秒ほどかかった。「/data」でも「/p1export」でも同じくらい時間がかかったことから、コロンオプションは今のところ無視されているか、あるいは私のやり方がまずいためにこのオプションが機能せず、読み取りの操作が双方のレプリカに対して行われているかのどちらかだと考えられる。
まとめ
Chiron FSの使用時には、カーネルの展開済みソースファイルすべての削除に相当な時間がかかった。耐えられないほどの長さではないが、その時間の差は歴然としている。一方、カーネルのtarballを展開するのに要した時間は、2つのローカルファイルシステムで構成されたChiron FSの使用時で通常の2倍ほどであり、ファイルの展開と書き込みの場合はChiron FSによるパフォーマンスのオーバーヘッドはそこまで大きくならない。また、Chiron FSにおける書き込みでは常にディスクへの書き込みが2回必要になるため、Chiron FSによるtarball展開の速度が大幅に向上することもない。ただし、Chiron FSの一方のファイルシステムをNFSマウントした場合は、NFSサーバによる書き込みの遅さがかなり効いてくる。
現行のChiron FSでは、特定のレプリカを書き込み専用にできるはずのコロンオプションが働いていないようだ。この機能が有効になればNFSサーバからの読み取りを避けるように指定できるので、読み取り時のネットワークトラフィックの増加を防ぎ、書き込み時のパフォーマンス低下を抑えることができる。現状のNFSのパフォーマンスに不満がなければ、Chiron FSを使っても動作速度が大幅に低下することはないので、ファイルシステムの可用性の向上とハードウェアの故障に対するある程度の備えがわずかなコストで可能になる。
Ben Martinは10年以上前からファイルシステムに携わっている。博士号を持ち、現在はlibferris、各種ファイルシステム、検索ソリューションを中心としたコンサルティング業務に従事。
