クライアント側障害時回避機能

クライアント側障害時回避機能を使うと、複製されたファイルシステムをサポートしているサーバが使用不能になったときに、NFS クライアントは別のサーバに切り替えることができます。ファイルシステムが使用不能になる原因としては、接続しているサーバのクラッシュ、サーバの過負荷、ネットワーク障害が考えられます。通常、このような場合の障害時回避機能はユーザには分かりません。設定が行われていれば、障害時回避機能はクライアント上のプロセスを中断することなく実行されます。

障害時回避機能が行われるためには、ファイルシステムが読み取り専用でマウントされている必要があります。また、ファイルシステムが完全に同じでないと障害時回避機能は成功しません。ファイルシステムが同一になる条件については、「複製されたファイルシステムとは」 を参照してください。障害時回避機能の候補としては、静的なファイルシステム、または変更の少ないファイルシステムが適しています。

CacheFS を使ってマウントされたファイルシステムは、障害時回避機能には使えません。CacheFS ファイルシステムは、それぞれについて追加情報が格納されています。この情報は障害時回避の際に更新できないため、ファイルシステムをマウントするときには障害時回避機能と CasheFS のどちらか片方の機能しか使えません。

各ファイルシステムについて用意すべき複製の数を決める要素はさまざまです。一般的に、サーバを何台か用意してそれぞれが複数のサブネットをサポートするという環境の方が、サブネット 1 つについて 1 台のサーバを用意するよりもすぐれています。この場合、リストにあるサーバを 1 台ずつチェックする必要があるため、リスト上のサーバが増えるにつれてマウントにかかる時間も増えます。

障害時回避機能に関する用語

障害時回避機能のプロセスを完全に理解するには、以下の 2 つの用語を理解しておく必要があります。

• 障害時回避機能 - 複製されたファイルシステムに対応するサーバのリストから、サーバを選択すること。通常、ソートされたリストの順番を元に、次のサーバが応答するならばそれが使われます。

• 再マッピング - 新しいサーバを使うこと。クライアントは、正常な状態のときにリモートファイルシステム上のアクティブなファイルそれぞれのパス名を格納します。再マッピング時には、そのパス名に基づいて新しいサーバ上のファイルを見つけます。

複製されたファイルシステムとは

障害時回避機能に関して、あるファイルシステムのすべてのファイルが元のファイルシステムのファイルとサイズも vnode タイプも同じ場合に、そのファイルシステムを「複製」といいます。アクセス権、作成日付などのファイル属性は関係ありません。ファイルサイズか vnode タイプが異なると再マッピングは失敗し、元のサーバが再び使用可能になるまでプロセスはハングします。

複製されたファイルシステムを保守するには、rdist や cpio などのファイル転送機構を使います。複製されたファイルシステムを更新すると不整合が発生するので、できるだけ以下を守ってください。

• 新しいバージョンのファイルをインストールするときは、あらかじめ古い方の名前を変更する

• クライアントによる使用が少ない夜間に更新を実行する

• 更新は小規模にとどめる

• コピーの数を最小限にする

障害時回避機能と NFS ロック

ソフトウェアパッケージの一部は、ファイルに読み取りロックをかける必要があります。そのようなソフトウェアが正常に動作できるようにするため、読み取り専用ファイルシステムに対しても読み取りロックがかけられるようになっています。ただし、これはクライアント側でしか認識されません。サーバ側で意識されないため、再マッピングされてもロックはそのまま残ります。ファイルはもともと変更が許されないので、サーバ側でファイルをロックする必要はありません。