test

Solaris Bandwidth Manager 1.6 のシステム管理

第 3 章 計画

帯域幅管理は、ソフトウェアが動作する個々の点ではなく、ネットワーク全体に対して計画する必要があります。

帯域幅管理の計画には次の 2 つの段階があります。

Solaris Bandwidth Manager を使用する地点

ネットワーク内において Solaris Bandwidth Manager を使用する地点は、帯域幅の需要が利用できる帯域幅をときどきまたは常に超えているところや、海を渡るような長距離のリンクの起点や、LAN または WAN の境界など、潜在的にボトルネックとなるところです。Solaris Bandwidth Manager は着信トラフィックと発信トラフィックを調節します。ネットワークリンクが共有媒体を使用する場合は、そのリンクを介してトラフィックを送るすべての地点でトラフィックを調節する必要があります。

Solaris Bandwidth Manager は、IP トラフィックの発信元であるホスト、IP ルーター、または、LAN とルーターの間にあるホスト上で使用できます。LAN とルーター間にあるホスト上では、「IP 透過モード」で述べたとおり、Solaris Bandwidth Manager は IP 透過モードで動作します。

注 -

Solaris Bandwidth Manager は、le0:1 などの論理インタフェース上のトラフィックフローを調節できません。しかし、論理インタフェースを使用するトラフィックに対応するクラスを定義することによって、同じ結果が得られます。この例については、「論理インタフェース」を参照してください。

Solaris Bandwidth Manager は、ネットワーク内の特定の場所で着信トラフィックと発信トラフィックを調節します。ネットワークトポロジによっては、既知のボトルネックよりも前の場所で帯域幅を割り振る方が便利な場合もあります。

図 3-1 Solaris Bandwidth Manager を使用する地点の計画

Graphic

図 3-1 に示すネットワークがあると仮定します。図中の数字はリンクの容量を示します (単位は任意)。

ホスト C がトラフィックを生成しない場合、Solaris Bandwidth Manager を使用する必要はありません。リンク CD の容量が、リンク AC とリンク BC の両方で同時に配信できるトラフィックの合計に対して充分なためです。ただし、ホスト C がトラフィックを生成する場合、ホスト C で Solaris Bandwidth Manager を使用して、リンク CD 上のトラフィックフローを調節する必要があります。

リンク AC の容量が 10 に増えた場合、ホスト C はトラフィックを生成するかどうかに関わらず、潜在的なボトルネックとなります。リンク AC とリンク BC の両方で同時に配信できるトラフィックの合計がリンク CD の容量を超えるためです。この場合、ホスト C で Solaris Bandwidth Manager を使用しても問題は解決しません。ホスト C ではなく、ホスト A で Solaris Bandwidth Manager を使用して、トラフィックがホスト C の容量を超える可能性をなくす、または減らす必要があります。ホスト C がトラフィックを生成しない場合、ホスト A で Solaris Bandwidth Manager を使用するだけでおそらく十分です。ホスト C がトラフィックを生成する場合、ホスト A とホスト C の両方で Solaris Bandwidth Manager を使用してください。

利用するネットワークのある地点で Solaris Bandwidth Manager の設定を計画するときは、トラフィックフローの上流にある他の Solaris Bandwidth Manager の設定内容も考慮する必要があります。たとえば、ホスト A において、ftp-from-A クラスが、リンク AC の容量を 2 を超えて使用しないように設定されている場合、ftp-from-A クラスが、リンク CD の容量を 2 より多く使用することはありません。

また、トラフィックの制限を極端に低く設定しないようにして、リンクが十分使用されるように注意する必要もあります。すべてのリンクが完全に使用されるようにネットワーク内の Solaris Bandwidth Manager を設定します。そして、クラスの相対的な優先度を使用して、リンクがビジーの場合にどのパケットを破棄または遅延するかを決定します。

Solaris Bandwidth Manager をインストールする地点を計画するとき、特定の種類のトラフィックについて特性を考慮する必要があります。たとえば、HTTP トラフィックの場合、データ転送を要求したユーザーへ向かうトラフィックフローが多いほど、ユーザーのローカルマシン上よりも、Web サーバー上で帯域幅を管理する方が有効です。

設定の計画

Solaris Bandwidth Manager の使用を計画している地点ごとに、次のことを決定する必要があります。

任意のサイトで Solaris Bandwidth Manager の初期設定内容を選択するための正確な規則はありません。実際の使用状況を反映するような設定で始めて、大きな問題を一つ一つ解決していき、一定の期間にわたって性能を監視し、徐々に設定を微調整していきます。あるいは、すべてのクラスに等しい帯域幅を割り振り、Solaris Bandwidth Manager を stats モードで実行し、トラフィックをどのように分類するかを監視して、帯域幅 (%) をクラスに実際に割り振ります。

クラス階層の設計

クラス階層は、リンクに対して確立したいネットワークトラフィックパターンに基づいている必要があります。まず、実際のトラフィックパターンについて考慮します。現在のトラフィックパターンについての情報からクラス階層を作成する方法については、「設定の計画の例」を参照してください。

クラス階層は、すべての場所で同じである必要はありません。ただし、ある場所のクラスがパケットの経路に沿った別の場所のクラスにどのように対応するかについて、常に認識しておく必要があります。

また、各クラスのトラフィックの特性や、クラスの定義方法を考慮する必要があります。たとえば、一部のアプリケーションはポート番号を動的に割り振ります。このような場合はポート番号を事前に知ることができないため、このようなアプリケーションが生成するトラフィックに対してポート番号に基づいたクラス定義は現実的でありません。代わりにプロトコルとアドレス情報を使用して、これらのクラスを定義します。

帯域幅の割り振り

最低保障帯域幅を割り振るときの単位は、百分率 (%) またはビット/秒 (bps) です。root クラスには 1 つのインタフェースについて 100% の帯域幅が割り振られています。root の子クラスには root の帯域幅を割り振ります。それらのクラスの子クラスには、その親クラスの帯域幅を割り振ります。割り振った帯域幅は、そのクラスの最低保障帯域幅となります。必要であれば、上限、つまり、最高帯域幅も設定できます。

この節の残りでは、クラス階層に帯域幅を割り振る例を示します。次のようなクラス階層を仮定します。

図 3-2 帯域幅の割り振りの例: クラス階層

Graphic

帯域幅を子クラスに割り振る前、root クラスは 100% の帯域幅を持ちます。

図 3-3 帯域幅の割り振りの例: root には 100% が割り振られている

Graphic

root クラスの子クラス (図 3-4 の、1、2、3) に、root クラスに割り振られている帯域幅を分配します。

図 3-4 帯域幅の割り振りの例: root の子クラス

Graphic

root クラス自身にも、自分に割り振られたトラフィックを処理するためにいくらかの帯域幅が必要です。したがって、子クラスには帯域幅の 100% を割り振らないようにしてください。上記の root クラスは残りの 5% を使用します。

それぞれの子クラスにおいて、割り振られている帯域幅を自身の子クラスに分配します。たとえば、クラス 1 に割り振られている 30% の帯域幅を、子クラスであるクラス 1.1 とクラス 1.2 に分配します。図 3-5 で括弧内の数字は、子クラスに割り振った後の残りの帯域幅を示しています。この残りの帯域幅は実際には親クラスに対する最低保障帯域幅となります。

図 3-5 帯域幅の割り振りの例: 2 番目のレベルのクラス

Graphic

すべてのクラスに帯域幅が割り振られるまで、各クラスに割り振られた帯域幅をその子クラスに分けていきます。

図 3-6 帯域幅の割り振りの例: 割り振りの完了

Graphic

注 -

設定ファイル内でクラスに帯域幅を指定する場合、または batool を使う場合は、クラスとそのすべての子孫に割り振る帯域幅の合計を指定する必要があります。たとえば、クラス 3.1 には 20% を指定し、クラス 1 には 30% を指定します。

帯域幅の借用

帯域幅を割り振るとき、すべてのクラスには最低保障帯域幅があります。ただし、そのクラスのトラフィック量が割り振られている帯域幅を超えた場合に、他のクラスが使用していない予備の帯域幅が存在すれば、そのクラスはその予備の帯域幅を借用できます。Graphic

上記設定において、クラス 1.2 のトラフィックが割り振られている 5% を超えて 7% になったと仮定します。ただし、クラス 1 の総トラフィックが 20% まで増加しただけで、クラス 1 には借用のための 10% の予備の帯域幅が残っているとします。つまり、クラス 1.2 はクラス 1 から 10% までの帯域幅を借用できます。したがって、この場合は必要な 2% の帯域幅を借用できます。

ただし、別のクラスの最低保障帯域幅を犠牲にしてまで、借用はできません。クラス 1.2 のトラフィックが 7% のままで、クラス 1.1 のトラフィックが 15% までに増加し、クラス 1 における総トラフィックが 30 % まで増加したと仮定します。この場合、クラス 1.2 はその親クラス (クラス 1) から借用し続けることはできません。しかし、クラス 1 がその親クラス (root クラス) から借用できる場合もあります。この場合、クラス 1.2 はクラス 1 からその追加の帯域幅を借用できます。

複数のクラスが帯域幅を借用したい場合、どのクラスが借用できるかはクラスの優先度によって決定されます。最高の優先度を持つクラスは、必要としている帯域幅以上のすべてを (利用可能な場合に) 借用できます。さらに帯域幅が残っている場合、次に優先度の高いクラスが借用できます。以降、同じように借用できます。

同じ優先度を持つ複数のクラスが借用したい場合は、最低保障帯域幅の量によって決定されます。たとえば、クラス 1.1 (15%) とクラス 1.2 (5%) の両方が借用したい場合に、両方が同じ優先度を持っていると、使用可能な帯域幅が 3:1 の割合で分割されます。

注 -

優先度の高いクラスが他のクラスを無視してすべての帯域幅を借用することを防ぐためには、次のようにします。

設定の計画の例

この節では、架空の会社のヨーロッパネットワーク (パリ、ボン、ロンドンの 3 箇所) で使用されている帯域幅管理の例を示します。

この例では、パリとボンのサイトには、それぞれ、ビジーな LAN があり、その LAN または他のサイトからのトラフィックをロンドンに経路制御して送ります。パリからロンドンには 256K の回線があります。ボンからロンドンには 768K の回線があります。また、パリからボンには直接のダイアルアップリンクがあります。ロンドンには独自の LAN があり、その LAN またはパリとボンからのトラフィックを米国のサイトに 10M バイトの回線で経路制御して送ります。

図 3-7 ある企業の帯域幅割り振りの計画

Graphic

3 つのすべてのサイトにおいて、ネットワーク管理者は実際のネットワーク使用状況を、一定の期間監視しました。また、ネットワークの利用上、もっとも重要な 3 つの点はなにかとユーザーに尋ねました。次の節では、各サイトのデータと設計された設定を示します。

パリ

図 3-8 パリのサイトにおける実際のネットワーク使用状況

Graphic

パリのサイトのネットワークユーザーは、ネットワークにおいてもっとも重要なものは、電子メール、ファイル転送、および World Wide Web へのアクセスであると考えています。図 3-8 に、実際の使用状況パターンを示します。

ネットワーク使用状況についてのデータとユーザーからの回答を考慮して、ネットワーク管理者は、図 3-9 のようなクラス階層を設計し、優先度と帯域幅 (%) を表 3-1 のように割り当てました。

図 3-9 パリのサイトにおけるクラス構造

Graphic

表 3-1 パリのサーバーにおける帯域幅と優先度のクラスへの割り振り

クラスの説明 

クラス名 

親クラス 

割り振られる帯域幅 (%) 

優先度 

ルート 

root 

 

100 

1 

ボンへの HTTP 

http-bonn 

http 

5 

3 

ロンドンまたは米国への HTTP 

http-lon 

http 

10 

3 

他の場所への HTTP 

http 

root 

20 

5 

telnet 

telnet 

root 

30 

1 

システム監視 

snmp 

root 

5 

1 

電子メール 

email 

root 

20 

4 

ファイル転送 

ftp 

root 

15 

7 

デフォルト 

default 

root 

5 

7 

batool と設定ファイルでは、クラスとそのすべての子孫に割り振る帯域幅を指定する必要があります。たとえば、http-bonn クラスと http-lon クラスは両方とも http クラスの子クラスです。http クラスとその子孫には帯域幅の 20% を割り振り、その子クラスである http-bonn クラスには 5% を、http-lon クラスには 10% を割り振っています。

この設定では、FTP トラフィックで使用される帯域幅は、現在の使用率は 30% を超えていますが 15% に制限されています。

ボン

図 3-10 ボンのサイトにおける実際のネットワーク使用状況

Graphic

ボンのサイトのネットワークユーザーは、ネットワークの使用でもっとも重要なものは、電子メールとカレンダへのアクセスであると考えています。受注管理システムは HTTP を使用してデータを転送します。図 3-10 に、実際の使用状況を示します。

ネットワーク使用状況についてのデータとユーザーからの回答を考慮して、ネットワーク管理者は、図 3-11 のようなクラス階層を設計し、表 3-2 のような優先度と帯域幅 (%) を割り当てました。

図 3-11 ボンのサイトにおけるクラス構造

Graphic

表 3-2 ボンのサーバーにおける帯域幅と優先度のクラスへの割り振り

クラスの説明 

クラス名 

親クラス 

割り振られる帯域幅 (%) 

優先度 

ルート 

root 

 

100 

1 

パリへの HTTP 

http-paris 

http 

18 

2 

ロンドンまたは米国への HTTP 

http-lon 

http 

18 

2 

他の場所への HTTP 

http 

root 

40 

2 

電子メール 

email 

root 

20 

6 

システム管理用の telnet 

telnet 

sysadmin 

8 

1 

SNMP 

snmp 

sysadmin 

10 

4 

システム管理 

sysadmin 

root 

20 

1 

デフォルト 

default 

root 

10 

7 

ロンドン

図 3-12 ロンドンのサイトにおける実際のネットワーク使用状況

Graphic

ロンドンのサイトのネットワークユーザーは、ネットワークにおいてもっとも重要なものは、電子メール、カレンダへのアクセス、およびファイル転送であると考えています。図 3-12 に、実際の使用状況を示します。

ロンドンのサイト用にクラス階層を設計して、帯域幅と優先度をクラスに割り当てるには、次の項目を考慮する必要があります。

このような問題をすべて考慮して、ネットワーク管理者は、経路制御ソフトウェアを実行するホスト上で Solaris Bandwidth Manager ソフトウェアを実行することに決定し、図 3-13 のようなクラス階層を設計しました。

括弧内のクラスは実際のクラスではありません。これは、親クラスに帯域幅を残し、そのすべてのトラフィックを子クラスで占有しないことをネットワーク管理者に注意するものです。たとえば、http クラスには、米国とヨーロッパ用に 2 つの子クラスがあります。http クラスには、米国とヨーロッパ以外に送信される http トラフィックもあります。このようなトラフィックは http クラスに割り振られます。そのため

http クラスに割り振られているすべての帯域幅を米国とヨーロッパ用の 2 つの子クラスだけで共有するべきではありません。表 3-3 に、各クラスに割り当てられた帯域幅 (%) と優先度を示します。

図 3-13 ロンドンのサイトにおけるクラス構造

Graphic

表 3-3 ロンドンのサーバーにおける帯域幅と優先度のクラスへの割り振り

クラスの説明 

クラス名 

親クラス 

割り振られる帯域幅 (%) 

 

ルート 

root 

 

100 

1 

HTTP 

http 

root 

35 

4 

米国への HTTP 

http-to-US 

http 

20 

2 

パリから米国への HTTP 

http-Paris-to-US 

http-to-US 

4 

4 

ボンから米国への HTTP 

http-Bonn-to-US 

http-to-US 

10 

2 

英国から米国への HTTP 

http-UK-to-US 

http-to-US 

4 

4 

ヨーロッパへの HTTP 

http-to-europe 

http 

10 

4 

電子メール 

email 

root 

30 

3 

パリからの電子メール 

email-paris 

email 

5 

3 

パリからの電子メール (IMAP) 

email-paris-imap 

email-paris 

4 

3 

パリからの電子メール (SMTP) 

email-paris-smtp 

email-paris 

1 

6 

ボンからの電子メール 

email-bonn 

email 

15 

3 

ボンからの電子メール (IMAP) 

email-bonn-imap 

email-bonn 

12 

3 

ボンからの電子メール (SMTP) 

email-bonn-smtp 

email-bonn 

3 

5 

IMAP を使用する電子メール 

email-imap 

email 

7 

3 

SMTP を使用する電子メール 

email-smtp 

email 

2 

5 

FTP 

ftp 

root 

15 

7 

システム管理 

sysadmin 

root 

10 

2 

Telnet 

telnet 

sysadmin 

5 

1 

システム監視 

snmp 

sysadmin 

2 

2 

システム管理コンソールから 

administrator 

sysadmin 

2 

1 

デフォルト 

default 

root 

5 

7 

パリまたはボンから発信されたトラフィックを含むクラスに割り当てられた帯域幅 (%) では、これらのサイトとロンドンのサイトの間のリンクの容量の違いを考慮しています。たとえば、ボンからの電子メール用のクラスには、パリからの電子メール用のクラスの 3 倍の帯域幅が割り振られています。