Compaq OpenVMS
OpenVMS Cluster システム

G.1.1.2 ローカルおよびリモート LAN アダプタの負荷分散

ECS に属するチャネルを選択すると， 1 つのローカル・アダプタを再利用する前に，パケット送信を行うすべてのローカル・アダプタを使用するように並びかえるアルゴリズムを使ってチャネルを順序づけます。また，この順序付けのアルゴリズムは，すべてのリモート LAN アダプタに対しても同様に適用されます。順序が決まると，ラウンド・ロビンを使用してパケットを送信します。

これらのアルゴリズムを使用して，PEDRIVER は，複数の LAN アダプタを使用する 1 クライアント (多くのクライアントに対しても同様) と連続して通信するサーバ・ノードの複数の LAN アダプタを効率よく使用します。 2 つのノードで構成されるクラスタでは， PEDRIVER は，他のノードの LAN アダプタへの通信に使用できる LAN パスがあり，同じキャパシティ値を持っている LAN アダプタのうち使用できるものをすべて実際に使用しようとします。このため，アダプタを追加すると，可用性が高くなり，ネットワークの輻輳の回避に用いることができる代替パスが増えます。

G.1.2 優先チャネル (OpenVMS バージョン 7.2 以前)

ここでは，OpenVMS バージョン 7.3 より前の OpenVMS VAX および OpenVMS Alpha で使用する，送信チャネル選択アルゴリズムについて説明します。

ノードで使用できるすべてのチャネルは，そのノードからのデータグラムの受信に使用できます。 PEDRIVER は，使用できるリモート・ノードへのチャネルの中からデータグラムを送信するチャネルを 1 つ選択します。

ドライバ・ソフトウェアは，各リモート・ノードに対して送信チャネルを 1 つ選択します。送信チャネルを選択するアルゴリズムでは，意図した順に受信されるようにメッセージを送信するようにしています。このようにしてメッセージを送信すると，古いバージョンのオペレーティング・システムとの互換性も維持することができます。現在選択している送信チャネルを優先チャネルと呼びます。

NISCA プロトコルの TR レベルで，以下のようにして優先チャネルの選択をいつでも変更できます。

測定着信遅延の極小化
NISCA プロトコルは，HELLO メッセージの遅延を定期的に測定し，その結果をもとに，最も負荷の軽いチャネルをメッセージ送信用に選択します。
データグラム・サイズの極大化
PEDRIVER は，大きなデータグラム・サイズが可能なチャネルを優先的に選択します。たとえば，FDDI-to-FDDI チャネルの方が， FDDI-to-Ethernet チャネルや Ethernet-to-Ethernet チャネルより優先的に選択されます。FDDI からイーサネットへのブリッジを使用している構成で，NISCA プロトコルの PPC レベルでは，メッセージを送信する前にイーサネットのデータグラム・サイズにあわせて小さくメッセージを分割します。

PEDRIVER は，各チャネルのネットワーク着信遅延を計算するために，受信 HELLO メッセージをいつも使用しています。このため，各チャネルの着信遅延は 2 ないし 3 秒間隔で再計算されます。次に，PEDRIVER はネットワークがブロードキャスト・タイプの媒体 (イーサネットケーブルまたは FDDI リングなど) を使用していると想定します。したがって，着信遅延と送信遅延は同じとなります。

PEDRIVER は，測定したネットワーク遅延またはネットワーク・コンポーネントの障害をもとに，優先チャネルを切り換えます。新しい送信チャネルへの切り換えが発生すると，メッセージが意図した順序で受信できないことがあります。 PEDRIVER は受信順序替えキャッシュを使用して，これらの順序を入れ換えており，不要な再送をしなくてもすむようにメッセージを破棄しないようにしています。

これらのアルゴリズムを使用することにより，PEDRIVER は，多くのクライアントと連続して通信するサーバ・ノードの複数のアダプタをうまく利用できるようにしています。2 つのノードで構成されるクラスタでは，PEDRIVER は最大 2 つの LAN アダプタを実際には使用します。1 つは送信用，もう 1 つは受信用です。アダプタを追加すると，可用性が高くなり，ネットワークの輻輳の回避に用いることができる代替パスが増えます。クラスタにノードを追加すればするほど，PEDRIVER は追加アダプタを使用するようになります。

G.2 NISCA 輻輳制御

ネットワークの輻輳は，各ハードウェア・コンポーネントの速度やバッファ容量も含めて，ネットワーク・トポロジと作業負荷の分散が複雑に関係し合う結果として発生します。

ネットワークの輻輳は，さまざまな方法でクラスタのパフォーマンスに悪影響を与えることがあります。

中程度の輻輳が発生すると，ネットワーク・コンポーネント (アダプタやブリッジなど) のキューの長さが長くなり，その結果，待ち時間が増加し，応答が低下します。
輻輳が高くなると，キューがオーバーフローするために，パケットが紛失する可能性があります。
パケットが紛失すると，パケットが再送されるため，さらに輻輳が発生します。極端な場合は，パケットの損失の結果， OpenVMS Cluster の接続が破壊されることもあります。
クラスタ・レベルでは，これらの輻輳の結果はクラスタ通信の遅延として現われます (ロック・トランザクションの遅延， I/O サービス遅延，ICC メッセージ遅延など)。ユーザの目に見えるネットワークの輻輳の影響には，アプリケーションの応答の遅さまたはスループットの低下があります。

このような理由から，特定のネットワーク・コンポーネントやプロトコルだけで，輻輳が発生しないことを保証することはできませんが，PEDRIVER に実装された NISCA トランスポート・プロトコルは複数のメカニズムを統合して， OpenVMS Cluster のトラフィックに輻輳が与える影響をできるだけ少なくし，輻輳が発生しても，クラスタ・トラフィックの輻輳をさらに悪化させないようにしています。これらのメカニズムは，接続を維持するために使用されるマルチキャスト HELLO データグラムと，ユーザ・データを伝達するパケットの再送に影響します。

G.2.1 再送によって発生する輻輳

各ノードからの各仮想サーキットには，送信ウィンドウ・サイズが割り当てられます。このウィンドウ・サイズは，リモート・ノードへの送信を待機できるパケットの数を示します (たとえば，確認応答 [ACK] を受信するまでに，仮想サーキットの反対側のノードに送信できるパケットの数)。

特定の仮想サーキットのウィンドウ・サイズが 8 の場合，送信側は最大 8 つのパケットを連続して送信できますが，9 番目のパケットを送信する前に，すでに送信した 8 つのパケットのうち，少なくとも最初のパケットが到着したことを示す ACK を受信するまで待たなければなりません。

ACK が受信されない場合，時間切れが発生し，パケットは損失したものと解釈され，再送が必要になります。再送パケットに対し他の時間切れが発生した場合にはタイムアウト時間間隔が大幅に延ばされ，パケットはもう一度再送されます。同じパケットの再送が何度も発生すると，仮想サーキットは切断されます。

G.2.1.1 OpenVMS VAX バージョン 6.0 または OpenVMS AXP バージョン 1.5 以降

ここでは，OpenVMS VAX バージョン 6.0 または OpenVMS AXP バージョン 1.5 以降で実行されている PEDRIVER に関して説明しています。

再送メカニズムでは，Van Jacobson がインターネットの TCP プロトコルに対してもともと開発したアルゴリズムが採用されており，ウィンドウ・サイズと再送の時間切れの間隔をネットワークの条件に適合させることにより，以前のメカニズムより大幅に改善されています。

パケットが紛失したために時間切れが発生すると，直ちにウィンドウのサイズが縮小され，ネットワークの負荷が削減されます。輻輳が軽減した場合だけ，ウィンドウ・サイズの拡大が認められます。さらに，パケットの損失が発生すると，ウィンドウ・サイズは 1 に縮小され，そのまま変更されないため，それまで送信されていたすべてのパケットに肯定応答があるまでは，送信側は一度に 1 つのパケットしか送信できなくなります。
この状況が発生した後，以前のサイズの半分までは，ウィンドウを迅速に拡大することが認められます。サイズが半分になると，ウィンドウ・サイズの拡大の速度はかなりゆるやかになり，構成変数 (たとえばアダプタ・バッファ数やリモート・ノードの受信順序替えキャッシュの最小) によって決定される最大値に到達するまで，使用可能なネットワーク・キャパシティを活用できるようになります。
再送時間切れの間隔は，仮想サーキットを通じて送信されるパケットの実際のラウンド・トリップ時間と，この平均値の偏差を測定することにより設定されます。このため，PEDRIVER は，ほとんどのネットワークでパケットの損失に対してより適切に応答できるようになりますが，実際のラウンド・トリップ遅延時間が確実に長いネットワークでは，途中で時間切れが発生するのを回避します。アルゴリズムによって，平均遅延を最大数秒以内になるように調整することができます

G.2.1.2 VMS バージョン 5.5 またはそれ以前のバージョン

ここでは，VMS バージョン 5.5 以前を実行している PEDRIVER に関して説明します。

ウィンドウ・サイズはほとんど一定しており，通常は 8，16，31 です。再送のポリシーは，肯定応答を受信していないすべてのパケットは損失したものとみなし，一度にすべてを再送します。輻輳状態でウィンドウの全パケットを再送すると，さらに状態は悪化します。
パケットが損失したと判断されるまでのタイムアウト時間は一定です (3 秒)。つまり，1 つのパケットが損失すると，クラスタ・ノード間の通信は最大 3 秒間中断されます。

G.2.2 HELLO マルチキャスト・データグラム

PEDRIVER は，ノードに接続されている各ネットワーク・アダプタを通じて定期的に HELLO データグラムをマルチキャストします。 HELLO データグラムには，以下の 2 つの目的があります。

送信側の存在を他のノードに通知することにより，チャネルと仮想サーキットを形成できるようにします。
通信が確立された後，それをオープンしたままにしておくのに役立ちます。

HELLO データグラムによる輻輳や HELLO データグラムの紛失は，接続の確立を妨げたり，接続を破壊する可能性があります。表 G-1 では，HELLO データグラムの輻輳の原因になる条件や，PEDRIVER が問題の回避にどのように役立つかについて説明しています。この結果，HELLO データグラムの同期化の可能性がかなり低下し，HELLO データグラムによる輻輳も低下します。

表 G-1 HELLO データグラムの輻輳の原因になる条件
輻輳の原因になる条件 PEDRIVER が輻輳を回避する方法

新しいノードから HELLO データグラムを受信するすべてのノードが直ちに応答しなかった場合，新しいノードの受信ネットワーク・アダプタは，HELLO データグラムによってオーバーランする可能性があり，一部のデータグラムが紛失することになり，接続を確立できない場合がある。これは特に，大規模なクラスタで発生する可能性が高い。以下のバージョンを実行しているノードでこの問題を回避するには，以下の操作を行う。

VMS バージョン 5.5--2 またはそれ以前のバージョンを実行しているノードでは，HELLO データグラムを受信するノードは，応答する前に最大 1 秒の間隔でランダムに遅延を発生させる。
OpenVMS VAX バージョン 6.0 またはそれ以降のバージョン，または OpenVMS AXP バージョン 1.5 またはそれ以降のバージョンを実行しているノードでは，大規模な OpenVMS Cluster システムをサポートするために，このランダムな遅延時間は最大 2 秒になっている。

ネットワーク内の多くのノードの同期がとられ，同時にまたはほとんど同時に HELLO データグラムを送信する場合，受信側のノードは一部のデータグラムを紛失し，チャネルを時間切れにすることがある。 VMS バージョン 5.5--2 またはそれ以前のバージョンを実行しているノードでは，PEDRIVER は 3 秒おきに各アダプタで HELLO データグラムをマルチキャストするため， HELLO データグラムによる輻輳が発生する可能性が高くなる。
OpenVMS VAX バージョン 6.0 またはそれ以降のバージョン，または OpenVMS AXP バージョン 1.5 またはそれ以降のバージョンを実行しているノードでは，PEDRIVER は HELLO データグラム・マルチキャストをランダムに分散させることにより，HELLO データグラムによる輻輳の発生を防止している。HELLO データグラムは約 3 秒ごとに各アダプタでマルチキャストされるが，一度にすべてのアダプタでマルチキャストされるわけではない。1 台のノードに複数のネットワーク・アダプタが接続されている場合，PEDRIVER は HELLO データグラム・マルチキャストを分散させて，3 秒間隔の毎秒，どれかのアダプタで HELLO データグラムを送信する。
さらに，正確に 3 秒ごとにマルチキャストするのではなく，PEDRIVER は約 1.6～3 秒の範囲で HELLO データグラムのマルチキャストの間隔を変更して，マルチキャスト間隔の平均時間を 3 秒から約 2.3 秒に変更する。

**表 G-1 HELLO データグラムの輻輳の原因になる条件**
輻輳の原因になる条件	PEDRIVER が輻輳を回避する方法
新しいノードから HELLO データグラムを受信するすべてのノードが直ちに応答しなかった場合，新しいノードの受信ネットワーク・アダプタは，HELLO データグラムによってオーバーランする可能性があり，一部のデータグラムが紛失することになり，接続を確立できない場合がある。これは特に，大規模なクラスタで発生する可能性が高い。	以下のバージョンを実行しているノードでこの問題を回避するには，以下の操作を行う。 VMS バージョン 5.5--2 またはそれ以前のバージョンを実行しているノードでは，HELLO データグラムを受信するノードは，応答する前に最大 1 秒の間隔でランダムに遅延を発生させる。 OpenVMS VAX バージョン 6.0 またはそれ以降のバージョン，または OpenVMS AXP バージョン 1.5 またはそれ以降のバージョンを実行しているノードでは，大規模な OpenVMS Cluster システムをサポートするために，このランダムな遅延時間は最大 2 秒になっている。
ネットワーク内の多くのノードの同期がとられ，同時にまたはほとんど同時に HELLO データグラムを送信する場合，受信側のノードは一部のデータグラムを紛失し，チャネルを時間切れにすることがある。	VMS バージョン 5.5--2 またはそれ以前のバージョンを実行しているノードでは，PEDRIVER は 3 秒おきに各アダプタで HELLO データグラムをマルチキャストするため， HELLO データグラムによる輻輳が発生する可能性が高くなる。 OpenVMS VAX バージョン 6.0 またはそれ以降のバージョン，または OpenVMS AXP バージョン 1.5 またはそれ以降のバージョンを実行しているノードでは，PEDRIVER は HELLO データグラム・マルチキャストをランダムに分散させることにより，HELLO データグラムによる輻輳の発生を防止している。HELLO データグラムは約 3 秒ごとに各アダプタでマルチキャストされるが，一度にすべてのアダプタでマルチキャストされるわけではない。1 台のノードに複数のネットワーク・アダプタが接続されている場合，PEDRIVER は HELLO データグラム・マルチキャストを分散させて，3 秒間隔の毎秒，どれかのアダプタで HELLO データグラムを送信する。さらに，正確に 3 秒ごとにマルチキャストするのではなく，PEDRIVER は約 1.6～3 秒の範囲で HELLO データグラムのマルチキャストの間隔を変更して，マルチキャスト間隔の平均時間を 3 秒から約 2.3 秒に変更する。

前へ索引目次

Compaq OpenVMSOpenVMS Cluster システム