日本-日本語 |
|
|
|
OpenVMS マニュアル |
|
HP OpenVMS
|
目次 | 索引 |
F.6 チャネルの形成 |
チャネルの形成に関する問題は,2 つのノードが LAN アダプタ間で正常に通信できないときに発生します。
表 F-7 では,チャネルの形成について 1 手順ずつ詳しく説明しています。 F.6.1 チャネルが形成される方法
手順 | 操作 | ||||||
---|---|---|---|---|---|---|---|
1 | ノードが HELLO データグラムを LAN アダプタから別のクラスタ・ノードの LAN アダプタに送信するときに,チャネルが形成される。これが新しいリモート LAN アダプタ・アドレスである場合や,対応するチャネルがクローズされている場合は, HELLO データグラムを受信するリモート・ノードは,最大 2 秒間の遅延の後,発信側のノードに CCSTART データグラムを送信する。 | ||||||
2 | CCSTARTデータグラムを受信すると,発信側のノードはクラスタ・パスワードを確認し,パスワードが正しい場合,ノードは VERF データグラムを応答し,リモート・ノードが VACK データグラムを送信するまで最大 5 秒間待つ (VERF,VACK,CCSTART,HELLO データグラムについては, 付録 F.8.5 項 を参照)。 | ||||||
3 | VERF データグラムを受信すると,リモート・ノードはクラスタ・パスワードを確認する。パスワードが正しい場合,ノードは VACK データグラムを応答し,チャネルをオープンされているものとしてマークする ( 図 F-3 を参照)。 | ||||||
4 |
|
||||||
5 | チャネルが形成された後,HELLO データグラム・メッセージの定期的なマルチキャストによって,チャネルはオープン状態に維持される。各ノードは,各 LAN アダプタを介して少なくとも 3.0 秒に 1 回ずつ,HELLO データグラム・メッセージをマルチキャストする。チャネルを共用するいずれかのノードが 8〜9 秒以内に他のノードから HELLO データグラムまたはシーケンス・メッセージを受信できない場合は,受信時間切れでチャネルをクローズする。 "Port closed virtual circuit" というメッセージを受信した場合,チャネルは形成されたが,トラフィックの受信に関する問題が発生したことを示す。この場合,紛失した HELLO データグラム・メッセージを検索する。 |
図 F-3 では,チャネル形成ハンドシェイクが正常に行われるときのメッセージの交換を示しています。
図 F-3 チャネルの形成のためのハンドシェイク
F.6.2 トラブルシューティングの手法 |
2 つのノード間の通信が正常に行われなくなり,チャネルの形成に問題があると考えられる場合は,以下の指示に従ってください。
手順 | 操作 |
---|---|
1 | 以下のような明らかな問題が発生していないかどうか確認する。
|
2 | SDA を使用して,チャネルに障害がないかどうか確認する。 SDA コマンド SHOW PORT/CHANNEL/VC=VC_
remote_node は,チャネルが存在していたかどうか判断するのに役立つ。このコマンドはチャネルの状態を表示する。
関連項目: SHOW PORT コマンドの例については, 付録 F.3 節 を参照。LAN アナライザを使用してチャネルの形成の問題を解決する方法については, 付録 F.11.1 項 を参照。 |
3 | LAVC$FAILURE_ANALYSIS プログラムを使用して,チャネルの問題に対処する方法については, 付録 D も参照。 |
送信側のノードがシーケンス・メッセージ・データを含むデータグラムを最初に送信すると,PEDRIVER は TR ヘッダの REXMT フラグ・ビットの値を 0 に設定します。データグラムの再送が必要になると,PEDRIVER は REXMT フラグ・ビットを 1 に設定し,データグラムを再送します。データグラムが受信されるか,仮想サーキットがクローズされるまで,PEDRIVER はデータグラムを再送します。複数のチャネルが使用可能な場合は,PEDRIVER は再送の原因になった問題を回避するために,異なるチャネルでメッセージを再送しようとします。
LRP (large request packets) や非ページング・プールなどの重要なリソースがすべて使用されてしまった等の原因で,メッセージがリモート・ノードに到達したにもかかわらず,紛失する場合は,一般に再送が実行されます。この他にも再送が行われる理由があります。たとえば,LAN ブリッジが過負荷状態である,LAN アダプタが低速である (DELQA など),システムの負荷が非常に高いなどの原因が考えられ,このような場合,パケットの送信や受信で遅延が発生します。
図 F-4 では,最初は送信が失敗した後,再送が成功した様子を示しています。
図 F-4 メッセージの紛失による再送
F.7 再送に関する問題
F.7.1 再送が発生する理由
最初のメッセージが紛失したため,ローカル・ノードはリモート・ノードから確認応答 (ACK) を受信しませんでした。リモート・ノードはメッセージの 2 回目の (正常) 送信に対して,確認応答メッセージを送信しました。
また,ケーブルが正しく接続されていない場合や,ネットワークが非常にビジー状態であるためにデータグラムを送信できない場合,あるいは発信側の LAN アダプタまたはブリッジやリピータによって送信時にデータグラムが破壊または紛失された場合,再送が行われます。 図 F-5 は別の種類の再送を示しています。
図 F-5 ACK の紛失による再送
図 F-5 では,リモート・ノードはメッセージを受信し,送信側のノードに確認応答 (ACK) を送信しています。しかし,受信側ノードからの ACK が紛失したため,送信側ノードはメッセージを再送します。
F.7.2 トラブルシューティングの手法
クラスタで発生する再送の問題は,各 LAN セグメントに対して LAN プロトコル・アナライザを使用して対処することができます。クラスタ通信のために複数のセグメントが使用されている場合, LAN アナライザは分散イネーブル機能および分散トリガ機能をサポートしなければなりません ( 付録 F.9 節 を参照)。
関連項目: LAN アナライザを使用して再送されたデータグラムを切り分ける手法については, 付録 F.11.2 項 を参照してください。輻輳制御と PEDRIVER のメッセージ再送の詳細については, 付録 G も参照してください。
NISCA プロトコルのパケットの形式は,$NISCADEF マクロによって定義されています。このマクロは,VAX システムでは CD リスティング・ディスクの [DRIVER.LIS],Alpha システムでは [LIB.LIS] に格納されています。
図 F-6 は,NISCA データグラムの一般的な形式を示しています。NISCA データグラムは以下のヘッダと,ユーザ・データによって構成されています。
図 F-6 NISCA のヘッダ
NISCA プロトコルは,イーサネットで構成される LAN でサポートされます。 付録 F.8.3 項 を参照してください。これらのヘッダには,LAN アダプタ間で発生した問題を診断するのに役立つ情報が含まれています。
関連項目: LAN ヘッダの情報を切り分ける方法については,
付録 F.10.4 項 を参照してください。
イーサネット上で送受信される各データグラムには,先頭にイーサネット・ヘッダが付いています。イーサネット・ヘッダは 16 バイトの長さであり,
図 F-7 に示すとおりです。詳細については, 表 F-8 を参照してください。
図 F-7 イーサネット・ヘッダ
F.8 NISCA データグラムについて
F.8.1 パケットの形式
注意
NISCA プロトコルは予告なく変更されることがあります。
F.8.2 LAN ヘッダ
F.8.3 イーサネットのヘッダ
フィールド | 説明 |
---|---|
Destination address | データグラムを受信するアダプタの LAN アドレス |
Source address | データグラムを送信するアダプタの LAN アドレス |
Protocol type | NISCA プロトコルを示す 16 進数 (60--07) |
Length | データグラム内で length フィールドの後に続くデータのバイト数 |
OpenVMS Cluster プロトコル用の DX (datagram exchange) ヘッダは,データを適切な OpenVMS Cluster ノードに渡すために使用されます。 DX ヘッダは 14 バイトの長さであり,
図 F-8 に示すとおりです。詳細については, 表 F-9 を参照してください。このヘッダには,2 つのノード間の OpenVMS Cluster 接続を記述する情報が含まれています。 DX ヘッダのデータを切り分ける方法については,
付録 F.10.3 項 を参照してください。
図 F-8 DX ヘッダ
F.8.4 Datagram Exchange (DX) ヘッダ
フィールド | 説明 |
---|---|
Destination SCS address | アドレス AA--00--04--00-- remote-node-SCSSYSTEMID を使用して作成される。下位 16 ビットに対して,リモート・ノードの SCSSYSTEMID システム・パラメータの値が追加される。このアドレスは,送信先の SCS トランスポート・アドレスまたは OpenVMS Cluster マルチキャスト・アドレスを表す。 |
Cluster group number | システム管理者が指定したクラスタ・グループ番号。クラスタ・グループ番号の詳細については, 第 8 章 を参照。 |
Source SCS address | 送信元 SCS トランスポート・アドレスを表し,アドレス AA--00--04--00-- local-node-SCSSYSTEMID を使用して作成される。下位 16 ビットに対して,ローカル・ノードの SCSSYSTEMID システム・パラメータの値が追加される。 |
CC (channel control) メッセージは,OpenVMS Cluster システム内のノード間でネットワーク・パスを形成し,パスを正常に動作する状態に維持するために使用されます。ネットワークのトラブルシューティングにとって重要なフィールドは,datagram flags/type と cluster password です。
CC ヘッダと TR ヘッダは同じ領域を使用するため,チャネルを介して送信されているメッセージの種類を示すために,TR/CC フラグが使用されます。 図 F-9 は,ネットワークのトラブルシューティングに必要な CC ヘッダの部分を示しており, 表 F-10 では,これらのフィールドについて説明しています。
図 F-9 CC ヘッダ
F.8.5 CC (Channel Control) ヘッダ
フィールド | 説明 | ||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Datagram type (ビット <3:0>) | チャネル制御レベルでメッセージの種類を示す。以下の表はデータグラムとその機能を示している。
|
||||||||||||||||||||||||||||||||||||
データグラム・フラグ (ビット <7:4>) | 制御データグラムに関する追加情報を提供する。以下のビットが定義されている。
|
||||||||||||||||||||||||||||||||||||
クラスタ・パスワード | クラスタ・パスワードが格納される。 |
目次 | 索引 |
|