日本-日本語

製品  >  ソフトウェア  >  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 システム


目次 索引

付録 F
NISCA プロトコルのトラブルシューティング

NISCA は,イーサネットおよび FDDI LAN を介して,クラスタ内の他のノードにディスク I/O やロック・メッセージなどのメッセージを伝達するトランスポート・プロトコルです。NISCA という頭字語は, SCA (System Communications Architecture) に従ってイーサネットまたは FDDI ネットワーク・インターコネクト (NI) を実装しているプロトコルのことを示しています。

OpenVMS ソフトウェア・インタフェースは,NISCA プロトコルを使用して,CI ポート・インタフェースをエミュレートします。つまり,データが LAN を介して転送されることを除けば,ソフトウェア・インタフェースは CI バスのインタフェースと同じです。 NISCA プロトコルを使用することにより,OpenVMS Cluster は特殊なハードウェアを必要とせずに,LAN 上で通信を行うことができます。

ここでは,NISCA トランスポート・プロトコルについて説明し,ネットワーク・マネージャがネットワーク関連の問題を突き止めるのに役立つトラブルシューティングの手法についても示します。LAN で発生したハードウェア・コンポーネント障害のトラブルシューティングは, LAN アナライザを使用して行うのが最適なので,この付録では, LAN 分析ツールの機能と設定についても説明します。

注意

改訂した PEDRIVER 固有のトラブルシューティングの追加情報については,本書の次の改訂版に記載される予定です。



NISCA プロトコルは,SCA の PPD (Port-to-Port Driver) プロトコルを実装したものです。

F.1.1 SCA プロトコル

第 2 章 で説明したように,SCA は,下位レベルの分散アプリケーション (たとえばデバイス・ドライバ,ファイル・サービス,ネットワーク・マネージャ) に効率のよい通信サービスを提供するソフトウェア・アーキテクチャです。

SCA では,SYSAP (System Applications), SCS (System Communications Services),PPD (Port-to-Port Driver),デバイス・ドライバと LAN アダプタの PI (Physical Interconnect: 物理インターコネクト) も含めて, OpenVMS Cluster システム用に多くのプロトコルが指定されています。 図 F-1 では,SCA アーキテクチャを構成する相互に依存するレベルとして,これらのプロトコルを示しています。 図 F-1 では, NISCA プロトコルは,SCA アーキテクチャの PPD レイヤの特定の実装として示されています。

図 F-1 SCA アーキテクチャのプロトコル


表 F-1 は, 図 F-1 に示した SCA プロトコルの各レベルについて説明しています。

表 F-1 SCA プロトコル・レイヤ
プロトコル 説明
SYSAP 各ノードで実行されるクラスタ単位のシステム・アプリケーションを表す。これらのシステム・アプリケーションは,ノード間でメッセージを送信するために通信パスを共用する。システム・アプリケーションの例として,ディスク・クラス・ドライバ (DUDRIVER など), MSCP サーバ,接続マネージャなどがある。
SCS OpenVMS Cluster を中心とした接続を管理し, 仮想サーキットと呼ばれる共通のトランスポートを介して,システム・アプリケーション間のメッセージを多重化する ( 付録 F.1.2 項 を参照)。また,SCS レイヤは,接続で障害が発生したときに,個々のシステム・アプリケーションが適切に応答できるように,各アプリケーションに通知を出す。たとえば, SCS からの通知によって DUDRIVER が起動されてディスクがフェールオーバされたり,クラスタの状態遷移が開始されたりする。 SCS はまた,再接続間隔 (RECNXINTERVAL) の時間のカウントを開始するように,接続マネージャに通知する。
PPD OpenVMS Cluster システム内の他のノードにメッセージ配布サービスを提供する。

PPD レベル 説明
PPD (Port-to-Port Driver) 仮想サーキットを確立し,エラーを処理する。
PPC (Port-to-Port Communication) ポート間通信,データグラム,シーケンス・メッセージ,ブロック転送を提供する。"セグメント化"も PPC レベルで行われる。LAN での大きなデータ・ブロックのセグメント化は, CI バスや DSSI バスとは異なる方法で行われる。 LAN データ・パケットは,以下に示すように,特定の LAN 通信パスで認められているサイズに従って断片化される。

ポート間通信 認められるパケット・サイズ
Ethernet-to-Ethernet 1498 バイト
FDDI-to-Ethernet 1498 バイト
FDDI-to-Ethernet-to-FDDI 1498 バイト
FDDI-to-FDDI 4468 バイト
注意: デフォルト値は,イーサネットの場合も FDDIの場合も 1498 バイトである。

TR (Transport) ノード間に,仮想サーキットというエラーのないパスを提供する ( 付録 F.1.2 項 を参照)。PPC レベルでは,クラスタ内の 2 つのノード間でシーケンス・メッセージとデータグラムを転送するために,仮想サーキットが使用される。
Channel Control (CC) OpenVMS Cluster 内で,ノード間のネットワーク・パス (チャネルと呼ぶ) を管理する。CC レベルでは,ノード間で HELLO データグラム・メッセージを送信することによりチャネルを管理する。ノードは,まだ機能していることを示すために,HELLO データグラム・メッセージを送信する。 TR レベルでは,仮想サーキット・トラフィックを伝達するためにチャネルを使用する。
DX (Datagram Exchange) LAN ドライバへのインタフェース。

PI LAN デバイスへの接続を提供する。PI は,パケットが送受信されるときに使用される LAN ドライバとアダプタを表す。

PI コンポーネント 説明
LAN ドライバ NISCA および他の多くのクライアント (DECnet,TCP/IP,LAT, LAD/LAST など) を多重化し,イーサネットおよび FDDI ネットワーク・インタフェース上でデータグラム・サービスを提供する。
LAN アダプタ LAN ネットワーク・ドライバとアダプタ・ハードウェアで構成される。



F.1.2 通信のために使用されるパス

NISCA プロトコルは, 表 F-2 で説明しているパス上の通信を制御します。

表 F-2 通信パス
パス 説明
仮想サーキット 以下の目的で,OpenVMS Cluster 内のノード間の信頼性の高いポート間通信を提供する共通のトランスポート。

  • 重複や紛失を発生させずに,メッセージを確実に配布する。各ポートは他の各リモート・ポートとの間で仮想サーキットを維持する。

  • メッセージの順序を確保する。各仮想サーキット・シーケンス番号が個々のパケットで使用される。各送信メッセージはシーケンス番号を転送するため,重複するメッセージは破棄される。

各ポートの仮想サーキット記述子テーブルは,そのポート間サーキットの状態を示す。2 つのポート間に仮想サーキットが作成された後,ノード内の SYSAP 間で通信を確立することができる。

チャネル 異なるノードにある 2 つの LAN アダプタ間の論理通信パス。ノード間のチャネルは,2 つ 1 組のアダプタとそれを接続するネットワークによって決定される。たとえば,それぞれ 2 つのアダプタを装備している 2 つのノードは,4 つのチャネルを確立することができる。特定の仮想サーキットによって伝達されたメッセージは,2 つのノードを接続するどのチャネルを介しても送信できる。

注意: チャネルと仮想サーキットの相違は,チャネルがデータグラム・サービスのためのパスを提供できるという点にあります。仮想サーキットはチャネルの上の層にあり,ノード間にエラーのないパスを提供します。OpenVMS Cluster では,ノード間に複数のチャネルが存在できますが,仮想サーキットは同時に 2 つのノード間に 1 つしか存在できません。

F.1.3 PEDRIVER

ポート・エミュレータ・ドライバである PEDRIVER は, NISCA プロトコルを実装し,ローカル LAN ポートとリモート LAN ポートの間の通信のためのチャネルを確立し,制御します。

PEDRIVER は,メッセージが順に配布されることを保証するパケット配布サービス (NISCA プロトコルの TR レベル) を実装します。特定の仮想サーキットによって伝達されるメッセージは,2 つのノードを接続するどのチャネルを通じても送信できます。チャネルの選択は,メッセージの送信側 (PEDRIVER) によって決定されます。メッセージを送信するノードは,どのチャネルも選択できるため,受信側の PEDRIVER は,どのチャネルからでもメッセージを受信できる準備をしておかなければなりません。

どの時点でも,TR レベルは特定の仮想サーキットのトラフィックを伝達するために,1 つの "優先チャネル" を使用します。

関連項目: 転送チャネルの選択方法については, 付録 G を参照してください。

F.2 LAN 通信の問題への対処

ここでは,LAN 通信の問題とその対処法について説明します。

F.2.1 症状

OpenVMS Cluster システムで発生する通信の問題は,以下のような症状によって示されることがあります。

  • パフォーマンスの低下

  • コンソール・メッセージ

    • PEA0 (PEDRIVER) からコンソールに表示される "Virtual circuit closed" というメッセージ

    • コンソールに表示される "Connection loss" という OPCOM メッセージ

    • CLUEXIT バグチェック

    • コンソールに表示される "Excessive packet losses on LAN Path" というメッセージ

  • 短時間 (10 分未満) に 1 つの仮想サーキットまたは複数の仮想サーキットが繰り返し失われる現象

複雑な診断手順を開始する前に,明白な問題を見逃さないようにしてください。ハードウェアの構成と接続が正しいかどうか,およびネットワークが起動されているかどうかは,必ず確認してください。また,OpenVMS Cluster のすべてのノードでシステム・パラメータが正しく設定されているかどうかも確認してください。

F.2.2 トラフィックの制御

OpenVMS Cluster システムでは,他の LAN プロトコルの場合より,かなり大量のトラフィックが生成されることに注意してください。ネットワークに関連しているように見えるクラスタの動作の問題が,実際にはソフトウェア,ハードウェア,ユーザ・エラーに関係していることがよくあります。たとえば,大量のトラフィックが発生したからといって,それは必ずしも OpenVMS Cluster ネットワークの問題を示すわけではありません。生成されるトラフィックの量は,ユーザがシステムをどのように利用しているかや,追加インターコネクト (DSSI や CI など) を利用して OpenVMS Cluster がどのように構成されているかに応じて異なります。

OpenVMS Cluster で生成されるトラフィックの量が,予想したレベルや適切なレベルを超える場合は,以下の方法でトラフィックのレベルを削減することができます。

  • DSSI または CI インターコネクトの追加

  • マシン間でのユーザ負荷の移動

  • LAN セグメントの追加,および OpenVMS Cluster システムでの LAN 接続の再構成



F.2.3 LAN パス上のパケットの大量損失

OpenVMS バージョン 7.3 より前のバージョンでは, SCS 仮想サーキット封鎖が, LAN パスが使用できなくなったことを示す最初の通知でした。 OpenVMS バージョン 7.3 では,最後に使用できる LAN パスが非常に高い比率でパケットを損失すると, PEDRIVER は以下のコンソール・メッセージを表示します。


%PEA0, Excessive packet losses on LAN path from local-device-name 
 to device-name on REMOTE NODE node-name 

このメッセージは,PEDRIVER が,ローカル・デバイス,介在するネットワーク・デバイス,およびリモート・ノード上のデバイスで構成される LAN パス上で,極端に高い比率でパケットの再送しなければならなかった後に表示されます。このメッセージは,LAN パスの品質が低下し,リモート・ノードと信頼できる通信が使用できなくなるところに近づいているか,または達したことを示します。パケットの損失が続くと,リモート・ノードへの仮想サーキットが切られることがあります。さらに,LAN パケットの損失が大きい状態で動作し続けると,パケット損失検出タイムアウトおよびパケットの再送による通信遅延のため,性能が大幅に低下します。

次のようにして修復します。

  1. 問題がローカル LAN デバイスおよびリモート LAN デバイスにあるかどうかを調べるため,それらのデバイスのエラー・カウントをチェックします。各ノードで以下のコマンドを実行します。


    $ SHOW DEVICE local-device-name 
    $ MC SCACP 
    SCACP> SHOW LAN device-name 
    $ MC LANCP 
    LANCP> SHOW DEVICE device-name/COUNT 
    

  2. ローカル・デバイスのデバイス・エラー・カウントが正常範囲内にある場合,デバイス間の LAN パスを診断するよう,ネットワーク管理者に連絡してください。



F.2.4 ネットワークに関する予備診断

さまざまな症状や予備診断によって,ネットワークに問題のある可能性が示された場合,LAN 通信障害のトラブルシューティングは, 付録 C で説明した手順から開始しなければなりません。 付録 C の説明は, OpenVMS Cluster の以下の動作中に発生した一般的なイーサネットおよび FDDI LAN 通信障害を診断し,解決するのに役立ちます。

  • コンピュータまたはサテライトをブートできない場合

  • コンピュータが OpenVMS Cluster に参加できない場合

  • 実行時にスタートアップ・プロシージャが完了しない場合

  • OpenVMS Cluster がハングした場合

付録 C で説明した手順では,診断プロセスで多くのパラメータを確認しなければなりません。システム・パラメータの設定は,効果的な OpenVMS Cluster 通信を行うために重要な役割を果たすため, 付録 F.2.6 項 では,LAN ブリッジ,ディスク・フェールオーバ,チャネル可用性のタイミングにとって特に重要ないくつかのシステム・パラメータについて説明しています。

F.2.5 断続的なエラーの追跡

PEDRIVER 通信はチャネルを基礎にしているため, LAN ネットワークの問題は通常,次のように分類できます。

  • チャネルの形成と管理
    チャネルは,HELLO データグラム・メッセージがリモート・システムから送られてきたときに形成されます。 HELLO データグラム・メッセージが受信されない場合や,チャネル制御メッセージに不正なデータが含まれている場合には,障害が発生することがあります。

  • 再送
    適切な構成の OpenVMS Cluster システムでは,ノード間で大量の再送は実行されないはずです。数秒ごとに 1 回より高い頻度でノード間で再送が行われる場合,ネットワークを調べる必要があります。

このレベルでは,一般にエラーが断続的に発生するため,障害の診断は他のレベルより複雑です。さらに,PEDRIVER は,チャネルが使用できなくなったときにそのことを認識し,この情報をもとにエラー回復を実行しますが,チャネル障害が発生したときに通知を提供するわけではありません。PEDRIVER は,仮想サーキット障害の場合にだけ通知を提供します。

しかし,SYS$EXAMPLES で提供されている Local Area OpenVMS Cluster Network Failure Analysis Program (LAVC$FAILURE_ANALYSIS) を使用すると,チャネルの状態に関する PEDRIVER の情報を利用するのに役立ちます。 LAVC$FAILURE_ANALYSIS プログラム ( 付録 D を参照) は,実行時に発生した LAN ネットワーク・コンポーネントでのハードウェア障害など,長期的なチャネル障害を分析します。

このプログラムでは,LAN ハードウェア構成を記述するテーブルが使用されます。チャネル障害が発生すると,PEDRIVER はテーブルに指定されているハードウェア構成を利用して,どのコンポーネントが障害の原因になっているか突き止めます。PEDRIVER は OPCOM 表示を通じて,疑いのあるコンポーネントを報告します。その情報をもとに,修理や交換のために,LAN コンポーネントを切り分けることができます。

関連項目: NISCA プロトコルで発生する可能性のある問題と,その問題の診断および解決方法については, 付録 F.7 節 を参照してください。


目次 索引

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