Cisco ACNS ソフトウェア デプロイメント コンフィギュレーション ガイド
ACNS ネットワークにおけるコンテン ツ要求ルーティングの設定
ACNS ネットワークにおけるコンテンツ要求ルーティングの設定
発行日;2012/02/04 | ドキュメントご利用ガイド | ダウンロード ; この章pdf | フィードバック

目次

ACNS ネットワークにおけるコンテンツ要求ルーティングの設定

WCCP 対応ルータによる代行受信の概要

エッジ代行受信と WCCP サービス グループ機能

WCCP の設定

前提条件

Content Engine の設定

ルータ上での WCCP のイネーブル化

Web キャッシング用の基本的な WCCP ルータ設定

クライアントと Content Engine が同一サブネット上にある場合の Web キャッシュ サービス設定

Web キャッシュ サービス用の Content Engine の設定:クライアントと Content Engine が同一サブネット上にある場合

Web キャッシュ サービス用のルータの設定:クライアントと Content Engine が同一サブネット上にある場合

設定例:クライアントと Content Engine が同一サブネット上にある場合の Web キャッシュ サービス

クライアントと Content Engine が異なるサブネット上にある場合の Web キャッシュ サービス設定

Web キャッシュ サービス用の Content Engine の設定:クライアントと Content Engine が異なるサブネット上にある場合

Web キャッシュ サービス用のルータの設定:クライアントと Content Engine が異なるサブネット上にある場合

設定例:クライアントと Content Engine が異なるサブネット上にある場合の Web キャッシュ サービス

プロキシを使用したコンテンツ ルーティングの概要

HTTP プロキシ キャッシング

HTTP 透過およびプロキシ ルーティング

FTP プロキシ キャッシング

簡易ハイブリッド ルーティングとカバレッジ ゾーンの概要

カバレッジ ゾーンとカバレッジ ゾーン ファイル

カバレッジ ゾーン ファイルの登録

カバレッジ ゾーンの選択

デフォルト カバレッジ ゾーンの選択

ユーザ定義のカバレッジ ゾーンの登録と適用

カバレッジ ゾーン ファイルの例

シナリオ 1:NAT(ネットワーク アドレス トランスレーション)ファイアウォールがない場合

シナリオ 2:NAT ファイアウォールの背後に Content Engine がある場合

シナリオ 3:NAT ファイアウォールの背後に複数の Content Engine がある場合

シナリオ 4:NAT ファイアウォールに複数の IP アドレスがある場合

Content Engine をルーティング Content Engine として設定

プロキシ自動設定ファイル サーバを使用したコンテンツ ルーティングの概要

PAC ファイル テンプレートの作成

PAC ファイルの例

PAC ファイル テンプレートの登録とカバレッジ ゾーン情報の割り当て

Content Engine を PAC ファイル サーバとして設定

ACNS ネットワークにおけるコンテンツ要求ルーティングの設定

Cisco ACNS 5.1 ソフトウェアでは、コンテンツの要求処理を次の 4 種類の方法でエンド ユーザにコンテンツを配信しています。次の項では、コンテンツ要求を処理する各方式を説明します。

「WCCP 対応ルータによる代行受信の概要」

「プロキシを使用したコンテンツ ルーティングの概要」

「簡易ハイブリッド ルーティングとカバレッジ ゾーンの概要」

「プロキシ自動設定ファイル サーバを使用したコンテンツ ルーティングの概要」


) この章で使用される CLI コマンドの構文と使用方法については、『Cisco ACNS Software Command Reference, Release 5.1』を参照してください。


WCCP 対応ルータによる代行受信の概要

この WCCP 透過代行受信方式(transparent interception method)では、オリジン サーバへのコンテンツの要求は WCCP 対応ルータによって代行受信されます。WCCP 対応ルータは、要求されたコンテンツを保存している Content Engine に、その要求を透過的にリダイレクトします。このタイプの透過リダイレクトでは、ルータを通過するトラフィックの任意のポート番号のポートでトラフィックは代行受信されます。WCCP に組み込まれているフェイルセイフ機能により、要求の代行受信はエンド ユーザには透過的に行われます。

WCCP で透過的に行われる代行受信方式では、コンテンツはエンド ユーザに次のように配信されます。

1. ユーザがブラウザから Web ページを要求します。

2. WCCP 対応ルータがその要求を代行受信し、TCP 宛先ポート番号に基づいてその要求を Content Engine に透過的にリダイレクトするかどうかを決定します。どの要求をリダイレクトするかを制御するために、アクセス リストが使用されます。

3. 要求されたコンテンツが Content Engine に保存されていない場合、Content Engine はエンド サーバとの別の TCP 接続をセットアップしてコンテンツを取得します(図 4-1 の 3a)。コンテンツは Content Engine に戻され、保存されます(図 4-1 の 3b)。

4. Content Engine がクライアントにコンテンツを送信します。それ以降に同じコンテンツに対する要求があると、Content Engine はローカル ストレージから透過的にその要求を処理します。

図 4-1 WCCP を使用したエッジ代行受信

 

WCCP はまた非対称パケット フローも処理でき、WCCP サービス グループで使用されているルータ数に関係なく(ルータのクラスタ内で最大 32 の Content Engine と通信しているルータは 32 台まで)、Web サーバと Content Engine との一貫性のあるマッピングを常に保持しています。

WCCP 対応ルータを透過モードでの要求ルーティング代行受信の要求に対して使用すると、次のような利点があります。

エンド ユーザによる設定を必要としない:ユーザはブラウザに Content Engine を指定する必要はありません。

フェイルセーフ:Content Engine は、自動的に耐障害性とフェイルセーフを備えます。キャッシュの障害により、エンド ユーザに対してサービスが拒否されることはありません。

スケーラブル:複数の Content Engine を配置することによって、キャッシュ サービスを拡張できます。

自動バイパス:エンド ユーザの認証が必要なサイト、または標準の HTTP で書かれていないサイトは、自動的に透過キャッシュをバイパスします。

エッジ代行受信と WCCP サービス グループ機能

1 台の Content Engine で最高 8 つのユーザ設定可能な、または動的な WCCP リダイレクト サービス(90 ~ 97)を処理するように Content Engine を設定できます。ただし、これらのサービスがルータ上でも設定されている必要があります。

wccp service-number グローバル設定コマンドは、Content Engine 上でこれらのサービスを使用可能にすることができます。各 wccp service-number コマンドは、ルータ リスト、1 つのポート リスト(最高 8 つのポートを含む)、アプリケーション タイプ(キャッシュまたはストリーミング)、負荷分散用のハッシュ パラメータまたはマスク割り当てパラメータ、パスワード、および重みを指定します。

表 4-1 では、WCCP 対応ルータでサポートされるサービス グループ機能を示しています。

 

表 4-1 WCCP サービス グループ

サービス グループ番号
サービスの説明

0

Web キャッシュ

50

ブーメラン

80

HTTP、RTSP

81

MMST

82

MMSU

90 ~ 97

ユーザが設定可能

98

カスタム

99

リバース プロキシ


表 4-1 に示されているすべてのサービス グループ番号に WCCP Version 2 が必要です。ただし、Web キャッシュ サービス(サービス グループ 0)を除きます。


8 つの動的サービスでそれぞれ最大数の 8 つのポートを使用する場合、透過リダイレクトに指定できる最大ポート数は 64 です。図 4-2 では、左側の 2 つの Content Engine は、ポート 80 を通る HTTP トラフィックだけを処理し、サービス グループ 90 のメンバーとして定義されます。右側の 2 つの Content Engine は、Microsoft Media Server(MMS)要求だけを処理し、サービス グループ 91 のメンバーとして定義されています。

図 4-2 WCCP サービス グループの機能

 

HTTP を受信するすべてのポートは同じ WCCP サービスのメンバーとして設定され、次の特性を共有します。

wccp service-number コマンドを使用して設定されているので、同じ負荷分散パラメータ(ハッシュまたはマスク)をもっています。

個々のポート上のサービスは、個別に停止または開始できません(WCCP Version 2 の制約事項)。

ファーム内の Content Engine では、次の制約事項が適用されます。

同じ WCCP サービスを使用するすべての Content Engine には、同じポートのリストおよび同じ負荷分散パラメータを設定する必要があります。

同じ WCCP サービスを使用するファームに加わろうとする Content Engine が、異なるポート リストまたは異なる負荷分散パラメータを使用している場合、その Content Engine はルータによって拒否されます。

特定の WCCP サービス用のポート リストを変更するには、関係しているすべての Content Engine 上で WCCP サービスを停止し、新しいパラメータを指定して再開する必要があります。

Content Engine の WCCP実装では、現在、すべての WCCP サービスに適用されるグローバル設定(たとえば、ヒーリング パラメータ、スロー スタート)が可能です。この複数サービス モデルによりその設定は変更されず、該当する設定値は WCCP システム全体でグローバルのままです。

WCCP の設定

Content Engine で WCCP 対応ルータを使用したエッジ代行受信を設定する際に、次の設定ガイドラインを使用してください。

前提条件

WCCP 対応ルータを使用するには、インターネットに接続されたルータのインターフェイス上で IP アドレスを設定します。このインターフェイスは、ネットワーク上の Content Engine から見えなければなりません。

Content Engine の設定

WCCP を使用するには、Content Engine を適切に設定する必要があります。次の重要事項に注意してください。

Content Engine 上のソフトウェアのバージョンは、ルータ上にインストールされているバージョンと互換性がなければなりません。

Content Engine では、パケットを暗号化も圧縮もしてはなりません。「内部」に NAT(Network Address Translation)ファイアウォールが存在する場合、Content Engine はそのファイアウォールに含まれていなければなりません。

Web キャッシュ リダイレクト対応のインターフェイスを超えて、サーバへのルート上に Content Engine を配置すると、IP ルート キャッシュにエントリが読み込まれません。


) ACNS 5.x ソフトウェアでは、現在、WCCP Version 2 の使用をお勧めしています。ただし、WCCP Version 1 も引き続きサポートされています。


ルータ上での WCCP のイネーブル化

インターフェイスが WCCP Version 2 を使用して Web トラフィックを Content Engine にリダイレクトできるようにするには、ルータ上でグローバル設定モードから次のタスクを実行してください。

 

コマンド
目的

ステップ 1

ip wccp enable

ルータが WCCP を使用できるようにします。

ステップ 2

ip wccp redirect-list [ number | name ]

(オプション)。リダイレクト アクセス リストを指定します。このアクセス リストと一致するパケットだけが転送されます。このコマンドを設定しない場合、すべてのパケットがリダイレクトされます。

ステップ 3

interface type number

インターフェイス設定モードに入ります。

ステップ 4

ip web-cache redirect

Web トラフィックを Content Engine にリダイレクトするように、インターネットに接続されているインターフェイスを設定します。

ステップ 5

ip route-cache same-interface

(オプション)。クライアントと Content Engine が同じネットワーク上にある場合、インターフェイス上で高速スイッチング パスを使用するようにルータを設定します。

ステップ 6

end

設定モードを終了します。

ステップ 7

copy running-config startup-config

設定を保存します。

Web キャッシング用の基本的な WCCP ルータ設定

ルータと Content Engine 上で WCCP のサポートを使用可能にすると、これらのデバイスは情報を交換し、設定されているサービスを配信します。これらのサービスを一時停止するには、個々の Content Engine の電源をオフにしたり、その他の方法で Content Engine を使用不可にするのではなく、ルータ上で WCCP のサポートを使用不可にできます(たとえば、ルータ上で WCCP のサポートを使用不可にするには、 no ip wccp ルータ コマンドを使用します)。

また、多くの WCCP Version 2 サービスには、適切な wccp グローバル設定コマンドの設定も必要です。詳細は、『Cisco ACNS Software Command Reference, Release 5.x』、および ACNS ソフトウェアのリリース ノートを参照してください。

クライアントと Content Engine が同一サブネット上にある場合の Web キャッシュ サービス設定

この場合、Content Engine と要求側クライアントが同一サブネット上にあります(図 4-3 を参照)。

WCCP Version 2 を実行するルータは、ルータ インターフェイス s0/0 宛てのクライアント HTTP トラフィックを Content Engine に透過的にリダイレクトします。Web キャッシュ サービスは、ポート 80 上だけで HTTP トラフィックをリダイレクトします。

図 4-3 クライアントと Content Engine が同一サブネット上にある場合の Web キャッシュ サービス

 

Web キャッシュ サービス用の Content Engine の設定:クライアントと Content Engine が同一サブネット上にある場合

Content Engine を Web キャッシュ サービス用に設定するには、ACNS ソフトウェアにログイン中に、グローバル設定モードで次の手順を実行してください。

 

コマンド
目的

ステップ 1

ContentEngine(config)# wccp version 2

Content Engine が WCCP Version 2 を実行していることを確認します。

ステップ 2

ContentEngine(config)# wccp router-list 1 10.10.10.1

ルータ リストを設定します。

ステップ 3

ContentEngine(config)# wccp web-cache router-list-num 1

Content Engine が Web キャッシュ サービスを受け入れることを、指定されたルータ リスト内のルータに知らせます。

ステップ 4

ContentEngine(config)# exit

グローバル設定モードを終了します。

ステップ 5

ContentEngine# copy running-config startup-config

実行中の設定を不揮発性メモリに書き込みます。

Web キャッシュ サービス用のルータの設定:クライアントと Content Engine が同一サブネット上にある場合

ルータを Web キャッシュ サービス用に設定するには、ルータにログイン中に、グローバル設定モードで次の手順を実行してください。

 

コマンド
目的

ステップ 1

Router(config)# ip wccp web-cache

Web キャッシュ サービスを実行するようにルータに指示します。

ステップ 2

Router(config)# interface Ethernet0

設定するルータ インターフェイスを指定します。この場合、Ethernet0 が Content Engine とクライアントが接続されるルータインターフェイスです。

ステップ 3

Router(config-if)# ip route-cache same-interface

リダイレクトされるパケットが受信されたときのインターフェイスを使用して、これらのパケットの高速スイッチングを可能にします。このコマンドを使用しない場合、ルータは高速スイッチング キャッシュを使用しません。パケットはプロセス交換され、速度はかなり遅くなります。

ステップ 4

Router(config)# interface Serial0

設定するルータ インターフェイスを指定します。この場合、Serial0 がインターネットとのルータ インターフェイスです。

ステップ 5

Router(config-if)# ip wccp web-cache redirect out

指定されたインターフェイス宛ての Web キャッシュ トラフィックを、Web キャッシュ サービスを受け入れる Content Engine にリダイレクトするようにルータに指示します。この場合、ルータは 1 つです。Web キャッシュ トラフィックは、TCP ポート 80 トラフィックとして定義されます。

ステップ 6

Router(config-if)# exit

インターフェイス設定モードを終了します。

設定例:クライアントと Content Engine が同一サブネット上にある場合の Web キャッシュ サービス

次の例では、図 4-3 で示されているトポロジーを使用して、Content Engine とルータを Web キャッシュ サービス用に設定しています。

Content Engine

hostname Content_engine_4.2
!
clock timezone pst -8 0
!
ip domain-name cu.net
!
interface FastEthernet 0
ip address 10.10.20.10 255.255.255.0
no autosense
bandwidth 100
full-duplex
exit
interface FastEthernet 1
shutdown
exit
!
ip default-gateway 10.10.20.1
!
ip name-server 10.10.10.100
!
!
!
wccp router-list 1 10.10.20.1
wccp web-cache router-list-num 1
wccp version 2
!
!
!
. . .

WCCP 対応ルータ

Building configuration...
 
Current configuration:
!
version 12.0
!
hostname WCCP-Router
!
!
ip wccp web-cache
!
interface Ethernet0
ip address 10.10.10.1 255.255.255.0
ip route-cache same-interface
!
interface Serial0
ip address 192.168.1.2 255.255.255.252
no ip directed-broadcast
no ip mroute-cache
ip wccp web-cache redirect out
!
end

クライアントと Content Engine が異なるサブネット上にある場合の Web キャッシュ サービス設定

この場合、Content Engine と要求側クライアントが異なるサブネット上に配置されています(図 4-4 を参照)。

WCCP Version 2 を実行するルータは、ルータ インターフェイス s0/0 宛てのクライアント HTTP トラフィックを Content Engine に透過的にリダイレクトします。Web キャッシュ サービスは、ポート 80 上だけで HTTP トラフィックをリダイレクトします。

図 4-4 Content Engine とクライアントが異なるサブネット上にある場合の Web キャッシュ サービス

 

Web キャッシュ サービス用の Content Engine の設定:クライアントと Content Engine が異なるサブネット上にある場合

Content Engine を Web キャッシュ サービス用に設定するには、ACNS ソフトウェアにログイン中に、グローバル設定モードで次の手順を実行してください。

 

コマンド
目的

ステップ 1

ContentEngine(config)# wccp version 2

Content Engine が WCCP Version 2 を実行していることを確認します。

ステップ 2

ContentEngine(config)# wccp router-list 1 10.10.20.1

ルータ リストを設定します。

ステップ 3

ContentEngine(config)# wccp web-cache router-list-num 1

Content Engine が Web キャッシュ サービスを受け入れることを、指定されたルータ リスト内のルータに知らせます。

ステップ 4

ContentEngine(config)# exit

グローバル設定モードを終了します。

ステップ 5

ContentEngine# copy running-config startup-config

実行中の設定を不揮発性メモリに書き込みます。

Web キャッシュ サービス用のルータの設定:クライアントと Content Engine が異なるサブネット上にある場合

ルータを Web キャッシュ サービス用に設定するには、ルータにログイン中に、グローバル設定モードで次の手順を実行してください。

 

コマンド
目的

ステップ 1

Router(config)# ip wccp web-cache

Web キャッシュ サービスを実行するようにルータに指示します。

ステップ 2

Router(config)# interface Serial0

設定するルータ インターフェイスを指定します。この場合、Serial0 がインターネットとのルータ インターフェイスです。

ステップ 3

Router(config-if)# ip wccp web-cache redirect out

指定されたインターフェイス宛ての Web キャッシュ トラフィックを、Web キャッシュ サービスを受け入れる Content Engine にリダイレクトするようにルータに指示します。この場合、ルータは 1 つです。Web キャッシュ トラフィックは、ポート 80 上の HTTP パケットとして定義されます。

ステップ 4

Router(config-if)# exit

インターフェイス設定モードを終了します。

設定例:クライアントと Content Engine が異なるサブネット上にある場合の Web キャッシュ サービス

次の例では、図 4-4 で示されているトポロジーを使用して、Content Engine とルータを Web キャッシュ サービス用に設定しています。

Content Engine の設定

. . .
hostname Content_engine_4.2
!
clock timezone pst -8 0
!
ip domain-name cisco.com
!
exec-timeout 20
!
interface FastEthernet 0
ip address 10.10.20.10 255.255.255.0
no autosense
bandwidth 100
full-duplex
exit
interface FastEthernet 1
shutdown
exit
!
ip default-gateway 10.10.20.1
!
ip name-server 10.10.10.100
!
!
wccp router-list 1 10.10.20.1
wccp web-cache router-list-num 1
wccp version 2
!
!
!
...

WCCP 対応ルータの設定

Building configuration...
 
Current configuration:
!
hostname WCCP-Router
!
!
ip subnet-zero
!
ip wccp web-cache
!
interface Ethernet0
ip address 10.10.10.1 255.255.255.0
!
interface Ethernet1
ip address 10.10.20.1 255.255.255.0
!
interface Serial0
ip address 192.168.1.2 255.255.255.252
no ip directed-broadcast
no ip mroute-cache
ip wccp web-cache redirect out
!
end

プロキシを使用したコンテンツ ルーティングの概要

プロキシ設定では、エンド ユーザのブラウザに Content Engine の IP アドレスを設定する必要があります。したがって、プロキシ スタイルの要求は、クライアントが Content Engine へのルーティングを指定した後で、Content Engine に着信します。

プロキシ モードでは、Content Engine は設定されている任意のプロトコルを処理します。サポートされているプロトコルは、HTTP、HTTPS(Hypertext Protocol Secure)、FTP(File Transfer Protocol)、MMS(Microsoft Media Services)、および RTSP(Real-Time Transport Protocol)です。Content Engine で受信したプロトコルのサポートが設定されていない場合、プロキシ サーバはエラーを戻します。たとえば、ポート 8080 が HTTP および HTTPS のプロキシ サービスを実行するように設定されている場合、FTP 要求がこのポートに着信するとその要求は拒否されます。


) コンテンツ ルーティングにプロキシ モードが使用されている場合、Windows Media Player(WMP)Version 6.4 は使用できません。これは、MMS プロキシを設定するオプションがないからです。


Content Engine は、FTP、HTTPS、HTTP、MMS、および RTSP のプロキシ モードに対して、それぞれ最高 8 つの着信ポートをサポートします。着信プロキシ ポートは、透過モード サービスが使用するポートと同じポートにすることができます。Content Engine またはファーム内の他の Content Engine 上で実行されている WCCP サービスを停止しなくても、着信プロキシ ポートを変更できます。

システム サービスまたはネットワーク サービス用に予約されている TCP ポートは、エッジ代行受信モードまたはプロキシ モードでサービスの代理処理(たとえば、DNS または FTP)には使用しないでください。1 つのプロトコルに 9 つ以上のポートが必要な場合、管理者は複数の動的 WCCP サービスを設定できます。他のプロキシ サーバのアドレスが指定された FTP、HTTP、および HTTPS の要求(透過モード ポート上で受信)が代行受信されると、その要求は proxy-protocols transparent コマンド パラメータに従って処理されます。

HTTP プロキシ キャッシング

着信プロキシ ポートを http proxy incoming ports オプションを使用して設定する場合、Content Engine は Web ブラウザから非透過モードでプロキシ スタイルの要求を受け入れます。着信プロキシ ポートは、コマンド ラインの 1 行または複数行で最高 8 つまで指定できます。

ICP または WCCP を使用せずにすべての HTTP キャッシュ ミス トラフィックを親キャッシュに転送するように Content Engine を設定するには、 http proxy outgoing host ip-address port primary オプションを使用します。ここで、 host は、発信プロキシ サーバのシステム名または IP アドレスです。 port は、プロキシ要求を受け入れるために発信(アップストリーム)サーバが指定するポート番号です。 primary オプションを使用して、このホストをプライマリ プロキシとして設定してください。

HTTP 透過およびプロキシ ルーティング

本社にプロキシ モードの Content Engine を配置し、支社のリモート ロケーションに透過モードの Content Engine を配置している場合があります。このような場合、リモート Content Engine でキャッシュ ミスが起きると、その要求を本社の Content Engine に転送するよう要求している場合があります。

proxy-protocols transparent original-proxy コマンドが入力されている場合、プロキシ サーバの役目をする Content Engine 宛ての HTTP 要求が、リモート ロケーションにある透過モードの Content Engine によって代行受信されるときに、キャッシュ ミスが起きると、Content Engine はその要求を目的のプロキシ サーバに転送します。このコマンドが入力されていなかった場合、Content Engine は、最初に HTTP 要求が行われたオリジン サーバにその要求を転送します。

FTP プロキシ キャッシング

Content Engine における FTP プロキシ キャッシングとは、FTP-over-HTTP 要求を処理する機能を指します。Web ブラウザとキャッシュ間のトランスポートは HTTP を介して行われ、キャッシュはオリジン FTP サーバへの FTP 転送を開始します。


) Content Engine が FTP トラフィックをキャッシュに保存するのは、クライアントが FTP 要求のプロキシ サーバとして Content Engine を使用する場合だけです。Web クライアントから FTP サーバに直接送信された FTP トラフィックが透過的に Content Engine によって代行受信された場合、そのトラフィックはすべて非 HTTP トラフィックとして扱われます。プロキシを使用するように Web ブラウザが明示的に設定されていない場合、このブラウザはエンドツーエンド FTP 接続を独自で開始するため、Content Engine はこの要求を代行受信することはできません。


ftp proxy コマンドを使用すると、WCCP が使用可能になっていない環境、または既存の FTP プロキシ サーバを使用するようにクライアント ブラウザがあらかじめ設定されている環境で、Content Engine が動作できます。

ftp proxy incoming port オプションは、プロキシ サーバが要求の受信に使用するポート番号を指定します。この番号は、1 ~ 65535 にすることができます。最大 8 つの着信プロキシ ポートを設定できます。これらの着信プロキシ ポートを透過モード サービスと共有したり、Content Engine がサポートしているその他のプロキシ モード プロトコル(たとえば、HTTP や HTTPS)とも共有することができます。 ftp proxy incoming port オプションは、デフォルトで使用不可になっています。


) Content Engine は、FTP プロキシとして機能するように設定されているポート上でのみ FTP 要求を受け入れ、処理します。他のプロキシ モードのポート上にある FTP 要求はすべて、Content Engine 上のエラー処理設定に従って拒否されます。


URL が FTP プロトコルを指定する場合(たとえば、GET ftp://ftp.cisco.com/pub/cao/READM) 、Content Engine は FTP 要求を受け入れます。これらの要求では、クライアントは、Content Engine とのトランスポート プロトコルとして HTTP を使用します。一方、Content Engine は、FTP サーバとのトランスポート プロトコルとして FTP を使用します。

Content Engine は、FTP ファイル オブジェクトとディレクトリ リストの両方をキャッシュ ファイル システム(cfs)にキャッシングします。Content Engine は、ファイルをダウンロードするためにクライアント ユーザがポイントしてクリックするリンクを付けて、FTP サーバからの通常のディレクトリ リストを HTML に変換します。

Content Engine が Web クライアントから FTP 要求を受信すると、まず、キャッシュを調べます。オブジェクトがキャッシュ内にない場合、アップストリーム FTP プロキシ サーバ(設定されている場合)から、またはオリジン FTP サーバから直接、オブジェクトをフェッチします。

FTP プロキシは、認証されている FTP 要求だけでなく、匿名 FTP 要求もサポートします。認証には base64 エンコーディングだけがサポートされます。FTP プロキシは、RFC 1738 で定義されているすべての FTP URL 方式を受け入れます。 ftp://user@site/dir/file 形式の URL の場合、プロキシは認証の失敗応答を戻し、ブラウザはユーザがログイン情報を入力するポップアップ ウィンドウを表示します。

Content Engine は、サーバ名、ドメイン名、サーバの IP アドレスとポート、クライアントの IP アドレス、および URL に基づいて、FTP 要求に Rules Template を適用できます。

Content Engine は、Squid 構文に従って、FTP トランザクションをトランザクション ログに記録します。

次の例では、ポート 8080、8081、および 9090 上で着信 FTP プロキシを設定します。同じコマンド ラインで、最高 8 つの着信プロキシ ポートを設定できます。

ContentEngine(config)# ftp proxy incoming 8080 8081 9090
 

次の例では、前例で入力されたリストから、1 つの FTP プロキシ ポートを削除します。ポート 8080 および 9090 は、引き続き FTP プロキシ ポートのままです。

ContentEngine(config)# no ftp proxy incoming 8081
 

次の例では、すべての FTP プロキシ ポートを使用不可にします。

ContentEngine(config)# no ftp proxy incoming
 

次の例では、ポート 8888 上で IP アドレス 172.31.76.76 のアップストリーム FTP プロキシを設定します。

ContentEngine(config)# ftp proxy outgoing host 172.31.76.76 8888
 

次の例では、FTP サーバと交信するときに Content Engine が使用する匿名パスワード ストリングを指定します。デフォルトのパスワード ストリングは anonymous@hostname です。

ContentEngine(config)# ftp proxy anonymous-pswd newstring@hostname
 

次の例では、Content Engine がキャッシュに保存する FTP オブジェクトの最大サイズ(キロバイト数)を設定します。デフォルトでは、キャッシュに保存することができるオブジェクトの最大サイズには限界がありません。

ContentEngine(config)# ftp object max-size 15000
 

次の例では、FTP 要求ごとのオブジェクトをすべて Content Engine で再検証します。

ContentEngine(config)# ftp reval-each-request all
 

次の例では、ディレクトリ リスト オブジェクトとファイル オブジェクトに対して、キャッシュの最大存続可能時間(Time To Live)を 3 日に設定します。

ContentEngine(config)# ftp max-ttl days directory-listing 3 file 3
 

簡易ハイブリッド ルーティングとカバレッジ ゾーンの概要

簡易ハイブリッド ルーティング(SHR)は、Content Router を経由する HTTP または RSTP リダイレクトを使用します。Content Router は、要求されたコンテンツ、クライアントの IP アドレス、および Content Engine の活動状況に基づいて、目的のコンテンツをクライアントに配信するのに最も適した Content Engine を判別します。Content Router は、クライアントのエンドシステムのソース IP アドレスを、Content Engine に割り当てられているアドレス範囲のテーブル(カバレッジ ゾーンと呼ばれます)と比較します。次に Content Router は、選択された Content Engine を指し示すリダイレクト応答をクライアントに送信します。

簡易ハイブリッド ルーティングは次のように動作します。

1. クライアントからローカル DNS プロキシ サーバに対して、コンテンツの IP アドレスを要求する DNS(ドメイン ネーム システム)クエリーが送信されます。

2. ローカル DNS プロキシが、その DNS クエリーをネームサーバに送信し、IP アドレスに対するドメイン名を解決します。

3. 解決プロセスが、最終的に Content Router で終わります。Content Router の IP アドレスが DNS プロキシ サーバに戻されます。

4. DNS プロキシ サーバが、Content Router の IP アドレスをクライアントに戻します。

5. クライアントが、目的のコンテンツの要求を Content Router に送信します。

6. Content Router が、Content Engine に最も近い DNS ドメイン名を示すリダイレクト応答を戻します。

7. クライアントが、コンテンツの要求を最適な Content Router に送信します。

8. 最適な Content Engine が、クライアントにコンテンツを送信します。

簡易ハイブリッド ルーティングを正常に機能させるには、次の情報を設定する必要があります。

カバレッジ ゾーン

Content Router は、カバレッジ ゾーンに基づいて、クライアントのエンドシステムに最も近い Content Engine を選択します(次の項の「カバレッジ ゾーンとカバレッジ ゾーン ファイル」を参照)。

Web サイトの登録

Content Engine が提供できるコンテンツは、その Content Engine が登録されている Web サイトのコンテンツだけです。Content Engine は、チャネルを経由して Web サイトに登録されます(「Content Engine の追加とチャネルからの削除」を参照)。

DNS サーバ

すべての完全修飾ドメイン名(FQDN)の DNS エントリは、Content Router が代行する必要があります。DNS サーバのゾーン データベース ファイル(db)では、Content Router に FQDN を代行させるネームサーバNS)レコードを入力し、その後 DNS サーバを再起動する必要があります。

次の例では、FQDN www.cisco.com が、bali-cr という名前の Content Router に代行されました。

www.cisco.com IN NS bali-cr

DNS サーバで NS レコードを設定した場合、FQDN およびその任意のサブドメインに対する要求はすべて、既存の DNS サーバではなく、Content Router に送信されます。Content Router は、FQDN に対する DNS クエリーを自動的に解決します。

カバレッジ ゾーンとカバレッジ ゾーン ファイル

カバレッジ ゾーンは、エンドシステムの IP アドレスを Content Engine へマッピングしたものです。Content Router は、Content Engine の IP アドレスを使用して、エンドシステムの IP アドレスを Content Engine にマップする静的リダイレクト テーブルを作成し、エンドシステムと Content Engine との近接性についての情報を提供します。エンド ユーザがコンテンツを要求すると、Content Router はエンド ユーザの IP アドレスを調べて、その IP アドレスが入っているカバレッジ ゾーンを検出します。次に Content Router は、このカバレッジ ゾーンを処理する Content Engine を選択します。特定の IP アドレスが複数のカバレッジ ゾーン内にある場合、より範囲が限定されているカバレッジ ゾーンが選択されます。たとえば、IP アドレス 172.1.1.1 は、カバレッジ ゾーン 172.0.0.0/8 ではなく、172.1.0.0/16 のデータを使用します。カバレッジ ゾーン データで一致が見付からない場合、要求は転送されず、したがってコンテンツは使用できません。

1 つのカバレッジ ゾーンを、1 つまたは複数の Content Engine に関連付けることができます。各 Content Engine が固有のカバレッジ ゾーンをもつか、Content Engine を複数のカバレッジ ゾーンに関連付け、カバレッジ ゾーンをオーバーラップさせることができます。ACNS 5.x ソフトウェアでは、カバレッジ ゾーンは Content Distribution Manager に割り当てられません。

1 つのカバレッジ ゾーンが複数の Content Engine によって処理される場合、最低のメトリック値をもつ Content Engine が、ルーティング テーブルに保存します。メトリック値( 表 4-2 を参照)は、Content Engine とエンド ユーザとの近接性を示します。1 つのカバレッジ ゾーンにある複数の Content Engine が同じサブネット上にあり、同じメトリック値をもつ場合、Content Router はラウンドロビン方式でクライアントへのリダイレクトを実行します。

Content Engine が Content Distribution Manager に登録されると、その Content Engine に割り当てられる IP アドレスとサブネット マスクによって決定されるデフォルトのカバレッジ ゾーンが割り当てられます。ネットワーク管理者は、カバレッジ ゾーン ファイルでカバレッジ ゾーンを定義することによって、独自のカスタム カバレッジ ゾーンを作成することもできます。

カバレッジ ゾーン ファイルは、ユーザ定義のカバレッジ ゾーンの指定に使用される XML ファイルです。ファイル内の各カバレッジ ゾーン エントリは、IP アドレスの範囲、このサブネットを処理する Content Engine の名前、メトリック値、および 1 つまたは複数のオプションのエージェント フィールド(このエントリが特定のルーティング Content Engine 用に指定されている場合)を指定します。カバレッジ ゾーンの情報に加えて、文書化のために 2 つのオプション要素が作成されます。カバレッジ ゾーン ファイルのバージョンを指定する改訂値と、カスタマー名です。

カバレッジ ゾーン ファイルは、任意の ASCII テキスト編集ツールを使用して作成できます。1 つのテキスト形式のカバレッジ ゾーン ファイルを使用して、ACNS ネットワークのすべてのカバレッジ ゾーンを定義できます。

表 4-2 では、カバレッジ ゾーン ファイルの要素を定義します。

 

表 4-2 カバレッジ ゾーン ファイルの要素

要素
説明

ネットワーク

IP アドレス

カバレッジ ゾーンの IP アドレス範囲。

Content Engine

Content Engine 名

ネットワーク要素で指定されたカバレッジ ゾーンを処理する Content Engine を指定します。これには、1 つまたは複数の要素を指定できます。

メトリック

整数

Content Engine のメトリック値を指定します。この値が小さいほど、Content Engine とエンド ユーザが近くなります。

エージェント

ルーティング Content Engine の名前

ルーティング Content Engine として機能する Content
Engine を指定するオプション フィールド。このフィールドが指定されない場合、カバレッジ ゾーン エントリは Content Router に指定されます。

カバレッジ ゾーン ファイルの登録

システム管理者は、Content Distribution Manager または個々のデバイスが URL にアクセスできる Web サーバにカバレッジ ゾーン ファイルを置きます。次に管理者は、Content Distribution Manager GUI にカバレッジ ゾーン ファイルの URL を登録します。カバレッジ ゾーン ファイルは、ACNS ネットワーク全体にグローバルに適用することも、ACNS ネットワーク内の特定の Content Router にローカルに適用することもできます。カバレッジ ゾーン ファイルをグローバルにすると、各 Content Router がそのファイルを読み取って、解析します。カバレッジ ゾーンがある特定の Content Router 設定に指定されている場合、その Content Router だけに適用されます。

カバレッジ ゾーンの選択

次の 2 つのタイプのカバレッジ ゾーンの使用を選択できます。

デフォルトのカバレッジ ゾーン

ユーザ定義のカバレッジ ゾーン

デフォルトのカバレッジ ゾーンは、同じローカル ネットワーク セグメントまたはサブネットに置かれているすべての Content Engine から構成されます。Content Distribution Manager GUI には、デフォルトのカバレッジ ゾーンを使用するかどうかを指定するチェックボックスがあります。

ユーザ定義のカバレッジ ゾーンは、カバレッジ ゾーン ファイルに指定されているすべての Content Engine から構成されます。このファイルは、ルーティング プロセスに含まれるネットワーク セグメントを定義します。このカバレッジ ゾーン ファイルは、Content Distribution Manager に登録され、その後 Content Router またはルーティング Content Engine のルーティングを定義します。


) デフォルトでは、カバレッジ ゾーンのメトリック値は 20 に設定されます。ユーザ定義のカバレッジ ゾーンを特定の Content Engine 用に優先設定する場合、カバレッジ ゾーン ファイル内のメトリック値は 19 以下の値に設定しなければなりません。デフォルトのカバレッジ ゾーンを優先設定される場合、カバレッジ ゾーン ファイル内のメトリック値は 21 以上の値に設定しなければなりません。


デフォルト カバレッジ ゾーンの選択

デフォルトのカバレッジ ゾーンを選択する手順は、次のとおりです。


ステップ 1 Content Distribution Manager GUI で、 Devices > Content Engines の順に選択します。

ステップ 2 変更したい Content Engine の名前の横にある Edit アイコンをクリックします。Modifying Content
Engine ウィンドウが表示されます。このウィンドウには、選択された Content Engine のプロパティを編集するためのフィールドが表示されます(図 4-5 を参照)。

図 4-5 Modifying Content Engine ウィンドウ

 

ステップ 3 Set Default Coverage Zone File チェックボックスにチェックマークを付けます。

ステップ 4 Submit をクリックします。


 

ユーザ定義のカバレッジ ゾーンの登録と適用

Content Router またはルーティング Content Engine にカスタム カバレッジ ゾーンを適用するには、まず、Content Distribution Manager GUI にカバレッジ ゾーン ファイル URL を登録する必要があります。カバレッジ ゾーン ファイル URL を Content Distribution Manager に登録した後、次の 2 通りの方法でカバレッジ ゾーン ファイルを適用できます。

グローバル:ACNS ネットワーク全体に配置されます。

ローカル:特定の Content Router またはルーティング Content Engine 上に配置されます。


) デバイスに対してローカルなカバレッジ ゾーンを適用すると、このカバレッジ ゾーン ファイルによって、そのデバイスの ACNS ネットワーク全体のカバレッジ ゾーン ファイルが変更されます。


カバレッジ ゾーン ファイルを登録する手順は、次のとおりです。


ステップ 1 Content Distribution Manager GUI から、 System > Routing の順に選択します。

ステップ 2 Contents ペインで、 Routing Management > Coverage Zone File Registration の順に選択します。Coverage Zone File Registration ウィンドウが表示されます。

ステップ 3 Create New Coverage Zone File アイコンをクリックします。Registering New Coverage Zone File ウィンドウが表示されます(図 4-6 を参照)。

図 4-6 Registering New Coverage Zone File ウィンドウ

 

ステップ 4 Coverage Zone File URL フィールドに、カバレッジ ゾーン ファイルにアクセスできるオリジン URL のフルパス(カバレッジ ゾーンのファイル名を含む)を入力します。

ステップ 5 Destination File Name フィールドに、ファイル名を入力します。

ステップ 6 Update Interval(minutes)フィールドに、存続可能時間(Time To Live)を入力します。デフォルト値は 10 分です。

ステップ 7 Submit をクリックして、入力した設定値を保存します。


 

カバレッジ ゾーン ファイル URL を Content Distribution Manager に登録した後、グローバル ルーティング設定としてこのファイルを使用できます。グローバル カバレッジ ゾーン ファイルを設定する手順は、次のとおりです。


ステップ 1 Content Distribution Manager GUI から、 System > Routing の順に選択します。

ステップ 2 Contents ペインから、 Routing Management > Global Routing Config の順に選択します。Set Global Coverage Zone File ウィンドウが表示されます(図 4-7 を参照)。

図 4-7 Set Global Coverage Zone File ウィンドウ

 

ステップ 3 Coverage Zone File のドロップダウン リストから、カバレッジ ゾーン ファイル(作成されている場合)を選択します。

ステップ 4 Keep Alive Port フィールドに、ルーティング要求を受信するために ACNS ネットワーク全体で使用するポート番号を入力します。

ステップ 5 Submit をクリックします。


 

ローカルで使用するカバレッジ ゾーン ファイルを個々の Contetn Router に適用する手順は、次のとおりです。


ステップ 1 Content Distribution Manager GUI から、 Devices > Content Routers の順に選択します。

ステップ 2 カバレッジ ゾーン ファイルを割り当てる Content Router の名前の横にある Edit アイコンをクリックします。Modifying Content Router ウィンドウが表示されます。

ステップ 3 Coverage Zone File のドロップダウン リストからカバレッジ ゾーン ファイルを選択します。

ステップ 4 Submit をクリックして、そのカバレッジ ゾーン ファイルを Content Router に適用します。


 

カバレッジ ゾーン ファイルの例

次の項では、異なる 4 つのシナリオを例にして、種々のカバレッジ ゾーン ファイルの使用例を示します。

シナリオ 1:NAT(ネットワーク アドレス トランスレーション)ファイアウォールがない場合

これは最も単純なシナリオです。この例では、企業 ent1.com は、別々のサブネット内に 2 つの Content Engine があるパブリック アドレス スペース内にあり、各 Content Engine は互いにバックアップをとります。両方の Content Engine は、デフォルトのカバレッジ ゾーンを使用します。これにより、カバレッジ ゾーン ファイルのエントリ 3 とエントリ 4(例を参照)が作成され Content Router によって追加されます。

カバレッジ ゾーン ファイル内でバックアップ Content Engine を定義するには、サブネットをバックアップ Content Engine にマップし、21 以上のメトリック値を指定します(エントリ 1 とエントリ 2)。

図 4-8 カバレッジ ゾーンのシナリオ 1:NAT がない場合

 

次のファイルは、シナリオ 1 のカバレッジ ゾーン ファイルの例です(図 4-8 を参照)。

<?xml version="1.0" ?>
<ACNNetwork>
<revision>1.0</revision>
<customerName>ent.com</customerName>
<!-- entry 1 >
<coverageZone>
<network>172.29.248.0/24</network>
<CE>ent_sanfrancisco</CE>
<metric>20</metric>
</coverageZone>
 
<!-- entry 2:backup CE for the San Francisco office >
<coverageZone>
<network >172.29.249.0/24</network>
<CE>ent_sanjose</CE>
<metric>20</metric>
</coverageZone>
 
<!-- entry 3 >
<coverageZone>
<network>172.29.248.0/24</network>
<CE>ent_sanjose</CE>
<metric>10</metric>
</coverageZone>
<!-- entry 4 >
<coverageZone>
<network>172.29.249.0/24</network>
<CE>ent_sanfrancisco</CE>
<metric>10</metric>
</coverageZone>
</ACNNetwork>
 

シナリオ 2:NAT ファイアウォールの背後に Content Engine がある場合

企業 ent2.com は、1 つの Content Engine を備えた NAT ファイアウォールの背後にあり、Content Router はパブリック インターネット上に配置されています。このパブリック IP アドレスからのすべてのコンテンツ要求はファイアウォールの背後にある Content Engine(ent2_sanfrancisco)によって処理されます。NAT の背後にあるエンドシステムからのすべてのコンテンツ要求は、同じパブリック IP アドレスをもっているため、カバレッジ ゾーン ファイルでは、1 つのエントリがこのパブリック IP アドレスを Content Engine ent2_sanfrancisco にマップします。Modifying Content Engine ウィンドウから General Configuration セクション(図 8-2 を参照)で、Set Default Coverage Zone File チェックボックスのチェックマークを外してください。これは、サブネット 10.1.1.0/24 がプライベート ネットワークであり、Content Router からそのサブネットが認識されないからです。

図 4-9 カバレッジ ゾーンのシナリオ 2:NAT ファイアウォールの背後にある場合

 

次のカバレッジ ゾーン ファイルは、図 4-9 と対応しています。

<?xml version="1.0" ?>
<!-- CZ for ent2.com >
 
<ACNNetwork>
<coverageZone>
<network>171.29.250.1/32</network>
<CE>ent2_sanfrancisco</CE>
<metric> 10 </metric>
</coverageZone>
</ACNNetwork>
 

シナリオ 3:NAT ファイアウォールの背後に複数の Content Engine がある場合

このシナリオでは、企業 ent3.com は複数のサブネットがある NAT ファイアウォールの背後にあり、各サブネットには 1 つの Content Engine があります。この場合、NAT ファイアウォール内には少なくとも 1 つのルーティング Content Engine が必要です。ルーティング Content Engine の役目をするように Content Engine を設定し直す方法については、「Content Engine のプロパティの変更」を参照してください。ルーティング Content Engine は、ルーティング プロセスにより、コンテンツ ルーティングを実行できます。Content Router は、ファイアウォールの背後からのコンテンツ要求をすべてルーティング Content Engine にリダイレクトし、その後このルーティング Content Engine が 2 回目のリダイレクトを実行します。

この例では、ent3_sanjose1 がルーティング Content Engine です。NAT ファイアウォールの背後からのコンテンツ要求をすべてent3_sanjose1 にマップするように、カバレッジ ゾーン エントリ(CZ entry 1)を定義する必要があります。また、ルーティング Content Engine である ent3_sanjose1 のカバレッジ ゾーン エントリを、10.1.1.0/24 からのすべての要求をそのルーティング Content Engine 自体にマップし(CZ entry 2)、10.1.2.0/24 からの要求を ent3_sanjose2 にマップするようにも(CZ entry 3)定義する必要があります。

図 4-10 シナリオ 3:NAT ファイアウォールの背後に複数の Content Engine がある場合

次のカバレッジ ゾーン ファイルは、図 4-10と対応しています。

<?xml version="1.0" ?>
<!-- CZ for ent3.com >
<ACNNetwork>
<customerName>ent3.com</customerName>
<!-- CZ entry 1 >
<coverageZone>
<network>171.29.1.1/32</network>
<CE>ent3_sanjose1</CE>
<metric> 10 </metric>
</coverageZone>
 
<!-- CZ for routing CE >
<!-- CZ entry 2 >
<coverageZone>
<network>10.1.1.0/24</network>
<CE>ent3_sanjose1</CE>
<metric> 10 </metric>
<agent> ent3_sanjose1</agent>
</coverageZone>
 
<!-- CZ entry 3 >
<coverageZone>
<network>10.1.2.0/24</network>
<CE>
ent3_sanjose2
</CE>
<metric> 10 </metric>
<agent>ent3_sanjose1</agent>
</coverageZone>
 

シナリオ 4:NAT ファイアウォールに複数の IP アドレスがある場合

企業 ent4.com は、複数のパブリック IP アドレスをもつ NAT ファイアウォールの背後にあります。NAT ファイアウォールの背後からのコンテンツ要求はすべて、これらのパブリック IP アドレスのいずれかになります。したがって、これらのパブリック IP アドレスごとに 1 つのカバレッジ ゾーン データ エントリが必要で、これらのパブリック IP アドレスは NAT ファイアウォールの背後にある Content Engine にマップされます。

図 4-11 シナリオ 4:NAT ファイアウォールに複数の IP アドレスがある場合

 

次のカバレッジ ゾーン ファイルは、図 4-11と対応しています。

<?xml version="1.0" ?>
<!-- CZ for ent4.com >
<ACNNetwork>
<coverageZone>
<network>171.29.10.1/32</network>
<CE>ent4_sanfrancisco</CE>
<metric>10</metric>
</coverageZone>
 
<!-- CZ for ent4.com >
<coverageZone>
<network>171.29.10.2/32</network>
<CE>ent4_sanfrancisco</CE>
<metric>10</metric>
</coverageZone>
</ACNNetwork>

Content Engine をルーティング Content Engine として設定

Content Engine 上でルーティング機能を使用可能にすると、この Content Engine がコンテンツ要求のリダイレクトも行うことができるようになります。ルーティング Content Engine が必要になるのは、同じ NAT ファイアウォールの背後にあるクライアントからのコンテンツ要求を処理できるように複数の Content Engine が NAT ファイアウォールの背後に置かれる場合です。この場合、まず Content Router はコンテンツの配信に最適な Content Engine ではなく、ルーティング Content Engine にコンテンツ要求をリダイレクトします。次にルーティング Content Engine は 2 回目のリダイレクトを実行して、コンテンツの処理に最適な Content Engine を特定します。ルーティング Content Engine の必要性を示す例については、「シナリオ 3:NAT ファイアウォールの背後に複数の Content Engine がある場合」を参照してください。

Content Engine をルーティング Content Engine 用に設定する方法については、「Content Engine のプロパティの変更」を参照してください。

プロキシ自動設定ファイル サーバを使用したコンテンツ ルーティングの概要

Cisco ACNS 5.1 ソフトウェアは、動的なプロキシ自動設定(PAC)をサポートしています。このルーティング方法は、Content Distribution Manager を使用して設定され(「PAC ファイル テンプレートの登録とカバレッジ ゾーン情報の割り当て」を参照)、PAC ファイル サーバとして使用可能になっている Content Engine が少なくとも 1 つ必要です(「Content Engine を PAC ファイル サーバとして設定」を参照)。PAC ファイル サーバは、PAC ファイル テンプレートの指示に基づいて、コンテンツを要求するクライアントに最も近いプロキシ Content Engine を動的に選択します(「PAC ファイル テンプレートの作成」を参照)。

動的な PAC ルーティング方法では、次の機能を使用できます。

複数の PAC ファイルをサポートしています。

ユーザは、事前設定された名前だけではなく、PAC ファイルの名前を指定できる。

PAC ファイル サーバは、カバレッジ ゾーン情報と要求側のソース IP アドレスに基づいて、1 組の「最も近いプロキシ」を PAC ファイル テンプレートに追加します。

Content Engine 自体が PAC ファイル テンプレートを獲得するのではなく、Content Distribution Manager が PAC ファイル テンプレートを獲得し、PAC ファイル サーバである Content Engine にそれらのテンプレートを配布します。


) この新しい機能は、ACNS 5.0 ソフトウェアでサポートされている proxy-auto-config コマンド機能の拡張ではなく、その機能に置き換わるものでもありません。どちらの機能も、ACNS 5.1 ソフトウェアでサポートされています。


PAC ファイル テンプレートの作成

システム管理者はワークステーション上で PAC ファイル テンプレートを作成し、Content Distribution Manager が URL にアクセスできる Web サーバにそのテンプレートを置きます。次に、管理者は Content Distribution Manager GUI で PAC ファイル テンプレート URL を登録し、それにカバレッジ ゾーン ファイルを割り当てます。

PAC ファイル サーバが動的情報を生成し、挿入する事前定義マクロを管理者が挿入する点を除いて、このテンプレートは完全な PAC ファイルです。最も近いプロキシは、カバレッジ ゾーン ファイルに含まれているメトリックによって判別されます。

Content Distribution Manager は、HTTP を使用してテンプレートを獲得し、すべての PAC ファイル サーバに配信します。PAC ファイル サーバである Content Engine ごとに、管理者は PAC ファイル要求に使用するポートも設定する必要があります。通常、ポート 80 が使用されます。

ポートを設定するには、CLI で http proxy incoming port コマンドを使用します(デフォルトはありません)。または、Content Distribution Manager を使用して、HTTP Connection Settings ウィンドウ(Devices > Content Engines > HTTP/S > HTTP Connections)で、着信プロキシ ポートを設定することもできます。

管理者は、目的のサーバを含めて、PAC ファイル URL をエンド ユーザに提示します。ユーザは、この URL を使用するようにブラウザを設定する必要があります。ブラウザが最初に起動するときに、その URL を要求します。PAC ファイル サーバは、任意の ACNS ソフトウェア マクロを、ローカル カバレッジ ゾーンからの現行の情報(存在する場合)、および要求側のソース IP アドレスに基づくデフォルトのカバレッジ ゾーンからの現行の情報で動的に置き換えます。完成した PAC ファイルは、要求側クライアントに戻されます。

エンド ユーザが NAT デバイスの背後に存在するときに、ネットワーク管理者がそのエンド ユーザを IP アドレスに基づいて別のプロキシに転送したい場合、これらのユーザが使用する PAC ファイル サーバもその NAT デバイスの背後に存在する必要があります。この理由は、NAT の背後にない PAC ファイル サーバは、エンド ユーザのソース IP アドレスではなく、NAT デバイスのソース IP アドレスをもつ、NAT の背後にいるユーザに対する PAC 要求を受け取るからです。

次の 3 つのマクロが定義されます。

CE_NAME_n

CE_IPADDR_n

NEAREST_PROXIES_n

ここで、 n は 1 ~ 5 の値です。

CE_NAME_n の場合、PAC ファイル サーバは n 番目に近いプロキシの名前を代入します。CE_IPADDR_n の場合、PAC ファイル サーバは n 番目に近いプロキシの IP アドレスを代入します。n 番目に近いプロキシがない場合、PAC ファイル サーバはマクロの代わりに空のストリング "" を使用します。PAC テンプレートの作成者は、PAC ファイル テンプレートの作成時にこの点に注意する必要があります。

NEAREST_PROXIES_n マクロの場合、PAC ファイル サーバは、最も近い n 個までのプロキシの代わりに、ストリング "PROXY <ip address>;" を使用します。ここで、<ip address> は、プロキシの IP アドレスです。テンプレートの作成者がマクロにポート番号を含める場合、このポート番号は各プロキシ IP アドレスの末尾に付加されます。

たとえば、NEAREST_PROXIES_2:8080 は、"PROXY 192.30.120.12:8080; PROXY 168.10.10.1:8080;" などのストリングになります。n が使用可能なプロキシ数より大きい場合、PAC ファイル サーバは n 個より少ないプロキシを代わりに使用します。たとえば、NEAREST_PROXIES_2 は、"PROXY 192.30.120.12;"、または最も近いプロキシがない場合は "" になることがあります。PAC テンプレートの作成者は、PAC ファイル テンプレートの作成時にこの点にも注意する必要があります。

PAC ファイルの例

CE1 はサブネット 10.1.1.0/24 を処理し、CE2 はサブネット 10.1.2.0/24 を処理することを前提とします。サブネット 10.1.1.0/24 上のクライアントはすべて、CE1 を最初のプロキシとして使用し、サブネット 10.1.2.0/24 上のクライアントはすべて、CE2 を最初のプロキシとして使用します。

PAC ファイル テンプレートは次のようになります。

Function FindProxyForURL(url, host)
{
// handle plain host names
if (isPlainHostName(host) {
return “DIRECT”;
 
// handle exception list
if (myIpAddress() == "10.1.1.2") {
return “DIRECT”;
}
 
// handle special domain list
if (shExpMatch(host, "specialdomain.com”)) {
return “PROXY specialDomainProxy.foo.com”;
}
 
// handle direct domain list
if (shExpMatch(host, "directdomain.com”)) {
return “DIRECT”;
}
 
// closest proxies + defaults
p1 = CE_NAME_1;
p2 = CE_NAME_2;
if (p1 != “”) {
p1 = “PROXY “ + p1 + “.proxy.foo.com:8080; ”;
}
if (p2 != “”) {
p2 = “PROXY “ + p2 + “.proxy.foo.com:8080; ”;
}
return p1 + p2 + “DIRECT”;
}
 

カバレッジ ゾーン ファイルは次のようになります。

<?xml version="1.0"?>
<CDNNetwork>
<!--No coverage zone file from CDM is available-->
<!--Default coverage zones, if any, follow this comment-->
<coverageZone>
<network>10.1.1.0/24</network>
<CE>CE1</CE>
<metric>20</metric>
</coverageZone>
<coverageZone>
<network>10.1.2.0/24</network>
<CE>CE2</CE>
<metric>20</metric>
</coverageZone>
</CDNNetwork>
 

クライアントのソース IP アドレス 10.1.1.20 の場合、次のような proxy.pac ファイルが作成されます。

function FindProxyForURL(url, host)
{
// handle plain host names
if (isPlainHostName(host) {
return “DIRECT”;
 
// handle exception list
if (myIpAddress() == "10.1.1.2") {
return “DIRECT”;
}
 
// handle special domain list
if (shExpMatch(host, "specialdomain.com”)) {
return “PROXY specialDomainProxy.foo.com”;
}
 
// handle direct domain list
if (shExpMatch(host, "directdomain.com”)) {
return “DIRECT”;
}
 
// closest proxies + defaults
p1 = “CE1”;
p2 = “CE2”;
if (p1 != “”) {
p1 = “PROXY “ + p1 + “.proxy.foo.com:8080; ”;
}
if (p2 != “”) {
p2 = “PROXY “ + p2 + “.proxy.foo.com:8080; ”;
}
return p1 + p2 + “DIRECT”;
}
 

PAC ファイル テンプレートの登録とカバレッジ ゾーン情報の割り当て

PAC ファイル テンプレートを登録し、カバレッジ ゾーン情報を割り当てる手順は、次のとおりです。


ステップ 1 Content Distribution Manger GUI で、 System > Routing > PAC File Management > PAC File Registration の順に選択します。PAC File Registration ウィンドウが表示されます。

ステップ 2 Create New PAC File アイコンをクリックします。Registering New PAC File ウィンドウが表示されます(図 4-12 を参照)。

図 4-12 Registering New PAC File ウィンドウ

 

ステップ 3 PAC File URL フィールドに、PAC ファイルの完全なロケーションを入力します。これにより、PAC ファイルを置く場所が CDM に指示され、PAC ファイルを PAC ファイル サーバに配布できるようになります。

ステップ 4 宛先のファイル名を入力します。これは、PAC ファイル サーバに配布される PAC ファイルの名前です。


) この宛先ファイル名をもつ PAC ファイルは、PAC ファイル サーバ上の /state/pacFile ディレクトリにコピーされます。


ステップ 5 エンド ユーザの要求 URL を入力します。これは、PAC ファイル サーバから PAC ファイルを取得するためにブラウザの設定にエンド ユーザが使用する URL です(URL によって指定されたファイルの末尾は「.pac」です)。


) ファイルの取得に 80 以外のポート番号を使用する場合、そのポート番号は URL で指定する必要があります。たとえば、ポート 8080 を使用する場合、URL は次のようになります。http://10.5.1.151:8080/sample.pac


ステップ 6 Coverage Zone File ドロップダウン リストからカバレッジ ゾーン ファイルを選択するか、 None を選択します。

ステップ 7 デフォルトのカバレッジ ゾーンに基づいて、最も近いプロキシを計算したい場合は、 Use the default Coverage Zone チェックボックスにチェックマークを付けます。


) 1 つのカバレッジ ゾーン ファイルだけが入力される場合(ステップ 6 を参照)、指定されたカバレッジ ゾーン ファイル内の情報を使用して、最も近いプロキシが計算されます。デフォルトのカバレッジ ゾーンだけが指定される場合、デフォルトのカバレッジ ゾーンだけを使用して、最も近いプロキシが計算されます。カバレッジ ゾーン ファイルが指定され、かつデフォルトのカバレッジ ゾーンのチェックボックスにチェックマークが付いている場合、カバレッジ ゾーン ファイルとデフォルトのカバレッジ ゾーンの組み合わせに基づいて、最も近いプロキシが計算されます。


ステップ 8 更新間隔の値を分単位で入力します。これは、PAC ファイル URL にあるPAC ファイルに加えられた変更を Content Distribution Manager が検出する頻度を設定します。

ステップ 9 Submit をクリックして、設定値を保存します。


 

Content Engine を PAC ファイル サーバとして設定

PAC ファイル サーバは、PAC ファイル サーバの状況、カバレッジ ゾーン情報、一般的な PAC 情報、および PAC テンプレート情報に加えられた変更を検出します。PAC ファイル サーバは、動的な PAC ファイルを正しく配信できるように、必要に応じて情報を更新します。また、PAC ファイル テンプレートとカバレッジ ゾーン ファイルを既知のロケーションにインストールします。管理者は、任意の数の Content Engine を PAC ファイル サーバとして設定できます。

PAC ファイル サーバとして Content Engine を設定する手順は、次のとおりです。


ステップ 1 Content Distribution Manager GUI から、 Devices > Content Engines の順に選択します。

ステップ 2 PAC ファイル サーバとして設定したい Content Engine の名前の横にある Edit アイコンをクリックします。Modifying Content Engine ウィンドウが表示されます。

ステップ 3 Request Routing セクションで、 Enable PAC File Server チェックボックスにチェックマークを付けます。

ステップ 4 Submit をクリックして、変更内容を保存します。