5    クラスタ・メンバの管理

この章では次の項目について説明します。

クラスタ・メンバの管理に関連する次のエントリについては,TruCluster Server 『クラスタ・インストレーション・ガイド』を参照してください。

Tru64 UNIX と TruCluster Server の可用性および保守性に関する構成と管理については,Tru64 UNIX の『Managing Online Addition and Removal』を参照してください。このマニュアルでは,可用性の高いシステムを構成して管理するためのガイドラインを,システム構成要素の OLAR (Online Addition and Replacement) 管理を中心に説明しています。

注意

Tru64 UNIX の『Managing Online Addition and Removal』で説明されているように,システムに固有なポリシは /etc/olar.config ファイルで定義し,クラスタ単位のポリシは /etc/olar.config.common ファイルで定義します。システムの /etc/olar.config ファイルで行った設定は,そのシステムに関する限り,/etc/olar.config.common ファイルに記述したクラスタ単位のポリシより優先します。

5.1    構成変数の管理

/etc/rc.config* ファイルの階層化により,ローカル・エリア・ネットワーク (LAN) 内およびクラスタ内のすべてのシステムの構成変数を一元管理できます。表 5-1 に,各種構成ファイルの有効範囲を示します。

表 5-1:  /etc/rc.config* ファイル

ファイル 有効範囲
/etc/rc.config

メンバ固有の変数を保存している。

/etc/rc.config はテキスト依存シンボリック・リンク (CDSL) である。クラスタの各メンバにはそれぞれ固有の /etc/rc.config ファイルがある。

/etc/rc.config 内の構成変数は /etc/rc.config.common/etc/rc.config.site 内の構成変数を上書きする。

/etc/rc.config.common

クラスタ単位の変数を保存している。これらの変数はクラスタのすべてのメンバに適用される。

/etc/rc.config.common 内の構成変数は,/etc/rc.config.site 内の構成変数を上書きするが,/etc/rc.config 内の構成変数によって上書きされる。

/etc/rc.config.site

サイト単位の変数を保存している。これらの変数は LAN 上のすべてのマシンの変数と一致する。

このファイル内の値は,/etc/rc.config.common または /etc/rc.config 内の対応する値によって上書きされる。

省略時の設定では,/etc/rc.config.site は作成されない。サイト単位の変数を設定する場合は,ファイルを /etc/rc.config.site という名前で作成して,サイト単位の構成変数を設定し,参加している各システムにそのファイルをコピーする。

その後,各システム上の /etc/rc.config 内で,/etc/rc.config.common を実行する行の直前に,次のコードを追加する。

# Read in the cluster sitewide attributes

# before overriding them with the

# clusterwide and member-specific values.

#

./etc/rc.config.site

詳細は, rcmgr(8) を参照。

rcmgr コマンドは標準の検索順 (最初に /etc/rc.config,次に /etc/rc.config.common,最後に /etc/rc.config.site) でこれらの変数にアクセスし,指定された値を検出または設定します。

特定のメンバの実行時構成変数を取得または設定するには,-h オプションを使用します。これによって,このコマンドの実行対象は /etc/rc.config (メンバ固有の構成ファイルの CDSL) になります。

このコマンドの実行対象をクラスタ全体にするには,-c オプションを使用します。これによって,このコマンドの実行対象は /etc/rc.config.common (クラスタ単位の構成ファイル) になります。

-h-c も指定しない場合は,/etc/rc.config 内のメンバ固有の値が使用されます。

メンバ固有の構成変数については,付録 B を参照してください。

5.2    カーネル属性の管理

クラスタの各メンバは,独自にカーネルを実行するので,それぞれ独自に /etc/sysconfigtab ファイルを持っています。このファイルには,メンバ固有の静的な属性設定が格納されます。クラスタ単位の /etc/sysconfigtab.cluster ファイルがありますが,その用途は /etc/rc.config.common とは異なり,TruCluster Server 製品に付属するユーティリティに限られています。

ここでは,各 TruCluster Server サブシステムで提供されているカーネル属性のリストの一部を示します。

次のコマンドを使用して,指定したサブシステムのこのような属性の現在の設定を表示します。

#  sysconfig -q subsystem-name attribute-list

すべてのサブシステムのリストと状態を得るには,次のコマンドを使用します。

# sysconfig -s

ここで示したクラスタ関連のカーネル属性のほかに,2 つのカーネル属性がクラスタのインストール中に設定されます。表 5-2 に,このようなカーネル属性を示しています。これらの属性に設定されている値は,増やすことはできますが,減らすことはできません。

表 5-2:  削減できないカーネル属性

属性 値 (削減不可)
vm_page_free_min 30
vm_page_free_reserved 20

表 5-3 は,各 TruCluster Server 構成要素に対応するサブシステム名を示しています。

表 5-3:  構成可能な TruCluster Server サブシステム

サブシステム名 構成要素 詳細
cfs クラスタ・ファイル・システム (CFS) sys_attrs_cfs(5)
clua クラスタ別名 sys_attrs_clua(5)
clubase クラスタ・ベース sys_attrs_clubase(5)
cms クラスタ・マウント・サービス sys_attrs_cms(5)
cnx 接続マネージャ sys_attrs_cnx(5)
dlm 分散ロック・マネージャ sys_attrs_dlm(5)
drd デバイス要求ディスパッチャ sys_attrs_drd(5)
hwcc ハードウェア・コンポーネント・クラスタ sys_attrs_hwcc(5)
icsnet ノード間通信サービスのネットワーク・サービス sys_attrs_icsnet(5)
ics_hl 上位レベルのノード間通信システム (ICS) sys_attrs_ics_hl(5)
mcs Memory Channel アプリケーション・プログラミング・インタフェース (API) sys_attrs_mcs(5)
rm Memory Channel sys_attrs_rm(5)
token CFS トークン・サブシステム sys_attrs_token(5)

カーネル・サブシステムの性能を調整するには,次のいずれかの方法で /etc/sysconfigtab ファイル内の属性をいくつか設定します。

Tru64 UNIX 『システム管理ガイド』で説明しているように,構成マネージャのフレームワークを使用すれば,属性を変更する以外に,別のホスト上のクラスタ・カーネル・サブシステムを管理することもできます。この作業を行うには,リモート・クライアント・システムの /etc/cfgmgr.auth ファイル内にホスト名を設定し,次の例に示すように,/sbin/sysconfig コマンドに -h オプションを指定します。

# sysconfig -h fcbra13 -r drd drd-do-local-io=0
 
drd-do-local-io: reconfigured

5.3    クラスタ内およびクラスタからのリモート・アクセスの管理

クラスタからの rloginrsh,または rcp コマンドでは,省略時のクラスタ別名が送信元アドレスとして使用されます。したがって,非クラスタ・ホストで,クラスタ内の任意のアカウントからのリモート・ホスト・アクセスを許可しなければならない場合は,非クラスタ・メンバの .rhosts ファイルに,/etc/hosts ファイル内のいずれかの形式,あるいはネットワーク情報サービス (NIS) またはドメイン・ネーム・システム (DNS) で解決できる形式で,クラスタ別名を登録する必要があります。

この要件は,クラスタ・メンバ間で機能する rloginrsh,または rcp にも適用されます。クラスタ作成時に,clu_create ユーティリティで,必要なホストすべての名前の入力が求められ,その名前が適切な形式で正しい場所に設定されます。clu_add_member では,新しいメンバがクラスタに追加されるときに同じ処理が行われます。/.rhosts を編集しなくても,クラスタ・メンバからクラスタ別名に対して,あるいは個々のメンバ間で /bin/rsh コマンドを使用できます。/etc/hosts/.rhosts 内に生成された名前のエントリを変更しないでください。

/etc/hosts/.rhosts のファイルが間違って構成された場合,多くのアプリケーションは正しく機能しません。たとえば,AdvFS (Advanced File System) の rmvoladdvol のコマンドでは,そのコマンドが実行されるメンバがドメインのサーバでない場合は,rsh が使用されます。これらのコマンドは,/etc/hosts または /.rhosts が正しく構成されていない場合には失敗します。

次のエラーは,/etc/hosts/.rhosts のファイルが間違って構成されたことを示しています。

rsh cluster-alias date
Permission denied.
 

5.4    クラスタのシャットダウン

クラスタのすべてのメンバを停止するには,shutdown コマンドに -c オプションを使用します。たとえば,5 分以内にクラスタをシャットダウンするには,次のコマンドを入力します。

# shutdown -c +5 Cluster going down in 5 minutes
 

クラスタの特定のメンバのシャットダウンについては,5.5 節を参照してください。

シャットダウンの猶予期間内 (クラスタの shutdown コマンドが入力されてからシャットダウンが実際に行われるまでの時間),clu_add_member コマンドは無効であり,新規メンバをクラスタに追加できません。

この猶予期間内にクラスタのシャットダウンを取り消すには,次の手順に従って,shutdown コマンドに関連付けられたプロセスを強制終了します。

  1. shutdown コマンドに関連付けられたプロセス ID (PID) を取得します。たとえば,次のように入力します。

    # ps ax | grep -v grep | grep shutdown
     14680 ttyp5    I <    0:00.01 /usr/sbin/shutdown +20 going down
    

    猶予期間内での shutdown の進行状況に応じて,ps/usr/sbin/shutdown または /usr/sbin/clu_shutdown のいずれかを表示します。

  2. 任意のメンバから,取得した PID を指定して kill コマンドを実行することにより,シャットダウン・プロセスをすべて強制終了します。たとえば,次のように入力します。

    # kill 14680
     
    

猶予期間内にシャットダウン・プロセスを強制終了した場合,シャットダウンが取り消されます。

コマンド clu_quorumclu_add_memberclu_delete_member,または clu_upgrade が実行中である場合,shutdown -c コマンドを実行するとエラーが生じます。

クラスタ全体をリブートするコマンドはありません。コマンド shutdown -rreboot,および halt は,それらの実行元のメンバのみに影響します。コマンド haltreboot,および init は,クラスタにマウントされたファイル・システムをアンマウントしないように修正されています。そのためクラスタは,いずれか 1 つのメンバが停止またはリブートされても,クォーラムを維持している限り,稼働し続けます。

詳細は, shutdown(8) を参照してください。

5.5    クラスタの特定のメンバのシャットダウンと起動

メンバをブートするときは,clu_add_member コマンドによって作成されたブート・ディスクからブートしなければなりません。ブート・ディスクのコピーからはブートできません。

クラスタの特定のメンバのシャットダウンはスタンドアロン・サーバのシャットダウンより複雑です。クォーラムの維持に必須のボートを持つクラスタ・メンバ (重要な投票メンバと呼びます) を停止した場合,クラスタはクォーラムを失い,ハングアップします。その結果,停止したメンバをリブートするまで,クラスタのどのメンバからもコマンドを入力できません。したがって,クラスタのメンバをシャットダウンする前に,まずそのメンバのボートがクォーラムの維持に必須かどうか調べなければなりません。また,シャットダウンしようとしているクラスタ・メンバが,restricted 配置ポリシで 1 つ以上のアプリケーションの唯一のホスト・メンバかどうかも判断する必要があります。

5.5.1    重要な投票メンバの識別

重要な投票メンバのあるクラスタは,縮退モードで稼働しているか (たとえば,1 つ以上の投票メンバまたは 1 つのクォーラム・ディスクがダウンしている),または最初から可用性を考慮して構成されていません (たとえば,各メンバにボートが割り当てられている 2 メンバ構成)。重要な投票メンバをクラスタから削除すると,クラスタがハングして,可用性が低下します。クラスタ・メンバを停止または削除する前に,重要な投票をしていないことを確認してください。

メンバが重要な投票メンバかどうかを調べるには,次の手順に従います。

  1. 可能であれば,クラスタのすべての投票メンバが稼働中であることを確認します。

  2. clu_quorum コマンドを入力し,問題のメンバの現在のボート,クォーラム・ボート,およびノード・ボートの実行時の値をメモしておきます。

  3. 現在のボートの値からメンバのノード・ボートの値を引きます。その結果がクォーラム・ボートの値より小さい場合,そのメンバは重要な投票メンバです。そのメンバをシャットダウンすると,クラスタがクォーラムを失い,ハングします。

5.5.2    重要な投票メンバの停止または削除の準備

重要な投票メンバの停止または削除を行う前に,クォーラムを維持するクラスタでそのボートが必要とされなくなっていることを確認してください。それを確認する最善の方法は,期待ボートを増やさずに,ノード・ボートまたはクォーラム・ディスク・ボートをクラスタにリストアすることです。具体的な方法は,以下のとおりです。

クラスタのボートが偶数の場合は,新たに投票メンバを追加するか,クォーラム・ディスクを構成すれば,重要な投票メンバを重要でないメンバにすることもできます。このような場合には,期待ボートは増えますが,クォーラム・ボートは変わりません。

5.5.3    重要でないメンバの停止

重要でないメンバ,つまりボートを持たないメンバ,またはクォーラムの維持に必須でないボートを持つメンバは,スタンドアロン・システムのようにシャットダウン,停止,またはリブートできます。

シャットダウンするメンバ上で shutdown コマンドを実行します。 メンバを停止するには,次のコマンドを入力します。

# shutdown -h time
 

メンバをリブートするには,次のコマンドを入力します。

# shutdown -r time
 

重要な投票メンバの識別については,5.5.1 項を参照してください。

5.5.4    ホスト・メンバのシャットダウン

アプリケーションを実行させるメンバは,CAA (cluster application availability) プロファイルの中で各ホスト・メンバを空白で区切って指定します。ホスト・メンバのリストは, caa(4) で説明しているように,アプリケーション・リソースのフェイルオーバ・ポリシ (favored または restricted) と組み合わせて使用します。

配置ポリシが restricted であるアプリケーションをただ 1 つのホスト・メンバだけがサポートしている場合は,そのクラスタ・メンバをシャットダウンするときに他のホスト・メンバを指定する必要があります。そうしなければ,そのメンバがダウンしている間,アプリケーションを実行できなくなります。こうした場合に備えて,他のホスト・メンバを追加するか,または既存のホスト・メンバを他のメンバに切り換えます。

この処理は次の手順で行います。

  1. 現在のホスト・メンバと配置ポリシを確認します。

    # caa_profile -print resource-name
    

  2. シャットダウンするクラスタ・メンバが唯一のホスト・メンバである場合は,ホスト・メンバをリストに追加するか,または既存のホスト・メンバを切り換えます。

    # caa_profile -update resource-name -h hosting-member another-hosting-member
    # caa_profile -update resource-name -h hosting-member
     
    

  3. CAA のレジストリ・エントリを最新のリソース・プロファイルで更新します。

    # caa_register -u resource-name
    

  4. アプリケーションを他のメンバに再配置します。

    # caa_relocate
    resource-name -c member-name
    

5.6    クラスタ・メンバをシャットダウンしてシングルユーザ・モードにする

クラスタ・メンバをシャットダウンしてシングルユーザ・モードにする必要がある場合は,メンバを停止してからシングルユーザ・モードでブートしなければなりません。この方法でメンバをシャットダウンすれば,そのメンバがクラスタに対して提供するサービスを最低限に抑えることができます。また,稼働中のクラスタがシングルユーザ・モードで動作しているメンバに依存する割合も最低にすることができます。特に,クラスタ・メンバの状態を DOWN にしてからフェイルオーバを行わなければならないサービスがある場合,メンバを停止することによって,その要件を満たすことができます。クラスタ・メンバを最初に停止しなければ,サービスが期待どおりにフェイルオーバしません。

クラスタ・メンバをシングルユーザ・モードに移行するには,shutdown -h コマンドを用いてメンバを停止させ,次にメンバをシングルユーザ・モードでブートします。システムがシングルユーザ・モードになったら,init sbcheckrc,および lmf reset コマンドを実行します。以下に例を示します。

注意

クラスタ・メンバを停止する前に,そのメンバのボートがなくなってもクラスタがクォーラムを維持できることを確認しておいてください。また,そのクラスタ・メンバが,restricted 配置ポリシで 1 つ以上のアプリケーションの唯一のホスト・メンバでないことも確認してください。

/sbin/shutdown -h now
 
>>> boot -fl s
 
# /sbin/init s/sbin/bcheckrc/usr/sbin/lmf reset
 

シャットダウンされてシングルユーザ・モードになったクラスタ・メンバ (つまり,停止してからシングルユーザ・モードでブートするという推奨シャットダウン手順を使わなかった場合) は,状態が UP のままです。クラスタ・メンバをこのようにシャットダウンしてシングルユーザ・モードにした場合は,そのメンバの投票状態には影響しません。シャットダウンされてシングルユーザ・モードになる前に投票メンバであった場合,そのメンバはシングルユーザ・モードでも引き続き投票メンバになります。

5.7    クラスタ・メンバのリブート

すべてのメンバを同時にリブートしてはなりません。 すべてのクラスタ・メンバを同時にリブートしようとすると,クォーラム喪失のため,1 つまたは複数のメンバがダウンの途中でハングし,他のリブート中のノードが,クラスタに再度加わることができないため,ブートに失敗します (ハング・ノード)。

クラスタ全体をリブートするために使用する方法は,目的によって異なります。

5.8    クラスタからのメンバの削除

クラスタからメンバを削除するには,clu_delete_member コマンドを使用します。

警告

TruCluster Server を再インストールする場合は,TruCluster Server 『クラスタ・インストレーション・ガイド』を参照してください。既存クラスタからメンバを削除し,削除したそのメンバから 1 メンバ構成の新規クラスタを作成しないでください。その新規クラスタが既存クラスタと同じ名前の場合,新しくインストールしたシステムが既存クラスタに参加する場合があります。これによってデータの破壊が起こる可能性があります。

clu_delete_member コマンドの構文は次のとおりです。

/usr/sbin/clu_delete_member [-f] [-m memberid]

メンバ ID を指定しなかった場合,削除するメンバのメンバ ID が要求されます。

clu_delete_member コマンドは次の処理を行います。

クラスタからメンバを削除するには,次の手順を実行します。

  1. そのメンバがクラスタの重要な投票メンバかどうかを調べます。そのメンバがクラスタに重要なボートを投じる場合,そのメンバを停止すると,クラスタはクォーラムを失い,動作が中断されます。メンバを停止する前に,5.5 節の手順に従って,そのメンバを停止しても安全かどうかを調べます。

    また,5.5.4 項で説明しているように,そのクラスタ・メンバが restricted 配置ポリシで 1 つ以上のアプリケーションの唯一のホスト・メンバかどうかも判断する必要があります。

  2. 削除するメンバを停止します。

  3. 可能であれば,クラスタのすべての投票メンバが稼働中であることを確認します。

  4. 別のメンバから clu_delete_member コマンドを使って,そのメンバをクラスタから削除します。たとえば,停止したメンバのメンバ ID が 3 であり,そのメンバを削除するには,次のコマンドを入力します。

    # clu_delete_member -m 3
    

  5. clu_delete_member の実行時に,メンバのブート・ディスクがアクセスできない場合は,その旨を通知するメッセージを表示して,終了します。

    たとえ,メンバのブート・ディスクにアクセスできないとしても,-f オプションの指定で,強制的にメンバを削除できます。この場合,削除されるメンバが投票メンバなら,メンバが削除された後にクラスタの期待ボートを手動で 1 ボート低くする必要があります。これは,次のコマンドで行います。

    # clu_quorum -e expected-votes
    

メンバ削除時のログ・ファイル /cluster/admin/clu_delete_member.log の例については,付録 C を参照してください。

5.9    クラスタからのメンバの削除とスタンドアロン・システムとしての復元

スタンドアロン・システムとしてクラスタのメンバを復元するには,次の手順を実行します。

  1. 5.5 節5.8 節の手順に従って,メンバを停止して削除します。

  2. 停止したメンバをクラスタから物理的に切断し,クラスタ・インターコネクトとストレージを切断します。

  3. 停止したメンバ上で,このメンバのローカル・ディスクを選択し,Tru64 UNIX をインストールします。システム・ソフトウェアのインストールについては,Tru64 UNIX 『インストレーション・ガイド』マニュアルを参照してください。

非クラスタ化システムへのクラスタ化 LSM (Logical Storage Manager) ボリュームの移動については,Tru64 UNIX 『Logical Storage Manager』を参照してください。

5.10    別の IP サブネットへのクラスタの移動

この節では 1 つの IP サブネットから別の IP サブネットへのクラスタの移動方法について説明します。通常,クラスタの外部 IP アドレスが別の IP サブネットを指すようにサイトのネットワーク・トポロジの再構成を行うときにだけ必要となります。

増大する複雑さを回避するために,クラスタを別の IP サブネットに移動する場合には,次の項目を変更する必要があります。

この節には,情報収集と移動の実行の際に使用する表が用意されています。この表では,3 つの移動方法に対してそれぞれ必要とされるファイルの編集方法について説明しています。計画している移動方法に該当する表を使用してください。5.10.2 項は移動を開始する前の情報収集に役立ち,このチェックリストは編集の履歴を残せます。

この手順を用いる前に,次の要件に注意してください。

クラスタを別の IP サブネットに移動するには,次の手順を実行します。

  1. 移動のために必要となる IP 名とアドレスを取得します。この情報を記録するために 5.10.2 項の表を使用します。移動のために必要なサブネット・マスクのすべての変更を記録します。移動した結果,クラスタが別のネームサーバを使う場合,/etc/resolv.conf ファイルに加える変更を記録します。

  2. この移動が物理的なネットワーク接続の変更を要する場合,新しい物理的なネットワーク接続が適切で,使用できる状態にあることを確認します。

  3. いつ移動を実行するかを,ユーザ,他のクラスタ,およびネットワーク管理者に知らせます。他のシステムやクラスタが変更を計画している IP 名とアドレスに依存している場合,それらの管理者と連携をとる必要があります。たとえば,NIS,DNS,またはメール・サーバが影響を受けます。クラスタが,停止してはならないサービスを実行中であれば,クラスタがシャットダウンしている間にサービスを実行する,別のシステムやクラスタを準備します。

  4. 現在のクラスタの IP 名とアドレスが共通のシステム構成ファイル中で使用されている場所を調べます。これを実行する 1 つの方法は,clu_get_info を使用し,現在のクラスタの情報を取得した後,grep を使用して共通のシステム構成ファイル内で情報を探します。

  5. ホスト名,IP アドレス,クラスタ別名,インタフェース IP 別名,名前の別名,またはサブネット・マスクを含む可能性のある CAA スクリプト・ファイルのようなすべてのファイルを探します。

  6. 更新しようとする構成ファイルの保存用,作業用の両方のファイルを作成します。

    注意

    CAA スクリプトやサイト固有のスクリプトが変更対象の IP アドレス,ホスト名,別名,またはサブネット・マスクを参照する場合,それらのファイルのコピーを作り,それらに加えた変更の履歴を残しておいてください。

  7. 計画している変更に該当する表を使用します。

    1. 表の情報を使用して,原本ではなくコピーの作業ファイルを編集します。CDSL では,メンバ固有のディレクトリ内の作業ファイルを編集することを覚えておいてください。

      注意

      sysman を使うか,またはエディタを使うかは自由です。正しく編集をすることが重要です。作業ファイルから原本ファイルの位置へコピーし,すべてのクラスタ・メンバを停止する前に,情報が正しいことを 100 パーセント確実にする必要があります。

      作業ファイルを編集する場合,新しいサブネット上のサブネット・マスクが現在のサブネット用のものと同じでないなら,それらを編集することを覚えておいてください。

      /.rhosts/etc/hosts.equiv 作業ファイルを編集する場合,新しいホスト名を追加しますが,そこに現在リストされているものを削除しないでください。新しいサブネットでクラスタが正常にブートできた後,旧ホスト名を削除してください。

    2. 編集をすべて終えた後で,作業ファイルと原本ファイルの内容を比較します。編集内容を見直してください。

  8. すべての編集内容の確認がとれた後,次のことを実施します。

    1. 影響を受ける全員にメッセージを送ります。いつクラスタへのアクセスが無効になる予定か,いつ実際の移動を開始するのかを知らせます。

    2. ログインとすべての外部ネットワーク・インタフェースを無効にします。たとえば,wall -c コマンドを使って,ユーザにすぐにログインが無効になることを知らせ,touch コマンドを使って,/etc/nologin ファイルを作成し,各メンバで rcinet stop コマンドを使ってそのメンバ上のネットワークを停止させます。

    3. 原本のファイル位置に作業ファイルをコピーします。編集後のファイルで置き換えた各ファイルの履歴を残しておいてください (更新した他のすべてのファイルの履歴も残しておいてください)。

    4. 編集した構成ファイルがすべて適切な位置に置かれた後で,すべての情報が正しいことを確認します。クラスタをシャットダウンした後のリブートの成否は編集結果によります。移動を必要とした変更範囲を考慮して,次の項目のうちいくつかあるいは全部が正しく変更されていることを確認します。

      • IP アドレス,インタフェース IP 別名,およびサブネット・マスク

      • ホスト名と名前の別名

      • 省略時のクラスタ別名とその他のクラスタ別名

  9. クラスタの各メンバを停止します。たとえば,各メンバ上で次のコマンドを実行します。

    shutdown -h now
     
    

    注意

    shutdown -c コマンドは,編集対象ファイルから影響を受けるため,それぞれのメンバを停止させる必要があります (編集ファイルが所定位置に戻された後で clu_get_info -full を実行すると,表示される情報のうちいくつかは,編集結果を反映しています)。

  10. クラスタが停止したら,ネットワーク接続への必要な変更を行います。

  11. クラスタをブートします。

  12. 5.10.3 項の情報を使って,すべてが期待通りに動作しているかどうかを調べます。

  13. /.rhosts/etc/hosts.equiv から無効になったエントリを削除します。

5.10.1    ファイル編集に関する表

この項には,種々の移動用に,一般的なシステム構成ファイルに加える必要のある項目をリストした表があります。

5.10.1.1    外部 IP アドレスだけの変更

一般的な構成ファイルで,クラスタの外部 IP アドレスを変更する場合に必要となる編集項目を示します。

ファイル 編集項目
共用ファイル
/etc/hosts 各クラスタの外部インタフェースとクラスタ別名に関連する IP アドレス。
/etc/networks 定義されていれば,ネットワークのアドレス。
/etc/resolv.conf クラスタが新しいサブネット上で別のネームサーバを使用する場合には,それらのアドレス。
CDSL
/etc/clu_alias.config 各メンバに対して,IP アドレス (可能であれば,サブネット・マスクも含む) によって定義された別名 (おそらく,DEFAULTALIAS エントリは変更不要)。
/etc/inet.local 各メンバに対して,このファイルをインタフェース IP 別名を構成するために使用する場合。
/etc/ntp.conf 各メンバに対して,IP アドレスをサーバやピア・システムのエントリで変更する場合。
/etc/rc.config 各メンバに対して,IFCONFIG エントリ。必要なら,サブネット・マスクを変更する。
/etc/routes 各メンバに対して,ルートが定義されている場合。必要なら,サブネット・マスクを変更する。
メンバ固有 (非 CDSL)
/etc/gated.conf.membern 各メンバに対して,IP アドレスを変更する必要があるエントリ。CLUAMGR_ROUTE_ARGS がメンバの rc.config ファイルで nogated に設定されている場合,メンバの /etc/gated.conf (CDSL) ファイルを変更する。
/cluster/admin/.membern.cfg これらのファイルを使用する場合,IP アドレスへの変更を更新する (使用しない場合,これらのファイルを clu_createclu_add_member で使うときには,旧の値に戻す)。

5.10.1.2    外部 IP アドレスとホスト名の変更

一般的な構成ファイルで,クラスタの外部 IP アドレスとホスト名を変更する必要がある編集項目を示します。

ファイル 編集項目
共用ファイル
/.rhosts 新しいクラスタ名を追加する。エントリを削除しない。
/etc/cfgmgr.auth メンバのホスト名。
/etc/hosts クラスタの外部インタフェースとクラスタ別名に関連する IP アドレス,ホスト名,および別名。
/etc/hosts.equiv 新しいクラスタ名を追加する。エントリを削除しない。
/etc/networks 定義されている場合,ネットワークのアドレス。
/etc/resolv.conf 新しいサブネット上でドメイン名やネームサーバを変更した場合。
CDSL
/etc/clu_alias.config 各メンバに対して,ホスト名や IP アドレス (可能であれば,サブネット・マスクも含む) によって定義された別名 (おそらく,DEFAULTALIAS エントリは変更不要)。
/etc/inet.local 各メンバに対して,このファイルをインタフェース IP 別名を構成するために使用する場合。
/etc/ntp.conf 各メンバに対して,IP アドレスとホスト名をサーバやピア・システムのエントリで変更する場合。
/etc/rc.config 各メンバに対して,HOSTNAMEIFCONFIG,および CLUSTER_NET エントリ。 必要なら,サブネット・マスクを変更する。
/etc/routes 各メンバに対して,ルートが定義されている場合。必要なら,サブネット・マスクを変更する。
/etc/sysconfigtab 各メンバに対して,cluster_namecluster_node_name
メンバ固有 (非 CDSL)
/etc/gated.conf.membern IP アドレスを変更する必要があるエントリ。CLUAMGR_ROUTE_ARGS がメンバの rc.config ファイルで nogated に設定されている場合には,メンバの /etc/gated.conf (CDSL) ファイルを変更する。
/cluster/admin/.membern.cfg これらのファイルを使用する場合,クラスタ名,ホスト名,IP アドレスへの変更を更新する (使用しない場合,これらのファイルを clu_createclu_add_member で使うときには,旧の値に戻す)。

5.10.1.3    外部および内部 IP アドレスとホスト名の変更

一般的な構成ファイルで,クラスタの外部および内部 IP アドレスとホスト名を変更する必要がある編集項目を示します。

ファイル 編集項目
共用ファイル
/.rhosts クラスタ・インターコネクトに関連する新しいクラスタ名と新しいホスト名を追加する。バージョン 5.0A から 5.1 では,*-mc0。バージョン 5.1A 以降では,*-ics0。エントリを削除しない。
/etc/cfgmgr.auth メンバのホスト名。
/etc/hosts クラスタの外部インタフェース,クラスタ別名およびクラスタ・インターコネクトのインタフェースに関連する IP アドレス,ホスト名,および別名。
/etc/hosts.equiv クラスタ・インターコネクトに関連する新しいクラスタ名と新しいホスト名を追加する。バージョン 5.0A から 5.1 では,*-mc0。バージョン 5.1A 以降では,*-ics0。エントリを削除しない。
/etc/networks 定義されていれば,ネットワークのアドレス。
/etc/resolv.conf 新しいサブネット上でドメイン名やネームサーバを変更した場合。
CDSL
/etc/clu_alias.config 各メンバに対して,ホスト名や IP アドレス (可能であれば,サブネット・マスクも含む) によって定義された別名 (おそらく,DEFAULTALIAS エントリは変更不要)。
/etc/ifaccess.conf クラスタ・インターコネクトに関連する IP アドレス。必要なら,サブネット・マスクを変更する。
/etc/inet.local 各メンバに対して,このファイルをインタフェース IP 別名を構成するために使用する場合。
/etc/ntp.conf 各メンバに対して,IP アドレスやホスト名をサーバやピア・システムのエントリで変更する場合 (クラスタ・インターコネクトに関連する名前を変更する場合,それらのピア名の変更を確実に行う)。
/etc/rc.config 各メンバに対して,HOSTNAMEIFCONFIG,および CLUSTER_NET エントリ。必要なら,サブネット・マスクを変更する。
/etc/routes 各メンバに対して,ルートが定義されている場合。必要なら,サブネット・マスクを変更する。
/etc/sysconfigtab 各メンバに対して,cluster_namecluster_node_name,および cluster_node_inter_name の値。
メンバ固有 (非 CDSL)
/etc/gated.conf.membern 各メンバに対して,IP アドレスを変更する必要があるエントリ。CLUAMGR_ROUTE_ARGS がメンバの rc.configファイルで nogated に設定されている場合,メンバの /etc/gated.conf (CDSL) ファイルを変更する。
/cluster/admin/.membern.cfg これらのファイルを使用する場合,クラスタ名,ホスト名,クラスタ・インターコネクト名,および IP アドレスへの変更を更新する (使用しない場合,これらのファイルを clu_createclu_add_member で使うときには,旧の値に戻す)。

5.10.2    属性のチェックリスト表

この項の表を使用して,新しいサブネットにクラスタを移動するのに必要な IP 名とアドレスの情報を記録してください。5 つ以上のクラスタ・メンバ,または 4 つ以上のクラスタ別名がある場合,必要に応じて,該当する表をコピーし,行に名前を書き込んでください。

5.10.2.1    外部ホスト名と IP アドレス

メンバ 属性
メンバ 1 ホスト名  
 
IP アドレス (およびサブネット・マスク)  
 
メンバ 2 ホスト名  
 
IP アドレス (およびサブネット・マスク)  
 
メンバ 3 ホスト名  
 
IP アドレス (およびサブネット・マスク)  
 
メンバ 4 ホスト名  
 
IP アドレス (およびサブネット・マスク)  
 

5.10.2.2    クラスタ名とクラスタ別名

クラスタ別名
完全に修飾されたクラスタ名 (クラスタ名は省略時のクラスタ名)  
 
省略時クラスタ別名 IP アドレス(およびサブネット・マスク)  
 
追加のクラスタ別名 #1  
 
追加のクラスタ別名 #1 の IP アドレス(およびサブネット・マスク)  
 
追加のクラスタ別名 #2  
 
追加のクラスタ別名 #2 の IP アドレス(およびサブネット・マスク)  
 

5.10.2.3    インタフェース IP 別名

メンバ 属性
メンバ 1 IP 別名 #1 (およびサブネット・マスク)  
 
IP 別名 #2 (およびサブネット・マスク)  
 
メンバ 2 IP 別名 #1 (およびサブネット・マスク)  
 
IP 別名 #2 (およびサブネット・マスク)  
 
メンバ 3 IP 別名 #1 (およびサブネット・マスク)  
 
IP 別名 #2 (およびサブネット・マスク)  
 
メンバ 4 IP 別名 #1 (およびサブネット・マスク)  
 
IP 別名 #2 (およびサブネット・マスク)  
 

5.10.2.4    外部サーバ

新しいサブネット上の BIND,NIS,または NTP のようなネットワーク・サービスに別のサーバを使用する場合,次の表の中にこれらのサービスで使用する IP アドレスの新旧を記録してください。

サーバ IP アドレス
   
 
   
 
   
 
   
 

5.10.2.5    チェックリスト

チェックリストの状況欄に,構成ファイルの作業用コピーへの編集の履歴を記録してください。

ファイル 状況
共用ファイル
/.rhosts  
/etc/cfgmgr.auth  
/etc/hosts  
/etc/hosts.equiv  
/etc/networks  
/etc/resolv.conf  
CDSL
/etc/clu_alias.config メンバ 1  
メンバ 2  
メンバ 3  
メンバ 4  
/etc/ifaccess.conf メンバ 1  
メンバ 2  
メンバ 3  
メンバ 4  
/etc/inet.local メンバ 1  
メンバ 2  
メンバ 3  
メンバ 4  
/etc/ntp.conf メンバ 1  
メンバ 2  
メンバ 3  
メンバ 4  
/etc/rc.config メンバ 1  
メンバ 2  
メンバ 3  
メンバ 4  
/etc/routes メンバ 1  
メンバ 2  
メンバ 3  
メンバ 4  
/etc/sysconfigtab メンバ 1  
メンバ 2  
メンバ 3  
メンバ 4  
メンバ固有 (非 CDSL)
/etc/gated.conf.membern メンバ 1  
メンバ 2  
メンバ 3  
メンバ 4  
/cluster/admin/.membern.cfg メンバ 1  
メンバ 2  
メンバ 3  
メンバ 4  

5.10.3    正常性の検証

クラスタを別の IP サブネットへ移動するための手順を適用した後に,正常に実行されたかどうかを検証します。

編集結果がすべて正しく,編集されたファイルが適切な場所に置かれている場合,システムをブートし,クラスタを形成して,新しい稼働環境になります。次のコマンドを使用して,クラスタとそのサブシステムが正しく動作していることを検証します。

hostnameifconfig -anetstat -iclu_get_info -full | morecluamgr -s allcaa_stat
 

pingrlogin,および rpcinfo のような標準的なネットワーク用のコマンドを使用しても,クラスタ・メンバが動作状態であるかどうか,ログインが受け付けられるかどうか,他のシステムと通信できるかどうかを検証できます。

手順が正常に終了しなかった場合,問題の特定と解決についての情報は 5.10.4 項を参照してください。

5.10.4    トラブルシューティング

5.10.3 項に説明されているように,手順が正常に終了しなかった場合は,次の表を使用して問題の特定と解決を図ってください。

問題 解決策
メンバがブートできない。

障害がブート・パスの初期段階で発生した場合,おそらく sysconfigtab ファイルの編集に間違いがある。

1 つのメンバがブートできる場合,ブートできないメンバの boot_partition をマウントし,編集結果を修正する。

どのメンバもブートできない場合,まず,どのメンバもクォーラムが得られず失敗しているのかどうかを調べる。その場合,1 つのメンバに対して対話形式のブートを実行し,期待ボートの値をゼロに設定する。そのメンバをブートして,他のメンバのファイルを修正し,それらのメンバをブートした後,クォーラムの期待ボートを再度調整する。

どのメンバも対話形式でブートできない場合は,Tru64 UNIX オペレーティング・システムをブートし,クラスタの最初のメンバのブート・パーティションをマウントしてそのメンバへの編集結果を修正し,Tru64 UNIX システムを停止したのちに,そのクラスタ・メンバを (必要であれば,対話形式で) ブートして,残りのメンバの編集結果を修正する。

クラスタはブートするがマルチユーザ・モードでネットワークに問題が発生する。 問題を特定し,どのメンバのどのファイルで最も誤った編集があり得るかを判断する。編集結果を修正し,それらのシステム上のネットワーク・サービスを停止して,再開する。
上記の解決策でも,正常にならない。 原本ファイルの保存用コピーで復元する。旧のネットワーク接続を復元する。何が異常かを調査している間,クラスタがクライアントにサービスを続けられるように,旧サブネット上でクラスタをブートする。

5.11    クラスタ名または IP アドレスの変更

この節では,クラスタ名や IP アドレスの変更の方法について説明します。クラスタの名前は省略時のクラスタ別名でもあるので,クラスタ名を変更すると省略時のクラスタ別名も変わります。

クラスタの名前を変更するには,クラスタ全体のシャットダウンとリブートが必要です。クラスタの IP アドレスを変更するには,個々のメンバそれぞれのシャットダウンとリブートが必要です。

5.11.1    クラスタ名の変更

クラスタの名前を変更するには,次の手順を注意して実行します。 間違えると,クラスタがブートできなくなるおそれがあります。

  1. clubase サブシステム・スタンザ・エントリに対する cluster_name 属性を新しくしたファイルを作成します。たとえば,クラスタ名を deli に変更するには,次の clubase サブシステム・スタンザ・エントリに名前を追加します。

    clubase:
     cluster_name=deli
     
    

    注意

    作成したファイルのすべての行末に改行 (LF) があることを確認してください。改行がなければ,sysconfigtab ファイルを変更した場合に,同じ行に属性が 2 つあることになり,システムがブートできなくなるおそれがあります。

    クラスタのルート・ディレクトリにファイルを作成すれば,そのファイルをコピーしなくても,クラスタ内のすべてのシステムで使用できるようになります。

  2. 各クラスタ・メンバで,新しく作成したファイルにある clubase サブシステム属性と /etc/sysconfig ファイルにある clubase サブシステム属性を,sysconfigdb -m -f file clubase コマンドを使用してマージします。

    たとえば,cluster-name-change ファイルに手順 1 の例で示した情報が入っているものとします。cluster-name-change ファイルを使用してクラスタ名を poach から deli に変更するには,次のコマンドを使用します。

    # sysconfigdb -m -f cluster-name-change clubase
    Warning: duplicate attribute in clubase: 
    was cluster_name = poach, now cluster_name = deli
     
    

    警告

    変更する属性が 1 つまたは 2 つしか入っていないファイルを指定して sysconfigdb -u コマンドを実行しないでください。-u フラグの指定により,サブシステム・エントリ (clubase など) が入力ファイルのサブシステム・エントリに置き換わります。そのため,clubase サブシステムに cluster_name 属性だけを指定してこのコマンドを実行すると,新しい clubase サブシステムの内容は cluster_name 属性だけになり,他の必要な属性が消えてしまいます。

  3. 次の各ファイルでクラスタ名を変更します。

    クラスタ内には,これらのファイルが 1 つしかありません。

  4. 新しいクラスタ名を /.rhosts ファイル (すべてのクラスタ・メンバに共通) に追加します。

    ファイル内の現在のクラスタ名は残しておきます。現在の名前は,次の手順で shutdown -c コマンドを実行する際に必要です。

    必要に応じて,クライアントの .rhosts ファイルを変更します。

  5. shutdown -c コマンドを使用してクラスタ全体をシャットダウンし,クラスタ内の各システムをリブートします。

  6. /.rhosts ファイルから以前のクラスタ名を削除します。

  7. 次のように /usr/sbin/clu_get_info コマンドを実行して,クラスタ名が変更されたことを確認します。

    # /usr/sbin/clu_get_info
    Cluster information for cluster deli    
      
    .
    .
    .

5.11.2    クラスタの IP アドレスの変更

クラスタの IP アドレスは,次の手順で変更します。

  1. /etc/hosts ファイルを編集して,クラスタの IP アドレスを変更します。

  2. 一度に 1 つずつ (クォーラムを維持するため),クラスタ・メンバ・システムをシャットダウンしてリブートします。

クラスタに現在入っていないシステムで /usr/sbin/ping コマンドを実行し,クラスタの IP アドレスが変更されたことを確認します。そのクラスタのアドレスを使用したときにクラスタからエコーが返ってくれば,変更されています。

# /usr/sbin/ping -c 3 16.160.160.160
PING 16.160.160.160 (16.160.160.160): 56 data bytes
64 bytes from 16.160.160.160: icmp_seq=0 ttl=64 time=26 ms
64 bytes from 16.160.160.160: icmp_seq=1 ttl=64 time=0 ms
64 bytes from 16.160.160.160: icmp_seq=2 ttl=64 time=0 ms
 
----16.160.160.160 PING Statistics----
3 packets transmitted, 3 packets received, 0% packet loss
round-trip (ms)  min/avg/max = 0/9/26 ms
 

5.12    メンバ名,IP アドレス,クラスタのインターコネクト・アドレスの変更

メンバ名,メンバ IP アドレス,またはクラスタのインターコネクト・アドレスを変更するには,クラスタからメンバを削除し,新しいメンバ名やアドレスを指定して元に戻します。これを行う前に,クラスタがクォーラムを失っていないことと,CAA の restricted 配置ポリシが影響していないことを確認します。

5.12.1    メンバ削除前のクォーラムのチェック

メンバを削除する前に,クラスタのメンバを削除しても問題なく稼働できるように十分な投票メンバ (クォーラム・ディスク・ボートを含む) がクラスタで動作していることを確認します。シングル・クラスタ・メンバのシャットダウンについての情報は,5.5 節を参照してください。

5.12.2    メンバ削除前の CAA の restricted 配置ポリシのチェック

CAA プロファイルで restricted 配置ポリシを使っているかどうかを調べる必要があります。その場合,HOSTING_MEMBERS リソースが,変更したいメンバ・システムの名前だけを含むかどうかを調べる必要があります。

/usr/sbin/caa_profile -print コマンドを使用して,CAA プロファイルを表示します。 アプリケーションの PLACEMENT リソースがアプリケーションに対して制限 (PLACEMENT=restricted) されている場合,および HOSTING_MEMBERS リソースに名前やアドレスを変更するメンバの名前だけが含まれる場合には,次のことを行います。

  1. アプリケーション・リソース・プロファイルを更新して,このアプリケーションを実行できる別のメンバ・システムをメンバ・リストに追加します。たとえば,HOSTING_MEMBERS リソースでメンバの provolone がアプリケーションの実行を制限していることを示している場合,HOSTING_MEMBERS リソースに pepicelli を追加します。この追加は,次のコマンドを実行します。

    # /usr/sbin/caa_profile -update resource_name -h provolone pepicelli
    

    注意

    名前やアドレスを変更するシステムの名前を削除しないでください。

  2. クラスタ・メンバ間での不整合を防ぐために,既存の CAA レジストリ・エントリを最新のリソース・プロファイルで更新します。次のようにコマンドを実行します。

    # /usr/sbin/caa_register resource_name -u
    

  3. HOSTING_MEMBERS リソースに追加されたシステムに,次のコマンドでアプリケーションを再配置します。

    # /usr/sbin/caa_relocate resource_name -c pepicelli
    

5.12.3    メンバの削除と追加

次の手順に従って,既存のライセンス・データを保存し,メンバを削除および追加して,ライセンス・データを復元します。

  1. 変更したいメンバ名,メンバ IP アドレス,またはクラスタ・インターコネクト・アドレスがあるメンバ・システムにログインします。

  2. lmf ユーティリティを使用し,システム上で実行を許可されている製品の PAK (product authorization key) を再構成します。次の例にある KornShell スクリプトは,再構成されたすべての PAK を /licenses ディクショナリに格納します。

    # mkdir /licenses
    # for i in `lmf list | grep -v Product | awk '{print $1}'`
    do
    lmf issue /licenses/$i.license $i
    done
     
    

  3. メンバを停止します。1 つのクラスタ・メンバをシャットダウンする方法については,5.5 節を参照してください。

  4. クラスタのアクティブ・メンバ上で,シャットダウンしたばかりのメンバを削除します。これは,コマンド clu_delete_member を実行して行います。

    # clu_delete_member -m memberid
     
    

    削除するメンバのメンバ ID を知るには,コマンド clu_get_info を使います。

    clu_delete_member の使い方については,5.8 節を参照してください。

  5. コマンド clu_add_member を使って,必要なメンバ名,メンバ IP アドレス,クラスタのインターコネクト・アドレスを指定し,クラスタにシステムを追加して元に戻します。

    クラスタにメンバを追加する方法についての詳細は,TruCluster Server 『クラスタ・インストレーション・ガイド』を参照してください。

  6. 新しく再インストールされたブート・ディスクから genvmunix をブートすると,新しいメンバが自動的にサブセットを構成し,カスタマイズされたカーネルを構築して,マルチユーザ・モードになります。次のように,ログインして保存されたライセンスを登録します。

    # for i in /licenses/*.license
    do
    lmf register - < $i
    done
    # lmf reset
     
    

  7. システムをリブートし,カスタマイズされたクラスタ・カーネルで動作させます。

    # shutdown -r now
    

  8. アプリケーションへの配置ポリシが favored か restricted であり,クラスタ・メンバ・システムで名前が変更されていて,そのアプリケーションに対する HOSTING_MEMBERS リソースにリストされている場合,次のように,リソースの古い名前を削除して新しい名前を追加します。

    1. HOSTING_MEMBERS リソースを変更し,古い名前を削除して新しい名前を追加します。

    2. 最新のリソース・プロファイルで,既存の CAA レジストリを次のように更新します。

      # /usr/sbin/caa_register resource_name -u
      

5.13    ソフトウェア・ライセンスの管理

クラスタに新規メンバを追加したら,そのメンバ上で実行するアプリケーションに関して,そのメンバ上でのアプリケーション・ライセンスを登録しなければなりません。

クラスタへの新規メンバの追加と Tru64 UNIX のライセンス登録については,TruCluster Server 『クラスタ・インストレーション・ガイド』のメンバの追加に関する章を参照してください。

5.14    レイヤード・アプリケーションのインストールと削除

アプリケーションのインストールや削除の手順は,通常,クラスタとスタンドアロン・システムのどちらも同じです。クラスタでは,アプリケーションは 1 回のインストールでかまいません。ただし,一部のアプリケーションでは,さらに手順を要します。

5.15    課金サービスの管理

システムの課金サービスは,クラスタ対応ではありません。このサービスでは,メンバ固有のファイルとデータベースが利用されます。このため,クラスタで課金サービスを利用するには,メンバ単位にサービスの設定や管理を行う必要があります。

/usr/sbin/acct ディレクトリは CDSL です。/usr/sbin/acct における課金サービス・ファイルは各クラスタ・メンバに固有です。

クラスタ上で課金サービスを設定するには,Tru64 UNIX 『システム管理ガイド』のシステムの課金サービスの管理に関する章に記載されている手順に,以下のような変更が加えられます。

  1. すべてのクラスタ・メンバ上で課金サービスを有効にするには,各メンバ上で次のコマンドを入力します。

    # rcmgr -c set ACCOUNTING YES
    

    特定のメンバ上でのみ課金サービスを有効にする場合は,rcmgr コマンドに -h オプションを使用します。たとえば,メンバ 2,3,および 6 で課金サービスを有効にするには,以下のコマンドを入力します。

    # rcmgr -h 2 set ACCOUNTING YES
    # rcmgr -h 3 set ACCOUNTING YES
    # rcmgr -h 6 set ACCOUNTING YES
     
    

  2. 各メンバ上で課金サービスを起動する必要があります。課金サービスを起動したい各メンバにログインして,次のコマンドを入力します。

    # /usr/sbin/acct/startup
    

    メンバ上の課金サービスを停止するには,そのメンバにログインして,コマンド /usr/sbin/acct/shutacct を実行する必要があります。

/usr/spool/cron ディレクトリは CDSL です。また,このディレクトリ内のファイルはメンバに固有であるため,そのファイルを使用して課金サービスをメンバ単位に調整できます。課金サービスを調整するには,課金サービスの実行対象の各メンバにログインします。必要に応じて,crontab コマンドを使用して crontab ファイルを変更します。詳細は,Tru64 UNIX 『システム管理ガイド』のシステムの課金サービスの管理に関する章を参照してください。

/usr/sbin/acct/holidays ファイルは CDSL です。このため,メンバ単位に課金サービスの休止予定を設定します。

課金サービスの詳細については, acct(8) を参照してください。