 |
||
|
|
|
| 注意： 本製品は既に生産⁄販売を終了しております。 |
|
  |
レポート |
[目次]
シスコシステムズとオラクル社では、シスコによるインテリジェントネットワークサービスであるQoS（Quality of Service）とポリシー管理を使ってOracle Applicationsのユーザーに優先的なネットワークアクセスを与えた場合の効果について調査しました。CiscoAssureポリシーネットワーキングは、QoSやポリシーベースの機能を統合したインテリジェントなネットワーキングデバイスによって構築され、ビジネスに不可欠なアプリケーションに対して優先的なサービスを提供します。今回のテストで使用したシスコ製品には、ルータおよびスイッチ、Cisco IOS®ソフトウェア、Cisco QoS Policy Manager（QPM）などがあります。QPMは、ポリシーの実装に使用しました。
ベンチマークの要約
- シスコのQoSソリューションは、複数のアプリケーションによって共有されている低速度のWANリンクを経由するOracle Applicationsのパフォーマンスを大幅に改善しました。
- 他のアプリケーショントラフィックのために非常に混雑しているテスト回線を使って、Oracleのトランザクション完了時間を測定しました。ポリシーの実装によって、トランザクション時間が100％以上削減されました（図1参照）。
- 重要度の低いアプリケーションのスループットを抑えることにより、Oracle Applicationsのストリームに対して優先順位の高いアクセスを提供できました。
- 特定のOracle Applicationsモジュールのユーザーに対して優先的なサービスを提供できるという結果が出ました。
- ベンチマークで使われたQoSポリシーの実装と追跡は、Cisco QoS Policy Managerを使って簡単に設定できました。
ルータやスイッチを通るトラフィックが回線の帯域幅を超えてしまうようなときには、ポリシーの設定によってトラフィックの種類ごとに異なるサービスレベルを提供します。これらのポリシーを設定すると、ユーザーによって指定された優先ルールにしたがって、ネットワークデバイスのキューにあるパケットに優先順位が付けられたり、輻輳時に重要ではないパケットが廃棄されたりします。
図1：128Kbpsの回線経由で実行するOracle Applicationsのテスト結果
シスコとオラクル社の共同テスト・ラボに構築したテスト用ネットワークでは、小さなブランチオフィスのローカルエリアネットワーク（LAN）を企業本部のバックボーンに接続するための低速ワイドエリアネットワーク（WAN）リンクをシミュレートしています。今回は、異なるポリシーを設定した状況でテストするために、３つのテスト手順を用意しました。図1には、128Kbpsでテスト実行した結果をまとめます。これらの結果は、重要性の低い対話型アプリケーションや突発的なHTTP（Hypertext Transfer Protocol）のWebトラフィックなどが存在する場合、シスコQoSソリューションを使用することにより、アプリケーションのパフォーマンスを大きく改善できることを示しています。
テスト手順A、B、Cそれぞれについて、基本シナリオ、輻輳時のシナリオ、およびQoSポリシーを実装した場合のシナリオの3つを設定しています。基本シナリオでは、Oracle Applications以外のトラフィックがなく、ポリシーが実装されていない状態でパフォーマンスをテストします。輻輳時のシナリオでは、他にもトラフィックが存在する状態で、ポリシーを使用しない場合のOracleのパフォーマンスをテストします。このシナリオは、QoSポリシーの効果を調べるための基準となります。またテスト手順Cの場合、基本シナリオではOracleクライアントストリームの集まりだけであるのに対して、ポリシーを実行した場合には他のトラフィックよりも優先されるために、基本シナリオよりもポリシーを実行した場合の結果のほうが早いように見えます。
図1に示されている通り、各テスト手順では、QoSポリシーを使ってビジネスに必要不可欠なアプリケーションを保護すれば、基本シナリオにかなり近いパフォーマンスを達成することができました。
| Cisco QoS Policy Managerについて |
| 集中化されたポリシー制御 | GUIによって簡単に設定することができます。QPMを使って、QoSの構成、修正、および配備を管理することにより、デバイスごとの設定が必要なくなります。 |
| アプリケーショントラフィックに 対する差別化サービス |
アプリケーションのサービスレベルを差別化するためのトラフィックのクラス分けとQoSのポリシー設定を簡単にします。 |
| QoSドメイン構成 | インタフェースをインテリジェントにグループ分けして、ポリシードメインごとにQoSメカニズムを選択して実行できます。 |
| 包括的なQoS機能のサポート | 充実した輻輳管理、輻輳回避、およびトラフィックシェーピングのサービスを提供し、Cisco IOS®ソフトウェアとデバイスが持つQoS機能を活用します。 |
| 信頼性の高いポリシー配備 | ポリシーの妥当性検査、構成変更のプレビュー、ACLの部分的な更新、ジョブ制御といった機能により、QoSポリシーを確実にネットワーク装置に配備できます。 |
| Webベースのレポート | Webベースのレポートにより、QoSポリシーの配備や状況を表示したり、分析したりできます。 |
| デバイスとCisco IOSリリースの 包括的なサポート |
Cisco 2500、2600、3600、4000、4500、4700、7100、7200、および7500シリーズのルータ、Catalyst® 5000、Catalyst 8510、およびLocalDirector V.3.1.1用のRSMなどをサポートします。また、Cisco IOSのリリース、11.1、11.2、11.3、12.0、11.1ccをサポートします。 |
| CiscoWorks2000との統合 | ポリシー設定をResource Manager Essentials 2.0からデバイスにインポートすることによって、ポリシー実施に関する設定にかかる時間を短縮できます。CiscoWorks2000を使えば、Webベースのレポートを見ることもできます。 |
QPMの画面例 |
|
| 結果 |
サービスの優先 テスト手順Aでは、使用率の高いWANリンクでQPMを使うことにより、重要なOracleトラフィックをHTTPトラフィックよりも優先させました。テストは、64Kbps、128Kbps、および256Kbpsの3つの速度のWANリンクを使って、OracleのネットワーキングアプリケーションプロトコルとQPMのクラス分けオプションの互換性についての確認も行われました。
帯域幅に対する負荷を最大限に高めるように、Oracleのクライアント⁄サーバトラフィックとHTTPトラフィックのストリームの数を、リンク速度に合わせていろいろに変化させて使っています。図1に示した基本シナリオの場合、5つのOracleストリームを使用しています。また、輻輳時とポリシー適用時のシナリオでは、5つのOracleストリームのほかに、５つの対話型ストリームと2つのHTTPストリームも混在させています。このテストの結果、どのリンク速度でも同じようなパターンが認められたので、以降のテストでは128Kbpsのリンクのみを使うことにしました。また、Cisco IOSソフトウェアのさまざまなQoSテクニックを適用してその効果を検査しましたが、最も効果的だったのは、カスタムキューイング（CQ）テクニックであったため、以降のテストでは主にこのテクニックを使用しました。CQには、最初に保守的な設定を行い、後から徐々に厳しい設定を実行していく、便利な“ダイヤル”機能があります。
Oracleのトランザクションの完了にかかる時間は、ポリシーを適用しなかった場合では、基本シナリオから平均で50％から200％以上も増加したのに対して、ポリシーを適用した場合では、平均で10％しか増加しませんでした。なお、この場合の平均値とは、64Kbps、128Kbps、および256Kbpsのそれぞれの場合のテスト結果の平均としています。
テスト手順Bでは、リンクの速度は128Kbpsを使用し、CQテクニックを適用しました。ここでは、TCP/UDPポートのクラス分けを利用して、対話型アプリケーションとHTTPトラフィックのストリームのどちらよりも、Oracleトラフィックを優先させるようにしました。基本シナリオでは、5つのOracleストリームを使用しています。また、輻輳時とポリシー適用時のシナリオでは、5つのOracleストリームのほかに、５つの対話型ストリームと2つのHTTPストリームも混在させています。
図2から図4は、テスト手順Bの結果です。これらのグラフは、各トラフィックの種類ごとに、一連のトランザクションの完了にかかった時間を示しています。この結果から、QPMを使ってCQポリシーを設定することによって、異なる種類のトラフィックに対して異なるサービスレベルを提供できることが分かります。なお、このテストでは、Oracleのトラフィックが最優先され、他のアプリケーションのトラフィックには中位の優先順位、HTTPトラフィックには下位の優先順位が割り当てられています。
図2は、3種類のトラフィックストリームすべてについて、そのスループットを時間を軸に表示したものです。グラフを見てもわかるように、3種類のトラフィックがすべて存在する場合には、優先されているOracleのストリームが最も高いスループットを達成しています。Oracleストリームが送信を行っていない場合は、対話型アプリケーションのストリームがHTTPトラフィックよりも優先されています。
図2：3種類のアプリケーションストリーム---カスタムキューイングを適用してQoSを設定し、Oracleトラフィックには高い優先順位、会話型トラフィックには中程度、HTTPには低い優先順位を割り当てています。
図3 ：2 種類のストリーム---他のトラフィックが同じ回線上に存在する場合、QoSを適用しないOracle Applicationsよりも、QoSポリシーを適用したOracle Applicationsのほうがスループットが向上しています。
図4：QoSポリシーの適用によって、HTTPのスループットは低下しています。
図3と図4はどちらも、優先順位の違いによって、トラフィックスループットがどのように変化するかを示しています。図3では、Oracleトラフィックに対する効果が焦点となっています。HTTPトラフィックやその他のアプリケーションのトラフィックが存在するため、これらのストリームが結果に影響を与えているはずですが、グラフには現れていません。この図は、ポリシーを適用すると、ポリシーを適用しなかった場合に比べてOracleのスループットのレベルが常に高くなることを示しています。図4は、Oracleに大きな優先度のポリシーを適用したとしても、HTTPトラフィックが通れなくなるわけではないことを示しています。この場合も、Oracle以外のアプリケーションのストリームが存在しているので、これらのストリームが結果に影響を与えているはずですが、グラフには現れていません。
テスト手順Cでは、IPアドレスによってトラフィックを分類し、あるOracleクライアントを他のOracleクライアントのストリームやHTTPトラフィックよりも優先させています。このテストでは、128Kbpsのリンクを使い、CQポリシーテクニックを適用しました。基本シナリオでは、6つのOracleストリームを使用し、輻輳時とポリシー適用のシナリオでは、6つのOracleストリームと2つのHTTPストリームを使用しました。ただし、6つのOracleストリームのうち、1つのクライアントのトラフィックを残り5つのクライアントのトラフィックよりも優先するようにしています。
図5から図7までのグラフは、これらのテスト結果で、トラフィックの種類ごとに一連のトランザクションの完了までにかかった時間を示しています。図5と図6はポリシー適用前の結果を示しており、図7は特定のユーザーあるいはユーザーグループのトラフィックを他のトラフィックよりも優先させるようにポリシーを設定した場合になっています。これらの図では、優先された１つのクライアントをクライアントB、残りの5つのクライアントをクライアントAとして示しています。
図5：Oracle以外のトラフィックがなく、ポリシーを提供しない場合
図6：ポリシーを適用しなかった場合のHTTPトラフィックがOracleストリームに与える影響
図7：１つのクライアントのOracleストリームを他のトラフィックより優先させるようにポリシーを適用した場合
図5は、HTTPトラフィックがなく、ポリシーも適用しなかった場合のOracleクライアントストリームのパフォーマンスを示しています。どちらのクライアントとも、トランザクションは92秒以内に完了しています。図6では、HTTPトラフィックを追加して、ポリシーを設定しない場合で、どちらのOracleトラフィックともパフォーマンスが落ちていることが分かります。トランザクションの完了にかかる時間は、どちらも160秒に増えています。図7は、１つのクライアントのOracleトラフィックを他の5クライアントよりも2倍優先させることによる効果を示しています。優先させたクライアントのOracleトラフィックは、他の5つのクライアントのOracleやHTTPのストリームよりも高いスループットを示しています。優先させたクライアントのOracleストリームが存在しないときには、５つのクライアントのOracleストリームがHTTPトラフィックよりも優先されます。今回のテスト結果では、優先させたクライアントのトランザクション時間は約71秒であり、他の５つよりも30秒短く、ポリシーを適用せずにクライアントが１つだけのトランザクション時間よりも約90秒も短くなっています。
| 分析 |
Oracleや対話型のアプリケーションと、バッチやHTTPのようなバースト性アプリケーションの両方をサポートするWANリンクでは、重要な対話型アプリケーションのパフォーマンスを確保することが非常に困難です。ここでの問題は、バッチやバースト性のトラフィックを生成するアプリケーションが、可能な限り多くの帯域幅を使用するように設計されている点にあります。これらのアプリケーションは、多くの場合、低速度のWANリンクのほとんどの帯域幅を消費してしまいます。
一方、重要なクライアント⁄サーバトラフィックは、トラフィックのバーストが少なく、そのためにキューに入るパケットの数も少なくなります。キューのなかに何もない時には、HTTPのようなバースト性のトラフィックが帯域幅を占領してしまいます。したがって、クライアント⁄サーバのトラフィックの送信が必要になったときには、これらのアプリケーションのトラフィックと競合することになります。その結果、輻輳が発生し、対話型トランザクションで実行されるクライアントとサーバとのパケット交換が遅れ、対話型アプリケーションのユーザーにとって大幅なパフォーマンス低下となります。図8は、種類の異なるトラフィックの帯域幅に対する競争の問題を示しています。
図8：輻輳問題---バックグラウンドのトラフィックが優位に立ってしまいます。
3つのテスト手順は、Cisco QoSソリューションが、Oracleネットワークでの輻輳問題を解決するかどうかを調べるために行われました。テストでは、さまざまなQoSテクニックが使われました。その結果、今回の条件ではCQが最も効果的なテクニックであったため、ここでは他のテクニックの詳細については触れません。また、このテストを行った時点ではCisco IOS V.12.0.5がまだリリースされていなかったため、CBWFQ（Class-Based Weighted Fair Queuing）についてのテストも行われていません。このテクニックはCQを上回る結果を残せる可能性を持っています。CQテクニックが選択された理由の１つは、強固な規制を実行でき、対話型のOracleストリームを効果的に優先させることができるからです。Oracleトラフィックフローのバーストの頻度、バックグラウンドトラフィックの状況、応答時間の改善目標といった環境の違いによっては、他のQoSテクニックの方が適している場合もあります。
企業においてアプリケーションのトラフィックに優先順位付けを行う場合は、重要なアプリケーションを優先するために、重要でないアプリケーションが犠牲になるのは仕方がありません。しかし、特定のトラフィックを大きく優先するからと言って、バックグラウンドのトラフィックを極限まで抑える必要はありません。例えば、小さなリモートオフィスの対話型アプリケーションの優先度を上げたとしても、重要度の低いバースト性のトラフィックやバッチのトラフィックを完全に排除してしまう必要はないのです。実際にテストでは、OracleトラフィックのCQ帯域幅をリンクの95％に設定し、他のトラフィックのCQ帯域幅をリンクの5％と設定しても、HTTPスループットは一貫して利用可能な帯域幅の50％以上になっていました。つまり、QoSポリシーを適用するときには、事前にOracleストリームとその他のアプリケーションのストリームの両方を、慎重に分析する必要があります。
また、サービス差別化ポリシーを適用するためには、その前に、アプリケーショントラフィックを適切に分類しておくことが重要になります。アプリケーションのパケットは、デバイスのインタフェースに入る際に検査され、パケットのトラフィッククラスとインタフェースのポリシーが一致するかどうか確認されます。この２つが一致したときにのみ、ポリシーが適用されます。このため、テストの際にOracleポートのクラス分け機能の検査も行われました。検査の結果、レイヤ4ポートの範囲に基づくシスコのクラス分け機能との完全な互換性が確認されました。これらのテスト結果は、QoSポリシーを使えば、非Oracleトラフィックや他のOracleストリームと競合してしまうすべてのOracleストリームを優先できることを示しています。
つまり、細かな優先の指定を利用すれば、大規模Oracleエンタープライズのなかで、最も重要なOracleトラフィックだけを優先することもできます。
図9：ラボに構築されたテスト用ネットワークの構成
| テストの構成と方法 |
リモートオフィスのLANには、2つのMercury Interactive LoadRunner（LR）ワークステーションが接続されています。1つのLRは、本社のLANに接続されたアプリケーションサーバに対して複数のOracleトランザクションストリームを発信するために使いました。Oracle ApplicationsサーバとOracleデータベースの間でのバックエンドトラフィックは、Catalyst 5500スイッチにつながった本社のローカルネットワークを移動します。2つめのLRステーションは、リモートオフィスLANと本社のLANの間に、HTTPやその他の会話型アプリケーションのトラフィックを発生させるために使われました。別のテストでは、Cisco 7200の代わりにCisco 3600を使用して、CPUの使用率に対するポリシーの影響を調べました。これらのテストでは、CPUの使用率の増加は見られず、パフォーマンスはCisco 7200を使用した場合と同じでした。
テストのために使用したアプリケーションストリームは、リモートオフィスと本社の間での忙しい時間帯のトラフィック負荷を再現するように設計されています。オラクル社は、頻繁に使用されているOracleトランザクションを含んだLRスクリプトを提供してくれました。競合するトラフィック負荷を作成するために、帯域幅を大量に消費するHTTPダウンロードやその他の対話型アプリケーションのトランザクションも使いました。
各帯域幅の設定において、輻輳を生成するのに必要なアプリケーションストリームの数を判断するため、予備的なテストも行いました。このテストでは、まず最初に、パフォーマンスを劣化させない範囲で、サポートできるOracleストリームの最大値を調べました。次に、その他のアプリケーションストリームを含めたテストを実行しました。Oracle以外のストリームの数は、フレームリレーの帯域幅の使用率が100％になるまで、徐々に増やしていきます。
| QPMを使ったポリシー管理 |
結果の信頼度を上げるために、テストは複数回実行され、各テスト構成の確認が行われました。パケット追跡のキャプチャ、スクリプト完了時間の記録、およびスループットの測定は、光通信のアプリケーション専門化チームによって行われました。
テストの最初では、他のアプリケーションのフローを緩やかに規制するようにポリシーを構成しておき、徐々にOracleのフローを増やすように修正していきます。ポリシーが実行する規制の度合いは、Oracleのトランザクション時間が目標値に達するか、あるいはその他のアプリケーションのパケット損失が不適切なレベルを超えるまで厳しくしていきました。
| まとめ |
- シスコのQoSソリューションは、複数のアプリケーションによって共有されている低速度のWANリンクを経由するOracle Applicationsリリース11のパフォーマンスを大幅に改善しました。
- QoSポリシーの実装により、レスポンスタイムの2倍から3倍もの劣化を防ぐことができました。
- 重要度の低いアプリケーションのスループットを維持しながら、Oracle Applicationsのストリームに対して優先順位の高いアクセスを提供することができました。
- Oracle Applicationsポートのクラス分けは、QPM、およびレイヤ4情報を使用するシスコのクラス分け機能と完全な互換性を持っています。
- テスト結果、特定のOracle Applicationsモジュールを使用しているユーザーに対して優先的なサービスを提供できることを確認しました。
- QPMによって、ベンチマーク作成に使用したQoSポリシーの実装と把握が容易になりました。
| 利点 |
- シスコQoSソリューションを実装すれば、ブランチオフィスやホームオフィスのOracleユーザーに対して、信頼性の高いアクセスを提供することができます。
- QoSポリシーをうまく計画して実装すれば、高価なワイドエリアネットワークの帯域幅の使用を最適化して、インフラストラクチャに対する投資を保護します。
- Cisco QPMを使えば、複雑な企業ネットワークにでも、効果的なQoSポリシーの作成と管理を行うことができます。
| 結論 |
QoSを実装する際には、その前に、リンクを共有する全てのアプリケーションについて、アカウント管理と分析を行う必要があります。Oracelとその他のアプリケーショントラフィックについて、ビジネスにとっての重要度、フローの特性、ネットワークの遅延に対する許容範囲、トラフィックの量、および平均パケットサイズなどを綿密に調べるようにしてください。QoSを設定するときには、重要度の低い非Oralceトラフィックに対する抑制ポリシーの効果を慎重に考慮しなければなりません。
ポリシーを実装する場合は、ポリシーの実装前と実装後のアプリケーションのトランザクション時間と可用性を監視してください。一部のユーザーからの非公式のフィードバックや、ヘルプデスクへ報告に来たユーザーの数を調べるだけでは、新しいポリシーの必要条件を判断したり、ポリシー実装の効果を評価したりすることはできません。実装前の監視から得た情報は、新しいポリシーを設計するのに必要なデータとなります。実装後の監視では、実装が成功したかどうかの判断や微調整を行うための重要なフィードバックを得ることができます。
