この章では次の項目について説明します。
構成変数の管理 (5.1 節)
カーネル属性の管理 (5.2 節)
クラスタへのリモート・アクセスの管理 (5.3 節)
クラスタのシャットダウン (5.4 節)
クラスタ・メンバのシャットダウンと起動 (5.5 節)
クラスタのシャットダウンとシングルユーザ・モードへの移行 (5.6 節)
クラスタ・メンバのリブート (5.7 節)
クラスタからのメンバの削除 (5.8 節)
クラスタ・メンバの削除とスタンドアロン・システムとしての復元 (5.9 節)
クラスタ名または IP アドレスの変更 (5.11 節)
別の IP サブネットへのクラスタの移動 (5.10 節)
メンバ名,IP アドレス,またはクラスタ・インターコネクト・アドレスの変更 (5.12 節)
ソフトウェア・ライセンスの管理 (5.13 節)
レイヤード・アプリケーションのインストールと削除 (5.14 節)
課金サービスの管理 (5.15 節)
クラスタ・メンバの管理に関連する次のエントリについては,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
ファイルに記述したクラスタ単位のポリシより優先します。
/etc/rc.config*
ファイルの階層化により,ローカル・エリア・ネットワーク (LAN) 内およびクラスタ内のすべてのシステムの構成変数を一元管理できます。表 5-1
に,各種構成ファイルの有効範囲を示します。
表 5-1: /etc/rc.config* ファイル
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
ファイル内の属性をいくつか設定します。
/etc/sysconfigtab
ファイル内の
subsystem name
スタンザ・エントリの追加または編集を行い,属性の値を変更して,次回のシステム・ブート時に新しい値が有効になるようにします。
次のコマンドを使用して,再設定できる属性の値を変更し,その新しい値が実行時に直ちに有効になるようにします。
# sysconfig -r subsystem-name attribute-list
次回のシステム・ブート時まで変更を保持するには,/etc/sysconfigtab
ファイルも編集しなければなりません。たとえば,drd-print-info
属性の値を 1 に変更するには,次のコマンドを入力します。
# sysconfig -r drd drd-print-info=1 drd-print-info: reconfigured
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 クラスタ内およびクラスタからのリモート・アクセスの管理
クラスタからの
rlogin
,rsh
,または
rcp
コマンドでは,省略時のクラスタ別名が送信元アドレスとして使用されます。したがって,非クラスタ・ホストで,クラスタ内の任意のアカウントからのリモート・ホスト・アクセスを許可しなければならない場合は,非クラスタ・メンバの
.rhosts
ファイルに,/etc/hosts
ファイル内のいずれかの形式,あるいはネットワーク情報サービス (NIS) またはドメイン・ネーム・システム (DNS) で解決できる形式で,クラスタ別名を登録する必要があります。
この要件は,クラスタ・メンバ間で機能する
rlogin
,rsh
,または
rcp
にも適用されます。クラスタ作成時に,clu_create
ユーティリティで,必要なホストすべての名前の入力が求められ,その名前が適切な形式で正しい場所に設定されます。clu_add_member
では,新しいメンバがクラスタに追加されるときに同じ処理が行われます。/.rhosts
を編集しなくても,クラスタ・メンバからクラスタ別名に対して,あるいは個々のメンバ間で
/bin/rsh
コマンドを使用できます。/etc/hosts
と
/.rhosts
内に生成された名前のエントリを変更しないでください。
/etc/hosts
と
/.rhosts
のファイルが間違って構成された場合,多くのアプリケーションは正しく機能しません。たとえば,AdvFS (Advanced File System) の
rmvol
と
addvol
のコマンドでは,そのコマンドが実行されるメンバがドメインのサーバでない場合は,rsh
が使用されます。これらのコマンドは,/etc/hosts
または
/.rhosts
が正しく構成されていない場合には失敗します。
次のエラーは,/etc/hosts
や
/.rhosts
のファイルが間違って構成されたことを示しています。
rsh cluster-alias date Permission denied.
クラスタのすべてのメンバを停止するには,shutdown
コマンドに
-c
オプションを使用します。たとえば,5 分以内にクラスタをシャットダウンするには,次のコマンドを入力します。
# shutdown -c +5 Cluster going down in 5 minutes
クラスタの特定のメンバのシャットダウンについては,5.5 節を参照してください。
シャットダウンの猶予期間内 (クラスタの
shutdown
コマンドが入力されてからシャットダウンが実際に行われるまでの時間),clu_add_member
コマンドは無効であり,新規メンバをクラスタに追加できません。
この猶予期間内にクラスタのシャットダウンを取り消すには,次の手順に従って,shutdown
コマンドに関連付けられたプロセスを強制終了します。
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
のいずれかを表示します。
任意のメンバから,取得した PID を指定して
kill
コマンドを実行することにより,シャットダウン・プロセスをすべて強制終了します。たとえば,次のように入力します。
# kill 14680
猶予期間内にシャットダウン・プロセスを強制終了した場合,シャットダウンが取り消されます。
コマンド
clu_quorum
,clu_add_member
,clu_delete_member
,または
clu_upgrade
が実行中である場合,shutdown -c
コマンドを実行するとエラーが生じます。
クラスタ全体をリブートするコマンドはありません。コマンド
shutdown -r
,reboot
,および
halt
は,それらの実行元のメンバのみに影響します。コマンド
halt
,reboot
,および
init
は,クラスタにマウントされたファイル・システムをアンマウントしないように修正されています。そのためクラスタは,いずれか 1 つのメンバが停止またはリブートされても,クォーラムを維持している限り,稼働し続けます。
詳細は,
shutdown
(8)5.5 クラスタの特定のメンバのシャットダウンと起動
メンバをブートするときは,clu_add_member
コマンドによって作成されたブート・ディスクからブートしなければなりません。ブート・ディスクのコピーからはブートできません。
クラスタの特定のメンバのシャットダウンはスタンドアロン・サーバのシャットダウンより複雑です。クォーラムの維持に必須のボートを持つクラスタ・メンバ (重要な投票メンバと呼びます) を停止した場合,クラスタはクォーラムを失い,ハングアップします。その結果,停止したメンバをリブートするまで,クラスタのどのメンバからもコマンドを入力できません。したがって,クラスタのメンバをシャットダウンする前に,まずそのメンバのボートがクォーラムの維持に必須かどうか調べなければなりません。また,シャットダウンしようとしているクラスタ・メンバが,restricted 配置ポリシで 1 つ以上のアプリケーションの唯一のホスト・メンバかどうかも判断する必要があります。
5.5.1 重要な投票メンバの識別
重要な投票メンバのあるクラスタは,縮退モードで稼働しているか (たとえば,1 つ以上の投票メンバまたは 1 つのクォーラム・ディスクがダウンしている),または最初から可用性を考慮して構成されていません (たとえば,各メンバにボートが割り当てられている 2 メンバ構成)。重要な投票メンバをクラスタから削除すると,クラスタがハングして,可用性が低下します。クラスタ・メンバを停止または削除する前に,重要な投票をしていないことを確認してください。
メンバが重要な投票メンバかどうかを調べるには,次の手順に従います。
可能であれば,クラスタのすべての投票メンバが稼働中であることを確認します。
clu_quorum
コマンドを入力し,問題のメンバの現在のボート,クォーラム・ボート,およびノード・ボートの実行時の値をメモしておきます。
現在のボートの値からメンバのノード・ボートの値を引きます。その結果がクォーラム・ボートの値より小さい場合,そのメンバは重要な投票メンバです。そのメンバをシャットダウンすると,クラスタがクォーラムを失い,ハングします。
重要な投票メンバの停止または削除を行う前に,クォーラムを維持するクラスタでそのボートが必要とされなくなっていることを確認してください。それを確認する最善の方法は,期待ボートを増やさずに,ノード・ボートまたはクォーラム・ディスク・ボートをクラスタにリストアすることです。具体的な方法は,以下のとおりです。
現在停止している投票メンバをブートする。
停止しているメンバのボートを削除 (clu_quorum -f -m
コマンドを使用) し,ボートが 1 のクォーラム・ディスクを構成 (clu_quorum -f -d add
コマンドを使用) する。こうすれば,期待ボートを増やさず,またクォーラム・ボートの値も変えずに,クラスタに現在のボートが追加される。
クラスタのボートが偶数の場合は,新たに投票メンバを追加するか,クォーラム・ディスクを構成すれば,重要な投票メンバを重要でないメンバにすることもできます。このような場合には,期待ボートは増えますが,クォーラム・ボートは変わりません。
5.5.3 重要でないメンバの停止
重要でないメンバ,つまりボートを持たないメンバ,またはクォーラムの維持に必須でないボートを持つメンバは,スタンドアロン・システムのようにシャットダウン,停止,またはリブートできます。
シャットダウンするメンバ上で
shutdown
コマンドを実行します。
メンバを停止するには,次のコマンドを入力します。
# shutdown -h time
メンバをリブートするには,次のコマンドを入力します。
# shutdown -r time
重要な投票メンバの識別については,5.5.1 項を参照してください。
5.5.4 ホスト・メンバのシャットダウン
アプリケーションを実行させるメンバは,CAA (cluster application availability)
プロファイルの中で各ホスト・メンバを空白で区切って指定します。ホスト・メンバのリストは,
caa
(4)
配置ポリシが restricted であるアプリケーションをただ 1 つのホスト・メンバだけがサポートしている場合は,そのクラスタ・メンバをシャットダウンするときに他のホスト・メンバを指定する必要があります。そうしなければ,そのメンバがダウンしている間,アプリケーションを実行できなくなります。こうした場合に備えて,他のホスト・メンバを追加するか,または既存のホスト・メンバを他のメンバに切り換えます。
この処理は次の手順で行います。
現在のホスト・メンバと配置ポリシを確認します。
# caa_profile -print resource-name
シャットダウンするクラスタ・メンバが唯一のホスト・メンバである場合は,ホスト・メンバをリストに追加するか,または既存のホスト・メンバを切り換えます。
# caa_profile -update resource-name -h hosting-member another-hosting-member # caa_profile -update resource-name -h hosting-member
CAA のレジストリ・エントリを最新のリソース・プロファイルで更新します。
# caa_register -u resource-name
アプリケーションを他のメンバに再配置します。
# caa_relocate resource-name -c member-name
5.6 クラスタ・メンバをシャットダウンしてシングルユーザ・モードにする
クラスタ・メンバをシャットダウンしてシングルユーザ・モードにする必要がある場合は,メンバを停止してからシングルユーザ・モードでブートしなければなりません。この方法でメンバをシャットダウンすれば,そのメンバがクラスタに対して提供するサービスを最低限に抑えることができます。また,稼働中のクラスタがシングルユーザ・モードで動作しているメンバに依存する割合も最低にすることができます。特に,クラスタ・メンバの状態を
DOWN
にしてからフェイルオーバを行わなければならないサービスがある場合,メンバを停止することによって,その要件を満たすことができます。クラスタ・メンバを最初に停止しなければ,サービスが期待どおりにフェイルオーバしません。
クラスタ・メンバをシングルユーザ・モードに移行するには,shutdown -h
コマンドを用いてメンバを停止させ,次にメンバをシングルユーザ・モードでブートします。システムがシングルユーザ・モードになったら,init s
,bcheckrc
,および
lmf reset
コマンドを実行します。以下に例を示します。
注意
クラスタ・メンバを停止する前に,そのメンバのボートがなくなってもクラスタがクォーラムを維持できることを確認しておいてください。また,そのクラスタ・メンバが,restricted 配置ポリシで 1 つ以上のアプリケーションの唯一のホスト・メンバでないことも確認してください。
# /sbin/shutdown -h now >>> boot -fl s # /sbin/init s # /sbin/bcheckrc # /usr/sbin/lmf reset
シャットダウンされてシングルユーザ・モードになったクラスタ・メンバ (つまり,停止してからシングルユーザ・モードでブートするという推奨シャットダウン手順を使わなかった場合) は,状態が
UP
のままです。クラスタ・メンバをこのようにシャットダウンしてシングルユーザ・モードにした場合は,そのメンバの投票状態には影響しません。シャットダウンされてシングルユーザ・モードになる前に投票メンバであった場合,そのメンバはシングルユーザ・モードでも引き続き投票メンバになります。
5.7 クラスタ・メンバのリブート
すべてのメンバを同時にリブートしてはなりません。 すべてのクラスタ・メンバを同時にリブートしようとすると,クォーラム喪失のため,1 つまたは複数のメンバがダウンの途中でハングし,他のリブート中のノードが,クラスタに再度加わることができないため,ブートに失敗します (ハング・ノード)。
クラスタ全体をリブートするために使用する方法は,目的によって異なります。
クラスタを停止することなくすべてのクラスタ・ノードをリブートするには,1 度に 1 メンバをリブートして,次のメンバをリブートする前に,リブート中のメンバがクラスタに再加入できるようにします。
注意
クラスタ・メンバをリブートする前に,そのメンバのボートがなくても,クラスタがクォーラムを維持できることを確認します。また,そのクラスタ・メンバが,restricted 配置ポリシで 1 つ以上のアプリケーションの唯一のホスト・メンバでないことも確認してください。
クラスタ全体をリブートするには (クラスタ状態は失われる),shutdown -c
コマンドでクラスタ全体をシャットダウンしたのち,メンバをブートします。
クラスタからメンバを削除するには,clu_delete_member
コマンドを使用します。
警告
TruCluster Server を再インストールする場合は,TruCluster Server 『クラスタ・インストレーション・ガイド』を参照してください。既存クラスタからメンバを削除し,削除したそのメンバから 1 メンバ構成の新規クラスタを作成しないでください。その新規クラスタが既存クラスタと同じ名前の場合,新しくインストールしたシステムが既存クラスタに参加する場合があります。これによってデータの破壊が起こる可能性があります。
clu_delete_member
コマンドの構文は次のとおりです。
/usr/sbin/clu_delete_member
[-f
]
[-m memberid
]
メンバ ID を指定しなかった場合,削除するメンバのメンバ ID が要求されます。
clu_delete_member
コマンドは次の処理を行います。
メンバのブート・パーティションをマウントし,ブート・パーティション内のファイルをすべて削除します。その結果,このシステムはこのディスクからブートできなくなります。
警告
clu_delete_member -f
コマンドは,メンバのブート・ディスクにアクセスできないときでも,そのメンバを削除します。そのため,ブート・ディスクに障害が発生したメンバでも削除できます。ただし,アクセスできないブート・ディスクのメンバを削除すると,clu_delete_member -f
は,(正常なclu_delete_member
コマンドがするようには) 稼働中のクラスタの期待ボートを調整しません。削除されるメンバが投票メンバの場合,期待ボートを適正に調整するように,メンバが削除された後でclu_quorum -e
を使用してください。このコマンドでメンバのブート・ディスクにアクセスできない場合は,クラスタのどのメンバもそのディスクから不用意にブートしないようにする必要があります。そのためには,そのディスクをクラスタから削除するか,再フォーマットするか,
disklabel
コマンドを使って非ブート・ディスクにします。
メンバがボートを持っている場合は,クラスタ単位のクラスタ期待ボートの値を調節します。
クラスタ全体のファイル・システムからメンバ固有のディレクトリとファイルをすべて削除します。
注意
clu_delete_member
コマンドは,ディレクトリ/cluster
,/usr/cluster
および/var/cluster
からメンバ固有のファイルを削除します。ただし,アプリケーションまたは管理者が/usr/local
などのその他のディレクトリ内にメンバ固有のファイルを作成している場合もあります。その場合は,clu_delete_member
の実行後に,これらのファイルを手作業で削除しなければなりません。この作業をしなかった場合は,新規メンバを追加し,同じメンバ ID を再使用すると,新規メンバはこれらの古い (おそらくエラーの原因になる) ファイルにアクセスしてしまいます。
ファイル
/.rhosts
および
/etc/hosts.equiv
から,削除されたメンバのクラスタ・インターコネクト用のホスト名を削除します。
ここまでの処理内容を削除ログ
/cluster/admin/clu_delete_member.log
に書き込みます。付録 C
に削除ログ
clu_delete_member
の例を示しています。
クラスタからメンバを削除するには,次の手順を実行します。
そのメンバがクラスタの重要な投票メンバかどうかを調べます。そのメンバがクラスタに重要なボートを投じる場合,そのメンバを停止すると,クラスタはクォーラムを失い,動作が中断されます。メンバを停止する前に,5.5 節の手順に従って,そのメンバを停止しても安全かどうかを調べます。
また,5.5.4 項で説明しているように,そのクラスタ・メンバが restricted 配置ポリシで 1 つ以上のアプリケーションの唯一のホスト・メンバかどうかも判断する必要があります。
削除するメンバを停止します。
可能であれば,クラスタのすべての投票メンバが稼働中であることを確認します。
別のメンバから
clu_delete_member
コマンドを使って,そのメンバをクラスタから削除します。たとえば,停止したメンバのメンバ ID が 3 であり,そのメンバを削除するには,次のコマンドを入力します。
# clu_delete_member -m 3
clu_delete_member
の実行時に,メンバのブート・ディスクがアクセスできない場合は,その旨を通知するメッセージを表示して,終了します。
たとえ,メンバのブート・ディスクにアクセスできないとしても,-f オプションの指定で,強制的にメンバを削除できます。この場合,削除されるメンバが投票メンバなら,メンバが削除された後にクラスタの期待ボートを手動で 1 ボート低くする必要があります。これは,次のコマンドで行います。
# clu_quorum -e expected-votes
メンバ削除時のログ・ファイル
/cluster/admin/clu_delete_member.log
の例については,付録 C
を参照してください。
5.9 クラスタからのメンバの削除とスタンドアロン・システムとしての復元
スタンドアロン・システムとしてクラスタのメンバを復元するには,次の手順を実行します。
停止したメンバをクラスタから物理的に切断し,クラスタ・インターコネクトとストレージを切断します。
停止したメンバ上で,このメンバのローカル・ディスクを選択し,Tru64 UNIX をインストールします。システム・ソフトウェアのインストールについては,Tru64 UNIX 『インストレーション・ガイド』マニュアルを参照してください。
非クラスタ化システムへのクラスタ化 LSM (Logical Storage Manager) ボリュームの移動については,Tru64 UNIX 『Logical Storage Manager』を参照してください。
5.10 別の IP サブネットへのクラスタの移動
この節では 1 つの IP サブネットから別の IP サブネットへのクラスタの移動方法について説明します。通常,クラスタの外部 IP アドレスが別の IP サブネットを指すようにサイトのネットワーク・トポロジの再構成を行うときにだけ必要となります。
増大する複雑さを回避するために,クラスタを別の IP サブネットに移動する場合には,次の項目を変更する必要があります。
クラスタの外部ネットワーク・インタフェース,インタフェースの IP 別名,およびクラスタ別名に関連した IP アドレス
クラスタの外部ネットワーク・インタフェース,インタフェースの IP 別名,およびクラスタ別名に関連した IP アドレスとホスト名
クラスタの外部ネットワーク・インタフェース,インタフェースの IP 別名,およびクラスタ別名に関連した IP アドレスとホスト名,および 内部のクラスタ・インターコネクトと関連した IP アドレスとインタフェース名
注意
クラスタ管理を簡単にするため,メンバの外部ホスト名を変更した場合,メンバのクラスタ・インターコネクト名のホスト部分も変更したくなります。しかし,クラスタ・インターコネクトに使用されるネットワークがクラスタ専用であるため,クラスタ・インターコネクトで使われる IP 名とアドレスを変更せずに別のネットワークにクラスタを再配置することができます。この方法については,十分な情報が提供されています。メンバのホスト名とクラスタ・インターコネクト名のホスト名部分を一致させるかどうかはユーザ次第です。
この節には,情報収集と移動の実行の際に使用する表が用意されています。この表では,3 つの移動方法に対してそれぞれ必要とされるファイルの編集方法について説明しています。計画している移動方法に該当する表を使用してください。5.10.2 項は移動を開始する前の情報収集に役立ち,このチェックリストは編集の履歴を残せます。
この手順を用いる前に,次の要件に注意してください。
クラスタ単位のリブートが必要です。
システム構成ファイルは注意深く編集する必要があります。これらのファイルの中にはコンテキスト依存シンボリック・リンク (CDSL) のものがあります。各クラスタ・メンバのターゲット・ファイルを編集する必要があり,ファイルをコピーするときには
mv
よりむしろ
cp
を使用するようにしてください。mv
を使うと,CDSL のターゲットにファイルをコピーせず CDSL に上書きします。
ファイルを編集またはコピーするときには,クラスタをブートして形成する際にクラスタ・メンバが停止するような間違いをする可能性があります。更新したファイルを正しい位置に置いてクラスタを停止させる前に,編集結果を 2 度確認してください。
IP アドレスを変更すると,そのアドレスと関連付けられているサブネット・マスクも変更する必要があります。
この節で説明する表と手順では,ホスト名と IP アドレスを含む最も一般的なシステム構成ファイルを扱っています。ホスト名,クラスタ別名,インタフェース IP 別名,またはサブネット・マスクを含む,CAA (cluster application availability) スクリプトまたはネットワーク・リソースのような,他のすべてのファイルを見直して,編集する必要があります。
クラスタを別の IP サブネットに移動するには,次の手順を実行します。
移動のために必要となる IP 名とアドレスを取得します。この情報を記録するために
5.10.2 項の表を使用します。移動のために必要なサブネット・マスクのすべての変更を記録します。移動した結果,クラスタが別のネームサーバを使う場合,/etc/resolv.conf
ファイルに加える変更を記録します。
この移動が物理的なネットワーク接続の変更を要する場合,新しい物理的なネットワーク接続が適切で,使用できる状態にあることを確認します。
いつ移動を実行するかを,ユーザ,他のクラスタ,およびネットワーク管理者に知らせます。他のシステムやクラスタが変更を計画している IP 名とアドレスに依存している場合,それらの管理者と連携をとる必要があります。たとえば,NIS,DNS,またはメール・サーバが影響を受けます。クラスタが,停止してはならないサービスを実行中であれば,クラスタがシャットダウンしている間にサービスを実行する,別のシステムやクラスタを準備します。
現在のクラスタの IP 名とアドレスが共通のシステム構成ファイル中で使用されている場所を調べます。これを実行する 1 つの方法は,clu_get_info
を使用し,現在のクラスタの情報を取得した後,grep
を使用して共通のシステム構成ファイル内で情報を探します。
ホスト名,IP アドレス,クラスタ別名,インタフェース IP 別名,名前の別名,またはサブネット・マスクを含む可能性のある CAA スクリプト・ファイルのようなすべてのファイルを探します。
更新しようとする構成ファイルの保存用,作業用の両方のファイルを作成します。
注意
CAA スクリプトやサイト固有のスクリプトが変更対象の IP アドレス,ホスト名,別名,またはサブネット・マスクを参照する場合,それらのファイルのコピーを作り,それらに加えた変更の履歴を残しておいてください。
計画している変更に該当する表を使用します。
外部 IP アドレスだけの変更 (5.10.1.1 項)
外部 IP アドレスとホスト名の変更 (5.10.1.2 項)
外部および内部 IP アドレスとホスト名の変更 (5.10.1.3 項)
表の情報を使用して,原本ではなくコピーの作業ファイルを編集します。CDSL では,メンバ固有のディレクトリ内の作業ファイルを編集することを覚えておいてください。
注意
sysman
を使うか,またはエディタを使うかは自由です。正しく編集をすることが重要です。作業ファイルから原本ファイルの位置へコピーし,すべてのクラスタ・メンバを停止する前に,情報が正しいことを 100 パーセント確実にする必要があります。作業ファイルを編集する場合,新しいサブネット上のサブネット・マスクが現在のサブネット用のものと同じでないなら,それらを編集することを覚えておいてください。
/.rhosts
や/etc/hosts.equiv
作業ファイルを編集する場合,新しいホスト名を追加しますが,そこに現在リストされているものを削除しないでください。新しいサブネットでクラスタが正常にブートできた後,旧ホスト名を削除してください。
編集をすべて終えた後で,作業ファイルと原本ファイルの内容を比較します。編集内容を見直してください。
すべての編集内容の確認がとれた後,次のことを実施します。
影響を受ける全員にメッセージを送ります。いつクラスタへのアクセスが無効になる予定か,いつ実際の移動を開始するのかを知らせます。
ログインとすべての外部ネットワーク・インタフェースを無効にします。たとえば,wall -c
コマンドを使って,ユーザにすぐにログインが無効になることを知らせ,touch
コマンドを使って,/etc/nologin
ファイルを作成し,各メンバで
rcinet stop
コマンドを使ってそのメンバ上のネットワークを停止させます。
原本のファイル位置に作業ファイルをコピーします。編集後のファイルで置き換えた各ファイルの履歴を残しておいてください (更新した他のすべてのファイルの履歴も残しておいてください)。
編集した構成ファイルがすべて適切な位置に置かれた後で,すべての情報が正しいことを確認します。クラスタをシャットダウンした後のリブートの成否は編集結果によります。移動を必要とした変更範囲を考慮して,次の項目のうちいくつかあるいは全部が正しく変更されていることを確認します。
IP アドレス,インタフェース IP 別名,およびサブネット・マスク
ホスト名と名前の別名
省略時のクラスタ別名とその他のクラスタ別名
クラスタの各メンバを停止します。たとえば,各メンバ上で次のコマンドを実行します。
# shutdown -h now
注意
shutdown -c
コマンドは,編集対象ファイルから影響を受けるため,それぞれのメンバを停止させる必要があります (編集ファイルが所定位置に戻された後でclu_get_info -full
を実行すると,表示される情報のうちいくつかは,編集結果を反映しています)。
クラスタが停止したら,ネットワーク接続への必要な変更を行います。
クラスタをブートします。
5.10.3 項の情報を使って,すべてが期待通りに動作しているかどうかを調べます。
/.rhosts
と
/etc/hosts.equiv
から無効になったエントリを削除します。
この項には,種々の移動用に,一般的なシステム構成ファイルに加える必要のある項目をリストした表があります。
外部 IP アドレスだけの変更 (5.10.1.1 項)
外部 IP アドレスとホスト名の変更 (5.10.1.2 項)
外部および内部 IP アドレスとホスト名の変更 (5.10.1.3 項)
一般的な構成ファイルで,クラスタの外部 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_create
や
clu_add_member
で使うときには,旧の値に戻す)。 |
一般的な構成ファイルで,クラスタの外部 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 |
各メンバに対して,HOSTNAME ,IFCONFIG ,および
CLUSTER_NET
エントリ。
必要なら,サブネット・マスクを変更する。 |
/etc/routes |
各メンバに対して,ルートが定義されている場合。必要なら,サブネット・マスクを変更する。 |
/etc/sysconfigtab |
各メンバに対して,cluster_name
と
cluster_node_name 。 |
メンバ固有 (非 CDSL) | |
/etc/gated.conf.membern |
IP アドレスを変更する必要があるエントリ。CLUAMGR_ROUTE_ARGS
がメンバの
rc.config
ファイルで
nogated
に設定されている場合には,メンバの
/etc/gated.conf
(CDSL) ファイルを変更する。 |
/cluster/admin/.membern.cfg |
これらのファイルを使用する場合,クラスタ名,ホスト名,IP アドレスへの変更を更新する (使用しない場合,これらのファイルを
clu_create
や
clu_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 |
各メンバに対して,HOSTNAME ,IFCONFIG ,および
CLUSTER_NET
エントリ。必要なら,サブネット・マスクを変更する。 |
/etc/routes |
各メンバに対して,ルートが定義されている場合。必要なら,サブネット・マスクを変更する。 |
/etc/sysconfigtab |
各メンバに対して,cluster_name ,cluster_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_create
や
clu_add_member
で使うときには,旧の値に戻す)。 |
この項の表を使用して,新しいサブネットにクラスタを移動するのに必要な IP 名とアドレスの情報を記録してください。5 つ以上のクラスタ・メンバ,または 4 つ以上のクラスタ別名がある場合,必要に応じて,該当する表をコピーし,行に名前を書き込んでください。
5.10.2.1 外部ホスト名と IP アドレス
メンバ | 属性 | 値 | |
メンバ 1 | ホスト名 | 旧 | |
新 | |||
IP アドレス (およびサブネット・マスク) | 旧 | ||
新 | |||
メンバ 2 | ホスト名 | 旧 | |
新 | |||
IP アドレス (およびサブネット・マスク) | 旧 | ||
新 | |||
メンバ 3 | ホスト名 | 旧 | |
新 | |||
IP アドレス (およびサブネット・マスク) | 旧 | ||
新 | |||
メンバ 4 | ホスト名 | 旧 | |
新 | |||
IP アドレス (およびサブネット・マスク) | 旧 | ||
新 |
クラスタ別名 | 値 | |
完全に修飾されたクラスタ名 (クラスタ名は省略時のクラスタ名) | 旧 | |
新 | ||
省略時クラスタ別名 IP アドレス(およびサブネット・マスク) | 旧 | |
新 | ||
追加のクラスタ別名 #1 | 旧 | |
新 | ||
追加のクラスタ別名 #1 の IP アドレス(およびサブネット・マスク) | 旧 | |
新 | ||
追加のクラスタ別名 #2 | 旧 | |
新 | ||
追加のクラスタ別名 #2 の IP アドレス(およびサブネット・マスク) | 旧 | |
新 |
メンバ | 属性 | 値 | |
メンバ 1 | IP 別名 #1 (およびサブネット・マスク) | 旧 | |
新 | |||
IP 別名 #2 (およびサブネット・マスク) | 旧 | ||
新 | |||
メンバ 2 | IP 別名 #1 (およびサブネット・マスク) | 旧 | |
新 | |||
IP 別名 #2 (およびサブネット・マスク) | 旧 | ||
新 | |||
メンバ 3 | IP 別名 #1 (およびサブネット・マスク) | 旧 | |
新 | |||
IP 別名 #2 (およびサブネット・マスク) | 旧 | ||
新 | |||
メンバ 4 | IP 別名 #1 (およびサブネット・マスク) | 旧 | |
新 | |||
IP 別名 #2 (およびサブネット・マスク) | 旧 | ||
新 |
新しいサブネット上の BIND,NIS,または NTP のようなネットワーク・サービスに別のサーバを使用する場合,次の表の中にこれらのサービスで使用する IP アドレスの新旧を記録してください。
サーバ | IP アドレス | |
旧 | ||
新 | ||
旧 | ||
新 | ||
旧 | ||
新 | ||
旧 | ||
新 |
チェックリストの状況欄に,構成ファイルの作業用コピーへの編集の履歴を記録してください。
ファイル | 状況 | |
共用ファイル | ||
/.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 |
クラスタを別の IP サブネットへ移動するための手順を適用した後に,正常に実行されたかどうかを検証します。
編集結果がすべて正しく,編集されたファイルが適切な場所に置かれている場合,システムをブートし,クラスタを形成して,新しい稼働環境になります。次のコマンドを使用して,クラスタとそのサブシステムが正しく動作していることを検証します。
# hostname # ifconfig -a # netstat -i # clu_get_info -full | more # cluamgr -s all # caa_stat
ping
,rlogin
,および
rpcinfo
のような標準的なネットワーク用のコマンドを使用しても,クラスタ・メンバが動作状態であるかどうか,ログインが受け付けられるかどうか,他のシステムと通信できるかどうかを検証できます。
手順が正常に終了しなかった場合,問題の特定と解決についての情報は
5.10.4 項を参照してください。
5.10.4 トラブルシューティング
5.10.3 項に説明されているように,手順が正常に終了しなかった場合は,次の表を使用して問題の特定と解決を図ってください。
問題 | 解決策 |
メンバがブートできない。 | 障害がブート・パスの初期段階で発生した場合,おそらく
1 つのメンバがブートできる場合,ブートできないメンバの
どのメンバもブートできない場合,まず,どのメンバもクォーラムが得られず失敗しているのかどうかを調べる。その場合,1 つのメンバに対して対話形式のブートを実行し,期待ボートの値をゼロに設定する。そのメンバをブートして,他のメンバのファイルを修正し,それらのメンバをブートした後,クォーラムの期待ボートを再度調整する。 どのメンバも対話形式でブートできない場合は,Tru64 UNIX オペレーティング・システムをブートし,クラスタの最初のメンバのブート・パーティションをマウントしてそのメンバへの編集結果を修正し,Tru64 UNIX システムを停止したのちに,そのクラスタ・メンバを (必要であれば,対話形式で) ブートして,残りのメンバの編集結果を修正する。 |
クラスタはブートするがマルチユーザ・モードでネットワークに問題が発生する。 | 問題を特定し,どのメンバのどのファイルで最も誤った編集があり得るかを判断する。編集結果を修正し,それらのシステム上のネットワーク・サービスを停止して,再開する。 |
上記の解決策でも,正常にならない。 | 原本ファイルの保存用コピーで復元する。旧のネットワーク接続を復元する。何が異常かを調査している間,クラスタがクライアントにサービスを続けられるように,旧サブネット上でクラスタをブートする。 |
この節では,クラスタ名や IP アドレスの変更の方法について説明します。クラスタの名前は省略時のクラスタ別名でもあるので,クラスタ名を変更すると省略時のクラスタ別名も変わります。
クラスタの名前を変更するには,クラスタ全体のシャットダウンとリブートが必要です。クラスタの IP アドレスを変更するには,個々のメンバそれぞれのシャットダウンとリブートが必要です。
5.11.1 クラスタ名の変更
クラスタの名前を変更するには,次の手順を注意して実行します。 間違えると,クラスタがブートできなくなるおそれがあります。
clubase
サブシステム・スタンザ・エントリに対する
cluster_name
属性を新しくしたファイルを作成します。たとえば,クラスタ名を
deli
に変更するには,次の
clubase
サブシステム・スタンザ・エントリに名前を追加します。
clubase: cluster_name=deli
注意
作成したファイルのすべての行末に改行 (LF) があることを確認してください。改行がなければ,
sysconfigtab
ファイルを変更した場合に,同じ行に属性が 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
属性だけになり,他の必要な属性が消えてしまいます。
次の各ファイルでクラスタ名を変更します。
/etc/hosts
/etc/hosts.equiv
クラスタ内には,これらのファイルが 1 つしかありません。
新しいクラスタ名を
/.rhosts
ファイル (すべてのクラスタ・メンバに共通) に追加します。
ファイル内の現在のクラスタ名は残しておきます。現在の名前は,次の手順で
shutdown -c
コマンドを実行する際に必要です。
必要に応じて,クライアントの
.rhosts
ファイルを変更します。
shutdown -c
コマンドを使用してクラスタ全体をシャットダウンし,クラスタ内の各システムをリブートします。
/.rhosts
ファイルから以前のクラスタ名を削除します。
次のように
/usr/sbin/clu_get_info
コマンドを実行して,クラスタ名が変更されたことを確認します。
# /usr/sbin/clu_get_info Cluster information for cluster deli
.
.
.
クラスタの IP アドレスは,次の手順で変更します。
/etc/hosts
ファイルを編集して,クラスタの IP アドレスを変更します。
一度に 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
リソースに名前やアドレスを変更するメンバの名前だけが含まれる場合には,次のことを行います。
アプリケーション・リソース・プロファイルを更新して,このアプリケーションを実行できる別のメンバ・システムをメンバ・リストに追加します。たとえば,HOSTING_MEMBERS
リソースでメンバの
provolone
がアプリケーションの実行を制限していることを示している場合,HOSTING_MEMBERS
リソースに
pepicelli
を追加します。この追加は,次のコマンドを実行します。
# /usr/sbin/caa_profile -update resource_name -h provolone pepicelli
注意
名前やアドレスを変更するシステムの名前を削除しないでください。
クラスタ・メンバ間での不整合を防ぐために,既存の CAA レジストリ・エントリを最新のリソース・プロファイルで更新します。次のようにコマンドを実行します。
# /usr/sbin/caa_register resource_name -u
HOSTING_MEMBERS
リソースに追加されたシステムに,次のコマンドでアプリケーションを再配置します。
# /usr/sbin/caa_relocate resource_name -c pepicelli
次の手順に従って,既存のライセンス・データを保存し,メンバを削除および追加して,ライセンス・データを復元します。
変更したいメンバ名,メンバ IP アドレス,またはクラスタ・インターコネクト・アドレスがあるメンバ・システムにログインします。
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
メンバを停止します。1 つのクラスタ・メンバをシャットダウンする方法については,5.5 節を参照してください。
クラスタのアクティブ・メンバ上で,シャットダウンしたばかりのメンバを削除します。これは,コマンド
clu_delete_member
を実行して行います。
# clu_delete_member -m memberid
削除するメンバのメンバ ID を知るには,コマンド
clu_get_info
を使います。
clu_delete_member
の使い方については,5.8 節を参照してください。
コマンド
clu_add_member
を使って,必要なメンバ名,メンバ IP アドレス,クラスタのインターコネクト・アドレスを指定し,クラスタにシステムを追加して元に戻します。
クラスタにメンバを追加する方法についての詳細は,TruCluster Server 『クラスタ・インストレーション・ガイド』を参照してください。
新しく再インストールされたブート・ディスクから
genvmunix
をブートすると,新しいメンバが自動的にサブセットを構成し,カスタマイズされたカーネルを構築して,マルチユーザ・モードになります。次のように,ログインして保存されたライセンスを登録します。
# for i in /licenses/*.license do lmf register - < $i done # lmf reset
システムをリブートし,カスタマイズされたクラスタ・カーネルで動作させます。
# shutdown -r now
アプリケーションへの配置ポリシが favored か restricted であり,クラスタ・メンバ・システムで名前が変更されていて,そのアプリケーションに対する
HOSTING_MEMBERS
リソースにリストされている場合,次のように,リソースの古い名前を削除して新しい名前を追加します。
HOSTING_MEMBERS
リソースを変更し,古い名前を削除して新しい名前を追加します。
最新のリソース・プロファイルで,既存の CAA レジストリを次のように更新します。
# /usr/sbin/caa_register resource_name -u
クラスタに新規メンバを追加したら,そのメンバ上で実行するアプリケーションに関して,そのメンバ上でのアプリケーション・ライセンスを登録しなければなりません。
クラスタへの新規メンバの追加と Tru64 UNIX のライセンス登録については,TruCluster Server 『クラスタ・インストレーション・ガイド』のメンバの追加に関する章を参照してください。
5.14 レイヤード・アプリケーションのインストールと削除
アプリケーションのインストールや削除の手順は,通常,クラスタとスタンドアロン・システムのどちらも同じです。クラスタでは,アプリケーションは 1 回のインストールでかまいません。ただし,一部のアプリケーションでは,さらに手順を要します。
アプリケーションのインストール
アプリケーションにメンバ固有の構成要件が適用される場合は,アプリケーションが動作する各メンバにログインしてアプリケーションを構成する必要があります。詳細は,アプリケーションの構成マニュアルを参照してください。
アプリケーションの削除
setld
を使用してアプリケーションを削除する前に,そのアプリケーションが実行中でないことを確認してください。確認するには,いくつかのメンバ上のアプリケーションを停止させる必要があるかもしれません。たとえば,マルチ・インスタンス・アプリケーションの場合,アプリケーションを停止させると複数のクラスタ・メンバ上で起動中のデーモンを強制終了させてしまう可能性があります。
CAA で管理されているアプリケーションの場合は,次のコマンドを使用して高可用性アプリケーションの状態を確認します。
# caa_stat
削除対象のアプリケーションが実行中 (STATE=ONLINE
) の場合は,それを停止して,次のコマンドで CAA レジストリから削除します。
# caa_stop application_name # caa_unregister application_name
アプリケーションが停止すれば,それを
setld
コマンドで削除します。そのアプリケーションのマニュアルに指示が記載されている場合は,それに従ってください。アプリケーションが現在利用できないメンバ上にインストールされている場合は,そのメンバがクラスタに参加すると,アプリケーションは利用できないメンバから自動的に削除されます。
システムの課金サービスは,クラスタ対応ではありません。このサービスでは,メンバ固有のファイルとデータベースが利用されます。このため,クラスタで課金サービスを利用するには,メンバ単位にサービスの設定や管理を行う必要があります。
/usr/sbin/acct
ディレクトリは CDSL です。/usr/sbin/acct
における課金サービス・ファイルは各クラスタ・メンバに固有です。
クラスタ上で課金サービスを設定するには,Tru64 UNIX 『システム管理ガイド』のシステムの課金サービスの管理に関する章に記載されている手順に,以下のような変更が加えられます。
すべてのクラスタ・メンバ上で課金サービスを有効にするには,各メンバ上で次のコマンドを入力します。
# 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
各メンバ上で課金サービスを起動する必要があります。課金サービスを起動したい各メンバにログインして,次のコマンドを入力します。
# /usr/sbin/acct/startup
メンバ上の課金サービスを停止するには,そのメンバにログインして,コマンド
/usr/sbin/acct/shutacct
を実行する必要があります。
/usr/spool/cron
ディレクトリは CDSL です。また,このディレクトリ内のファイルはメンバに固有であるため,そのファイルを使用して課金サービスをメンバ単位に調整できます。課金サービスを調整するには,課金サービスの実行対象の各メンバにログインします。必要に応じて,crontab
コマンドを使用して
crontab
ファイルを変更します。詳細は,Tru64 UNIX 『システム管理ガイド』のシステムの課金サービスの管理に関する章を参照してください。
/usr/sbin/acct/holidays
ファイルは CDSL です。このため,メンバ単位に課金サービスの休止予定を設定します。
課金サービスの詳細については,
acct
(8)