この章では次の項目について説明します。
ここでは,クラスタの日常の運用時に生じるおそれのある問題の解決策について説明します。
11.1.1 ライセンスなしのシステムのブート
TruCluster Server ライセンスのないシステムをブートできます。このシステムはクラスタに参加し,マルチユーザ・モードでブートしますが,root のみ (最大 2 ユーザ) がログインできます。CAA (Cluster Application Availability) デーモン
caad
は起動されません。システムから,ライセンスの登録を通知するライセンス・エラー・メッセージが表示されます。このような方法でライセンス・チェックが実施され,緊急時のシステムに対するブート,ライセンス設定,および修復を行うことができるようになります。
11.1.2 メンバが動作したままになるシャットダウン
クラスタ・シャットダウン (shutdown -c
) で 1 つ以上のメンバが動作したままになる場合があります。このような場合は,すべてのメンバをシャットダウンしてクラスタ・シャットダウンを完了しなければなりません。
各メンバに対するボートが 1 でクォーラム・ディスクなしの 3 メンバ・クラスタが構成されているとします。クラスタ・シャットダウンの間に,最後から 2 番目のメンバが停止すると,クォーラムを喪失します。クォーラム・チェックが有効になっている場合は,動作中の最後のメンバは処理がすべて中断され,クラスタ・シャットダウンが完了しません。
このような状況での手詰まりを回避するために,クラスタ・シャットダウン・プロセスの起動時にクォーラム・チェックが無効にされます。クラスタ・シャットダウンの間にメンバがシャットダウンできなかった場合,そのメンバは正常に機能しているクラスタ・メンバのように見えますが,そうではありません。この理由は,クォーラム・チェックが無効になっているためです。したがって,手動でシャットダウン・プロセスを完了しなければなりません。
このシャットダウン手順は,引き続き稼働しているシステムの状態によって次のように異なります。
システムがハングしており,コンソールからのコマンドを処理できない場合は,システムを停止してクラッシュ・ダンプを生成します。
システムがハングしていない場合は,/sbin/halt
を使用してシステムを停止します。
envconfig
コマンド
(
envconfig
(8)ENVMON_SHUTDOWN_SCRIPT
変数が含まれています。この変数には,シャットダウンする状況になったとき,envmond
デーモンを実行するユーザ定義スクリプトへのパスを指定します。クラスタでこのスクリプトを使う場合,スクリプトを実行した後,クラスタがクォーラムを失わないようにする必要があります。作成する
ENVMON_SHUTDOWN_SCRIPT
スクリプトでは,シャットダウンするとメンバがクォーラムを失うことになるかどうかを確実に調べる必要があります。クォーラムを失う場合には,残りのクラスタ・メンバをシャットダウンします。
たとえば,5 つのメンバで構成されるクラスタがあるとします。また,すべてのクラスタ・メンバが同じコンピュータ室に配置されていて,空調設備が故障したとします。気温がシステムの許容限度を超えた場合,クラスタ・メンバはそれぞれで気温が高すぎることを感知し,ENVMON_SHUTDOWN_SCRIPT
スクリプトを呼び出します。3 番目のメンバがクラスタを離脱したときに,クラスタはクォーラムを失い (クォーラム・ボート = (クラスタ期待ボート + 2) / 2 (小数点以下切捨て)),2 つの残りのメンバがすべての処理を停止します。その結果として,これらの残りのメンバが過熱した研究室の中で稼働し続けます。
クラスタ・メンバの喪失がクォーラムの喪失の原因になる場合,残りのクラスタ・メンバをシャットダウンします。
ENVMON_SHUTDOWN_SCRIPT
スクリプトはすべてのケースで
shutdown -c
を使用してシャットダウンを実行できますが,この方法は推奨できません。
次のサンプル・スクリプトは,現在のメンバをシャットダウンすると,クォーラムを失うことになるかどうかを判定します。
#!/usr/bin/ksh -p # typeset currentVotes=0 typeset quorumVotes=0 typeset nodeVotes=0 clu_get_info -q is_cluster=$? if [ "$is_cluster" = 0 ] then # The following code checks whether it is safe to shut down # another member. It is considered safe if # the cluster would not lose quorum if a member shuts down. # If it's not safe, shut down the entire cluster. currentVotes=$(sysconfig -q cnx current_votes | \ sed -n 's/current_votes.* //p') quorumVotes=$(sysconfig -q cnx quorum_votes | \ sed -n 's/quorum_votes.* //p') nodeVotes=$(sysconfig -q cnx node_votes | \ sed -n 's/node_votes.* //p') # Determine if this node is a voting member if [ "$nodeVotes" -gt 0 ] then # It's a voting member, see if we'll lose quorum. if [[ $((currentVotes-1)) -ge ${quorumVotes} ]] then echo "shutdown -h now..." else echo "shutdown -c now..." fi else echo "This member has no vote...shutdown -h now..." fi else # not in a cluster...nothing to do exit 0 fi
システムのブート時にクラスタ単位のルート (/
) が初めてマウントされると,CFS で次の警告メッセージが生成される場合があります。
"WARNING:cfs_read_advfs_quorum_data: cnx_disk_read failed with error-number
通常は,error-number
は
EIO
の値です。
このメッセージには,次のメッセージが伴います。
"WARNING: Magic number on ADVFS portion of CNX partition on quorum disk \ is not valid"
これらのメッセージは,ブート・メンバによる,クォーラム・ディスクの CNX パーティションのデータへのアクセスで問題が生じていることを示しています。メッセージには,cluster_root
ドメインのデバイス情報も含まれています。メッセージが表示されるのは,ブート・メンバがクォーラム・ディスクにアクセスできない場合で,その理由はクラスタが意図的にこのように構成されているか,またはパスの障害のどちらかです。前者の理由の場合,メッセージを情報とみなすことができます。後者の理由の場合は,パスの障害の原因に対して処置を講ずる必要があります。
メッセージは,クォーラム・ディスク自体に問題があることを示す場合があります。クォーラム・ディスクのハードウェア・エラーもレポートされている場合は,そのディスクを交換してください。クォーラム・ディスクの交換については,4.5.1 項を参照してください。
エラー番号については,
errno
(5)EIO
については,
errno
(2)11.1.5 メンバのブート・ディスクのバックアップと修復
メンバのブート・ディスクには,3 つのパーティションがあります。 表 11-1 は,このパーティションの詳細を示しています。
注意
メンバのブート・パーティションにファイルセットを追加することは禁止しませんが,推奨しません。メンバがクラスタを離脱する場合,メンバのブート・パーティションからマウントされたすべてのファイルセットは,強制的にアンマウントされ,再配置することはできません。
パーティション | 内容 |
a |
AdvFS (Advanced File System) ブート・パーティション,メンバ・ルート・ファイル・システム |
b |
スワップ・パーティション (a
と
h
のパーティションの間の全領域) |
h |
CNX バイナリ・パーティション AdvFS と LSM (Logical Storage Manager) では,それぞれが機能するために重要な情報が
|
メンバのブート・ディスクが破損している場合や利用できなくなった場合は,クラスタにメンバをリストアするために
h
パーティションの情報が必要です。clu_bdmgr
コマンドを使用すれば,メンバ・ブート・ディスクを構成して,メンバ・ブート・ディスクに関するデータの保存やリストアを行うことができます。
clu_bdmgr
コマンドを使用して,次の作業を行うことができます。
新しいメンバ・ブート・ディスクを構成する。
メンバ・ブート・ディスクの
h
パーティション上の情報をバックアップする。
ファイルからのデータ,または現在利用可能なメンバのブート・ディスクの
h
パーティションからのデータで
h
パーティションを修復する。
このコマンドの詳細は,
clu_bdmgr
(8)
メンバがブートするときは必ず,clu_bdmgr
により,そのメンバのブート・ディスクの
h
パーティションのコピーが自動的に保存されます。データは,/cluster/members/memberID/boot_partition/etc/clu_bdmgr.conf
に保存されます。
一般に,すべてのメンバ・ブート・ディスクの
h
パーティションには,同じデータが格納されます。ただし,次の 2 つの場合は除きます。
h
パーティションの内容が破損している場合。
メンバのブート・ディスクがメンバのプライベート・バス上にあり,ブート・ディスクの
h
パーティションの内容に影響を及ぼす更新がクラスタで行われたときにそのメンバが停止している場合。停止中のメンバのディスクはプライベート・バス上にあるので,h
パーティションを更新できません。
メンバのブート・ディスクは,共用 SCSI バスに接続することをお勧めします。h
パーティションを確実に最新にするほかに,この構成では,メンバをブートできない場合にブート・ディスクの診断と問題に対して処置を講ずることができます。
メンバのブート・ディスクが破損している場合は,clu_bdmgr
を使用すれば,そのディスクの修復や交換が可能です。クラスタが稼働していない場合でも,少なくとも 1 つのクラスタ・メンバ上のクラスタ化されたカーネルをブートできる間は,clu_bdmgr
コマンドを使用できます。
クラスタに新しいディスクを追加する方法については,9.2.3 項を参照してください。
メンバのブート・ディスクを修復するには,最初にブート・パーティションをバックアップしなければなりません。その 1 つの方法は,各メンバのブート・パーティションのダンプ・イメージ用のディスク・スペースを,共用
/var
ファイル・システムに割り当てることです。
member3
のブート・パーティションのダンプ・イメージをメンバ固有のファイル
/var/cluster/members/member3/boot_part_vdump
に保存するには,次のコマンドを入力します。
# vdump -0Df /var/cluster/members/member3/boot_part_vdump \ /cluster/members/member3/boot_partition
次の手順は,vdump
で保存されたファイルを使用してブート・ディスクを交換する方法を示しています。この手順では,次のような仮定をします。
member3
のブート・ディスクが
dsk3
である。
クラスタに新しいメンバのブート・ディスクを既に追加しており,この交換するディスクの名前が
dsk5
である。
ディスクを追加する処理では,hwmgr -scan comp -cat scsi_bus
コマンドを使用して,すべてのメンバが新しいディスクを認識できるようにします。ディスクをクラスタに追加する方法については,9.2.3 項を参照してください。
注意
メンバのブート・ディスクは,常にクラスタ・メンバすべてによって共用されるバスに接続する必要があります。このように配置すれば,少なくとも 1 つのクラスタ・メンバをブートできる間は,どのメンバのブート・ディスクでも修復できます。
clu_get_info
を使用して,member3
が停止しているかどうかを判断します。
# clu_get_info -m 3 Cluster memberid = 3 Hostname = member3.zk3.dec.com Cluster interconnect IP name = member3-mc0 Member state = DOWN
新しいディスク (この例では
dsk5
) を
member3
の交換ブート・ディスクとして選択します。member3
のブート・ディスクは
dsk3
なので,dsk5
が
member3
の新しいディスクとして使用されるように,member3
の
/etc/sysconfigtab
を編集する必要があります。
dsk5
を
member3
のブート・ディスクとして構成するには,次のコマンドを入力します。
# /usr/sbin/clu_bdmgr -c dsk5 3 The new member's disk, dsk5, is not the same name as the original disk configured for domain root3_domain. If you continue the following changes will be required in member3's/etc/sysconfigtab file: vm: swapdevice=/dev/disk/dsk5b clubase: cluster_seqdisk_major=19 cluster_seqdisk_minor=175
member3
のルート・ドメイン (新しい
dsk5
上) をマウントし,member3
の
/etc/sysconfigtab
を編集して,ブート・パーティションをリストアします。
# mount root3_domain#root /mnt
ブート・パーティションをリストアします。
# vrestore -xf /var/cluster/members/member3/boot_part_vdump -D /mnt
member3
の
/etc/sysconfigtab
を編集します。
# cd /mnt/etc # cp sysconfigtab sysconfigtab-bu
clu_bdmgr
コマンドからの出力に指示されているとおりに,vm
スタンザの
swapdevice
属性ならびに
clubase
スタンザの
cluster_seqdisk_major
属性と
cluster_seqdisk_minor
属性の値を変更します。
swapdevice=/dev/disk/dsk5b clubase: cluster_seqdisk_major=19 cluster_seqdisk_minor=175
h
パーティションの CNX 情報をリストアします。
# /usr/sbin/clu_bdmgr -h dsk5
h
パーティション情報は,clu_bdmgr
コマンドを実行するクラスタ・メンバから
dsk5
の
h
パーティションにコピーされます。
クラスタ全体が停止している場合は,クラスタ化されたカーネルからいずれかのメンバをブートする必要があります。単一メンバのクラスタが稼働した後は,h
パーティションの CNX 情報を
/mnt/etc/clu_bdmgr.conf
から
member3
の新規ブート・ディスク
dsk5
にリストアできます。次のコマンドを入力します。
# /usr/sbin/clu_bdmgr -h dsk5 /mnt/etc/clu_bdmgr.conf
member3
のルート・ドメインをアンマウントします。
# umount root3_domain#root /mnt
member3
をクラスタ内にブートします。
必要であれば,member3
で
consvar -s bootdef_dev
disk_name
コマンドを使用して,bootdef_dev
変数を新しいディスクに設定します。
ブート時に,cluster_root
(クラスタ・ルート・ファイル・システム) のマウントにクラスタが使用するデバイスを指定することができます。この機能を使用するのは,障害回復のために新しいクラスタ・ルートでブートする必要があるときだけです。
CFS (クラスタ・ファイル・システム) カーネル・サブシステムでは,3 つまでの
cluster_root
デバイスに対する主番号と副番号を指定するために,6 つの属性をサポートしています。障害回復のために使用している
cluster_root
ドメインは複数のボリュームで構成されている可能性があるため,次のように
cluster_root
デバイスを 3 つまで指定することができます。
cluster_root_dev1_maj
1 つの
cluster_root
デバイスの主デバイス番号
cluster_root_dev1_min
同じ
cluster_root
デバイスの副デバイス番号
cluster_root_dev2_maj
2 番目の
cluster_root
デバイスの主デバイス番号
cluster_root_dev2_min
2 番目の
cluster_root
デバイスの副デバイス番号
cluster_root_dev3_maj
3 番目の
cluster_root
デバイスの主デバイス番号
cluster_root_dev3_min
3 番目の
cluster_root
デバイスの副デバイス番号
これらの属性を使用するには,クラスタをシャットダウンし,あるメンバを対話的にブートして適切な
cluster_root_dev
の主番号と副番号を指定します。メンバをブートすると,メンバのブート・ディスクの CNX パーティション (h
パーティション) は,cluster_root
デバイスのロケーションで更新されます。クラスタにクォーラム・ディスクがある場合は,その CNX パーティションも更新されます。その他のノードがクラスタの中にブートされるときに,それらのメンバのブート・ディスク情報も更新されます。
たとえば,dsk6b
と
dsk8g
を構成する 2 つのボリュームのファイル・システムの
cluster_root
を使用するとします。dsk6b
の主番号は 19,副番号は 227 とします。dsk8g
の主番号は 19,副番号は 221 とします。次のようにクラスタをブートします。
あるメンバを対話的にブートします。
>>> boot -fl "ia" (boot dkb200.2.0.7.0 -flags ia) block 0 of dkb200.2.0.7.0 is a valid boot block reading 18 blocks from dkb200.2.0.7.0 bootstrap code read in base = 200000, image_start = 0, image_bytes = 2400 initializing HWRPB at 2000 initializing page table at fff0000 initializing machine state setting affinity to the primary CPU jumping to bootstrap code
.
.
.
Enter kernel_name [option_1 ... option_n] Press Return to boot default kernel 'vmunix':vmunix cfs:cluster_root_dev1_maj=19 \ cfs:cluster_root_dev1_min=227 cfs:cluster_root_dev2_maj=19 \ cfs:cluster_root_dev2_min=221[Return]
その他のクラスタ・メンバをブートします。
これらの属性を使用してクラスタのルート・ファイル・システムを回復させる方法についての詳細は,11.1.7 項および
11.1.8 項を参照してください。
11.1.7 クラスタの既存のディスクへのクラスタ・ルート・ファイル・システムの回復
次のすべてにあてはまる場合に,ここで記述する回復手順を使用してください。
クラスタ・ルート・ファイル・システムが破損している場合,または使用できない場合
最新のクラスタ・ルート・ファイル・システムのバックアップがある場合
バックアップは,クラスタ・ルート・ファイル・システムが障害が発生した時点に認識していたディスク・ストレージ環境を反映していなければなりません。たとえば,バックアップを作成した以降に,デバイスを削除したり (hwmgr del
を使用),リダイレクトしたり (hwmgr redirect
を使用),リフレッシュしたり (hwmgr refresh comp
を使用) していてはなりません。
クラスタ・ルート・ファイル・システムのバックアップが現在のディスク・ストレージ環境を反映していない場合,このプロシージャはパニックを引き起こします。このパニックが起こると,クラスタ・ファイル・システムを回復できなくなり,clu_create
コマンドを使用してクラスタを再作成しなければならなくなります。
全クラスタ・メンバにアクセス可能な共用バス上のディスク (複数可) が,ファイル・システムをリストアするために使用でき,かつ,このディスクがルート・ファイル・システムの問題発生前にはクラスタ構成に組み込まれていた場合
この手順は次のことを想定しています。
クラスタ・ルート (cluster_root
) ファイル・システムをバックアップするのに,コマンド
vdump
を使用した。
別のバックアップ・ツールを使用した場合は,適切なツールを使用してファイル・システムをリストアしてください。
少なくとも 1 つのメンバは次のようなデバイスにアクセスできる。
ブート可能な Tru64 UNIX ディスク
ブート可能なベース・ディスクが使用できない場合は,クラスタ・メンバのローカル・ディスク上に Tru64 UNIX をインストールします。クラスタ上にインストールされた Tru64 UNIX と同じバージョンである必要があります。
対象メンバ用のメンバ・ブート・ディスク (この例では
dsk2a
)
クラスタのルート・バックアップ用デバイス
クラスタの全メンバが停止している。
クラスタ・ルートをリストアするには,次のように行います。
Tru64 UNIX ディスクでシステムをブートします。
この手順では,このシステムを member 1 と想定します。
このシステムの,新しいクラスタ・ルートになるデバイスの名前が,クラスタのそのデバイスの名前と異なる場合は,コマンド
dsfmgr -m
を使用してデバイス名を変更し,クラスタのデバイスの名前が一致するようにします。
たとえば,クラスタの新しいクラスタ・ルートになるデバイスの名前が
dsk6b
で,システムのそのデバイスの名前が
dsk4b
の場合,デバイスの名前を次のコマンドで変更します。
# dsfmgr -m dsk4 dsk6
必要に応じて,ディスクにパーティションを設定し,ディスクがクラスタ・ルートとして,パーティション・サイズとファイル・システム・タイプが適切になるようにします。
新しいクラスタ・ルート用の新規ドメインを作成します。
# mkfdmn /dev/disk/dsk6d cluster_root
そのドメインのルート・ファイルセットを作成します。
# mkfset cluster_root root
この復旧手順では,cluster_root
に 3 つまでのボリュームを使用できます。復旧が完了したら,新しいボリュームをクラスタ・ルートに追加することができます。この例の場合,1 つのボリューム (dsk6b
) のみを追加します。
# addvol /dev/disk/dsk6b cluster_root
新しいクラスタ・ルートになるドメインをマウントします。
# mount cluster_root#root /mnt
バックアップ・メディアからクラスタ・ルートをリストアします (vdump
以外のバックアップ・ツールを使用した場合は,vrestore
の代りに適切なリストア・ツールを使用します)。
# vrestore -xf /dev/tape/tape0 -D /mnt
新しくリストアされたファイル・システムの
/etc/fdmns/cluster_root
を変更し,新しいデバイスを参照するようにします。
# cd /mnt/etc/fdmns/cluster_root # rm * # ln -s /dev/disk/dsk6b
コマンド
file
を使用して,新しい
cluster_root
デバイスの主番号と副番号を書き出しておきます (cluster_root
デバイスの主番号と副番号の使用についての詳細は,11.1.6 項を参照してください)。
たとえば,次のように行います。
# file /dev/disk/dsk6b /dev/disk/dsk6b: block special (19/221)
システムをシャットダウンし,新しいクラスタ・ルートの主番号と副番号を指定して対話的にリブートします。11.1.6 項では,ブート時のクラスタ・ルートの指定方法について説明しています。
注意
4.10.2 項で説明されているように,メンバをブートするには,おそらく,期待ボードを調整する必要があります。
>>> boot -fl "ia" (boot dkb200.2.0.7.0 -flags ia) block 0 of dkb200.2.0.7.0 is a valid boot block reading 18 blocks from dkb200.2.0.7.0 bootstrap code read in base = 200000, image_start = 0, image_bytes = 2400 initializing HWRPB at 2000 initializing page table at fff0000 initializing machine state setting affinity to the primary CPU jumping to bootstrap code
.
.
.
Enter kernel_name [option_1 ... option_n] Press Return to boot default kernel 'vmunix':vmunix cfs:cluster_root_dev1_maj=19 \ cfs:cluster_root_dev1_min=221[Return]
メンバをブートすると,メンバのブート・ディスクの CNX パーティション (h
パーティション) は,cluster_root
デバイスの位置で更新されます。クラスタにクォーラム・ディスクがある場合,その CNX パーティションも更新されます。クラスタに他のノードをブートするときには,メンバのブート・ディスク情報も更新されます。
その他のクラスタ・メンバをブートします。
11.1.8 新しいディスクへのクラスタ・ルート・ファイル・システムの回復
クラスタの既存のディスク以外を使用して
cluster_root
を回復する手順は複雑です。回復させる前に,新しいクラスタ・ルート・ディスクとして使用できる,クラスタに既にインストールされているディスクを探してみてください。見つかったら,11.1.7 項の手順を実行してください。
次のような場合に,ここで記述する回復手順を使用します。
クラスタ・ルート・ファイル・システムが破損している場合,または使用できない場合
最新のクラスタ・ルート・ファイル・システムのバックアップがある場合
バックアップは,クラスタ・ルート・ファイル・システムが障害が発生した時点に認識していたディスク・ストレージ環境を反映していなければなりません。たとえば,バックアップを作成した以降に,デバイスを削除したり (hwmgr del
を使用),リダイレクトしたり (hwmgr redirect
を使用),リフレッシュしたり (hwmgr refresh comp
を使用) していてはなりません。
クラスタ・ルート・ファイル・システムのバックアップが現在のディスク・ストレージ環境を反映していない場合,このプロシージャはパニックを引き起こします。このパニックが起こると,クラスタ・ファイル・システムを回復できなくなり,clu_create
コマンドを使用してクラスタを再作成しなければならなくなります。
ファイル・システムをリストアするために,全クラスタ・メンバにアクセス可能な共用バス上のディスクで,ルート・ファイル・システムの問題発生前にはクラスタ構成に組み込まれていたディスクが利用できない場合
この手順は次のことを想定しています。
cluster_usr
および
cluster_var
ファイル・システムが,cluster_root
と同じディスクにない。
この手順では,cluster_root
ファイル・システムの回復についてのみ説明します。
クラスタ・ルート (cluster_root
) ファイル・システムをバックアップするのに,コマンド
vdump
を使用した。
別のバックアップ・ツールを使用した場合は,適切なツールを使用してファイル・システムをリストアしてください。
少なくとも 1 つのメンバは次のようなデバイスにアクセスできる。
クラスタにインストールされていた Tru64 UNIX とバージョンが同じブート可能な Tru64 UNIX ディスク
ブート可能なベース・オペレーティング・システム用ディスクが使用できない場合は,クラスタ・メンバのローカル・ディスク上に Tru64 UNIX をインストールします。クラスタ上にインストールされた Tru64 UNIX と同じバージョンであることを確認してください。
対象メンバ用のメンバ・ブート・ディスク (この例では
dsk2a
)
クラスタ・ルート・バックアップ用デバイス
新しいクラスタ・ルート用ディスク (複数可)
クラスタの全メンバが停止している。
クラスタ・ルートをリストアするには,次のように行います。
Tru64 UNIX ディスクでシステムをブートします。
この手順では,このシステムを member 1 と想定します。
必要に応じて,ディスクにパーティションを設定し,ディスクがクラスタ・ルートとして,パーティション・サイズとファイル・システム・タイプが適切になるようにします。
新しいクラスタ・ルート用の新規ドメインを作成します。
# mkfdmn /dev/disk/dsk5b new_root
TruCluster Server 『クラスタ・インストレーション・ガイド』で説明されているように,cluster_root
ファイル・システムは
b
パーティションによく置かれます。この場合,例として
/dev/disk/dsk5b
が使用されます。
そのドメインのルート・ファイルセットを作成します。
# mkfset new_root root
この復旧手順では,new_root
に 3 つまでのボリュームを使用できます。復旧が完了したら,新しいボリュームをクラスタ・ルートに追加することができます。この例の場合,1 つのボリューム (dsk8e
) を追加します。
# addvol /dev/disk/dsk8e new_root
新しいクラスタ・ルートになるドメインをマウントします。
# mount new_root#root /mnt
バックアップ・メディアからクラスタ・ルートをリストアします (vdump
以外のバックアップ・ツールを使用した場合は,vrestore
の代わりに適切なリストア・ツールを使用します)。
# vrestore -xf /dev/tape/tape0 -D /mnt
リストアされたデータベースを,Tru64 UNIX システムの
/etc
ディレクトリにコピーします。
# cd /mnt/etc # cp dec_unid_db dec_hwc_cdb dfsc.dat /etc
リストアされたデータベースの現在のメンバのメンバ固有データを Tru64 UNIX システムの
/etc
ディレクトリにコピーします。
# cd /mnt/cluster/members/member1/etc # cp dfsl.dat /etc
メンバのブート・ディスクのドメインが存在しない場合には,ドメインを作成します。
# cd /etc/fdmns # ls # mkdir root1_domain # cd root1_domain # ln -s /dev/disk/dsk2a
メンバのブート・パーティションをマウントします。
# cd / # umount /mnt # mount root1_domain#root /mnt
メンバのブート・パーティションから Tru64 UNIX システムの
/etc
ディレクトリにデータベースをコピーします。
# cd /mnt/etc # cp dec_devsw_db dec_hw_db dec_hwc_ldb dec_scsi_db /etc
メンバのブート・ディスクをアンマウントします。
# cd / # umount /mnt
データベースの
.bak
バックアップ・ファイルを更新します。
# cd /etc # for f in dec_*db ; do cp $f $f.bak ; done
同じ Tru64 UNIX ディスクを使ってシステムをシングルユーザ・モードにリブートし,/etc
にコピーされたデータベースを使うようにします。
クラスタ・ルート・ファイル・システムのバックアップが現在のディスク・ストレージ環境を反映していない場合,このプロシージャはこの時点でパニックを引き起こします。パニックが起こると,クラスタ・ファイル・システムを回復できなくなり,clu_create
コマンドを使用してクラスタを再作成しなければならなくなります。
シングルユーザ・モードにブートした後,バス上にあるデバイスをスキャンします。
# hwmgr -scan scsi
書き込み可能としてルートを再マウントします。
# /sbin/mountroot
デバイス・データベースを検証し,更新します。
# dsfmgr -v -F
hwmgr
を使用して現在のデバイス命名規則を確認します。
# hwmgr -view devices
必要に応じて,ローカル・ドメインを更新し,デバイス命名規則を反映させます (特に,usr_domain
,new_root
,root1_domain
)。
この更新作業は,適切な
/etc/fdmns
ディレクトリへ移り,既存リンクを削除してから新たに現在のデバイス名へのリンクを作成して行います (現在のデバイス名は前の手順で調べました)。たとえば,次のように行います。
# cd /etc/fdmns/root_domain # rm * # ln -s /dev/disk/dsk1a # cd /etc/fdmns/usr_domain # rm * # ln -s /dev/disk/dsk1g # cd /etc/fdmns/root1_domain # rm * # ln -s /dev/disk/dsk2a # cd /etc/fdmns/new_root # rm * # ln -s /dev/disk/dsk5b # ln -s /dev/disk/dsk8e
コマンド
bcheckrc
を実行し,ローカル・ファイル・システムをマウントします。特に
/usr
のマウントが必要です。
# bcheckrc
更新されたクラスタ・データベース・ファイルをクラスタ・ルート上にコピーします。
# mount new_root#root /mnt # cd /etc # cp dec_unid_db* dec_hwc_cdb* dfsc.dat /mnt/etc # cp dfsl.dat /mnt/cluster/members/member1/etc
新しいクラスタ・ルートで,cluster_root
ドメインを使用します。
# rm /mnt/etc/fdmns/cluster_root/* # cd /etc/fdmns/new_root # tar cf - * | (cd /mnt/etc/fdmns/cluster_root && tar xf -)
更新されたクラスタ・データベース・ファイルをメンバのブート・ディスクにコピーします。
# umount /mnt # mount root1_domain#root /mnt # cd /etc # cp dec_devsw_db* dec_hw_db* dec_hwc_ldb* dec_scsi_db* /mnt/etc
コマンド
file
を使用して,新しい
cluster_root
デバイスの主番号と副番号を調べます (cluster_root
デバイスの主番号と副番号の使用についての詳しい情報は,11.1.6 項を参照してください)。この番号は次の手順で使用するので書き出しておきます。
たとえば,次のように行います。
# file /dev/disk/dsk5b /dev/disk/dsk5b: block special (19/227) # file /dev/disk/dsk8e /dev/disk/dsk8e: block special (19/221)
システムを停止させ,新しいクラスタ・ルートの主番号と副番号を指定して対話形式でリブートします。ブート時のクラスタ・ルートの指定方法については,11.1.6 項で説明しています。
注意
4.10.2 項で説明しているように,メンバをブートするには,おそらく,期待ボートを調整する必要があります。
>>> boot -fl "ia" (boot dkb200.2.0.7.0 -flags ia) block 0 of dkb200.2.0.7.0 is a valid boot block reading 18 blocks from dkb200.2.0.7.0 bootstrap code read in base = 200000, image_start = 0, image_bytes = 2400 initializing HWRPB at 2000 initializing page table at fff0000 initializing machine state setting affinity to the primary CPU jumping to bootstrap code
.
.
.
Enter kernel_name [option_1 ... option_n] Press Return to boot default kernel 'vmunix':vmunix cfs:cluster_root_dev1_maj=19 \ cfs:cluster_root_dev1_min=227 cfs:cluster_root_dev2_maj=19 \ cfs:cluster_root_dev1_min=221[Return]
その他のクラスタ・メンバをブートします。
ブート時にデバイス・ファイルでエラーが発生した場合は,コマンド
dsfmgr -v -F
を実行します。
ここでは,AdvFS を利用した場合に生じるおそれのある問題について説明します。
11.1.9.1 addvol または rmvol からの警告メッセージに対する応答
ある条件下では,cluster_root
ドメインで
addvol
または
rmvol
を使用すると,次の警告メッセージが出力される場合があります。
"WARNING:cfs_write_advfs_root_data: cnx_disk_write failed for quorum disk with error-number."
通常は,error-number
は
EIO
の値です。
このメッセージは,addvol
または
rmvol
が実行されたメンバが,クォーラム・ディスクの CNX パーティションに書き込みができないことを示しています。CNX パーティションには,cluster_root
ドメインのデバイス情報が含まれています。
この警告が生じるのは,ブート・メンバがクォーラム・ディスクにアクセスできない場合で,その理由はクラスタが意図的にこのように構成されているか,またはパスの障害のどちらかです。前者の理由の場合,メッセージを情報とみなすことができます。後者の理由の場合は,パスの障害の原因に対して処置を講ずる必要があります。
メッセージは,クォーラム・ディスク自体に問題があることを示す場合があります。クォーラム・ディスクのハードウェア・エラーもレポートされている場合は,そのディスクを交換する必要があります。クォーラム・ディスクの交換については,4.5.1 項を参照してください。
エラー番号については,
errno
(5)EIO
については,
errno
(2)11.1.9.2 デバイスの接続障害による AdvFS ドメイン・パニックの解消
ドメインまたはファイルセットの置かれているストレージが 1 つでも使用できなくなると,AdvFS でドメイン・パニックが発生するおそれがあります。この問題がもっともよく発生するケースは,AdvFS ドメインで使用されているプライベート・ストレージに接続しているクラスタ・メンバがクラスタを離れた場合です。次によくあるケースは,ストレージ・デバイスにハードウェア・トラブルが発生して使用できなくなった場合です。どちらの場合も,クラスタ・メンバからそのストレージへアクセスするパスがすべてなくなって,そのストレージが使用できなくなるため,ドメイン・パニックが発生します。
通常は,ドメイン・パニックが発生して最初に現れる症状として,デバイスから入出力エラーが返ったり,システム・コンソールにパニック・メッセージが出力されたりします。ドメインでは,まだ動作しているクラスタ・メンバによってサービスが行われていると,cfsmgr -e
のような CFS コマンドに対して
OK
のステータスが返ることがあり,問題がただちに反映されるとは限りません。
# ls -l /mnt/mytst /mnt/mytst: I/O error # cfsmgr -e Domain or filesystem name = mytest_dmn#mytst Mounted On = /mnt/mytst Server Name = deli Server Status : OK
デバイスの接続を回復してサービスに使用できる場合は,cfsmgr
コマンドを使用して,影響を受けたドメイン内のファイルセットを,パニックが生じる前にそのドメインへサービスを提供していたメンバに (または別のメンバに) 再配置することで,継続してドメインを使用することができます。
# cfsmgr -a SERVER=provolone -d mytest_dmn # cfsmgr -e Domain or filesystem name = mytest_dmn#mytests Mounted On = /mnt/mytst Server Name = provolone Server Status : OK
11.1.9.3 AdvFS ファイル・システムまたはドメインの強制アンマウント
デバイスの接続性を回復してサービスに戻せない場合,TruCluster Server バージョン 5.1B の
cfsmgr -u
と
cfsmgr -U
コマンドを使用します。
クラスタ・メンバがサービスしていない AdvFS ファイル・システムやドメインは,cfsmgr -u
を使用して,強制的にアンマウントできます。ファイル・システムまたはドメインがサービス中の場合は,アンマウントできません。
cfsmgr -U
コマンドを使用して,クラスタ・メンバによってサービスされている AdvFS のドメイン全体を強制的にアンマウントできます。
上記のコマンドのどちらを使用するのかは,その時点で CFS (クラスタ・ファイル・システム) がドメインをどう認識しているかによって異なります。
cfsmgr -e
コマンドを実行してドメインまたはファイル・システムの状態を調べ,サービス中でないことが分かれば,cfsmgr -u
コマンドを使用してそのドメインまたはファイルを強制的にアンマウントします。
# cfsmgr -e Domain or filesystem name = mytest_dmn#mytests Mounted On = /mnt/mytst Server Name = deli Server Status : Not Served # cfsmgr -u /mnt/mytst
ファイル・システム上でネストされたマウントがアンマウントされる場合,強制アンマウントは実行されません。同様に,ネストされたマウントがファイルセット上にある場合,全ドメインが強制的にアンマウントされるとき,およびネストされたマウントが同じドメインにないときは,強制アンマウントは実行されません。
cfsmgr -e
コマンドを実行してドメインまたはファイル・システムがサービス中であることが分かった場合は,cfsmgr -U
コマンドを使用して,全ドメインを強制アンマウントできます。
# cfsmgr -e Domain or filesystem name = mytest_dmn#mytests Mounted On = /mnt/mytst Server Name = deli Server Status : OK # cfsmgr -U /mnt/mytst
-u フラグとは違って,-U はドメイン全体に対してだけ用いられます。サービスされているドメイン中のファイル・システムのうち,1 つだけをアンマウントすることはできません。すなわち,1 つのファイル・システムを指定すると,ドメイン全体がアンマウントされます。アンマウントされるドメインのファイル・システム上にネストされたマウントがあり,同じドメイン上にネストされたマウントがない場合は,強制アンマウントは実行されません。
cfsmgr
コマンドについての詳細は,
cfsmgr
(8)11.1.9.4 ドメイン・パニックの回避
AdvFS GUI (グラフィカル・ユーザ・インタフェース) エージェント
advfsd
は,定期的にシステム・ディスクを走査します。メタデータの書き込みエラーが発生した場合,または単一の AdvFS ファイル・ドメインで破損が検出された場合,advfsd
デーモンは,システム・パニックではなく,ファイル・ドメイン上でドメイン・パニックを発生させます。この措置により,障害の発生したドメインが分離されるので,システムが引き続き他のすべてのドメインに対するサービスを提供できます。
クラスタのメンバ上で実行中の
advfsd
デーモンから見ると,AdvFS ドメインが含まれているディスクにアクセスできなくなったためにドメイン・パニックが生じる場合があります。正常な場合には,これは予定された動作です。このようなパニックを診断するには,Tru64 UNIX 『AdvFS 管理ガイド』のトラブルシューティングに関する章の手順に従ってください。ただし,クラスタ・メンバが,別のメンバのプライベート・ディスクが利用できなくなった (メンバの停止など) ためにドメイン・パニックを検出した場合は,ドメイン・パニックによって無用な混乱が生じます。
このようなメイン・パニックを回避するには,メンバの
/usr/var/advfs/daemon/disks.ignore
ファイルを編集して,AdvFS ドメインが含まれている他のメンバのプライベート・ストレージのディスク名を指定してください。これにより,ローカル・メンバ上の
advfsd
デーモンが,指定されたデバイスを走査しなくなります。
プライベート・デバイスを識別するには,sms
コマンドを使用して SysMan Station のグラフィック・インタフェースを起動し,次に [Views
] メニューから [Hardware
] を選択してください。
11.1.10 停止したシステム上のブート・パーティションへのアクセス
正常なシャットダウンによって,またはパニックなどの予定外の方法で,メンバがクラスタから外れる場合は,そのメンバのブート・パーティションはアンマウントされます。ブート・パーティションが共用バス上にある場合は,そのパーティションをマウントすれば,他のどのメンバでもブート・パーティションにアクセスできます。
システム
provolone
の停止中に
provolone
の
/etc/sysconfigtab
を編集するとします。その場合は,次のように入力できます。
# mkdir /mnt # mount root2_domain#root /mnt
provolone
をリブートする前に,root2_domain#root
をアンマウントしなければなりません。たとえば,次のように指定します。
# umount root2_domain#root
11.1.11 ブート・ディスクがすでにマウントされているメンバのブート
期待されるクォーラム・ボートまたはクォーラム・ディスク・デバイスが変更されると,各メンバの
/etc/sysconfigtab
ファイルが更新されます。クラスタ・メンバがダウンしている場合は,クォーラムに影響するクラスタ・ユーティリティ (clu_add_member
,clu_quorum
,clu_delete_member
など) が,ダウンしているメンバのブート・ディスクをマウントして更新します。ダウンしたメンバをブート・ディスクのマウント中にブートしようとすると,次のようなパニック・メッセージが出力されます。
cfs_ mountroot: CFS server already exists for this nodes boot partition
クラスタ・ユーティリティは,正常にダウンしているメンバのブート・ディスクをアンマウントします。
一般に,他のメンバがあるメンバのブート・ディスクをマウントしているときにそのメンバをブートしようとすると,パニックが発生します。たとえば,ダウンしているメンバのブート・ディスクをマウントして修復する場合,修復できたメンバをブートする前にそのブート・ディスクをアンマウントしなければ,パニックが発生します。
11.1.12 クラッシュ・ダンプの生成
クラスタに重大な問題が生じた場合は,すべてのクラスタ・メンバからのクラッシュ・ダンプが必要になる可能性があります。動作中のメンバからクラッシュ・ダンプを取得するには,dumpsys
コマンドを使用して,システム・メモリのスナップショットをダンプ・ファイルに保存してください。
クラッシュ・ダンプを生成するには,動作中の各クラスタ・メンバにログインして
dumpsys
を実行してください。省略時には,dumpsys
を実行すると,メンバ固有のディレクトリ
/var/adm/crash
にダンプが書き込まれます。
詳細は,
dumpsys
(8)
SysMan Menu Configure Dump および Create Dump Snapshot を使用しても,クラッシュ・ダンプを構成できます。Configure Dump 機能は,savecore
コマンドに関連する一般的なシステム構成変数に設定します。Create Dump Snapshot 機能は,dumpsys
コマンドを使用します。このコマンドは,通常のクラッシュ・ダンプを生成するためにそのシステムを停止することができないときに,メモリのスナップショットを手動でファイルにダンプするために使用します。
11.1.12.1 メンバがハングしたときのクラッシュ・ダンプの生成
クラスタ・メンバがハングした場合,クラッシュ・ダンプを生成するために
dumpsys
コマンドを使用することができません。この場合,クラッシュ・ダンプを生成するには次の手順を使用します。
dumpsys
コマンドを使用して,動作中のメンバのメモリ・スナップショットをダンプ・ファイルにコピーします。省略時には,dumpsys
コマンドは
/var/adm/crash
にダンプを書き込みます。このパスは,CDSL であり,実際のパスは
/cluster/members/{memb}/adm/crash
となります。
5.5 節に説明されているように,clu_quorum
コマンドを使用して,ハングしたメンバを停止したときにクォーラムを失っていないことを確認します。
ハングしたメンバをクラッシュさせます。これを行うには,メンバを手動で停止し,コンソールのプロンプトで
crash
を実行します。
メンバをブートします。ブートで
savecore
(
savecore
(8)/var/adm/crash
にダンプします。
ここでは,クラスタ内の潜在的なネットワークの問題とその解決策について説明します。
症状
クラスタに対して
ping
を実行できない。
クラスタへの,あるいはクラスタからの
rlogin
を実行できない。
クラスタから
telnet
を実行できない。
確認事項
すべてのクラスタ・メンバで
gated
が実行されていることを確認します。
さらに,/etc/rc.config
に次の行が含まれていることを確認します。
GATED="yes"
export GATED
/etc/rc.config
に次の行が含まれていることを確認します。
ROUTER="yes"
export ROUTER
/etc/hosts
に省略時のクラスタ別名とクラスタ・メンバの正しいエントリが設定されていることを確認します。
/etc/hosts
には,少なくとも次のエントリが設定されている必要があります。
クラスタ別名の IP アドレスと名前
注意
クラスタ別名のアドレスでは,ブロードキャスト・アドレスやマルチキャスト・アドレスを使用できず,また,クラスタ・インターコネクトの使用するサブネット内のアドレスも使用できません。さらに,クラスタ・メンバは IPv6 アドレスを公開して使用できますが,クラスタ別名サブシステムはそのアドレスをサポートしていません。したがって,IPv6 アドレスをクラスタ別名に割り当てることはできません。
RFC 1918 で定義されているプライベート・アドレス・スペースの IP アドレスであれば,クラスタ別名に割り当てることができますが,別名サブシステムがその別名アドレスへのルートを公開できるようにするために,次のようなコマンドを実行する必要があります。
# rcmgr -c set CLUAMGR_ROUTE_ARGS resvok # cluamgr -r resvok
各クラスタに対して
cluamgr
コマンドを繰り返します。resvok
フラグについての詳細は,を参照してください。 cluamgr
(8)
各クラスタ・メンバの IP アドレスと名前
各メンバのクラスタ・インターコネクト・インタフェースに関連付けられた IP アドレスとインタフェース名
たとえば,次のようになります。
127.0.0.1 localhost
16.140.102.238 trees.tyron.com trees
16.140.102.176 birch.tyron.com birch
16.140.102.237 oak.tyron.com oak
16.140.102.3 hickory.tyron.com hickory
10.0.0.1 birch-mc0
10.0.0.2 oak-mc0
10.0.0.3 hickory-mc0
すべてのクラスタ・メンバ上で
aliasd
が実行していることを確認します。
すべてのクラスタ・メンバが省略時の別名のメンバになっている (joined
と
enabled
) ことを確認します。これを確認するには,次のコマンドを入力します。
# cluamgr -s default_alias
あるメンバを省略時の別名のメンバにするには,そのメンバ上で
cluamgr
コマンドを実行します。たとえば,次のように指定します。
# cluamgr -a alias=default_alias,join
次に,各メンバ上で次のコマンドを実行します。
# cluamgr -r start
1 つのメンバが,省略時の別名に対してルーティングしていることを確認します。これを確認するには,各メンバ上で次のコマンドを実行します。
# arp default_alias
実行結果には,permanent published
というフレーズが含まれるはずです。1 つのメンバにおいて,省略時のクラスタ別名に向けた静的発行経路が設定されている必要があります。
クラスタ別名の IP アドレスが別のシステムで使用されていないことを確認します。
クラスタ別名デーモン
aliasd
を誤って別のシステムで使用中の別名 IP アドレスで構成した場合は,クラスタで接続障害が発生するおそれがあります。たとえば,一部のマシンはクラスタ別名に到達できますが,その他のマシンは到達できない場合があります。別名に到達できないマシンは,まったく別のマシンに接続する可能性があります。
クラスタ外のシステム上の
arp
キャッシュを検査すれば,影響を受ける別名 IP アドレスが 2 つ以上の異なるハードウェア・アドレスにマップされていることが明白になる可能性があります。
クラスタが重大度
err
のメッセージを記録するように構成されている場合は,システム・コンソールとカーネル・ログ・ファイルで次のメッセージを調べます。
local IP address
nnn.nnn.nnn.nnn
in use
by hardware address
xx-xx-xx-xx-xx
/etc/rc.config
と
/etc/hosts
内のエントリが正しく,他の問題がすべて修正されたことを確認した後は,gateway
と
inet
のデーモンを停止してから再起動してください。この操作を行うには,各クラスタ・メンバ上で次のコマンドを入力します。
# /sbin/init.d/gateway stop # /sbin/init.d/gateway start
TruCluster Server バージョン 5.1B より前のリリースでは,ルーティング・デーモンとして
gated
をクラスタで実行する必要がありました。routed
,ogated
,または静的ルーティングのセットアップを使用できず,また,ルーティング・デーモンも使用できませんでした。バージョン 5.1B からは,gated
,routed
,または静的ルーティングが使用可能になりました。ogated
は使用できません。省略時の構成では,gated
となります。3.14 節でルーティング・オプションについて説明しています。
11.2 クラスタ管理のヒント
ここでは,クラスタの構成と管理のヒントおよび提案について説明します。
11.2.1 /tmp の移動
省略時には,メンバ固有の
/tmp
領域は同じファイル・システム内にありますが,その領域は個々のファイル・システムに移動できます。場合によっては,共用 SCSI バスのトラフィックを軽減するために,各メンバの
/tmp
領域をメンバのローカル・ディスクに移動してもかまいません。
クラスタ・メンバに対してプライベート・バス上の固有の
/tmp
ディレクトリを設定したい場合は,そのクラスタ・メンバのローカル・バス上のディスクに AdvFS ドメインを作成して,そのドメインの
/etc/fstab
に
/tmp
のマウント・ポイントを持つエントリを追加できます。
たとえば,次の
/etc/fstab
のエントリは,メンバ ID がそれぞれ
58
と
59
の 2 つのクラスタ・メンバ
tcr58
と
tcr59
の
/tmp
ディレクトリに対応しています。
tcr58_tmp#tmp /cluster/members/member58/tmp advfs rw 0 0
tcr59_tmp#tmp /cluster/members/member59/tmp advfs rw 0 0
tcr58_tmp
ドメインは,tcr58
メンバのみが接続できるバス上にあります。tcr59_tmp
ドメインは,tcr59
メンバのみが接続できるディスク上にあります。
各メンバは,ブート時に
/etc/fstab
内のすべてのファイル・システムをマウントしようとしますが,マウントできるのは,まだマウントされていない,デバイスへのパスが存在するドメインのみです。この例では,tcr58
は
tcr58_tmp#tmp
のみをマウントできます。また,tcr59
は
tcr59_tmp#tmp
のみをマウントできます。
/etc/fstab
に次のように設定できます。
tcr58_tmp#tmp /tmp advfs rw 0 0
tcr59_tmp#tmp /tmp advfs rw 0 0
/tmp
は CDSL (コンテキスト依存シンボリック・リンク) なので,/cluster/members/membern/tmp
に解決されます。ただし,/etc/fstab
に完全パス名を設定すれば,より明らかになるので混乱が生じる確率は低くなります。
11.2.2 MC_CABLE コンソール・コマンドの実行
任意のメンバ上で
MC_CABLE
Memory Channel 診断コマンドを実行する前に,すべてのメンバをコンソール・プロンプトに応じてシャットダウンしなければなりません。これは正常な操作です。
停止しているクラスタ・メンバのコンソールから,他のメンバの起動時に
MC_CABLE
コマンドを実行すると,クラスタがクラッシュします。
11.2.3 Korn シェルにおけるメンバ固有のディレクトリへの実パスの非表示
Korn シェル (ksh
) では,ディレクトリまでのパスが記憶され,pwd
コマンドを入力すると,そのパス名が表示されます。これは,パス内のシンボリック・リンクのために別のディレクトリに移動している場合でも同じです。TruCluster Server では,CDSL を利用してメンバ固有のディレクトリがクラスタ単位のネームスペースに保持されるので,作業ディレクトリが CDSL になっている場合は,Korn シェルでは実パスは返されません。
パス名の表示時にシェルでシンボリック・リンクを解釈させたい場合は,Korn シェル以外のシェルを使用してください。たとえば,次のようになります。
# ksh # ls -l /var/adm/syslog lrwxrwxrwx 1 root system 36 Nov 11 16:17 /var/adm/syslog ->../cluster/members/{memb}/adm/syslog # cd /var/adm/syslog # pwd /var/adm/syslog # sh # pwd /var/cluster/members/member1/adm/syslog