| 前へ | 次へ | 目次 | 索引 |
クラスタに参加するには，コンピュータの SCSNODE パラメータと SCSSYSTEMID パラメータを固有の値に設定しなければなりません。
| ステップ | 操作 | ||||||
|---|---|---|---|---|---|---|---|
| 1 | 現在の値が既存の OpenVMS Cluster コンピュータに対して設定した値と重複していないかどうか確認する。値を確認するには，会話型ブートストラップ操作を実行する。 | ||||||
| 2 | SCSNODE または SCSSYSTEMID の値が固有の値でない場合は，以下のいずれかの操作を行う。
注意: 値を変更するには，会話型ブートストラップ操作を実行する。しかし，将来のブートストラップ操作が信頼性の高い方法で行われるようにするには，コンピュータの MODPARAMS.DAT ファイルでこれらのパラメータに対して適切な値を指定する。
|
クラスタ・グループ・コードとパスワードを確認するには，以下の操作を行います。
| ステップ | 操作 |
|---|---|
| 1 | データベース・ファイル SYS$COMMON:CLUSTER_AUTHORIZE.DAT が存在するかどうか確認する。 |
| 2 | 複数のシステム・ディスクを使用しているクラスタの場合は，各システム・ディスクに対して正しい (同じ) グループ番号とパスワードが指定されているかどうか確認する。
関連項目: SYSMAN ユーティリティを使用してグループ番号を表示し， CLUSTER_AUTHORIZE.DAT ファイルでパスワードを再設定する方法については， 第 10.9 節 を参照。 |
コンピュータがブートされ，クラスタに参加した後，スタートアップ・プロシージャが完了する前に，つまり，システムにログインする前に，ハングしているように見える場合は，スタートアップ・プロシージャを実行できるだけの十分な時間を確保したかどうか確認します。
| 状態 | 対処法 |
|---|---|
| サイトで標準的な時間が経過した後も，スタートアップ・プロシージャを完了できない。 | OpenVMS Cluster の別のコンピュータからプロシージャにアクセスし，適切な調整を行う。たとえば，必要なすべてのデバイスが構成され，使用可能な状態であるかどうか確認する。 NPAGEDYN やページ・ファイル領域など，システム・リソースが不足しているために，このような障害が発生することもある。 |
| NPAGEDYN パラメータの値が小さすぎないかどうか確認する。 | 会話型ブートストラップ操作を実行して，このパラメータの値を大きくする。SYSBOOT を使用して現在の値を確認し，値を 2 倍にする。 |
| ページ・ファイル領域が不足している可能性があり，別の OpenVMS Cluster コンピュータを利用できる。 | そのコンピュータにログインし， System Generation ユーティリティ (SYSGEN) を使用して，問題のコンピュータに対して適切なページ・ファイル領域を提供する。
注意: ブート・コンピュータでページ・ファイル領域が不足すると，他のコンピュータがハングすることがある。 |
| 以上の調整を行っても，コンピュータがスタートアップ・プロシージャを完了できない。 | コンパックのサポート担当者に連絡する。 |
LAN コンポーネント障害 (たとえば LAN ブリッジの破損) が発生したときのトラブルシューティングの手法については， 付録 D.5 節 を参照してください。その付録では， Local Area OpenVMS Cluster Network Failure Analysis Program を使用する方法についても説明しています。
断続的に LAN コンポーネント障害 (たとえばパケットの損失) が発生すると，SCS (System Communications Services) メッセージを OpenVMS Cluster の他のノードに配布している NISCA トランスポート・プロトコルで問題が発生する可能性があります。LAN アナライザ・ツールを使用してトラブルシューティングを行う方法と，このツールを使用する場合の必要条件については，
付録 F を参照してください。
C.7 クラスタのハングの診断
以下のような状態が発生すると，OpenVMS Cluster コンピュータはプロセスまたはシステム動作を中断します (つまりハングします)。
| 状態 | 参照先 |
|---|---|
| クラスタ・クォーラムが失われた。 | 付録 C.7.1 項 |
| 共用クラスタ・リソースにアクセスできない。 | 付録 C.7.2 項 |
OpenVMS Cluster のクォーラム・アルゴリズムは， OpenVMS Cluster のコンピュータ間で動作を調整し，共用クラスタ・リソースの整合性を確保します (クオーラム・アルゴリズムの詳細については， 第 2 章 を参照してください)。クラスタ構成が変更された場合，たとえばボーツ・コンピュータがクラスタから削除されたり，クラスタに追加された場合，クォーラムが確認されます。クォーラムが失われると，クラスタ内のすべてのコンピュータで実行されていたプロセスや I/O 動作は停止されます。
クォーラムが失われたことに関する情報と，クォーラムが失われた原因になったクラスタ単位のイベントに関する情報が OPCOM プロセスに送信されます。このプロセスは，指定されたオペレータ・ターミナルにメッセージをブロードキャストします。また，この情報は各コンピュータのオペレータ・コンソール (OPA0) にもブロードキャストされますが，そのターミナルでブロードキャスト動作が明示的に無効に設定されている場合は，ブロードキャストされません。しかし， OPCOM がオペレータ・ターミナルにメッセージを送信できるようになる前に，クォーラムが失われることもあるため， OPA0 に送信されるメッセージは，クォーラムが失われた原因となったイベントに対する最も信頼性の高い情報源です。
クォーラムが失われた場合，ノードを追加するか，ノードをリブートすることにより，ボーツ数を追加します。
関連項目: クラスタ・クォーラムについては， 第 10.12 節 も参照してください。
C.7.2 クラスタ・リソースにアクセスできない
共用クラスタ・リソースへのアクセスは，分散ロック・マネージャによって調整されます。特定のプロセスがリソース (たとえば共用データ・ファイル) に対するロックを獲得すると，そのリソースに対して互換性のないロックを要求したクラスタ内の他のプロセスは，元のロックが解放されるまで待たなければなりません。元のプロセスがかなり長い時間にわたってロックを保持している場合，そのロックが解放されるのを待っている他のプロセスはハングしているように見えることがあります。
場合によっては，システム動作で長期間にわたってリソースに対する制限付きロックを取得しなければならないことがあります。たとえば，ボリュームの再構築を実行するには，システム・ソフトウェアが再構築するボリュームに対して排他的ロックを獲得します。このロックが保有されている間，他のプロセスはディスク・ボリューム上で領域を割り当てることができません。このような操作を実行しようとすると，プロセスはハングしているように見えることがあります。
システムの操作にとって必要なデータが格納されているファイルへのアクセスは，分散ロック・マネージャによって調整されます。この理由から，プロセスがこれらのリソースのいずれかに対してロックを取得した後，そのプロセスの処理ができなくなった場合，クラスタはハングしているように見えることがあります。
たとえば，プロセスが書き込みアクセスのためにシステム登録ファイル (SYS$SYSTEM:SYSUAF.DAT) の一部をロックした場合，この状況が発生することがあります。同じユーザ名や類似したユーザ名を持つアカウントへのログインや，そのユーザ名へのメールの送信など，ファイルのその部分へのアクセスが必要な操作は，元のロックが解放されるまで実行されません。通常，このロックは迅速に解放されるため，ユーザがロック操作に気付くことはありません。
しかし，ロックを保有しているプロセスを処理できなくなった場合，他のプロセスも待ち状態になります。登録ファイルはログイン時に使用され，多くのプロセス生成操作 (たとえばバッチ・ジョブやネットワーク・ジョブなど) でも使用されるため，クラスタ内でブロックされたプロセスが急増します。このような状況でも，分散ロック・マネージャは正常に機能しているため，ブロードキャスト・メッセージや他の手段によって問題が発生したことがユーザに通知されることはありません。
C.8 CLUEXIT バグチェックの診断
オペレーティング・システムがバグチェック操作を実行するのは，正常なシステム動作を損なう可能性がある状況や，データの整合性をおかす危険性のある条件を検出した場合だけです。 CLUEXIT バグチェックは，接続マネージャによって開始される一種のバグチェックです。接続マネージャは，協調動作する OpenVMS Cluster コンポーネントの相互関係を管理する OpenVMS Cluster ソフトウェアのコンポーネントです。このようなバグチェックの大部分は，ハードウェア障害 (特に通信パスの障害)，構成エラー，システム管理エラーから発生した状況によって起動されます。
C.8.1 バグチェックの原因になる状況
CLUEXIT バグチェックが実行される最も一般的な状況は，以下のとおりです。
| 可能性のあるバグチェックの原因 | 対処法 |
|---|---|
| 2 台のコンピュータの間のクラスタ接続が， RECNXINTERVAL に指定されている秒数より長い時間破壊されている。その後，接続は修復できないほど破壊されていることが宣言される。後で接続が再確立されると，コンピュータの 1 台が CLUEXIT バグチェックでシャットダウンされる。
この状況は以下の場合に発生する可能性がある。
|
接続が破壊された原因を判断し，問題を解決する。たとえば，電源障害から修復するのに，RECNXINTERVAL の秒数より長い時間がかかる場合は，すべてのコンピュータで RECNXINTERVAL パラメータの値を大きくしなければならない。 |
| クラスタ分断が発生した。クラスタのメンバが別のクラスタのメンバへの接続を検出したか，または確立したか，あるいはフォーリン・クラスタがクォーラム・ファイルから検出された。 | すべてのコンピュータで EXPECTED_VOTES の設定を確認する。 |
| コンピュータで SCSMAXMSG システム・パラメータに対して指定されている値が小さすぎる。 | OpenVMS Cluster のすべてのコンピュータで，SCSMAXMSG の値が少なくともデフォルト値以上に設定されているかどうか確認する。 |
ここでは，ポート通信の問題の診断に役立つ，ポート通信の詳細について説明します。
C.9.1 ポート・ポーリング
CI コンピュータがブートされた後間もなく， CI ポート・ドライバ (PADRIVER) は CI 上で他のアクティブ・ポートを検出するために，構成のポーリングを開始します。通常，ポーラ (poller) は 5 秒ごとに実行されます (PAPOLLINTERVAL システム・パラメータのデフォルト値)。最初のポーリング・パスでは，ケーブル・パス A 上のすべてのアドレスが確認されます。 2 番目のパスでは，パス B 上のすべてのアドレスが確認されます。 3 番目のパスでは，パス A が再び確認されます。以下同様に，この処理が繰り返されます。
ポーラは Request ID (REQID) パケットを，ポーラ自体も含めて可能なすべてのポート番号に送信することにより，プローブを行います。 REQID を受信したアクティブ・ポートは， REQID を送信したポートに ID Received パケット (IDREC) を返します。ポートに接続されているコンピュータが動作していないときでも，ポートは REQID に応答することがあります。
CI，DSSI，またはこれらのインターネットの組み合わせを介して通信している OpenVMS Cluster システムの場合， 2 つのポートとポート・ドライバが ID パケットを正しく交換することができると，ポート・ドライバはスタート・ハンドシェイクを実行します。ポート・ドライバは，コンピュータの種類やオペレーティング・システムのバージョンなど，コンピュータに関する情報を格納したデータグラムを交換します。この交換が成功すると，各コンピュータは仮想サーキットがオープンされていることを宣言します。仮想サーキットのオープンは，他のすべての動作にとって必要な処理です。
C.9.2 LAN 通信
Ethernet または FDDI インターコネクトを含むクラスタの場合， LAN 上のコンピュータを検出するためにマルチキャスト方式が使用されます。約 3 秒ごとに，ポート・エミュレータ・ドライバ (PEDRIVER) は，各 LAN アダプタを介して，クラスタ・グループ番号から求められたクラスタ固有のマルチキャスト・アドレスに，HELLO データグラム・メッセージを送信します。また，ドライバは他のコンピュータから送信されたこれらのメッセージの受信も有効にします。現在オープンされている仮想サーキットを共用していないコンピュータから送信された HELLO データグラム・メッセージをドライバが受信すると，サーキットを作成しようとします。現在仮想サーキットがオープンされているコンピュータから受信した HELLO データグラム・メッセージは，リモート・コンピュータが動作していることを示します。
仮想サーキットを作成するには，標準的な 3 つのメッセージで構成される交換ハンドシェイクが使用されます。ハンドシェイク・メッセージには，送信側コンピュータに関する情報とクラスタ・パスワードの記録が格納されます。これらのパラメータは，受信側コンピュータで確認され，確認が正常終了した場合にだけ，ハンドシェイクが続行されます。したがって，各コンピュータが相手のコンピュータを認証します。最後のメッセージが送信された後，両方のコンピュータで使用できるように，仮想サーキットがオープンされます。
C.9.3 SCS (System Communications Services) 接続
ディスク・クラス・サーバ，接続マネージャ，MSCP および TMSCP サーバなどのシステム・サービスは， SCS (System Communications Services) というプロトコルを使用してコンピュータ間で通信します。SCS は主に，システム間プロセス接続の確立と終了，およびこれらの接続を介したメッセージ・トラフィックのフロー制御を行います。 SCS はポート・ドライバ (たとえば PADRIVER，PBDRIVER， PEDRIVER，PIDRIVER) と，SCSLOA.EXE というオペレーティング・システムのロード可能な部分 (システム初期化時に自動的にロードされる部分) で実装されています。
仮想サーキットがオープンされている場合は，コンピュータは定期的にリモート・コンピュータを調べ，リモート・コンピュータが提供しているシステム・サービスがないかどうか確認します。 SCS ディレクトリ・サービスは，コンピュータが提供しているサービスを認識できるようにするためのサービスであり，コンピュータと HSC サブシステムの両方に常に存在します。システム・サービスが他のコンピュータおよび HSC サブシステムから対応するサービスを検出すると，SCS 接続を相互に確立します。これらの接続は全二重であり，特定の仮想サーキットに関連付けられます。通常，複数の接続が 1 つの仮想サーキットに関連付けられます。
| 前へ | 次へ | 目次 | 索引 |