レベル: 初級 Abhidnya Chirmule, System Software Engineer, IBM
Chinmay Soman, Associate Software Engineer, IBM
2009年 02月 11日 複数の NFS バージョンのエクスポートが同時に存在する場合、統一的なマウントを効率的に行うためには汎用の NFS マウント・ユーティリティーが必要です。汎用の NFS マウント・ユーティリティーを利用することで、複数の NFS バージョンを扱う際の煩雑さを軽減し、またそれらのバージョンの管理を単純化する方法を学びましょう。この記事では、汎用 NFS マウントの概念、このシステムの利点と応用に関する概要、そして全体的な設計の詳細について説明します。
NFS (Network File System) は広く使われている分散ファイルシステムです。NFS を利用すると、リモート・クライアントからサーバー上でファイル操作を行うことができます。サーバーは、エクスポート (export) 操作を行うことで、そのディレクトリーやファイルシステムをサーバーの外から利用できるようにします。クライアントがこれらのディレクトリーにアクセスするためには、エクスポートされたディレクトリーまたはファイルシステムを、そのクライアントのローカル・ディレクトリーの階層にマウント (mount) します。クライアントはマウントされたディレクトリーの中で、あたかもそのローカル・マシンに保存されているファイルにアクセスするかのようにリモート・ファイルにアクセスします。NFS には現在、ディレクトリーまたはファイルシステムのエクスポートとマウントを行うためのバージョンとして、バージョン 2、3、4 という 3 つのバージョンが用意されています。
この記事では、汎用の NFS マウントを使って既存のすべてのバージョンの NFS のエクスポートとマウントを統合し、1 つのシームレスなメカニズムにするための方法を説明します。1 つのシナリオとして、サーバーが NFS の 3 つのバージョンすべてを使ってディレクトリー・エントリーをエクスポートした場合を考えてみましょう。現状では、クライアントがこれらのエントリーのすべてにアクセスするためには、これらの各エントリーを別々に、異なるマウント・ポイントにマウントする必要があります。NFS バージョン 4 には擬似的なツリー・メカニズムが用意されており、NFSv4 でエクスポートされたすべてのエントリーを 1 つのマウント操作で処理することができますが、この機能はバージョン 4 で作成されたエントリーでしか利用することができません。クライアントはバージョン 2 と 3 のエントリーを別々に、バージョン 4 の単一マウント (擬似的なツリーが存在する場合) と合わせてマウントしなければなりません。
汎用の NFS マウント・ユーティリティーは、実質的には mount コマンドのラッパーです。このラッパーを利用すると、ある特定のサーバーからエクスポートされるすべてのエントリーを 1 つのコマンドを使ってマウントすることができます。NFS サーバーに対して変更が行われるのは望ましくないため、このラッパーは内部的に、ユーザーには見えない形でクライアント・マシンに対して個々の mount コマンドを実行します。
NFS サーバー上に図 1 のようなディレクトリーの階層がある場合を考えてみてください。
図 1. サーバー上のディレクトリーの階層
このシナリオでは、クライアント・マシン上で以下のマウント操作を実行する必要があります。
- 1 つの NFSv4 マウント: これによって NFSv4 の疑似的なツリー (Fileset1 と Fileset2) がマウントされます。NFSv4 の疑似ツリー機能を利用すると、NFSv4 クライアントは疑似ツリーの中にあるすべてのエクスポートされたエントリーに対して 1 つの
マウント操作を行うだけでよくなります。
- 2 つの NFSv3 マウント: これによって Tools と Docs がマウントされます。
- 1 つの NFSv3 マウント: これによって Binaries がマウントされます。
汎用の NFS マウント・ユーティリティーを使うと、これらのマウント操作を 1 つのマウント操作のみに減らすことができます。以下に示すのが、そのためのコマンドです。
gennfsmount <NFS server> <mountpoint>
|
汎用の NFS マウントを使うことによる利点は以下のとおりです。
- ユーザーは 1 つのマウント操作をするだけで、サーバーのすべての情報にアクセスすることができます。これは今までサポートされていなかった機能です。
- 一例として、古いインストールのファイルセットをバージョン 2 と 3 でエクスポートし、新しいファイルセットをバージョン 4 でエクスポートするサーバーを考えてみてください。クライアントは 1 つの操作を行うだけで、これらのファイルセットすべてにアクセスしてインストールすることができます。
- この汎用ユーティリティーを使うと、ある特定のサーバー上でのファイル検索機能や、特定のエクスポート・ディレクトリー/ファイルシステムでのファイル検索機能を強化することができます。
- このユーティリティーは、バージョンごとに自動的に分けて NFS のエクスポートを行うため、これらの異なるマウント・ポイントを管理するためのユーザーの手間を減らすことができます。
- NFS 管理者は古いバージョンの NFS エクスポートをサーバー上に保持することができます。1 つの
mount コマンドで、古いバージョンのデータと新しいバージョンのデータとを利用できるようになるからです。
同様の出力を automount ユーティリティーを使って得ることもできますが、automount の場合、必要な NFS マウントに対する automount マップ・ファイルを構成する必要があるため、管理の手間が増えます。automount の hostmap 機能を利用すると、管理上の構成をすることなく、サーバーからエクスポートされたすべてのエントリーをマウントできることになっていますが、hostmap を使って NFSv4 のエントリーをマウントする場合には問題があることがわかっています。それに加え、この操作は /etc/hosts ファイルに記載されているすべてのサーバーに対して実行されてしまいます。ある特定の 1 台のサーバーからエクスポートされたすべてのエントリーを 1 つのポイントにマウントできるというソリューションはありません。
全般的に、汎用の NFS マウント・メカニズムはユーザーにとって便利です。次に、汎用の NFS マウンターを実装する際の設計上の判断ポイントをいくつか調べてみましょう。
実装の詳細を設計する
汎用の NFS マウント・システムの基本的なアーキテクチャーを見てみましょう。汎用の NFS マウンターは内部的にサーバーに対して、エクスポートされたすべてのエントリーを要求するリクエストを送信します。
図 2. エクスポートされたすべてのエントリーを汎用の NFS マウントが要求する
サーバーからの応答を受信すると、リスト 1 のアルゴリズムによって処理が行われます。
リスト 1. 汎用の NFS マウントのアルゴリズム
Start
Create temporary directories for all versions.
Initialize list of mount security flavors.
Embed this list in each internal mount operation.
For each item in the export-list
Do
Mount internally for every NFSv2 and NFSv3 export
Update internal log
End for
Mount internally only once for NFSv4 export.
Update internal log
Stop
|
security flavors は、マウント・ポイントの下で read/write 操作の間に使われるセキュリティー・メソッド (sys、krb5、krb5i など) のカンマ区切りリストです。このリストは、サーバーがサポートするセキュリティー・メソッドと、このマウント・ポイントの下で後に行われるシステム・コールで使用されるセキュリティー・メソッドとを突き合わせるために使われます。同様のメカニズムは、エクスポートされたエントリーの NFS バージョンの突き合わせにも使用することができます。
すべての内部マウントが完了すると、これらの内部ディレクトリーを UnionFS を使って統合します (リスト 2)。
リスト 2. UnionFS を使って内部ディレクトリーを統合する
mount -t unionfs -o dirs=<temp_dir1>[:<temp_dir2>...] none <mount-point>
|
先ほどのシナリオを思い出してください。先ほどのシナリオでは、v4 疑似ツリーに対する 1 つの NFSv4 マウント、Tools と Docs に対する 2 つの NFSv3 マウント、Binaries に対する 1 つの NFSv3 マウントがクライアント・マシン上にあり、汎用の NFS マウント・ユーティリティー (gennfsmount <NFS server> <mountpoint>) を使ってそれらのマウントを 1 つのマウントに削減しました。さて、この場合には以下の一時ディレクトリーが作成されます。
- /tmp/NFSv4
- /tmp/NFSv3/Tools
- /tmp/NFSv3/Docs
- /tmp/NFSv2/Binaries
そしてこれらの一時ディレクトリーを unionfs を使ってマージします (リスト 3)。
 |
UnionFS
UnionFS は Linux® と FreeBSD 用のファイルシステム・サービスであり、他のファイルシステムを統一マウントすることができます。UnionFS を使うと個々のファイルシステムのファイルやディレクトリー (ブランチと呼ばれます) を透過的に重ねることができるため、それらのブランチを 1 つの統一的なファイルシステムにすることができます。同じパスを持つ複数のディレクトリーの内容は、統合されたファイルシステムの、マージされた 1 つのディレクトリーの中に表示されます。Linux 用の UnionFS には次の 2 つのバージョンがあります。
- バージョン 1.x はスタンドアロンのバージョンであり、モジュールとして構築されます。
- バージョン 2.x はバージョン 1.x よりも新しく、再設計と再実装が行われており、Andrew Morton による Linux の
-mm ツリーに含まれています (そのためメインのソース・ツリーに入るはずです)。
|
|
リスト 3. unionfs を使ってマージする
mount -t unionfs -o dirs=/tmp/NFSv4:/tmp/NFSv3:/tmp/NFSv2 none /mnt
|
するとディレクトリーの階層は次のようになります。
図 3. unionfs を使ってマージした後のディレクトリー階層
次に、このシステムの使い方を調べてみましょう。
システムを使用する
このシナリオでの NFS サーバーは、さまざまな NFS バージョンのさまざまなエントリーをエクスポートします。しかしクライアント・サイドでは汎用の NFS マウントという 1 つのマウントが行われるにすぎません。図 4 はサーバー上にあるエクスポートされたエントリーを示しています。
図 4. サーバー上にあるエクスポート
ここではサーバーが、NFS バージョンの異なる 5 つの NFS エントリーをエクスポートします。nfs4_A と nfs4_B は NFSv4 の疑似ツリーを構成します (/nfs4_A と /nfs4_A/nfs4_B)。それ以外はバージョン 2 と 3 の NFS エクスポートです。
図 5 はサーバー上に存在するファイルを示しています。
図 5. サーバー上に存在するファイル
現在のシナリオでは、クライアントが利用できるこれらのすべてのファイルは、個別のマウント操作によってマウントされた別々のディレクトリーの配下にあります。しかしここで提案するシステムを利用すると、1 回のマウント操作を行うだけで、ユーザーは 1 つの階層の中ですべてのファイルにアクセスできるようになります。
図 6 は汎用の NFS マウントを行った後にクライアントから見た場合のシナリオを示しています
図 6. 汎用 NFS マウントの出力
図 6 を見るとわかるように、複数の内部マウント操作が汎用の NFS マウンターによって実行されています。すべての NFS マウントは /mnt というディレクトリーにマージされています。
まとめ
ここでは汎用の NFS マウンターの背後にあるアーキテクチャーとメカニズムを説明しました。このユーティリティーによって 1 つのポイントから NFS サーバー上のファイルに容易にアクセスすることができ、また NFS 全体を 1 つに統合された形で見ることができるため、NFS クライアントにとっては非常に有効です。
参考文献 学ぶために
製品や技術を入手するために
- developerWorks から直接ダウンロードできる IBM ソフトウェアの試用版を利用して皆さんの次期 Linux 開発プロジェクトを構築してください。
議論するために
著者について | 
| | Abhidnya Chirmule はインドの Pune にある IBM Software Labs の Network File System Team の System Software Engineer として、AIX プラットフォームでの Open Network Computing 技術 ( RPC や NFS など) に取り組んでいます。彼女はインドの Pune にある College of Engineering でコンピューター工学の学位を取得しています。 |
| 
| | Chinmay Soman はインドの Pune にある IBM Systems and Technology Labs のソフトウェア・エンジニアです。現在は CTDB/Panache の研究活動に従事しています。彼は NFS チームで AIX での NFS の開発と管理に従事した経験があります。彼はコンピューター科学および工学の学位を取得しています。 |
記事の評価
| 
