４．ファイルサービス

　KEKBシステムにおけるファイルサービスはその用途により大まかに次の5種類分類され、それぞれ異なる方法により提供されている。また、システムファイルを除き実際にファイルを保持するディスクには活性保守が可能なRAID5ディスクが使用されている。ディスクユニットの総数が600を超えるため、平均寿命を単純に割り算すると週に１度程度のユニット故障が予期される。実際には初期故障を除き、月に１ユニット程度の故障に収まっている。運用時間が平均寿命を過ぎるころから故障頻度が急増しないことを祈っている。

システムファイル： OSやシステム設定ファイル、ログなど。このファイルにアクセスできないと計算機が停止してしまうため、計算機に直接接続された独立なSCSIディスクに2重化して保持している (Solaris Disk Suite使用)。２つのうち１つに異常が生じても運用続行が可能であり、ほとんどが読み出しだけなのでオーバーヘッドもほとんどない。しかし、立ち上げの際に Solaris Disk suite の問題で立ち上がらなくなってしまうことがあった。

ホームディレクトリー： ユーザー開発のプログラムソースやメイル、ドキュメントなどのファイルをこの場所に保持する。ファイルのサイズがデータファイルなどに比べ小さく、読み書きの比率はほぼ同等である。KEKBシステム以外のホストからマウントされることを考慮してセキュリティー上の観点からDFSが使用されている。DFSでは、１日に一回スナップショットのバックアップがとられるので、ユーザーはうっかり消してしまったファイルなどを自分で簡単に復旧することができる。

アプリケーション実行ファイル：ユーザー開発または、市販のアプリケーションソフトウエアのファイルを保管するためのものであり、DFSで提供されている。ほぼ読み出しのみで、多数のクライアントから同時にアクセスされるため、クライアントのファイルキャッシュが有効に機能する。また、ファイルの実体を複数自動的にコピー・保持して負荷分散や可用性を向上するレプリカサーバ機能も有効につかえる。

データファイル（1）： 解析結果などのデータで、多くのユーザが同時に使用する可能性の高いファイルが置かれる。階層型ファイルシステムとNFS (Network File System Ver.3) によりサービスされる。階層型ファイルシステムは簡単にいえば使用頻度が下がったファイルが自動的にディスクからテープなどのアクセス性は低いが保存コストの低い媒体に移動(migrate)され、再び必要になったときテープなどからディスクに戻される仕組みである。KEKBシステムではディスク階層が3.5TB、テープ階層を含めると最大約60TBがこの方法で提供されている。ファイルの典型的サイズは１GBオーダーで、読み書きはほぼ同頻度である。一人のユーザが次々と一連のファイルをスキャンしていくことが普通であるため、ファイルサイズの大きさと共にクライアント側のキャッシュが大きなオーバヘッドとなるためDFSは使われず、NFSをAP netを通じて使用している。 AP net自体は200MB/秒 の転送速度を有するが、プロトコルオーバーヘッドとDISKの性能の上限（〜10MB/秒）により NFSを介する使用では 8MB/秒程度の性能である。

データファイル（２）： 実験の生データで、データ収集などの定型ジョブにより使用される。ファイル最大容量は約80TBである。ファイルの平均サイズは40GB、読み書き頻度はほぼ同程度。かぎられたユーザからのみ利用されること、転送速度を保証する必要があること（データ収集で15MB/秒）から、テープへの直接読み書きによりおこなっている。テープのボリューム管理やテープライブラリーのコントロールには富士通特製のソフトウエアを使用している。

DFS と NFS
　ファイルシステムとして、主にDFSとNFSを用途により使い分けていることがおわかりいただけたと思う。DFSとNFSの主な相違は

(1)	クライアントにおける、ファイルキャッシュの有無。
(2)	ファイルシステムのマウント情報を、クライアント側に（NFS）持つか、ネットワーク上の独立したファイル情報サーバ(DFS）に持つか。
(3)	レプリカサーバの有無。

等である。DFSでは、各クライアントに必要に応じた量のキャッシュを持つことが出来、複数のキャシュと実体ファイルの無矛盾についてもよく考慮されている。これにより、クライアント数がふえても、サーバ側の過負荷がおこりにくい。一方、キャッシュにヒットしなかったデータについては、オーバーヘッドのためにNFSより転送速度をあげることができない。キャシュの中身の更新が頻繁になると、このオーバーヘッドがひどく大きくなる。したがって、キャシュのサイズやユーザのファイルアクセスパターンなどを考慮しながらのチューニングや適用が必要である。
上記(2)の特徴のために、DFSはファイルの物理位置（サーバの場所）をクライアントユーザには透過的に移動することができるため、パーティションあたりのユーザの配置についてあまり悩む必要がない。（移動中のファイルへのアクセスは、移動終了まで待たされる。）
サーバが増えた場合でも、クライアント側に一台ごとにマウント情報（/etc/fstab や auto_xxx）を用意する必要がないため、クライアント側の設定が随分容易である。
DFSでは ファイルの複写をもつ複数の読み出しのみ可能なレプリカサーバを持つことができる。これは読み出しが主なアプリケーションソフトの供給には非常に有用である。読み書き可能なレプリカサーバは開発が待たれる技術であるが、ファイルの同期とcoherency(一貫性)に困難があり、いまだ実現されていない。