アプリケーション ネットワーキング サービス : Cisco CSS 11500 ???? Content Services Switches

CSS 11000 のキャッシング設定と互換性に関する考慮事項

2005 年 2 月 23 日 - ライター翻訳版
その他のバージョン: PDFpdf | 機械翻訳版 (2013 年 8 月 21 日) | 英語版 (2007 年 12 月 27 日) | フィードバック

目次

概要
前提条件
      要件
      使用するコンポーネント
      表記法
キャッシュの設定
      レイヤ 2 スイッチとフロー スイッチ
      ルーティング
      サービス
      レイヤ 4 とレイヤ 5
      非対称性
      バランス
      フェールオーバー
      EQL バイパス
      キャッシュのバイパス
      URL パラメータのバイパス機能
      プレフェッチ機能
関連するシスコ サポート コミュニティ ディスカッション
関連情報

概要

この文書は、Cisco Content Services Switch(CSS; コンテンツ サービス スイッチ)11000/11500 を導入する際の、キャッシングと互換性に関する考慮事項を決定するためのガイドラインです。

前提条件

要件

この文書の読者は次の項目に関する知識が必要です。

  • キャッシュのデフォルトのゲートウェイは CSS であること。

使用するコンポーネント

この情報は、WebNS ソフトウェア リリース 3.0x 以降を実行している、すべての Cisco CSS(11000 および 11500)に適用できます。

この文書の情報は、特定のラボ環境にあるデバイスに基づいて作成されています。 この文書内で使用されているデバイスはすべて、クリアな状態(デフォルト)から設定作業を始めています。 対象のネットワークが実稼動中である場合には、すべてのコマンドによる潜在的な影響について確実に理解しておく必要があります。

表記法

文書の表記法の詳細は、『シスコ テクニカル ティップスの表記法』を参照してください。

キャッシュの設定

レイヤ 2 スイッチとフロー スイッチ

CSS はフロー スイッチであり、レイヤ 2(L2)スイッチとは異なります。 フロー スイッチでは、IP 情報を基にしてフローをポートにマップします。これに対して、L2 スイッチでは MAC レイヤ情報が基になります。 フロー スイッチの機能によって CSS はコンテンツ スマート スイッチになり、単なる転送フレームとは対照的に、TCP synchronize/start(SYN)パケットまたは HTTP GET を読み取ってコンテンツを決定できます。 キャッシング環境においては、フロー スイッチでは、クライアント宛のキャッシュから到達するすべてのパケットをルーティングする必要があります。

ルーティング

CSS はキャッシュのデフォルト ゲートウェイであり、キャッシュからのすべてのパケットをルーティングする必要があるため、CSS には完全なルーティング テーブルが必要です。

サービス

サービスを透過キャッシュ タイプとして設定する場合、CSS では宛先 MAC アドレスをキャッシュの MAC で書き換え、宛先の IP アドレスを保持するために、この IP パケットをキャッシュに転送します。 キャッシュがすべてのポート 80 トラフィックを無差別に受信できない場合は、キャッシュをプロキシ キャッシュ タイプに設定する必要があります。ただし、プロキシ キャッシュ サービスはバイパスのフェールオーバー方式を使用できません。 パケットをキャッシュに MAC 転送するため、キャッシュはこの装置に直接接続されている必要があります。 これができない場合は、クライアント接続またはインターネット接続と共有できない L2 デバイスを通じて、キャッシュを接続する必要があります。

サービスをプロキシ キャッシュまたは透過キャッシュとして設定している場合は、キャッシュの発信元の IP がすべてのコンテンツ ルールをバイパスするよう作成された自動不可視アクセスリスト(ACL)があるため、元のサーバからページを取得することができます。 WebNS バージョン 4.0 以降では、透過キャッシュ サービスおよびプロキシ キャッシュ サービスに対して no cache-bypass コマンドを入力して、コンテンツ ルールの自動バイパスを無効にすることができます。

各キャッシュがスイッチに直接接続されている場合を除いては、実稼働する CSS を 2 台設置して、それぞれにキャッシュ 1 つを直接接続し、透過キャッシュ タイプとして定義した場合に 2 つのキャッシュのロード バランスを行うことはできません。 一方のスイッチがクライアントからの要求を受信した後、その要求をもう一方のスイッチに接続されたキャッシュで処理するように決定する場合があります。しかし、もう一方のスイッチは、転送されてきた要求を読み取り、ルールと照合した結果、その要求を最初のスイッチに接続されたキャッシュで処理するものと決定する可能性があります。 これらのパケットは MAC 転送されるため、この状況を適切に処理する ACL を作成する方法はありません。

レイヤ 4 とレイヤ 5

情報がルールに一致する必要がある場合、またはロード バランシングの決定が TCP SYN ではなく HTTP GET で行われる場合は、ルールがレイヤ 5(L5)であると見なされます。したがって、URL、ドメインのバランス方式、ドメインのハッシュ、または URL のハッシュを追加する場合には、ルールは自動的に L5 になり、スプーフィングが誘発されます。 スプーフィングは、それが必要とされている状況でなくても、SYN フラッド攻撃からキャッシュを保護するため利点があります。 L5 設定では、Extension Qualifier List(EQL; 拡張子修飾子リスト)とフェールオーバーのバイパスの両方を許可するため、ボックスでは、キャッシュではなく、元のサーバとの接続をスプーフするようになります。 コンテンツ ルールが L5 と見なされている場合は、CSS がクライアントとの接続をスプーフしていることを意味します。

非対称性

CSS を経由しないで元のサーバからクライアントへ戻るルートがある場合は、非対称(トライアングレーション)であることになります。 L5 ルールを使用し、バイパスがある場合は、ボックスは元のサーバとの接続をスプーフし、リターン パスはクライアントに直接向かいます。この場合、クライアントはシーケンス番号を認識しないため、直ちに廃棄されます。 非対称性を修復して、すべてがキャッシュに送信されて、フェールオーバーをリニアに行うか、クライアントの IP を発信元のグループに Network Address Translation(NAT; ネットワーク アドレス変換)する NAT ピアリングを使用する必要があります。

バランス

ドメイン ハッシュと URL ハッシュのバランス方式を使用することを推奨します。 ドメイン ハッシュはホスト タグ全体にわたってハッシュ処理を実行し、そのドメインにサービスを提供するサーバを決定するため、負荷を均等に分散できます。 URL ハッシュ バランス方式もドメイン ハッシュ方式と同様に動作しますが、データ ソースとしてホスト タグの代わりに URL を使用します。

プロキシ キャッシュのサービス タイプを使用している場合は、最初の固定接続の GET をベースとしてバランスを実行し、2 度目の GET が同じルールに合致する限りは、再バランスは実行しません。これによって、一部のサイトの複製がキャッシュ上に作成されます(後述のプリフェッチのセクションを参照してください)。 WebNS 4.0 では、コンテンツ ルールにおいて no persistent コマンドを発行し、固定接続を解除して再バランスを実行するよう CSS を設定できます。 no persistent コマンドを発行する場合は、常に WebNS 4.0 の persistence reset remap コマンドも使用したくなります。 persistence reset コマンドは、固定接続を解除する方法を指定するために使用します。 デフォルトの方法は、固定接続のリセットとリダイレクトであり、これは CSS が TCP のリセットと HTTP 302 のリダイレクトをクライアントに送信し、クライアントに新たな接続の確立を強制するものです。 Internet Explorer(IE)5.0 には、同じドメインに戻る複数のリダイレクトを受信する、既知の問題があります。 persistence reset remap はクライアント接続を維持したまま、その接続をあるサーバから別のサーバへ背後で移動します。

フェールオーバー

コンテンツ ルールが透過キャッシュ タイプのサービスから構成されていて、キャッシング バランス方式のいずれかを使用している場合は、フェールオーバー バイパス方式を使用して、キャッシュに障害が発生したときに、そのキャッシュ宛ての要求を発信元サーバに転送できます。 前述の非対象性の問題を参照してください。

EQL バイパス

CSS には、キャッシュに送信するファイル拡張子のリストを設定できます。 このリストが EQL と呼ばれます。 コンテンツ ルールの URL 行の最後に EQL を追加すると、そのルールはリストにあるファイル拡張子を付けられた要求のみに一致します。 また、コンテンツ ルールの適用を変更することにより、EQL をバイパスするように CSS を設定できます。 WebNS 4.0 を使用しているときに、CSS によって固定接続における各要求を EQL に基づいて適切な宛先に配布させたい場合は、コンテンツ ルールにおいて no persistent コマンドを発行する必要があります。 コンテンツ ルールがバイパスされた後、キャッシュ可能な場合に、固定接続での次の GET をキャッシュに送信したい場合は、WebNS 4.0 の bypass persistence disable グローバル コマンドを発行する必要があります。 固定接続を解除する場合は、常に 4.0 の persistence reset remap グローバル コマンドを発行して、IE 5.0 による発行を回避します。

キャッシュのバイパス

バイパスするサイトのリストを設定するために使用できるキャッシュがあります。 CSS は、ほとんどのキャッシュのバイパス機能との互換性がありません。 CSS では Extension Qualifier List(EQL; 拡張子修飾子リスト)が設定可能で、これによって ACL 内の 1 つの句に追加できる IP アドレスまたはネットワークのリストを設定できます。

URL パラメータのバイパス機能

CSS は、パラメータを伴なうすべての URL を自動的にバイパスするように設定できます。 これらは、キャッシュでは対応できない要求です(たとえば、株価など)。

プレフェッチ機能

クライアントにキャッシュ サービスを提供している際、応答時間の最大の遅延を引き起こす不確定要素は、要求されたページがキャッシュ内に存在しないことです。キャッシュ内に存在しないときは、そのページをどこかから取得する必要があります。 キャッシュの負荷バランシングの目的は、キャッシュのヒット率を向上することです。 一部のキャッシュにはプリフェッチと呼ばれる機能があります。この機能を使用すると、最初の GET 要求から返されたデータをキャッシュが解析し、クライアントから明示的に要求される前に、そのページのオブジェクトを先行して取得できます。 これは、クライアントがそのページのロードを中止した場合、インターネット バックボーンを無駄に利用しますが、無視できる程度のトラフィック量です。

透過キャッシングを使用している場合に、CSS の EQL バイパス機能を使用すると、プリフェッチ アルゴリズムは機能しません。これは、デフォルトでは EQL にホームページ、つまり単なる「/.」の GET が含まれないためです。 サイトのメイン ホームページが含まれていなければ、プリフェッチのために処理するメインページがキャッシュ内に格納されません。 また、キャッシュに動的な要求を送信しない場合は、発信元サーバへの要求が CSS から 1 つ、およびキャッシュから 1 つ送られるため、要求が重複します。 お客様はそれぞれ目標を定め、各製品のどの機能を組み合せればよいかを決定する必要があります。

複数のキャッシュが配備されているサイトでは、一定のキャッシュ ヒットを確保するために、ロード バランサが最善を尽くすようにする必要があります。 CSS には、キャッシュのヒット数を最適化するよう設計された複数のロード バランシング アルゴリズムがあります。 このスイッチは L5 スイッチであるため、他のロード バランサでは見ることのできない HTTP GET の中の情報を見ることができます。 たとえば、要求を送る先のキャッシュを、要求されているドメイン名や URL に基づいて決めることができます。 ドメイン ハッシュ アルゴリズムを使用すると、ホスト タグが同じであるコンテンツの要求がすべて同じキャッシュに送信されるため、コンテンツがそのキャッシュ内に存在する確率が高くなります。 透過キャッシュでプリフェッチを使用する場合は、スイッチが要求をキャッシュに転送する前に、キャッシュが要求を取得しようとします。これにより、誤ったキャッシュがページを取得する可能性があります。 この場合は、プリフェッチを無効にできます。

プロキシ キャッシュの場合は、キャッシュ ヒット数を最適化する意味で、IP ヘッダー内に負荷バランシングにとって真に有効な情報はありません。宛先 IP アドレスは変更されないままです。 利用できそうな唯一の情報は送信元 IP アドレスですが、実際のところ、インターネット サーフィンに関して送信元 IP アドレスはまったく意味がありません。 スイッチは依然としてホスト タグと URL 情報を参照して、これらの決定を行います。 プロキシ キャッシュは通常はクライアントとの固定接続を維持するため、スイッチでは最初の HTTP GET と、同じキャッシュに送られる後続のすべての GET に基づいて、ロード バランシングの決定だけを行います。 固定接続を解除することはできないため、同じ接続に対する後続のすべての GET に対して、プリフェッチ機能とともに有効に動作します。 WebNS リリース 4.0 でこのような動作を実行したい場合は、no persistent コマンドを実行して、これらの接続を解除するよう CSS を設定できます。


関連するシスコ サポート コミュニティ ディスカッション

シスコ サポート コミュニティは、どなたでも投稿や回答ができる情報交換スペースです。


関連情報


Document ID: 12574