7    ネットワーク・サービスの管理

TruCluster Server 『クラスタ・インストレーション・ガイド』では,ネットワーク・サービスの初期構成の方法について説明しています。ネットワーク・サービスの構成はクラスタの作成前に行うよう強くお勧めします。クラスタの作成後にこの構成を行うと,構成の手順が複雑になることがあります。

この章では,クラスタ作成後のネットワーク・サービスの構成手順について取り上げ,次の項目について説明します。

7.1    DHCP の構成

クラスタは高可用性の DHCP (Dynamic Host Configuration Protocol) サーバとして構成できますが,DHCP クライアントとしては構成できません。クラスタは静的なアドレス指定を使用する必要があります。クラスタ内では DHCP は,フェイルオーバ機能を提供する CAA (Cluster Application Availability) サブシステムと連携して,シングル・インスタンス・アプリケーションとして動作します。DHCP サーバとして動作できるのは常にクラスタの 1 つのメンバのみです。フェイルオーバが行われた場合,新規 DHCP サーバは,前のサーバが使用していたのと同じ共通データベースを使用します。

DHCP サーバは,自身のホスト名および IP アドレスと DHCP データベース内のエントリとを一致させようとします。クラスタ・メンバのホスト名と IP アドレスを使ってデータベースを構成している場合は,問題が発生する可能性があります。メンバがダウンした場合,DHCP サーバは別のメンバに自動的にフェイルオーバされます。しかし,この新規 DHCP サーバのホスト名と IP アドレスは,DHCP データベース内のエントリと一致しません。この問題とその他の関連する問題を回避するには,次の手順を実行します。

  1. Tru64 UNIX 『ネットワーク管理ガイド:接続編』 の DHCP に関する章を参照し,この章で説明されている DHCP サーバの構成手順について把握します。

  2. 初期 DHCP サーバとして実行するクラスタ・メンバ上で,/usr/bin/X11/xjoin を実行し,DHCP を構成します。

  3. [Server/Security] を選択します。

  4. 現在表示されている [Server/Security Parameters] のプルダウン・メニューから,[IP Ranges] を選択します。

  5. [DHCP Server] エントリに,省略時のクラスタ別名の IP アドレスを設定します。

    DHCP データベースには,DHCP サーバの IP アドレスが複数存在する場合があります。作業を簡単にするために,jdbdump コマンドを使って,DHCP データベースの内容をテキスト・ファイルに出力します。次に,テキスト・エディタを使って,このファイル内の元の DHCP サーバ の IP アドレスをクラスタ別名の IP アドレス に変更します。最後に,jdbmod を使って,編集したファイルを DHCP データベースに読み込みます。たとえば,テキスト・ファイルへの出力とこのファイルの編集を行うには,次のコマンドを入力します。

    # jdbdump > dhcp_db.txt
    # vi dhcp_db.txt
     
    

    dhcp_db.txt ファイルを編集して,元の DHCP サーバ の IP アドレスを省略時のクラスタ別名の IP アドレスに変更します。

    データベースを更新し,変更を反映させるには,次のコマンドを入力します。

    # jdbmod -e dhcp_db.txt
     
    

  6. xjoin を使って DHCP を終了したら,DHCP を高可用性アプリケーションにします。DHCP には処理スクリプトとリソース・プロファイルが既に用意されており,DHCP は CAA デーモンに既に登録されています。CAA サブシステムを使って DHCP を起動するには,次のコマンドを入力します。

    # caa_start dhcp
     
    

  7. /etc/join/server.pcy を編集して,次の行を追加します。

    canonical_name  cluster_alias
     
    

    cluster_alias は省略時のクラスタ別名です。

  8. DHCP を停止して再起動します。

    # caa_stop dhcp
    # caa_start dhcp
     
    

高可用性アプリケーションと CAA サブシステムについては,TruCluster Server 『クラスタ高可用性アプリケーション・ガイド』を参照してください。

7.2    NIS の構成

NIS (ネットワーク情報サービス) デーモン ypxfrd および rpc.yppasswdd は,クラスタのあらゆるメンバ上で動作し,メンバの可用性を高めます。

3.1 節で説明されているように,クラスタ別名を通してアクセスするサービスのポートは,in_single または in_multi のいずれかで定義します (この定義は,サービスを複数のクラスタ・メンバで同時に実行できるかどうかとは無関係です)。

ypxfrdin_multi サービスで動作します。つまり,クラスタ別名サブシステムは,このサービスに宛てられた接続要求とパケットを,その別名に対して資格のあるメンバ全員に送ります。

rpc.yppasswddin_single サービスで動作します。つまり,このサービスに宛てられた接続要求とパケットは,1 つの別名メンバだけが受信します。そのメンバが使用できなくなると,クラスタ別名サブシステムは同じ別名内の他のメンバを選択し,このサービスに宛てられたすべての要求とパケットをそのメンバに受信させます。

NIS パラメータは /etc/rc.config.common ファイルに保存されています。NIS データベース・ファイルは /var/yp/src ディレクトリにあります。これらのファイルはクラスタのすべてのメンバによって共用されます。クラスタは,スレーブ,マスタ,またはクライアントです。クラスタ内で,スレーブ,マスタ,およびクライアントの機能を備えたメンバは混在できません。

クラスタの作成時に NIS を構成した場合,NIS の構成に限り,クラスタに対するメンバの追加または削除時に何も行う必要はありません。

クラスタの稼働後に NIS を構成するには,次の手順を実行します。

  1. nissetup コマンドを実行し,Tru64 UNIX 『ネットワーク管理ガイド:サービス編』 の NIS に関する章の指示に従って,NIS を構成します。

    NIS がバインドするホスト名として,クラスタ別名をホスト名のリストに追加しなければなりません。

  2. クラスタの各メンバ上で,次のコマンドを実行します。

    # /sbin/init.d/nis stop
    # /sbin/init.d/nis start
     
    

7.2.1    クラスタ内の NIS マスタへのエンハンスト・セキュリティ機能の追加

拡張ユーザ・プロファイルとパスワードによって NIS データベースを保護するように,NIS マスタを構成できます。NIS とエンハンスト・セキュリティ機能については,Tru64 UNIX 『セキュリティ管理ガイド』を参照してください。NIS マスタへのエンハンスト・セキュリティ機能の追加についての詳細は,同じマニュアルのクラスタ用のエンハンスト・セキュリティ機能に関する付録を参照してください。

7.3    印刷の構成

多少の例外はありますが,クラスタ内でのプリンタの構成はスタンドアロン Tru64 UNIX システム上でのプリンタの構成と同じです。プリンタ・システムの管理についての概説は,Tru64 UNIX 『システム管理ガイド』を参照してください。

クラスタでは,メンバはクラスタ内のどの場所にあるプリンタにもプリント・ジョブを送信できます。プリンタ・デーモン (lpd) はクラスタの各メンバ上で動作します。親デーモンである lpd は,ローカルの lpr の要求にも,リモートからのプリント・ジョブの要求にも応答します。

各ノードで動作する親プリンタ・デーモンは /var/spool/lpd を使用します。このパスは,/cluster/members/{memb}/spool/lpd へコンテキスト依存シンボリック・リンク (CDSL) でつながっています。他の目的では /var/spool/lpd を使用しないでください。

クラスタの各ローカル・プリンタにはそれぞれ専用のスプーリング・ディレクトリがあります。そのディレクトリは通常,/usr/spool の下にあります。スプーリング・ディレクトリは CDSL であってはなりません。

プリンタ特性 (:on) がクラスタ内での印刷をサポートするために新規に追加されました。プリンタを構成するには,クラスタの任意のメンバ上で printconfig または lprsetup を実行します。

プリンタが COM ポート (/dev/tty01) またはパラレル・ポート (/dev/lp0) 経由でメンバに接続されているローカル・プリンタである場合,:on にプリンタ接続先のメンバの名前を設定します。たとえば,:on=memberA と設定します。

この例では,プリンタはメンバ memberA に接続されています。

プリンタが TCP/IP 経由でメンバに接続されるネットワーク・プリンタである場合,:on 特性の値として次の 2 つの選択肢があります。

Advanced Printing Software の使用

クラスタでの Advanced Printing Software のインストールおよび使用については,Tru64 UNIX Advanced Printing Softwareシステム管理/操作ガイド』を参照してください。

7.4    DNS/BIND の構成

クラスタを BIND (Berkeley Internet Name Domain) サーバとして構成することは,スタンドアロン Tru64 UNIX システムを BIND サーバとして構成することに似ています。クラスタの場合は,クラスタ内の 1 つのメンバ上で named デーモンが動作します。Tru64 UNIX システムの場合は,そのシステム自体が実際の BIND サーバになります。クラスタでは,クラスタ別名サブシステムが名前の照会に応答するので,クラスタ全体が BIND サーバのように見えます。フェイルオーバ機能は CAA サブシステムによって提供されます。named デーモンが動作しているメンバが使用できなくなった場合,CAA サブシステムは別のメンバ上でこのデーモンを起動します。

bindconfig コマンドでは,クラスタをクライアントとするかサーバとするかのどちらか一方を指定します。クラスタはクライアントとサーバの両方として動作できるので,この選択はいくぶん誤解を招く恐れがあります。特に,クラスタを BIND サーバとして構成する場合,/etc/resolv.conf にネームサーバを指定していないときは,自動的にそのサーバの BIND クライアントとして構成されます。

クラスタが BIND サーバとして構成され,/etc/resolv.conf にネームサーバの指定が無い場合,bindconfig がクラスタ別名を最初のネームサーバとして /etc/resolv.conf に自動的に追加します。これは,初期インストール中にシステムを BIND サーバとして構成する場合に行われます。だたし,クラスタを最初に BIND クライアントになるようにセットアップした後,BIND サーバにするように bindconfig を実行すると,/etc/resolv.conf にはすでに少なくとも 1 つネームサーバが指定されているものと想定します。この場合には,bindconfig は自動的にクラスタ別名を最初のネームサーバとして追加しません。これを変更するには bindconfig を使用します。

BIND 環境変数はクラスタ単位の /etc/rc.config.common に格納されているので,すべてのクラスタ・メンバはブート時に同一に構成されます。同様に,/etc/resolv.conf はクラスタ単位のファイルなので,すべてのクラスタ・メンバは同じネームサーバを使用します。

BIND の構成手順は,クラスタの作成時でもクラスタの稼働後でも同じです。

クラスタを BIND クライアントとして,または BIND サーバとして構成するには,コマンド bindconfig または sysman dns を使用します。

どのメンバでコマンドを実行しても問題ありません。BIND サーバを構成する場合,CAA はネームサーバ named が実行するメンバを決めます。クライアントかサーバかに特定のメンバを構成しているのではなく,むしろクラスタ全体をクライアントかサーバかに構成しているので,sysman -focus オプションは,BIND を構成するには適切ではありません。つまり,BIND サーバ構成を行うメンバ上では,named ネームサーバは実行する必要はありません。CAA は named を任意のメンバ上で起動します。

/etc/resolv.conf および /etc/svc.conf ファイルはクラスタ単位のファイルです。

BIND の構成についての詳細は,Tru64 UNIX 『ネットワーク管理ガイド:サービス編』 の DNS (ドメイン・ネーム・サービス) に関する章を参照してください。

7.5    時刻同期の管理

クラスタのすべてのメンバは時刻の同期を必要とし,そのためには NTP (Network Time Protocol) が必要です。この理由から,クラスタの作成時に clu_create コマンドを実行すると,初期メンバ上で NTP が構成されます。その後,クラスタに新規メンバが追加されるたびに,新規メンバ上で NTP が自動的に構成されます。つまり,クラスタのメンバはすべて NTP ピアとして構成されます。

自サイトで NTP を使用しない場合は,使用するタイム・サービスが『RFC 1035 Network Time Protocol (Version 3) Specification, Implementation and Analysis』で定義された細分性の要件を満たしているかどうかを確認してください。

クラスタのメンバ間でわずか数秒でもシステム時間の誤差があってはならないので,timed デーモンによる時刻の同期化はお勧めしません。

7.5.1    NTP 構成

クラスタ・インストレーション・ガイド』では,クラスタ・ソフトウェアをインストールして初期クラスタ・メンバのシステムを生成する前に,Tru64 UNIX システム上で NTP を構成することをお勧めしています。このようにしなければ,clu_createclu_add_member が各クラスタ・メンバごとに自動的に NTP を構成してしまいます。この構成では,各メンバの NTP サーバが localhost になります。メンバはそれぞれが NTP ピアとして設定され,クラスタのインターコネクト・インタフェースの IP アドレスが使用されます。

localhost エントリは,そのメンバが稼働中のノードだけで使用されます。ピア・エントリは全クラスタ・メンバの同期をとるために動作するので,クラスタ内の時間誤差はマイクロ秒です。NTP 構成を後で変更して外部サーバを追加したとしても,初期サーバとピア・エントリは変更しないでください。

クラスタの稼働後に NTP 構成を変更するには,クラスタの各メンバ上で ntpconfig または sysman ntp を実行しなければなりません。これらのコマンドは常にクラスタの 1 つのメンバ上で動作します。NTP の構成対象のメンバを指定するには次の 2 とおりの方法があります。つまり,メンバにログインすれば,そのメンバが構成対象になります。あるいは,sysman-focus オプションを使って,構成対象のメンバを指定します。NTP デーモン (xntpd) の起動と停止は,クラスタ全体に対して行うと,クラスタ全体が稼働不能になる可能性があるので,一度に 1 つのメンバに対して行う必要があります。

sysman を使用すれば,クラスタ全体または 1 つのメンバを対象に NTP デーモンの状態がわかります。

7.5.2    すべてのメンバでの同一外部 NTP サーバの使用

外部 NTP サーバをクラスタの 1 メンバだけに追加できます。ただし,単一点障害となりえます。これを回避するには,外部サーバの同じセットを全クラスタ・メンバに追加する必要があります。

外部 NTP サーバのリストを全メンバで同じにすることを強くお勧めします。メンバごとに外部サーバ・リストを異なるもので構成する場合は,サーバがすべて同じ階層レベルであり,これらの時間差を小さくする必要があります。

7.5.2.1    時間のずれ

クラスタ・メンバ間の時間のずれに気が付いた場合は,メンバ相互に同期をとりなおす必要があります。この作業を行うには,クラスタの各メンバにログインして,ntp -s -f コマンドを入力し,ログインしたメンバ以外のメンバのクラスタ・インターコネクト名を指定する必要があります。省略時には,クラスタ・インターコネクト名は,-ics0 が付加された簡略ホスト名です。たとえば,provolone がクラスタ・メンバで,provolone 以外のメンバにログインしている場合は,次のコマンドを入力します。

# ntp -s -f provolone-ics0
 

次に,他のクラスタ・メンバにログインして,このコマンドを繰り返しますが,どのメンバにおいても,ログインしているシステム以外のクラスタ・インターコネクト名を使用します。

7.6    NFS の管理

クラスタは高可用性のネットワーク・ファイル・システム (NFS) サービスを提供できます。クラスタが NFS サーバとして動作するとき,クラスタの外部クライアント・システムからは,クラスタはクラスタ別名で参照される単一システムとして見えます。クラスタが NFS クライアントとして動作している場合に,クラスタの外部 NFS ファイル・システムがクラスタの 1 つのメンバによってマウントされると,そのファイル・システムにはクラスタのすべてのメンバがアクセスできます。クラスタの外部 NFS サーバへのファイルのアクセスは,マウント元のこのメンバ経由で行われます。外部 NFS サーバからは,クラスタは独立したノードの集合として見え,クラスタのメンバ間でファイル・システムが共有されていることは意識されません。

7.6.1    NFS の構成

NFS を構成するには,nfsconfig または sysman nfs コマンドを使用します。

注意

クラスタ内で nfssetup コマンドを使用しないでください。このコマンドはクラスタ対応ではないので,NFS が正しく構成されません。

クラスタの 1 つ以上のメンバで,NFS デーモンと mount デーモンの実行が可能であり,同時にクライアント・デーモン lockd および statd の実行も可能です。

nfsconfig または sysman nfs によって,クラスタ全体または特定のメンバに対して,次のことを行うことができます。

特定のメンバの NFS を構成するには,sysman-focus オプションを使用します。

フォーカスを指定しないで NFS を構成すると,その構成はクラスタ全体に適用され,/etc/rc.config.common に保存されます。フォーカスを指定して NFS を構成すると,その構成はフォーカスを指定されたクラスタ・メンバのみに適用され,そのメンバの CDSL ファイル /etc/rc.config に保存されます。

ローカルの NFS 構成はクラスタ全体の NFS 構成を上書きします。たとえば,メンバ mutt を NFS サーバにならないように構成した場合,クラスタ全体を NFS サーバとして構成しても,その構成は mutt に適用されません。つまり,mutt は引き続き NFS サーバにはなりません。

ここで,もっと興味深い例を挙げます。たとえば,alphabetagamma という 3 つのメンバから構成されるクラスタがあるとします。まず,8 つの TCP サーバ・スレッドをクラスタ全体に対して構成します。次に,メンバ alpha にフォーカスを指定し,10 個の TCP サーバ・スレッドを構成します。この条件で,各メンバ上で ps コマンドを実行してみます。その結果,次のことがわかります。つまり,メンバ alpha 上には 10 個の TCP サーバ・スレッドがあります。しかし,メンバ beta および gamma 上には 8 つの TCP サーバ・スレッドしかありません。今度は,クラスタ全体にフォーカスを指定し,TCP サーバ・スレッドの構成を 8 つから 12 個に変更します。この条件で,各メンバ上で ps コマンドを実行してみます。この場合,メンバ alpha 上には前と同じ 10 個の TCP サーバ・スレッドがあります。しかし,メンバ beta および gamma には現在,それぞれ 12 個の TCP サーバ・スレッドがあります。

クラスタのメンバで nfsd を実行する場合は mountd も実行しなければなりません。逆に,mountd を実行する場合は nfsd を実行しなければなりません。nfsconfig または sysman nfs を使って NFS を構成するときは,この操作は自動的に行われます。

クラスタのメンバ上でロックが有効な場合は,デーモン rpc.lockd および rpc.statd がそのメンバ上で起動されます。ロックがクラスタ全体に対して構成された場合 (rpc.lockd -crpc.statd -c),デーモン lockd および statd はクラスタ単位で起動されます。この場合,これらのデーモンは高可用性で,CAA サブシステムによって管理されます。NFS サーバは自身のアドレスとして,省略時のクラスタ別名または /etc/exports.aliases で指定されている別名を使用します。

クラスタが NFS サーバとして動作するとき,クラスタの外部クライアント・システムからは,クラスタはクラスタ別名で参照される単一システムとして見えます。外部クライアント・システムがクラスタ内のディレクトリの CDSL をマウントしても,このシステムが見えるのはクラスタ・メンバ上のパスだけです。ただし,このメンバでは statdlockd のペアがクラスタ単位で動作している必要があります。

NFS サービスの起動と停止は,特定のメンバに対してもクラスタ全体に対しても行うことができます。通常,クラスタ単位で動作する lockdstatd のペアの起動と停止は自動的に行われます。ただし,これらのデーモンを手動で停止する場合は,次のコマンドを入力します。

# caa_stop cluster_lockd
 

これらのデーモンを手動で起動する場合は,次のコマンドを入力します。

# caa_start cluster_lockd
 

サーバ・デーモン lockd および statd のペアを別のメンバに再配置するには,次のように caa_relocate コマンドを入力します。

# caa_relocate cluster_lockd
 

高可用性アプリケーションの起動および停止方法についての詳細は,第 8 章を参照してください。

7.6.2    クラスタ内での NFS の使用上の考慮事項

ここでは,クラスタ内とスタンドアロン・システム内で NFS を使用する際の違いについて説明します。

7.6.2.1    CFS での NFS ファイル・システムのサポート

CFS は NFS (ネットワーク・ファイル・システム) クライアントに読み取り/書き込みアクセスをサポートします。クラスタでファイル・システムを NFS マウントすると,CFS はすべてのクラスタ・メンバからの読み取り/書き込みアクセスを可能にします。実際にマウントしたメンバが,他のクラスタ・メンバに対するファイル・システムのサーバとなります。

NFS ファイル・システムをマウントしているメンバがシャットダウンされるか,障害が発生すると,ファイル・システムは自動的にアンマウントされ,CFS はマウント・ポイントをクリーンアップします。クリーンアップ処理の間,マウント・ポイントにアクセスするメンバはクリーンアップの進展状況により,次のような状態になります。

CFS のクリーンアップが完了するまでは,メンバは NFS ファイル・システムのローカル・マウント・ポイントで (または,マウント・ポイントの下にローカルに作られたディレクトリ内で) 新しいファイルを作成することができます。

AutoFS か Automount を使用していなければ,NFS ファイル・システムは自動的に別のクラスタ・メンバにフェイルオーバしません。別のクラスタ・メンバから,手動で同じマウント・ポイントか別のマウント・ポイントに再マウントして,再度使用可能にする必要があります。もう 1 つの方法としては,クラスタ・メンバをブートして,/etc/fstab ファイルに登録されていて,クラスタで現在マウントされておらず,サービスされいないファイル・システムを再マウントします。

7.6.2.2    クライアントはクラスタ別名を使用しなければならない

クラスタが NFS サーバとして動作している場合,外部クライアントは,クラスタからファイル・システムをマウントするとき,省略時のクラスタ別名か,または /etc/exports.aliases で指定されている別名を使ってホストを指定しなければなりません。外部クライアントがクラスタからファイル・システムをマウントしようとしたが,省略時のクラスタ別名または /etc/exports.aliases で指定されている別名を使用しなかった場合は,「connection refused」というエラー・メッセージがそのクライアントに返されます。

mountd 経由で動作するその他のコマンド (たとえば umountexport) が外部クライアントから発行されたが,省略時のクラスタ別名も /etc/exports.aliases で指定されている別名も使用されなかった場合,「Program unavailable」というエラー・メッセージがそのクライアントに返されます。

NFS サーバとして使用する別名を追加する場合は,その前に,『クラスタ概要』にある,NFS およびクラスタ別名と NFS,TCP,および UDP (User Datagram Protocol) トラフィックがどのように相互作用するか説明した節を参照してください。また, exports.aliases(4)/etc/exports.aliases ファイルの冒頭にあるコメントも参照してください。

7.6.2.3    CDSL を使って NFS ファイル・システムをマウントする

クラスタが NFS クライアントとして動作している場合,1 つのクラスタ・メンバがマウントした NFS ファイル・システムは,すべてのクラスタ・メンバからアクセスできます。クラスタ・ファイル・システム (CFS) では,外部の NFS サーバにあるファイルへアクセスする場合,そのファイル・システムをマウントしたメンバを経由します。つまり,マウントを実行したクラスタ・メンバが,NFS ファイル・システムの CFS サーバになり,外部 NFS と通信するノードになります。その結果,CFS では,クラスタ・メンバ全体でキャッシュ内容が同一に保たれ,全メンバから NFS ファイル・システムが常に同じように見えます。

ただし,マウント・メンバが使用できなくなると,フェイルオーバは起こりません。他のクラスタ・メンバが NFS ファイル・システムをマウントするまで,NFS ファイル・システムへアクセスできません。

ファイル・システムが使用できなくなった場合の対応方法には何通りかあります。その中でも,AutoFS を使用して NFS ファイル・システムを自動的にフェイルオーバする方法が最も確実です。この方法を使えば,可用性を損なうことなくクラスタ・メンバの間でキャッシュの整合性を保つことができます。AutoFS をクラスタ環境で使用する方法は,7.6.3 項に記載されています。

AutoFS とは別の方法として,mkcdsl -a コマンドを用いてマウント・ポイントを CDSL に変換する方法があります。この変換する方法では,すべてのメンバのメンバ固有領域に,既存のディレクトリがコピーされます。そうしておいて,CDSL を NFS ファイル・システムのマウント・ポイントとして使用します。この方法では,ファイル・システムに対する NFS サーバが 1 つだけですが,各クラスタ・メンバがそれぞれ NFS クライアントになります。クライアント・メンバは,NFS ファイル・システムの CFS サーバとして機能する 1 つのクラスタ・メンバに依存しているわけではありません。1 つのクラスタ・メンバが使用できなくなっても,他のクラスタ・メンバが行う NFS ファイル・システムへのアクセスは影響を受けません。ただし,CFS はクラスタ・メンバ間でキャッシュの整合性を保証できません。クラスタ・メンバは NFS の通常の方法を使用したキャッシュの整合性に依存することになります。当然ですが,シングル・システムの場合とは異なります。

NFS のレベルで提供されるファイル・システムの整合性を受け容れられる環境では,次の手順を実行して,CDSL をマウント・ポイントとして使用します。

  1. マウント・ポイントがない場合は作成します。

    # mkdir /mountpoint
    

  2. mkcdsl -a コマンドを使用して,ディレクトリを CDSL に変換します。これにより,全メンバのメンバ固有領域に,既存のディレクトリがコピーされます。

    # mkcdsl -a /mountpoint
    

  3. 同じ NFS サーバを使用して,各クラスタ・メンバに NFS ファイル・システムをマウントします。

    # mount server:/filesystem  /mountpoint
    

マウント情報を /etc/fstab ファイルに追加し,各クラスタ・メンバでマウントが自動的に実行されるようにすることをお勧めします。

7.6.2.4    ループバック・マウントはサポートされていない

NFS ループバック・マウントはクラスタでは機能しません。クラスタからファイル・システムをクラスタ内のディレクトリに NFS マウントしようとすると,「Operation not supported」というエラー・メッセージが返されます。

7.6.2.5    NFS マウントしたパスに非 NFS ファイル・システムをマウントしてはならない

CFS では,NFS マウントしたパスに非 NFS ファイル・システムをマウントしてはなりません。この制限によって,NFS ファイル・システムをマウントしたクラスタ・メンバがダウンした場合でも,対応する物理ファイル・システムの可用性には問題は発生しません。

7.6.3    クラスタでの AutoFS の使用

NFS ファイル・システムを自動マウントにする場合には,AutoFS を使用します。 AutoFS は,CAA の自動マウント・サービスを使用して自動フェイルオーバを実現します。あるメンバが自動マウントされたファイル・システムの CFS サーバとして動作し,AutoFS デーモン autofsd のアクティブ・コピーを起動します。このメンバに障害が発生すると,CAA は別のメンバ上で autofsd を開始します。

AutoFS の構成方法については,Tru64 UNIX 『ネットワーク管理ガイド:サービス編』 のリモート・ファイル・システムの自動マウントについての節を参照してください。AutoFS を構成した後は,次のようにしてデーモンを起動する必要があります。

# caa_start autofs

autofs リソースを自動的に起動させたい場合は,/usr/sbin/caa_profile -update コマンドを使用して,auto_start のプロファイル・オプションを 1 に設定します。

AutoFS を使用する場合は,次の事項を考慮してください。

TruCluster Server バージョン 5.1A,では,SCRIPT_TIMEOUT 属性の値が 3600 に増やされ,autofs がタイムアウトしにくくなりました。この値を増やすことはできますが,減らすことはお勧めできません。

TruCluster Server の以前のバージョンでは,インポートしているファイル・システムの数,データ・リンクの速度,インポートされたファイル・システムのサーバ間での配布方法に応じて,次のような CAA メッセージが表示される可能性があります。

# CAAD[564686]: RTD #0: Action Script \
/var/cluster/caa/script/autofs.scr(start) timed out! (timeout=180) 
 

この場合,autofs の CAA プロファイル内の属性 SCRIPT_TIMEOUT の値を 180 より大きい値に増やす必要があります。値を増やすには,/var/cluster/caa/profile/autofs.cap を編集するか,コマンド caa_profile -update autofs を使ってプロファイルを更新します。

たとえば,SCRIPT_TIMEOUT を 3600 秒に増やすには,次のようなコマンドを入力します。

# caa_profile -update autofs -o st=3600

CAA プロファイルとコマンド caa_profile の使用方法については, caa_profile(8) を参照してください。

7.6.3.1    ファイル・システムの強制アンマウント

クラスタ・メンバの AutoFS が停止したか使用できなくなった場合 (CAA autofs リソースが停止した場合など) でも,インターセプト・ポイントと AutoFS が自動マウントしたファイル・システムは使用できます。ただし,AutoFS が,使用中のファイル・システムのあるクラスタ・メンバ上で停止した後,別のメンバで開始されると,AutoFS インターセプト・ポイントが前のクラスタ・メンバをサーバとして認識したままになります。これは,AutoFS インターセプト・ポイントが,自分のところにマウントされているファイル・システムが使用中であると自分自身も使用中になり,前のクラスタ・メンバをサーバとして要求するからです。これらのインターセプト・ポイントでは新しい自動マウントを行うことはできません。

7.6.3.1.1    強制アンマウントが必要かどうかの判断

この問題は次の状況で発生します。

自動マウントしたファイル・システムへアクセスしたときに問題の発生することが明らかな場合は,自動マウントしたファイル・システムが期待したとおりに動作していることを確認します。 手順は,次のとおりです。

  1. caa_stat autofs コマンドを使用して,autofs リソースの動作している場所を CAA がどのように把握しているかを確認します。

  2. 次の ps コマンドを使用して,CAA の期待しているメンバで確かに autofsd デーモンが動作していることを確認します。

    # ps agx | grep autofsd
     
    

    動作してない場合は,動作させて問題が解決されるかどうかを確認します。

  3. アクセスできないファイル・システムに対応する,自動マウントのマップ・エントリを調べます。たとえば,エントリを対象に /etc/auto.x を検索して調べます。

  4. cfsmgr -e コマンドを使用して,マウント・ポイントが存在しかつ期待するメンバがサービスを行っているかどうかを調べます。

    サーバが CAA の期待どおりでなければ,問題があります。

CAA リソースを他のメンバに移動する場合は,mount -e コマンドを使用して AutoFS インターセプト・ポイントを識別するとともに,cfsmgr -e コマンドを使用して,すべてのマウント・ポイントのサーバを表示します。AutoFS を停止したメンバ上で,すべての AutoFS インターセプト・ポイントと自動マウントしたファイル・システムがアンマウントされていることを確認してください。

mount -e コマンドを使用する場合は,その出力を次のように検索して autofs の出現する行を探します。

# mount -e | grep autofs
/etc/auto.direct on /mnt/mytmp type autofs (rw, nogrpid, direct)
 

cfsmgr -e コマンドを使用する場合は,出力を検索して次のようなマップ・ファイル・エントリを探します。「Server Status 」フィールドには,ファイル・システムが実際にサービスされているかどうかは表示されません。「Server Name」フィールドで,AutoFS が停止されたメンバの名前を検索してください。

# cfsmgr -e
Domain or filesystem name = /etc/auto.direct
Mounted On = /mnt/mytmp
Server Name = provolone
Server Status : OK
 

7.6.3.1.2    問題の解決

問題になっている使用中のファイルがアクティブでなくなるまで待てる場合は,待ってください。そして,アクティブでなくなってから以前の AutoFS サーバ・ノードで autofsmount -U コマンドを実行して,そのファイル・システムをアンマウントします。このアプローチは時間がかかりますが,比較的安全な方法です。

問題になっている使用中のファイル・システムがアクティブでなくなるまで待てない場合は,以前の AutoFS サーバ・ノードで cfsmgr -K directory コマンドを使用して,AutoFS インターセプト・ポイントと,そのノードがサービスしている自動マウントされたファイルをすべて,使用中かどうかに関係なく強制的にアンマウントします。

注意

cfsmgr -K コマンドは AutoFS インターセプト・ポイントと,そのノードがサービスしている自動マウントされたファイル・システムをすべてアンマウントする最も強力な方法です。しかし,cfsmgr -K コマンドが常に成功するとは限りません。たとえば,NFS サーバがダウンするか NFS サーバと通信できなくなったために NFS が止まっていると,cfsmgr -K コマンドは動作しません。

cfsmgr -K コマンドを実行すると,アプリケーションは,自分がオープンしているファイルの中に影響を受けるファイル・システムにあるものがあると,そのファイルに対して I/O エラーを受信します。影響を受けるファイル・システムに現在の作業ディレクトリがあるアプリケーションは,そのファイル・システムのネームスペースで相対パス名を用いて位置を指定することができなくなります。

次の手順を実行して,autofs CAA リソースを再配置し,AutoFS インターセプト・ポイントと自動マウントしたファイル・システムを強制的にアンマウントします。

  1. 可能であればシステムを静止させて,ユーザとアプリケーションの混乱を最小限に抑えます。

  2. 次のコマンドを入力して,autofs CAA リソースを停止します。

    # caa_stop autofs
    

    CAA は,自動マウントしたファイル・システムにまだ使用中のものがあっても,autofs リソースを停止すべきであると解釈します。

  3. 次のコマンドを入力して,AutoFS インターセプト・ポイントと自動マウントしたファイル・システムがすべてアンマウントされたことを確認します。 出力で autofs の参照を検索します。

    # mount -e
    

  4. アンマウントされていないものがまだある場合は,次のコマンドを入力して AutoFS インターセプトと自動マウントされたファイル・システムを強制的にアンマウントします。

    #cfsmgr -K directory
    

  5. AutoFS インターセプト・ポイントまたは自動マウントされたファイル・システムがマウントされているディレクトリを指定します。インターセプトと自動マウントされたファイル・システム (同じノードでサービスされているもの) をすべて削除するために入力する必要があるマウント・ディレクトリは 1 つだけです。

  6. 次のコマンドを入力して autofs リソースを起動します。

    # caa_start autofs -c cluster_member_to_be_server
    

7.6.4    Automount から AutoFS への移行

この項では,Automount から AutoFS への移行にあたって,考えられる 3 つの場面について説明します。

7.6.4.1    クラスタ・メンバのリブートなしの移行

クラスタ・メンバのリブートなしの移行は,多くの手順が必要ですが,最高の可用性をもたらします。リブートによって,Automount のインターセプト・ポイントをクリーンアップし,AutoFS を自動的に起動することができないため,最も多くの手順が必要になります。

注意

ほとんどの Automount の環境では,1 つの automount インスタンスで,すべてのマップ・ファイルを処理します。ここで説明する手順では,この一般的なケースについて説明します。

各マップ・ファイルを複数の automount インスタンスで処理する複雑な Automount 環境の場合,/etc/rc.config.common ファイルをカスタマイズしたり,ps コマンドで戻された複数のプロセス識別子を強制終了する必要があったり,すべての NFS ファイル・システムに対して 1 つのメンバだけが自動マウント・サーバ・ノードでないなどの状況が発生します。

Automount 環境に適合する手順を考慮する場合,アクティブな Automount サーバ・プロセスを強制終了させるときに,Automount サービスのフェイルオーバが発生しないように,Automount の "standby" プロセスを強制終了してください。

クラスタ・メンバのリブートなしに Automount から AutoFS へ移行する手順は,次のとおりです。

  1. rc.config.common ファイルを変更します。

    1. autofsmount の引数を調べます。これらの引数は,通常,すでに AUTOMOUNT_ARGS 環境変数で指定された引数のサブセットです。この変数の値を表示するには,次の例で示すように rcmgr -get コマンドを使用します。

      # /usr/sbin/rcmgr -c get AUTOMOUNT_ARGS 
      -D MACH=alpha -D NET=f /- /etc/auto.direct
       
      

      -D オプションを使用して設定された環境変数は,automount のマップ・ファイル・エントリ定義内のプレースホルダを解決します。たとえば,マップ・ファイルに,次のような関連する NET エントリがあるとします。

      vsx ${NET}system:/share/hunch/usr/projects2/vsx
       
      

      このプレースホルダを解決すると,次のようになります。

      vsx fsystem:/share/hunch/usr/projects2/vsx
       
      

    2. 前の手順での決定に従って,autofsmount に渡す引数を設定します。これを行うには,次の例で示すように,rcmgr -set コマンドを使用します。

      # /usr/sbin/rcmgr -c set AUTOFSMOUNT_ARGS  -D MACH=alpha -D NET=f /- /etc/auto.direct
       
      

    3. autofsd デーモンに渡す引数を次の例で示すように設定します。

      # /usr/sbin/rcmgr -c set AUTOFSD_ARGS -D MACH=alpha -D NET=f
      

      これらの引数は,AUTOMOUNT_ARGS に設定されたのと同じように,-D オプションの環境変数と一致する必要があります。

    4. mount -e コマンドを使用して,automount によって使用されるファイル・システムを識別します。

      # mount -e | grep "(pid"
      deli.zk3.dec.com:(pid524825) on /net type nfs (v2, ro, nogrpid, udp, hard, intr, noac, timeo=350, retrans=5)
      

      自動マウントされるファイル・システムは,hostname:(pid) によって示されます。

    5. 次の例で示すように,どのクラスタが前の手順で識別された NFS ファイル・システムの Automount サーバ・ノードかを調べます。

      # cfsmgr -p /net
      Domain or filesystem name = /net
      Server Name = swiss
      Server Status: OK
      

    6. 前の手順で識別した Automount サーバを除くすべてのクラスタ・メンバでの Automount サービスを停止します。これを行うには,ps -ef コマンドを使用し,プロセス識別子を表示して,その出力から automount のインスタンスを探した後,kill -TERM コマンドを使用して各プロセスを強制終了します。TERM は省略時の値です。

      # ps -ef | grep automount
      root 1049132 1048577 0.0 May 10 ?? 0:00.00 /usr/sbin/automount -D MACH=alpha -D NET=f /- /etc/auto.direct
      

      # kill 1049132
      

      Tru64 UNIX バージョン 5.1A からは,kill コマンドがクラスタ単位で動作し,どのクラスタ・メンバからでもプロセスを強制終了できます。

    7. 次のように,rc.config.commonファイルで Automount を無効にし,AutoFS を有効にします。

      # /usr/sbin/rcmgr -c set AUTOMOUNT 0
      # /usr/sbin/rcmgr -c set AUTOFS 1
      

  2. すべての自動マウントされたファイル・システムが休止状態になるまで待ちます。

  3. サーバとして動作しているクラスタ・メンバでの Automount サービスを停止します。 これを行うには,ps -ef コマンドを使用し,プロセス識別子を表示して,その出力から automount のインスタンスを探した後,kill -TERM を使用して各プロセスを強制終了します。TERM は省略時の値です。automount デーモンに SIGTERM シグナル送ると,マウントされていたすべてのファイル・システムをアンマウントして終了します。

    # ps -ef | grep automount
    root  524825 524289  0.0   May 10 ??  0:00.01 /usr/sbin/automount -D MACH=alpha -D NET=f /- /etc/auto.direct
    

    # kill 524825
    

  4. mount -e コマンドを使用し,tmp_mnt の出力,または automount -M コマンドで指定されたディレクトリを検索し,自動マウントされたファイル・システムがマウントされていないことを確認します。

    # mount -e | grep tmp_mnt
    

    マウント・ポイントがまだ存在していても,もはや期待されるパス名で使用することはできません。ただし,/tmp_mnt/... というフル・パス名では使用することができます。AutoFS は /tmp_mnt マウント・ポイントを使用しないので,競合がなく,完全な自動マウントのネームスペースが AutoFS で使用可能になります。これらの tmp_mnt マウント・ポイントが後でアイドル状態になった場合は,umount コマンドの -f オプションを使用してアンマウントできます。このオプションは,サーバに通知することなしにリモート・ファイル・システムをアンマウントします。

  5. AutoFS を起動します。AutoFS は CAA を使用して自動マウント・サービスの自動フェイルオーバ機能を提供します。つまり,1 つのクラスタ・メンバが自動マウントされたファイル・システムの CFS サーバとして動作し,AutoFS デーモンの 1 つのアクティブ・コピーを実行します。このクラスタ・メンバに障害が発生すると,CAA は別のメンバ上で autofs リソースを起動します。

    AutoFS をどのノードで実行してもかわない場合は,クラスタ・メンバを指定しないで /usr/sbin/caa_start autofs コマンドを使用します。AutoFS を実行するクラスタ・メンバが必要であれば,/usr/sbin/caa_start autofs -cmember-name コマンドでそのメンバを指定します。

    # /usr/sbin/caa_start autofs
     
    

    -c オプションで指定したクラスタ・メンバが配置ポリシとリソースの依存性を満足している場合は,そのメンバ上で autofs リソースを起動します。クラスタ・メンバが配置ポリシとリソースの依存性を満足していない場合,caa_start コマンドは失敗します。指定されたメンバが使用可能でない場合には,そのコマンドは失敗します。

    リソース・ファイル・オプションについては, caa_profile(8) を参照してください。

  6. caa_stat autofs コマンドを使用して,autofs リソースを期待通りに起動したことを確認します。

    # /usr/bin/caa_stat autofs
    NAME=autofs
    TYPE=application
    TARGET=ONLINE
    STATE=ONLINE on swiss
    

7.6.4.2    クラスタ・メンバをリブートする移行

クラスタ・メンバをリブートする移行は,リブートなしの移行よりも,可用性は落ちますが実行手順が少なくなります。

注意

クラスタ・メンバをシャットダウンする前に,そのクラスタ・メンバが不可欠な投票メンバであるかどうかと,restricted ポリシで指定された 1 つ以上のアプリケーションの唯一のホスト・メンバであるかどうかを調べる必要があります。これらについては,5.5 節で説明しています。

ほとんどの Automount の環境では,1 つの automount インスタンスで,すべてのマップ・ファイルを処理します。ここで説明する手順では,この一般的なケースについて説明します。

各マップ・ファイルを複数の automount インスタンスで処理する複雑な Automount 環境の場合,/etc/rc.config.common ファイルをカスタマイズしたり,ps コマンドで戻された複数のプロセス識別子を強制終了する必要があったり,すべての NFS ファイル・システムに対して 1 つのメンバだけが自動マウント・サーバ・ノードでないなどの状況が発生します。

Automount 環境に適合する手順を考慮する場合,アクティブな Automount サーバ・プロセスを強制終了させるときに,Automount サービスのフェイルオーバが発生しないように,Automount の "standby" プロセスを強制終了してください。

クラスタ・メンバをリブートする,Automount から AutoFS への移行手順は,次のとおりです。

  1. rc.config.common ファイルを変更します。

    1. autofsmount コマンドに渡す引数を調べます。これらの引数は,通常,すでに AUTOMOUNT_ARGS 環境変数で指定されている引数のサブセットです。この変数の値を表示するには,次の例で示すように rcmgr -get コマンドを使用します。

      # /usr/sbin/rcmgr -c get AUTOMOUNT_ARGS
      -m -D MACH=alpha -D NET=f /- /etc/auto.direct
       
      

      -D オプションを使用して設定された環境変数は,automount のマップ・ファイル・エントリ定義内のプレースホルダを解決します。たとえば,マップ・ファイルに,次のような関連する NET エントリがあるとします。

      vsx ${NET}system:/share/hunch/usr/projects2/vsx
       
      

      このエントリは,次のように解決されます。

      vsx fsystem:/share/hunch/usr/projects2/vsx
       
      

    2. 前の手順での決定に従って,autofsmount に渡す引数を設定します。これを行うには,次の例で示すように,rcmgr -set コマンドを使用します。

      # /usr/sbin/rcmgr -c set AUTOFSMOUNT_ARGS -D MACH=alpha -D NET=f /- /etc/auto.direct
       
      

    3. 次の例で示すように,autofsd デーモンに渡す引数を設定します。

      # /usr/sbin/rcmgr -c set AUTOFSD_ARGS -D MACH=alpha -D NET=f
      

      これらの引数は,AUTOMOUNT_ARGS に設定されたのと同じように,-D オプションの環境変数と一致する必要があります。

    4. mount -e コマンドを使用して,automount で使用されるファイル・システムを識別します。

      # mount -e | grep "(pid"
      deli.zk3.dec.com:(pid524825) on /net type nfs (v2, ro, nogrpid, udp, hard, intr, noac, timeo=350, retrans=5)
      

      自動マウントされたファイル・システムは hostname:(pid) によって示されます。

    5. 次の例で示すように,どのクラスタが前の手順で識別された NFS ファイル・システムの Automount サーバ・ノードかを調べます。

      # cfsmgr -p /net
      Domain or filesystem name = /net
      Server Name = swiss
      Server Status: OK
      

    6. 前の手順で識別した Automount サーバを除くすべてのクラスタ・メンバでの Automount サービスを停止します。これを行うには,ps -ef コマンドを使用し,プロセス識別子を表示して,その出力から automount のインスタンスを探した後,kill -TERM コマンドを使用して各プロセスを強制終了します。TERM は省略時の値です。

      # ps -ef | grep automount
      root 1049132 1048577 0.0 May 10 ?? 0:00.00 /usr/sbin/automount -D MACH=alpha -D NET=f /- /etc/auto.direct
      

      # kill 1049132
      

      Tru64 UNIX バージョン 5.1A からは,kill コマンドがクラスタ単位で動作し,どのクラスタ・メンバからでもプロセスを強制終了できます。

    7. 次のように,rc.config.commonファイルで Automount を無効にし,AutoFS を有効にします。

      # /usr/sbin/rcmgr -c set AUTOMOUNT 0
      # /usr/sbin/rcmgr -c set AUTOFS 1
      

  2. (オプション) AutoFS サーバを指定します。AutoFS は,CAA を使用して自動マウント・サービスの自動フェイルオーバ機能を提供します。つまり,1 つのクラスタ・メンバが自動マウントされたファイル・システムの CFS サーバとして動作し,AutoFS デーモンの 1 つのアクティブ・コピーを実行します。このクラスタ・メンバに障害が発生すると,CAA は別のメンバ上で autofs リソースを起動します。

    CAA ホスト・ポリシおよび配置ポリシがある場合は,caa_profile autofs -print コマンドを使用して表示できます。ホスト・ポリシでは,アプリケーション・リソースのホスト・メンバを空白で区切った順序付きリストで指定します。配置ポリシでは,CAA がアプリケーション・リソースの起動または再起動を行うメンバを選択する際に従うポリシを指定します。自動起動ポリシは,リブートの前に停止していたか動作していたかにかかわらず,自動的にリソースを起動するかどうかを決定します。リブートの前に動作していたかどうかにかかわりなくリソースを起動させたい場合は,auto_start=1 に設定します。

    # /usr/sbin/caa_profile autofs -print
    NAME=autofs
    TYPE=application
    ACTION_SCRIPT=autofs.scr
    ACTIVE_PLACEMENT=0
    AUTO_START=0
    CHECK_INTERVAL=0
    DESCRIPTION=Autofs Services
    FAILOVER_DELAY=0
    FAILURE_INTERVAL=0
    FAILURE_THRESHOLD=0
    HOSTING_MEMBERS=
    OPTIONAL_RESOURCES=
    PLACEMENT=balanced
    REQUIRED_RESOURCES=
    RESTART_ATTEMPTS=3
    SCRIPT_TIMEOUT=3600
    

    省略時および推奨する設定は,balanced の配置ポリシを使って,どのクラスタ・メンバ上でも実行できる動作です。このポリシが適切でない環境では,/usr/bin/caa_profile -update コマンドを使用して,autofs リソース・プロファイルを変更します。

    リソース・ファイル・オプションについては, caa_profile(8) を参照してください。

    変更した場合,CAA の /usr/sbin/caa_register -u autofs コマンドを使用して,変更を有効にします。

  3. クラスタ・メンバをリブートします。クラスタ・メンバをシャットダウンする前に,そのクラスタ・メンバが不可欠な投票メンバでないことと,restricted 配置ポリシで指定された 1 つ以上のアプリケーションの唯一のホスト・メンバでないことを確認します。これらについては,5.5 節で説明しています。

    リブートすると,AutoFS が起動し,Automount はクラスタで実行されません。

    # /sbin/shutdown -r now
    

7.6.4.3    クラスタをリブートする移行

クラスタ全体をリブートする移行は,リブートなしの移行や単一メンバをリブートする移行より実行手順が少なくなりますが,クラスタの可用性は失われます。

クラスタのリブートは,思い切った方法であり,推奨する移行方法ではありません。

クラスタのリブート時に次の手順に従って,Automount から AutoFS へ移行します。

  1. rc.config.common ファイルを変更します。

    1. autofsmount に渡す引数を調べます。これらの引数は,通常,すでに AUTOMOUNT_ARGS 環境変数で指定されている引数のサブセットです。この変数の値を表示するには,次の例で示すように rcmgr -get コマンドを使用します。

      # /usr/sbin/rcmgr -c get AUTOMOUNT_ARGS
      -D MACH=alpha -D NET=f /- /etc/auto.direct
      

      -D オプションを使用して設定された環境変数は,automount のマップ・ファイル・エントリ定義内のプレースホルダを解決します。たとえば,マップ・ファイルに,次のような関連する NET エントリがあるとします。

      vsx ${NET}system:/share/hunch/usr/projects2/vsx
       
      

      このエントリは,次のように解決されます。

      vsx fsystem:/share/hunch/usr/projects2/vsx
       
      

    2. 前の手順での決定に従って,autofsmount に渡す引数を設定します。これを行うには,次の例で示すように,rcmgr -set コマンドを使用します。

      # /usr/sbin/rcmgr -c set AUTOFSMOUNT_ARGS -D MACH=alpha -D NET=f /- /etc/auto.direct
       
      

    3. 次の例で示すように,autofsd デーモンに渡す引数を設定します。

      # /usr/sbin/rcmgr -c set AUTOFSD_ARGS -D MACH=alpha -D NET=f
      

      これらの引数は,AUTOMOUNT_ARGS に設定されたのと同じように,-D オプションの環境変数と一致する必要があります。

    4. 次のように,rc.config.common ファイルで Automount を無効にし,AutoFS を有効にします。

      # /usr/sbin/rcmgr -c set AUTOMOUNT 0
      # /usr/sbin/rcmgr -c set AUTOFS 1
      

  2. (オプション) AutoFS サーバを指定します。AutoFS は,CAA を使用して自動マウント・サービスの自動フェイルオーバ機能を提供します。つまり,1 つのクラスタ・メンバが自動マウントされたファイル・システムの CFS サーバとして動作し,AutoFS デーモンの 1 つのアクティブ・コピーを実行します。このクラスタ・メンバに障害が発生すると,CAA は別のメンバ上で autofs リソースを起動します。

    CAA ホスト・ポリシおよび配置ポリシがある場合は,/usr/bin/caa_profile autofs -print コマンドを使用して表示できます。ホスト・ポリシでは,アプリケーション・リソースのホスト・メンバを空白で区切った順序付きリストで指定します。配置ポリシでは,CAA がアプリケーション・リソースの起動または再起動を行うメンバを選択する際に従うポリシを指定します。自動起動ポリシは,リブートの前に停止していたか動作していたかにかかわらず,自動的にリソースを起動するかどうかを決定します。リブートの前に動作していたかどうかにかかわりなくリソースを起動させたい場合は,auto_start=1 に設定します。

    # /usr/bin/caa_profile autofs -print
    NAME=autofs
    TYPE=application
    ACTION_SCRIPT=autofs.scr
    ACTIVE_PLACEMENT=0
    AUTO_START=0
    CHECK_INTERVAL=0
    DESCRIPTION=Autofs Services
    FAILOVER_DELAY=0
    FAILURE_INTERVAL=0
    FAILURE_THRESHOLD=0
    HOSTING_MEMBERS=
    OPTIONAL_RESOURCES=
    PLACEMENT=balanced
    REQUIRED_RESOURCES=
    RESTART_ATTEMPTS=3
    SCRIPT_TIMEOUT=3600
    

    省略時および推奨する設定は,balanced の配置ポリシを使って,どのクラスタ・メンバ上でも実行できる動作です。このポリシが適切でない環境では,/usr/sbin/caa_profile -update コマンドを使用して,autofs リソース・プロファイルを変更します。

    リソース・ファイル・オプションについては, caa_profile(8) を参照してください。

    変更した場合,CAA の /usr/sbin/caa_register -u autofs コマンドを使用して,変更を有効にします。

  3. クラスタをリブートします。リブートすると,Automount はクラスタ内で実行されておらず,AutoFS が起動しています。

    # /sbin/shutdown -c now
    

7.7    inetd の構成の管理

インターネット・サーバ・デーモン (inetd) の構成データは,次の 2 つのファイルに保存されています。

ローカル・メンバ上のクラスタ単位のサービスを無効にするには,そのメンバの /etc/inetd.conf.local 内で,無効にするサービスの ServerPath フィールドに disable を入力します。たとえば,inetd.conf 内でクラスタ全体に対する finger が有効になっている場合,1 つのメンバに対して finger を無効にするには,そのメンバの inetd.conf.local ファイルに次の行を追加します。

finger  stream  tcp     nowait  root   disable       fingerd
 

/etc/inetd.conf.local がメンバ上にないときは,/etc/inetd.conf 内のエントリが使用されます。inetd.conf.local がメンバ上にあるときは,そのファイル内のエントリが inetd.conf 内のエントリよりも優先されます。

7.8    メール・サービスの管理

TruCluster Server は次のメール・プロトコルをサポートしています。

SMTP はクラスタ単位でクラスタ別名を使用することができます。他のメール・プロトコルはクラスタ環境で実行できますが,各クラスタ・メンバがスタンドアロン・システムであるかのように動作します。

クラスタでは,すべてのメンバのメール・サービスの構成を同一にしなければなりません。DECnet,SMTP,またはその他の任意のプロトコルを 1 つのメンバ上で構成した場合は,そのプロトコルを他のすべてのメンバ上でも構成する必要があります。また,そのプロトコルの構成は各メンバ上で同一でなければなりません。クラスタは,メール・サーバまたはメール・クライアントにするか,スタンドアロン構成にできます。ただし,構成の適用対象は常にクラスタ全体です。たとえば,あるメンバをメール・クライアントとして構成し,別のメンバをメール・サーバとして構成することはできません。

サポートされているプロトコルのうち SMTP だけがクラスタ対応なので,クラスタ別名を使用できるのは SMTP のみです。SMTP は,クラスタ別名宛の電子メールを処理し,返信アドレスとしてクラスタ別名を送信メールに付けます。

sendmail が構成されると,そのインスタンスはクラスタの各メンバ上で動作します。すべてのメンバは,メール・キュー・ファイルを共用するので,処理待ちのメッセージを処理できます。また,各ユーザのメール・ボックスも共用するので,ローカルで配信されたメールを処理できます。

その他のメール・プロトコル (DECnet Phase IV,DECnet/OSI,MTS,UUCP,および X.25) もクラスタ環境で動作できます。しかしこれらのプロトコルからは,クラスタの各メンバがスタンドアロン・システムであるかのように見えます。これらのプロトコルの 1 つを使用する受信電子メールには,宛先アドレスとしてクラスタ別名ではなく,宛先のクラスタ・メンバのアドレスが書き込まれます。これらのプロトコルの 1 つを使用する送信電子メールには,返信アドレスとして送信元のクラスタ・メンバのアドレスが書き込まれます。

クラスタでの DECnet Phase IV,DECnet/OSI,MTS,UUCP,または X.25 の構成は,スタンドアロン・システムでの構成に似ています。この構成は,クラスタの各メンバ上で行わなければなりません。プロトコルに必要なハードウェアは,クラスタの各メンバにインストールされていなければなりません。

以降の各項で,メール・サービスの管理についてより詳しく説明します。

7.8.1    メール・サービスの構成

メール・サービスの構成には,mailsetup または mailconfig コマンドを使用します。各コマンドにはそれぞれ固有の構成形式があるので,どちらのコマンドを選択しても,クラスタ内で以降に行うメール・サービスの構成では,選択した同じコマンドを使用しなければなりません。

7.8.1.1    メール・ファイル

次のメール・ファイルはクラスタ全体で共用される共通ファイルです。

次のメール・ファイルはメンバ固有のファイルです。

/var/adm/sendmail 内で,ファイル名に hostname を含むファイルは,hostname の代わりに省略時のクラスタ別名を使用します。たとえば,クラスタ別名が accounting の場合は,/var/adm/sendmail には accounting.m4Makefile.cf.accounting という名前のファイルが格納されます。

メールの統計情報ファイル (/usr/adm/sendmail/sendmail.st) がメンバに固有なので,メールの統計情報はクラスタの各メンバに固有です。mailstat コマンドは,その実行元のメンバだけに関するメールの統計情報を返します。

SMTP 以外のメール・プロトコルを構成すると,メンバ固有の /var/adm/sendmail/protocols.map ファイルには,使用中のプロトコルに関するメンバ固有の情報が保存されます。protocols.map には,プロトコルのリストに加えて,DECnet Phase IV および DECnet/OSI で使用される別名のリストも保存されます (これらのプロトコルが構成されている場合のみ)。

7.8.1.2    Cw マクロ (システム・ニックネーム・リスト)

メール・サービスの構成に使用したのが mailsetup であっても mailconfig であっても,その構成プログラムは sendmail.cf ファイル内の Cw マクロ (ニックネーム・リスト) に,クラスタのすべてのメンバの名前とクラスタ別名を自動的に追加します。ニックネーム・リストにこれらの名前は必須です。メール・サービスの構成中に,ニックネーム・リストからクラスタ別名またはメンバ名を不用意に削除してしまっても,この構成プログラムによって,削除された名前は自動的に再追加されます。

メール・サービスの構成中にクラスタのニックネームを追加できます。ただし,mailsetup のクイック・セットアップを実行した場合は,ニックネーム・リストの更新は要求されません。クラスタのメンバの名前とクラスタ別名は Cw マクロに自動的に追加されます。

7.8.1.3    クラスタ作成時のメール・サービスの構成

clu_create コマンドの実行前に Tru64 UNIX システム上でメール・サービスの構成を行うことをお勧めします。SMTP のみを実行している場合は,クラスタに新規メンバを追加するたびに,そのメンバのメール・サービスを構成する必要はありません。clu_add_member コマンドによって,新規メンバのメール・サービスは自動的に正しく構成されます。

DECnet Phase IV,DECnet/OSI,MTS,UUCP,または X.25 を構成した場合は,クラスタに新規メンバを追加するたびに,mailsetup または mailconfig を実行し,新規メンバ上でプロトコルを構成しなければなりません。

7.8.1.4    クラスタ稼働後のメール・サービスの構成

すべてのメンバのメール・サービスの構成は同一にしなければなりません。SMTP のみを実行する場合は,この構成は一度行うだけで済みます。クラスタの任意のメンバから mailsetup または mailconfig を実行できます。

SMTP 以外のプロトコルを実行する場合は,各メンバ上で mailsetup または mailconfig を実行し,プロトコルを構成しなければなりません。各メンバには,プロトコルに必要なハードウェアをインストールしておく必要があります。プロトコルの構成は,クラスタの各メンバに対して行い,すべてのメンバ上で同一でなければなりません。

コマンド mailsetup および mailconfig では,クラスタの特定のメンバにフォーカスを指定できません。SMTP の場合,これらのコマンドはクラスタ全体を対象にメール・サービスを構成します。その他のメール・プロトコルの場合,これらのコマンドは実行元のメンバのみを対象にメール・プロトコルを構成します。

-focus オプションを付けて mailsetup を実行しようとすると,次のエラー・メッセージが表示されます。

Mail can only be configured for the entire cluster.

SMTP 以外のメール・プロトコルを実行している場合は,クラスタに新規メンバを追加するたびに,mailconfig または mailsetup を実行し,新規メンバ上でプロトコルを構成しなければなりません。SMTP のみを実行している場合は,新規メンバを追加するたびに,メール・サービスは自動的に構成されます。

クラスタからメンバを削除したときは,実行中のプロトコルにかかわらず,メール・サービスの再構成は必要ありません。

7.8.2    クラスタ・メンバ間でのメールの負荷分散

SMTP によって処理されるメールの負荷分散を行うには,クラスタ別名の選択優先順位 (selp) と選択重み (selw) を使って,クラスタのメンバ間でネットワーク接続の負荷分散を行います。選択優先順位と選択重みは,次のような仕組みになっています。

省略時の設定では,クラスタのすべてのメンバには,各メンバの /etc/clu_alias.config ファイル内で設定された値と同じ選択優先順位 (selp=1) と選択重み (selw=1) が割り当てられます (clu_create コマンドは省略時の選択重み 3 を使用しますが,別名を作成する場合は省略時の選択重みが 1 になります)。すべてのメンバが同じ選択優先順位と選択重みを共有するとき,接続要求はメンバ間で均等に分配されます。省略時のシステム構成では,各メンバが順番に 1 つの接続要求を受信します。

受信メール (およびその他すべての接続) を一部のクラスタ・メンバだけに処理させたい場合は,それらのクラスタ・メンバの選択優先順位を,その他のメンバの選択優先順位より高い値に統一します。

また,メールを処理させるクラスタ・メンバだけで新しいメール別名を作成することも,すべてのメンバを含むメール別名を作成し,選択優先順位を用いて,新しい接続要求を受信するメンバの順序を決定することもできます。

メンバの選択重みまたは選択優先順位を設定するには,そのメンバ上で cluamgr コマンドを実行します。メンバの selpselw に省略時の値が設定されている場合に,すべてのメール (およびその他のすべての接続要求) がクラスタの 1 つのメンバによって受信されるようにするには,そのメンバにログインして,selp に省略時の値より大きい値を設定します。たとえば,次のコマンドを入力します。

# cluamgr -a alias=DEFAULTALIAS,selp=50

8 メンバ構成のクラスタがあり,2 つのメンバ alpha および beta にすべての接続要求を受信させるとします。このとき,alphabeta との間の負荷分散を 40/60 にするとします。そのためには,まず alpha にログインして,次のコマンドを入力します。

# cluamgr -a alias=DEFAULTALIAS,selp=50,selw=2

その後,beta にログインして,次のコマンドを入力します。

# cluamgr -a alias=DEFAULTALIAS,selp=50,selw=3

その他のメンバの selp に省略時の値の 1 が設定されているとすると,betaalpha はすべての接続要求を受信します。まず beta が 3 つの接続要求を受信し,次に alpha が 2 つの接続要求を受信し,次に beta が 3 つの接続要求を受信する,という具合に続きます。

注意

selpselw をこのように設定すると,メールのトラフィックだけでなく,クラスタ別名を介するすべての接続に影響します。

接続要求の分配についての詳しい説明は,3.10 節および cluamgr(8) を参照してください。

7.9    RIS 用のクラスタの構成

クラスタ内に RIS (Remote Installation Services) サーバを作成するには,Tru64 UNIX 『Sharing Software on a Local Area Network』で説明した手順に加えて,次の手順を実行します。

/etc/bootptab については, bootptab(4) を参照してください。

注意

ネットワークの構成に応じて,RIS サーバにクラスタ別名を登録するときは,一意かつ任意のハードウェア・アドレスを指定する必要があります。

RIS クライアントとしてクラスタを使用するには,次のことを行う必要があります。

  1. RIS サーバに setld コマンドを使用して,クラスタ・メンバを登録します。これは,メンバ名とそのメンバのハードウェア・アドレスを登録することにより行います。

  2. 省略時のクラスタ別名を登録します。

    オペレーティング・システム・キットに対して登録する場合には,ハードウェア・アドレスの入力が必要となります。クラスタ別名には,ホスト名と対応した物理インタフェースがありません。代わりに,/etc/bootptab または /usr/var/adm/ris/clients/risdb にまだ存在しない物理アドレスならどれでも使用できます。

    クラスタでクラスタ別名仮想 MAC (vMAC) 機能を使用している場合は,RIS サーバに省略時のクラスタ別名のハードウェア・アドレスとして仮想ハードウェア・アドレスを登録します。クラスタでクラスタ別名仮想 MAC 機能を使用していない場合でも,3.12 節に記述されたアルゴリズムを使用して仮想アドレスを生成することができます。

    仮想 MAC アドレスは,接頭部 (省略時は AA:01) と,別名に対する 16 進数形式の IP アドレスで構成されます。たとえば,省略時のクラスタ別名が deli で,その IP アドレスが 16.140.112.209 である場合,クラスタの省略時の別名に対する vMAC アドレスは AA:01:10:8C:70:D1 で表されます。アドレスは次のような方法で決定されます。

            省略時の vMAC 接頭部:      AA:01
            クラスタ別名 IP アドレス:   16.140.112.209
            IP アドレス (16 進形式):   10.8C.70:D1
            このアドレスの vMAC:       AA:01:10:8C:70:D1
     
    

    そのため,省略時のクラスタ別名を RIS クライアントとして登録するとき,ホスト名は deli で,ハードウェア・アドレスは AA:01:10:8C:70:D1 となります。

省略時のクラスタ別名とそのメンバの両方を登録していない場合,setld コマンドは,次のようなメッセージのいずれかを返します。

# setld -l ris-server:
setld: Error contacting server ris-server: Permission denied.
setld: cannot initialize ris-server:
 

または

# setld -l ris-server:
setld: ris-server: not in server database
setld: cannot load control information
 

7.10    リモートへの X Window アプリケーションの表示

クラスタを構成すると,クラスタ外のシステムのユーザが,クラスタ上で X アプリケーションを実行し,クラスタ別名を使用してユーザのシステム上に X アプリケーションを表示できます。

次の例は,クラスタ・メンバから表示される X アプリケーションを単一システムのアプリケーションのように処理する手段として out_alias を使用する方法を示しています。

/etc/clua_services で,out_alias 属性が X サーバ・ポート (6000) 用に設定されます。クラスタ外のシステムのユーザは,クラスタ・メンバ上の X アプリケーションを実行し,表示はユーザのシステム上に行う必要があります。out_alias 属性はクラスタ内のポート 6000 に対して設定されるので,ユーザは,xhost コマンドの実行時に省略時のクラスタ別名を指定して,X クライアントがユーザのローカル・システムにアクセスできるようにする必要があります。たとえば,deli という名前のクラスタの場合,ユーザはローカル・システム上で次のコマンドを実行します。

# xhost +deli
 

このように out_alias を使用すれば,どのクラスタ・メンバの X アプリケーションでも,そのユーザのシステム上に表示されるようにすることができます。クラスタ管理者は,メンバ単位にユーザがアクセスできるようにしたい場合には,/etc/clua_servicesXserver の行をコメントにするか,その行から out_alias 属性を削除します (その後で,各クラスタ・メンバ上で cluamgr -f を実行して,変更を有効にします)。

クラスタ別名の詳細については,第 3 章を参照してください。