OpenVMS
OpenVMS Cluster システム


前へ 次へ 目次 索引


C.3.3 MOP サーバのトラブルシューティング

MOP サーバの問題を診断し,修正するには,ここで説明する手順を実行します。

ステップ 操作
1 付録 C.3.2 項 で説明したステップを実行する。
2 NCP サーキットの状態がオンであるかどうかと,サービスが有効に設定されているかどうかを確認する。以下のコマンドを入力して NCP ユーティリティを実行し,NCP サーキットの状態を確認する。
$ MCR NCP

NCP> SHOW CIRCUIT ISA-0 CHARACTERISTICS
Circuit Volatile Characteristics as of 12-JAN-1994 10:08:30
Circuit = ISA-0
State = on
Service = enabled
Designated router = 63.1021
Cost = 10
Maximum routers allowed = 33
Router priority = 64
Hello timer = 15
Type = Ethernet
Adjacent node = 63.1021
Listen timer = 45
3 サービスが有効に設定されていない場合は,以下のような NCP コマンドを入力して,有効に設定することができる。
NCP> SET CIRCUIT
circuit-id STATE OFF

NCP> DEFINE CIRCUIT circuit-id SERVICE ENABLED
NCP> SET CIRCUIT circuit-id SERVICE ENABLED STATE ON

DEFINE コマンドはパーマネント・データベースを更新し,ネットワークを次回起動するときに,サービスが有効に設定されるようにする。サーキットがオフの間, DECnet トラフィックは中断される。

4 ロード・アシスト・パラメータがシステム・ディスクおよびサテライトのシステム・ルートを指していることを確認する。
5 サテライトのシステム・ディスクが MOP サーバ・ノードでマウントされているかどうか確認する。
6 ++Alpha システムでは,ロード・ファイルが APB.EXE であることを確認する。
7 MOP ブートの場合,サテライト・ノードのパラメータ・ファイル (Alpha コンピュータの場合は ALPHAVMSYS.PAR,VAX コンピュータの場合は VAXVMSSYS.PAR) がサテライト・システム・ルートの [SYSEXE] ディレクトリに格納されていなければならない。
8 CLUSTER_AUTHORIZE.DAT ファイルがサテライト・システム・ルートの [SYSCOMMON.SYSEXE] ディレクトリに格納されていることを確認する。


++Alpha 固有

C.3.4 ディスク・サーバのトラブルシューティング

ディスク・サーバの問題を診断し,修正するには,ここで説明する操作を実行します。

ステップ 操作
1 付録 C.3.2 項 で説明したステップを実行する。
2 各サテライト・ノードに対して,以下のシステム・パラメータの値を確認する。
MSCP_LOAD = 1
MSCP_SERVE_ALL = 1
3 システム・ディスクをサービスするディスク・サーバは,ディスクに直接接続されていなければならない。

C.3.5 サテライト・ブートのトラブルシューティング

サテライト・ブートの問題を診断し,修正するには,ここで説明する操作を実行します。

ステップ 操作
1 付録 C.3.2 項付録 C.3.3 項付録 C.3.4 項 で説明した操作を実行する。
2 各サテライト・ノードに対して,VOTES システム・パラメータが 0 に設定されているかどうか確認する。
3 ++Alpha システムでは,NCP ユーティリティを実行し,以下のコマンドを入力してノード属性を表示することにより, MOP サーバで DECnet ネットワーク・データベースを確認する。以下の例では,UTAH という Alpha ノードに関する情報が表示されている。
$ MCR NCP

NCP> SHOW NODE UTAH CHARACTERISTICS
Node Volatile Characteristics as of 15-JAN-1994 10:28:09
Remote node = 63.227 (UTAH)
Hardware address = 08-00-2B-2C-CE-E3
Load file = APB.EXE
Load Assist Agent = SYS$SHARE:NISCS_LAA.EXE
Load Assist Parameter = $69$DUA100:[SYS17.]

ロード・ファイルは APB.EXE でなければならない。さらに, Alpha ノードをブートする場合,ブート・コマンド・ラインに指定した各 LAN アダプタに対して,ロード・アシスト・パラメータが同じシステム・ディスクおよびルート番号を指さなければならない。

4 +VAX システムでは,NCP ユーティリティを実行し,以下のコマンドを入力してノード属性を表示することにより, MOP サーバで DECnet ネットワーク・データベースを確認する。以下の例では,ARIEL という VAX ノードに関する情報が表示されている。
$ MCR NCP

NCP> SHOW CHAR NODE ARIEL
Node Volatile Characteristics as of 15-JAN-1994 13:15:28

Remote node = 2.41 (ARIEL)

Hardware address = 08-00-2B-03-27-95
Tertiary loader = SYS$SYSTEM:TERTIARY_VMB.EXE
Load Assist Agent = SYS$SHARE:NISCS_LAA.EXE
Load Assist Parameter = DISK$VAXVMSRL5:<SYS12.>

VAX ノードでは,3 次ローダが SYS$SYSTEM:TERTIARY_VMB.EXE であることに注意する。

5 Alpha システムと VAX システムで,NCP 表示から以下の情報を確認する。

ステップ 操作
A ノードの DECnet アドレスを確認する。
B ロード・アシスト・エージェントが SYS$SHARE:NISCS_LAA.EXE であることを確認する。
C ロード・アシスト・パラメータがサテライト・システム・ディスクと正しいルートを指していることを確認する。
D ハードウェア・アドレスがサテライトの Ethernet アドレスと一致することを確認する。サテライトのコンソール・プロンプトに対して, 表 8-3 に示した情報を使用して,サテライトの現在の LAN ハードウェア・アドレスを取得する。

NCP によって表示されたハードウェア・アドレスの値と,サテライトのコンソールに表示されるアドレスを比較する。値は同一でなければならず, SYS$MANAGER:NETNODE_UPDATE.COM ファイルに指定されている値と一致しなければならない。値が一致しない場合は,適切な調整を行う必要がある。たとえば,サテライトの LAN アダプタを最近交換した場合は,CLUSTER_CONFIG.COM の CHANGE 機能を実行して,適切な MOP サーバでネットワーク・データベースと NETNODE_UPDATE.COM を更新しなければならない。

6 会話型ブートを実行して,サテライトのブートでなぜ問題が発生したのか,その正確な理由を突き止める。会話型ブート・プロシージャでは,ネットワーク・ブートに関する問題を解決するのに役立つメッセージが表示される。メッセージには,ネットワークの状態情報や,サテライトとシステム・ディスク・サーバの間の通信プロセスに関する情報が示される。

関係項目: Alpha システムの場合のブート・メッセージについては, 付録 C.3.6 項 を参照。


+VAX 固有
++Alpha 固有

C.3.6 Alpha ブート・メッセージ (Alpha のみ)

Alpha システムでは, 表 C-2 に示したメッセージが表示されます。

表 C-2 Alpha のブート・メッセージ (Alpha のみ)
メッセージ 説明
%VMScluster-I-MOPSERVER, MOP server for downline load was node UTAH
このメッセージには, DECnet MOP ダウンライン・ロードを提供するシステムの名前が表示される。このメッセージは, MOP ロードを実行しているコンソールから,ロードされたイメージに,制御が正しく転送されたことを確認する。 このメッセージが表示されない場合は,MOP ロードが失敗したか,MOP によって不正なファイルがダウンライン・ロードされたと考えられる。
%VMScluster-I-BUSONLINE, LAN adapter is now running 08-00-2B-2C-CE-E3
このメッセージには,ブート・コマンドに指定された Ethernet または FDDI アダプタの LAN アドレスが表示される。複数の LAN デバイスをブート・コマンド・ラインに指定した場合は,複数行が表示されることがある。ブート・サテライトは,クラスタ・マルチキャスト・アドレスにメッセージを送信することにより,システム・ディスクを探すことができるようになる。 このメッセージが表示されない場合は,LAN アダプタが正しく初期化されていない。物理的なネットワーク接続を確認する。 FDDI の場合は,アダプタはリング上になければならない。
%VMScluster-I-VOLUNTEER, System disk service volunteered by node EUROPA AA-00-04-00-4C-FD
このメッセージには,サテライト・システム・ディスクをサービスしているシステムの名前が表示される。このシステムは,ブート・サテライトがシステム・ディスクのサーバを探すために送信したマルチキャスト・メッセージに応答している。 このメッセージが表示されない場合は,以下の 1 つ以上の状況によって問題が発生していると考えられる。

  • サテライトとブート・サーバの間のネットワーク・パスが破壊されているか,またはローカル・エリア OpenVMS Cluster マルチキャスト・メッセージをフィルタリングしている。

  • システム・ディスクがサービスされていない。

  • システム・ディスクに格納されている CLUSTER_AUTHORIZE.DAT ファイルが他のクラスタ・メンバのファイルと一致しない。

%VMScluster-I-CREATECH, Creating channel to node EUROPA 08-00-2B-2C-CE-E2 08-00-2B-12-AE-A2
このメッセージには,ローカル LAN アダプタの LAN アドレス (最初のアドレス) と,ネットワークを介して通信パスを形成しているリモート LAN アダプタの LAN アドレス (2 番目のアドレス) が表示される。これらのアダプタは,ブートのために NISCA 仮想サーキットをサポートするのに使用できる。複数の LAN アダプタをブート・コマンド・ラインに指定した場合や,システム・ディスクをサービスしているシステムに複数の LAN アダプタが接続されている場合は,複数のメッセージが表示されることがある。 これらのメッセージが期待した数だけ表示されない場合は,アドレスが表示されない LAN アダプタに関連してネットワークの問題が発生している可能性がある。 Local Area OpenVMS Cluster Network Failure Analysis Program を使用して,詳細なトラブルシューティングを行う ( 付録 D.5 節 を参照)。
%VMScluster-I-OPENVC, Opening virtual circuit to node EUROPA
このメッセージには,ブート・プロセスで通信のために使用される NISCA 仮想サーキットを確立したシステムの名前が表示される。ブートでは,この仮想サーキットを使用して,リモート MSCP サーバに接続される。  
%VMScluster-I-MSCPCONN, Connected to a MSCP server for the system disk, node EUROPA
このメッセージには,サテライト・システム・ディスクを実際にサービスしているシステムの名前が表示される。 このメッセージが表示されない場合は,システム・ディスクをサービスしていると主張したシステムがディスクをサービスすることができない状態である。 OpenVMS Cluster の構成を確認する。
%VMScluster-W-SHUTDOWNCH, Shutting down channel to node EUROPA 08-00-2B-2C-CE-E3 08-00-2B-12-AE-A2
このメッセージには,ローカル LAN アダプタの LAN アドレス (最初のアドレス) と,通信できなくなったリモート LAN アダプタ LAN アドレス (2 番目のアドレス) が表示される。障害の種類に応じて,ブート・システムまたはシステム・ディスクをサービスしているシステムに複数の LAN アダプタが接続されている場合は,複数のメッセージが表示されることがある。  
%VMScluster-W-CLOSEVC, Closing virtual circuit to node EUROPA
このメッセージには,名前が表示されたシステムと NISCA 通信を実行できないことが示される。  
%VMScluster-I-RETRY, Attempting to reconnect to a system disk server
このメッセージには,システム・ディスクをサービスしている別のシステムを探すことが示される。 LAN アダプタが再初期化され,すべての通信が再起動される。  
%VMScluster-W-PROTOCOL_TIMEOUT, NISCA protocol timeout
ブート・ノードとリモート・システムの間の接続が切断されたか,またはリモート・システムがブート・システムからの要求に応答しなくなったことを示す。どちらの場合も,ブート・システムが障害を宣言し,ブート・サーバへの接続を再確立する。  

C.4 コンピュータがクラスタに参加できない障害

コンピュータがクラスタに参加できない場合は,ここで説明する手順を実行して,原因を判断します。

C.4.1 OpenVMS Cluster ソフトウェアのロードの確認

OpenVMS Cluster ソフトウェアがロードされているかどうか確認するには,以下の操作を行います。

ステップ 操作
1 付録 C.1.2 項 に示した接続マネージャ (%CNXMAN) メッセージを探す。
2 このようなメッセージが表示されない場合は,おそらくブート時に OpenVMS Cluster ソフトウェアがロードされていない。会話モードでコンピュータをリブートする。SYSBOOT> プロンプトに対して, VAXCLUSTER パラメータを 2 に設定する。
3 LAN または複合インターコネクトを介して通信している OpenVMS Cluster システムの場合,NISCS_LOAD_PEA0 を 1 に設定し,VAXCLUSTER を 2 に設定する。これらのパラメータは,コンピュータの MODPARAMS.DAT ファイルでも設定しなければならない (会話モードでコンピュータをブートする方法については,インストール・ガイドおよび操作ガイドを参照)。
4 LAN 上の OpenVMS Cluster システムの場合,クラスタ・セキュリティ・データベース・ファイル (SYS$COMMON:CLUSTER_AUTHORIZE.DAT) が存在することと,このクラスタに対して正しいグループ番号を指定したことを確認する ( 第 10.9.1 項 を参照)。

C.4.2 ブート・ディスクとルートの確認

コンピュータが正しいディスクおよびシステム・ルートからブートされたかどうかを確認するには,以下の操作を行います。

ステップ 操作
1 %CNXMAN メッセージが表示され,会話型リブートの後,コンピュータがクラスタに参加できない場合は,すべてのアクティブ・コンピュータでコンソール出力を確認し, 1 台以上のコンピュータで既知のコンピュータまたはローカル・コンピュータと競合するリモート・コンピュータを検出したことを示すメッセージが出力されていないかどうか調べる。このようなメッセージは,2 台のコンピュータが同じシステム・ルートからブートされたことを示している。
2 すべての CI コンピュータのブート・コマンド・ファイルを確認し,すべてが正しいディスクおよび固有のシステム・ルートからブートされていることを確認する。
3 コンピュータのブートストラップ・コマンド・プロシージャ (コンソール・メディア) を変更しなければならないことがわかった場合は,クラスタ内ですでに稼動している別のプロセッサでこの操作を実行できる。

稼動しているプロセッサのコンソール・メディアを変更するメディアと交換し,Exchange ユーティリティとテキスト・エディタを使用して,必要な変更を行う。ブート・コマンド・ファイルの確認と編集の方法については,適切なプロセッサのインストールおよび操作ガイドを参照。


前へ 次へ 目次 索引