第 12 章キャッシュ

この章では、Sun Java^TM System Web Proxy Server がどのようにドキュメントをキャッシュするかについて説明します。また、オンラインページを使用してキャッシュを設定する方法についても説明します。

キャッシュのしくみ

キャッシュを利用すると、ネットワークのトラフィックが減少し、プロキシサーバーを使用するクライアントへの応答時間は、リモートサーバーに直接アクセスしないため短縮されます。

クライアントがプロキシサーバーから Web ページまたはドキュメントを要求する場合、プロキシサーバーはクライアントにドキュメントを送信する間に、リモートサーバーのドキュメントをローカルのキャッシュディレクトリ構造にコピーします。

以前に要求したことがあり、プロキシのキャッシュにコピーされているドキュメントをクライアントが要求した場合、プロキシはドキュメントを再度リモートサーバーから取得するのではなく、キャッシュからドキュメントを返します (図 12-1 を参照)。プロキシで、ファイルが最新の状態ではないと判断すると、リモートサーバーのドキュメントを更新し、キャッシュを更新してからドキュメントをクライアントに送信します。

キャッシュ内のファイルは、Sun Java^TM System Web Proxy Serverガベージコレクションユーティリティー (CacheGC) により自動的に管理されます。CacheGC は定期的にキャッシュを自動消去し、キャッシュが古いドキュメントでいっぱいにならないようにします。

キャッシュ構造について

キャッシュは 1 つ以上のパーティションから構成されます。概念上、パーティションとはキャッシュのために確保しておくディスク上のストレージ領域です。キャッシュを複数のディスクに分散させる場合、各ディスクに 1 つ以上のキャッシュパーティションを設定する必要があります。各パーティションは、個別に管理できます。つまり、ほかのすべてのパーティションとは別に各パーティションを有効、無効、および設定できます。

キャッシュされた大量のファイルを一箇所に保存すると、パフォーマンスが低下する場合があるため、各パーティションに複数のディレクトリ、またはセクションを作成することをお勧めします。セクションはキャッシュ構造内のパーティションの 1 つ下のレベルです。キャッシュ内には、パーティション全体で最大 256 のセクションを作成できます。キャッシュのセクション数は、必ず 2 の累乗 (1、2、4、8、16…、256) にしてください。

キャッシュ構造の階層の最下位レベルはサブセクションです。サブセクションはセクション内のディレクトリです。各セクションは 64 のサブセクションから構成されます。キャッシュされたファイルは、キャッシュ内の最下位レベルであるサブセクションに格納されます。

図 12-2 は、パーティションとセクションからなるキャッシュ構造の例を示しています。この図では、キャッシュ全体を 3 つのパーティションに分割したキャッシュディレクトリ構造になっています。最初のパーティションには、4 つのキャッシュセクションが含まれ、2 番目の 2 つのパーティションにはそれぞれ 2 つのセクションが含まれています。

キャッシュの各セクションには、セクションを示す s とセクション番号が付けられています。s3.4 というセクションの場合、3 はキャッシュセクションの数を表す 2 の累乗を示し (2³ = 8)、4 はセクションの番号を意味します (8 つのセクションに 0 ～ 7 のラベルが付けられる)。したがって、s3.4 はセクション 5/8 を意味します。

キャッシュへのファイルの分散

プロキシサーバーは特定のアルゴリズムを使用して、ドキュメントを格納するディレクトリを決定します。このアルゴリズムにより、ディレクトリ内でドキュメントを均等に分散させることができます。ディレクトリに大量のドキュメントを格納すると、パフォーマンスの問題が生じる傾向があるため、均等に分散することが重要です。

プロキシサーバーは、RSA MD5 (Message Digest 5) アルゴリズムを使用して URL を 16 バイトのバイナリデータに縮小し、このデータの 8 バイトを使用してキャッシュにドキュメントを格納するために使用する 16 文字の 16 進数ファイル名を算出します。

キャッシュの詳細設定

キャッシュの詳細を設定することにより、キャッシュを有効にし、プロキシサーバーがキャッシュするプロトコルの種類を制御できます。キャッシュの詳細には、次の項目が含まれます。

キャッシュの有効化または無効化

キャッシュが一時ファイルを格納する作業ディレクトリ

キャッシュされた URL が記録されるディレクトリ名

キャッシュのサイズ

キャッシュの容量

キャッシュされるプロトコルの種類

キャッシュされたドキュメントの更新頻度

プロキシがドキュメントへのアクセス回数を追跡し、リモートサーバーに報告するかどうか

キャッシュの詳細を設定するには

サーバーマネージャーにアクセスし、「Caching」タブをクリックします。

「Set Cache Specifics」リンクをクリックします。「Set Cache Specifics」ページが表示されます。

適切なオプションを選択して、キャッシュを有効または無効にできます。キャッシュはデフォルトで有効になっています。詳細は、「キャッシュの有効化」を参照してください。

作業ディレクトリを入力します。デフォルトでは、作業ディレクトリはプロキシインスタンスの下にあります。キャッシュディレクトリは、別の場所に変更できます。詳細は、「キャッシュの作業ディレクトリの作成」を参照してください。

パーティション設定リンクをクリックします。「Add/Edit Cache Partitions」ページが表示されます。新しいキャッシュのパーティションを追加したり、既存のキャッシュのパーティションを編集したりできます。キャッシュサイズは、キャッシュを増やすことができる最大のサイズです。最大キャッシュサイズは 32Gバイトです。詳細は、「キャッシュサイズの設定」を参照してください。

キャッシュの容量設定リンクをクリックします。「Set Cache Capacity」ページが表示されます。「Set Cache Capacity」ページで、キャッシュの容量を設定できます。詳細は、「キャッシュ容量の編集」を参照してください。

「Cache HTTP」チェックボックスを選択し、HTTP ドキュメントのキャッシュを有効にします。プロキシサーバーで HTTP ドキュメントのキャッシュを行うことにした場合、キャッシュ内のドキュメントの最新状態チェックを常に行うか、あるいは定期的にチェックを行うかを決定する必要があります。また、プロキシサーバーがリモートサーバーにキャッシュのヒットを報告する機能を有効または無効にできます。詳細は、「HTTP ドキュメントのキャッシュ」を参照してください。オプションには次のものがあります。

「Always Check That The Document Is Up To Date」オプションを選択し、HTTP ドキュメントを常に最新の状態に保ちます。

「Check Only If Last Check More Than」ドロップダウンリストから時間数を選択し、プロキシサーバーの更新間隔を指定します。最新状態チェックは、次のオプションのいずれかを使用して実行します。

「Use Last-modified Factor」: これは配信元サーバーによりドキュメントとともに送信される、最後に変更されたヘッダーです。

「Use Only Explicit Expiration Information」: プロキシサーバーは Expires ヘッダーを使用して、キャッシュエントリが新しいか古いかを判断します。

「Never Report Accesses To Remote Server」オプションを選択し、プロキシサーバーからリモートサーバーにアクセス回数を報告しないようにします。

「Report Cache Hits To Remote Server」オプションを選択し、ドキュメントへのアクセス回数を追跡し、リモートサーバーに報告します。

キャッシュされた FTP ドキュメントの更新間隔を設定できます。「Yes; Reload If Older Than」チェックボックスを選択し、ドロップダウンリストから値を選択して間隔を設定します。詳細は、「FTP ドキュメントと Gopher ドキュメントのキャッシュ」を参照してください。

キャッシュされた Gopher ドキュメントに更新間隔を設定できます。「Yes; Reload If Older Than」チェックボックスを選択し、ドロップダウンリストから値を選択して間隔を設定します。詳細は、「FTP ドキュメントと Gopher ドキュメントのキャッシュ」を参照してください。

「了解」をクリックします。

「Restart Required」をクリックします。「Apply Changes」ページが表示されます。

「Restart Proxy Server」ボタンをクリックして、変更を適用します。

次に示す節では、「Set Cache Specifics」ページに一覧表示される要素の詳細情報と、ユーザーのニーズに最も適した設定を決定する際に役立つヒントを提供します。

キャッシュの有効化

キャッシュは、プロキシサーバーを使用する場合にネットワークトラフィックを減らす効果的な方法です。またキャッシュにより、リモートサーバーからドキュメントを取得する必要がなくなるため、クライアントへの応答時間が短縮されます。プロキシサーバーは、キャッシュを有効にした場合は常に最も効果的に機能します。

キャッシュの作業ディレクトリの作成

キャッシュファイルは、キャッシュパーティションに置かれています。「Set Cache Specifics」ページで指定する作業ディレクトリは、多くの場合、キャッシュの親ディレクトリになります。キャッシュされたすべてのファイルは、キャッシュディレクトリに、体系付けられたディレクトリ構造として表現されます。キャッシュディレクトリ名を変更する場合、またはキャッシュディレクトリを別の場所に移動する場合、プロキシに新しい場所を知らせる必要があります。

キャッシュのディレクトリ構造は複数のファイルシステムに拡張できるため、大容量のキャッシュ構造を 1 つの大容量ディスクで管理するのではなく、複数の容量の小さなディスクに分割することができます。各プロキシサーバーには専用のキャッシュディレクトリ構造が必要です。つまり、キャッシュディレクトリは、複数のプロキシサーバーで同時に共有することはできません。

キャッシュサイズの設定

キャッシュサイズは、パーティションサイズを表します。キャッシュサイズは、常にキャッシュ容量より小さくする必要があります。キャッシュ容量はキャッシュを増加させることができる最大サイズであるためです。すべてのパーティションサイズの合計は、必ずキャッシュサイズ以下にする必要があります。

プロキシのキャッシュに利用できるディスク容量は、キャッシュのパフォーマンスに大きく影響します。キャッシュが小さすぎる場合、Cache GC がキャッシュされたドキュメントを削除してディスクに空き容量を作る頻度が増加し、ドキュメントがコンテンツサーバーから取得される頻度が高くなるため、パフォーマンスが低下します。

より多くのドキュメントをキャッシュでき、ネットワークトラフィックの負荷を減少させ、プロキシの応答時間を速くできるため、キャッシュサイズを大容量にするのが最適です。また、キャッシュされたドキュメントは、ユーザー側で不要になれば GC によって削除されます。ファイルシステムの制限をなくすことにより、キャッシュサイズが大きくなり過ぎることはなくなります。つまり、余分な容量は未使用領域として残ります。

またキャッシュは複数のディスクパーティションに分割できます。

キャッシュ容量の編集


警告	キャッシュ構造の変更には時間がかかります。

キャッシュの容量は、「Set Cache Specifics」ページ、および「Set Cache Capacity」ページで編集できます。キャッシュ容量の編集については、「キャッシュ容量の設定」を参照してください。

HTTP ドキュメントのキャッシュ

内部的に、HTTP ドキュメントのキャッシュと FTP ドキュメントおよび Gopher ドキュメントのキャッシュは異なります。HTTP ドキュメントは、ほかのプロトコルのドキュメントにはないキャッシュ機能を備えています。ただし、キャッシュを正しくセットアップし、設定することで、プロキシサーバーでの HTTP、FTP、および Gopher の各ドキュメントを効果的にキャッシュできるようになります。

HTTP ドキュメントにはすべて詳細ヘッダーセクションがあり、プロキシサーバーはこのセクションを使用してプロキシキャッシュ内のドキュメントとリモートサーバー上のドキュメントを比較し、評価します。プロキシが HTTP ドキュメントに対して最新状態チェックを実行する場合、プロキシはサーバーに 1 つの要求を送信し、キャッシュ内のドキュメントが古ければサーバーにドキュメントを返すように指示します。ドキュメントは最後の要求から、変更されていないことが多く、したがって転送されません。このような HTTP ドキュメントの最新状態チェックにより、帯域幅が節約され、遅延が減少します。

リモートサーバーとのトランザクションを減らすために、プロキシサーバーで HTTP ドキュメント用に Cache Expiration setting を設定できます。Cache Expiration setting の設定では、サーバーに要求を送信する前に HTTP ドキュメントの最新状態チェックが必要かどうかを評価するようにプロキシに指示します。プロキシはこの評価を、ヘッダー内の HTTP ドキュメントが最後に変更された (Last-Modified) 日付に基づいて行います。

HTTP ドキュメントの場合、Cache Refresh 設定も使用できます。このオプションは、プロキシが常に最新状態チェックを行うかどうか (有効期限の設定がオーバーライドされる)、プロキシが一定期間待機してからチェックを行うかどうかを指定します。表 12-1 に、有効期限設定と更新設定の両方が指定された場合のプロキシの動作を示します。Refresh 設定を使用すると、遅延が減り、帯域幅を大幅に節約できます。

表 12-1 Cache Expiration 設定と Cache Refresh 設定の HTTP での使用
更新の設定	有効期限の設定	結果
常に最新状態チェックを行う	(適用なし)	常に最新状態チェックを行う
ユーザー指定の間隔	ドキュメントの「expires」ヘッダーを使用	更新期間が過ぎれば最新状態チェックを行う
ユーザー指定の間隔	ドキュメントの Last-Modified ヘッダーで評価	評価および expires ヘッダーに小さな値を設定*

*. 小さな値を使用すると、ドキュメントが頻繁に変更されるため、キャッシュのデータが古くなりません。

HTTP キャッシュの更新間隔の設定

プロキシサーバーで HTTP ドキュメントのキャッシュを行うことにした場合、プロキシサーバーでキャッシュ内のドキュメントの最新状態チェックを常に行うか、あるいはプロキシサーバーで Cache Refresh 設定 (最新状態チェックの間隔) に基づいてチェックを行うかを指定する必要があります。HTTP ドキュメントの場合、更新間隔は 4 ～ 8 時間が適当です。更新間隔を長くすると、プロキシがリモートサーバーに接続する回数が少なくなります。プロキシが次の更新までの間に最新状態チェックを行わない場合でも、クライアントで「Reload」ボタンをクリックすると更新を実行できます。この操作により、プロキシはリモートサーバーで強制的に最新状態チェックを実行します。

HTTP ドキュメントの更新間隔は、「Set Cache Specifics」ページまたは「Set Caching Configuration」ページで設定できます。「Set Cache Specifics」ページでは、グローバルなキャッシュプロシージャーを設定できます。また「Set Caching Configuration」ページでは、特定の URL およびリソースのキャッシュプロシージャーを制御できます。

HTTP キャッシュの有効期限ポリシーの設定

また、Last-Modified 要素または明示的な有効期限情報のみを使用して、キャッシュされたドキュメントが最新かどうかを確認するようにサーバーを設定できます。

明示的な有効期限情報とは、一部の HTTP ドキュメント内にある、ファイルが期限切れになる日時を指定するヘッダーです。明示的な Expires ヘッダーを使用する HTTP ドキュメントは多くないため、Last-modified ヘッダーに基づいて評価することをお勧めします。

HTTP ドキュメントを Last-modified ヘッダーに基づいてキャッシュすることを決定した場合、有効期限の評価で使用する割合を選択する必要があります。LM 要素として知られるこの割合に、最後の変更からドキュメントで最後に最新状態チェックが実行された時間までの間隔を乗算します。この結果の数字を、最後の最新状態チェックからの経過時間と比較します。この数字が間隔時間よりも小さい場合、ドキュメントの期限は切れていません。割合が小さくなると、プロキシのドキュメントチェックの頻度が高くなります。たとえば、最後の変更が 10 日前に行われたドキュメントを考えてみます。Last-Modified 要素を 0.1 に設定した場合、プロキシはこの要素の意味を、ドキュメントが 1 日 (10 * 0.1 = 1) の間変更されない、と解釈します。その場合、ドキュメントのチェックが 1 日以内に実行されている場合、プロキシはキャッシュからドキュメントを返します。

同じ例で、HTTP ドキュメントのキャッシュ更新設定が 1 日未満に設定された場合、プロキシは 1 日に何度か最新状態チェックを実行します。プロキシは常に、ファイルがより頻繁に更新される値 (キャッシュの更新またはキャッシュの有効期限) を使用します。

HTTP ドキュメントの有効期限の設定は「Set Cache Specifics」ページまたは「Set Caching Configuration」ページで設定できます。「Set Cache Specifics」ページでは、グローバルなキャッシュプロシージャを設定できます。また「Set Caching Configuration」ページでは、特定の URL およびリソースのキャッシュプロシージャを制御できます。

HTTP アクセスのリモートサーバーへの報告

Sun Java^TM System Web Proxy Server でドキュメントがキャッシュされると、そのドキュメントには再度更新されるまでに、何度もアクセスできます。リモートサーバーの場合、プロキシにコピーを 1 つ送信し、プロキシがそれをキャッシュする動作が 1 回のアクセス、すなわち「ヒット」になります。Sun Java^TM System Web Proxy Server は、指定されたドキュメントが現在の最新状態チェックから次のチェックまでの間にプロキシキャッシュからアクセスされた回数をカウントし、次回ドキュメントが更新されるときに追加 HTTP 要求ヘッダー (Cache-Info) でそのヒットカウントをリモートサーバーに送信します。このように、リモートサーバーがこの種類のヘッダーを認識するように設定されていれば、リモートサーバーはドキュメントのアクセス回数をより正確に受信できます。

FTP ドキュメントと Gopher ドキュメントのキャッシュ

FTP と Gopher では、ドキュメントの最新状態をチェックするための方法が使用できません。したがって、FTP ドキュメントと Gopher ドキュメントのキャッシュを最適化する唯一の方法は、キャッシュ更新間隔の設定になります。キャッシュ更新間隔は、リモートサーバーから最新バージョンのドキュメントを取得するまでにプロキシサーバーが待機する時間です。キャッシュ更新間隔を設定しない場合、プロキシはキャッシュ内のバージョンが最新である場合でも、リモートサーバーからこれらのドキュメントを取得します。

FTP および Gopher のキャッシュ更新間隔の設定

FTP および Gopher にキャッシュ更新間隔を設定する場合、プロキシがドキュメントを安全に取得できると考えられる間隔を選択します。たとえば、変更がまれな情報を格納している場合、高い数値 (数日間) を使用します。データが常に変更されている場合、最低でも数時間間隔でファイルが取得されるようにします。更新中は、古いファイルをクライアントに送信してしまう危険性があります。この間隔が十分に短い場合 (数時間)、このような危険性をほぼ完全に除外でき、応答時間も著しく向上します。

FTP ドキュメントおよび Gopher ドキュメントのキャッシュの更新間隔は、「Set Cache Specifics」ページまたは「Set Caching Configuration」ページで設定できます。「Set Cache Specifics」ページでは、グローバルなキャッシュプロシージャーを設定できます。また「Set Caching Configuration」ページでは、特定の URL およびリソースのキャッシュプロシージャーを制御できます。「Set Cache Specifics」ページの使用については、「キャッシュの詳細設定」を、「Set Caching Configuration」ページの使用については、「キャッシュの設定」を参照してください。


注	FTP ドキュメントおよび Gopher ドキュメントでドキュメント間に大きな相違がある場合 (ドキュメントにより変更頻度が異なる場合)、「Set Caching Configuration」ページでドキュメントの種類ごとに個別にテンプレートを作成し (たとえば、リソース ftp://.*.gif でテンプレートを作成するなど)、次にそのリソースに適した更新間隔を設定します。

キャッシュの作成と変更

キャッシュパーティションは、キャッシュ用に確保される、予約されたディスクまたはメモリーの一部です。キャッシュ容量が変更された場合、「Add/Edit Cache Partitions」ページを使用してパーティションを変更または追加できます。このページでは、パーティションの場所、ニーモニック名、最大および最小サイズを編集できます。また、そのパーティションのキャッシュセクションテーブルを表示できます。

キャッシュパーティションを追加するには

サーバーマネージャーにアクセスし、「Caching」タブをクリックします。

「Add/Edit Cache Partitions」リンクをクリックします。「Add/Edit Cache Partitions」ページが表示されます。

「Add Cache Partition」ボタンをクリックします。「Cache Partition Configuration」ページが表示されます。

新しいパーティションの適切な値を入力します。

「了解」をクリックします。

「Restart Required」をクリックします。「Apply Changes」ページが表示されます。

「Restart Proxy Server」ボタンをクリックして、変更を適用します。

キャッシュパーティションを変更するには

サーバーマネージャーにアクセスし、「Caching」タブをクリックします。

「Add/Edit Cache Partitions」リンクをクリックします。「Add/Edit Cache Partitions」ページが表示されます。

変更するパーティションの名前をクリックします。

情報を編集します。

「了解」をクリックします。

「Restart Required」をクリックします。「Apply Changes」ページが表示されます。

「Restart Proxy Server」ボタンをクリックして、変更を適用します。

キャッシュ容量の設定

キャッシュ容量の値は、キャッシュのディレクトリ構造を導き出すために使用します。このキャッシュ容量から、キャッシュディレクトリに含められるセクションの数が導き出されます。キャッシュ容量とキャッシュディレクトリのキャッシュ階層には直接的な関係があります。容量が大きくなると、階層も大規模になります。キャッシュ容量は、キャッシュのサイズ以上である必要があります。外部ディスクを追加するなど、あとでキャッシュサイズを増やす予定があるとわかっている場合は、キャッシュ容量をキャッシュサイズよりも大きく設定しておくと便利です。キャッシュ容量の最大値は 32G バイトで、この中に 256 のセクションを作成できます。

キャッシュ容量を設定するには

サーバーマネージャーにアクセスし、「Caching」タブをクリックします。

「Set Cache Capacity」リンクをクリックします。「Set Cache Capacity」ページが表示されます。

「New Capacity Range」ドロップダウンリストから、容量を選択します。

「了解」をクリックします。

「Restart Required」をクリックします。「Apply Changes」ページが表示されます。

「Restart Proxy Server」ボタンをクリックして、変更を適用します。

キャッシュセクションの管理

プロキシキャッシュは、1 つ以上のキャッシュセクションに分割されます。最大 256 のセクションを作成できます。キャッシュセクションの数は、必ず 2 の累乗 (1、2、4、8、16…、256) にしてください。最大容量は 32G バイト (最適) で、256 のキャッシュセクションに分割できます。

キャッシュ容量に 500M バイトを選択した場合、インストーラは 4 つのキャッシュセクション (500 / 125 = 4) を作成します。キャッシュ容量に 2G バイトを選択した場合、インストーラは 16 のセクション (2000 / 125 = 16) を作成します。125M バイトは、各セクションでセクション数を確保するための最適値として選択します。セクション数が多くなると、格納および分散される URL の数が多くなります。

キャッシュセクションを管理するには

サーバーマネージャーにアクセスし、「Caching」タブをクリックします。

「Manage Sections」リンクをクリックします。「Manage Sections」ページが表示されます。

テーブル内の情報を変更します。セクションは既存のパーティション間で移動することができます。

「了解」をクリックします。

「Restart Required」をクリックします。「Apply Changes」ページが表示されます。

「Restart Proxy Server」ボタンをクリックして、変更を適用します。

ガベージコレクションの詳細設定

「Set Garbage Collection Preferences」ページは、ガベージコレクションモードの設定に使用します。

キャッシュガベージコレクタを使用して、キャッシュからファイルを削除します。ガベージコレクションは、自動モードまたは明示モードのいずれかで実行できます。明示モードは、「Schedule Garbage Collection」ページを使用して管理者が外部からスケジュールします。いずれかのモードを選択し、「了解」をクリックします。「Restart Required」をクリックします。「Apply Changes」ページが表示されます。「Restart Proxy Server」ボタンをクリックして、変更を適用します。

ガベージコレクションのスケジュール

「Schedule Garbage Collection」ページでは、ガベージコレクションが実行される日時を指定できます。

ガベージコレクションをスケジュールするには:

サーバーマネージャーにアクセスし、「Caching」タブをクリックします。

「Schedule Garbage Collection」リンクをクリックします。「Schedule Garbage Collection」ページが表示されます。

ガベージコレクションが実行される時間を、「Schedule Garbage Collection At」リストから選択します。

ガベージコレクションを実行する曜日を指定します。

「了解」をクリックします。

「Restart Required」をクリックします。「Apply Changes」ページが表示されます。

「Restart Proxy Server」ボタンをクリックして、変更を適用します。

キャッシュの設定

「Set Caching Configuration」ページを使用して、特定のリソースに使用するキャッシュの種類を設定できます。URL には指定する正規表現パターンに一致する複数の設定パラメータ値を指定できます。この機能により、キャッシュされたドキュメントの種類に基づいて、プロキシキャッシュを詳細に制御できます。キャッシュの設定では、次の項目を指定します。

キャッシュのデフォルト

認証が必要なページをキャッシュする方法

クエリーをキャッシュする方法

キャッシュファイルの最小および最大サイズ

キャッシュされたドキュメントの更新頻度

キャッシュの有効期限ポリシー

クライアント割り込みの場合のキャッシュ動作

配信元サーバーへの接続が失敗した場合のキャッシュ動作



注	特定のリソースのキャッシュデフォルトを「Derived configuration」か「Don’t cache」のいずれかに設定した場合、キャッシュ設定オプションは「Set Caching Configuration」ページに表示されません。ただし、リソースにキャッシュデフォルトの「Cache」を選択した場合は、複数のほかの設定項目を指定することができます。

キャッシュを設定するには

サーバーマネージャーにアクセスし、「Caching」タブをクリックします。

「Set Caching Configuration」ページをクリックします。「Set Caching Configuration」ページが表示されます。

ドロップダウンリストからリソースを選択するか、「Regular Expression」ボタンをクリックして正規表現を入力し、「了解」をクリックします。

設定情報を変更します。

「了解」をクリックします。

「Restart Required」をクリックします。「Apply Changes」ページが表示されます。

「Restart Proxy Server」ボタンをクリックして、変更を適用します。

設定要素のキャッシュ

次の項では、「Set Caching Configuration」ページに一覧表示される項目について説明します。次の節では、ニーズに最も適した設定を決定する際に役に立つ情報が含まれています。

キャッシュデフォルトの設定

プロキシサーバーでは、特定のリソースに対するキャッシュデフォルトを指定できます。リソースは指定した特定の基準と一致する、ファイルの一種です。たとえば、サーバーがドメイン company.com からすべてのドキュメントを自動的にキャッシュするように設定することができます。この場合、「Set Caching Configuration」ページの最上部にある「Regular Expression」ボタンをクリックし、表示されるフィールドに次のように入力します。

デフォルトでは、「Cache」オプションが選択されています。サーバーはキャッシュ可能なすべてのドキュメントを上記のドメインから自動的にキャッシュします。正規表現については、「正規表現について」を参照してください。

HTTP、FTP、および Gopher のキャッシュデフォルトは、「Set Cache Specifics」ページでも設定できます。

認証が必要なページのキャッシュ

サーバーのキャッシュにユーザー認証が必要なファイルを保存できます。プロキシサーバーのキャッシュにこのようなファイルを保存することを選択した場合、プロキシサーバーはキャッシュ内のファイルにタグを付け、ユーザーがファイルを要求した場合に、リモートサーバーからの認証が必要なファイルとして認識できるようにします。

プロキシサーバーはリモートサーバーの認証方式を認識しておらず、ユーザーの ID やパスワードを把握していないため、認証を必要とするドキュメントが要求されるたびにリモートサーバーで最新状態チェックを強制的に実行します。したがって、ユーザーはファイルにアクセスするために ID とパスワードを入力する必要があります。ユーザーが Navigator セッションで以前にそのサーバーにアクセスしている場合、Navigator により認証情報が自動的に送信され、ユーザーに入力が要求されません。

認証を必要とするページのキャッシュを有効に設定していない場合、プロキシはデフォルトと見なしてそのページをキャッシュしません。

クエリーのキャッシュ

クエリーのキャッシュは HTTP ドキュメントでのみ有効です。キャッシュされるクエリーの長さを制限できます。またはクエリーのキャッシュを完全に禁止することができます。クエリーが長くなると、繰り返される可能性が低くなるため、キャッシュの有用性も低くなります。

アクセス方式を GET にする、ドキュメントは保護されない (認証されたページのキャッシュを有効にしている場合を除く)、応答には少なくとも Last-modified ヘッダーを含める、というキャッシュ制限がクエリーに対して適用されます。この制限では、クエリーエンジンに対して、クエリー結果のドキュメントがキャッシュ可能であることを示す必要があります。Last-modified ヘッダーが含まれている場合は、クエリーエンジンはキャッシュを有効にするために条件付き GET メソッド (If-modified-since ヘッダーを使用) をサポートする必要があります。含まれていない場合は、Expires ヘッダーを返す必要があります。

キャッシュファイルの最小および最大サイズの設定

プロキシサーバーにキャッシュされるファイルに最小および最大サイズを設定できます。高速ネットワーク接続を確立している場合、最小サイズを設定してください。高速接続を使用している場合、小さい容量のファイルはすぐに取得できるため、サーバーはファイルをキャッシュする必要がありません。この例では、大容量のファイルのみキャッシュが必要になります。最大ファイルサイズを設定することで、大容量のファイルによりプロキシのディスク容量が占有されるのを防ぐことができます。

最新状態チェックポリシーの設定

このオプションを使用して、HTTP ドキュメントを常に最新の状態に保つことができます。また、プロキシサーバーに更新間隔を指定することもできます。

有効期限ポリシーの設定

Last-modified 要素または明示的な有効期限情報を使用して、有効期限ポリシーを設定できます。

クライアント割り込みの場合のキャッシュ動作の設定

ドキュメントの一部のみが取得され、クライアントがデータ転送に割り込む場合、プロキシにはドキュメントをキャッシュするために、ドキュメントの取得を終了させる機能があります。プロキシのデフォルトでは、ドキュメントの 25 パーセント以上が取得された場合、キャッシュのためドキュメントの取得を終了します。それ以外の場合、プロキシはリモートサーバー接続を終了し、不完全なファイルを削除します。クライアント割り込みの割合は、高くしたり低くしたりすることができます。

サーバー接続に失敗した場合の動作

配信元サーバーに到達できないため、古いドキュメントの最新状態チェックに失敗する場合、プロキシがキャッシュの古いドキュメントを送信するかどうかを指定できます。


注	特定のリソースのキャッシュデフォルトを、「Derived configuration」か「Don’t cache」のいずれかに設定した場合、そのリソースのキャッシュを設定する必要はありません。ただし、リソースにキャッシュデフォルトの「Cache」を選択した場合は、複数のほかの設定項目を指定することができます。これらの項目のリストについては、「キャッシュの設定」を参照してください。

ローカルホストのキャッシュ

ローカルホストから要求された URL にドメイン名がない場合、プロキシサーバーはキャッシュの重複を避けるために、その URL をキャッシュしません。たとえば、ユーザーがローカルサーバーから http://machine/filename.html と http://machine.example.com/filename.html を要求する場合、どちらの URL もキャッシュに格納されている可能性があります。これらのファイルはローカルサーバーのファイルであるため、すばやく取得でき、キャッシュする必要がありません。

ただし、会社で複数のリモートの場所にサーバーを配置している場合、すべてのホストのドキュメントをキャッシュして、ネットワークトラフィックを減らし、ファイルへのアクセス時間を短縮することができます。

ローカルホストのキャッシュを有効にするには

サーバーマネージャーにアクセスし、「Caching」タブをクリックします。

「Cache Local Hosts」リンクをクリックします。「Cache Local Hosts」ページが表示されます。

ドロップダウンリストからリソースを選択するか、「Regular Expression」ボタンをクリックして正規表現を入力し、「了解」をクリックします。正規表現については、「テンプレートとリソースの管理」を参照してください。

「Enabled」ボタンをクリックします。

「了解」をクリックします。

「Restart Required」をクリックします。「Apply Changes」ページが表示されます。

「Restart Proxy Server」ボタンをクリックして、変更を適用します。

ファイルキャッシュの設定

デフォルトでは、ファイルキャッシュが有効になっています。ファイルキャッシュの設定は、server.xml ファイルに保存されています。ファイルキャッシュの設定は、サーバーマネージャーを使用して変更することができます。

ファイルキャッシュを設定するには


注	「Configure File Cache」ページはユーザーインタフェースに表示されますが、今回の Proxy Server 4 のリリースでは実装されていません。

サーバーマネージャーから、「Preferences」タブをクリックします。

「File Cache Configuration」リンクをクリックします。「File Cache Configuration」ページが表示されます。

まだ選択されていない場合には、「Enable File Cache」を選択します。

ファイルを転送するかどうかを選択します。

「Transmit File」を有効にした場合、サーバーはファイルキャッシュにファイルのコンテンツではなく、オープンしているファイルの記述子をキャッシュし、クライアントへのファイルコンテンツの送信には PR_TransmitFile が使用されます。「Transmit File」を有効にした場合、オープンしているファイルの記述子のみがキャッシュされるため、通常はファイルキャッシュによって行われる、小、中、大の異なるサイズのファイルの区別が行われなくなります。デフォルトでは、Windows では「Transmit File」は有効に、UNIX では無効に設定されています。UNIX では、ネイティブ OS で PR_TransmitFile がサポートされているプラットフォームのみで「Transmit File」を有効にしてください。現在 HP-UX と AIX が該当します。その他の UNIX/Linux プラットフォームではお勧めできません。

ハッシュテーブルのサイズを入力します。デフォルトサイズはファイルの最大数の 2 倍に 1 を加えた数です。たとえば、ファイルの最大数が 1024 に設定されている場合、デフォルトのハッシュテーブルのサイズは 2049 になります。

有効なキャッシュエントリの最大時間を秒数で入力します。デフォルトでは、これは 30 に設定されています。この設定により、ファイルがキャッシュされてから、キャッシュされた情報を継続して使用できる時間が制御されます。「MaxAge」よりも古いエントリは、同じファイルがキャッシュから参照された場合、同じファイルの新しいエントリに置き換えられます。コンテンツを定期的に更新 (既存のファイルを変更) するかどうかに基づいて最大時間を設定します。たとえば、コンテンツが定期的に 1 日に 4 回更新される場合、最大時間を 21600 秒 (6 時間) に設定できます。それ以外の場合、最大時間には、ファイルが変更されたあと、以前のバージョンのコンテンツファイルを提供する最大時間を設定することを検討してください。

キャッシュするファイルの最大数を入力します。デフォルトでは、これは 1024 に設定されています。

ファイルサイズ (中) およびファイルサイズ (小) の上限をバイトで入力します。デフォルトでは、「Medium File Size Limit」は 537600 に設定され、「Small File Size Limit」は 2048 に設定されています。

キャッシュは小ファイル、中ファイル、大ファイルを異なる方法で処理します。中ファイルのコンテンツは、ファイルが仮想メモリー (現在は UNIX/Linux プラットフォームのみ) にマッピングされることにより、キャッシュされます。小ファイルのコンテンツは、ヒープスペースが割り当てられ、ファイルをそのスペース内に読み込むことにより、キャッシュされます。(中よりも大きい) 大ファイルのコンテンツはキャッシュされませんが、大ファイルの情報はキャッシュされます。小ファイルと中ファイルを区別する利点は、小ファイルが多数ある場合に、仮想メモリーで多くのページが消費されるのを防ぐことにあります。このため、「Small File Size Limit」の値は、通常は VM ページサイズよりもやや低い値になります。

中ファイルおよび小ファイルの容量を設定します。中ファイルの容量は、中サイズの全ファイルのマップに使用される仮想メモリーのサイズをバイトで表したものです。デフォルトでは、これは 10485760 に設定されています。小ファイルの容量は、小ファイルのキャッシュに使用されるヒープスペースを含めた、キャッシュに使用されるヒープスペースをバイトで表したものです。UNIX/Linux の場合、デフォルトで 1048576 に設定されています。

「了解」をクリックします。

「Restart Required」をクリックします。「Apply Changes」ページが表示されます。

「Restart Proxy Server」ボタンをクリックして、変更を適用します。

URL データベースの表示

記録およびキャッシュされたすべての URL の名前と属性を表示できます。URL 情報は、キャッシュされたドキュメントをアクセスプロトコルとサイト名別にグループ化したリストとして表示されます。リストに表示する URL は、「Find」フィールドにドメイン名を入力して制限できます。この情報にアクセスすることで、ドキュメントの期限切れやキャッシュからの削除などのさまざまなキャッシュ管理機能を実行できます。

データベースの URL を表示するには

サーバーマネージャーにアクセスし、「Caching」タブをクリックします。

「View URL Database」リンクをクリックします。「View URL Database」ページが表示されます。

「Regenerate」ボタンをクリックし、キャッシュされた URL の最新のリストを生成します。特定の URL の情報を表示する場合は、「Find」フィールドに URL または正規表現を入力し、「Find」ボタンをクリックします。

ドメイン名とホストで分類されたキャッシュデータベース情報を表示する場合は、リストからドメイン名を選択します。そのドメインのホストのリストが表示されます。ホスト名をクリックすると、URL のリストが表示されます。

URL の名前をクリックします。その URL に関する詳細な情報が表示されます。

ファイルの期限切れとキャッシュからの削除

「View URL Database」ページから、ドキュメントを期限切れにし、キャッシュから削除できます。

キャッシュされた URL を期限切れ、または削除するには

サーバーマネージャーにアクセスし、「Caching」タブをクリックします。

「View URL Database」リンクをクリックします。「View URL Database」ページが表示されます。

「Regenerate」ボタンをクリックします。キャッシュデータベースのスナップショットが生成されます。このスナップショットが、以降の手順の基準になります。

期限切れにするまたは削除する特定の URL についての情報を得たい場合は、「Find」フィールドにその URL またはその URL に対応するまたは正規表現を入力し、「Find」ボタンをクリックします。ドメイン名とホストで分類された URL のグループに対して処理を行う場合は、リストからドメイン名を選択します。そのドメイン内にあるホストのリストが表示されます。ホスト名をクリックすると、URL のリストが表示されます。

個々のファイルを期限切れにするには、それらのファイルの URL の横の「Ex」オプションを選択し、「Exp/Rem Marked」オプションをクリックします。リスト内のすべてのファイルを期限切れにするには、フォームの下部の「Exp All」ボタンをクリックします。キャッシュから個々のファイルを削除するには、それらのファイルの URL の横の「Remove」オプションを選択し、「Exp/Rem Marked」ボタンをクリックします。リスト内のすべてのファイルを削除するには、「Rem All」ボタンをクリックします。

「Regenerate」ボタンをクリックし、スナップショットを再生成します。



注	「Ex」オプションまたは「Remove」オプションを使用する場合、関連ファイルは処理されますが、スナップショットに変更が反映されません。変更を反映させるには、スナップショットを再生成する必要があります。

キャッシュのバッチ更新の使用

キャッシュのバッチ更新機能を使用した場合、指定された Web サイトにファイルをプリロードしたり、プロキシサーバーがビジー状態の場合を除いて、キャッシュ内のドキュメントの最新状態チェックを実行したりすることができます。URL のバッチは「Set Cache Batch Updates」ページで作成、編集、削除することができ、バッチの更新を有効または無効にすることができます。

バッチ更新の作成

バッチ更新を実行するファイルを指定することによって、オンデマンドとは異なり、ファイルをアクティブにキャッシュできます。プロキシサーバーでは、現在キャッシュにある複数のファイルに対して、最新状態チェックを実行したり、特定の Web サイト内の複数のファイルをプリロードしたりできます。

バッチ更新を作成するには

サーバーマネージャーにアクセスし、「Caching」タブをクリックします。

「Set Cache Batch Updates」リンクをクリックします。「Set Cache Batch Updates」ページが表示されます。

「Create/Select a Batch Update Configuration.」の横のドロップダウンリストから、「New and Create」を選択します。

「了解」をクリックします。「Set Cache Batch Updates」ページが表示されます。

「Name」セクションに、新しいバッチ更新のエントリの名前を入力します。

このページの「Source」セクションで、作成するバッチ更新の種類のラジオボタンをクリックします。キャッシュ内のすべてのドキュメントに対して最新状態チェックを実行する場合は、最初のラジオボタンをクリックします。指定されたソース URL から再帰的に URL をキャッシュする場合は、2 つ目のラジオボタンをクリックします。

「Source」セクションフィールドで、バッチ更新で使用するドキュメントを指定します。

「Exceptions」セクションで、バッチ更新から除外するファイルをすべて指定します。

「Resources」セクションに、同時接続の最大数と走査するドキュメントの最大数を入力します。

「Timing」セクションに、バッチ更新を生成する開始時間と終了時間を入力します。常に 1 つのバッチ更新のみが実行されるため、ほかのバッチ更新設定と重ならないようにするためには最適な方法です。

「了解」をクリックします。



注	バッチ更新設定は、この機能を有効にせずに作成、編集、および削除できます。ただし、「Set Cache Batch Updates」ページで設定した時間に従ってバッチ更新を実行する場合は、更新を有効にする必要があります。

「Restart Required」をクリックします。「Apply Changes」ページが表示されます。

「Restart Proxy Server」ボタンをクリックして、変更を適用します。

バッチ更新設定の編集または削除

「Set Cache Batch Updates」ページを使用して、バッチ更新を編集または削除できます。特定のファイルを除外する必要がある場合、またはバッチの更新回数を増やす場合、バッチ更新を編集することができます。また、バッチ更新設定を完全に削除することもできます。

バッチ更新設定を編集または削除するには

サーバーマネージャーにアクセスし、「Caching」タブをクリックします。

「Set Cache Batch Updates」リンクをクリックします。「Set Cache Batch Updates」ページが表示されます。

バッチを編集する場合は、そのバッチの名前を選択し、「Create/Select a Batch Update Configuration」の横のドロップダウンリストから「Edit」を選択します。バッチを削除する場合、そのバッチの名前を選択し、ドロップダウンリストから「Remove」を選択します。

「了解」をクリックします。「Set Cache Batch Updates」ページが表示されます。

必要に応じて、情報を変更します。

「了解」をクリックします。

「Restart Required」をクリックします。「Apply Changes」ページが表示されます。

「Restart Proxy Server」ボタンをクリックして、変更を適用します。

コマンド行インタフェースの使用

プロキシサーバーには、いくつかのコマンド行ユーティリティーが付属しており、これを使用してキャッシュのディレクトリ構造を設定、変更、生成、および修正することができます。これらのユーティリティーのほとんどは、サーバーマネージャーの各ページで使用できるものと重複しますが、cron ジョブなどの保守をスケジュールする必要がある場合、ユーティリティーを使用することもできます。すべてのユーティリティーは extras ディレクトリにあります。

コマンド行ユーティリティーを実行するには

コマンド行プロンプトから server_root/proxy-serverid ディレクトリに移動します。

./start -shell と入力します。

次の節では各種のユーティリティーについて説明します。

キャッシュのディレクトリ構造の構築

プロキシには、オフラインでキャッシュデータベースを管理する cbuild と呼ばれるユーティリティーがあります。このユーティリティーを使用すると、コマンド行インタフェースを使用して新しいキャッシュ構造を作成したり、既存のキャッシュ構造を変更することができます。新しく作成されたキャッシュをプロキシで使用できるようにするには、サーバーマネージャーのページを使用します。このユーティリティーは server.xml ファイルを更新しません。cbuild は複数のパーティションを持つキャッシュのサイズを変更できません。server.xml ファイルには、cachecapacity パラメータを持つ CACHE と呼ばれる要素が含まれています。キャッシュが cbuild により作成または変更された場合、server.xml ファイルで cachecapacity パラメータを手動で更新する必要があります。

cbuild ユーティリティーは 2 つのモードで起動できます。1 つ目のモードは次のとおりです。

cbuild -d server_root/proxy-serverid/config -c server_root/proxy-serverid/cache -s 512

cbuild -d server_root/proxy-serverid/config -c server_root/proxy-serverid/cache -s 512 -r

conf-dir は、プロキシインスタンスの設定ディレクトリ。server_root/proxy-serverid/config のパスにあります。

cache-dir はキャッシュ構造のディレクトリ。

cache size は、キャッシュを増加させることができる最大サイズ。このオプションは cache-dim パラメータとともに使用できません。最大サイズは 65135M バイトです。

-r は、単一パーティション構成の場合、既存のキャッシュ構造のサイズを変更します。新しいキャッシュを作成する場合は必要ありません。

cbuild -d server_root/proxy-serverid/config -c server_root/proxy-serverid/cache -n 3

cbuild -d server_root/proxy-serverid/config -c server_root/proxy-serverid/cache -n 3 -r

conf-dir はプロキシインスタンスの設定ディレクトリ。server_root/proxy-serverid/config のパスにあります。

cache-dir はキャッシュ構造のディレクトリ。

cache-dim はセクション数を指定します。たとえば、図 12-2 の s3.4 として示されるセクションでは、3 は次元を示します。cache-dim のデフォルト値は 0、最大値は 8 です。

-r は、単一パーティション構成の場合、既存のキャッシュ構造のサイズを変更します。新しいキャッシュを作成する場合は必要ありません。

キャッシュ URL リストの管理

プロキシには、キャッシュ内の URL リストを管理する urldb と呼ばれるユーティリティーがあります。このユーティリティーを使用して、キャッシュされる URL を一覧表示することができます。また、キャッシュされたオブジェクトを選択的に有効期限切れにしたり、キャッシュデータベースから削除することができます。

urldb コマンドは、-o オプションに基づいて 3 つのグループに分類できます。

ドメイン

サイト

URL

ドメインを一覧表示するには、コマンド行で次のコマンドを入力します。

urldb -o matching_domains -e ".*phoenix.*" -d server_root/proxy-serverid/config

matching_domains は正規表現に一致するドメインを一覧表示します。

reg_exp は使用する正規表現。

conf-dir は、プロキシインスタンスの設定ディレクトリ。server_root/proxy-serverid/config のパスにあります。

ドメイン内で一致するサイトをすべて一覧表示するには、コマンド行で次のように入力します。

urldb -o matching_sites_in_domain -e ".*atlas" -m phoenix.com -d server_root/proxy-serverid/config

matching_sites_in_domain は正規表現に一致するドメイン内のすべてのサイトを一覧表示します。

reg_exp は使用する正規表現。

domain_name はドメインの名前。

conf-dir は、プロキシインスタンスの設定ディレクトリ。server_root/proxy-serverid/config のパスにあります。

一致するサイトをすべて一覧表示するには、コマンド行で次のように入力します。

urldb -o all_matching_sites -e ".*atlas.*" -d server_root/proxy-serverid/config

all_matching_sites は、正規表現に一致するすべてのサイトを一覧表示します。

reg_exp は使用する正規表現。

conf-dir は、プロキシインスタンスの設定ディレクトリ。server_root/proxy-serverid/config のパスにあります。

サイト内で一致する URL を一覧表示するには、コマンド行で次のように入力します。

urldb -o matching_urls_from_site -e "http://.*atlas.*" -s atlas.phoenix.com -d server_root/proxy-serverid/config

matching_urls_from_site は、正規表現に一致するサイトのすべての URL を一覧表示します。

reg_exp は使用する正規表現。

site_name はサイトの名前。

conf-dir は、プロキシインスタンスの設定ディレクトリ。server_root/proxy-serverid/config のパスにあります。

サイト内で一致する URL を有効期限切れまたは削除するには、コマンド行で次のように入力します。

urldb -o matching_urls_from_site -e "http://.*atlas.*" -s atlas.phoenix.com -x e -d iserver_root/proxy-serverid/config

matching_urls_from_site は、正規表現に一致するサイトのすべての URL を一覧表示します。

reg_exp は使用する正規表現。

site_name はサイトの名前。

-x e は、キャッシュデータベースで一致する URL を有効期限切れにするオプション。このオプションは、ドメインモードおよびサイトモードでは使用できません。

-x r は、キャッシュデータベースで一致する URL を削除するオプション。

conf-dir は、プロキシインスタンスの設定ディレクトリ。server_root/proxy-serverid/config のパスにあります。

一致する URL をすべて一覧表示するには、コマンド行で次のように入力します。

urldb -o all_matching_urls -e ".*cgi-bin.*" -d server_root/proxy-serverid/config

all_matching_urls は、正規表現に一致するすべての URL を一覧表示します。

reg_exp は使用する正規表現。

conf-dir は、プロキシインスタンスの設定ディレクトリ。server_root/proxy-serverid/config のパスにあります。

一致する URL をすべて有効期限切れまたは削除するには、コマンド行で次のように入力します。

urldb -o all_matching_urls -e ".*cgi-bin.*" -x e -d server_root/proxy-serverid/config

all_matching_urls は、正規表現に一致するすべての URL を一覧表示します。

reg_exp は使用する正規表現。

-x e は、キャッシュデータベースで一致する URL を有効期限切れにするオプション。

-x r は、キャッシュデータベースで一致する URL を削除するオプション。

conf-dir は、プロキシインスタンスの設定ディレクトリ。server_root/proxy-serverid/config のパスにあります。

URL のリストを有効期限切れまたは削除するには、コマンド行で次のように入力します。

url-list は、有効期限切れにする必要のある URL のリストです。このオプションを使用して、URL リストを表示できます。

-x e は、キャッシュデータベースで一致する URL を有効期限切れにするオプション。

-x r は、キャッシュデータベースで一致する URL を削除するオプション。

reg_exp は使用する正規表現。

conf-dir は、プロキシインスタンスの設定ディレクトリ。server_root/proxy-serverid/config のパスにあります。

キャッシュガベージコレクションの管理

cachegc ユーティリティーを使用すると、キャッシュデータベースにある有効期限切れのオブジェクト、または古くなりすぎてキャッシュサイズの制約によりディレクトリにキャッシュできなくなったオブジェクトを消去できます。


注	cachegc ユーティリティーを使用する場合は、プロキシインスタンスで CacheGC が実行されていないことを確認してください。

cachegc -f leave-fs-full-percent -u gc-high-margin-percent -l gc-low-margin-percent -e extra-margin-percent -d conf-dir

leave-fs-full-percent は、ガベージコレクションが実行されない範囲のキャッシュパーティションサイズの割合を決定します。

gc-high-margin-percent は、最大キャッシュサイズの割合を制御します。その割合に達するとガベージコレクションが開始されます。

gc-low-margin-percent は、ガベージコレクタがターゲットとする最大キャッシュサイズの割合を制御します。

extra-margin-percent は、削除するキャッシュの割合を決定するために、ガベージコレクタによって使用されます。

conf-dir は、プロキシインスタンスの設定ディレクトリ。server_root/proxy-serverid/config のパスにあります。

バッチ更新の管理

bu ユーティリティーはキャッシュを更新し、2 つのモードで動作します。1 つ目のモードでは、キャッシュデータベース内を反復し、それぞれに HTTP 要求を送信することで、キャッシュ内に存在するすべての URL を更新します。2 つ目のモードでは、指定された URL から開始し、その URL から指定する深さまでのすべてのリンクに対して幅優先の反復を行い、キャッシュにページをフェッチします。bu は RFC 準拠のロボットです。

bu -n hostname -p port -t time-lmt -f contact-address -s sleep-time -o object -r n -d conf-dir

bu -n phoenix -p 80 -t 3600 -f admin@phoenix.com -s 60 -o nova -r n -d server_root/proxy-serverid/config

hostname は、プロキシが稼働しているマシンのホスト名。デフォルト値は localhost。

port はプロキシサーバーが稼働しているポート。デフォルトポートは 8080。

time-lmt はユーティリティーが実行される制限時間。

contact-address は、bu から送信される HTTP 要求で送信される連絡先アドレスを指定します。デフォルト値は worm@proxy-name。

sleep-time は 2 つの連続する要求の間のスリープ時間。デフォルト値は 5 秒です。

object は、現在実行している bu.conf で指定されるオブジェクト。

-r n オプションは、robot.txt ポリシーに従うかどうかを指定します。デフォルト値は y。

conf-dir は、プロキシインスタンスの設定ディレクトリ。server_root/proxy-serverid/config のパスにあります。

Internet Cache Protocol (ICP) の使用

ICP について

Internet Cache Protocol (ICP) は、オブジェクトロケーションプロトコルで、キャッシュ間の対話を可能にします。キャッシュでは ICP を使用して、キャッシュされた URL の存在と、それらの URL を取得するための最適な場所について、クエリーの送信と応答を行います。通常の ICP 交換では、1 つのキャッシュから特定の URL に関する 1 つの ICP クエリーが隣接するすべてのキャッシュに送信されます。次に、隣接するキャッシュに、その URL が含まれているかどうかを示す ICP 応答を返します。隣接するキャッシュに URL が含まれていない場合、「MISS」を返します。URL が存在する場合、「HIT」を返します。

隣接 ICP を経由したルーティング

ICP は異なる管理ドメインに存在するプロキシ間の通信に使用できます。ICP により、ある管理ドメインのプロキシキャッシュは、別の管理ドメイン内のプロキシキャッシュと通信できます。ICP は複数のプロキシサーバー間で通信する必要があるが、プロキシ配列内にあるため、1 つのマスタープロキシからすべてのプロキシサーバーを設定できないような場合に適しています。図 12-3 は異なる管理ドメインにあるプロキシ間の ICP 交換を示しています。

ICP を介して通信するプロキシは、ネイバーと呼ばれます。隣接 ICP 内に 64 を超えるネイバーを配置できません。隣接 ICP には、parent と sibling の 2 種類のネイバーがあります。要求される URL がほかのネイバーに存在しない場合、parent のみがリモートサーバーにアクセスできます。隣接 ICP には parent が存在しなくても、また複数の parent が存在していてもかまいません。隣接 ICP 内の parent 以外のネイバーは、sibling と呼ばれます。sibling は、sibling が ICP のデフォルト経路としてマークされている場合を除き、リモートサーバーからドキュメントを取得できません。この場合 ICP はデフォルトを使用します。

ネイバーがクエリーを受け取る順序を決定する場合は、ポーリングラウンドを使用できます。ポーリングラウンドは ICP クエリーのサイクルです。各ネイバーに対して、ポーリングラウンドを割り当てる必要があります。すべてのネイバーをポーリングラウンド 1 に設定する場合、すべてのネイバーは 1 サイクルで照会されます。言い換えると、すべてのネイバーは同時に照会されます。一部のネイバーをポーリングラウンド 2 に設定した場合、ポーリングラウンド 1 のすべてのネイバーが最初に照会され、どのネイバーも「HIT」を返さない場合、ラウンド 2 のすべてのプロキシが照会されます。ポーリングラウンドの最大回数は 2 です。

ICP の parent はネットワークのボトルネックになりやすいため、ポーリングラウンドを使用して負荷を軽減できます。一般的な設定では、すべての sibling をポーリングラウンド 1 に設定し、すべての parent をポーリングラウンド 2 に設定します。このようにすることで、ローカルプロキシが URL を要求した場合、要求はまず隣接内のすべての sibling に照会されます。どの sibling にも要求された URL が存在しない場合、要求は parent に照会されます。parent にも URL が存在しない場合、ローカルプロキシはリモートサーバーから URL を取得します。

隣接 ICP の各ネイバーは、少なくとも 1 台の ICP サーバーを稼働させている必要があります。ネイバーが ICP サーバーを稼働させていない場合、ネイバーからの ICP 要求に答えることができません。プロキシサーバーで ICP を有効にすると、まだ稼働していない場合は、ICP サーバーが起動されます。

ICP を設定するには

隣接 ICP に parent を追加します。この手順は、隣接 ICP に parent が必要な場合にのみ実行します。隣接 ICP への parent の追加については、「隣接 ICP への Parent の追加」を参照してください。

隣接 ICP に sibling を追加します。隣接 ICP への sibling の追加については、「隣接 ICP への Sibling の追加」を参照してください。

隣接 ICP の各ネイバーを設定します。隣接 ICP の設定については、「個々の隣接 ICP の設定」を参照してください。

ICP を有効にします。ICP の有効化については、「ICP の有効化」を参照してください。

プロキシの隣接 ICP に sibling または parent がある場合、隣接 ICP を経由したルーティングを有効にします。隣接 ICP を経由したルーティングについては、「隣接 ICP を経由したルーティングの有効化」を参照してください。

隣接 ICP への Parent の追加

隣接 ICP に parent プロキシを追加するには

サーバーマネージャーにアクセスし、「Caching」タブをクリックします。

「Configure ICP」リンクをクリックします。「Configure ICP」ページが表示されます。

このページの「Parent List」セクションで、「Add」ボタンをクリックします。「ICP Parent」ページが表示されます。

「Machine Address」フィールドに、隣接 ICP に追加する parent プロキシの IP アドレスまたはホスト名を入力します。

「ICP Port」フィールドに、parent プロキシが ICP メッセージを待機するポート番号を入力します。

「Multicast Address」フィールドに、parent が待機するマルチキャストアドレスを入力できます。マルチキャストアドレスは、複数のサーバーが待機できる IP アドレスです。マルチキャストアドレスを使用することによって、そのマルチキャストアドレスを待機しているすべてのネイバーで表示できるネットワークに対して、プロキシから 1 つのクエリーを送信することができます。そのため、各ネイバーに個別にクエリーを送信する必要がなくなります。マルチキャストの使用はオプションです。



注	別のポーリングラウンドのネイバーは、同じマルチキャストアドレスを待機できません。

「TTL」フィールドに、マルチキャストメッセージが転送されるサブネットの数を入力します。TTL を 1 に設定すると、マルチキャストメッセージはローカルサブネットにのみ転送されます。TTL を 2 に設定すると、メッセージは、1 レベル先のすべてのサブネットに送信され、3 の場合は 2 レベル先のように拡大されます。



注	マルチキャストを使用した場合、2 つの関連性のないネイバーで相互に ICP メッセージを送信することができます。したがって、隣接 ICP のプロキシからの ICP メッセージを関連性のないネイバーに受け取られるのを防ぐ場合は、「TTL」フィールドの TTL の値を低く設定することをお勧めします。

「Proxy Port」フィールドに、parent のプロキシサーバー用のポートを入力します。

「Polling Round」ドロップダウンリストから、parent に割り当てるポーリングラウンドを選択します。デフォルトのポーリングラウンドは 1 です。

「了解」をクリックします。

「Restart Required」をクリックします。「Apply Changes」ページが表示されます。

「Restart Proxy Server」ボタンをクリックして、変更を適用します。

隣接 ICP の Parent 設定の編集

parent 設定を編集するには

サーバーマネージャーにアクセスし、「Caching」タブをクリックします。

「Configure ICP」リンクを選択します。「Configure ICP」ページが表示されます。

編集する parent の横のラジオボタンをクリックします。

「Edit」ボタンをクリックします。

該当する情報を変更します。

「了解」をクリックします。

「Restart Required」をクリックします。「Apply Changes」ページが表示されます。

「Restart Proxy Server」ボタンをクリックして、変更を適用します。

隣接 ICP からの Parent の削除

隣接 ICP から parent プロキシを削除するには

サーバーマネージャーにアクセスし、「Caching」タブをクリックします。

「Configure ICP」リンクを選択します。「Configure ICP」ページが表示されます。

削除する parent の横のラジオボタンをクリックします。

「Remove」ボタンをクリックします。

「Restart Required」をクリックします。「Apply Changes」ページが表示されます。

「Restart Proxy Server」ボタンをクリックして、変更を適用します。

隣接 ICP への Sibling の追加

隣接 ICP に sibling プロキシを追加するには

サーバーマネージャーにアクセスし、「Caching」タブをクリックします。

「Configure ICP」リンクを選択します。「Configure ICP」ページが表示されます。

このページの「Sibling List」セクションで、「Add」ボタンをクリックします。「ICP Sibling」ページが表示されます。

「Machine Address」フィールドに、隣接 ICP に追加する sibling プロキシの IP アドレスまたはホスト名を入力します。

「ポート」フィールドに、sibling プロキシが ICP メッセージを待機するポート番号を入力します。

「Multicast Address」フィールドに、sibling が待機するマルチキャストアドレスを入力します。マルチキャストアドレスは、複数のサーバーが待機できる IP アドレスです。マルチキャストアドレスを使用することによって、そのマルチキャストアドレスを待機しているすべてのネイバーで表示できるネットワークに対して、プロキシから 1 つのクエリーを送信することができます。そのため、各ネイバーに個別にクエリーを送信する必要がなくなります。



注	別のポーリングラウンドのネイバーは、同じマルチキャストアドレスを待機できません。

「TTL」フィールドに、マルチキャストメッセージが転送されるサブネットの数を入力します。TTL を 1 に設定すると、マルチキャストメッセージはローカルサブネットにのみ転送されます。TTL を 2 に設定すると、メッセージは、1 レベル先のすべてのサブネットに送信されます。



注	マルチキャストを使用した場合、2 つの関連性のないネイバーで相互に ICP メッセージを送信することができます。したがって、隣接 ICP のプロキシからの ICP メッセージを関連性のないネイバーに受け取られるのを防ぐ場合は、「TTL」フィールドの TTL の値を低く設定することをお勧めします。

「Proxy Port」フィールドに、sibling のプロキシサーバーのポートを入力します。

「Polling Round」ドロップダウンリストから、sibling に割り当てるポーリングラウンドを選択します。デフォルトのポーリングラウンドは 1 です。

「了解」をクリックします。

「Restart Required」をクリックします。「Apply Changes」ページが表示されます。

「Restart Proxy Server」ボタンをクリックして、変更を適用します。

隣接 ICP の Sibling 設定の編集

sibling 設定を編集するには

サーバーマネージャーにアクセスし、「Caching」タブをクリックします。

「Configure ICP」リンクを選択します。「Configure ICP」ページが表示されます。

編集する sibling の横のラジオボタンをクリックします。

「Edit」ボタンをクリックします。

該当する情報を変更します。

「了解」をクリックします。

「Restart Required」をクリックします。「Apply Changes」ページが表示されます。

「Restart Proxy Server」ボタンをクリックして、変更を適用します。

隣接 ICP からの Sibling の削除

隣接 ICP から sibling プロキシを削除するには

サーバーマネージャーにアクセスし、「Caching」タブをクリックします。

「Configure ICP」リンクを選択します。「Configure ICP」ページが表示されます。

削除する sibling の横のラジオボタンをクリックします。

「Remove」ボタンをクリックします。

「Restart Required」をクリックします。「Apply Changes」ページが表示されます。

「Restart Proxy Server」ボタンをクリックして、変更を適用します。

個々の隣接 ICP の設定

隣接 ICP では各ネイバー、すなわちローカルプロキシを設定する必要があります。

隣接 ICP でローカルプロキシサーバーを設定するには

サーバーマネージャーにアクセスし、「Caching」タブをクリックします。

「Configure ICP」リンクを選択します。「Configure ICP」ページが表示されます。

「Binding Address」フィールドに、隣接サーバーがバインドする IP アドレスを入力します。

「ポート」フィールドに、隣接サーバーが ICP を待機するポート番号を入力します。

「Multicast Address」フィールドに、ネイバーが待機するマルチキャストアドレスを入力します。マルチキャストアドレスは、複数のサーバーが待機できる IP アドレスです。マルチキャストアドレスを使用することによって、そのマルチキャストアドレスを待機しているすべてのネイバーで表示できるネットワークに対して、プロキシから 1 つのクエリーを送信することができます。そのため、各ネイバーに個別にクエリーを送信する必要がなくなります。

ネイバーにマルチキャストアドレスとバインドアドレスの両方が指定されている場合、ネイバーは、応答の送信にはバインドアドレスを使用し、待機にはマルチキャストを使用します。バインドアドレスもマルチキャストアドレスも指定されない場合、オペレーティングシステムによりデータの送信に使用するアドレスが決定されます。

「Default Route」フィールドに、隣接するプロキシが「HIT」を応答しない場合にネイバーが応答をルーティングするプロキシの名前または IP アドレスを入力します。このフィールドに「origin」と入力した場合、または空白のままにした場合、デフォルト経路で配信元サーバーにルーティングされます。



注	「No Hit Behavior」ドロップダウンリストから「最初に応答する parent」を選択した場合、「Default Route」フィールドに入力した経路は無効になります。プロキシがこの経路を使用するのは、デフォルトのヒット動作なしを選択した場合のみです。

2 つ目の「ポート」フィールドに、「Default Route」フィールドに入力したデフォルト経路のマシンのポート番号を入力します。

「On No Hits, Route Through」ドロップダウンリストから、隣接 ICP のどの sibling もキャッシュ内に要求された URL がない場合のネイバーの動作を選択します。次から選択できます。

「first responding parent」: ネイバーは最初に「miss」で応答する parent から、要求された URL を取得します。

「デフォルトルート」: ネイバーは、「Default Route」フィールドに指定されたマシンから、要求された URL を取得します。

「Server Count」フィールドに、ICP 要求を処理するプロセス数を入力します。

「Timeout」フィールドに、各ラウンドでネイバーが ICP 応答を待機する最大時間を入力します。

「了解」をクリックします。

「Restart Required」をクリックします。「Apply Changes」ページが表示されます。

「Restart Proxy Server」ボタンをクリックして、変更を適用します。

ICP の有効化

ICP を有効にするには

サーバーマネージャーにアクセスし、「Preferences」タブをクリックします。

「Configure System Preferences」リンクをクリックします。「Configure System Preferences」ページが表示されます。

ICP の「Yes」ラジオボタンを選択します。

「了解」をクリックします。

「Restart Required」をクリックします。「Apply Changes」ページが表示されます。

「Restart Proxy Server」ボタンをクリックして、変更を適用します。

隣接 ICP を経由したルーティングの有効化

隣接 ICP を経由したルーティングを有効にするには

サーバーマネージャーにアクセスし、「Routing」タブをクリックします。

「Set Routing Preferences」リンクをクリックします。「Set Routing Preferences」ページが表示されます。

ドロップダウンリストからリソースを選択するか、「Regular Expression」ボタンをクリックして正規表現を入力し、「了解」をクリックします。

テキスト「Route Through」の横のラジオボタンを選択します。

ICP の横のチェックボックスを選択します。

クライアントが別のネイバーを経由してドキュメントを取得するのではなく、そのドキュメントを持つ隣接 ICP から直接ドキュメントを取得するように設定する場合は、テキスト「redirect」の横のチェックボックスを選択します。

「了解」をクリックします。



警告	現在リダイレクトはどのクライアントでもサポートされていないため、今回はこの機能を使用しないでください。



注	隣接 ICP を経由したルーティングを有効にする必要があるのは、プロキシが隣接 ICP にほかの sibling または parent を持っている場合のみです。プロキシが別のプロキシの parent であり、独自の sibling または parent を持っていない場合、そのプロキシに対してのみ ICP を有効にする必要があります。隣接 ICP を経由したルーティングを有効にする必要はありません。

「Restart Required」をクリックします。「Apply Changes」ページが表示されます。

「Restart Proxy Server」ボタンをクリックして、変更を適用します。

プロキシ配列の使用

プロキシ配列について

分散キャッシュのためにプロキシ配列を使用すると、複数のプロキシが 1 つのキャッシュとして機能します。つまり、配列内の各プロキシに、ブラウザまたはダウンストリームのプロキシサーバーにより取得可能な、さまざまなキャッシュ URL が格納されます。プロキシ配列を使用すると、複数のプロキシサーバーを使用するとしばしば発生する、キャッシュの重複を避けることができます。ハッシュベースのルーティングを通じて、プロキシ配列はプロキシ配列内の正しいキャッシュに要求をルーティングします。

またプロキシ配列では、増分スケーラビリティが可能です。つまり、プロキシ配列へのプロキシの追加を決定した場合、各メンバーのキャッシュは無効になりません。各メンバーのキャッシュ内の 1/n の URL のみが、ほかのメンバーに再割り当てされます (n は配列のプロキシの数)。

プロキシ配列を経由したルーティング

プロキシ配列からの各要求について、ハッシュ機能は配列内の各プロキシに、要求された URL、プロキシ名、およびプロキシの負荷要因に基づくスコアを割り当てます。要求はスコアが最も高いプロキシにルーティングされます。

URL の要求はクライアントとプロキシの両方から送られるため、プロキシ配列を経由するルーティングには 2 種類あります。クライアントからプロキシへのルーティングとプロキシからプロキシへのルーティングです。

クライアントからプロキシへのルーティングでは、クライアントはプロキシ自動設定 (Proxy Auto Configuration、PAC) メカニズムを使用して、経由するプロキシを決定します。ただし、標準の PAC ファイルを使用する代わりに、クライアントは、ハッシュアルゴリズムを計算する特別な PAC ファイルを使用し、要求された URL に適切な経路を決定します。図 12-4 は、クライアントからプロキシへのルーティングを示しています。

図 12-4 では、プロキシ配列の各メンバーがロードされ、マスタープロキシに対してPAT ファイルに加えられた更新をポーリングします。PAC ファイルを取得したクライアントに必要となるのは、設定が変更されるたびにこのファイルをダウンロードすることだけです。通常、クライアントは再起動時に PAC ファイルをダウンロードします。

プロキシサーバーは、管理インタフェースから作成された Proxy Array Membership Table (PAT) 仕様に基づいて特別な PAC ファイルを自動的に生成できます。

プロキシからプロキシへのルーティングでは、プロキシはクライアントが使用する PAC ファイルの代わりに、PAT (Proxy Array Table) ファイルを使用してハッシュアルゴリズムを計算します。PAT ファイルは、プロキシのマシン名、IP アドレス、ポート、負荷要因、キャッシュサイズなどを含むプロキシ配列に関する情報を格納した ASCII ファイルです。サーバー側でハッシュアルゴリズムを計算する場合、PAC ファイル (実行時に解釈が必要な JavaScript ファイル) よりも PAT ファイルを使用する方がより効率的です。ただし、ほとんどのクライアントは PAT ファイル形式を認識しません。このため、PAC ファイルを使用する必要があります。図 12-5 は、プロキシからプロキシへのルーティングを示しています。

PAT ファイルは、プロキシ配列の 1 つのプロキシ、マスタープロキシで作成されます。プロキシの管理者は、マスタープロキシにするプロキシを決定する必要があります。管理者はこのマスタープロキシサーバーから PAT ファイルを変更できます。プロキシ配列のほかのメンバーはすべて、手動または自動によるポーリングで、マスタープロキシのこれらの変更を調査できます。これらの変更に基づき、PAC ファイルを自動的に生成するように各メンバーを設定できます。

また、プロキシ配列を連鎖して、階層ルーティングを作成することもできます。プロキシサーバーが受信した要求を上流のプロキシ配列にルーティングする場合、上流のプロキシ配列は親配列となります。親配列とは、プロキシサーバーを経由するプロキシ配列のことです。つまり、クライアントがプロキシ X のドキュメントを要求し、プロキシ X にそのドキュメントがない場合、クライアントは直接リモートサーバーに要求を送信する代わりに、プロキシ配列 Y に要求を送信します。このため、プロキシ配列 Y が親配列になります。図 12-5 では、プロキシ配列 1 がプロキシ配列 2 の親配列です。プロキシ配列 2 のメンバーがロードされ、親配列の PAT ファイルに加えられた更新をポーリングします。通常は、親配列のマスタープロキシに対してポーリングします。要求された URL のハッシュアルゴリズムがダウンロードした PAT ファイルを使用して計算されると、プロキシ配列 2 のメンバーはプロキシ配列 1 の中で最もスコアの高いプロキシを通して要求された URL を取得します。図 12-5 では、クライアントから要求された URL に関して最もスコアが高いのはプロキシ B です。

プロキシ配列を設定するには

マスタープロキシから、次の手順を実行します。

プロキシ配列を作成します。メンバーリストの作成については、「プロキシ配列メンバーリストの作成」を参照してください。

PAT ファイルから PAC ファイルを生成します。PAC ファイルを生成する必要があるのは、クライアントからプロキシへのルーティングを使用する場合のみです。PAT ファイルから PAC ファイルを生成する方法については、「PAT ファイルからの PAC ファイルの生成」を参照してください。

配列のマスターメンバーを設定します。マスターメンバーの設定については、「プロキシ配列メンバーの設定」を参照してください。

プロキシ配列を経由したルーティングを有効にします。プロキシ配列を経由したルーティングの有効化については、「プロキシ配列を経由したルーティングの有効化」を参照してください。

URL「/pat」を PAT ファイルにマップする PAT マッピングを作成します。

プロキシ配列を有効にします。プロキシ配列の有効化については、「プロキシ配列の有効化」を参照してください。

マスター以外の各プロキシから、次の手順を実行します。

配列のマスター以外のメンバーを設定します。マスター以外のメンバーの設定については、「プロキシ配列メンバーの設定」を参照してください。

プロキシ配列を有効にします。プロキシ配列の有効化については、「プロキシ配列の有効化」を参照してください。



注	プロキシ配列が親配列を経由してルーティングされる場合、親配列を有効にし、各メンバーが親配列を経由して要求される URL にルーティングされるように設定する必要があります。親配列については、「親配列を経由したルーティング」を参照してください。

プロキシ配列メンバーリストの作成

プロキシ配列のメンバーリストの作成および更新は、配列のマスタープロキシからのみ行うことができます。プロキシ配列のメンバーリストは 1 度だけ作成する必要がありますが、いつでも変更できます。プロキシ配列のメンバーリストを作成することにより、配列内のすべてのプロキシおよびダウンストリームのプロキシに配布される PAT ファイルが生成されます。


警告	プロキシ配列のメンバーリストへの変更または追加は、配列内のマスタープロキシからのみ実行します。配列内のほかのメンバーはすべて、メンバーリストの読み込みのみ可能です。

サーバーマネージャーにアクセスし、「Caching」タブをクリックします。

「Configure Proxy Array」リンクをクリックします。「Configure Proxy Array」ページが表示されます。

「Array name」フィールドに、配列の名前を入力します。

「Reload Configuration Every」フィールドに、PAT ファイルのポーリング間隔を分で入力します。

「Array Enabled」チェックボックスをクリックします。

「Create」ボタンをクリックします。



注	メンバーをメンバーリストに追加する前に、必ず「了解」をクリックしてください。



注	「Create」ボタンは、プロキシ配列が作成されたあと、「了解」ボタンに変わります。

「Restart Required」をクリックします。「Apply Changes」ページが表示されます。

プロキシ配列の各メンバーについて、次の内容を入力し、「了解」をクリックします。

「Name」: メンバーリストに追加するプロキシサーバーの名前。

「IP Address」: メンバーリストに追加するプロキシサーバーの IP アドレス。

ポート: メンバーが PAT ファイルをポーリングするポート。

「Load Factor」: メンバーへのルーティングが必要な相対負荷を反映する整数。

「状態」: メンバーの状態。値はオンまたはオフ。プロキシ配列メンバーを無効にした場合、メンバーの要求は別のメンバーに再ルーティングされます。



注	最初にマスターメンバーを追加してから、ほかのメンバーを追加してください。



注	追加するプロキシ配列メンバーごとに情報を入力したあと、必ず「了解」をクリックしてください。

「Restart Required」をクリックします。「Apply Changes」ページが表示されます。

「Restart Proxy Server」ボタンをクリックして、変更を適用します。

プロキシ配列メンバーリスト情報の編集

プロキシ配列メンバーリスト内のメンバー情報は、いつでも変更できます。プロキシ配列メンバーリストは、マスタープロキシからのみ編集できます。

プロキシ配列のメンバーについてメンバーリスト情報を編集するには


警告	プロキシ配列のメンバーリストへの変更または追加は、配列内のマスタープロキシからのみ実行します。配列のほかのメンバーからこのリストを変更した場合、すべての変更内容は失われます。

サーバーマネージャーにアクセスし、「Caching」タブをクリックします。

「Configure Proxy Array」リンクをクリックします。「Configure Proxy Array」ページが表示されます。

「Member List」で、編集するメンバーの横のラジオボタンを選択します。

「Edit」ボタンをクリックします。「Configure Proxy Array Member」ページが表示されます。

該当する情報を編集します。

「了解」をクリックします。

「Restart Required」をクリックします。「Apply Changes」ページが表示されます。

「Restart Proxy Server」ボタンをクリックして、変更を適用します。



注	変更内容を有効にし、プロキシ配列のメンバーに配布する場合、「Configure Proxy Array」ページの「configuration ID」を更新し、「了解」をクリックします。設定 ID を更新する場合、ID に 1 を加えます。

プロキシ配列メンバーの削除

プロキシ配列のメンバーを削除すると、プロキシ配列から削除されます。プロキシ配列のメンバーは、マスタープロキシからのみ削除できます。

プロキシ配列からメンバーを削除するには


警告	プロキシ配列のメンバーリストへの変更または追加は、配列内のマスタープロキシからのみ実行します。配列のほかのメンバーからこのリストを変更した場合、すべての変更内容は失われます。

サーバーマネージャーにアクセスし、「Caching」タブをクリックします。

「Configure Proxy Array」リンクをクリックします。「Configure Proxy Array」ページが表示されます。

「Member List」で、削除するメンバーの横のラジオボタンを選択します。

「Remove」ボタンをクリックします。



注	変更内容を有効にし、プロキシ配列のメンバーに配布する場合、「Configure Proxy Array」ページの「configuration ID」を更新し、「了解」をクリックします。設定 ID を更新する場合、ID に 1 を加えます。

「Restart Required」をクリックします。「Apply Changes」ページが表示されます。

「Restart Proxy Server」ボタンをクリックして、変更を適用します。

プロキシ配列メンバーの設定

プロキシ配列内のメンバーは 1 度だけ設定する必要があります。これは各メンバーから行います。配列のメンバーの設定は、別のメンバーからは行うことができません。また、マスタープロキシを設定する必要があります。

プロキシ配列の各メンバーを設定するには

サーバーマネージャーにアクセスし、「Caching」タブをクリックします。

「Configure Proxy Array Member」リンクをクリックします。「Configure Proxy Array Member」ページが表示されます。

「Proxy Array」セクションで、適切なラジオボタンを選択し、メンバーが PAT ファイルをポーリングする必要があるかどうかを指定します。次の中から選択します。

Non-Master Member: 設定するメンバーがマスタープロキシ以外の場合、このオプションを選択します。マスタープロキシ以外のプロキシ配列メンバーは、マスタープロキシから PAT ファイルを取得するために、PAT ファイルをポーリングする必要があります。

「Master Member」: マスタープロキシを設定する場合、このオプションを選択します。マスタープロキシを設定する場合、PAT ファイルはローカルのため、ポーリングする必要はありません。

「Poll Host」フィールドに、PAT ファイルをポーリングするマスタープロキシの名前を入力します。

「ポート」フィールドに、マスタープロキシが HTTP 要求を受け取るポートを入力します。

「URL」フィールドに、マスタープロキシの PAT ファイルの URL を入力します。マスタープロキシで、PAT ファイルを URL /pat にマッピングする PAT マッピングを作成している場合、「URL」フィールドに /pat と入力します。

「Headers File」フィールドに、PAT ファイルに対する HTTP 要求 (認証情報など) とともに送信する必要がある特殊ヘッダー付きのファイルのフルパス名を入力します。このフィールドはオプションです。

「了解」をクリックします。

「Restart Required」をクリックします。「Apply Changes」ページが表示されます。

「Restart Proxy Server」ボタンをクリックして、変更を適用します。

プロキシ配列を経由したルーティングの有効化

プロキシ配列を経由したルーティングを有効にするには

サーバーマネージャーにアクセスし、「Routing」タブをクリックします。

「Set Routing Preferences」リンクをクリックします。「Set Routing Preferences」ページが表示されます。

ドロップダウンリストからリソースを選択するか、「Regular Expression」ボタンをクリックして正規表現を入力し、「了解」をクリックします。

「Route Through」オプションを選択します。

「proxy array」と「parent array」の両方、またはいずれかのチェックボックスを選択します。

プロキシ配列経由でルーティングし、要求を別の URL にリダイレクトする場合、「redirect」チェックボックスを選択します。リダイレクトは、プロキシ配列のメンバーが処理できない要求を受け取った場合、クライアントに、その要求を照会するプロキシを伝えることを意味します。

「了解」をクリックします。



注	設定するプロキシサーバーがプロキシ配列のメンバーである場合のみ、プロキシ配列のルーティングを有効にできます。親配列が存在する場合、親ルーティングのみを有効にできます。いずれのルーティングオプションも、独立して使用されます。



警告	現在リダイレクトはどのクライアントでもサポートされていないため、今回はこの機能を使用しないでください。

「Restart Required」をクリックします。「Apply Changes」ページが表示されます。

「Restart Proxy Server」ボタンをクリックして、変更を適用します。

プロキシ配列の有効化

プロキシ配列を有効にするには

サーバーマネージャーにアクセスし、「Preferences」タブをクリックします。

「Configure System Preferences」リンクをクリックします。「Configure System Preferences」ページが表示されます。

有効にする配列の種類、すなわち通常の「proxy array」または「parent array」のいずれかで「Yes」オプションをクリックします。

「了解」をクリックします。



注	プロキシ配列を経由したルーティングを行わない場合、プロキシ配列オプションを無効にする前に、すべてのクライアントが特別な PAC ファイルを使用して正しくルーティングしていることを確認する必要があります。親配列オプションを無効にする場合、「Set Routing Preferences」ページで、明示的プロキシまたは直接接続など、有効な代替ルーティングオプションを設定する必要があります。

「Restart Required」をクリックします。「Apply Changes」ページが表示されます。

「Restart Proxy Server」ボタンをクリックして、変更を適用します。

プロキシ配列の要求のリダイレクト

プロキシ配列経由のルーティングを選択する場合、要求を別の URL にリダイレクトするかどうかを指定する必要があります。リダイレクトは、プロキシ配列のメンバーが処理できない要求を受け取った場合、クライアントに、その要求を照会するプロキシを伝えることを意味します。

PAT ファイルからの PAC ファイルの生成

ほとんどのクライアントは PAT ファイル形式を認識しないため、クライアントからプロキシへのルーティングを使用するクライアントはプロキシ自動設定 (PAC) メカニズムを使用して、どのプロキシを経由するかについての情報を受け取ります。ただし、標準の PAC ファイルを使用する代わりに、クライアントは PAT ファイルから生成された特別な PAC ファイルを使用します。この特別な PAC ファイルは、ハッシュアルゴリズムを計算して、要求された URL に最適な経路を決定します。

PAC ファイルは、PAT ファイルから手動で、または自動的に生成できます。プロキシ配列の特定のメンバーから手動で PAC ファイルを生成する場合、そのメンバーは PAT ファイルの現在の情報に基づいてただちに PAC ファイルを再生成します。プロキシ配列メンバーにPAC ファイルの自動生成を設定する場合、PAT ファイルが変更されたことを検出するたびに、メンバーは自動的にファイルを再生成します。

PAT ファイルからの PAC ファイルの手動生成

PAT ファイルから PAC ファイルを手動で生成するには


警告	現在リダイレクトはどのクライアントでもサポートされていないため、今回はこの機能を使用しないでください。


注	プロキシサーバーのプロキシ配列機能を使用していない場合、「Create / Edit Autoconfiguration File」ページを使用して PAC ファイルを生成する必要があります。詳細は、「クライアント自動設定ファイルの使用」を参照してください。


注	PAC ファイルは、マスタープロキシからのみ生成できます。

マスタープロキシのサーバーマネージャーにアクセスし、「Caching」タブをクリックします。

「Configure Proxy Array」リンクをクリックします。「Configure Proxy Array」ページが表示されます。

「Generate PAC」ボタンをクリックします。「PAC Generation」ページが表示されます。

PAC ファイルでカスタムロジックを使用する場合、「Custom logic file」フィールドに、PAC ファイルの生成時に組み込むカスタムロジックを含むファイル名を入力します。このロジックは、FindProxyForURL 関数のプロキシ配列の選択ロジックの前に挿入されます。この関数は、通常はプロキシ配列を経由する必要のないローカル要求で使用されます。

「Configure Proxy Array Member」ページですでにカスタムロジックファイルを入力している場合、このフィールドにはその情報が表示されます。必要に応じてカスタムロジックファイルの名前を編集できます。変更内容は「Configure Proxy Array Member」ページにも転送されます。

「Default Route」フィールドに、配列内のプロキシが利用できないときにクライアントが利用する経路を入力します。

「Configure Proxy Array Member」ページですでにデフォルト経路を入力している場合、このフィールドにはその情報が表示されます。必要に応じてデフォルト経路を編集できます。変更内容は「Configure Proxy Array Member」ページにも転送されます。

「了解」をクリックします。

「Restart Required」をクリックします。「Apply Changes」ページが表示されます。

「Restart Proxy Server」ボタンをクリックして、変更を適用します。

PAT ファイルからの PAC ファイルの自動生成

変更が検出されるたびに PAT ファイルから PAC ファイルを自動生成するには

サーバーマネージャーにアクセスし、「Caching」タブをクリックします。

「Configure Proxy Array Member」リンクをクリックします。「Configure Proxy Array Member」ページが表示されます。

「Auto-generate PAC File」チェックボックスを選択します。

PAC ファイルでカスタムロジックを使用する場合、「Custom Logic File」フィールドに、PAC ファイルの生成時に組み込むカスタムロジックを含むファイル名を入力します。このロジックは、FindProxyForURL 関数のプロキシ配列の選択ロジックの前に挿入されます。

「Configure Proxy Array」ページですでにカスタムロジックファイルを入力、保存している場合、このフィールドにはその情報が表示されます。必要に応じてカスタムロジックファイルの名前を編集できます。変更内容は「Configure Proxy Array」ページにも転送されます。

「Default Route」フィールドに、配列内のプロキシが利用できないときにクライアントが利用する経路を入力します。

「Configure Proxy Array」ページですでにデフォルト経路を入力、保存している場合、このフィールドにはその情報が表示されます。必要に応じてデフォルト経路を編集できます。変更内容は「Configure Proxy Array」ページにも転送されます。

「了解」をクリックします。

「Restart Required」をクリックします。「Apply Changes」ページが表示されます。

「Restart Proxy Server」ボタンをクリックして、変更を適用します。

親配列を経由したルーティング

直接リモートサーバーに接続する代わりに、上流の親配列を経由してルーティングするよう、プロキシまたはプロキシ配列のメンバーを設定できます。

親配列を経由したルーティングをプロキシまたはプロキシ配列のメンバーに設定するには

親配列を有効にします。配列の有効化については、「プロキシ配列の有効化」を参照してください。

親配列を経由するルーティングを有効にします。配列を経由したルーティングの有効化については、「プロキシ配列を経由したルーティングの有効化」を参照してください。

サーバーマネージャーにアクセスし、「Caching」タブをクリックします。

「Configure Proxy Array Member」リンクをクリックします。「Configure Proxy Array Member」ページが表示されます。

このページの「Parent Array」セクションにある「Poll Host」フィールドに、PAT ファイルをポーリングする親配列にあるプロキシのホスト名を入力します。このプロキシは、通常、親配列のマスタープロキシになります。

このページの「Parent Array」セクションにある「ポート」フィールドに、PAT ファイルをポーリングする親配列にあるプロキシのポート番号を入力します。

「URL」フィールドに、マスタープロキシの PAT ファイルの URL を入力します。マスタープロキシで PAT マッピングを作成している場合、この「URL」フィールドにマッピングを入力する必要があります。

このフォームの「Parent Array」セクションにある「Headers File」フィールドに、PAT ファイルに対する HTTP 要求 (認証情報など) とともに送信する必要がある特殊ヘッダー付きのファイルのフルパス名を入力します。このフィールドはオプションです。

「了解」をクリックします。

「Restart Required」をクリックします。「Apply Changes」ページが表示されます。

「Restart Proxy Server」ボタンをクリックして、変更を適用します。

親配列情報の表示

プロキシ配列が親配列経由でルーティングする場合、親配列のメンバーの情報が必要です。この情報は PAT ファイルの形式で親配列から送信されます。この PAT ファイルの情報は、「View Parent Array Configuration」ページに表示されます。

前へ目次索引次へ
Sun Java System Web Proxy Server 4.0.1 管理ガイド