従来の DNS ルーティング
ここでは、GSS の背景となる主要な DNS ルーティング概念について説明します。
1980年代のはじめ以降、インターネット上のコンテンツ ルーティングの処理には、DNS(ドメイン名をIPアドレスにマッピングするホスト情報の分散データベース)が使用されてきました。電子メール、Telnet などのリモート端末アクセスに、File Transfer Protocol(FTP; ファイル転送プロトコル)によるファイル転送、および Web サーフィンなど、インターネットで発生するほとんどすべてのトランザクションに DNS が使用されています。DNS では、ホストのコンテンツに関係のない数値表記の IP アドレスの代わりに英数字のホスト名を使用します。
DNS は、ドメイン ネーム スペースと呼ばれ、ほとんど無限の数のホスト名を管理できます(図 1-1 を参照)。また、DNS はデータベース全体のセグメント(個別のドメイン)をローカルに管理できますが、任意のセグメントのデータをネットワーク全体で使用可能にすることができます。このプロセスは 委任 と呼ばれます。
図 1-1 ドメイン ネーム スペース
ここで説明する内容は、次のとおりです。
•
DNS ネーム サービス
•
DNS 構造
•
要求解決
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 を持つネーム スペースの領域であり、このレコードのフォーマットは、次の例のとおりです。
DOMAIN.NAME. IN SOA Hostname.Domain.Name. Mailbox.Domain.Name.
1 ; serno (serial number)
86400 ; refresh in seconds (24 hours)
7200 ; retry in seconds (2 hours)
2592000 ; expire in seconds (30 days)
345600 ; TTL in seconds (4 days)
ネガティブ キャッシング
サーバは、ビジーな場合、毎秒数百または数千もの名前解決要求を処理する必要があります。これらの要求のそれぞれが解決されるまでに時間がかかり、リソースが消費されることから、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 を使用したグローバル ロード バランシング
GSS は、分散したデータセンターにグローバル ロード バランシングを実行することによって重大な障害回復要件に対処しています。GSS は、次のシスコ製品がグローバル ネットワークに配置されている場合に、分散配置された SLB の負荷を調整します。
•
Cisco Content Services Switch 11500、11000、または 11150
•
Catalyst 6500 シリーズ スイッチ用 Cisco Content Switching Module(CSM)
•
Cisco LocalDirector
•
Cisco IOS SLB
•
ネットワーク プロキシミティに DRP エージェントを使用する Cisco ルータ
•
HTTP HEAD、ICMP、または TCP 要求に応答可能な任意のサーバ
•
キャッシュ モジュール搭載の Cisco ルータ
•
Cisco Cache Engine
GSS は4000 を超える個別のバーチャル IP(VIP)アドレスをサポートします。GSS は、管理されたこれらの装置に対して権威のある DNS サーバとして機能することで、SLB のアクティビティを調整します。
GSS が GSLB サービスを引き継ぐと、DNS プロセスは GSS に移行します。DNS 設定は、「要求解決」で説明するプロセスと同じです。唯一の例外は、NS レコードが各データセンターにある GSS をポイントするという点で、GSS がクライアント トラフィックを受信するデータセンター サイトを決定します。
GSS は、ドメインまたはサブドメインの権限ネーム サーバとして DNS 要求に応答するときに、次の付加的な要因を考慮します。
•
アベイラビリティ ― オンライン状態であり、クエリーへの応答に使用できるサーバ
•
プロキシミティ ― 最も速くクエリーに応答したサーバ
•
負荷 ― ドメイン内で各サーバが処理しているトラフィック負荷のタイプ
•
要求の送信元 ― コンテンツを要求しているネーム サーバ(D プロキシ)
•
初期設定 ― クエリーに応答する際に使用する最初、2 番め、または 3 番めのロード バランシング アルゴリズム
このタイプのグローバル ロード バランシングを使用すると、エンド ユーザが常にオンライン状態のリソースに転送されるだけでなく、要求が最適な装置に転送されて、ユーザの応答時間が短縮されます。
DNS 要求の解決中に、GSS は管理されているリソースを考慮するための一連の各処理を実行して、要求元クライアントの D プロキシに最適な回答を戻します。
要求されたコンテンツ サイトの IP アドレスを返すために、Web サイト選択プロセスの一部として、GSS がさまざまなクライアントとどのように対話するかを、図 1-3 に示します。
1.
クライアントが www.cisco.com からソフトウェアのアップデート バージョンのダウンロードするために、ブラウザのロケーションまたはアドレス フィールドに www.cisco.com と入力します。このアプリケーションは、3 つの異なるデータセンターでサポートされています。
2.
DNS グローバル コントロール プレーン インフラストラクチャは要求を処理し、その要求が GSS 装置に到達します。
3.
GSS は、クライアントに SLB に最適なサーバ ロード バランサ(この場合、データセンター 2)の IP アドレスを送信します。
4.
Web ブラウザは送信された IP アドレスを処理します。
5.
IP コントロールおよび転送プレーンがクライアントをデータセンター 2 の SLB に誘導します。
6.
GSS は、DNS グローバル コントロール プレーンのサイト選択プロセスの負荷を軽減します。要求およびサイト選択は、ユーザ制御のロード バランシング アルゴリズムを使用した負荷および健全性情報に基づいており、GSS は利用可能で負荷の低いデータセンターを即座に選択します。
図 1-3 GLSB を使用する Cisco Global Site Selector
GSS のアーキテクチャ
ここでは、ハードウェアやソフトウェアなど GSS 配置に関する主要コンポーネント、および GSS ネットワークの概念について説明します。ここで説明する内容は、次のとおりです。
•
GSS および GSSM
•
DNS 規則
•
ロケーションおよびリージョン
•
所有者
•
送信元アドレスおよび送信元アドレス リスト
•
ホステッド ドメインおよびドメイン リスト
•
回答および回答グループ
•
キープアライブ
•
分散方式
•
トラフィック管理負荷分散
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 がオフラインであることを確認してください。
注意 2 つのプライマリ GSSM を同時にアクティブにすると、GSS ネットワークの構成変更が不意に削除されることがあります。このようにプライマリ GSSM が重複して設定された場合、プライマリ GSSM が 2 つともスタンバイ モードになり、いずれかの 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 の高速キープアライブ送信速度の算出方法を示します。
表1-1 回答ごとのキープアライブに対するキープアライブ送信速度
|
|
|
|
|
|
|
KAL-AP |
1 |
2 秒 |
2 秒 |
1 |
0 |
4 秒 |
ICMP |
1 |
2 秒 |
2 秒 |
1 |
0 |
4 秒 |
TCP(RST) |
1 |
2 秒 |
2 秒 |
1 |
0 |
4 秒 |
TCP(FIN) |
2 |
2 秒 |
1 秒 |
1 |
2 秒 |
10 秒 |
HTTP HEAD(RST) |
2 |
2 秒 |
2 秒 |
1 |
0 |
8 秒 |
HTTP HEAD(FIN) |
3 |
2 秒 |
2 秒 |
1 |
2 秒 |
14 秒 |
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 が順序付きリスト分散方式を使用する場合、回答グループ内の各リソース(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-2 回答グループ オプション
|
|
|
VIP |
ハッシュ 最小負荷 順序付きリスト ラウンド ロビン WRR |
順序 負荷スレッシュホールド 重み |
ネーム サーバ |
ハッシュ 順序付きリスト ラウンド ロビン WRR |
順序 重み |
CRA |
ブーメラン(DNS レース) |
None |
ここでは、回答グループの回答に使用可能な各オプションについて説明します。ここで説明する内容は、次のとおりです。
•
順序
•
重み
•
負荷スレッシュホールド
順序
順序オプションは、回答グループの分散方式が順序付きリストの場合に使用します。要求に応答する場合は、リスト内の回答の位置に基づいて、リストの回答に優先順位が設定されます。
重み
回答グループ重みオプションは、回答グループの分散方式が重み付けラウンドロビンまたは最小負荷の場合に使用します。重みは、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 装置に対してプロキシミティを設定する場合の情報については、「ネットワーク プロキシミティの設定」を参照してください。
DDoS 検出および軽減
分散型サービス拒絶(DDoS)攻撃は、特定のコンピュータあるいはネットワーク リソースへの正当なユーザ アクセスを拒否することを意図しています。このような攻撃は、悪意のある攻撃者が数千もの偽装アドレスを使用して DNS 要求をターゲット装置に送信することによって行われます。ターゲットはこれらの要求を有効であるとして処理し、スプーフィングされた受信者(犠牲者)に DNS 応答を返します。
ターゲットは攻撃者に応答することでビジー状態になるため、正当な D プロキシからの有効な DNS 要求を除外します。要求数が何千にも達すると、攻撃者は、数ギガビットの DNS 返答で満杯状態を作り出す可能性があり、このためのネットワークに輻輳が発生します。
このような場合、次のネットワーク ポイントが影響を受けます。
•
ターゲット装置は、スプーフィングされた要求を処理することでビジー状態になるため、パフォーマンスが低下する。
•
応答によって生成されたトラフィックが ISP や上流のプロバイダに影響を及ぼすインターネット バックボーンを横断する。
•
スプーフィング操作で使用された IP アドレスに類似した IP アドレスを持つホストは、大量のインバウンド DNS トラフィックを受信する。
このような問題に対処するために、GSS は、ライセンス付きの DDoS 検出および軽減モジュールを備えています。DDoS ライセンスの取得およびインストールの詳細については、『Global Site Selector Administration Guide』を参照してください。
一般に、DDoS モジュールでは次のことを防止できます。
•
攻撃者が犠牲者(つまり、GSS)の IP アドレスを詐称している場合のリフレクタ アタック。詳細については、「軽減ルール」を参照してください。
•
不正な DNS パケットが送信される場合の攻撃。
•
DNS クエリーが以下のように送信される場合の攻撃。
–
特定の送信元 IP からあらゆるドメイン(すなわち、DoS リプレイ アタック)に対して送信する。
–
GSS で設定されていないドメインに対して送信する。
–
さまざまな送信元 IP からグローバルに GSS パケット処理レートを超えて送信する。
–
スプーフィングされた IP アドレスから送信する。
DDoS モジュールは、次の項で説明する 3 つの主要機能を実行することにより、これらの攻撃を防ぎます。
•
軽減ルール
•
レート制限
•
アンチスプーフィング メカニズム
軽減ルール
攻撃者が犠牲者(この場合、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 防止の設定」を参照してください。