日本-日本語

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


目次 索引

付録 G
NISCA トランスポート・プロトコル・チャネル選択および輻輳制御



この付録では,OpenVMS バージョン 7.3 (Alpha および VAX) で実行している PEDRIVER と,前のバージョンの OpenVMS Alpha および OpenVMS VAX の PEDRIVER について説明します。

G.1.1 OpenVMS バージョン 7.3 以降 (Alpha および VAX) の複数チャネル負荷分散

他ノードからデータグラムを受信するためにはノードで使用できるすべてのチャネルを使用できますが,他のノードへデータグラムを送信する場合には必ずしもすべてのチャネルが必要になるとは限りません。NISCA プロトコルは,使用できるすべてのチャネルからリモート・ノードへのデータグラムの送信に使用するチャネルを選択します。この送信チャネルのセットを 等価チャネル・セット (ECS) と呼びます。データグラム送信は, ECS のすべてのチャネルにラウンドロビンで配信されるため,ノード間のクラスタ通信のスループットが最大になります。

複数のノード間チャネルが使用可能な場合, OpenVMS Cluster ソフトウェアは次の基準で使用するチャネル・セットを選択します。この基準は厳密にリストした順で評価されます。

  1. パケットの損失履歴
    少し前に高頻度で LAN パケットを損失したことがあるチャネルは, 損失過多 と呼ばれ,対象外とします。損失履歴が許容範囲にあるチャネルは,タイトと呼び,使用対象の候補にします。

  2. キャパシティ
    次に,タイト・チャネルの現在の候補セットに対してキャパシティ基準を評価します。キャパシティ基準には次のものがあります。

    1. 優先順位
      管理優先順位値を,個々のチャネルとローカル LAN デバイスの両方に割り当ることができます。チャネルの優先順位値は,割り当て済みの管理優先順位値の合計です。タイト・チャネルは,最大の優先順位値のタイト・チャネルと同じか,または 1 つだけ小さいタイト・チャネルのみを候補に残します。

    2. パケット・サイズ
      同じ優先順位値のタイト・チャネルの最大使用可能パケット・サイズが,最大のものと同じタイト・チャネルを候補に残します。


    これらのキャパシティ基準をすべて満たすチャネルを, 同位チャネル と分類します。キャパシティ基準に満たないチャネルは, 劣位チャネル として分類します。現在のキャパシティ基準を 1 つ以上上回り,別のキャパシティ基準も満たすチャネルを, 優位チャネル として分類します。
    優位チャネルを検出すると,すぐにECS選択のためのキャパシティ基準を再計算することに注意してください。この再計算により,優位チャネルのキャパシティ基準が ECS のキャパシティ基準となり,これに対してすべてのタイト・チャネルの評価が行われます。
    同様に,残り 1 つの同位チャネルが使用不能になったり,損失過多チャネルになると, ECS 選択のためのキャパシティ基準が再計算されます。これにより,以前には劣位チャネルであったものが同位チャネルとなることがあります。
    ECS 選択のための現在のキャパシティ基準に対してキャパシティの値が評価されていないチャネルを,未評価チャネル と分類します。未評価チャネルは ECS 選択のための現在の基準には影響しないため,ECS 選択のための再計算が行われるときには,損失過多チャネルは計算の都合上は未評価チャネルと扱われます。

  3. 遅延
    ECS 選択のための前述の基準を満たすチャネルで,平均ラウンド・トリップ遅延が最も短いチャネルとほぼ同じチャネルを 高速チャネル と呼びます。この ECS 選択の遅延基準を満たさないチャネルを,低速チャネル と見なします。
    現在 ECS に属する各チャネルの遅延は,そのチャネルを用いて送信されるクラスタ通信トラフィックを使って測定されます。チャネルが数秒間データグラムの送信に使用されていないときは,ラウンドトリップのハンドシェークを使って遅延が測定されます。このため,損失過多チャネルまたは低速チャネルは,数秒間隔で測定され,遅延またはデータグラム損失率が ECS 選択基準を満たす程度に改善されたかどうかを判断します。

ここで定義した用語を使用すれば, ECS に属するチャネルとはその時点で,タイトで,同位で,高速のチャネルです。

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

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

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

  • パケットが紛失したために時間切れが発生すると,直ちにウィンドウのサイズが縮小され,ネットワークの負荷が削減されます。輻輳が軽減した場合だけ,ウィンドウ・サイズの拡大が認められます。さらに,パケットの損失が発生すると,ウィンドウ・サイズは 1 に縮小され,そのまま変更されないため,それまで送信されていたすべてのパケットに肯定応答があるまでは,送信側は一度に 1 つのパケットしか送信できなくなります。
    この状況が発生した後,以前のサイズの半分までは,ウィンドウを迅速に拡大することが認められます。サイズが半分になると,ウィンドウ・サイズの拡大の速度はかなりゆるやかになり,構成変数 (たとえばアダプタ・バッファ数やリモート・ノードの受信順序替えキャッシュの最小) によって決定される最大値に到達するまで,使用可能なネットワーク・キャパシティを活用できるようになります。

  • 再送時間切れの間隔は,仮想サーキットを通じて送信されるパケットの実際のラウンド・トリップ時間と,この平均値の偏差を測定することにより設定されます。このため,PEDRIVER は,ほとんどのネットワークでパケットの損失に対してより適切に応答できるようになりますが,実際のラウンド・トリップ遅延時間が確実に長いネットワークでは,途中で時間切れが発生するのを回避します。アルゴリズムによって,平均遅延を最大数秒以内になるように調整することができます



ここでは,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 秒に変更する。


索引 目次

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