Cisco Global Site Selector CLI-Based グローバル サーバ ロード バランシング コンフィギュレーション ガイド Software Version 2.0

DNS ネーム サービス

ドメイン ネーム スペースに関する情報は、インターネット全体に分散しているネーム サーバに格納されます。各サーバは、ドメイン ネーム スペース全体の一部に関する詳細な情報を格納します。このスペースは DNS ゾーン と呼ばれ、ゾーン ファイルには、1 つのドメイン（mycompany.com）またはサブドメイン
（gslb.mycompany.com）に関する DNS 情報が含まれます。

DNS 情報はリソース レコードと呼ばれる情報系統に編成されます。リソース レコードは、ゾーンのグローバル プロパティおよびゾーンの一部であるホストまたはサービスを記述し、DNS ソフトウェアが使用できるように、バイナリ形式で内部に格納されます。ただし、リソース レコードは、ゾーン転送実行時に、テキスト形式でネットワーク全体に送信されます。

リソース レコードは、次の各種タイプのレコードで構成されています。

• Start of Authority（SOA）

• Name Service（NS）

• Address（A）

• Host Information（HINFO）

• Mail Exchange（MX）

• Canonical Name（CNAME）

• Pointer（PTR）

このマニュアルでは、主に SOA および NS レコード タイプについて説明します。その他サポートされているレコード タイプの詳細な説明およびリソース レコードの設定方法については、『 Cisco CNS Network Registrar User's Guide 』を参照してください。また、リソース レコードに関する詳細な背景情報については、RFC 1034 および 1035 を参照してください。

ここで説明する内容は、次のとおりです。

• SOA レコード

• ネガティブ キャッシング

• SOA レコードおよび負の応答

SOA レコード

トップレベル ドメインでは、ネーム データベースに、ドメイン内のデータについて最適な送信元を識別する Start of Authority（SOA）レコードが格納されている必要があります。また、SOA レコードは、DNS データベースの最新バージョンを格納し、特定の DNS サーバの動作を定義します。

個別に名前が割り当てられる各サブドメインでは、ネーム サーバ同士が NS レコードを使用して検出し合うため、対応する NS レコードが少なくとも 1 つ必要です。ゾーンは、別個の SOA を持つネーム スペースの領域であり、このレコードのフォーマットは、次の例のとおりです。

ネガティブ キャッシング

サーバは、ビジーな場合、毎秒数百または数千もの名前解決要求を処理する必要があります。これらの要求のそれぞれが解決されるまでに時間がかかり、リソースが消費されることから、DNS サーバ実装では、効率を向上させ、不要な名前解決要求を削減するメカニズムを使用することが不可欠です。また、このような要求により、ネットワーク間の帯域幅が消費され、ビジネスでデータを転送する帯域幅が奪われてしまいます。

キャッシングは、これらの効率化メカニズムで最も重要なものの 1 つです。キャッシングとは、最近取得された情報を再使用できるように、その情報を格納するために確保されたメモリの領のことです。DNS の場合、キャッシングは、DNS ネーム サーバが最近の名前解決およびその他の要求の結果を格納するために使用します。そのため、要求が再び発生した場合は、完全な名前解決プロセスを再度実行せずに、キャッシュから要求できます。詳細については、「要求解決」を参照してください。

ネガティブ キャッシングとは、実在しない特定の DNS レコードを保持するネーム サーバ内の機能のことです。ネガティブ キャッシングでは、負の結果が格納され、負の応答に対する応答時間が短縮されます。またネガティブ キャッシングにより、リゾルバとネーム サーバ間で送信されるメッセージ数も減るため、ネットワーク全体のトラフィック量が低減されます。ネガティブ キャッシュ状態を維持すると、ルックアップ試行が再試行された場合に、システムは迅速に障害状態を返すことができます。

SOA レコード内では、Time to Live（TTL; 存続可能時間）フィールドの数値により、ネーム サーバ同士がポーリングして更新された情報を取得する頻度を制御します。たとえば、TTL フィールドでは、データをキャッシュに入れる時間を決定するために、ネーム サーバが互いにポーリングする頻度を制御します。DNS では、TTL を持つ負の結果をネーム サーバが配布し、リゾルバがキャッシュすることができます。

DNS クエリーに対し、ネガティブ キャッシング内の情報にリソース レコード セット（RRset）が存在しない、ドメイン ネームが存在しない、または回答を提供できないなどの理由で負の応答を形成する場合には、SOA レコードの TTL が必要です。

（注） RRset は、同じラベル、クラス、およびタイプを含むものの、異なるデータを含んでいるレコードのグループです。

最も一般的な負の応答は、特定の RRset が DNS 内に存在しないことです。ネーム エラー（NXDOMAIN）の場合は、応答コード（RCODE）フィールドに name error が表示されます。また、NODATA の場合は、NOERROR に RCODE を持つ回答が送られ、answer セクションに関連する回答は表示されません。このような負の応答に対して、GSS は応答の authority セクションに、そのゾーンの SOA レコードを追加します。

SOA レコードおよび負の応答

SOA レコードを負の応答に含める必要がある場合、対応するネーム サーバは、GSS から SOA に対応するドメインを尋ねられます。この SOA 応答は、SOA レコードの最小フィールドで指定された期間キャッシュされます。この期間のすべての負の応答については、ネーム サーバに同じドメインを問い合わせるのではなく、キャッシュされた SOA レコードが使用されます。

（注） GSS v2.0 のデフォルト動作では、負の応答でクエリーに応答しますが、GSS v1.3.3 では、デフォルトで負のクエリーに応答しません。

GSS が SOA の取得に失敗する場合、負の応答は該当するエラー コードです。キャッシュされた SOA を使用すると、負の応答の TTL は、SOA がキャッシュされたときから秒単位で減少します。このプロセスは、キャッシング専用ネーム サーバがキャッシュされたレコードの TTL を減少させる方法に類似しています。

（注） GSS v2.0 にアップグレードすることを希望するが、新しい DNS 機能は必要なく、またクエリーに対してどのタイプの負の応答が返されても構わない場合、SOA 設定を追加して実行する必要はありません。このような場合、GSS は、要求に応答できないときに、タイプ 3 の負の応答を返します。この応答には SOA 情報は含まれていません。

SOA レコードを GSS で設定して否定回答で使用するには、ドメインおよびネーム サーバでホストされたドメインに対して権限ネーム サーバの IP アドレスを指定する NS 回答を設定する必要があります。詳細については、 の「回答グループの権限ドメインの追加または削除」を参照してください。

DNS 構造

特定のドメインまたはマシンのデータを必要とするエンド ユーザは、クライアント上で、ローカルな NS（ネーム サーバ）（別名、 D プロキシ ）に最初に送信される再帰 DNS 要求を生成します。D プロキシは、要求されたドメインの IP アドレスをエンド ユーザに返します。

DNS 構造は、一般的なファイル システムに類似した階層ツリー構造に基づいています。この構造での主なコンポーネントは、次のとおりです。

• DNS リゾルバ ― クライアント ネーム サーバにアクセスするクライアント。

• クライアント ネーム サーバ ― DNS ソフトウェアを実行するサーバ。DNS ソフトウェアは、要求された Web サイトを見つける役割を担います。クライアント ネーム サーバは、クライアント DNS プロキシ（D プロキシ）とも呼ばれます。

• ルート ネーム サーバ ― DNS 階層の最上位に常駐するサーバ。ルート ネーム サーバは、ホスト名でピリオドの後にあるすべての拡張子を識別します。多数のトップレベル ドメインがあり、最も一般的なトップレベル ドメインには、.org、.edu、.net、.gov、および .mil があります。全世界でおよそ 13 のルート サーバがすべてのインターネット要求を処理しています。

• 中間ネーム サーバ ― スケーリング目的で使用されるサーバ。ルート ネーム サーバに権限ネームサーバの IP アドレスがない場合、中間ネーム サーバに要求元のクライアント ネーム サーバが送信されます。そこで、中間ネーム サーバは、権限ネーム サーバにそのクライアント ネーム サーバを誘導します。

• 権限ネーム サーバ ― 企業によって運営されている、あるいはサービス プロバイダに委託されているサーバで、要求されたドメインに対する権限を持ちます。権限ネーム サーバは、要求された IP アドレスで（クライアントにではなく）直接クライアント ネーム サーバに応答します。

要求解決

エンド ユーザから要求された情報がローカル D プロキシ内に存在しない場合、D プロキシは、要求されたドメイン付近のドメインに対して権威があると判断したネーム サーバに反復要求を送信します。たとえば、www.cisco.com に対する要求があると、ローカル D プロキシは最初に www.cisco.com に対して権威のある別のネーム サーバがあるかを調べます。

図 1-2 に、クライアントが www.cisco.com の Web サイトにアクセスしようと試みるとき、IP アドレスを戻すために DNS 構造によって実行されるシーケンスを要約します。

図 1-2 DNS 要求解決

1. リゾルバ（クライアント）は、www.cisco.com に対するクエリーをローカル クライアント ネーム サーバ（D プロキシ）に送信します。

2. ローカル D プロキシは www.cisco.com に対する IP アドレスを持っていないため、IP アドレスを要求するルート ネーム サーバ（"."）にクエリーを送信します。ルート ネーム サーバは、次のいずれかを実行して要求に応答します。

• .com ドメインをサポートする個別のネーム サーバに D プロキシを誘導する。

• www.cisco.com に対して権威あるネーム サーバのアドレスを認識している中間ネーム サーバに D プロキシを送る。この方法は反復クエリーと呼ばれます。

3. ローカル D プロキシは、クエリーを中間ネーム サーバに送ります。この中間ネーム サーバは、D プロキシを cisco.com およびすべての関連付けられたサブドメインに対して権威のあるネーム サーバに誘導することによって応答します。

4. ローカル D プロキシは、クエリーをトップレベル ドメインである cisco.com の権威のあるネーム サーバに送ります。この例では、www.cisco.com は cisco.com のサブドメインであるため、このネーム サーバは要求されたドメインに対して権威のあるサーバであり、IP アドレスをネームサーバ（D プロキシ）に送ります。

5. ネーム サーバ（D プロキシ）は、IP アドレス（172.16.56.76）をクライアント ブラウザに送ります。ブラウザはこの IP アドレスを使用して、
www.cisco.com の Web サイトへの接続を開始します。

GSS および GSSM

プライマリ Global Site Selector Manager（GSSM）およびスタンバイ GSSM を含めて、ネットワーク内のすべての GSS 装置は、ドメインに関する権限を委任されており、DNS クエリーに応答し、キープアライブを実行し、さらには、基本的なネットワーク管理用のローカル CLI（コマンドライン インターフェイス）を使用します。すべての GSS 装置は、一元化された、共通のグローバル サーバ ロードバランシング機能を提供するために、プライマリ GSSM に依存します。

ここで説明する内容は、次のとおりです。

• プライマリ GSSM

• GSS

• スタンバイ GSSM

プライマリ GSSM

プライマリ GSSM は GSS ソフトウェアが稼働する GSS で、GSS ネットワークの中央管理機能および共通グローバル サーバ ロード バランシング機能のほかに、コンテンツ ルーティングを実行します。

プライマリ GSSM は、各 GSS などの、すべての GSS リソースおよび DNS 規則に関する構成情報を格納する組み込みの GSS データベースをホスティングします。すべての GSS 装置は、プライマリ GSSM にステータスを報告します。

プライマリ GSSM では、次の方法のいずれかを使用して GSS 装置をモニタおよび管理します。

• CLI コマンド

• GUI（グラフィカル ユーザ インターフェイス）機能（『 Cisco Global Site Selector GUI-Based Global Server Load-Balancing Configuration Guide 』を参照）

すべての設定変更はプライマリ GSSM が管理する各装置に自動的に伝えられます。

設定済みのシステムでは、どの GSS 装置も単一の、プライマリ GSSM として機能することができます。

GSS

GSS は GSS ソフトウェアを実行し、プライマリ GSSM を使用して設定した DNS 規則および条件に基づいて DNS クエリーをルーティングします。

各 GSS はプライマリ GSSM に認識され、プライマリ GSSM と同期します。

各 GSS は、その CLI を使用して個々に管理されます。GUI は、GSS またはスタンバイ GSSM でサポートされていません。

スタンバイ GSSM

スタンバイ GSSM は、GSS ソフトウェアを実行し、プライマリ GSSM を使用して設定した DNS 規則および条件に基づいて DNS クエリーをルーティングする GSS です。さらに、スタンバイ GSSM は、指定されたプライマリ GSSM がオフラインになったり、他の GSS 装置と通信不能になった場合に、プライマリ GSSM として機能するように設定されています。

スタンバイ GSSM が仮のプライマリ GSSM として作動するときには、この GSSM に、現在プライマリ GSSM にインストールされている組み込み GSS データベースの重複コピーが格納されます。また、スタンバイ GSSM を仮のプライマリ GSSM として設定すると、そのスタンバイ GSSM では CLI と GUI がサポートされ、この両方を使用できます。プライマリ GSSM として機能している間も、GSS の動作をモニタしたり、必要に応じて設定を変更することができます。

GSS ネットワークに影響するすべての設定またはネットワークの変更はプライマリ GSSM とスタンバイ GSSM 間で同期されるため、2 つの装置は常に一致します。

スタンバイ GSSM をプライマリ GSSM としてイネーブルにするには、 gssm standby-to-primary CLI コマンドを使用します。スタンバイ GSSM を新しいプライマリ GSSM としてイネーブルにする前に、元のプライマリ GSSM がオフラインであることを確認してください。

プライマリ GSSM が使用できない場合、スタンバイ GSSM が一時的にプライマリ GSSM の役割を担うことができます（たとえば、プライマリ GSSM を移動したり、修理あるいはメンテナンスのためにオフラインにすることが必要な場合です）。指定されたプライマリ GSSM とスタンバイ GSSM との役割の切り替えは、元のプライマリ GSSM がオンラインに復帰するまでの一時的な GSS ネットワーク構成として意図されています。元のプライマリ GSSM が使用可能になった場合には、2 つの GSSM に GSS ネットワークでの元の役割を再度割り当ててください（『 Cisco Global Site Selector Administration Guide 』を参照）。

DNS 規則

プライマリ GSSM で DNS 規則を設定して、次のことを行うことができます。

• 中央で管理されたコマンドを提供し、GSS が所定のホステッド ドメインでどのようにグローバル ロード バランシングを行うかを制御します。

• クライアントのネーム サーバ（D プロキシ）に送信する IP アドレスを定義します。

• （最大 3 つの負荷分散句を使用して）使用するリカバリー方法を定義します。

各 DNS 規則は、既知の送信元または D プロキシから受信した要求を、ネーム サーバまたは VIP のグループ内の最適なメンバーと照合することによって、受信した各クエリーへの応答方法を決定します。

各 DNS 規則では次の変数が考慮されます。

• 要求元 D プロキシの送信元 IP アドレス

• 要求されたホステッド ドメイン

• 回答グループ ― 応答に関して考慮するリソース グループ。

• 分散方式 ― 最適なサーバを選択するためのアルゴリズム。分散方式と回答グループで句を構成します。

• DNS スティッキおよびネットワーク プロキシミティなどの拡張トラフィック管理ロード バランシング機能。

DNS 規則は次の質問に回答して、GSS での要求の処理方法を定義します。

特定のドメイン名を問い合わせるトラフィックが DNS プロキシから着信した時刻、応答に関して考慮する必要があるリソース、および分散方式

各 GSS ネットワークでは、最大 4000 の DNS 規則をサポートします。

DNS 規則ごとに最大 3 つの可能な回答グループおよび分散方式句を使用できます。各句は、特定の回答グループが要求を処理し、特定の分散方式を使用して回答グループから最適なリソースを選択するように指定します。これらの句は設定されたパラメータで順番に評価され、最初の回答グループと指定の分散方式が回答にたどり着かない場合に、いつスキップして次の句を使用するかを決定します。

GSS ネットワークですべてのグローバル サーバ ロード バランシングを管理する DNS 規則の作成手順については、「DNS 規則の作成および変更」を参照してください。

ロケーションおよびリージョン

GSSネットワークが拡大するにつれて、GSS リソース（ロケーション、リージョン、回答と回答グループ、ドメイン リスト、および DNS 規則）を編成および管理する作業がますます複雑になります。GSS では、次の機能を提供してリソースを編成しやすくしています。

• ロケーション ― 都市、データセンター、コンテンツ サイトなど、地理的なエリアに対応する GSS リソースの論理的グループ

• リージョン ― 1 つまたは複数のロケーションを含む、より高度な地理的グループ

ロケーションやリージョンなどの論理グループを使用すると、長い回答リスト、DNS規則などを簡単に並べ替えたり、ナビゲートできるだけでなく、GSSリソースの一括管理を簡単に実行できます。たとえば、プライマリ GSSM から、特定の GSS データセンターにリンクされたすべての回答を中断またはアクティブ化できます。マウスを数回クリックするだけで、スケジュールされたメンテナンス作業のためにサイトをシャットダウンし、その後、再びオンラインに戻すことができます。

ロケーションおよびリージョン設定の詳細については、「リソースの設定」を参照してください。

所有者

所有者は、Web コンテンツを所有し、GSS を使用してコンテンツへのアクセスを管理するエンティティです。ロケーションおよびリージョンにより、GSS ネットワークを地理的に設定できますが、所有者は GSS ネットワークを組織的に設定することができます。

たとえば、GSS を使用して複数のホスティング サイトを管理するサービス プロバイダーは、カスタマーをホスティングしている Web またはアプリケーションごとに所有者を作成することができます。この構成方式を使用すると、その所有者のホスト コンテンツが格納されたドメイン リスト、およびこれらのドメインに送信されたトラフィックの処理方法を指定する DNS 規則、回答グループ、送信元アドレス リストなどの要素をすべて所有者に関連付けて、各所有者を通して管理することができます。

所有者を企業イントラネットに導入した場合、所有者を設定して、GSS リソースを部門単位で分離したり、特定のリソースを IT 担当者に割り当てることができます。たとえば、会計、人事、および営業部門の所有者を作成して、それぞれに対応するリソースをまとめて表示したり、管理することができます。

所有者の設定に関する詳細は、「リソースの設定」を参照してください。

送信元アドレスおよび送信元アドレス リスト

送信元アドレスとは、GSS で受信された DNS クエリーの送信元を表します。送信元アドレスは、通常、クエリーの送信元であるクライアント D プロキシを表す IP アドレスまたはアドレス ブロックを示します。

DNS 規則を使用することにより、GSS は複数の分散方式のいずれかを使用して、GSS でホスティングされるドメインと送信元アドレスを比較します。

送信元アドレスは、要求元クライアントが再帰要求を発行した D プロキシ（ローカル ネーム サーバ）から取得されます。D プロキシはクライアントのクエリーを複数のネーム サーバに送信し、最終的に GSS にクエリーを実行して、設定済み送信元アドレスのリストと D プロキシの送信元アドレスを比較します。

GSS で受信された DNS クエリーをルーティングする場合は、このクエリーを特定の D プロキシと比較する必要はありません。既知の送信元アドレスから送られなかった要求には、デフォルト ルーティングを実行できます。GSS では、安全な "Anywhere" 送信元アドレス リストがデフォルトで用意されています。設定済み送信元アドレス リストと一致しない着信クエリーは、このリストと比較されます。

送信元アドレスは、要求をルーティングするために、リスト（送信元アドレス リスト）にグループ化されます。送信元アドレス リストには 1 ～ 30 個の送信元アドレス、または一意のアドレス ブロックを格納できます。各 GSS では、最大 60 個の送信元アドレス リストをサポートします。

送信元アドレス リストの設定に関する詳細は、「送信元アドレス リストの設定」を参照してください。

ホステッド ドメインおよびドメイン リスト

HD（ホステッド ドメイン）は、GSS に委任され、プライマリ GSSM を使用して DNS クエリー応答用に設定された任意のドメインまたはサブドメインです。ホステッド ドメインは、GSS が権威を持つ DNS ドメイン名です。

すべての DNS クエリーは、設定されたドメイン リストに属するドメインに一致する必要があります。一致しない DNS クエリーは、GSS によって拒否されます。GSS ドメイン リストのドメインと一致しないクエリーは、GSS によって外部 DNS ネーム サーバに転送して解決することもできます。

ただし、128 文字を超えるホステッド ドメイン名は指定でません。GSS では、ドメイン名にワイルドカードを使用できます。また GSS では、ワイルドカードを比較する際に、POSIX 1003.2 拡張正規表現を使用することもできます。

GSS でのドメイン名またはサブドメイン名の設定例は、次のとおりです。

ドメイン リストは、GSS に委任されたホステッド ドメインのグループです。各 GSS では、最大 2000 個のホステッド ドメインおよび各ドメイン リストに最大 500 個のホステッド ドメインが格納されたホステッド ドメイン リストを最大 2000 個使用できます。

ドメイン リストは、GSS が着信 DNS 要求と DNS 規則を比較するために使用されます。クエリー ドメインがドメイン リスト内で見つかり、DNS 規則と比較されると、DNS 規則の分散方式句により、GSS がどのように最適な回答（例えば VIP）を選択して要求を処理するかが定義されます。

ドメイン リストの設定に関する詳細は、「ドメイン リストの設定」を参照してください。

回答および回答グループ

GSS ネットワークで、回答とは、受信した DNS 要求を GSS が解決するリソースを表します。GSS ネットワークでは、次の 3 つのタイプの回答が可能です。

• VIP ― Cisco CSS、Cisco CSM、Cisco IOS に準拠した SLB、Cisco LocalDirector などの SLB、Web サーバ、キャッシュ、またはグローバル ネットワークで地理的に分散配置されているその他のデバイスに関連付けられた VIP アドレス。

• ネーム サーバ ― GSS が解決できないクエリーに応答可能な設定済みの DNS ネーム サーバ。

（注） GSS をスタンドアロン モードで設定する場合、GSS が正常に稼働し、DNS 解決を実行するために、ネーム サーバが適切に設定されて稼働し、到達可能である必要があります。ただし、Cisco ネットワーク レジストラ （CNR）が v2.0 GSS にインストールされている場合は、ネーム サーバは必要ありません。

• CRA ― ユーザの D プロキシに同一の応答を同時に送信するために、DNS レースという解決プロセスを使用するコンテンツ ルーティング エージェント。

ドメインおよび送信元アドレスと同様に、回答はプライマリ GSSM を使用して設定されます。そのためには、クエリーを転送できる IP アドレスを指定する必要があります。

作成された回答は、回答グループというリソース プールとしてグループ化されます。GSS は、ユーザ要求を処理する最適なリソースを選択するために、DNS 規則で使用可能な回答グループから、最大 3 つの可能な応答の回答グループおよび分散方式句を使用できます。各分散方式では、設定済みの回答グループから 1 つの回答を選択するために異なるアルゴリズムが提供されます。各句は、特定の回答グループが要求を処理し、特定の分散方式を使用して回答グループから最適なリソースを選択するように指定します。

回答タイプに応じて、詳細な基準を DNS クエリーに適用して、最適なホストを選択できます。たとえば、Cisco CSS に関連付けられた VIP にルーティングされる要求は、CSS で判別される負荷およびアベイラビリティに基づいて、最適なリソースにルーティングされます。コンテンツ ルーティング エージェント（CRA）にルーティングされる要求は、GSS によって実行される DNS レースで判別されたプロキシミティに基づいて、最適なリソースにルーティングされます。

GSS 回答および回答グループの設定についての詳細は、「回答および回答グループの設定」を参照してください。

ここで説明する内容は、次のとおりです。

• VIP 回答

• ネーム サーバ回答

• CRA 回答

VIP 回答

SLB は、VIP 回答を使用して管理されている 1 つ以上のサーバにホスティングされたコンテンツを表します。VIP を使用すると、GSS は、トラフィックを複数のオリジン サーバ、アプリケーション サーバ、またはトランザクション サーバ間で分散して、ユーザの応答時間を短縮し、ホストのネットワーク輻輳を軽減することができます。

VIP 回答タイプに関連付けられたドメインに対してクライアントの D プロキシから問い合わせがあった場合、GSS はその要求を処理するために最適な SLB の VIP アドレスを使用して応答します。次に、要求元クライアントは SLB に問い合わせを行い、そこで要求の応答に最適なサーバに要求を負荷分散します。

ネーム サーバ回答

ネーム サーバ回答は、GSS から送信された DNS クエリーの転送先となる DNS ネーム サーバの IP アドレスを指定します。

クエリーは、ネーム サーバの転送機能を使用して、外部（GSS 以外の）ネーム サーバに転送されて解決されます。回答は GSS ネーム サーバに戻され、要求元の D プロキシに戻されます。ネーム サーバ回答は、保証されたフォールバック リソースとして機能することができます。これは、GSS が自身で解決できない要求を解決する方法です。GSS は、次の理由によりこのような要求を解決できないことがあります。

• コンテンツが GSS に対して未知である。

• 一般的にこのような要求を処理するリソースが利用できない。

GSS によって転送された外部の DNS ネーム サーバ回答では、次の機能を実行することができます。

• メール エクスチェンジャ（タイプ MX）レコードなどの、GSS によってサポートされない DNS サーバ機能を使用している

• フェールオーバーおよびエラー回復用にサードパーティのコンテンツ プロバイダーを使用している

• 階層 DNS システムへのアクセスを提供している

CRA 回答

CRA 回答は、CRA および GSS を信頼し、複数の可能なホストと要求元 D プロキシとのプロキシミティに基づいて、指定されたクエリーに最適な回答を選択します。

CRA 回答が指定されている場合、特定の D プロキシから受信した要求は、最初に要求に応答するコンテンツ サーバによって処理されます。応答時間は DNS レースを使用して測定され、GSS および各コンテンツ サーバで稼働している CRA によって調整されます。DNS レースでは、複数のホストが A レコード要求に同時に応答します。応答時間が最短のサーバ（サーバ自身と D プロキシ間のネットワーク遅延が最短のサーバ）が、コンテンツ処理用に選択されます。

GSS では、DNS レースを開始する前に、次の情報が必要です。

• GSS と各データセンター内の各 CRA の間の遅延。このデータを使用して、GSS は各データセンターからのレースの遅延を計算し、各 CRA がレースを同時に開始できるようにします。

• キープアライブを使用して取得された CRA のオンライン ステータス。

ブーメラン分散方式では、DNS レースを使用して、最適なサイトを判別します。この分散方式の詳細については、「DNS レース（ブーメラン）方式」を参照してください。

キープアライブ

各回答には、リソースを指定する機能のほかに、そのリソースにキープアライブを指定するオプションもあります。キープアライブは、リソースがまだアクティブであるかどうか判別するために、GSS が定期的にチェックする方法であり、一般にサポートされているプロトコルを使用して、GSS と別の装置の間で実行される特定のインタラクション（ハンドシェイク）です。キープアライブは、装置上の特定のプロトコルが適切に機能しているかどうかテストすることを目的としています。ハンドシェイクが成功すれば、装置は使用可能でアクティブであり、トラフィックを受信できます。ハンドシェイクが失敗する場合、装置は使用できず、アクティブでないとみなされます。すべての回答は設定済みのキープアライブによって検証され、回答が使用不可能であることをキープアライブが示している場合、回答は GSS によって D プロキシに戻されません。

GSS はキープアライブを使用して、VIP のオンライン ステータスから、サーバ上で稼働しているサービスおよびアプリケーションにいたるまでの情報を収集および追跡します。キープアライブを設定して、絶えずリソースのオンライン ステータスをモニタし、その情報をプライマリ GSSM に報告するようにすることができます。ルーティングの決定では、報告されたオンライン ステータス情報がリソースによって考慮される必要があります。

GSS では、GSS および GSS がモニタしている SLB 間のトラフィックを最小限に抑えるために、共有キープアライブを使用できます。共有キープアライブは、複数の回答にステータスを提供できる共通のアドレスあるいはリソースを識別し、ネーム サーバまたは CRA 回答で使用されません。

VIP タイプの回答を設定する際に、さまざまなキープアライブ タイプの 1 つまたは複数を設定して、目的の回答をテストすることができます。プライマリ GSSM では、特定の VIP 回答に対して複数のキープアライブおよび宛先ポートを割り当てることができます。ICMP、TCP、HTTP HEAD、および KAL-AP VIP キープアライブ タイプでは、1 つの VIP 回答に対して最大 5 つの異なるキープアライブを混在または比較設定にて設定できます。TCP または HTTP HEAD キープアライブの場合、1 つの VIP サーバに対して異なる宛先ポートを指定できます。

GSS でのキープアライブの詳細については、次の項で説明します。

• ICMP

• TCP

• HTTP HEAD

• KAL-AP

• スクリプト キープアライブ

• CRA

• ネーム サーバ

• None

• キープアライブの障害検出時間の調整

マルチポート キープアライブ

GSS では、マルチポート キープアライブを使用して、複数の装置で VIP タイプ回答をモニタできます。さまざまなタイプのキープアライブを設定して、VIP サーバ上の複数のポートをモニタすることができます。また、VIP サーバ以外（たとえば、ルータ、バックエンド データベースサーバ、Catalyst 6500 シリーズ スイッチ、またはデータセンター構成の CSS）の IP アドレスを指定するキープアライブを設定することもできます。

複数のキープアライブ（各キープアライブは、指定された装置をプローブするように設定されている）がグループとして機能し、ご使用の設定状況をオンラインでモニタします。すべてのキープアライブが正常である限り、GSS は設定がアクティブであるとみなし、トラフィックをデータセンターに転送し続けます。データセンターの複数の装置をプローブするキープアライブ設定例については、図 1-4 を参照してください。

図 1-4 複数のキープアライブを使用したデータセンターのモニタ

（注） プライマリ GSSM では、複数のキープアライブ タイプを指定すると、1 つの KAL-AP キープアライブと複数の共有キープアライブを設定できます。

グローバル キープアライブ パラメータを修正して、共有キープアライブを作成する方法については、「キープアライブの設定」を参照してください。

ICMP

ICMP キープアライブは、テスト中の GSS 回答が VIPアドレス、IP アドレス、または仮想サーバ IP アドレスの場合に使用します。インターネット制御メッセージプロトコル（ICMP）キープアライブ タイプは、ICMP パケットを含むクエリーを設定済みの VIP アドレス（または共有キープアライブ アドレス）に発行して回答を要求することによって、リソースの健全性をモニタします。オンライン ステータス（ネットワークに単に接続されているかどうか）は、対象アドレスからの応答によって判別されます。GSS では、標準検出方法の使用時に最大 750 の ICMP キープアライブを、高速検出方法の使用時に最大 150 の ICMP キープアライブをサポートします。詳細については、「キープアライブの障害検出時間の調整」を参照してください。

TCP

TCP キープアライブは、テスト中の GSS 回答が CSS または CSM 以外の GSLB 装置である場合に使用します。GSLB リモート装置には、Web サーバ、LocalDirector、ワイヤレス アプリケーション プロトコル（WAP）ゲートウェイのほか、TCP キープアライブを使用してチェック可能な装置があります。TCP キープアライブは、スリーウェイ ハンドシェイクのシーケンスを実行して、リモート装置への TCP 接続を開始します。

TCP 接続が確立されると、GSS は接続を終了します。リセット（ハードリセットを使用した即時終了）またはグレースフル（標準的なスリーウェイ ハンドシェイクの終了）の2 つの終了方法から接続を終了できます。

GSS では、標準検出方法の使用時に最大 1500 の TCP キープアライブを、高速検出方法の使用時に最大 150 の TCP キープアライブをサポートします。詳細については、「キープアライブの障害検出時間の調整」を参照してください。

HTTP HEAD

HTTP HEAD キープアライブは、テスト中の GSS 回答がスタンドアロン装置として機能する HTTP Web サーバ、または Cisco CSS、Cisco CSM、Cisco IOS 準拠の SLB、あるいは Cisco LocalDirector などの SLB 装置によって管理されている HTTP Web サーバである場合に使用します。HTTP HEAD キープアライブ タイプは、TCP 形式の HTTP HEAD 要求を指定されたアドレスの Web サーバに送信します。装置のオンライン ステータスは、200 の HTTP 応答ステータ スコード（たとえば、HTTP/1.0 200 OK）の形式で返されます。

HTTP HEAD 接続が確立されると、GSS は接続を終了します。接続を終了する方法には、リセット（ハードリセットを使用した即時終了）またはグレースフル（標準的なスリーウェイ ハンドシェイクの終了）の 2 つがあります。

GSS では、標準検出方法の使用時に最大 500 の HTTP HEAD キープアライブを、高速検出方法の使用時に最大 100 の HTTP HEAD キープアライブをサポートします。詳細については、「キープアライブの障害検出時間の調整」を参照してください。

KAL-AP

キープアライブ アプライアンス プロトコル（KAL-AP）キープアライブは、テスト中の GSS 回答が Cisco CSS または Cisco CSM に関係づけられた VIP である場合に使用します。KAL-AP キープアライブ タイプは、詳細なクエリーを指定されたプライマリ（マスター）と任意のセカンダリ（バックアップ）回路アドレスの両方に送信します。KAL-APキープアライブで指定された各 VIP のオンライン ステータスおよび負荷が返されます。

GSS ネットワーク設定に応じて、VIP アドレスを直接問い合わせたり（KAL-AP By VIP）、英数字のタグ（KAL-AP By Tag）によってアドレスを問い合わせるために、KAL-APキープアライブを使用できます。KAL-AP By Tag キープアライブ クエリーは、次のような場合に役立ちます。

• Network Address Translation（NAT; ネットワークアドレス変換）を実行しているファイアウォールの背後にある装置のオンライン ステータスを判別しようする場合。

• SLB で複数のコンテンツ規則を選択できる場合。

GSS は、標準検出方法の使用時に最大 128 のプライマリおよび 128 のセカンダリ KAL-AP キープアライブをサポートし、高速検出方法の使用時に、最大 40 のプライマリおよび 40 のセカンダリ KAL-AP キープアライブをサポートします。詳細については、「キープアライブの障害検出時間の調整」を参照してください。

スクリプト キープアライブ

スクリプト キープアライブは、サードパーティ製の装置をプローブして負荷情報を取得する場合に使用します。スクリプト キープアライブは、SNMP Get 要求を使用してターゲット装置から負荷情報をフェッチします。

（注） スクリプト キープアライブは常に共有キープアライブである必要があります。

GSS では、標準検出方法の使用時に最大 384 のスクリプト キープアライブを、高速検出方法の使用時に最大 120 のスクリプト キープアライブをサポートします。詳細については、「キープアライブの障害検出時間の調整」を参照してください。セカンダリ スクリプト キープアライブは、GSS でサポートされません。

CRA

CRA キープアライブは、DNS レース要求に応答する CRA 回答をテストするときに使用します。CRA キープアライブ タイプは、情報パケットが CRA に到達して GSS に戻るまでの所要時間を（ミリ秒）追跡します。GSS では、最大 200 の CRA キープアライブをサポートします。

ネーム サーバ

ネーム サーバ キープアライブは、指定されたクエリー ドメイン（www.cisco.com など）のネーム サーバの IP アドレスにクエリーを送信するために使用します。ネーム サーバ回答のオンライン ステータスは、クエリー ドメインのネーム サーバがクエリーに応答し、アドレスにドメインを割り当てる能力によって判別されます。GSS では、最大 100 のネーム サーバ キープアライブをサポートします。

None

キープアライブが None に設定されている場合、GSS は回答が常にオンラインであるとみなします。キープアライブ タイプを None に設定すると、GSS はルーティング時にオンライン ステータスまたは負荷を考慮しなくなります。ただし、他のキープアライブ タイプに適さない GSS ネットワークに装置を追加する場合など、特定の状況では、キープアライブが None に設定されていると便利です。ICMP はほとんどの装置で使用できる単純で柔軟なキープアライブ タイプです。None オプションを使用するよりも、ICMP を使用することを推奨します。

キープアライブの障害検出時間の調整

GSS の場合、失敗検出時間とは、装置に障害が発生（回答リソースがオフラインになる）してから障害が発生したことが GSS によって認識されるまでの時間です。応答パケットがこのウインドウ内で GSS に戻ってこない場合、その回答にはオフラインのマークが付けられます。

GSS は、標準と高速の 2 つの障害検出モードをサポートします。

標準モードでは、障害が発生したことが GSS によって検出されるまでの障害検出時間は通常 60 秒です。標準モードでは、次のパラメータを調整できます。

• 応答タイムアウト ― 要求に応答していない装置に GSS がデータを再送信できるようになるまでの時間長。有効な入力値は、20 ～ 60 秒で、デフォルト値は 20 秒です。

• Minimum Interval ― GSS がキープアライブのスケジューリングを試みる最小間隔。有効な入力値は、40 ～ 255 秒で、デフォルト値は 40 秒です。

高速モードでは、GSS は次のキープアライブ送信間隔の公式を使用して障害検出時間を制御します。

( # Ack'd Packets * ( Response TO + ( Retry TO * # of Retrie s))) + Timed Wait

ここで、

# Ack'd Packets = 何らかの形の確認応答を必要とするパケット数

Response TO = 応答タイムアウト。これは確認応答を必要とするパケットの応答を待つ時間長です。

Retry TO = リトライ タイムアウト。これは再送信されたパケットの応答を待つ時間長です。

# of Retries ＝ リトライ回数。これは、GSS によって装置がオフラインであると宣言されるまでに、機能していない可能性がある装置に GSS がパケットを再送信する回数です。

Timed Wait = リモート側の接続が終了するまでの時間（TCP ベースのキープアライブのみ）。

表1-1 に、回答ごとの単一キープアライブに対する、GSS の高速キープアライブ送信速度の算出方法を示します。

TCP（RST）接続の場合、TCP キープアライブでのデフォルト送信間隔は次のとおりです。

(1 * (2 + (2 * 1))) + 0 = 4 秒

ICMP、TCP、HTTP HEAD、および KAL-AP キープアライブ タイプについては、リトライ回数を調整することができます。リトライ回数は、装置がオフラインであると GSS によって宣言されるまでに、機能していない可能性がある装置に GSS がパケットを再送信する回数を定義します。GSS では、最大 10 回のリトライが可能で、デフォルトは 1 回です。リトライ回数を調整する場合、GSS によって決定された検出時間を変更します。リトライ回数を増やすと、検出時間が長くなり、リトライ回数を減らすと、検出時間が短縮されます。

GSS は、リトライ値の回数を何らかの形の確認応答が必要なすべてのパケットに関連付けてから、キープアライブ サイクル（ICMP 要求、TCP SYN、または TCP FIN）を続行します。たとえば、完全に TCP ベースのキープアライブ サイクルを完了するために、TCP ベースのキープアライブは、指定されたリトライ回数で SYN パケットをリトライし、次に指定されたリトライ回数で FIN パケットをリトライします。

上記の例の TCP（RST）接続で、リトライ回数をデフォルト値の 1 から 5 の設定値に変更した場合、送信間隔は次のようになります。

(1 * (2 + (2 * 5))) + 0 = 12 秒

図 1-5 に、リトライ回数の値を増やした場合の、キープアライブ送信間隔に与える影響を示します。

図 1-5 リトライ回数の値がキープアライブ送信間隔に与える影響

また、オフラインの回答がオンラインであることが GSS によって識別されるまでに、連続して成功する必要があるキープアライブの試行（プローブ）回数も定義できます。GSS は、各キープアライブの試行をモニタして試行が成功したかどうか判別します。 successful-probes キーワードは、回答が再度オンラインになり、GSS ネットワークに戻されるまでに、GSS によって認識される必要がある、連続して成功したキープアライブの試行回数を示します。

プライマリ GSSM は、1 つの VIP 回答に複数のキープアライブを割り当てることができます。ICMP、TCP、HTTP HEAD、および KAL-AP VIP キープアライブ タイプでは、1 つの VIP 回答に対して最大 5 つの異なるキープアライブを混在または比較設定にて設定できます。この設定では、障害検出時間は、回答に関連付けられている各キープアライブで示された計算伝送レベルに基づいています。

分散方式

GSS では 6 つの独自の分散方式をサポートしており、特定の DNS クエリーに応答する GSS 回答の選択方法を指定できます。各分散方式では、設定済みの回答グループから 1 つの回答を選択するために異なるアルゴリズムが提供されます。ここでは、次の内容を含む、GSS によってサポートされる分散方式について説明します。

• 順序付きリスト方式

• ラウンドロビン方式

• 重み付けラウンドロビン方式

• 最小負荷方式

• ハッシュ方式

• DNS レース（ブーメラン）方式

順序付きリスト方式

GSS が順序付きリスト分散方式を使用する場合、回答グループ内の各リソース（SLB VIP やネーム サーバなど）にグループ内の回答のランクに対応する番号が割り当てられます。割り当てられた番号は、リスト内の回答の順序を表します。その番号以降の VIP またはネーム サーバは、リスト内でそれ以前の VIP またはネーム サーバが使用不可能な場合にのみ使用されます。GSS は順序リストでのナンバリングのギャップをサポートします。

（注） 1 つの回答グループに同じ順序番号を持つ回答がある場合、GSS はその番号を含んでいる最初の回答のみを使用します。回答グループの各回答には、一意の順序番号を指定する必要があります。

GSS は各回答のランキングを使用して、各リソースを割り当てられた順序で試行します。そのため、最初に、ユーザ要求を処理するのに有効な回答を選択します。リストのメンバーには所定の優先順位が設定されており、順序に従って実行されます。また、メンバーが使用されるのは、その前のすべてのメンバーで最適の結果が得られなかった場合に限ります。

順序付きリスト分散方式を使用すると、回答を選択するための決定論的方法が必要な複数のコンテンツ サイト間でリソースを管理することができます。

順序付きリスト分散方式の使用時に、選択する回答を GSS が判別する方法については、「各回答グループの分散方式オプション」を参照してください。

ラウンドロビン方式

GSS でラウンドロビン分散方式を使用すると、回答グループ内の各リソースが順番に試行されます。GSS は、各要求について順番に次の回答を選択しながら、回答リストを巡回します。この方法では、GSS は使用可能な回答間で負荷を均等に分散して、要求を解決できます。

ラウンドロビン分散方式は、同一コンテンツをホスティングしている複数のアクティブなデータセンター間（プライマリ サイトの SLB と、要求を処理するアクティブ スタンバイ サイトの SLB 間など）で要求を分散する場合に便利です。

ラウンドロビン分散方式の使用時に、選択する回答を GSS が判別する方法については、「各回答グループの分散方式オプション」を参照してください。

重み付けラウンドロビン方式

ラウンドロビン分散方式と同様に、重み付けラウンドロビン（WRR）分散方式では定義済みの回答リストを実行して、使用可能な各回答をそれぞれ順に選択します。ただし、WRR の場合は、各回答にさらに重み係数が割り当てられ、特定のサーバに対する GSS が優遇されて、使用頻度が高まります。

重み付けラウンドロビン分散方式の使用時に、選択する回答を GSS が判別する方法については、「各回答グループの分散方式オプション」を参照してください。

最小負荷方式

最小負荷分散方式を使用すると、GSS はすべてのリソースの中で負荷が最小のリソースに対して要求を解決します。負荷が最小のリソースは、SLB の負荷およびアベイラビリティに関する詳細情報を GSS に提供する KAL-AP キープアライブ プロセスの報告に基づいて判別されます。

最小負荷方式では、接続数が最小の CSM または負荷が最小の CSS を判別することによって、要求を解決します。

最小負荷分散方式の使用時に、選択する回答を GSS が判別する方法については、「各回答グループの分散方式オプション」を参照してください。

ハッシュ方式

GSS でハッシュ分散方式を使用すると、クライアントの DNS プロキシ IP アドレスおよび要求元クライアントのドメインの要素が抽出されて、ハッシュ値と呼ばれる一意の値が作成されます。一意のハッシュ値は、DNS クエリーの処理用に選択される VIP を識別するために付加したり、使用します。

ハッシュ値を使用すると、特定の要求元クライアントからのトラフィックを特定の VIP に「固定」して、今後そのクライアントから送信される要求を同一の VIP にルーティングすることができます。このタイプの方法は、クライアントからサイトへの接続が終了または中断した場合でもクライアント固有のデータが保持される、オンライン「ショッピング バスケット」などの機能を実行するために使用できます。

GSS では、次の 2 つのハッシュ分散方式をサポートします。このハッシュ分散方式のいずれかまたは両方を指定された回答グループに適用できます。

• By Source Address ― GSS は、要求の送信元アドレスから作成されたハッシュ値に基づいて回答を選択します。

• By Domain Name ― GSSは、要求されたドメイン名から作成されたハッシュ値に基づいて回答を選択します。

DNS レース（ブーメラン）方式

GSS は近接ルーティングに関するDNSレース（ブーメラン）方式をサポートします。これは、GSS によって開始され、2 ～ 20 箇所のサイト間で負荷を分散する DNS 解決タイプの方式です。

ブーメラン方式は、各データセンター内の CRA がまったく同じ時間にクライアントの D プロキシに A レコード（IP アドレス）を送信した場合に、瞬間的にプロキシミティを判別できるという概念に基づいています。DNS 解決の DNS レース方式では、すべての CRA（Cisco コンテント エンジンまたはコンテント サービス スイッチ）にクライアント要求を解決する機会を与え、クライアントの D プロキシをプローブせずにプロキシミティを判別することができます。デフォルトでは、D プロキシによって最初に受信された A レコードが最も近接しているとみなされます。

GSS が DNS レースを開始するためには、CRA ごとに次の情報を確立する必要があります。

• GSS と各データセンター内の各 CRA の間の遅延。このデータを使用して、GSS は各データセンターからのレースの遅延時間を計算し、各 CRA がレースを同時に開始できるようにします。

• CRA のオンライン ステータス。このデータを使用して、GSS は応答していない CRA に要求を転送しないようにします。

GSS のブーメラン サーバは定義した間隔でキープアライブ メッセージを送信して、この情報を収集します。ブーメラン サーバは、このデータと CRA の IP アドレスを使用して、DNS レースの正確な開始時刻を要求します。

D プロキシが CRA 応答を受け入れるためには、各 CRA は応答時の DNS 要求の送信先である GSS の IP アドレスを詐称する必要があります。

各回答グループの分散方式オプション

GSS でサポートされるほとんどの分散方式には、回答グループの特定の回答をグループ化する場合の追加の設定オプションがあります。これらの設定オプションにより、GSS は、適切に回答の分散方式を適用し、GSS 装置から最適な結果を取得できます。

表1-2 に、回答タイプ（VIP、CRA、NS）ごとに使用可能な回答グループ オプションと負荷分散方式の組み合わせを示します。

ここでは、回答グループの回答に使用可能な各オプションについて説明します。ここで説明する内容は、次のとおりです。

• 順序

• 重み

• 負荷スレッシュホールド

順序

順序オプションは、回答グループの分散方式が順序付きリストの場合に使用します。要求に応答する場合は、リスト内の回答の位置に基づいて、リストの回答に優先順位が設定されます。

重み

回答グループ重みオプションは、回答グループの分散方式が重み付けラウンドロビンまたは最小負荷の場合に使用します。重みは、1 ～ 10 の値を入力して指定し、この値は回答の要求に応答する能力を示します。この重みにより、GSS が要求を各回答に誘導する際に使用する比率が作成されます。たとえば、回答 A の重みが 10、回答 B の重みが 1 の場合、回答 B に要求が 1 つ転送されるたびに、回答 A は 10 個の要求を受信します。

重み付けラウンドロビン分散方式に重みを指定すると、GSS は回数の比率を作成します。この比率は、GSS が要求に応答するために、リスト上の次の回答を試行するまでに、回答を使用する回数の比率です。

最小負荷分散方式で重みを指定した場合、GSS は回答に関連付けられた負荷値を計算するときに、この値を除数として使用します。この負荷値は、より大きい容量を持つ回答を優先させるバイアスを作成します。

負荷スレッシュホールド

回答タイプが VIP、キープアライブ方式が KAL-AP の場合、使用される分散方式にかかわらず、回答が入手可能であるか判別するには、負荷スレッシュホールド オプションを使用します。負荷スレッシュホールドは、回答デバイスから報告される負荷と比較する 2 から 254 までの数値です。報告された負荷が指定されたスレッシュホールド値を超えている場合、回答はオフラインとみなされ、これ以上の要求を処理できなくなります。

トラフィック管理負荷分散

GSS は、GSS ネットワークで高度なグローバル サーバ ロードバランシング機能を実現するために、DNS スティッキおよびネットワーク プロキシミティ トラフィック管理機能を備えています。

DNS スティッキは、カスタマーと e- コマース サーバ間で永続的なスティッキ ネットワーク接続をサポートすることによって、e- コマース サイトが中断することなくサービスを提供し、ビジネス用に解放された状態を維持します。永続的なネットワーク接続により、購入トランザクションが完了するまで、アクティブな接続が中断されず、ショッピング カートが失われないことが保証されます。

ネットワーク プロキシミティは、要求元クライアントの D プロキシ ロケーションまでのラウンドトリップ時間を測定して最も近接したサーバを選択するので、GSS ネットワーク内の効率が向上します。ネットワーク トポロジに変化がない場合、所定のロケーション（D プロキシ）からのすべての要求については、通常、同一のプロキシミティ計算が実行されます。このアプローチでは、サイトの健全性（アベイラビリティや負荷）とクライアントからサーバ ゾーンまでのネットワーク距離との組み合わせに基づいて最適なサーバが選択されます。

ここで説明する内容は、次のとおりです。

• DNS スティッキ GSL

• ネットワーク プロキシミティ GSLB

DNS スティッキ GSL

スティッキ性は永続的回答または回答キャッシングとしても知られ、これにより、GSS は クライアント D プロキシに返される DNS 応答を記憶しておき、後でクライアント D プロキシが同じ要求を実行したときに、同じ回答を返すことができます。DNS 規則でスティッキ性をイネーブルにすると、GSS は、元の VIP が引き続き使用可能であるとみなして、要求元クライアント D プロキシに同一の A レコード応答を常に提供するために最善の努力をします。

GSS で DNS スティッキを使用すると、DNS マッピングがクライアントのブラウザによってリフレッシュされた場合でも、e- コマース クライアントは、トランザクションの期間中、特定のサーバに接続されたままになります。ブラウザには、クライアント接続が、ブラウザのインスタンスのライフタイム中または数時間持続するものもあれば、DNS の再解決が必要になるまでの 30 分間に制限されるものもあります。この時間は、クライアントが e- コマース取引を完了するのに十分でない場合があります。

ローカルの DNS スティッキを使用すると、各 GSS 装置は、同じ GSS 装置の同じドメイン名に対する以降のクライアント D プロキシの要求を最初の要求と同じロケーションに固定しようと試みます。ユーザ設定可能なスティッキの非アクティブ時間間隔が持続している間、DNS スティッキは、回答がまだ有効であるとみなします。これにより、クライアント D プロキシから特定のホステッド ドメインまたはドメイン リストへのすべての要求で同じ回答が GSS によって確実に与えられます。

グローバル DNS スティッキがイネーブルにされた状態では、ネットワーク内の各 GSS 装置は、完全に接続されたピアツーピア メッシュとして稼働し、ネットワーク内の他の GSS 装置と回答を共有します。メッシュ内の各 GSS 装置は、クライアント D プロキシからの要求および応答を自身のローカル データベースに保管し、この情報をネットワーク内の他の GSS 装置と共有します。結果として、ネットワーク内で同じドメイン名の GSS に送信される以降のクライアント D プロキシ要求では、クライアントが固定されます。

DNS スティッキ選択プロセスは、DNS 規則分散方式句の一部として開始されます。

ネットワーク内の GSS 装置に対してローカルおよびグローバル DNS スティッキを設定するための情報については、「DNS スティッキの設定」を参照してください。

ネットワーク プロキシミティ GSLB

GSS は、要求元 D プロキシに関連する最も近接した回答（リソース）で DNS 要求に応答します。このため、ネットワーク トポロジの用語では、プロキシミティは、要求元クライアントの D プロキシとその回答までの距離（地理上の距離ではない）または遅延と呼びます。

最も近接した回答を判別するために、GSS はプローブ装置、つまり各プロキシミティ ゾーンに配置されている Cisco IOS ベースのルータと通信して、要求元クライアントの D プロキシとゾーン間で測定されたラウンドトリップ時間（RTT）メトリック情報を収集します。各 GSS は、クライアント要求を RTT 値が最も低い、使用可能なサーバに誘導します。

プロキシミティ選択プロセスは、DNS 規則分散方式句の一部として開始されます。プロキシミティがイネーブルの状態で、要求が DNS 規則および負荷分散句と一致した場合、GSS は最も近接した回答で応答します。

ネットワーク内の GSS 装置に対してプロキシミティを設定する場合の情報については、「ネットワーク プロキシミティの設定」を参照してください。

軽減ルール

攻撃者が犠牲者（この場合、GSS）の IP アドレスを詐称して、DNS サーバまたは複数の DNS サーバに複数の DNS 要求を送信するときに、リフレクタ アタックが発生します（図 1-6 を参照）。増幅効果は、小さいクエリーが応答でより大きい UDP パケットを生成して、大量の DNS 応答トラフィックで犠牲者を攻撃することができるという事実に基づいています。

図 1-6 リフレクタ アタックの図

次の GSS の基本的な軽減ルールを使用することにより、リフレクタ アタックを低減できます。

• 応答が 53 以外の送信元ポートから着信する場合、送信元ポートが 53、QR ビットが 1（応答）以外のパケットはドロップされます。

• 応答がポート 53 に着信する場合、宛先ポートが 53、およびQR ビットが 1（応答）のパケットはドロップされます。

• 送信元ポートが 53 に等しくても 1024 未満で、QR ビットが 0（要求）のパケットはドロップされます。

軽減ルールは、デフォルトでイネーブルになります。軽減ルールをイネーブルにする方法に関する詳細については、「DDoS 防止の設定」を参照してください。

レート制限

GSS では、各 D プロキシに対して毎秒の DNS パケット数を制限したり、全体的なグローバル レート制限を実施しますが、その他のすべてのトラフィックに対しては制限を実施しません。最初は、この制限がデフォルト値となります。ただし、平時に制限値を調整する、あるいは D プロキシまたは D プロキシのグループを設定することによって、制限値を上書きすることができます。この制限値を上回ると、DNS パケットがドロップされます。

（注） 各 D プロキシの最終レート制限およびグローバル レート制限は、平時に得られた許容値によってレート制限を増やす（あるいは CLI で設定する）ことにより、決定します。この値は、ddos 設定モードで rate-limit global および tolerance-factor global CLI コマンドを使用して設定できます。詳細については、「DDoS 防止の設定」を参照してください。

アンチスプーフィング メカニズム

スプーフィングされたパケットは、ヘッダーに実際の送信元装置のものと異なる IP アドレスを含んでいます。スプーフィング攻撃の狙いは、ターゲット サイト リンクおよびターゲットサイトのサーバ リソースまたはゾーンを飽和状態にすることにあります。スプーフィングされたパケットの送信元 IP アドレスは、ランダムに指定されているか、対象をしぼった特定のアドレスが指定されています。

スプーフィング攻撃は、アクセス リスト（ACL）またはフィルタを使用しても防ぐことができないため、1 台の装置からでも大量に、しかも容易に発生させることができます。そのため、攻撃者は絶えずパケットの送信元 IP アドレスを変えることができるのです。

スプーフィング攻撃を撃退するために、GSS では Redirect to TCP と呼ばれるアンチスプーフィング メカニズムを使用します。このメカニズムは DNS クエリー用に使用され、DNS プロキシとも呼ばれます。このメカニズムは、TCP を使用してクエリーを再送するようにクライアントに強制することにより実行されます。クエリーが TCP で到着すると、GSS はチャレンジ/レスポンス メカニズムを使用して送信元を認証します。送信元が認証に成功すると、GSS は TCP 応答を送信します。GSS が TC または切り捨てられたビットを送信する間に、D プロキシは UDP 要求を送信します。D プロキシは TCP で返し、次に GSS は応答を TCP で送信します。

（注） GSS は、TSIG、DDNS （OP コード = 5）および DNS 通知（OP コード = 4) 要求を除く、すべての要求パケット（qrbit によって識別済み = 0）に対してアンチスプーフィングを実行します。

チャレンジ/レスポンス アルゴリズムは、スプーフィングされたトラフィックとスプーフィングされていないトラフィックを見分けることによって機能します。GSS は、GSS に接続しようとするクライアントにチャレンジ（クッキーとしても知られる）を送信します。パケット ヘッダーの送信元 IP アドレスがクライアントに割り当てられている IP アドレスである場合、クライアントはチャレンジを受信し、応答を返送します。

ただし、パケットの送信元 IP アドレスが詐称されている場合、ゾーンに対して元のトラフィックを生成したクライアントは GSS 応答を受信しないため、正しいチャレンジに応答できません。GSS は、正しいチャレンジが返されるときだけ、クライアントが認証されたとみなします。DDoS モジュールは、単にこのようなクライアントからのトラフィックがセレクタまたは CNR に通過するのを許可するだけです。

DDoS をイネーブルにして、フィルタ、レート制限およびアンチスプーフィング メカニズムを設定するための具体的な説明については、「DDoS 防止の設定」を参照してください。

GSS 装置の配置

ネットワーク内の GSS 装置の配置については組織が決定しますが、配置する際には以下のガイドラインに従う必要があります。

GSS は、1 つ以上のドメインに対して権威があるネーム サーバとして機能することから、各 GSS は企業ネットワーク上でパブリックに、またはプライベートにアドレス指定できる必要があります。これにより、コンテンツを要求する D プロキシ クライアントは、DNS 要求を処理するために割り当てられた GSS を見つけることができます。

ドメインに送受信されるトラフィック パターンに応じて、ドメインの役割を GSS デバイスに委任するオプションを使用できます。たとえば、5 台の GSS 装置を含むネットワークで、ドメインに送信されるすべてのトラフィックが GSS ネットワークに転送されるように、親ドメインの DNS サーバを変更することができます。また、トラフィックのサブセットを 1 つまたは複数の GSS に委任し、その他のトラフィック セグメントを残りの装置で処理することもできます。

別の GSS 装置を収容できるようにネットワークの DNS 設定を変更する手順については、「DNS 規則の作成および変更」を参照してください。

ファイアウォール背後の GSS 装置の配置

ファイアウォールを配置すると、GSS ネットワークへの不正アクセスを防止したり、通常の GSS 装置に対する DoS 攻撃を排除することができます。GSS パケット フィルタリング機能は、企業のファイアウォールの背後に配置できるだけでなく、この機能により、GSS 管理者はすべての GSS 装置へのトラフィックを許可したり、拒否することができます。

GSS をファイウォールの背後に配置するか、または GSS 自身のパケット フィルタリングをイネーブルにする場合は、有効なネットワーク トラフィックが GSS デバイスの特定ポートに到達できるように、各デバイス（ファイアウォールおよび GSS）を適切に設定する必要があります。プライマリ GSS GUI にアクセスするためには、HTTPS トラフィックが必要なだけでなく、特定のポートを介して FTP、Telnet、および SSH アクセスができるように、GSS を設定する必要があります。さらに、GSS は GSSM に自身のステータスを伝え、そこから設定情報を受信できなければなりません。また、プライマリおよびスタンバイ GSSM は相互に通信したり、同期できなければなりません。最後に、GSS ネットワークでグローバル DNS スティッキがイネーブルになっている場合、スティッキ メッシュ内のすべての GSS は、スティッキ データベースを共有するために互いに通信できなくてはなりません。

着信トラフィックを制限するためのアクセス リストについては、『 Cisco Global Site Selector Administration Guide 』を参照してください。GSS を適切に機能させるために、イネーブルにする必要があるポート、および開いたままにしておく必要があるポートについては、「ファイアウォール背後の GSS 装置の配置」を参照してください。

ノード間の通信

プライマリ GSSM およびスタンバイ GSSM を含めて、すべての GSS 装置は、DNS クエリーに応答したり、グローバル サーバ ロードバランシングを行うためにキープアライブを実行します。さらに、プライマリ GSSM は中央の管理装置として機能し、管理対象の各 GSS に関する共通設定情報（DNS 規則などの）が格納された組み込みの GSS データベースをホスティングします。プライマリ GSSM は、設定変更を行うために使用します。設定変更は、プライマリ GSSM によって管理される、登録済みの各 GSS 装置に自動的に伝達されます。

スタンバイ GSSM は、GSS ネットワークに対して GSLB 機能を実行し、指定された プライマリ GSSM が突然オフラインになったり、他の GSS 装置と通信不能になった場合に、スタンバイ GSSM は、GSS ネットワークの仮のプライマリ GSSM として機能できます。プライマリ GSS がオフラインになっても、GSS ネットワークは引き続き機能するため、グローバル サーバ ロード バランシングに影響を及ぼすことはありません。

GSS は、DNS 規則およびプライマリ GSSM から作成された条件に基づいて DNS クエリーのルーティングを実行します。ネットワーク上の各 GSS 装置は、DNS 要求を処理する親ドメインの GSS DNS サーバに権限を委任します。

各 GSS はプライマリ GSSM に認識され、プライマリ GSSM と同期します。グローバル DNS スティッキがイネーブルにならない限り、個別のGSS が自身の存在またはステータスを互いに報告しません。GSS が不意にオフラインになっても、同じリソースに処理を行うネットワーク上の他の GSS は影響を受けません。

GSS ネットワークにプライマリとスタンバイの両方の GSSM が配置されている場合、装置の設定情報およびDNS 規則は、プライマリ GSSM とスタンバイ GSSM に保持されているデータ ストア間で自動的に同期されます。

GSS ネットワーク設定が変更されると、2 台の装置間で自動的に同期が発生します。更新内容がパッケージ化され、2 台の装置間の安全な接続を使用してスタンバイ GSSM に送信されます。

GSS ネットワークで各 GSS 装置をイネーブルにするための説明および GSS ネットワークでの GSSM 役割変更に関する詳細については、『 Cisco Global Site Selector Administration Guide 』を参照してください。

データセンター内での配置

一般的な GSS ネットワークは、データセンターおよびサーバ ファームなどの、複数のコンテンツ サイトで構成されており、データセンターまたはサーバ ファームへのアクセスは、Cisco CSS や Cisco CSM などの、1 つまたは複数の SLB によって管理されます。各 SLB は 1 つまたは複数の VIP で表されます。各 VIP は、パブリックにアドレス指定可能なデータセンターのフロントエンドとして機能します。各 SLB の背後にトランザクション サーバ、データベース サーバ、およびミラーリングされた送信元サーバが配置されており、Web サイトからアプリケーションまで、さまざまなコンテンツを提供しています。

GSS は各データセンターを表している SLB と直接通信し、各 SLB および VIP のアベイラビリティや負荷に関する統計情報を収集します。GSS はこのデータを使用して、要求を最適なデータセンターおよび各データセンター内で最もアベイラビリティの高いリソースに転送します。

一般的なデータセンターには、SLBだけでなく、GSSで管理されない DNS ネーム サーバが配置されている場合もあります。これらの DNS ネームサーバを使用すると、GSS が解決できない要求を、ネーム サーバ転送によって解決できます。

CLI ベースの GSS 管理

CLI を使用すると、GSS に対して次のインストール、管理、およびグローバル サーバ ロード バランシング作業を設定できます。

• GSS および GSSM（プライマリおよびスタンバイ）装置の初期設定および設定

• GSS および GSSM でのソフトウェアのアップグレードおよびダウングレード

• データベース バックアップ、設定バックアップおよびデータベースの復元操作

• プライマリ GSSM で DNS 規則を作成し、キープアライブをモニタすることによる、グローバル サーバ ロード バランシングの設定および DNS 要求処理

さらに、CLI を使用して次のネットワーク設定タスクを実行できます。

• ネットワーク アドレスおよびホスト名の設定

• ネットワーク インターフェイス設定

• IP フィルタリングやトラフィック セグメンテーションなど、GSS デバイスのアクセス制御

また、CLI を使用して、各 GSS 装置のローカル ステータスをモニタおよびロギングすることができます。

構文、オプションおよび関連のコマンドを含む、すべての GSS CLI コマンドのアルファベット順のリストについては、『 Cisco Global Site Selector Command Reference 』を参照してください。

GUI ベースのプライマリ GSS 管理

プライマリ GSSM には、GSS ネットワーク全体をモニタおよび管理するための、一元化された GUI が備わっています。プライマリ GSSM GUI を使用して次のタスクを実行できます。

• DNS 規則を作成し、キープアライブをモニタすることによる、DNS 要求処理およびグローバル サーバ ロード バランシングの設定

• GSS ネットワークに設定済みの GSS の起動

• GSS ネットワーク リソースのモニタ

• 要求ルーティングおよび GSS 統計のモニタ

GUI に関する詳細については、『 Global Site Selector GUI-Based グローバル ロード バランシング コンフィギュレーション ガイド 』を参照してください。