TruCluster Server 『クラスタ・インストレーション・ガイド』では,ネットワーク・サービスの初期構成の方法について説明しています。ネットワーク・サービスの構成はクラスタの作成前に行うよう強くお勧めします。クラスタの作成後にこの構成を行うと,構成の手順が複雑になることがあります。
この章では,クラスタ作成後のネットワーク・サービスの構成手順について取り上げ,次の項目について説明します。
DHCP の構成 (7.1 節)
NIS の構成 (7.2 節)
印刷の構成 (7.3 節)
DNS/BIND の構成 (7.4 節)
時刻同期の管理 (7.5 節)
NFS の管理 (7.6 節)
inetd
の構成の管理 (7.7 節)
メール・サービスの管理 (7.8 節)
RIS 用のクラスタの構成 (7.9 節)
X Windows アプリケーションのリモートでの表示 (7.10 節)
クラスタは高可用性の DHCP (Dynamic Host Configuration Protocol) サーバとして構成できますが,DHCP クライアントとしては構成できません。クラスタは静的なアドレス指定を使用する必要があります。クラスタ内では DHCP は,フェイルオーバ機能を提供する CAA (Cluster Application Availability) サブシステムと連携して,シングル・インスタンス・アプリケーションとして動作します。DHCP サーバとして動作できるのは常にクラスタの 1 つのメンバのみです。フェイルオーバが行われた場合,新規 DHCP サーバは,前のサーバが使用していたのと同じ共通データベースを使用します。
DHCP サーバは,自身のホスト名および IP アドレスと DHCP データベース内のエントリとを一致させようとします。クラスタ・メンバのホスト名と IP アドレスを使ってデータベースを構成している場合は,問題が発生する可能性があります。メンバがダウンした場合,DHCP サーバは別のメンバに自動的にフェイルオーバされます。しかし,この新規 DHCP サーバのホスト名と IP アドレスは,DHCP データベース内のエントリと一致しません。この問題とその他の関連する問題を回避するには,次の手順を実行します。
Tru64 UNIX 『ネットワーク管理ガイド:接続編』 の DHCP に関する章を参照し,この章で説明されている DHCP サーバの構成手順について把握します。
初期 DHCP サーバとして実行するクラスタ・メンバ上で,/usr/bin/X11/xjoin
を実行し,DHCP を構成します。
[Server/Security
] を選択します。
現在表示されている [Server/Security Parameters
] のプルダウン・メニューから,[IP Ranges
] を選択します。
[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
xjoin
を使って DHCP を終了したら,DHCP を高可用性アプリケーションにします。DHCP には処理スクリプトとリソース・プロファイルが既に用意されており,DHCP は CAA デーモンに既に登録されています。CAA サブシステムを使って DHCP を起動するには,次のコマンドを入力します。
# caa_start dhcp
/etc/join/server.pcy
を編集して,次の行を追加します。
canonical_name cluster_alias
cluster_alias は省略時のクラスタ別名です。
DHCP を停止して再起動します。
# caa_stop dhcp # caa_start dhcp
高可用性アプリケーションと CAA サブシステムについては,TruCluster Server 『クラスタ高可用性アプリケーション・ガイド』を参照してください。
7.2 NIS の構成
NIS (ネットワーク情報サービス) デーモン
ypxfrd
および
rpc.yppasswdd
は,クラスタのあらゆるメンバ上で動作し,メンバの可用性を高めます。
3.1 節で説明されているように,クラスタ別名を通してアクセスするサービスのポートは,in_single
または
in_multi
のいずれかで定義します (この定義は,サービスを複数のクラスタ・メンバで同時に実行できるかどうかとは無関係です)。
ypxfrd
は
in_multi
サービスで動作します。つまり,クラスタ別名サブシステムは,このサービスに宛てられた接続要求とパケットを,その別名に対して資格のあるメンバ全員に送ります。
rpc.yppasswdd
は
in_single
サービスで動作します。つまり,このサービスに宛てられた接続要求とパケットは,1 つの別名メンバだけが受信します。そのメンバが使用できなくなると,クラスタ別名サブシステムは同じ別名内の他のメンバを選択し,このサービスに宛てられたすべての要求とパケットをそのメンバに受信させます。
NIS パラメータは
/etc/rc.config.common
ファイルに保存されています。NIS データベース・ファイルは
/var/yp/src
ディレクトリにあります。これらのファイルはクラスタのすべてのメンバによって共用されます。クラスタは,スレーブ,マスタ,またはクライアントです。クラスタ内で,スレーブ,マスタ,およびクライアントの機能を備えたメンバは混在できません。
クラスタの作成時に NIS を構成した場合,NIS の構成に限り,クラスタに対するメンバの追加または削除時に何も行う必要はありません。
クラスタの稼働後に NIS を構成するには,次の手順を実行します。
nissetup
コマンドを実行し,Tru64 UNIX 『ネットワーク管理ガイド:サービス編』 の NIS に関する章の指示に従って,NIS を構成します。
NIS がバインドするホスト名として,クラスタ別名をホスト名のリストに追加しなければなりません。
クラスタの各メンバ上で,次のコマンドを実行します。
# /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 つの選択肢があります。
:on=localhost
クラスタのあらゆるメンバが印刷を担当するようにするには,localhost
を指定します。プリント・ジョブが送信されると,応答した最初のメンバが,キューが空になるまで,すべてのプリント・ジョブを処理します。ローカル・ジョブの場合,最初にジョブを投入したメンバが最初に応答するメンバとなります。外から入ってくるリモート・ジョブの場合,そのジョブのサービスはクラスタ別名に基づいて行われます。
:on=member1,member2,...,memberN
クラスタのいずれか 1 つのメンバにすべての印刷を担当させるには,特定のメンバを列挙指定します。:on
に列挙された最初のメンバがすべてのプリント・ジョブを処理します。そのメンバが使用できなくなった場合は,列挙された次のメンバが処理を引き継ぐという具合に続きます。
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 クライアントとして構成されます。
/etc/resolv.conf
にネームサーバのエントリがある場合,クラスタは BIND クライアントです。各クラスタ・メンバは,/etc/resolv.conf
に指定されたネームサーバの BIND クライアントです。
省略時のクラスタ別名の名前が
/etc/resolv.conf
のネームサーバとして指定されていて,クラスタも
named
デーモンを実行している場合,クラスタは BIND クライアントと 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_create
と
clu_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 デーモンの起動,再起動,または停止
サーバ・デーモンの構成または構成除外
クライアント・デーモンの構成または構成除外
NFS の構成状態の表示
NFS デーモンの状態の表示
特定のメンバの NFS を構成するには,sysman
の
-focus
オプションを使用します。
フォーカスを指定しないで NFS を構成すると,その構成はクラスタ全体に適用され,/etc/rc.config.common
に保存されます。フォーカスを指定して NFS を構成すると,その構成はフォーカスを指定されたクラスタ・メンバのみに適用され,そのメンバの CDSL ファイル
/etc/rc.config
に保存されます。
ローカルの NFS 構成はクラスタ全体の NFS 構成を上書きします。たとえば,メンバ
mutt
を NFS サーバにならないように構成した場合,クラスタ全体を NFS サーバとして構成しても,その構成は
mutt
に適用されません。つまり,mutt
は引き続き NFS サーバにはなりません。
ここで,もっと興味深い例を挙げます。たとえば,alpha
,beta
,gamma
という 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 -c
と
rpc.statd -c
),デーモン
lockd
および
statd
はクラスタ単位で起動されます。この場合,これらのデーモンは高可用性で,CAA サブシステムによって管理されます。NFS サーバは自身のアドレスとして,省略時のクラスタ別名または
/etc/exports.aliases
で指定されている別名を使用します。
クラスタが NFS サーバとして動作するとき,クラスタの外部クライアント・システムからは,クラスタはクラスタ別名で参照される単一システムとして見えます。外部クライアント・システムがクラスタ内のディレクトリの CDSL をマウントしても,このシステムが見えるのはクラスタ・メンバ上のパスだけです。ただし,このメンバでは
statd
と
lockd
のペアがクラスタ単位で動作している必要があります。
NFS サービスの起動と停止は,特定のメンバに対してもクラスタ全体に対しても行うことができます。通常,クラスタ単位で動作する
lockd
と
statd
のペアの起動と停止は自動的に行われます。ただし,これらのデーモンを手動で停止する場合は,次のコマンドを入力します。
# 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 はマウント・ポイントをクリーンアップします。クリーンアップ処理の間,マウント・ポイントにアクセスするメンバはクリーンアップの進展状況により,次のような状態になります。
ファイル・システム上でメンバがファイルをオープンしている場合,書き込みデータは NFS マウントされた実際のファイル・システムでなく,ローカル・キャッシュに送られる。
ファイル・システム上ですべてのファイルをクローズした後では,ファイル・システムを再マウントしない限り,ファイル・システム上のファイルをオープンしようとしてもオープンできず,EIO
エラーが発生する。アプリケーションは「Stale NFS handle」メッセージを通知される場合がある。これは,クラスタと同様にスタンドアロン・システムでも一般的に起こりえる。
CFS のクリーンアップが完了するまでは,メンバは NFS ファイル・システムのローカル・マウント・ポイントで (または,マウント・ポイントの下にローカルに作られたディレクトリ内で) 新しいファイルを作成することができます。
AutoFS か Automount を使用していなければ,NFS ファイル・システムは自動的に別のクラスタ・メンバにフェイルオーバしません。別のクラスタ・メンバから,手動で同じマウント・ポイントか別のマウント・ポイントに再マウントして,再度使用可能にする必要があります。もう 1 つの方法としては,クラスタ・メンバをブートして,/etc/fstab
ファイルに登録されていて,クラスタで現在マウントされておらず,サービスされいないファイル・システムを再マウントします。
7.6.2.2 クライアントはクラスタ別名を使用しなければならない
クラスタが NFS サーバとして動作している場合,外部クライアントは,クラスタからファイル・システムをマウントするとき,省略時のクラスタ別名か,または
/etc/exports.aliases
で指定されている別名を使ってホストを指定しなければなりません。外部クライアントがクラスタからファイル・システムをマウントしようとしたが,省略時のクラスタ別名または
/etc/exports.aliases
で指定されている別名を使用しなかった場合は,「connection refused」というエラー・メッセージがそのクライアントに返されます。
mountd
経由で動作するその他のコマンド (たとえば
umount
と
export
) が外部クライアントから発行されたが,省略時のクラスタ別名も
/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 をマウント・ポイントとして使用します。
マウント・ポイントがない場合は作成します。
# mkdir /mountpoint
mkcdsl -a
コマンドを使用して,ディレクトリを CDSL に変換します。これにより,全メンバのメンバ固有領域に,既存のディレクトリがコピーされます。
# mkcdsl -a /mountpoint
同じ 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 を使用する場合は,次の事項を考慮してください。
1 つの単一 NFS サーバから多数のファイル・システムをインポートしたり,特に遅いデータリンクを使うサーバからインポートしたりするクラスタでは,autofs
サブシステム内の
mount_timeout
カーネル属性の値を増やす必要があるかもしれません。mount_timeout
の省略時の値は 30 秒です。メンバが稼働中にこの属性の値を変更するには,sysconfig
コマンドを使用します。たとえば,タイムアウト値を 50 秒に変更するには,次のコマンドを使用します。
# sysconfig -r autofs mount_timeout=50
自動マウントしたファイル・システムを表示すると,ファイル・システムは何度かマウントされたかのように見えます。カーネルが自動マウント要求のタイムアウトを検出するが,NFS マウントが継続されたときにこの現象が発生します。つまり,こタイムアウトにより,次の自動マウント要求が処理された結果,重複したマウントが発生します。この場合には,操作上の影響はありません。
autofsd
デーモンを起動するか,autofsmount
を実行して自動ファイル・システムのマッピングを処理するとき,AutoFS はすべてのクラスタ・メンバが同じバージョンの TruCluster Server ソフトウェアを実行していることを確認します。
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 強制アンマウントが必要かどうかの判断
自動マウントしたファイル・システムへアクセスしたときに問題の発生することが明らかな場合
CAA
autofs
リソースを移動した場合
自動マウントしたファイル・システムへアクセスしたときに問題の発生することが明らかな場合は,自動マウントしたファイル・システムが期待したとおりに動作していることを確認します。 手順は,次のとおりです。
caa_stat
autofs
コマンドを使用して,autofs
リソースの動作している場所を CAA がどのように把握しているかを確認します。
次の
ps
コマンドを使用して,CAA の期待しているメンバで確かに
autofsd
デーモンが動作していることを確認します。
# ps agx | grep autofsd
動作してない場合は,動作させて問題が解決されるかどうかを確認します。
アクセスできないファイル・システムに対応する,自動マウントのマップ・エントリを調べます。たとえば,エントリを対象に
/etc/auto.x
を検索して調べます。
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
問題になっている使用中のファイルがアクティブでなくなるまで待てる場合は,待ってください。そして,アクティブでなくなってから以前の 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 インターセプト・ポイントと自動マウントしたファイル・システムを強制的にアンマウントします。
可能であればシステムを静止させて,ユーザとアプリケーションの混乱を最小限に抑えます。
次のコマンドを入力して,autofs
CAA リソースを停止します。
# caa_stop autofs
CAA は,自動マウントしたファイル・システムにまだ使用中のものがあっても,autofs
リソースを停止すべきであると解釈します。
次のコマンドを入力して,AutoFS インターセプト・ポイントと自動マウントしたファイル・システムがすべてアンマウントされたことを確認します。 出力で autofs の参照を検索します。
# mount -e
アンマウントされていないものがまだある場合は,次のコマンドを入力して AutoFS インターセプトと自動マウントされたファイル・システムを強制的にアンマウントします。
#cfsmgr -K directory
AutoFS インターセプト・ポイントまたは自動マウントされたファイル・システムがマウントされているディレクトリを指定します。インターセプトと自動マウントされたファイル・システム (同じノードでサービスされているもの) をすべて削除するために入力する必要があるマウント・ディレクトリは 1 つだけです。
次のコマンドを入力して
autofs
リソースを起動します。
# caa_start autofs -c cluster_member_to_be_server
7.6.4 Automount から AutoFS への移行
この項では,Automount から AutoFS への移行にあたって,考えられる 3 つの場面について説明します。
クラスタ・メンバのリブートなしの移行は,多くの手順が必要ですが,最高の可用性をもたらします。リブートによって,Automount のインターセプト・ポイントをクリーンアップし,AutoFS を自動的に起動することができないため,最も多くの手順が必要になります。
注意
ほとんどの Automount の環境では,1 つの automount インスタンスで,すべてのマップ・ファイルを処理します。ここで説明する手順では,この一般的なケースについて説明します。
各マップ・ファイルを複数の automount インスタンスで処理する複雑な Automount 環境の場合,
/etc/rc.config.common
ファイルをカスタマイズしたり,ps
コマンドで戻された複数のプロセス識別子を強制終了する必要があったり,すべての NFS ファイル・システムに対して 1 つのメンバだけが自動マウント・サーバ・ノードでないなどの状況が発生します。Automount 環境に適合する手順を考慮する場合,アクティブな Automount サーバ・プロセスを強制終了させるときに,Automount サービスのフェイルオーバが発生しないように,Automount の "standby" プロセスを強制終了してください。
クラスタ・メンバのリブートなしに Automount から AutoFS へ移行する手順は,次のとおりです。
rc.config.common
ファイルを変更します。
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
前の手順での決定に従って,autofsmount
に渡す引数を設定します。これを行うには,次の例で示すように,rcmgr -set
コマンドを使用します。
# /usr/sbin/rcmgr -c set AUTOFSMOUNT_ARGS -D MACH=alpha -D NET=f /- /etc/auto.direct
autofsd
デーモンに渡す引数を次の例で示すように設定します。
# /usr/sbin/rcmgr -c set AUTOFSD_ARGS -D MACH=alpha -D NET=f
これらの引数は,AUTOMOUNT_ARGS
に設定されたのと同じように,-D
オプションの環境変数と一致する必要があります。
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)
によって示されます。
次の例で示すように,どのクラスタが前の手順で識別された NFS ファイル・システムの Automount サーバ・ノードかを調べます。
# cfsmgr -p /net Domain or filesystem name = /net Server Name = swiss Server Status: OK
前の手順で識別した 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
コマンドがクラスタ単位で動作し,どのクラスタ・メンバからでもプロセスを強制終了できます。
次のように,rc.config.common
ファイルで Automount を無効にし,AutoFS を有効にします。
# /usr/sbin/rcmgr -c set AUTOMOUNT 0 # /usr/sbin/rcmgr -c set AUTOFS 1
すべての自動マウントされたファイル・システムが休止状態になるまで待ちます。
サーバとして動作しているクラスタ・メンバでの 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
mount -e
コマンドを使用し,tmp_mnt
の出力,または
automount -M
コマンドで指定されたディレクトリを検索し,自動マウントされたファイル・システムがマウントされていないことを確認します。
# mount -e | grep tmp_mnt
マウント・ポイントがまだ存在していても,もはや期待されるパス名で使用することはできません。ただし,/tmp_mnt/...
というフル・パス名では使用することができます。AutoFS は
/tmp_mnt
マウント・ポイントを使用しないので,競合がなく,完全な自動マウントのネームスペースが AutoFS で使用可能になります。これらの
tmp_mnt
マウント・ポイントが後でアイドル状態になった場合は,umount
コマンドの
-f
オプションを使用してアンマウントできます。このオプションは,サーバに通知することなしにリモート・ファイル・システムをアンマウントします。
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)
caa_stat autofs
コマンドを使用して,autofs
リソースを期待通りに起動したことを確認します。
# /usr/bin/caa_stat autofs NAME=autofs TYPE=application TARGET=ONLINE STATE=ONLINE on swiss
クラスタ・メンバをリブートする移行は,リブートなしの移行よりも,可用性は落ちますが実行手順が少なくなります。
注意
クラスタ・メンバをシャットダウンする前に,そのクラスタ・メンバが不可欠な投票メンバであるかどうかと,restricted ポリシで指定された 1 つ以上のアプリケーションの唯一のホスト・メンバであるかどうかを調べる必要があります。これらについては,5.5 節で説明しています。
ほとんどの Automount の環境では,1 つの automount インスタンスで,すべてのマップ・ファイルを処理します。ここで説明する手順では,この一般的なケースについて説明します。
各マップ・ファイルを複数の automount インスタンスで処理する複雑な Automount 環境の場合,
/etc/rc.config.common
ファイルをカスタマイズしたり,ps
コマンドで戻された複数のプロセス識別子を強制終了する必要があったり,すべての NFS ファイル・システムに対して 1 つのメンバだけが自動マウント・サーバ・ノードでないなどの状況が発生します。Automount 環境に適合する手順を考慮する場合,アクティブな Automount サーバ・プロセスを強制終了させるときに,Automount サービスのフェイルオーバが発生しないように,Automount の "standby" プロセスを強制終了してください。
クラスタ・メンバをリブートする,Automount から AutoFS への移行手順は,次のとおりです。
rc.config.common
ファイルを変更します。
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
前の手順での決定に従って,autofsmount
に渡す引数を設定します。これを行うには,次の例で示すように,rcmgr -set
コマンドを使用します。
# /usr/sbin/rcmgr -c set AUTOFSMOUNT_ARGS -D MACH=alpha -D NET=f /- /etc/auto.direct
次の例で示すように,autofsd
デーモンに渡す引数を設定します。
# /usr/sbin/rcmgr -c set AUTOFSD_ARGS -D MACH=alpha -D NET=f
これらの引数は,AUTOMOUNT_ARGS
に設定されたのと同じように,-D
オプションの環境変数と一致する必要があります。
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)
によって示されます。
次の例で示すように,どのクラスタが前の手順で識別された NFS ファイル・システムの Automount サーバ・ノードかを調べます。
# cfsmgr -p /net Domain or filesystem name = /net Server Name = swiss Server Status: OK
前の手順で識別した 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
コマンドがクラスタ単位で動作し,どのクラスタ・メンバからでもプロセスを強制終了できます。
次のように,rc.config.common
ファイルで Automount を無効にし,AutoFS を有効にします。
# /usr/sbin/rcmgr -c set AUTOMOUNT 0 # /usr/sbin/rcmgr -c set AUTOFS 1
(オプション) 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
コマンドを使用して,変更を有効にします。
クラスタ・メンバをリブートします。クラスタ・メンバをシャットダウンする前に,そのクラスタ・メンバが不可欠な投票メンバでないことと,restricted 配置ポリシで指定された 1 つ以上のアプリケーションの唯一のホスト・メンバでないことを確認します。これらについては,5.5 節で説明しています。
リブートすると,AutoFS が起動し,Automount はクラスタで実行されません。
# /sbin/shutdown -r now
クラスタ全体をリブートする移行は,リブートなしの移行や単一メンバをリブートする移行より実行手順が少なくなりますが,クラスタの可用性は失われます。
クラスタのリブートは,思い切った方法であり,推奨する移行方法ではありません。
クラスタのリブート時に次の手順に従って,Automount から AutoFS へ移行します。
rc.config.common
ファイルを変更します。
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
前の手順での決定に従って,autofsmount
に渡す引数を設定します。これを行うには,次の例で示すように,rcmgr -set
コマンドを使用します。
# /usr/sbin/rcmgr -c set AUTOFSMOUNT_ARGS -D MACH=alpha -D NET=f /- /etc/auto.direct
次の例で示すように,autofsd
デーモンに渡す引数を設定します。
# /usr/sbin/rcmgr -c set AUTOFSD_ARGS -D MACH=alpha -D NET=f
これらの引数は,AUTOMOUNT_ARGS
に設定されたのと同じように,-D
オプションの環境変数と一致する必要があります。
次のように,rc.config.common
ファイルで Automount を無効にし,AutoFS を有効にします。
# /usr/sbin/rcmgr -c set AUTOMOUNT 0 # /usr/sbin/rcmgr -c set AUTOFS 1
(オプション) 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
コマンドを使用して,変更を有効にします。
クラスタをリブートします。リブートすると,Automount はクラスタ内で実行されておらず,AutoFS が起動しています。
# /sbin/shutdown -c now
インターネット・サーバ・デーモン (inetd
) の構成データは,次の 2 つのファイルに保存されています。
クラスタのすべてのメンバによって共用されるクラスタ単位のファイル。/etc/inetd.conf
を使って,あらゆるメンバ上で同じ動作をするネットワーク・サービスを構成します。
/etc/inetd.conf.local
クラスタの各メンバに固有の構成データを保存するファイル。メンバごとに異なる動作をするネットワーク・サービスを構成するときに使用します。
ローカル・メンバ上のクラスタ単位のサービスを無効にするには,そのメンバの
/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 Phase IV
DECnet/OSI
MTS (メッセージ・トランスポート・システム)
UUCP (UNIX 間コピー・プログラム)
X.25
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 メール・ファイル
次のメール・ファイルはクラスタ全体で共用される共通ファイルです。
/usr/adm/sendmail/sendmail.cf
/usr/adm/sendmail/aliases
/var/spool/mqueue
/usr/spool/mail/*
次のメール・ファイルはメンバ固有のファイルです。
/var/adm/sendmail
内で,ファイル名に
hostname
を含むファイルは,hostname
の代わりに省略時のクラスタ別名を使用します。たとえば,クラスタ別名が
accounting
の場合は,/var/adm/sendmail
には
accounting.m4
と
Makefile.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
) を使って,クラスタのメンバ間でネットワーク接続の負荷分散を行います。選択優先順位と選択重みは,次のような仕組みになっています。
最高の選択優先順位のクラスタ・メンバはすべての接続要求を受信します。
選択優先順位の値として 1 〜 100 のいずれかの整数を指定できます。省略時の値は 1 です。
選択重みによって,同じ選択優先順位のメンバ間での接続要求の分配が決まります。メンバは,平均して選択重みと同数の接続要求を受信します。その後,後続の接続要求は同じ優先順位の次のメンバに送信されます。
選択重みの値として 0 〜 100 のいずれかの整数を指定できます。選択重みが 0 のメンバは,要求の受信はしませんが,送信はできます。
省略時の設定では,クラスタのすべてのメンバには,各メンバの
/etc/clu_alias.config
ファイル内で設定された値と同じ選択優先順位 (selp=1
) と選択重み (selw=1
) が割り当てられます (clu_create
コマンドは省略時の選択重み 3 を使用しますが,別名を作成する場合は省略時の選択重みが 1 になります)。すべてのメンバが同じ選択優先順位と選択重みを共有するとき,接続要求はメンバ間で均等に分配されます。省略時のシステム構成では,各メンバが順番に 1 つの接続要求を受信します。
受信メール (およびその他すべての接続) を一部のクラスタ・メンバだけに処理させたい場合は,それらのクラスタ・メンバの選択優先順位を,その他のメンバの選択優先順位より高い値に統一します。
また,メールを処理させるクラスタ・メンバだけで新しいメール別名を作成することも,すべてのメンバを含むメール別名を作成し,選択優先順位を用いて,新しい接続要求を受信するメンバの順序を決定することもできます。
メンバの選択重みまたは選択優先順位を設定するには,そのメンバ上で
cluamgr
コマンドを実行します。メンバの
selp
と
selw
に省略時の値が設定されている場合に,すべてのメール (およびその他のすべての接続要求) がクラスタの 1 つのメンバによって受信されるようにするには,そのメンバにログインして,selp
に省略時の値より大きい値を設定します。たとえば,次のコマンドを入力します。
# cluamgr -a alias=DEFAULTALIAS,selp=50
8 メンバ構成のクラスタがあり,2 つのメンバ
alpha
および
beta
にすべての接続要求を受信させるとします。このとき,alpha
と
beta
との間の負荷分散を 40/60 にするとします。そのためには,まず
alpha
にログインして,次のコマンドを入力します。
# cluamgr -a alias=DEFAULTALIAS,selp=50,selw=2
その後,beta
にログインして,次のコマンドを入力します。
# cluamgr -a alias=DEFAULTALIAS,selp=50,selw=3
その他のメンバの
selp
に省略時の値の 1 が設定されているとすると,beta
と
alpha
はすべての接続要求を受信します。まず
beta
が 3 つの接続要求を受信し,次に
alpha
が 2 つの接続要求を受信し,次に
beta
が 3 つの接続要求を受信する,という具合に続きます。
注意
selp
とselw
をこのように設定すると,メールのトラフィックだけでなく,クラスタ別名を介するすべての接続に影響します。
接続要求の分配についての詳しい説明は,3.10 節および
cluamgr
(8)7.9 RIS 用のクラスタの構成
クラスタ内に RIS (Remote Installation Services) サーバを作成するには,Tru64 UNIX 『Sharing Software on a Local Area Network』で説明した手順に加えて,次の手順を実行します。
/etc/bootptab
を修正して,NFS マウント・ポイントとして省略時のクラスタ別名を設定する。
tftp
サーバのアドレスとして省略時のクラスタ別名を設定する。
sa=default_cluster_alias
/etc/bootptab
については,
bootptab
(4)
注意
ネットワークの構成に応じて,RIS サーバにクラスタ別名を登録するときは,一意かつ任意のハードウェア・アドレスを指定する必要があります。
RIS クライアントとしてクラスタを使用するには,次のことを行う必要があります。
RIS サーバに
setld
コマンドを使用して,クラスタ・メンバを登録します。これは,メンバ名とそのメンバのハードウェア・アドレスを登録することにより行います。
省略時のクラスタ別名を登録します。
オペレーティング・システム・キットに対して登録する場合には,ハードウェア・アドレスの入力が必要となります。クラスタ別名には,ホスト名と対応した物理インタフェースがありません。代わりに,/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_services
の
Xserver
の行をコメントにするか,その行から
out_alias
属性を削除します (その後で,各クラスタ・メンバ上で
cluamgr -f
を実行して,変更を有効にします)。
クラスタ別名の詳細については,第 3 章を参照してください。