autofs がクライアント用のもっとも近い読み取り専用ファイルを選択する方法 (複数ロケーション)

このセクションでは、autofs がどのようにもっとも近い読み取り専用ファイルをクライアントに選択するかを説明するために、次の直接マップの例を使用します。

/usr/local          -ro \
   /bin                   ivy:/export/local/sun4\
   /share                 ivy:/export/local/share\
   /src                   ivy:/export/local/src
/usr/man            -ro   oak:/usr/man \
                          rose:/usr/man \
                          willow:/usr/man
/usr/games          -ro   peach:/usr/games
/usr/spool/news     -ro   pine:/usr/spool/news \
                          willow:/var/spool/news 

マウントポイント /usr/man および /usr/spool/news には 1 つ以上の場所 (最初のマウントポイントには 3 つの場所、2 番目のマウントポイントには 2 つの場所) がリストされています。複製された場所のどこからマウントしてもユーザーは同じサービスを受けられます。ユーザーの書き込みまたは変更が可能ならば、その変更をロケーション全体で管理しなければならなくなるので、この手順は、読み取り専用のファイルシステムをマウントするときにだけ意味があります。あるときに、あるサーバー上のファイルを変更し、そのすぐあとに別のサーバー上で「同じ」ファイルを変更するといった作業は避けたいものです。この利点は、最善の利用可能なサーバーがユーザーの作業なしで自動的に使用されることです。

ファイルシステムを複製として構成してあると (複製されたファイルシステムとはを参照)、クライアントはフェイルオーバー機能を使用できます。最適なサーバーが自動的に決定されるだけでなく、そのサーバーが使用できなくなるとクライアントは自動的に 2 番目に適したサーバーを使います。

複製として構成するのに適しているファイルシステムの例は、マニュアルページです。大規模なネットワークでは、複数のサーバーがマニュアルページをエクスポートできます。どのサーバーからマニュアルページをマウントするかは、サーバーが実行中でそのファイルシステムをエクスポートしているかぎり、重要ではありません。直接マップの例では、複数のマウント場所は、マップエントリ内のマウント場所のリストとして表現されています。

/usr/man -ro oak:/usr/man rose:/usr/man willow:/usr/man 

この例では、サーバー oak、rose、または willow からマニュアルページをマウントできます。どのサーバーが最適であるかは、次のいくつかの要素によって決まります。

• 特定の NFS プロトコルレベルをサポートするサーバーの数

• サーバーの近接性

• 重み付け

順位を決定するときには、各バージョンの NFS プロトコルをサポートしているサーバーの数が数えられます。サポートしているサーバーの数が多いプロトコルがデフォルトになります。これによって、クライアントにとっては利用できるサーバーの数が最大になります。

プロトコルが同じバージョンのサーバーの組の中で数がもっとも多いものがわかると、サーバーのリストが距離によってソートされます。近接性を判定するために、IPv4 アドレスが調査されてどのサーバーが各サブネットにあるかが判別されます。ローカルサブネット上のサーバーには、リモートサブネット上のサーバーよりも高い優先順位が付けられます。もっとも近いサーバーが優先されることにより、待ち時間とネットワークトラフィックが軽減されます。

Figure 2–5 に、サーバーとの距離を示します。

図 2-5  サーバー近接性

ローカルサブネット上に同じプロトコルをサポートしているサーバーが複数あるときは、それぞれのサーバーに接続する時間が計測され、速いものが使用されます。重み付けを使用することで選別が影響されることもあります。重み付けの詳細は、autofs と重み付け. を参照してください。

たとえば、ローカルサブネット上で NFS Version 4 サーバーの方が多い場合には、NFS Version 4 がデフォルトで使用されるプロトコルになります。ただし、ローカルサブネット上のサーバーが異なるプロトコルをサポートするときは、選別プロセスが複雑になります。次に、優先順位の決定の例をいくつか示します。

• ローカルサブネット上のサーバーには、リモートサブネット上のサーバーよりも高い優先順位が付けられます。ローカルサブネット上に NFS Version 3 サーバーがあり、もっとも近い NFS Version 4 サーバーがリモートサブネット上にある場合は、NFS Version 3 サーバーが優先されます。同様に、ローカルサブネットが NFS Version 2 サーバーで構成される場合は、それらが NFS Version 3 と NFS Version 4 サーバーで構成されるリモートサブネットより優先されます。

• ローカルサブネットが NFS Version 2、NFS Version 3、および NFS Version 4 サーバーで構成されていて、それぞれ数が異なる場合は、より複雑な選別が必要になります。オートマウンタは、ローカルサブネット上でもっとも高いバージョンを優先します。この場合、NFS Version 4 がもっとも高いバージョンです。ただし、ローカルサブネット上で NFS Version 4 サーバーよりも NFS Version 3 または NFS Version 2 サーバーが多い場合には、オートマウンタはローカルサブネット上のもっとも高いバージョンから 1 バージョン「競り下げ」ます。たとえば、ローカルサブネットが NFS Version 4 で 3 サーバー、NFS Version 3 で 3 サーバー、NFS Version 2 で 10 サーバーで構成される場合は、NFS Version 3 サーバーが選択されます。

• 同じように、ローカルサブネットが NFS Version 2 と NFS Version 3 サーバーで構成され、それぞれ数が異なる場合は、オートマウンタは最初にどのバージョンがローカルサブネット上でもっとも高いバージョンを示しているかを見つけます。次に、オートマウンタは各バージョンを実行するサーバーの数を数えます。ローカルサブネット上でもっとも高いバージョンが、同時にもっとも多いサーバーの場合、もっとも高いバージョンが選択されます。低いバージョンのサーバーの数が多い場合、オートマウンタはローカルサブネットのもっとも高いバージョンから 1 つ下のバージョンを選択します。たとえば、ローカルサブネット上で NFS Version 2 サーバーが NFS Version 3 サーバーよりも多い場合、NFS Version 2 サーバーが選択されます。

フェイルオーバー機能を指定していると、この優先順位はサーバーが選択されるマウント時に確認されます。複数の場所を指定しておくと、個々のサーバーが一時的にファイルシステムをエクスポートできないときに便利です。

多くのサブネットで構成される大きなネットワークでは、フェイルオーバーが特に便利です。autofs は適切なサーバーを選択して、ネットワークトラフィックをローカルネットワークのセグメントに限定することができます。サーバーが複数のネットワークインタフェースを持つ場合は、それぞれのインタフェースが別々のサーバーであるとみなして、各ネットワークインタフェースに対応付けられているホスト名を指定します。autofs はそのクライアントにいちばん近いインタフェースを選択します。

詳細は、automount(1M) のマニュアルページを参照してください。