| 前へ | 次へ | 目次 | 索引 |
ここでは，LAN 通信の問題とその対処法について説明します。
F.2.1 症状
OpenVMS Cluster システムで発生する通信の問題は，以下のような症状によって示されることがあります。
複雑な診断手順を開始する前に，明白な問題を見逃さないようにしてください。ハードウェアの構成と接続が正しいかどうか，およびネットワークが起動されているかどうかは，必ず確認してください。また，OpenVMS Cluster のすべてのノードでシステム・パラメータが正しく設定されているかどうかも確認してください。
F.2.2 トラフィックの制御
OpenVMS Cluster システムでは，他の LAN プロトコルの場合より，かなり大量のトラフィックが生成されることに注意してください。ネットワークに関連しているように見えるクラスタの動作の問題が，実際にはソフトウェア，ハードウェア，ユーザ・エラーに関係していることがよくあります。たとえば，大量のトラフィックが発生したからといって，それは必ずしも OpenVMS Cluster ネットワークの問題を示すわけではありません。生成されるトラフィックの量は，ユーザがシステムをどのように利用しているかや，追加インターコネクト (DSSI や CI など) を利用して OpenVMS Cluster がどのように構成されているかに応じて異なります。
OpenVMS Cluster で生成されるトラフィックの量が，予想したレベルや適切なレベルを超える場合は，以下の方法でトラフィックのレベルを削減することができます。
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 パケットの損失が大きい状態で動作し続けると，パケット損失検出タイムアウトおよびパケットの再送による通信遅延のため，性能が大幅に低下します。
次のようにして修復します。
$ SHOW DEVICE local-device-name $ MC SCACP SCACP> SHOW LAN device-name $ MC LANCP LANCP> SHOW DEVICE device-name/COUNT |
さまざまな症状や予備診断によって，ネットワークに問題のある可能性が示された場合，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 の回復およびフェールオーバの時間制限に関するいくつかのシステム・パラメータについて説明しています。
| パラメータ | 使用方法 |
|---|---|
| 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 ドライバによって検出されます。
| 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 はチャネルを再びオープンする。 |
ここでは，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
|
ローカル・ノード (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 にリセットされます。各フィールドの最大サイズ，および値が増加する速度は異なっているため，フィールド・カウンタは異なるときにリセットされます。したがって，長い間実行されているシステムの場合，一部のフィールドの値が不合理であったり，矛盾するように見えることがあります。
| フィールド | 説明 |
|---|---|
| (1) Msg Xmt (送信されたメッセージ) | シーケンス・メッセージと非シーケンス・メッセージ (チャネル制御)，確認応答メッセージも含めて，仮想サーキットを介してリモート・ノードに送信されたパケットの総数を示す (アプリケーション・データはすべて，シーケンス・メッセージで送信される)。シーケンス・メッセージと確認応答メッセージのカウンタは，他の大部分のフィールドより増大する速度が速い。 |
| (2) ReXmt (再送) | 仮想サーキットの再送の数と再送に関連する時間切れの数を示す。
|
| (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 | パイプ・クォータを監視する現在のしきい値を示す。
関連項目: 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) に対応しているかどうか確認しなければならない。 |
| 前へ | 次へ | 目次 | 索引 |