Compaq OpenVMS
OpenVMS Cluster システム


前へ 次へ 目次 索引


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

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

F.2.1 症状

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

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

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

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

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

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 通信障害を診断し,解決するのに役立ちます。

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

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

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

このレベルでは,一般にエラーが断続的に発生するため,障害の診断は他のレベルより複雑です。さらに,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 節 を参照してください。

F.2.6 システム・パラメータの確認

表 F-3 では,OpenVMS Cluster 内の LAN の回復およびフェールオーバの時間制限に関するいくつかのシステム・パラメータについて説明しています。

表 F-3 タイミングを制御するシステム・パラメータ
パラメータ 使用方法
RECNXINTERVAL
仮想サーキット障害が検出された後, OpenVMS Cluster からノードを削除するまでに待つ時間を定義する。このような障害は,LAN ブリッジ障害から発生することがある。 ネットワークで複数のパスを使用しており,LAN ブリッジ間でフェールオーバされても,OpenVMS Cluster が動作を続行できるようにするときは,RECNXINTERVAL の値が,これらのパスでフェールオーバされるのに必要な時間より大きな値になるように設定する。

関連項目: このパラメータを計算する公式については, 第 3.4.7 項 を参照。

MVTIMEOUT
障害メッセージをアプリケーションに返す前に, OpenVMS オペレーティング・システムがディスクへのパスの回復を試行する時間を定義する。 イーサネットまたは FDDI を介してディスクをサービスするように, OpenVMS Cluster 構成を設定するときに関連するパラメータである。 MVTIMEOUT は RECNXINTERVALに類似しているが, RECNXINTERVAL が CPU から CPU であるのに対し, MVTIMEOUT は CPU からディスクである点が異なる。
SHADOW_MBR_TIMEOUT
Volume Shadowing for OpenVMS が複数メンバのシャドウ・セットの中の 1 つのメンバで,一時的なディスク・エラーから回復を試行する時間を定義する。 SHADOW_MBR_TIMEOUT は障害のあるシャドウ・セット・メンバを直ちに削除するので,MVTIMEOUT と異なる。障害のあるメンバが削除された後,残りのシャドウ・セット・メンバはより迅速に回復できるようになる。

注意: TIMVCFAIL システム・パラメータは,通信障害を検出するのに必要な時間を最適化するパラメータですが,LAN 通信に対して使用することは推奨できません。このパラメータは,CI 接続および DSSI 接続のためのものです。PEDRIVER (イーサネットおよび FDDI 用のドライバ) は通常,8〜9 秒のリスン時間切れの TIMVCFAIL で提供される検出より優れています。

F.2.7 チャネル時間切れ

チャネル時間切れは, 表 F-4 に説明しているように,PEDRIVER ドライバによって検出されます。

表 F-4 チャネル時間切れの検出
PEDRIVER の動作 説明
少なくとも 3 秒に 1 回ずつチャネル上を送信される HELLO データグラム・メッセージを受信する。 OpenVMS Cluster 内の各ノードは,各 LAN アダプタで HELLO データグラム・メッセージをマルチキャストして,まだ機能していることを他のノードに通知する。受信側のノードは,ネットワーク接続がまだ機能していることを認識する。
HELLO データグラムまたはシーケンス・メッセージが 8〜9 秒間に受信されなかった場合,チャネルを閉じる。 HELLO データグラム・メッセージは少なくとも 3 秒に 1 回ずつ送信されるため,少なくとも 2 つの HELLO データグラム・メッセージが紛失し,シーケンス・メッセージ・トラフィックも受信できなかった場合だけ, PEDRIVER はチャネルを時間切れにする。
仮想サーキットは以下の場合に閉じられる。

  • チャネルを使用できない。

  • 使用できるチャネルのパケット・サイズが不十分である。

使用できるチャネルのパケット・サイズが,仮想サーキットに対して使用されているチャネルより小さい場合を除き,ノードへの他のチャネルが使用できる場合,仮想サーキットはクローズされない。たとえば,チャネルが FDDI からイーサネットにフェールオーバされた場合,PEDRIVER は仮想サーキットをクローズし,イーサネット・セグメント化にとって必要な小さなパケット・サイズのネゴシエーションが行われた後,仮想サーキットを再びオープンする。
チャネルがクローズされても,エラーは報告されない。 仮想サーキットがシャットダウンされるまで, OPCOM "Connection loss" エラーや SYSAP メッセージはユーザや他のシステム・アプリケーションに送信されない。このことは重要である。特に,ノードに対して複数のパスが存在し, LAN ハードウェア障害が発生した場合は,このことが重要である。この場合,エラー・メッセージが受信されないことがあるため, PEDRIVER は他の使用可能なチャネルを通じて仮想サーキットを引き続き使用する。
チャネルが再び使用可能になったときに,仮想サーキットを再び確立する。 HELLO データグラム・メッセージが再び受信されると, PEDRIVER はチャネルを再びオープンする。

F.3 LAN 通信を監視するための SDA の使用

ここでは,SDA を使用して LAN 通信を監視する方法について説明します。

F.3.1 問題領域の切り分け

システムで実行時に断続的な障害が発生していることを示す症状が現れた場合,ネットワークに問題があるのか,システムの他の何らかの動作によって問題が発生しているのかを判断しなければなりません。

一般に,NISCA プロトコルやネットワークで発生した問題は, OpenVMS System Dump Analyzer ユーティリティ (SDA) を使用して診断できます。SDA は,OpenVMS Cluster システムを実行している特定のノードで問題を切り分けるための効果的なツールです。

関連項目: この後の説明では,SDA コマンドと修飾子を使用します。SDA の詳細については,『OpenVMS Alpha System Analysis Tools Manual』または『OpenVMS VAX System Dump Analyzer Utility Manual』を参照してください。

F.3.2 SDA コマンド SHOW PORT

SDA コマンド SHOW PORT は,特に PEDRIVER と LAN アダプタのトラブルシューティングで役立つ関連情報を提供します。まず,SHOW PORT コマンドを入力します。このコマンドを入力すると,SDA はクラスタ・シンボルを定義します。 例 F-1 では,SHOW PORT コマンドが OpenVMS Cluster のデータ構造の要約をどのように表示するかを示しています。

例 F-1 SDA コマンド SHOW PORT の表示

$ ANALYZE/SYSTEM
SDA> SHOW PORT
VAXcluster data structures 
-------------------------- 
 
                  --- PDT Summary Page --- 
 
 PDT Address          Type         Device          Driver Name 
 -----------          ----         -------         ----------- 
 
  80C3DBA0             pa          PAA0            PADRIVER 
  80C6F7A0             pe          PEA0            PEDRIVER

F.3.3 仮想サーキットの監視

ローカル・ノード (SDA を実行しているノード) と別のリモート・ノードの間でメッセージを伝達している仮想サーキット (VC) に関する情報を確認するには, SDA コマンド SHOW PORT/VC=VC_remote-node-name を入力します。 例 F-2 は,ローカル・ノードとリモート・ノード NODE11 の間で動作している仮想チャネルに関する情報を調べる方法を示しています。

例 F-2 SDA コマンド SHOW PORT/VC の表示

SDA> SHOW PORT/VC=VC_NODE11
VAXcluster data structures 
-------------------------- 
                 --- Virtual Circuit (VC) 98625380 --- 
Remote System Name:  NODE11  (0:VAX)     Remote SCSSYSTEMID:  19583 
Local System ID:  217 (D9)              Status: 0005 open,path 
------ Transmit -------  ----- VC Closures -----  (7)--- Congestion Control ---- 
Msg Xmt(1)      46193196  SeqMsg TMO            0  Pipe Quota/Slo/Max(8) 31/ 7/31 
  Unsequence          3  CC DFQ Empty          0  Pipe Quota Reached(9)   213481 
  Sequence     41973703  Topology Change(5)     0  Xmt C/T(10)              0/1984 
  ReXmt(2)       128/106  NPAGEDYN Low(6)        0  RndTrp uS(11)        18540+7764 
  Lone ACK      4219362                           UnAcked Msgs                0 
Bytes Xmt     137312089                           CMD Queue Len/Max        0/21 
------- Receive -------  - Messages  Discarded -  ----- Channel Selection ----- 
Msg Rcv(3)      47612604  No Xmt Chan           0  Preferred Channel    9867F400 
  Unsequence          3  Rcv Short Msg         0  Delay Time           FAAD63E0 
  Sequence     37877271  Illegal Seq Msg       0  Buffer Size              1424 
  ReRcv(4)         13987  Bad Checksum          0  Channel Count              18 
  Lone ACK      9721030  TR DFQ Empty          0  Channel Selections      32138 
  Cache             314  TR MFQ Empty          0  Protocol                1.3.0 
  Ill ACK             0  CC MFQ Empty          0  Open(12) 8-FEB-1994 17:00:05.12 
Bytes Rcv    3821742649  Cache Miss            0  Cls(13) 17-NOV-1858 00:00:00.00 

SHOW PORT/VC=VC_remote-node-name コマンドは,ターゲット・ノードの仮想サーキットに関するパフォーマンス情報を表示します。表示では,パフォーマンスの統計情報はカテゴリ別に分類して表示されます。各カテゴリでは,リモート・ノードに送信されたパケット,リモート・ノードから受信したパケット,輻輳制御の動作などの情報が要約されます。問題を切り分けるのに最も役立つ統計情報については, 例 F_2 で番号によって示し, 表 F-5 で説明しています。

注意: 例 F-2 に示したカウンタは,固定サイズのフィールドに格納され,フィールドが最大値になったとき (またはシステムが再ブートされるとき),自動的に 0 にリセットされます。各フィールドの最大サイズ,および値が増加する速度は異なっているため,フィールド・カウンタは異なるときにリセットされます。したがって,長い間実行されているシステムの場合,一部のフィールドの値が不合理であったり,矛盾するように見えることがあります。

表 F-5 SHOW PORT/VC の表示
フィールド 説明
(1) Msg Xmt (送信されたメッセージ) シーケンス・メッセージと非シーケンス・メッセージ (チャネル制御),確認応答メッセージも含めて,仮想サーキットを介してリモート・ノードに送信されたパケットの総数を示す (アプリケーション・データはすべて,シーケンス・メッセージで送信される)。シーケンス・メッセージと確認応答メッセージのカウンタは,他の大部分のフィールドより増大する速度が速い。
(2) ReXmt (再送) 仮想サーキットの再送の数と再送に関連する時間切れの数を示す。

  • ReXmt フィールドの右端の数字 (106) は,発生した時間切れの回数を示す。時間切れは以下のいずれかの問題があることを示す。

    • リモート・システム NODE11 が UPNVMS から送信されたシーケンス・メッセージを受信できなかった。

    • シーケンス・メッセージは到着したが,NODE11 へのトランジットで遅延が発生した。

    • ローカル・システム UPNVMS が,リモート・ノード NODE11 に送信されたメッセージへの確認応答メッセージを受信できなかった。

    • 確認応答メッセージは到着したが,NODE11 からのトランジットで遅延が発生した。

    ネットワーク内またはノードのいずれかでの輻輳により,以下の問題が発生することがある。

    • ネットワーク内で輻輳が発生すると,パケットが遅延したり,紛失する可能性がある。ネットワーク・ハードウェアに問題がある場合も,パケットが紛失する可能性がある。

    • UPNVMS または NODE11 で輻輳が発生すると,アダプタ内でキューイングが発生するためにパケットが遅延することがあり,バッファ領域が不足するためにパケットが破棄されることもある。

  • 左端の数字 (128) は,実際に再送されたパケットの数を示す。たとえば,ネットワークで同時に 2 つのパケットが紛失した場合,時間切れは 1 回だけカウントされるが,2 つのパケットが再送される。あらかじめ決められた時間切れの範囲内で送信されたパケットに対する確認応答メッセージをローカル・ノードが受信しないと,再送が行われる。

    特定の数の再送は発生しても仕方がないが (特に負荷の高いネットワークの場合),再送の回数があまり多いと,ネットワークの帯域幅が無駄に使用され,負荷が非常に高いことあるいは断続的にハードウェア障害が発生していることを示している。ReXmt フィールドの左端の値が,Msg Xmt フィールドに示された送信メッセージの総数の約 0.01〜0.05% より大きい場合,おそらく OpenVMS Cluster システムで輻輳によってネットワークの問題やローカル・ロスが発生していると考えられる。

(3) Msg Rcv (受信メッセージ) この仮想サーキットを介してローカル・ノード UPNVMS が受信したメッセージの総数を示す。シーケンス・メッセージと確認応答メッセージの値は通常,他の値より急速に増大する。
(4) ReRcv (受信) このシステムで重複して受信したパケットの数を表示する。ローカル・ノードがすでに受信している場合でも,リモート・システムがパケットを再送することがある。たとえば,パケットの遅延時間が累積され,リモート・ノードが時間切れの値として使用している見積りラウンド・トリップ時間より長い時間がかかって確認応答メッセージが到着した場合,この状況が発生する。したがって,リモート・ノードは,不要であってもパケットを再送する。

リモート・ノードがラウンド・トリップ遅延時間の見積りを低い値に設定しても,直接的に問題はないが,リモート・ノードで行われる再送とその後の輻輳制御動作によって,データのスループットに悪影響がある。この値が大きい場合,ネットワークまたはアダプタで頻繁に輻輳が発生し,遅延時間が非常に長くなっている可能性がある。 ReRcv フィールドの値が,受信した総メッセージの約 0.01〜0.05% より大きい場合,輻輳またはネットワーク遅延の問題があると考えられる。

(5) Topology Change PEDRIVER が FDDI から Ethernet へのフェールオーバを実行した回数を示す。この結果,仮想サーキットのクローズと再オープンが必要になる。 例 F-2 では,フェールオーバは発生していない。しかし,このフィールドに多くのフェールオーバが発生したことが示される場合,問題は FDDI リングにある可能性がある。
(6) NPAGEDYN (非ページング動的プール) ローカル・ノードでプール割り当て障害が発生したために,仮想サーキットがクローズされた回数を示す。この値が 0 以外の場合,おそらくローカル・ノードで NPAGEDYN システム・パラメータの値を大きくしなければならない。
(7) Congestion Control パイプ・クォータ (確認応答メッセージおよび再送時時間切れを受信する前にリモート・ノードに送信できる ["パイプ" に置くことができる] メッセージの数) を制御するために,仮想サーキットに関する情報を表示する。PEDRIVER は,ネットワークの輻輳を制御するために,パイプ・クォータおよび時間切れの値を変更する。
(8) Pipe Quota/Slo/Max パイプ・クォータを監視する現在のしきい値を示す。

  • 左端の数字 (31) は,パイプ・クォータの現在の値 (送信ウィンドウ) である。時間切れが発生した後,パイプ・クォータは,輻輳を低下させるために 1 にリセットされ,確認応答メッセージを受信するたびに迅速に増大することが認められる。

  • 中央の数字 (7) は,ネットワークで再び輻輳が発生するのを防止するために使用される,ゆるやかに拡大するしきい値 (拡大速度が低下されるときのサイズ) である。

  • 右端の数字 (31) は,チャネル制限をもとに,VC に対して現在認められている最大値である。

関連項目: PEDRIVER の輻輳制御とチャネル選択の詳細については, 付録 G を参照。

(9) Pipe Quota Reached 送信ウィンドウ全体が満杯になった回数を示す。この値が送信されたシーケンス・メッセージの数と比べて小さい場合,ローカル・ノードがリモート・ノードに大きなデータ・バーストを送信していないことを示す。
(10) Xmt C/T (送信カウント/ターゲット) 最後にパイプ・クォータが増大された後,正常終了した送信の数と,パイプ・クォータの増大が認められているターゲット値を示す。この例では,パイプ・クォータはすでに最大値 (31) になっているため,カウントは 0 であり,正常終了した送信の数はカウントされていない。
(11) RndTrp uS (マイクロ秒単位のラウンド・トリップ時間) 再送の時間切れをマイクロ秒単位で計算するために使用される値を表示する。左端の数字 (18540) は平均ラウンド・トリップ時間であり,右端の数字 (7764) はラウンド・トリップ時間の平均偏差である。この例では,値は,ラウンド・トリップが約 19 ミリ秒±約 8 ミリ秒であることを示している。
(12) Open and Cls 仮想サーキットが最後に大幅に変更されたときの,オープン (Open) とクローズ (Cls) タイムスタンプを表示する。短い時間 (10 分以内) に 1 つ以上の仮想サーキットが繰り返し失われる場合,ネットワークに問題があると考えられる。
(13) Cls クラッシュ・ダンプを分析する場合,クラッシュ・ダンプの時刻がチャネル・クローズのタイムスタンプ (Cls) に対応しているかどうか確認しなければならない。


前へ 次へ 目次 索引