| 前へ | 次へ | 目次 | 索引 |
ここでは，以下のトラブルシューティング操作を実行するのに役立つ情報をまとめます。
予備チェックを実行し，必要に応じて適切な処置を実行した後，コンピュータがまだブートできなかったり，クラスタに参加できない場合は， C.2 〜
C.4 項の手順に従って，障害からの回復を試みてください。
C.1.2 ブート・イベント・シーケンス
診断手順と回復手順を効果的に実行するには，コンピュータがブートし，クラスタに参加するときに，どのようなイベントが実行されるかを理解しておく必要があります。ここでは，これらのイベントの概要を示し，コンソールに表示される典型的なメッセージも示します。
発生するイベントは，コンピュータが新しいクラスタにブートされる最初のコンピュータであるのか，アクティブ・クラスタでブートされているのかに応じて異なります。また，一部のイベント (パスワードとグループ番号が格納されているクラスタ・データベースのロードなど) は，LAN 上の OpenVMS Cluster システムでのみ発生します。
通常のイベント・シーケンスは 表 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 サーバもロードできる。
|
| 3 | コンピュータがクラスタを検出すると，そのクラスタに参加しようとする。クラスタが検出されると，接続マネージャは以下の形式で 1 つ以上のメッセージを表示する。
%CNXMAN, Sending VAXcluster membership request to system X... クラスタを検出できない場合，クォーラムを確立できるだけの十分なボーツ数があるとき (つまり，十分な数のボーツ・コンピュータがブートされているとき) は，接続マネージャはクラスタを作成する。 |
| 4 | ブート・コンピュータがクラスタに参加すると，接続マネージャは以下の形式のメッセージを表示する。
%CNXMAN, now a VAXcluster member -- system X... コンピュータのブート中にクォーラムが失われた場合や，コンピュータが 2 分間のブート中にクラスタに参加できない場合は，接続マネージャは以下のようなメッセージを表示する。
最後の 2 つのメッセージは，すでに確立されている接続を示している。 |
| 5 | クラスタにクォーラム・ディスクが含まれている場合は，以下のメッセージも表示されることがある。
%CNXMAN, Using remote access method for quorum disk 最初のメッセージは，ディスクが使用できない状態であるか， MSCP サーバを介してアクセスされるために，接続マネージャがクォーラム・ディスクに直接アクセスできないことを示している。ディスクに直接アクセス可能なクラスタ内の別のコンピュータが，ディスクに対して信頼性のある接続が確立されているかどうかを確認しなければならない。 2 番目のメッセージは，接続マネージャがクォーラム・ディスクに直接アクセスでき，ディスクに直接アクセスできないコンピュータにディスクの状態情報を提供できることを示している。 注意: クォーラム・ディスクがまだ構成されていないために，最初は接続マネージャがクォーラム・ディスクを確認できないことがある。その場合，接続マネージャは，最初はリモート・アクセスを使用し，後でローカル・アクセスに切り換える。 |
| 6 | コンピュータがクラスタに参加した後，通常のスタートアップ・プロシージャが実行される。最初に実行される機能の 1 つとして，OPCOM プロセスが起動される。
%%%%%%%%%%% OPCOM 15-JAN-1994 16:33:55.33 %%%%%%%%%%% |
| 7 | 他のコンピュータがクラスタに参加すると，OPCOM は以下のようなメッセージを表示する。
%%%%% OPCOM 15-JAN-1994 16:34:25.23 %%%%% (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 テーブルのすべてのディスクを表示する。
|
C.3 サテライトのブート障害
サテライトを正しくブートするには，サテライトが LAN を介して MOP サーバと通信しなければなりません。この通信を確認するには， DECnet イベント・ログを使用できます。以下の操作を実行してください。
サテライト・ブートのトラブルシューティングについては， C.3.2 〜 C.3.5 項を参照してください。トラブルシューティングの説明では，システム・パラメータが正しく設定されているかどうか確認することが頻繁に求められます。
C.3.1 接続メッセージの表示
会話型ブートで接続メッセージの表示を有効にするには，以下の操作を行います。
| ステップ | 操作 |
|---|---|
| 1 | サテライトの NISCS_CONV_BOOT システム・パラメータを 1 に設定することにより，会話型ブートを有効に設定する。 Alpha システムでは，ディスク・サーバのシステム・ルートで ALPHAVMSSYS.PAR ファイルを更新し，VAX システムでは VAXVMSSYS.PAR ファイルを更新する。 |
| 2 | 会話型ブートを実行する。
++Alpha システムでは，コンソールから以下のコマンドを入力する。
|
+VAX システムでは，レジスタ R5 のビット <0> をセットする。たとえば， VAXstation 3100 システムでは，コンソールから以下のコマンドを入力する。
>>> B/1 |
|
| 3 | 接続メッセージを確認する。
サテライト・ブートで接続メッセージを表示して，大規模なクラスタのどのシステムがブート・プロセスでクラスタ・サテライトにシステム・ディスクをサービスしているかを判断する。ブートの問題が発生した場合は，この表示を利用することで，システム・ディスクを現在サービスしているシステムの問題を切り分けるのに役立つ。その後，サーバ・システムに複数の LAN アダプタがある場合は，特定の LAN アダプタを切り分けることができる。 |
| 4 | LAN アダプタを切り分ける。
LAN アダプタを切り分けるには，1 つのアダプタだけが接続された状態でリブートを行う。つまり，サーバ・システムで 1 つの LAN アダプタを除き，他のすべてのアダプタを切断し，サテライトをリブートする。そのアダプタがシステム・ディスク・サーバに接続されているときに，サテライトが正しくブートされる場合は，他の LAN アダプタに対しても同じ手順を実行する。問題のあるアダプタを突き止めることができるまで，この操作を繰り返す。 |
サテライトをブートできない場合は，ここで説明する手順に従って， OpenVMS Cluster システムで問題点を診断し，修正します。
| ステップ | 操作 | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| 1 | ブート・デバイスが使用可能であるかどうか確認する。複数のシステム・ディスクからサテライトがブートされるようなクラスタの場合は，このチェックが特に重要である。 | ||||||||
| 2 | DECnet ネットワークが起動され，動作しているかどうか確認する。 | ||||||||
| 3 | クラスタ・グループ・コードとパスワードを確認する。クラスタ・グループ・コードとパスワードは， CLUSTER_CONFIG.COM プロシージャを使用して設定される。 | ||||||||
| 4 | 正しい OpenVMS Alpha ライセンスと OpenVMS VAX ライセンスをインストールしたかどうか確認する。 | ||||||||
| 5 | 各サテライト・ノードで，以下のようにシステム・パラメータの値が設定されているかどうか確認する。
VAXCLUSTER = 2 SCS パラメータ値は，システム構成に応じて異なる設定になる。 関連項目: これらの SCS パラメータの設定方法については， 付録 A を参照。 ブートできないサテライト・ノードでシステム・パラメータ値を確認するには， OpenVMS Cluster で実行中のシステムのうち，サテライト・ノードのローカル・ノードにアクセスできるシステムで， SYSGEN ユーティリティを起動する (SYSGEN ユーティリティは，同じ種類のオペレーティング・システムを稼動しているノードから起動しなければならない。たとえば，Alpha サテライト・ノードをトラブルシューティングする場合は，Alpha システムで SYSGEN ユーティリティを実行しなければならない)。システム・パラメータが以下のように設定されているかどうか確認する。
|
| 前へ | 次へ | 目次 | 索引 |