サービス品質 (QoS) ポリシーを計画するときは、ネットワークが提供するサービスの確認、分類、そして優先順位付けを行う必要があります。また、利用できる帯域幅の大きさを評価して、各トラフィッククラスがネットワークに送出される速度を決める必要もあります。
QoS ポリシーを計画するための情報を IPQoS 構成ファイルに必要な情報を含む形式で収集します。たとえば、次のテンプレートを使って、IPQoS 構成ファイルで使用する主な情報を表にすることができます。
表 2–2 QoS 構成テンプレート
クラス |
優先順位 |
フィルタ |
セレクタ |
速度 |
転送動作をどうするか |
アカウンティングが必要か |
---|---|---|---|---|---|---|
クラス 1 |
1 |
フィルタ 1
|
セレクタ 1 セレクタ 2 |
メーターの速度 (メーターの種類による) |
マーカーのドロップ優先度 |
フローアカウンティング統計情報を必要とする |
|
|
フィルタ 2 |
セレクタ 1 セレクタ 2
|
|
|
|
クラス 2 |
2 |
フィルタ 1 |
セレクタ 1 セレクタ 2 |
メーターの速度 (メーターの種類による) |
マーカーのドロップ優先度 |
フローアカウンティング統計情報を必要とする |
|
|
フィルタ 2 |
セレクタ 1 セレクタ 2 |
|
|
|
各カテゴリをいくつかに分けて、QoS ポリシーをさらに細かく定義することができます。以下では、テンプレートに示されているカテゴリの情報を入手する方法について説明します。
次の作業マップは、QoS ポリシーを計画するための主な作業を示しています。
表 2–3 QoS ポリシーの計画 (作業マップ)
作業 |
説明 |
参照先 |
---|---|---|
1. IPQoS をサポートするようネットワークトポロジを設計する |
差別化サービスを提供するネットワーク上のホストとルーターを特定する | |
2. ネットワーク上のサービスを分類するためのクラスを定義する |
自分のサイトで提供するサービスの種類と SLA を調べ、これらのサービスを分類するためのトラフィッククラスを決める | |
3. クラス用のフィルタを定義する |
特定のトラフィッククラスをネットワークトラフィックフローから取り出すための最善の方法を決める | |
4. IPQoS システムから送出されるトラフィックを測定するためのフロー制御速度を定義する |
トラフィッククラスごとに容認できるフロー速度を決める | |
5. QoS ポリシーで使用する DS コードポイントすなわちユーザー優先順位の値を定義する |
トラフィックフローがルーターまたはスイッチによって処理されるときに割り当てられる転送動作を決める方法を計画する | |
6. 必要であれば、ネットワーク上のトラフィックフローに対する統計監視計画を設定する |
トラフィッククラスを評価して、アカウンティングまたは統計上の目的で監視するトラフィックフローを決める |
この節の残りの部分では、IPQoS 対応システムの QoS ポリシーを計画する方法について説明します。diffserv ルーターの QoS ポリシーを計画する方法については、ルーターのマニュアルおよびルーター製造元の Web サイトを参照してください。
次の手順は、QoS ポリシーを作成する前に行う一般的な計画作業を示しています。
ネットワークトポロジを確認し、IPQoS システムと diffserv ルーターを使用するトポロジを計画します。
トポロジの例については、diffserv ネットワークトポロジの計画を参照してください。
IPQoS を必要とするホスト、または IPQoS サービスの有力な候補となるホストをトポロジで特定します。
IPQoS 対応後に同じ QoS ポリシーを共用できそうなシステムを調べます。
たとえば、ネットワーク上のすべてのホストで IPQoS を有効にする場合は、同じ QoS ポリシーを使用できるホストをすべて特定します。 各 IPQoS 対応システムにはローカル QoS ポリシーが必要で、そのポリシーはそれぞれの IPQoS 構成ファイルに実装されます。 ただし、IPQoS 構成ファイルを 1 つだけ作成し、これを同じ QoS 要件を持つすべてのシステムにコピーして使うこともできます。
ネットワーク上の diffserv ルーターに対して必要な計画作業をすべて確認し、実行します。
詳細については、ルーターのマニュアルとルーター製造元の Web サイトを参照してください。
QoS ポリシーを定義する最初の手順は、トラフィックフローをいくつかのクラスに分類することです。diffserv ネットワーク上のトラフィックの種類ごとにクラスを作成する必要はありません。また、計画したネットワークトポロジによっては、IPQoS 対応システムごとに異なる QoS ポリシーを作成する必要があります。
クラスの概要については、クラスを参照してください。
次の手順の前に、IPQoS 用のネットワークを準備する方法で特定したとおり、ネットワーク上のどのシステムを IPQoS 対応とするかが決まっているものとします。
QoS ポリシーを構成するための表を作成します。
推奨される表については、表 2–2を参照してください。
ネットワーク上にあるすべての QoS ポリシーについて、残りの手順を実行します。
QoS ポリシーで使用するクラスを定義します。
次の質問は、ネットワークトラフィックを解析してクラス定義を行うためのガイドラインとなります。
顧客にサービスレベル契約を提示しているか
提示する場合は、顧客に提供する複数の SLA 間の相対的な優先レベルを評価します。保証されている優先レベルが異なる顧客に同じアプリケーションを提供する場合もあります。
たとえば、企業が各顧客に対して Web サイトの運営サービスを提供するとします。この場合は、顧客の Web サイトごとに 1 つのクラスを定義する必要があります。また、プレミアム Web サイトをサービスレベルの 1 つとして提供する SLA もあれば、ベストエフォートの個人用 Web サイトを割引き客に提供する SLA もあります。この場合は、Web サイトのクラスが異なるだけでなく、クラスに割り当てられる PHB も異なる可能性があります。
IPQoS システムでは、フロー制御を必要としそうなよく使われるアプリケーションを提供しているか
よく使われるアプリケーションを提供しているために大量のトラフィックが生成されるサーバーの場合、IPQoS を有効にするとネットワークパフォーマンスが向上します。そのようなアプリケーションの例として、電子メール、ネットワークニュース、FTP などがあげられます。該当する場合は、サービスの種類ごとに着信トラフィックと発信トラフィックのクラスを別々に作成することを検討してください。たとえば、メールサーバーの QoS ポリシーに対して、mail-in クラスと mail-out クラスを作成します。
ネットワークでもっとも高い優先順位の転送動作を必要とする特定のアプリケーションを実行しているか
もっとも高い優先順位の転送動作を必要とする重要なアプリケーションは、ルーターで特別な処理を受ける必要があります。一般的な例は、ストリーミングビデオやストリーミングオーディオです。
まず、優先順位の高いこれらのアプリケーションに対して、それぞれ着信クラスと発信クラスを定義します。次に、定義したクラスを、それらのアプリケーションを提供する IPQoS 対応システムと diffserv ルーターの両方の QoS ポリシーに追加します。
帯域幅を大量に消費するため、ネットワークで制御を必要とするトラフィックフローが発生したことがあるか
netstat、snoop などのネットワーク監視ユーティリティを使用して、ネットワーク上で問題のあるトラフィックの種類を検出します。これまでに作成したクラスを確認し、問題のトラフィックカテゴリが未定義である場合は、このカテゴリに対して新しいクラスを作成します。問題のトラフィックカテゴリのクラスが定義済みである場合は、このトラフィックを制御するメーターの速度を定義します。
問題のあるトラフィックのクラスは、ネットワーク上の IPQoS 対応システムごとに作成します。これによって、各 IPQoS システムは、問題のあるトラフィックを受け取った場合に、トラフィックフローをネットワークに送出する速度を制限できるようになります。また、diffserv ルーターの QoS ポリシーにもこれらの問題のあるクラスを必ず定義してください。これによって、diffserv ルーターは、QoS ポリシーの設定に従って、問題のあるフローをキューに入れたりスケジュールしたりできるようになります。
特定の種類のトラフィックに対して統計情報を取得する必要があるか
SLA をざっと確認すると、どのタイプの顧客のトラフィックにアカウンティングが必要であるかがわかります。自分のサイトで SLA を提供している場合は、アカウンティングを必要とするトラフィックのクラスはおそらく作成済みです。また、クラスを新たに定義して、監視中のトラフィックフローやセキュリティ上の目的でアクセスを制限しているトラフィックフローの統計情報を取得することもできます。
QoS 構成表に定義したクラスを記入します。
優先レベルを各クラスに割り当てます。
たとえば、優先レベル 1 がもっとも高い優先順位のクラスを表すようにし、それ以降の優先レベルを残りのクラスに割り当てます。優先レベルは、構成上の目的で割り当てているだけで、IPQoS が実際に使用するわけではありません。また、QoS ポリシーによっては、同じ優先順位を複数のクラスに割り当てることもできます。
クラスの優先順位付けの重要性については、次の項を参照してください。
クラスの定義が終わったら、次はクラスごとにフィルタを定義します (QoS ポリシーにフィルタを定義する方法を参照)。
クラスを作成するうちに、どのクラスの優先順位が高いか、中程度か、ベストエフォートでよいかがすぐに明らかになってきます。クラスの優先順位付けは、PHB (ホップ単位動作) を発信トラフィックに割り当てるときに特に重要となります (転送動作を計画する方法を参照)。
PHB をクラスに割り当てるほかに、そのクラスのフィルタに優先順位セレクタを定義することもできます。優先順位セレクタは、IPQoS 対応ホストでのみ有効です。たとえば、同じ速度と同じ DSCP を持ついくつかのクラスが、IPQoS システムから送出されるときに帯域幅をめぐって競合することがあるとします。このような場合、各クラスの優先順位セレクタによって、他の点ではまったく同じ評価のクラスに割り当てられるサービスレベルをさらに細かく順序付けることができます。
パケットフローを特定のクラスのメンバーとして識別するには、フィルタを作成します。各フィルタには、パケットフローの評価基準を定義するセレクタがいくつか含まれています。IPQoS 対応システムは、セレクタに定義されている基準を使ってトラフィックフローからパケットを取り出し、それらのパケットをクラスに対応付けます (フィルタの概要については、フィルタを参照)。
次の手順に進む前に、QoS ポリシーのクラスを定義する方法を終わらせておく必要があります。
QoS ポリシーのクラスを定義する方法で作成した QoS 構成表のクラスごとにフィルタを最低 1 つ作成します。
必要であれば、1 つのクラスの着信トラフィックと発信トラフィックに対して、フィルタを別々に作成することを検討してください。たとえば、ftp-in フィルタと ftp-out フィルタを IPQoS 対応の FTP サーバーの QoS ポリシーに追加します。そうすれば、基本セレクタに加えて、該当する方向セレクタも定義できます。
クラスのフィルタごとにセレクタを最低 1 つ定義します。
次の表に、もっとも一般的に使用されるセレクタを示します。最初の 5 つのセレクタは、IPQoS 5 タプルを表し、IPQoS システムがパケットをフローのメンバーとして識別するときに使用します。利用可能なセレクタについては、表 6–1 を参照してください。
セレクタは正しい判断のもとで選択してください。 また、クラスのパケットを取り出すのに必要なものだけを使用してください。 定義するセレクタが多いほど、IPQoS パフォーマンスに与える影響も大きくなります。
名前 |
定義 |
---|---|
saddr |
発信元アドレス |
daddr |
着信先アドレス |
sport |
発信元ポート番号。 /etc/services に定義されている既知のポート番号、またはユーザー定義のポート番号を使用できる |
dport |
着信先ポート番号 |
protocol |
IP プロトコル番号またはプロトコル名。/etc/protocols のトラフィックフロータイプに割り当てられる |
ip_version |
使用するアドレス指定方式。V4 または V6 を使用する。デフォルトは V4 |
dsfield |
DS フィールドの内容、つまり DS コードポイント。 このセレクタは、特定の DSCP が付いている着信パケットを取り出すために使用する |
priority |
クラスに割り当てられている優先レベル。 詳細については、クラスの優先順位付けを参照 |
user |
UNIX のユーザー ID またはユーザー名。上位アプリケーションの実行時に使用される |
projid |
プロジェクト ID。上位アプリケーションの実行時に使用される |
direction |
トラフィックフローの方向。 LOCAL_IN、LOCAL_OUT、FWD_IN、または FWD_OUT のいずれかの値 |
表 2–2 で紹介したテンプレートを使用して、定義したクラスのフィルタを記入します。
クラス |
優先順位 |
フィルタ |
セレクタ |
---|---|---|---|
ftp-traffic |
4 |
ftp-out |
saddr 10.190.17.44 daddr 10.100.10.53 sport 21 direction LOCAL_OUT |
作業 |
参照先 |
---|---|
フロー制御方式を定義する | |
フローがネットワークストリームに戻されるときの転送動作を定義する | |
特定の種類のトラフィックに対してフローアカウンティングを計画する | |
QoS ポリシーにさらにクラスを追加する | |
QoS ポリシーにさらにフィルタを追加する |
フロー制御では、まずクラスのトラフィックフローを測定し、次に定義された速度でパケットをネットワークに送出します。フロー制御を計画するときは、IPQoS メータリングモジュールが使用するパラメータを定義します。メーターは、トラフィックがネットワークに送出される速度を決定します。メーターの概要については、メーター (tokenmt および tswtclmt) の概要を参照してください。
次の手順の前に、QoS ポリシーにフィルタを定義する方法の説明に従って、フィルタとセレクタを定義してあるものとします。
ネットワークの最大帯域幅を調べます。
ネットワーク上でサポートされている SLA をすべて確認して、顧客と各顧客に保証されているサービスの種類を特定します。
SLA はある一定レベルのサービスを顧客に保証しているため、顧客によって生成される特定のトラフィッククラスを計測する必要があります。
QoS ポリシーのクラスを定義する方法で作成したクラスのリストを確認します。
SLA に対応付けられているクラス以外に計測する必要があるクラスがあるかどうか確認します。
たとえば、IPQoS システムが大量のトラフィックを生成するアプリケーションを実行するとします。この場合は、そのアプリケーションのトラフィックを分類したあと、フローのパケットがネットワークに戻される速度を制御して、フローを計測します。
すべてのクラスを計測する必要があるとは限りません。 クラスのリストを確認するときは、このガイドラインに留意してください。
クラスのどのフィルタがフロー制御を必要とするトラフィックを選択するかを確認することにより、計測するクラスのリストを作成し直します。
複数のフィルタを持つクラスでも 1 つのフィルタに対してだけ計測を必要とする場合もあります。たとえば、あるクラスの着信トラフィックと発信トラフィックに対してフィルタを定義したとします。しかし、結果的にどちらかの方向のトラフィックしかフロー制御を必要としない場合があります。
フロー制御を行うクラスごとにメーターモジュールを選択します。
作成した構成表のメーター欄にモジュール名を追加します。
計測するクラスごとの速度を構成表に追加します。
tokenmt モジュールを使用する場合は、次の速度を bps で定義する必要があります。
認定速度
最大速度
特定のクラスの計測に十分な場合は、認定速度と認定バーストを tokenmt に定義するだけでも構いません。
認定バースト
最大バースト
tokenmt の速度の詳細については、tokenmt をツーレートメーターとして構成するを参照してください。tokenmt(7ipp) のマニュアルページでも詳しく説明しています。
tswtclmt モジュールを使用する場合は、次の速度を bps で定義する必要があります。
認定速度
最大速度
また、ウィンドウサイズをミリ秒単位で定義することもできます。これらの速度は、tswtclmt メータリングモジュールおよび twstclmt(7ipp) のマニュアルページに定義されています。
計測するトラフィックのトラフィック適合結果 (outcome) を追加します。
どちらのメータリングモジュールでも、結果は緑、赤、黄の 3 つです。定義した速度に当てはまるトラフィック適合結果を QoS 構成表に追加します。これらのメーターの結果については、メーターモジュールで詳しく説明します。
認定速度に適合したトラフィックまたは適合しなかったトラフィックに対して取るべきアクションを決める必要があります。よく取られるアクションは、パケットヘッダーに PHB を付けることですが、常にそうするわけではありません。緑レベルのトラフィックに対して取りうるアクションの 1 つとして、トラフィックフローが認定速度を超えないかぎり処理を続行することもあります。あるいは、フローが最大速度を超えた場合にそのクラスのパケットをドロップすることもできます。
次の表に、電子メールトラフィックのクラスに対するメーターの記入例を示します。この IPQoS システムが配置されているネットワークには、合計 100 Mbps (100000000 bps) の帯域幅があります。QoS ポリシーは、電子メールクラスに対して、低い優先順位とベストエフォートの転送動作を割り当てています。
表 2–5 メーターが定義されている QoS ポリシーの例
クラス |
優先順位 |
フィルタ |
セレクタ |
速度 |
---|---|---|---|---|
|
8 |
mail_in |
daddr 10.50.50.5 dport imap direction LOCAL_IN |
|
|
|
mail_out |
saddr 10.50.50.5 sport imap direction LOCAL_OUT |
メーター =tokenmt 認定速度 =5000000 認定バースト =5000000 最大速度 =10000000 最大バースト =1000000 緑の優先度 = 処理続行 黄の優先度 = 黄の PHB を付加 赤の優先度 = ドロップ |
作業 |
参照先 |
---|---|
フローがネットワークストリームに戻されるときの転送動作を定義する | |
特定の種類のトラフィックに対してフローアカウンティングを計画する | |
QoS ポリシーにさらにクラスを追加する | |
QoS ポリシーにさらにフィルタを追加する | |
別のフロー制御方式を定義する | |
IPQoS 構成ファイルを作成する |
転送動作は、ネットワークに転送されようとしているトラフィックフローの優先順位とドロップ優先度を決めます。 選択できる主な転送動作は 2 つあります。1 つは他のトラフィッククラスとの関連でクラスのフローに優先順位を付けることで、もう 1 つはフローを完全にドロップすることです。
diffserv モデルでは、マーカーを使用して、選択した転送動作をトラフィックフローに割り当てます。 IPQoS には、次のマーカーモジュールが用意されています。
この節では、IP パケットに限定して説明します。 IPQoS システムに VLAN デバイスが含まれている場合は、dlcosmk マーカーを使って、データグラムの転送動作をマークできます。 詳細については、VLAN デバイスでの dlcosmk マーカーの使用を参照してください。
IP トラフィックに優先順位を付けるには、各パケットに DS コードポイントを割り当てる必要があります。 dscpmk マーカーでは、パケットの DS フィールドに DS コードポイントを付けます。 クラスの DS コードポイントは、転送動作の種類に対応付けられている既知のコードポイントのグループから選択します。既知のコードポイントには、EF PHB 用の 46 (101110) や AF PHB 用のいくつかのコードポイントがあります。DS コードポイントと転送の概要については、IPQoS 対応ネットワークでのトラフィック転送を参照してください。
次の手順の前に、QoS ポリシーのクラスとフィルタを定義してあるものとします。トラフィックを制御する場合は、メーターをマーカーと組み合わせて使用しますが、転送動作を定義するだけであれば、マーカーを単独で使用できます。
これまでに作成したクラスとそれらに割り当てた優先順位を確認します。
すべてのトラフィッククラスをマークする必要があるとは限りません。
もっとも高い優先順位のクラスに EF PHB を割り当てます。
EF PHB は、EF DS コードポイント 46 (101110) を持つパケットが、AF PHB を割り当てたパケットよりも先にネットワーク上に送出されることを保証します。このため、もっとも高い優先順位のトラフィックには EF PHB を使用します。EF の詳細については、完全優先転送 (Expedited Forwarding、EF) PHBを参照してください。
トラフィックを計測するクラスに転送動作を割り当てます。
トラフィックの計測は、一般に次の理由で行います。
SLA は、ネットワークの使用率が高いときでも、このクラスのパケットにある程度のサービスを保証する
低い優先順位のクラスがネットワークをあふれさせる傾向がある
マーカーをメーターと組み合わせて使用すると、これらのクラスに対して差別化サービスを提供したり帯域幅の管理を行ったりできます。次の表に、高いレベルのトラフィックを生成するよく使われるゲーム用アプリケーションのクラスを定義した、QoS ポリシー例の一部を示します。
クラス |
優先順位 |
フィルタ |
セレクタ |
速度 |
転送 |
---|---|---|---|---|---|
games_app |
9 |
games_in |
sport 6080 |
|
|
|
|
games_out |
dport 6081 |
メーター =tokenmt 認定速度 =5000000 認定バースト =5000000 最大速度 =10000000 最大バースト =15000000 緑の優先度 = 処理続行 黄の優先度 = 黄の PHB を付加 赤の優先度 = ドロップ
|
緑 =AF31 黄 =AF42 赤 = ドロップ |
これらの転送動作では、認定速度に適合しているか、最大速度を下回っている games_app トラフィックには、低い優先順位の DS コードポイントを割り当てます。games_app トラフィックが最大速度を上回ると、QoS ポリシーは games_app のパケットをドロップするよう指示します。すべての AF コードポイントは、表 6–2 に示してあります。
残りのクラスに、すでに割り当てた優先順位に応じた DS コードポイントを割り当てます。
作業 |
参照先 |
---|---|
特定の種類のトラフィックに対してフローアカウンティングを計画する | |
QoS ポリシーにさらにクラスを追加する | |
QoS ポリシーにさらにフィルタを追加する | |
フロー制御方式を定義する | |
フローがネットワークストリームに戻されるときの追加の転送動作を定義する | |
IPQoS 構成ファイルを作成する |
IPQoS の flowacct モジュールを使用すると、課金やネットワーク管理の目的で、トラフィックフローを常時監視できます。 次の手順に従って、QoS ポリシーにフローアカウンティングを含める必要があるかどうか判断してください。
顧客に SLA を提示していますか
提示している場合は、フローアカウンティングを使用する必要があります。まず、SLA を確認して、企業が顧客に使用料を請求するネットワークトラフィックの種類を調べます。次に、QoS ポリシーを確認して、課金の対象となるトラフィックが含まれるクラスを調べます。
ネットワークの問題を防ぐために監視またはテストを必要とするアプリケーションはありますか
ある場合は、フローアカウンティングを使ってそれらのアプリケーションの動作を監視することを検討します。QoS ポリシーを確認して、監視を必要とするトラフィックに割り当てたクラスを調べます。
QoS 計画テンプレートで、フローアカウンティングを必要とする各クラスのフローアカウンティング欄に Y と記入します。
作業 |
参照先 |
---|---|
QoS ポリシーにさらにクラスを追加する | |
QoS ポリシーにさらにフィルタを追加する | |
フロー制御方式を定義する | |
フローがネットワークストリームに戻されるときの転送動作を定義する | |
特定の種類のトラフィックに対して追加のフローアカウンティングを計画する | |
IPQoS 構成ファイルを作成する |