日本-日本語

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

OpenVMS マニュアル


HP OpenVMS
OpenVMS Cluster システム


目次 索引



クラスタ・グループ・コードとパスワードを確認するには,以下の操作を行います。

手順 操作
1 データベース・ファイル SYS$COMMON:CLUSTER_AUTHORIZE.DAT が存在するかどうか確認する。
2 複数のシステム・ディスクを使用しているクラスタの場合は,各システム・ディスクに対して正しい (同じ) グループ番号とパスワードが指定されているかどうか確認する。

関連項目: SYSMAN ユーティリティを使用してグループ番号を表示し, CLUSTER_AUTHORIZE.DAT ファイルでパスワードを再設定する方法については, 第 10.8 節 を参照。



C.4 スタートアップ・プロシージャの完了障害

コンピュータがブートされ,クラスタに参加した後,スタートアップ・プロシージャが完了する前に,つまり,システムにログインする前に,ハングしているように見える場合は,スタートアップ・プロシージャを実行できるだけの十分な時間を確保したかどうか確認します。

状態 対処法
サイトで標準的な時間が経過した後も,スタートアップ・プロシージャを完了できない。 OpenVMS Cluster の別のコンピュータからプロシージャにアクセスし,適切な調整を行う。たとえば,必要なすべてのデバイスが構成され,使用可能な状態であるかどうか確認する。 NPAGEDYN やページ・ファイル領域など,システム・リソースが不足しているために,このような障害が発生することもある。
NPAGEDYN パラメータの値が小さすぎないかどうか確認する。 会話型ブートストラップ操作を実行して,このパラメータの値を大きくする。SYSBOOT を使用して現在の値を確認し,値を 2 倍にする。
ページ・ファイル領域が不足している可能性があり,別の OpenVMS Cluster コンピュータを利用できる。 そのコンピュータにログインし, System Generation ユーティリティ (SYSGEN) を使用して,問題のコンピュータに対して適切なページ・ファイル領域を提供する。

注意: ブート・コンピュータでページ・ファイル領域が不足すると,他のコンピュータがハングすることがある。

以上の調整を行っても,コンピュータがスタートアップ・プロシージャを完了できない。 コンパックのサポート担当者に連絡する。



C.5 LAN コンポーネント障害の診断

LAN コンポーネント障害 (たとえば LAN ブリッジの破損) が発生したときのトラブルシューティングの手法については, 付録 D.5 節 を参照してください。その付録では, Local Area OpenVMS Cluster Network Failure Analysis Program を使用する方法についても説明しています。

断続的に LAN コンポーネント障害 (たとえばパケットの損失) が発生すると,SCS (System Communications Services) メッセージを OpenVMS Cluster の他のノードに配布している NISCA トランスポート・プロトコルで問題が発生する可能性があります。LAN アナライザ・ツールを使用してトラブルシューティングを行う方法と,このツールを使用する場合の必要条件については, 付録 F を参照してください。

C.6 クラスタのハングの診断

以下のような状態が発生すると,OpenVMS Cluster コンピュータはプロセスまたはシステム動作を中断します (つまりハングします)。

状態 参照先
クラスタ・クォーラムが失われた。 付録 C.6.1 項
共用クラスタ・リソースにアクセスできない。 付録 C.6.2 項



C.6.1 クラスタ・クォーラムが失われた

OpenVMS Cluster のクォーラム・アルゴリズムは, OpenVMS Cluster のコンピュータ間で動作を調整し,共用クラスタ・リソースの整合性を確保します (クォーラム・アルゴリズムの詳細については, 第 2 章 を参照してください)。クラスタ構成が変更された場合,たとえば投票メンバがクラスタから削除されたり,クラスタに追加された場合,クォーラムが確認されます。クォーラムが失われると,クラスタ内のすべてのコンピュータで実行されていたプロセスや I/O 動作は停止されます。

クォーラムが失われたことに関する情報と,クォーラムが失われた原因になったクラスタ単位のイベントに関する情報が OPCOM プロセスに送信されます。このプロセスは,指定されたオペレータ・ターミナルにメッセージをブロードキャストします。また,この情報は各コンピュータのオペレータ・コンソール (OPA0) にもブロードキャストされますが,そのターミナルでブロードキャスト動作が明示的に無効に設定されている場合は,ブロードキャストされません。しかし, OPCOM がオペレータ・ターミナルにメッセージを送信できるようになる前に,クォーラムが失われることもあるため, OPA0 に送信されるメッセージは,クォーラムが失われた原因となったイベントに対する最も信頼性の高い情報源です。

クォーラムが失われた場合,ノードを追加するか,ノードをリブートすることにより,票数を追加します。

関連項目: クラスタ・クォーラムについては, 第 10.11 節 も参照してください。

C.6.2 クラスタ・リソースにアクセスできない

共用クラスタ・リソースへのアクセスは,分散ロック・マネージャによって調整されます。特定のプロセスがリソース (たとえば共用データ・ファイル) に対するロックを獲得すると,そのリソースに対して互換性のないロックを要求したクラスタ内の他のプロセスは,元のロックが解放されるまで待たなければなりません。元のプロセスがかなり長い時間にわたってロックを保持している場合,そのロックが解放されるのを待っている他のプロセスはハングしているように見えることがあります。

場合によっては,システム動作で長期間にわたってリソースに対する制限付きロックを取得しなければならないことがあります。たとえば,ボリュームの再構築を実行するには,システム・ソフトウェアが再構築するボリュームに対して排他的ロックを獲得します。このロックが保有されている間,他のプロセスはディスク・ボリューム上で領域を割り当てることができません。このような操作を実行しようとすると,プロセスはハングしているように見えることがあります。

システムの操作にとって必要なデータが格納されているファイルへのアクセスは,分散ロック・マネージャによって調整されます。この理由から,プロセスがこれらのリソースのいずれかに対してロックを取得した後,そのプロセスの処理ができなくなった場合,クラスタはハングしているように見えることがあります。

たとえば,プロセスが書き込みアクセスのためにシステム登録ファイル (SYS$SYSTEM:SYSUAF.DAT) の一部をロックした場合,この状況が発生することがあります。同じユーザ名や類似したユーザ名を持つアカウントへのログインや,そのユーザ名へのメールの送信など,ファイルのその部分へのアクセスが必要な操作は,元のロックが解放されるまで実行されません。通常,このロックは迅速に解放されるため,ユーザがロック操作に気付くことはありません。

しかし,ロックを保有しているプロセスを処理できなくなった場合,他のプロセスも待ち状態になります。登録ファイルはログイン時に使用され,多くのプロセス生成操作 (たとえばバッチ・ジョブやネットワーク・ジョブなど) でも使用されるため,クラスタ内でブロックされたプロセスが急増します。このような状況でも,分散ロック・マネージャは正常に機能しているため,ブロードキャスト・メッセージや他の手段によって問題が発生したことがユーザに通知されることはありません。

C.7 CLUEXIT バグチェックの診断

オペレーティング・システムがバグチェック操作を実行するのは,正常なシステム動作を損なう可能性がある状況や,データの整合性をおかす危険性のある条件を検出した場合だけです。 CLUEXIT バグチェックは,接続マネージャによって開始される一種のバグチェックです。接続マネージャは,協調動作する OpenVMS Cluster コンポーネントの相互関係を管理する OpenVMS Cluster ソフトウェアのコンポーネントです。このようなバグチェックの大部分は,ハードウェア障害 (特に通信パスの障害),構成エラー,システム管理エラーから発生した状況によって起動されます。

C.7.1 バグチェックの原因になる状況

CLUEXIT バグチェックが実行される最も一般的な状況は,以下のとおりです。

可能性のあるバグチェックの原因 対処法
2 台のコンピュータの間のクラスタ接続が, RECNXINTERVAL に指定されている秒数より長い時間破壊されている。その後,接続は修復できないほど破壊されていることが宣言される。後で接続が再確立されると,コンピュータの 1 台が CLUEXIT バグチェックでシャットダウンされる。

この状況は以下の場合に発生する可能性がある。

  • 電源障害が発生した後,バッテリ・バックアップによって修復されたとき

  • SCS 通信リンクが修復された後

  • RECNXINTERVAL パラメータに指定されている秒数より長い時間,コンピュータが停止され,オペレータ・コンソールから入力された CONTINUE コマンドによって再起動された後

接続が破壊された原因を判断し,問題を解決する。たとえば,電源障害から修復するのに,RECNXINTERVAL の秒数より長い時間がかかる場合は,すべてのコンピュータで RECNXINTERVAL パラメータの値を大きくしなければならない。
クラスタ分断が発生した。クラスタのメンバが別のクラスタのメンバへの接続を検出したか,または確立したか,あるいはフォーリン・クラスタがクォーラム・ファイルから検出された。 すべてのコンピュータで EXPECTED_VOTES の設定を確認する。
コンピュータで SCSMAXMSG システム・パラメータに対して指定されている値が小さすぎる。 OpenVMS Cluster のすべてのコンピュータで,SCSMAXMSG の値が少なくともデフォルト値以上に設定されているかどうか確認する。



C.8 ポート通信

ここでは,ポート通信の問題の診断に役立つ,ポート通信の詳細について説明します。

C.8.1 LAN 通信

Ethernet あるいは FDDI インターコネクトを含むクラスタでは, LAN 上のコンピュータを見つけるのにマルチキャスト・スキームが使用されます。ポート・エミュレータ・ドライバ (PEDRIVER) は,クラスタ・グループ番号から得られたクラスタ固有のマルチキャスト・アドレスに対し,約 3 秒ごとに各 LAN アダプタを通して HELLO データグラム・メッセージを送信します。このドライバは,他のコンピュータからこの種のメッセージを受け取ることも可能です。オープンな仮想サーキットを現在共有しないコンピュータから HELLO データグラム・メッセージを受け取った場合,サーキットを作成しようとします。現在オープンは仮想サーキットで他のコンピュータから HELLO データグラム・メッセージを受け取った場合,そのリモート・コンピュータが動作可能なことを示しています。

仮想サーキットの作成には標準の 3 つのメッセージ交換ハンドシェークが使用されます。ハンドシェーク・メッセージには,伝送するコンピュータに関する情報およびコンピュータ・パスワードの記録などが含まれます。これらのパラメータは受信側のコンピュータで確認され,検証に成功した場合のみハンドシェークが継続されます。このようにして,各コンピュータは他のコンピュータを認証します。最後のメッセージの後,仮想サーキットはオープンされ,両方のコンピュータで使用できるようになります。

C.8.2 SCS (System Communications Services) 接続

ディスク・クラス・サーバ,接続マネージャ,MSCP および TMSCP サーバなどのシステム・サービスは, SCS (System Communications Services) というプロトコルを使用してコンピュータ間で通信します。SCS は主に,システム間プロセス接続の確立と終了,およびこれらの接続を介したメッセージ・トラフィックのフロー制御を行います。 SCS はポート・ドライバ (たとえば PADRIVER,PBDRIVER, PEDRIVER,PIDRIVER) と,SCSLOA.EXE というオペレーティング・システムのロード可能な部分 (システム初期化時に自動的にロードされる部分) で実装されています。

仮想サーキットがオープンされている場合は,コンピュータは定期的にリモート・コンピュータを調べ,リモート・コンピュータが提供しているシステム・サービスがないかどうか確認します。 SCS ディレクトリ・サービスは,コンピュータが提供しているサービスを認識できるようにするためのサービスであり,コンピュータと HSC サブシステムの両方に常に存在します。システム・サービスが他のコンピュータおよび HSC サブシステムから対応するサービスを検出すると,SCS 接続を相互に確立します。これらの接続は全二重であり,特定の仮想サーキットに関連付けられます。通常,複数の接続が 1 つの仮想サーキットに関連付けられます。

C.9 ポート障害の診断

ここでは,通信パスの階層と,障害が発生する場所について説明します。

C.9.1 通信パスの階層構造

SCS,ポート・ドライバ,ポート自体の組み合わせによって,通信パスの階層構造がサポートされます。ここでは,最も基本的なレベルから順に説明します。

  • 物理ワイヤ。Ethernet は 1 本の同軸ケーブルです。ポートは,使用されていない方のパスを選択しますが,両方のパスが使用されていない場合は,任意のパスを選択します (ケーブルとスター・カプラで実装され,ポートによって管理されます)。

  • 仮想サーキット (LAN ポート・エミュレータ・ドライバ (PEDRIVER) で一部が実装され,SCS ソフトウェアで一部が実装されます)。

  • SCS 接続 (システム・ソフトウェアで実装されます)。



C.9.2 障害の発生場所

障害は,各通信レベルおよび各コンポーネントで発生する可能性があります。 表 C-3 で説明しているように,あるレベルの障害が別の障害を招くことがあります。

表 C-3 ポート障害
通信レベル 障害
ワイヤ LAN 障害が発生するか,または切断された場合,障害の性質に応じて, LAN トラフィックが停止するか,または中断される。すべてのトラフィックは,障害の発生していないパスに送られる。ワイヤが修復されると,修復はポート・ポーリングによって自動的に検出され,すべてのポートで正常な操作が再開される。
仮想サーキット 2 つのポート間のパスが動作しなくなった場合,仮想サーキットで障害が発生し,仮想サーキットはクローズされる。他のコンピュータからのマルチキャスト HELLO データグラム・メッセージあるいはの着信トラフィックが無い場合, LAN に対するパス障害があると判断される。

仮想サーキットで障害が発生すると,そのサーキット上のすべての SCS 接続はクローズされる。仮想サーキットが再び確立されると,ソフトウェアは自動的に接続を再確立する。通常,仮想サーキットの再確立には,問題が解決された後,数秒かかる。

LAN アダプタ LAN アダプタ・デバイスで障害が発生すると,そのデバイスを再起動しようとする試みが行われる。試行を繰り返しても再起動できない場合,そのアダプタを使用しているすべてのチャネルが破壊される。チャネルは 2 つ 1 組の LAN アドレスであり, 1 つはローカル・アドレス,もう 1 つはリモート・アドレスである。仮想サーキットに対してオープンされている最後のチャネルで障害が発生すると,仮想サーキットがクローズされ,接続は破壊される。
SCS 接続 ソフトウェア・プロトコルで障害が発生するか,またはソフトウェアがハードウェアの誤動作を検出すると,接続は終了する。他の接続は,仮想サーキットの場合と同様に,通常は影響を受けない。接続の終了は,特定の状況でエラー回復のための機能として使用されることがある。最も一般的な例として,コンピュータで利用できる非ページング・プールが不足する場合,このような状況が発生する。
コンピュータ オペレータ・シャットダウン,バグチェック,または停止によって,コンピュータで障害が発生すると,クラスタ内の他のすべてのコンピュータは,シャットダウンしているコンピュータのポートに対する仮想サーキットの障害として,シャットダウンを記録する。


目次 索引

プライバシー ご利用条件・免責事項