日本-日本語

製品  >  ソフトウェア  >  OpenVMS  >  マニュアル

OpenVMS マニュアル


≫ 

OpenVMS V8.3
ライブラリ

タイトルページ
目次
まえがき
第 1 章:OpenVMS Cluster システムの管理の概要
第 2 章:OpenVMS Cluster の概念
第 3 章:OpenVMS Cluster インターコネクト構成
第 4 章:OpenVMS Cluster オペレーティング環境
第 5 章:共用環境の準備
第 6 章:クラスタ・ストレージ・デバイス
第 7 章:クラスタ・キューの設定と管理
第 8 章:OpenVMS Cluster システムの構成
第 9 章:大規模な OpenVMS Cluster システムの構築
第 10 章:OpenVMS Cluster システムの保守
付録 A :クラスタ・システム・パラメータ
付録 B :共通ファイルの作成
付録 C :クラスタのトラブルシューティング
付録 D :LAN 制御のためのサンプル・プログラム
付録 E :LAN 制御のためのサブルーチン
付録 F :NISCA プロトコルのトラブルシューティング
付録 G :NISCA トランスポート・プロトコル・チャネル選択および輻輳制御
索引
PDF
OpenVMS ホーム
OpenVMS | HPE 日本

OpenVMS
OpenVMS Cluster システム


目次 索引

付録 C
クラスタのトラブルシューティング



ここでは,以下のトラブルシューティング操作を実行するのに役立つ情報をまとめます。

  • コンピュータのブートまたはクラスタへの参加での障害

  • クラスタのハング

  • CLUEXIT バグチェック

  • ポート・デバイスの問題



C.1.1 予備チェックリスト

診断手順を開始する前に,以下の確認を行ってください。

  • すべてのクラスタ・ハードウェア・コンポーネントが正しく接続されており,正しく動作しているかどうか確認します。

  • 新しい CI コンピュータまたは最近修理した CI コンピュータをクラスタに追加するときに,CI ケーブルが正しく接続されているかどうか確認します。 付録 C.10.5 項 を参照してください。

  • OpenVMS Cluster Software Software Product Description (SPD 29.78.xx) に指定されている要件に従って, OpenVMS Cluster コンピュータとマス・ストレージ・デバイスが構成されていることを確認します。

  • サテライトをクラスタに追加する場合は, OpenVMS Cluster Software SPD に指定されている要件に従って, LAN が構成されていることを確認しなければなりません。また, 第 4 章 で説明した手順に従って,ネットワークを正しく構成し,起動したかどうかも確認しなければなりません。

予備チェックを実行し,必要に応じて適切な処置を実行した後,コンピュータがまだブートできなかったり,クラスタに参加できない場合は, C.2C.4 項の手順に従って,障害からの回復を試みてください。

C.1.2 ブート・イベント・シーケンス

診断手順と回復手順を効果的に実行するには,コンピュータがブートし,クラスタに参加するときに,どのようなイベントが実行されるかを理解しておく必要があります。ここでは,これらのイベントの概要を示し,コンソールに表示される典型的なメッセージも示します。

発生するイベントは,コンピュータが新しいクラスタにブートされる最初のコンピュータであるのか,アクティブ・クラスタでブートされているのかに応じて異なります。また,一部のイベント (パスワードとグループ番号が格納されているクラスタ・データベースのロードなど) は,LAN 上の OpenVMS Cluster システムでのみ発生します。

通常のイベント・シーケンスは 表 C-1 に示すとおりです。

表 C-1 ブート・イベント・シーケンス
ステップ 操作
1 コンピュータがブートする。コンピュータがサテライトの場合は,以下のようなメッセージに,サテライトをダウンライン・ロードした MOP サーバの名前と LAN アドレスが表示される。この時点で,サテライトは MOP サーバとの通信を完了しており, OpenVMS Cluster 通信機能を使用してシステム・ディスク・サーバとの通信を続行している。
%VAXcluster-I-SYSLOAD, system loaded from Node X...

ブート中のコンピュータに対して, OpenVMS "バナー・メッセージ" が以下の形式で表示される。
operating-system Version
n.n dd-mmm-yyyy hh:mm.ss

2 コンピュータがクラスタを作成するか,またはクラスタに参加しようとすると,以下のメッセージが表示される。
waiting to form or join an OpenVMS Cluster system

コンピュータが LAN ベースの OpenVMS Cluster のメンバである場合は,クラスタ・セキュリティ・データベース (クラスタ・パスワードとグループ番号が格納されている) がロードされる。必要に応じて,MSCP サーバと TMSCP サーバもロードできる。

%VAXcluster-I-LOADSECDB, loading the cluster security database

%MSCPLOAD-I-LOADMSCP, loading the MSCP disk server
%TMSCPLOAD-I-LOADTMSCP, loading the TMSCP tape server
3 コンピュータがクラスタを検出すると,そのクラスタに参加しようとする。クラスタが検出されると,接続マネージャは以下の形式で 1 つ以上のメッセージを表示する。
%CNXMAN, Sending VAXcluster membership request to system X...

クラスタを検出できない場合,クォーラムを確立できるだけの十分なボーツ数があるとき (つまり,十分な数のボーツ・コンピュータがブートされているとき) は,接続マネージャはクラスタを作成する。

4 ブート・コンピュータがクラスタに参加すると,接続マネージャは以下の形式のメッセージを表示する。
%CNXMAN, now a VAXcluster member -- system X...

コンピュータのブート中にクォーラムが失われた場合や,コンピュータが 2 分間のブート中にクラスタに参加できない場合は,接続マネージャは以下のようなメッセージを表示する。

%CNXMAN, Discovered system X...

%CNXMAN, Deleting CSB for system X...
%CNXMAN, Established "connection" to quorum disk
%CNXMAN, Have connection to system X...
%CNXMAN, Have "connection" to quorum disk

最後の 2 つのメッセージは,すでに確立されている接続を示している。

5 クラスタにクォーラム・ディスクが含まれている場合は,以下のメッセージも表示されることがある。
%CNXMAN, Using remote access method for quorum disk

%CNXMAN, Using local access method for quorum disk

最初のメッセージは,ディスクが使用できない状態であるか, MSCP サーバを介してアクセスされるために,接続マネージャがクォーラム・ディスクに直接アクセスできないことを示している。ディスクに直接アクセス可能なクラスタ内の別のコンピュータが,ディスクに対して信頼性のある接続が確立されているかどうかを確認しなければならない。

2 番目のメッセージは,接続マネージャがクォーラム・ディスクに直接アクセスでき,ディスクに直接アクセスできないコンピュータにディスクの状態情報を提供できることを示している。

注意: クォーラム・ディスクがまだ構成されていないために,最初は接続マネージャがクォーラム・ディスクを確認できないことがある。その場合,接続マネージャは,最初はリモート・アクセスを使用し,後でローカル・アクセスに切り換える。

6 コンピュータがクラスタに参加した後,通常のスタートアップ・プロシージャが実行される。最初に実行される機能の 1 つとして,OPCOM プロセスが起動される。
%%%%%%%%%%% OPCOM 15-JAN-1994 16:33:55.33 %%%%%%%%%%%

Logfile has been initialized by operator _X...$OPA0:
Logfile is SYS$SYSROOT:[SYSMGR]OPERATOR.LOG;17
%%%%%%%%%%% OPCOM 15-JAN-1994 16:33:56.43 %%%%%%%%%%%
16:32:32.93 Node X... (csid 0002000E) is now a VAXcluster member
7 他のコンピュータがクラスタに参加すると,OPCOM は以下のようなメッセージを表示する。
%%%%% OPCOM 15-JAN-1994 16:34:25.23 %%%%% (from node X...)

16:34:24.42 Node X... (csid 000100F3)
received VAXcluster membership request from node X...

この後,スタートアップ・プロシージャが続行されると,さまざまなメッセージが表示され,スタートアップ・イベントが報告されます。

ヒント: トラブルシューティングのために,スタートアップ・プロセスの各フェーズ,たとえばディスクのマウントやキューの起動などを報告するメッセージをサイト固有のスタートアップ・プロシージャに指定することができます。

C.2 CI 上のコンピュータのブート障害

CI コンピュータをブートできない場合は,以下のチェックを行います。

ステップ 操作
1 コンピュータの SCSNODE パラメータと SCSSYSTEMID パラメータがクラスタ内で固有の値であるかどうか確認する。固有の値でない場合は, 両方の値を変更するか,他のすべてのコンピュータをリブートしなければならない。
2 正しいブートストラップ・コマンド・ファイルを使用しているかどうか確認する。このファイルには,内部バス・コンピュータ番号 (適用可能な場合),HSC または HSJ ノード番号,コンピュータのブートで使用されるディスクが指定されていなければならない。デフォルト・ブートストラップ・コマンド・プロシージャで値を設定する方法については,各プロセッサのインストールおよび操作ガイドを参照。
3 PAMAXPORT システム・パラメータが最大の CI ポート番号に等しいか,それより大きい値に設定されているかどうか確認する。
4 CI ポートに固有のハードウェア・ステーション・アドレスが割り当てられているかどうか確認する。
5 HSC サブシステムがオンライン状態であるかどうか確認する。 HSC オペレータ・コントロール・パネルの ONLINE スイッチが押された状態になっていなければならない。
6 ディスクが使用可能であるかどうか確認する。ディスクのオペレータ・コントロール・パネルの正しいポート・スイッチが押された状態でなければならない。
7 コンピュータが HSC サブシステムにアクセスできるかどうか確認する。HSC SETSHO ユーティリティの SHOW HOSTS コマンドは,クラスタ内のすべてのコンピュータ (ホスト) の状態を表示する。問題のあるコンピュータがディスプレイに DISABLED として表示される場合は,SETSHO ユーティリティを使用してコンピュータを ENABLED 状態に設定する。

関連項目: SETSHO ユーティリティの詳細については, HSC ハードウェア・マニュアルを参照。

8 HSC サブシステムがブート・ディスクにアクセスできるかどうか確認する。HSC サブシステムがブート・ディスクにアクセスできるかどうか確認するには,SETSHO ユーティリティを起動する。ユーティリティの SHOW DISKS コマンドは, HSC サブシステムから確認できるすべてのディスクの現在の状態を表示し,no-host-access テーブルのすべてのディスクを表示する。

条件 対処法
ブート・ディスクが no-host-access テーブルに表示される。 SETSHO ユーティリティを使用して,ブート・ディスクを host-access に設定する。
ブート・ディスクは使用可能またはマウントされた状態であり,ホスト・アクセスが有効に設定されていれば,ディスクは no-host-access テーブルに表示されない。 サポート担当者に連絡し,問題点とこれまでの対処を説明する。



C.3 サテライトのブート障害

サテライトを正しくブートするには,サテライトが LAN を介して MOP サーバと通信しなければなりません。この通信を確認するには, DECnet イベント・ログを使用できます。以下の操作を実行してください。

ステップ 操作
1 MOP サーバにシステム管理者としてログインする。
2 管理レイヤ・イベントのイベント・ロギングがまだ有効に設定されていない場合は,以下の NCP コマンドを入力して有効にする。
NCP> SET LOGGING MONITOR EVENT 0.*

NCP> SET LOGGING MONITOR STATE ON
3 以下の DCL コマンドを入力して,ダウンライン・ロード・イベントを報告する DECnet メッセージをターミナルが受信できるようにする。
$ REPLY/ENABLE=NETWORK

4 サテライトをブートする。サテライトと MOP サーバが通信でき,すべてのブート・パラメータが正しく設定されている場合は,以下のようなメッセージが MOP サーバのターミナルに表示される。
DECnet event 0.3, automatic line service

From node 2.4 (URANUS), 15-JAN-1994 09:42:15.12
Circuit QNA-0, Load, Requested, Node = 2.42 (OBERON)
File = SYS$SYSDEVICE:<SYS10.>, Operating system
Ethernet address = 08-00-2B-07-AC-03
DECnet event 0.3, automatic line service
From node 2.4 (URANUS), 15-JAN-1994 09:42:16.76
Circuit QNA-0, Load, Successful, Node = 2.44 (ARIEL)
File = SYS$SYSDEVICE:<SYS11.>, Operating system
Ethernet address = 08-00-2B-07-AC-13

場合 対処法
サテライトが MOP サーバ (VAX または Alpha) と通信できない。 そのサテライトに対するメッセージは表示されない。 LAN ケーブル接続またはアダプタ・サービスに問題があると考えられる。
DECnet データベースにサテライトのデータが正しく指定されていない (たとえば,ハードウェア・アドレスが不正である)。 以下のようなメッセージに正しいアドレスが表示され,ロードが要求されたことが示される。
 DECnet event 0.7, aborted service

request
From node 2.4 (URANUS) 15-JAN-1994
Circuit QNA-0, Line open error
Ethernet address=08-00-2B-03-29-99

ノード名,ノード・アドレス,システム・ルートが表示されていないことに注意する。

サテライト・ブートのトラブルシューティングについては, C.3.2C.3.5 項を参照してください。トラブルシューティングの説明では,システム・パラメータが正しく設定されているかどうか確認することが頻繁に求められます。

C.3.1 接続メッセージの表示

会話型ブートで接続メッセージの表示を有効にするには,以下の操作を行います。

ステップ 操作
1 サテライトの NISCS_CONV_BOOT システム・パラメータを 1 に設定することにより,会話型ブートを有効に設定する。 Alpha システムでは,ディスク・サーバのシステム・ルートで ALPHAVMSSYS.PAR ファイルを更新し,VAX システムでは VAXVMSSYS.PAR ファイルを更新する。
2 会話型ブートを実行する。

++Alpha システムでは,コンソールから以下のコマンドを入力する。

>>> b -flags 0,1

  +VAX システムでは,レジスタ R5 のビット <0> をセットする。たとえば, VAXstation 3100 システムでは,コンソールから以下のコマンドを入力する。
>>> B/1

3 接続メッセージを確認する。

サテライト・ブートで接続メッセージを表示して,大規模なクラスタのどのシステムがブート・プロセスでクラスタ・サテライトにシステム・ディスクをサービスしているかを判断する。ブートの問題が発生した場合は,この表示を利用することで,システム・ディスクを現在サービスしているシステムの問題を切り分けるのに役立つ。その後,サーバ・システムに複数の LAN アダプタがある場合は,特定の LAN アダプタを切り分けることができる。

4 LAN アダプタを切り分ける。

LAN アダプタを切り分けるには,1 つのアダプタだけが接続された状態でリブートを行う。つまり,サーバ・システムで 1 つの LAN アダプタを除き,他のすべてのアダプタを切断し,サテライトをリブートする。そのアダプタがシステム・ディスク・サーバに接続されているときに,サテライトが正しくブートされる場合は,他の LAN アダプタに対しても同じ手順を実行する。問題のあるアダプタを突き止めることができるまで,この操作を繰り返す。


+VAX 固有
++Alpha 固有



サテライトをブートできない場合は,ここで説明する手順に従って, OpenVMS Cluster システムで問題点を診断し,修正します。

ステップ 操作
1 ブート・デバイスが使用可能であるかどうか確認する。複数のシステム・ディスクからサテライトがブートされるようなクラスタの場合は,このチェックが特に重要である。
2 DECnet ネットワークが起動され,動作しているかどうか確認する。
3 クラスタ・グループ・コードとパスワードを確認する。クラスタ・グループ・コードとパスワードは, CLUSTER_CONFIG.COM プロシージャを使用して設定される。
4 正しい OpenVMS Alpha ライセンスと OpenVMS VAX ライセンスをインストールしたかどうか確認する。
5 各サテライト・ノードで,以下のようにシステム・パラメータの値が設定されているかどうか確認する。
VAXCLUSTER = 2
NISCS_LOAD_PEA0 = 1
NISCS_LAN_OVRHD = 0
NISCS_MAX_PKTSZ = 1498 1
SCSNODE はコンピュータの名前である。
SCSSYSTEMID はコンピュータ識別番号である。
VOTES = 0

SCS パラメータ値は,システム構成に応じて異なる設定になる。

関連項目: これらの SCS パラメータの設定方法については, 付録 A を参照。

ブートできないサテライト・ノードでシステム・パラメータ値を確認するには, OpenVMS Cluster で実行中のシステムのうち,サテライト・ノードのローカル・ノードにアクセスできるシステムで, SYSGEN ユーティリティを起動する (SYSGEN ユーティリティは,同じ種類のオペレーティング・システムを稼動しているノードから起動しなければならない。たとえば,Alpha サテライト・ノードをトラブルシューティングする場合は,Alpha システムで SYSGEN ユーティリティを実行しなければならない)。システム・パラメータが以下のように設定されているかどうか確認する。

ステップ 操作
A システム・ディスクからサテライト・ノードのローカル・ルートを検索する。以下の例は,DECnet for OpenVMS を実行している Alpha システムの例である。
$ MCR NCP SHOW NODE HOME CHARACTERISTICS

Node Volatile Characteristics as of 10-JAN-1994 09:32:56
Remote node = 63.333 (HOME)
Hardware address = 08-00-2B-30-96-86
Load file = APB.EXE
Load Assist Agent = SYS$SHARE:NISCS_LAA.EXE
Load Assist Parameter = ALPHA$SYSD:[SYS17.]

この例のローカル・ルートは ALPHA$SYSD:[SYS17.] である。

関連項目: NCL コマンドを使用する場合については,DECnet--Plus のマニュアルを参照。

B システム・プロンプトに対して SHOW LOGICAL コマンドを入力して,ALPHA$SYSD の論理名を変換する。
$ SHO LOG ALPHA$SYSD

"ALPHA$SYSD" = "$69$DUA121:" (LNM$SYSTEM_TABLE)
C サテライトのローカル・ディスクにアクセスできるシステムで, SYSGEN ユーティリティを起動する (この例では, Alpha パラメータ・ファイル ALPHAVMSSYS.PAR を使用して, Alpha システムで SYSGEN ユーティリティを起動している。 VAX システムでは,SYSGEN ユーティリティは VAX パラメータ・ファイル VAXVMSSYS.PAR を使用する)。以下の例は,サテライト・ノードのローカル・ルートにあるシステム・パラメータ・ファイルを使用して, SYSGEN コマンド USE を入力し,その後, SHOW コマンドを入力して問題のパラメータを確認する方法を示している。
$ MCR SYSGEN

SYSGEN> USE $69$DUA121:[SYS17.SYSEXE]ALPHAVMSSYS.PAR
SYSGEN> SHOW VOTES
Parameter
Name Current Default Min. Max. Unit Dynamic
--------- ------- ------- --- ----- ---- -------
VOTES 0 1 0 127 Votes
SYSGEN> EXIT


1 Ethernet アダプタの場合,NISCS_MAX_PKTSZ の値は 1498 である。FDDI アダプタの場合,この値は 4468 である。


目次 索引

印刷用画面へ
プライバシー 本サイト利用時の合意事項