図 4 amd によるホーム・ディレクトリのマウント NFS サーバー usr home var hayao : dOC tex . 」 oe 自動マウント amd による . amd—mnt home : doc tex.. NFS クライアント (amd) h ayao home usr シンポリック・リンク して、一定時間 (FreeBSD の amd では、とくに指定し なければ 2 分間 ) /home/hayao 以下のファイルにアク セスがないと、 amd は /. amd-mnt/home/hayao をア ンマウントします。 これまでの例とは異なり、 NFS サーバーの /home を マウントするのではなく、 /home/hayao をマウントして いることに注意してください。 amd では、 NFS クライア ントの /home を管理する場合、 /home のサプディレク トリ ( シンポリック・リンク ) に対するアクセスを監視し、 アクセスがあったサプディレクトリごとにマウントを実行 します。 NFS サーバーの /home を NFS クライアント の /home にマウントしたいときは、もうすこし凝ったテ クニックを使う必喫があります。 ホーム・ディレクトリだけを amd で管理するのであれ は、 /etc/fstab を利用する去とくらべてあまりメリッ トを感しないかもしれません。しかし、多くのオートマウ ンタではローカルな CD-ROM ドライプなども管理でき ます。 UNIX では、一ヨ殳に CD-ROM などのマウントは スーパーユーサーでなければおこなえませんが、 amd な どのオートマウンタを使うと、一ヨ殳ユーサーでもマウント できるようになります 10 オートマウンタについての説明はここまでにします。詳 細は、 amd に関しては文献 [ 5 ] を、 automount に関して は文献 [ 6 ] などを参考にしてください。 NFS クライアントのデーモン オートマウンタに関連するデーモンを除けば、 NFS ク 10 より確には、一ヨ殳ューサーによる CD-ROM ドライプ / ) アクセス オトマウンタかオ剱日し、マウント操作を自的におこないます。 UNIX MAGAZINE 2002.1 ライアントに関するデーモンは 1 つだけです。 FreeBSD は nfsiod 、 SunOS の場合は biod がこれに相当しま す 11 これらのデーモンは複数起動され、 NFS クライアント の複数のリクエストを NFS サー ーに対して並列に処理 します。これによって NFS クライアントのパフォーマン スは矼 E しますが、かならす起動しなければならないわけ ではありません。 FreeBSD では、 /etc/rc. conf ファイルに nfs_c1ient_enab1e="YES " という行を書いておけは、 OS の起重加こ nfsiod が自動 的に起動されます (NFS サーバーに関するデーモンと同 様、 sysinstall コマンドで設定することもできます ) 。 オートマウンタに関連するデーモンについては、前出の 文献 [ 5 , 6 ] などを参照してください。 シェノレの言殳疋ファイノレ ホーム・ディレクトリを NFS で共有すると、どの NFS クライアントを使ってもユーサーのホーム・ディレクトリ の内容は変わらないので、必要なファイルをほかのコンピ ュータからコピーするといった手間が省けます。しかし、 OS や機種の異なる NFS クライアントカ鯤在する工竟で は、アプリケーション・プログラムの↑褓昜所や、プログ ラムの使い方か徴妙に異なることがあります。、、どこでも 同し作業環境 " を実現するには、自分が使っているシェル の設定ファイルを上手に言当する必要があります。 11 SoIaris や Linux には NFS クライアントに関するデーモンはなく、 カーネルて処理されています。 43

特集ネットワークの基礎知識 0 log tm P log tmp 図 1 ローカルなファイルシステムの輊成例 / ( ルート ) home hayao 」 oe usr bin lib local bin lib db 図 2 NFS マウント列 三 hayao joe.: home NFS マウント home ファイルサ / ( ルート ) usr bin lib var var クライアント / ( ルート ) usr : bin lib 三 lib local var db 一方、 NFS を利用すると、あらかじめ指定した NFS サーバー上のディレクトリを、あたかもローカルなパーテ ィションであるかのようにマウント (NFS マウント ) する ことができます。たとえば、ファイルサーバーの /home と /usr/local を NFS クライアントにマウントすると、 図 2 のようになります。 アプリケーション側からみると、 NFS マウントしたデ ィレクトリやファイルに対する読み書きなどは、ローカル なハードディスク上のディレクトリやファイルに封する 操作と同様に扱うことができます。 NFS クライアントで は、ファイルがローカルなファイルシステム上にあるの か、それとも NFS マウントされたディレクトリにあるの かがカーネルによって識別さ後者の場合は操作のリク 工ストが NFS サーバーに送られます。 このとき、異なるアプリケーションや NFS クライア ントが、 NFS サーバー上の同じファイルに対して同時に 38 書込みをおこなわないように、 NFS とは別のプロトコル でファイルのロック冓を提供しています。これにより、 ある NFS クライアントのアプリケーションがファイルを UNIX MAGAZINE 2002.1 いてそれはど彳釜質にならなくてもいいでしよう。 したがって、一イ殳的な利用では、ファイルのロックにつ に 1 つのファイルに書き込むことはめったにありません。 込んだり、ユーサーか複数の NFS クライアントから同時 のユーサ、一のホーム・ディレクトリにあるファイルに書き ルの書込みが頻繁におこなわれますが、あるユーサーが別 どないはすです。また、ホーム・ディレクトリではファイ が NFS サーバー上のファイルを書き換える必要はほとん などに置かれたプログラムについて、 NFS クライアント ただし、ファイル共有の目的を考えると、 /usr/local という奇妙な状態になっています。 するのに、 FreeBSD の NFS クライアントでは動かない の NFS クライアントとのあいだではロックが正しく機能 す。このため、 FreeBSD の NFS サー ーとはかの OS 構カ躾装されていますが、 NFS クライアントは未対応で とえば、 FreeBSD では NFS サーバー側にはこれらの機 と組み合わせるとうまく働かない場合もあるようです。た 対応がまちまちで、実装されていなかったり、異なる OS もっとも、ファイルのロックや監視オ冓は OS ごとに るといえます。 に動くだけでなく、さまざまな OS への実装も容易になってい NFS はステートレスでシンプルに言 t されたため、上は交的高速 シュしたときの再刑処理も複雑になります。 ための情報を処理する手間がかかるだけでなく、一方がクラッ グ欟冓を含む、より高機能なサービスを提供できますが、その ステートレスの反対は、ステートフル (stateful)" です。ロッ たかのように処理を再開します。 サーバーか復帰すると、 NFS クライアントはなにごともなかっ シュすると NFS クライアントの処理も停止しますが、 NFS まったくもっていません。たとえば、 NFS サーバーがクラッ あり、 NFS クライアントとの接続状態をイ寺するための情報は NFS 自体は、ステートレス (stateless)" なプロトコルで クライアントの状態を監視する機溝も提供されています。 情報がそのまま残るのを防ぐため、 NFS サーバーや NFS NFS クライアントがクラッシュした場合、一方のロック できなくなります。さらに、ロック中に NFS サーバーや ントは、ロックが解除されるまでそのファイルにアクセス ロックすると、はかのアプリケーションや NFS クライア

図 3 /etc/exports 列 /usr/local /usr/local /home —maproot=O : 0 —ro —network —network 192. 168. 1 . 0 —mask 255 .255.255.0 192. 168.1 . 0 —mask 255.255.255.0 myp c NFS サーバーの設定 ファイルのロックを別にすると、 NFS サーノヾーでおこ なわれる処理は、以下の 2 つに分かれます。 ・マウント要求の処理 UNIX MAGAZINE 2002.1 デモン、プログラムです。 共有されたファイルに対するロック機溝を寒見するため ・ rpc. lockd の起重丿時の引数で変史できます ) 。 います ( 多くの場合、同時に起重丿けるプロセス数は nfsd 起動され、複数の要求を並列に処理できるようになって れるのに対し、 nfsd は通常 4 ~ 6 個のプロセスか 1 司時に デーモン・プログラムです。 mountd が 1 つだけ起動さ NFS クライアントからのファイル操作要求を処理する ・ nfsd モン・プログラムです。 NFS クライアントからのマウント要求を処理するデー ・ m011 ⅲ d は、名前が異なることもあります ) 。 があります ( これは FreeBSD の場合です。はかの OS で て起動されるデーモン・プログラムには以下のようなもの デーモンがおこないます。これらも含め、 NFS サー ほとんどの OS では、これらの処理はそれぞれ独立した 移動などが含まれます。 操作と同様、読出し、書込み、ファイルの作成・削除・ す。ファイル操作には、ローカルなファイルに対する NFS クライアントからのファイル操作要求を処理しま ・ファイル操作要求の処理 マウントの可否を決定します。 し、あらかじめ設定されたアクセス制御リストに従って ーは NFS クライアントからのマウント要求を処理 レクトリをマウントしなければなりません。 NFS サー 有するためには、ます NFS サーノヾー上の特定のディ NFS クライアントが NFS サーバー上のファイルを共 ・ rpc. statd コンピュータの状態を監視するためのデーモン・プロ グラムで、 rpc. lockd や、ほかのコンピュータの rpc. statd と叫して重川します。 nfsd や rpc. lockd 、 rpc. statd は、起重圻は自動的に 処理をおこなってくれます。したがって、 NFS サーバー に対して管理者がおこなう設疋は mountd の動作、つま り NFS サーノヾーの、 ・どのディレクトリを ・どの NFS クライアントに対して ・どのようにマウントさせるか を決めることです。 /etc/exports 多くの UNIX では、これらの設定は /etc/exports というファイルに言当します 7 。基本的には、一ド記の情報 の組を 1 行すっ列挙します。 ・エクスポートするディレクトリ ・マウントを許可する NFS クライアント ・マウント広 ) オフション たとえは、 /usr/local と /home を工クスポートする 場合、 FreeBSD の /etc/exports ファイルは図 3 のよ うになります。 1 行目では、 NFS サーバーの /usr/local を、 mypc という NFS クライアントにェクスポートしています。 mypc からは読み書き可能であり、 mypc のスーパーユー サーは、共有したファイルを NFS サーバーのスーパー ューザーと同し権限で操作できます (-maproot オプシ ョン ) 。 2 行目は、ローカル・ネットワーク ( 192.168.1.0 ) 内 のすべての NFS クライアントに対して (-network オプ ション ) 、 /usr/local を言蒄呂し専用 (-ro オプション ) で 7 NFS サーバーが NFS クライアントに対してディレクトリを公開するこ とを、、、ェクスポートする " といいます。 39

特集ネットワークの基礎知識 3 /usr/local と /home を NFS クライアントがマウントす る場合には、 /etc/fstab に以下の 2 行を j 助日します。 fs :/usr/local /usr/local nfs ro 0 0 fs : /home /home nfs て 0 0 ( ホスト名は (s) の /usr/ 1 行目では、 NFS サー local を NFS クライアントの /usr/local に、 2 行目 では、 NFS サーバーの /home を NFS クライアントの /home にマウントしています。この例では、 /usr/local を読出し専用、 /home を読み書き可能でマウントするよ うに設定していますが、読み書きについては NFS サー バーでの設定が優先されます。したがって、 1 行目の第 4 フィールドで、、 rw " と指定しても、 NFS サーバーの /etc/exports に -ro と指定されていれば、読出し専用で マウントされることになります。 こまでに紹介した例では、 NFS サーバーがェクスポ ートするディレクトリと NFS クライアントのマウント ポイントは同じになっていますが、もちろん違っていて もかまいません。たとえは、 NFS サーバーが複数の OS の /usr/local を管理し、それぞれ /arch/freebsd や /arch/linux などのディレクトリに分けてオ褓内している 場合は、 /etc/fstab に記述する NFS サーバーのディレ クトリ ( 四 ) を OS の不鶤頁ごとに変えれはいいことにな ります。 オートマウンタ /etc/fstab に NFS マウントの設定を記述する方法は 簡単ですが、 NFS クライアントか起動しているあいだは、 つねに NFS サーバーのディレクトリをマウントしていま す。そのため、とくにハードマウントしている場合は、共 有されたファイルにアクセスしていなくても、 NFS サー バーのクラッシュによって NFS クライアントもハング アッフする可能生があります。 一方、 NFS クライアント側でオートマウンタと呼はれ るイ督目みを使うと、共有するファイルへのアクセスが発生 した時点で NFS マウントがおこなわれ、一定時間アク セスがなけれは自重加勺にアンマウントされます。このガ去 は、 /etc/fstab を用いたマウントにくらべて、 NFS サー ノヾーのクラッシュによる景グを抑えることができます。オ ートマウンタは NFS クライアント側て利用する技術であ り、 NFS サーバーでは特別な設定はイです。 42 おもなオートマウンタには、 Sun の automount や フリーウェアの amd 、 Linux の autofs などがありま す (FreeBSD では、 amd かオ票準的にサポートされてい ます ) 。設定去などはそれぞれ異なりますが、いすれも 基本的には以下のアイデアにもとづいて動作します。 ・ NFS クライアント上のマウントボイントはシンポリッ ク・リンクで、オートマウンタはこのシンポリック・リ ンクに対するアクセスを本鎹日して自動マウント / アンマ ウントをおこなう。 ・マウントボイントは特別なディレクトリの下に設けら ー一日のシンポリック・リンクは実際のアクセスポ イントを指している。 これだけでは分かりにくいかもしれないので、 amd を 用いたホーム・ディレクトリの管理について、図を見なが ら説明しましよう。 amd では、 NFS サーバーが工クスポートするディレ クトリは、 NFS クライアントの特定のディレクトリ以下 にマウントされます。 FreeBSD の場合、 /. arnd-mnt と いうディレクトリ以下にマウントされます。さきほど示 した図 2 のように、ホーム・ディレクトリが、、 /home/ ューザー名 " という形式になっていたとすると、 NFS ク ライアントの /home 以下を amd が管理します。この とき、 /home 以下のユーサー名のディレクトリ ( たとえ は hayao) はシンポリック・リンクであり、実際のマウ ントボイント (). amd-mnt/home/hayao) を指していま す。もちろん、アクセスがない状態では、 /. amd-mnt/ home/hayao には NFS サーバーのホーム・ディレクト リはマウントされていません。 こで、ユーサー hayao がログインするなどして、本 来のホーム・ディレクトリである /home/hayao にアクセ スしようとすると、これを amd かオ剱日し、 NFS サー の /home/hayao を NFS クライアントの /. amd-mnt/ home/hayao にマウントします。 NFS クライアントの /home/hayao は /. amd-mnt/home/hayao へのシンポ リック・リンクになっているので、 /home/hayao とい うパス名で自分のホーム・ディレクトリ上のファイルを利 用することができます。 この時点での NFS クライアントの状態は、図 4 のよう になっています。ューザー haya 。がログアウトするなど UNIX MAGAZINE 2002.1

ジョン 2 (NFSv2) から、以下の点について刻長あるいは 機能強化がおこなわれています。 ・ファイルサイズ NFSv2 では、ファイルを扱うときのオフセット値が 32bit であったため、クライアントがアクセスできるフ ァイルの大きさが約 4.2GB ( IGB = 109 バイトとした 場合 ) に制限されていました。これほど巨大なファイル を扱うことはないと思うかもしれませんが、ハードディ スクが大容量化している現在では、 OS やホーム・ディ レクトリにあるファイルをバックアップしようとして、 tar などでまとめるとこの制限に引っかかる可能性があ ります。 NFSv3 では、このオフセット値が 64bit に拡張され た 5 ので、すくなくと墅点ではファイルサイズに関 する制約は事実 - E ないといっていいでしよう。 ・転送サイズ NFSv2 には、 1 回の読出しまたは書込みの処理て転送 できるデータは最大で 8 , 192 バイトという制約があり ました。 IOMbps の Ethernet が主流だったころは、 これでもとくに間題はありませんでしたが、より高速な メディアが LAN の主充になり、大きなファイルを共 有するようになると、データを小分けにすることによる 効率の悪さカ甘商されるようになりました。 そこで、 NFSv3 ではこの制限を取り払い、クライアン トとファイルサーバーが交渉して最大転送サイズを決 め、より少ないリクエスト数でファイルを中幻医できるよ うにしています。ファイルサーバー側かサポートしてい れは、 1 つのファイルを 1 回の読出しリクエストて転 送することも可能です。 書込み性能 共有されたファイルをクライアント側で変更して保存す る場合、クライアントからファイルサーバーに対して書 込み要求がおこなわれます。このとき、 NFSv2 では、 ファイルサーバーはハードディスクにデータを確実に書 き込んでからクライアントに応答します。ファイルサー バーがクラッシュしてもデータが失われる危険性カ觝い という点はいいのですが、クライアントはファイルサー 5 興未のある人は、ファイルサイスの一ヒ限羽叱ヾイトになるかを引算してみ ーー - ーーーー ~ ー - ーーーーる - と - いいでしようにそれこそ、途方もない新直になります。 UNIX MAGAZINE 2002.1 バーからの応答を受け取るまで次の書込み要求がおこな えないため、ネットワークではなくファイルサーバーの 処理能力がポトルネックとなる可能性がありました。 これに対し、 NFSv3 では、書込みの石忍 (commit) 操 作を追加することにより、ファイルサー ーに対して 、、安全ではない ( unsafe ) " 書込みがおこなえるように変 更されています。安全ではない書込みとは、ファイル サーバーがハードディスクへのデータの保存を石薩忍せす に応答することを意味します。クライアントは、ある程 度まとまった数の書込み要求をおこなったあとで市忍操 作をすることで、従来よりも高速にデータの書込みがで きるようになりました。 NFSv3 の機能を利用するには、ファイルサーバーだけ でなくクライアントも対応している必要があります。 PC UNIX のなかでは、 FreeBSD や NetBSD など BSD 系 の UNIX は早くから対応していましたし 6 、 Linux でも、 最新の安定版であるカーネル 2.4. x 以降で対応していま す。 ただし、 NFSv3 のファイルサーバーやクライアント は、たいていは NFSv2 にも対応しているので、ファイ ルサイズや書込み性能などをシビアに考える必要がなけれ は、 2 不頁のバージョンが混在していてもかまいません。 また、ファイルサーバーやクライアントの設定という点で は、 NFS のバージョンによる違いはさほどありません。 以下では、 NFS の次に紹介する Samba との混乱を避 けるため、 NFS のファイルサーバーを NFS サーパー クライアントを NFS クライアントと呼ぶことにします。 N F S の仕組み UNIX では、物理的なハードディスクをいくっかの部 分 ( パーティション ) に分割し、パーティションごとに ファイルシステムを構成します。各ファイルシステムで はツリー状にディレクトリか配置さあるパーティショ ンのルート・ディレクトリを別パーティションのディレク トリにマウントすることにより、全体として 1 つの大きな ツリーを形成します。たとえば、 / ( ルート ) パーティショ /home 、 /usr 、 /var を異なるパーティショ ンのはかに ンに割り当てた場合、その本友は図 1 のようになります。 6 たとえば、 FreeBSD は 1997 年に発表されたバージョン 2.2.2 から、 NFSv3 カ鰾第勺にサポートされています。 37

UNIX Communication Notes 山口英 局性能サーバーを目指して ( 3 ) 図 1 トランサクションの構成 十分な処理速度が得られるサーバー このシリーズでは、インターネットにサービスを提供 する高性能なサーバーを構成する技術について解説してい る。 1 回目 ( 2001 年 11 月号 ) で述べたように、高性能 サーバーカえるべき要件は以下の 3 点に集約できる。 クライアント 処理要求 サーバー 処理結果の返送 占郞章に強い。 ・十分な処珊度か得られる。 手間がかからない。 今回は、、、十分な処理速度が得られる " サー する技術をとりあげる。 里とは何か ーを構成 技術そのものの説明に入る前に、サーバーにおける処理 速度について考えてみよう。 インターネットにおける大部分のサーピスは、クライ アント・サーバーモテフレにもとづいておこなわれている。 つまり、サー ーはクライアントからの処理要求を受け 付け、なんらかの処理を施し、結果をクライアントに送 り返す。一般に、クライアントとサーバーとのあいだの やりとりは、、トランザクション (transaction)" と呼はれ る。 WWW システムを例にとると、クライアントからの HTTP GET リクエストの送信と、サーバーから応答と して返されるデータの送受信によって 1 つのトランサク ションカ材冓成される。 トランザクション処理は、大雑把にいえは図 1 のように おこなわれる。ます、クライアントにおいて日該れ 1 にトラ ンサクションが始まる。これが、サーバーには日該れ 2 に届 一一一一一一一一一一一一一いたと - ーしようこの図では、処理要求は 1 バケットになっ UNIX MAGAZINE 2002.1 ているが、複数のバケットから構成される場合もある ) 。 の場合、 t2 ー tl はバケットの伝送遅延を表す。サーバー は処理要求を受け取り、処理をおこなって時刻なに返送 する。すなわち、 t3 ー t2 がサーノヾーでのトランザクション 処王寺間である。そして、日該れ 3 から t4 までのあいだに、 処理結果か数のバケットとしてクライアントに送り返さ れる。トランサクション全体の処理には、 t4 ー tl の時間 がかかっていることになる。 1 つのトランザクション処理は、以下の要素から友さ れる。 1. 処理要求の伝送 2. サーバーでの処理 3. 処理結果の伝送 1 番目と 3 番目は伝送遅延であり、ネットワークの性 能に左右される部分である。 2 番目はサーバーの処理生能 そのものを表す。高性能サーバーを構築するには、この 2 つ、すなわちネットワークでの遅延とサーバー本体での処 理日判りをま可宿する必要がある。 55

特集ネットワークの基礎知識 0 あっけないはど簡単です。そのため、 /usr や /usr/local 以下のファイルをすべての PC がローカルにもっていて も、以前とくらべて管理にほとんど手間がかからなくなっ ています。 現在、充になっているファイル共有は、コストの低 減よりもユーザーの便宜を重視したものといえます。コス トという点だけからみると、各 PC のディスクにホーム・ ディレクトリを置いてもとくに問題はないでしよう。しか し、 PC ごとにホーム・ディレクトリの内容が異なると、 ューサーは違う PC を利用するたびに必要なファイルを コピーしなけれはならす、本来の仕事に専念できません。 ューザーがどの PC でも同し環境で作業できるのであれ ば、ファイルに対するアクセス速度を多少牲にしても、 データ共有には大きなメリットがあるといえます。 とはいえ、プログラムの共有もまったくなくなったわ けではありません。たとえは、数百台のクライアント PC から構成される環境では、新たなアプリケーションをす べての PC にインストールしようとすると、相当な時間 と労力がかかります。さすがに、このくらいの規模にな ると 1 台のファイルサーバーだけでは面倒をみきれない ので、クライアントをいくっかのグループ ( クラスタ ) に 分け、グループごとにファイルサーバーの複製 ( クラスタ サーバー ) を置いてプログラムを共有するといった方法が 採られます。 けっきよくのところ、ファイルサーバーを使って何を 共有するかは、ハードウェアのコストやクライアントの台 数など、環竟ごとに異なります。ファイルサーバーを導入 するうえでのポイントを以下に挙げておきます。自分の環 境と照らし合わせて考えるといいでしよう。 ・ネットワークの規模 今回紹介する NFS や Samba は、上交的高速かっ信 頼性の高い LAN での利用が前提となっています。 れらの技術はインターネット上でも使えないことはあり ませんが、 LAN と上交してバケットの遅延ゃ損失 ( パ ケットロス ) が大きくなるので、寺点ではあまり現実 的ではありません。また、インターネット上て利用する 場合にはセキュリテイも間題になります。暗号技術を用 いて角夬しようとすると、実質的なアクセス速度はさら に低下します。 36 インターネット上でファイル共有を実現するための技 術としては、 Microsoft や Netscape などが中心とな って開発を進めている WebDAV (Web-based Dis- tributed Authoring and Versioning) などがありま す。 WebDAV は HTTP を拡張することにより、イ ンターネットを介したファイルの遠隔操作を実現しよ うというものです。特定のプラットホームに依存せす、 SSL などと組み合わせたセキュリティの確保か容易な 点など、将来的に有望な技術だと思います。現時点で は、 Microsoft の IIS をはしめとする実装がいくつか ありますが、今回はとりあげません。興味のある人は、 WebDAV の RFC [ 1 ] や、 WebDAV Resources の ページ [ 2 ] などをご覧ください。 ・クライアントの台数 クライアントの台数が多いはど、プログラムの共有によ って管理の手間は軽減されます。しかし、さきほども述 べたように、台数があまりにも多い場合には、クラスタ サーバーの導入を検討したはうがいいでしよう。 ・クライアントの不頁 データの共有は別にして、プログラムの共有による効果 は、クライアントの不頁か充一されているかどうかによ って大きく異なります。極論をいえば、すべてのクライ アントが異なる OS て構成されている場合には、同しア プリケーションであっても OS ごとに異なる実行ファ イルやライプラリを用意しなけれはなりません。このよ うな環境では、各クライアントごとにプログラムをイン ストールするのと手間はほとんど変わりません。 NFS NFS は、 1980 年代衫月に Sun Microsystems によっ て開発されたファイル共有技術です。 Sun のワークステー ションだけでなく、ほかの OS で用いられるファイルシ ステムにも積梛均に対応した結果、早くから LAN におけ るオ剽純勺なファイル共有技術として普及しました。 現在、ひろく使われているのは IBM や HP などと共 同で開発されたバージョン 3 (NFSv3) で、 RFC1813 [ 3 ] として公開されています 4 。それまでの充であったバー 4 まだ一難勺に利用されていませんが、セキュリティの強化やクライアン トでのキャッシュ : 臠虍などを盛り込んだバージョン 4 が RFC3010 [ 4 ] として公開されています。 UNIX MAGAZINE 2002.1

表 1 NFS のおもなオプション 旧形式 意味 最初のマウントに失敗すると、バックグラウンドてマウントを試み続ける。これを指定しなかったり、旧形式 で、 fg " を指定した場合は、そのままフォアグラウンドで実行される NFS サーバーからの応答がない場合、キーポードからの割込み (Ctrl-C など ) によってマウントの実行を中 止できる ソフトマウント。あらかしめ決まった回数マウントに失敗すると、エラーを返してマウントをあきらめる。 れを指定しなかったり、旧形式で、 hard" を指定した場合にはハードマウントになり、マウントに成功するま て繰り返される ーれ NFS クライアントが 1 回のリクエストで読み込むデータサイズをれでオ日疋。最小値は 1024 で、 2 のべき乗 rslze¯ になるように指定する必要がある -r と同様、書込み時のデータサイズを指定する。 NFS サーバーと NFS クライアントの OS が異なる場合、 -r や -w の値を変えると、うまく読み書きができるようになることもある 第 2 フィールド (mountpoint) NFS クライアントのどのディレクトリにマウントする かを指定します。 ・第 3 フィールド (nfs) ファイルシステムの不鶤頁を指定するフィールドで、 NFS の場合はつねに、、 nfs" を指定します。 第 4 フィーノレド ( 0 0 れ s マウント時のオプションを指定します ( 複数ある場合は カンマで区切って並べます ) 。 FreeBSD では、すくな くとも、、 rw" ( 読み書き可能 ) または、、 r 。 " ( 読出し専 用 ) のいすれかのオプションを指定する必要がありま す。 NFS 関連のオプションは、これ以外にもたくさん あります。おもなオプションとその意味を表 1 に示し ます。詳細は、 OS に付属するオンライン・マニュア ル 9 などを参照してください。 山も匠の FreeBSD は、従来にくらべて NFS 里のオプ ションの書き方が大きく変わっています。そこで、ほ かの OS でよく使われる旧い形式の書き方も併記して おきます。 ・第 5 およひ第 6 フィールド ( 0 0 ) それぞれ、ファイルシステムのバックアップをおこな う順番、 OS の起重加こファイルシステムのチェックを おこなう順番に対応します。通常、これらのフィール ドはローカルなハードディスクのパーティションに対 してだけ意味をもつので、 NFS の場合は両方とも 0 を 指定します。 たとえば、さきほどの図 3 のように工クスポートされた 9 OS によって異なりますが、 FreeBSD では mount-nfs ( 8 ) 、 Linux では nfs ( 5 ) にオプションに関する説明があります。 bg soft —r れ —W れ WSIze==n NFS クライアントの設定 NFS サーバーがェクスポートしたディレクトリを NFS クライアントがマウントするには、 2 つの方法があります。 1 つは、 NFS クライアントか起動してからシャットダ ウンするまで、 NFS サーバーのディレクトリをマウント し続けるガ去です。もう 1 つは、アクセスの有無に応して マウントおよびアンマウント ( マウントされているディレ クトリをファイルシステムから切り離すこと ) を自重加勺に おこなうガ去です。 /etc/fstab ローカルなパーティションと同しく、 NFS サーバーの ディレクトリをマウント / アンマウントするには、それぞ れ mount および umount コマンドを用います。もち ろん、これらを必要に応してコマンドラインで実行しても かまいません。しかし、マウントしたい (NFS サー の ) ディレクトリに関する情報を /etc/fstab ファイル に言当主しておけは・、 OS の起重丿時に自重加勺にマウントされ ます。 NFS クライアントから NFS サーバーのディレクトリ をマウントするには、以下の行を /etc/fstab に加えます。 se ロ肥 7 、 : 2 佖 t ん・ rno 社れゆ 0 をれ nfs 0 〃 0 れ s 0 0 1 つの行は 6 つのフィールドからなり、それぞれの意 味は次のとおりです。 第 1 フィールド ( se 理挈観の NFS サーバーのホスト名 ( “ e のと、 NFS クライ アントがマウントする NFS サーバー上のディレクトリ ( コロン ) で区切って指定します。 四 ) ーの組を、 41 UNIX MAGAZINE 2002.1

図 5 分割した言諚ファイルを読み込む部分 # generiC if [ -f ~/. Env/generic ] ; then source ~ / . Env/generic f i if [ —f ~ / . Env/bash—a1iases ] ; source ~ / . Env/bash—aIiases f i # os specific if [ -f ~/. Env/arch. $OSTYPE ] ; 特有の設定を言当します。 f i source ~ / . Env/host . $SHOST if [ -f ~ / . Env/host . $SHOST ] ; SHOST= ( echo $HOSTNAME ー awk -F # hOSt specific f i source ~ / . Env/arch. $OSTYPE then then ' {print then これらのファイルは、 ~ /. bashrc から図 5 のようにし て読み込みます。 通常、工竟変数 HOSTNAME の値は FQDN (FullY Qualified Domain Name) 、つまり、ホスト名にドメ イン名を加えた文字列が設定されるので、そのまま使う とファイル名が長くなってしまいます。これを避ける ために、新たな変数 ( この例では SHOST) を定義し、 awk コマンドでホスト名の部分だけを切り出しています (HOSTNAME にホスト名しか設定されていない場合 は、 SHOST には HOSTNAME の値がそのまま代入さ れます ) 。また、いすれのファイルについても、その有無 を調べてから読み込んでいるため、ファイルがなけれは無 視されるだけです。 NFS 利用上の注意点 NFS はネットワークを利用したファイル共有技術であ り、 NFS クライアントは NFS サーバーに依存するため、 運用時に注意しなければならない点がいくっかあります。 いすれも、 NFS の管理・運用経験のある人には当り前の UNIX MAGAZINE 2002.1 ルで NFS のサポートを有効にする必要があります。 FreeBSD や Linux などで NFS を使うには、カーネ ・カーネルの設正 話ですが、最後にこれらをまとめておきます。 これらの OS でも、たいていは OS をインストールした ときのカーネル ( いわゆる GENERIC カーネル ) で、 NFS のサポートか有効になっているはすです。しかし、 カーネルをカスタマイズしたときに NFS のサポートを 無効にしてしまうと、いくら設定ファイルが正しくても NFS は使えません。 故正ファイルには間題がないのに NFS がうまく動かな い場合は、カーネルの設定をチェックしてみるといいで しよう。カーネルの NFS サポートが無効になっていた ら、これを有効にしてカーネルを明冓築し、現在のカー ネルと入れ替えてみましよう。 ・ユーサー ID とグループ ID UNIX では、ユーザー ID とグループ ID にもとづいて ファイルに対する操作の可否か決定されます。したがっ て、 NFS サーバーと NFS クライアントでは、ユーサー ID とグループ ID を統一的に管理する必要があります。 コンピュータごとにこれらの ID がバラバラだと、ある NFS クライアントでは自分のホーム・ディレクトリの ファイルか読み書きできるのに、別の NFS クライアン トではまったくアクセスできなくなったり、他人のファ イルか読み書きできるといったトラブルに陥る可能生か あります。 NIS (Network lnformation service) を使うと、ア カウント情報を NIS サーバーて集中管理することがで きます。今回は NIS については説明しないので、文献 [ 7 ] などを参照してください。 ・シャットダウンの順番 NFS クライアントは NFS サーバーに依存するので、 ネットワーク内のコンピュータをすべてシャットダウ ンするときは、その順番に注意する必要があります。 そのような場合は、かならす最後に NFS サーバーを シャットダウンします。何も考えすに NFS サーバーを シャットダウンすると、とくにハードマウントしている ときは、 NFS クライアントがウンともスンともいわな くなるので、 NFS サーバーを再起動しなけれはならな くなります。 描丘はあまりみかけなくなりましたが、複数の NFS サ ーバーがそれぞれのディレクトリを柤圧にマウントして いることもあります。このような状態をクロスマウント といいますが、この場合はもっと厄介で、単純に片方 45

ファイルの共有といっても、、、何を " 共有するかはそれ ぞれ - の↓竟や目的によって異なります。 コンピュータ上のファイルは、大雑把にいってシステ ムファイルとユーサーファイルの 2 不鶤頁に分けられます。 UNIX 系の OS でいえは、システムファイルとは起重加芋に 必要なファイル 1 や、すべてのユーザーカリ用するアプリ ケーションのためのファイルです。これらは、おもにルー ト ( / ) もしくは / usr パーティションなどに各内されてい ます。さらに、これらのファイルは、 OS のインストール 時に作成されるものと、あとで追加インストールされるも のに分けられることもあります。多くの UNIX では、追 加インストールされるファイルは /usr/local 以下に置か れるのが間列となっています 2 。 一方、ユーザーファイルは、各ューザーのホーム・デ ィレクトリ (/home など ) 以下に置かれるファイルです。 ューサーが作成したドキュメントなどのデータファイル、 シェルや各種アプリケーションを利用するための設定ファ イルなどか含まれます。 ハードディスクは、現在でこそ大容量の製品が安価に入 手できますが、 10 年ほど前にはきわめて高価な貴重品で した。当時は、すべてのコンヒュータに寸分な容量のハー ドディスクを装備するのが予算的に難しかったので、ディ スク資源をファイルサーバーに集中させ、クライアントは ファイルサーバーカ甘是供するシステムファイルやホーム・ ディレクトリを利用するのが一麺勺な形態でした。 現在ではほとんどみられませんが、データレス・ワーク ステーションやディスクレス・ワークステーションと呼 ばれるコンピュータが使われていたのもこのころです。前 者は、 OS の起動に必要なファイル十をハードディスク ( ゴ内し、その他のファイルはすべてファイルサーバーに 頼ります。後者はハードディスクをまったくもたす、 OS の起動に必要なファイルも、ファイルサーバーからファ イル中幻などによって提供されるものを使います。このこ 1 カーネルや当加 ) 言置ファイル、基恥均なコマンドやライプラリなどが 含まれます。 2 パッケージ管理システムか普及している Linux では、追加するアプリ ケーションが /usr/bin や /usr/lib などに置かれるようになってい ァイル共有スタイルの変遷 UNIX MAGAZINE 2002.1 ろもホーム・ディレクトリの共有はおこなわれていました が、どちらかというとクライアントの /usr や /usr/local など、システムの運用に必要なプログラムを共有し、コス トを抑えることに力点が置かれていたように思います 3 しかし、ファイル共有はいいことずくめではありませ ん。ファイルサーバーか物章などの理由によって停止して しまうと、それに依存するクライアントも止まってしまい ます。また、クライアントからのアクセスがファイルサー ーに集中するので、クライアントの台数か増加するにつ れて、ネットワークとファイルサーバーに負荷がかかるよ うになります。その結果、共有しているファイルの読み書 きが遅くなったり、はかのネットワーク・サービスに悪影 響をえる場合もあります。 ファイルに対する読み書きの速度という点では、ネット ワーク経由でファイルサーバーにアクセスするよりも、ロ ーカルに接続されたハードディスク上のファイルにアクセ スするはうがはるかに高速です。たとえば、理言直でいう と、 100Mbps の Ethernet であれば 12.5MB / 秒です が、 UItra ATA/IOO という規格のハードディスクでは PC とのあいだの転送速度は 100MB / 秒と、その差は 8 倍にもなります。もちろん、現実には理論値どおりの匪能 は出ません。しかし、ネットワークはファイル共有以外の 用途てイ吏われることもあり、ある程度以上の規模のオフィ スならクライアントの台数は数台 ~ 数十台になるので、そ の差はもっと大きくなるでしよう。 このようなデメリットがあることに加え、現在では数十 GB のハードディスクが 1 万円前後で購入できるので、フ ァイル共有のスタイルも、、プログラムの共有 " から、ホー ム・ディレクトリの共有を中心とした、、データの共有 " に 変わってきているようです。 事実、私のいるオフィスでも、 Sun のワークステーショ ンが中心だった日罸にには、ファイルサーバーはクライアン トの /usr/local とホーム・ディレクトリの共有に使われ ていました。しかし、主力が PC に移行してからは、ファ イルサーバーで共有するのはユーサーのホーム・ディレク トリだけになっています。 Linux や FreeBSD などのいわ ゆる PC UNIX では、一難勺なアプリケーションの多く がバイナリ・パッケージとして提供さインストールも 3 もちろん、ファイル共有にはコスト面だけでなく、管理の手間を減らすと いうメリットもあります。 35