test

Solaris Bandwidth Manager 1.6 のシステム管理

第 2 章 アーキテクチャ

製品の構造

Solaris Bandwidth Manager の主な構成要素は次のとおりです。

図 2-1 に、Solaris Bandwidth Manager のアーキテクチャを示します。

図 2-1 Solaris Bandwidth Manager のアーキテクチャ

Graphic

管理ツール

管理ツール batool を使って、Solaris Bandwidth Manager を設定できます。batool には 2 つのモードがあります。

管理ツール batool は、ポリシーエージェント経由でカーネルモジュールと通信します。batool はカーネルモジュールに設定内容の変更を送信し、カーネルモジュールは batool に統計情報を送信します。

batool の詳細と使用法については、第 5 章「batool による Solaris Bandwidth Manager の設定」を参照してください。Solaris Bandwidth Manager は設定ファイルを編集することによっても設定できます。あるいは、ディレクトリサービスからも設定できます。

ポリシーエージェント

ポリシーエージェントは Solaris Bandwidth Manager の通信ハブであり、他の構成要素との間で送受信される情報を制御し、これらの構成要素が運用するポリシーを制御します。ポリシーエージェントは Java Dynamic ManagementTM Kit フレームワークを使って実装されています。ポリシーエージェントは Java 管理 bean (m-bean) のセットとそれらのエクスポートしているインタフェースも含んでいます。ポリシーエージェントのアーキテクチャについての詳細は、付録 A 「ポリシーエージェントのアーキテクチャ」 を参照してください。

フロー

フローとは、ユーザーの視点から見ると、送信者と受信者との間における完結した情報交換のことです。たとえば、メールメッセージの送信や、Web ページのダウンロードなどです。

フローは、次の要素から定義されます。

TOS 値はフローの生存期間中に変更される可能性があるため、フローはあるクラスから別のクラスに移動できます。しかし、パケットの順番に影響を与える可能性もあるため、お勧めできません。

現在のすべてのフローについての情報はキャッシュに格納されます。パケットが到着すると、そのフローの特性とキャッシュ内の情報が比較されて、そのフローが既存のフローの一部であるのか、新しいフローが始まったのかが判断されます。フロー識別情報に加えて、キャッシュには次のような統計も記録されます。

注 -

フロー内の最後のパケットが検出されてから 60 秒経過すると、フローは終了されます。この時間は変更できません。

クラスではなくフローを監視すると、より正確なネットワークの使用率をより細かいレベルで求めることができます。これによって、将来のネットワークの必要性をより正確に予測できます。また、このような情報はアカウンティングにも使用できます。

batool を使用すると、フローの統計を表示できます。第 8 章「統計情報」を参照してください。また、CISCO NetFlow プロトコルのバージョン 5 と互換性を持つ任意の課金パッケージとアカウンティングパッケージも使用できます。

TOS (Type of Service) のサポート

IP パケットには TOS (Type Of Service) フィールドがあります。このフィールドの目的は、パケットが処理される方法を伝えることです。Solaris Bandwidth Manager はこの情報を使用して、パケットをクラス分けできます。また、Solaris Bandwidth Manager はこの情報を変更して、パケットが処理される方法に影響を与えることができます。

IP 仕様における TOS 定義の要約については、「IP 仕様の TOS」を参照してください。Solaris Bandwidth Manager が TOS と連携する方法については、「Solaris Bandwidth Manager と TOS」を参照してください。

IP 仕様の TOS

IP 仕様では、IP パケットのヘッダーにおける TOS フィールドも定義されています。このフィールドは、パケットの経路制御を最適化する方法について、上位層プロトコルによってインターネット層へ情報提供するのに使用されることが想定されています。

ネットワークトポロジは、パケットの発信元と着信先との間に複数の経路が存在することを意味します。いくつかの経路は他の経路よりも信頼性が高く、また高価な (呼び出し設定料や使用料が高い) 経路や、低コストだが低速な経路もあります。パケットに最適な経路はアプリケーションやユーザーによって異なり、時刻など他の要素によっても変わる可能性があります。たとえば、リモートシステムを監視するシステム管理者の場合、コストに関係なく警報トラフィックをできるだけ迅速に受信する必要があります。これは警報トラフィックを経路指定するコストはシステム障害によるコストよりもはるかに低いためです。しかし、翌日の仕事に備えて終業時刻間際に同じリモートシステムから ftp で文書を入手する場合は、低コストで低速な経路で十分です。

インターネット層は、アプリケーションやユーザーに対して経路を最適化する方法に関して直接的な知識を持っていません。TOS 機能は、いかにパケットを最適に経路付けるかについてのヒントを提供するのに使用されることが想定されていました。これは、待ち行列アルゴリズムと経路制御アルゴリズムの両方に影響を与えます。TOS 機能には、3 ビットの優先度フィールドと 4 ビットの TOS フィールドがあります。優先度フィールドの設定値は、優先順位を示す次の値のうちの 1 つを示します。

次に、TOS フィールドに設定できる値を示します。

TOS 機能は従来、あまり使用されていませんでした。しかし、IETF (Internet Engineering Task Force) は、現在、TOS 機能の定義を変更し、その使用を推進しています。

Solaris Bandwidth Manager と TOS

TOS (Type of Service) 機能は IP プロトコルによって提供され、個々のパケットがインターネットを介して送信される方法を伝えます。TOS フィールドは、ゲートウェイ動作における経路制御アルゴリズムと待ち行列アルゴリズムを制御します。

TOS バイトには、優先度フィールド、TOS フィールド、および空のフィールドがあります。

Graphic

詳細は、P.Almquist 著の RFC 1349『Type of Service in the Internet Protocol Suite』を参照してください。

Solaris Bandwidth Manager のモード

Solaris Bandwidth Manager は 2 つのモードで使用できます。サーバーモードと IP 透過モードです。

サーバーモード

IP トラフィックの発信元であるホスト上では、サーバーモードで Solaris Bandwidth Manager を実行します。ホストが IP トラフィックの発信元であるのは、そのホストが WAN または LAN へのネットワーク接続を 1 つだけ持っている場合か、トラフィックのルーターである場合です。

図 2-2 サーバーモードにおける Solaris Bandwidth Manager

Graphic

図 2-3 サーバーモードにおけるルーター上の Solaris Bandwidth Manager

Graphic

帯域幅管理が設定されているインタフェースが初期化されるとき (通常はシステム起動時)、ipqos モジュールは IP とインタフェース間の IP スタック上にプッシュされます。Solaris Bandwidth Manager のポリシーエージェントは設定ファイルを読み取って、設定情報を ipqos モジュールにロードします。次に、ipqos モジュールは設定された定義に従って、すべてのトラフィックを処理します。

注 -

同じマシン上でファイアウォールが動作している場合、暗号化ソフトウェアが動作していないインタフェース上に Solaris Bandwidth Manager をインストールしてください。

IP 透過モード

LAN とルーター間にあるホスト上では、IP 透過モードで Solaris Bandwidth Manager を実行します。

このモードが IP 透過と呼ばれるのは、Solaris Bandwidth Manager が動作しているホストが IP ネットワークに完全に透過的であり、LAN に接続されたまったく別のマシンのように認識されるためです。LAN と WAN は、そのルーターだけで直接接続されているように動作します。各ホストのルーティングテーブルを変更する必要はありません。

図 2-4 Solaris Bandwidth Manager なしのネットワーク構成

Graphic

図 2-5 IP 透過モードにおけるネットワーク構成

Graphic

カーネルアーキテクチャ

カーネルには 3 つのモジュールがあり、LAN とルーター間でパケットを受信、フィルタ、分類、スケジュール管理、および転送を行います。図 2-6 に点線で、IP 透過モードにおけるデータの論理フローを示します。

ipqos1 

システム起動時に autopush.ba と autopush_usr.ba によって IP スタックに実装される。このモジュールは LAN からホストに到着するパケットを監視するが、ホストマシン宛のパケットだけを処理する

ipqos2 

ポリシーエージェント起動時に実装される。このモジュールは LAN からホストに到着するパケットを監視して、フィルタし、カーネル内に振り分ける 

ipqos3 

ポリシーエージェント起動時に実装される。このモジュールインタフェースは LAN または WAN からホストに到着したパケットを監視する。そして、分類、スケジュール管理する。設定ファイルのクラスはこのモジュールに格納される 

LAN からのトラフィックフロー

LAN から Solaris Bandwidth Manager が動作しているホストへ向けたトラフィックは、LAN インタフェースによって受信されます。

パケットの着信先 IP アドレスが Solaris Bandwidth Manager が動作しているホストである場合、そのパケットはすでに ipqos1 によって IP スタック上へ送られているため、ipqos2 では破棄されます。

パケットの着信先 IP アドレスが Solaris Bandwidth Manager が動作しているホストでない場合、次の条件に適合すれば、そのパケットはルーターへ直接転送されます。

上記以外の場合、パケットは ipqos3 によって分類およびスケジュール管理されます。

WAN からのトラフィックフロー

WAN からのトラフィックは、ipqos3 と ipqos2 経由で LAN に転送されます。

図 2-6 透過モードにおけるトラフィックフロー

Graphic

設定ファイルから設定できるのは ipqos3 だけです。そのため、設定ファイル内のインタフェースに対する参照はすべて、WAN インタフェースである必要があります。設定ファイル内のネットワークデバイスオプションを設定して LAN インタフェースを参照するには、次のどちらかの方法を使用します。

非 IP パケット

nonip_mode パラメータが direct に設定されている場合、非 IP トラフィックは ipqos をバイパスします。このようなパケットはフロー統計に記録されません。nonip_mode パラメータが ipqos に設定されている場合、トラフィックは default クラスに送られます。default クラスが設定されていない場合は root クラスに送られます。

マルチキャスト経路制御と Solaris Bandwidth Manager

サーバーモードでは、Solaris Bandwidth Manager はマルチキャストを他のトラフィックの種類と区別しません。ただし、Solaris Bandwidth Manager を IP 透過モードで使用している場合、ルーターがマルチキャストパケットを転送するかどうかはネットワーク構成によって異なるため、自動的に予測できません。

そのため、Solaris Bandwidth Manager がマルチキャストトラフィックを処理する方法を制御するための選択肢が 3 つあります。各ネットワークに最適な選択肢を選択してください。