-
-
-
VMware ESX、Linux KVM、およびCitrix HypervisorでNetScaler ADC VPXのパフォーマンスを最適化する
-
AWSでNetScaler ADC VPXインスタンスを展開する
-
-
-
-
-
-
-
-
-
-
-
-
This content has been machine translated dynamically.
Dieser Inhalt ist eine maschinelle Übersetzung, die dynamisch erstellt wurde. (Haftungsausschluss)
Cet article a été traduit automatiquement de manière dynamique. (Clause de non responsabilité)
Este artículo lo ha traducido una máquina de forma dinámica. (Aviso legal)
此内容已经过机器动态翻译。 放弃
このコンテンツは動的に機械翻訳されています。免責事項
이 콘텐츠는 동적으로 기계 번역되었습니다. 책임 부인
Este texto foi traduzido automaticamente. (Aviso legal)
Questo contenuto è stato tradotto dinamicamente con traduzione automatica.(Esclusione di responsabilità))
This article has been machine translated.
Dieser Artikel wurde maschinell übersetzt. (Haftungsausschluss)
Ce article a été traduit automatiquement. (Clause de non responsabilité)
Este artículo ha sido traducido automáticamente. (Aviso legal)
この記事は機械翻訳されています.免責事項
이 기사는 기계 번역되었습니다.책임 부인
Este artigo foi traduzido automaticamente.(Aviso legal)
这篇文章已经过机器翻译.放弃
Questo articolo è stato tradotto automaticamente.(Esclusione di responsabilità))
Translation failed!
GSLBで永続性を構成する方法
永続性により、特定のドメイン名に対する一連のクライアント要求が、負荷分散されるのではなく、同じデータセンターに送信されます。特定のドメインに対してパーシステンスが設定されている場合は、設定された GSLB メソッドよりも優先されます。永続性は、クライアントトランザクションに関連する情報が、最初のリクエストを処理したインスタンスにローカルに保存されるデプロイメントに使用できます。たとえば、ショッピングカートを使用する電子商取引の展開では、サーバーはトランザクションを追跡するために接続の状態を維持する必要があります。Citrix ADCアプライアンスは、クライアント要求を処理するデータセンターを選択します。永続性を有効にすると、後続のすべてのドメインネームシステム(DNS)要求に対して、選択したデータセンターの同じIPアドレスが転送されます。永続セッションがダウンしているデータセンターを指している場合、Citrix ADCアプライアンスは構成済みのGSLBメソッドを使用して新しいデータセンターを選択します。その後、クライアントからの後続の要求に対して永続的になります。 GSLBで永続化するには、すべてのデータセンターのGSLB仮想サーバーで同じ永続性識別子のセット(persistID)を構成する必要があります。GSLBモジュールは、永続性識別子を使用してGSLB仮想サーバーを一意に識別します。GSLB仮想サーバーでソースIP永続性が有効になっている場合、永続性セッションもメトリック交換の一部として交換されます。Citrix ADCアプライアンスがサイト間の永続性をサポートするには、参加しているすべてのGSLBサイトで永続性関連の構成を行う必要があります。ステートフルアプリケーションにはGSLBでの永続性を推奨します。これにより、クライアントは後続の要求のために同じアプリケーションインスタンスに再接続する必要があります。
次の方法でGSLBの永続性を実現できます。
- GSLB仮想サーバーでの永続性
- GSLBサービスでのサイトの永続性
GSLB仮想サーバーでの永続性
GSLB仮想サーバーでの永続性は、DNS要求中に使用されます。DNS要求の送信元IPアドレスは、クライアントとデータセンター間の永続セッションを作成するために使用されます。DNSクライアントは通常、ローカルDNS(LDNS)またはDNSゲートウェイであり、その背後にあるクライアントのセットをプロキシします(ISP内)。GSLB仮想サーバーでの永続性は、アプリケーションプロトコルに依存しません。 一般に、複数のDNSゲートウェイまたはローカルドメインネームサーバー(LDNS)がクライアントネットワークに構成されます。後続のDNS要求では、ADCアプライアンスへの接続に使用されるアップストリームLDNSデバイスに関係なく、クライアントは以前の要求を処理した同じデータセンターに永続化できるため、適切な永続性マスクを構成することをお勧めします。LDNS IPアドレスの永続化セッションが作成された後、そのLDNSを使用して接続するすべてのエンドクライアントには、同じデータセンターIPアドレスが割り当てられます。
GSLBサービスでのサイトの永続性
サイトの永続性は、アプリケーション要求の処理中に有効になります。永続性はHTTPCookieを使用して実現されるため、サイトの永続性はHTTPおよびHTTPSトラフィックに対してのみ機能します。CookieはHTTPクライアント(ブラウザー)で維持されるため、DNSゲートウェイの背後にあるクライアントを可視化できます。Cookieを使用してクライアントの永続性を実現する場合、着信クライアントごとにADCアプライアンスでリソースが消費されることはありません。GSLBサービスを遅延時間でDOWNにすると、サービスはアウトオブサービス(TROFS)状態に移行します。サービスがUPまたはTROFS状態である限り、永続性がサポートされます。つまり、サービスが TROFS とマークされた後、同じクライアントが同じサービスの要求を指定された遅延時間内に送信すると、同じ GSLB サイト (データセンター) が要求を処理します。
エイリアスを介してアプリケーションにアクセスする場合は、CNAMEレコードがCitrix ADCアプライアンスでも構成されていることを確認してください。親子トポロジでは、エイリアスを介してアプリケーションにアクセスすると、サイトの永続性が機能しません。
注
接続プロキシがサイトの永続化方法として指定されていて、LB仮想サーバーでも永続性を構成する場合は、ソースIPの永続性はお勧めしません。接続がプロキシされると、クライアントの実際のIPアドレスではなく、ADCアプライアンスが所有するIPアドレスが使用されます。 HTTP(S)要求のソースIPを使用してクライアントを識別することのない適切な永続性を構成します(Cookieの永続性やルールベースの永続性など)。
送信元 IP アドレスに基づく永続性の設定
GSLB仮想サーバーで送信元IP永続性が構成されている場合、DNS要求の送信元IPアドレスに対して永続化セッションが作成されます。拡張クライアントサブネット(ECS)機能に応じて、DNS要求の送信元IPアドレスは次のいずれかから取得されます。
- 着信DNS要求パケットのIPヘッダーの送信元IP
- DNS 要求の ECS オプション ECS の詳細については、「 グローバルサーバー負荷分散に EDNS0 クライアントサブネットオプションを使用する」を参照してください。
クライアントの永続セッションは、永続タイムアウトまで続きます。タイムアウト期間が終了すると、既存の永続セッションがクリアされます。その後の要求では、新しいGSLB決定が行われ、別のGSLBサービスIPアドレスが選択される場合があります。 GSLB仮想サーバーでのソースIPの永続性と、GSLBサービスでのサイトの永続性は互いに補完し合っています。GSLB仮想サーバーでソースIPの永続性が無効になっている場合、GSLB仮想サーバーはDNSが解決を試みるたびに異なるGSLBサービスを選択します。また、クライアントは別のGSLBサービスに接続し、アプリケーション要求プロキシを受信するデータセンターは、最初にクライアントにサービスを提供したデータセンターへの接続をプロキシします。これにより、待ち時間が増える可能性があります。したがって、GSLB仮想サーバーでソースIPの永続性を有効にすることで、アプリケーション要求に対するこのような頻繁な複数のホップを回避できます。ソースIP永続性セッションが期限切れになり、その後クライアントが再接続した場合、サイト永続性はクライアントを、最初にクライアントにサービスを提供していたデータセンターに接続し直します。また、クライアントが構成された永続性マスクの範囲内にないDNSゲートウェイを介して接続し直す場合、サイトの永続性は、クライアントが最初の要求を処理したデータセンターに固執するのにも役立ちます。
CLIを使用して送信元IPアドレスに基づいて永続性を構成するには
コマンドプロンプトで入力します。
set gslb vserver <name> -persistenceType (SOURCEIP|NONE) -persistenceId <positive_integer> [-persistMask <netmask>] –[timeout <mins>]
<!--NeedCopy-->
例:
set gslb vserver vserver-GSLB-1 -persistenceType SOURCEIP -persistenceId 23 -persistMask 255.255.255.255 –timeout 2
<!--NeedCopy-->
GUIを使用して送信元IPアドレスに基づいて永続性を構成するには
- トラフィック管理 > GSLB > 仮想サーバーに移動して、メソッドを変更するGSLB仮想サーバーをダブルクリックします(たとえば、vserver-GSLB-1)。
- 「 持続性 」セクションをクリックし、「 持続性 」ドロップダウンリストから「 SOURCEIP 」を選択し、次のパラメータを設定します。
- 持続性ID:持続性ID
- タイムアウト:タイムアウト
- IPv4 ネットマスクまたは IPv6 マスクの長さ:永続マスク
HTTPCookieに基づいてサイトの永続性を構成する
サイトの永続性は、HTTP Cookie(「サイトCookie」と呼ばれる)を使用してクライアントを同じサーバーに再接続することで実現されます。GSLBアプライアンスが選択したGSLBサイトのIPアドレスを送信してクライアントDNS要求に応答すると、クライアントはそのGSLBサイトにHTTP要求を送信します。そのGSLBサイトのアプリケーションエンドポイントはHTTPヘッダーにサイトCookieを追加し、サイトの永続性が有効になります。 クライアントキャッシュの有効期限が切れた後にクライアントがDNSクエリを送信すると、DNS要求が別のGSLBサイトに送信される可能性があります。新しいGSLBサイトは、クライアント要求ヘッダーにあるサイトCookieを使用して永続性を実装します。サイト永続化機能は、次の条件下でアクティブになります。
- ホストヘッダーのドメイン名がGSLBドメインの1つと一致する場合
- アプリケーショントラフィックを受信する仮想サーバーを表すGSLBサービスでサイトの永続性が有効になっている場合。
サイトクッキーには、クライアントが永続的な接続を持つ選択された GSLB サービスに関する情報が含まれています。Cookieが指すGSLBサービスがダウンしているか、GLSB構成から削除されている場合、トラフィックを受信する仮想サーバーは引き続きトラフィックを処理します。クッキーの有効期限は、Citrix ADCアプライアンスで設定されたクッキーのタイムアウトに基づいています。仮想サーバー名がすべてのサイトで同一でない場合は、永続識別子を使用する必要があります。挿入されたクッキーは、RFC 2109に準拠しています。
Citrix ADCは、次の2種類のサイト永続性をサポートしています。
- 接続プロキシ
- HTTPリダイレクト
接続プロキシ
サイト永続性の接続プロキシモードでは、後続のアプリケーション要求を受信するデータセンターは、接続を確立するために次のタスクを実行します。
- サイトCookieを挿入したGSLBサイトへの接続を作成します。
- クライアント要求を元のサイトにプロキシします。
注:
プロキシサーバーは、次の詳細を使用して元のサイトとの接続を確立します。
- 新しいサイトのSNIPは送信元IPアドレスです。
- 元のサイトのGSLBサービスのパブリックIPアドレスが宛先IPアドレスです。
- エフェメラルポートは送信元ポートであり、GSLBサービスポートは宛先ポートです。
- GSLBサービスタイプに応じて、HTTPまたはHTTPSプロトコルのいずれかを使用します。
- 元のGSLBサイトから応答を受け取ります。
- その応答をクライアントに中継します。
- 接続を閉じます。
HTTPリダイレクト
GSLB 設定が HTTP リダイレクト永続性を使用する場合、新しいサイトは Cookie を最初に挿入したサイトに要求をリダイレクトします。リダイレクトURLのドメイン名はサイトドメインです。CookieとSSL証明書の両方がGSLBドメインとサイトドメインの両方に適用可能であることを確認してください。GSLBとサイトドメインの両方にCookieを適用するには、CookieドメインがサイトからGSLBドメインである必要があります。SSL証明書をGSLBとサイトドメインの両方に適用するには、SSL仮想サーバーにバインドされた証明書がワイルドカード証明書である必要があります。
接続プロキシは、次の条件が満たされた場合に発生します。
- GSLBに参加しているドメインに対してリクエストが送信されます。ドメインは URL/Host ヘッダーから取得されます。
- ローカル GSLB サービスで接続プロキシが有効になっています。
- 要求には、アクティブなリモート GSLB サービスの IP アドレスを含む有効な Cookie が含まれています。
注
GSLB親子構成では、子サイトでGSLBサービスが構成されていない場合でも、接続プロキシは意図したとおりに機能します。ただし、クライアント認証、クライアントIPアドレスの挿入、またはその他のSSL固有の要件などの追加の構成がある場合は、サイトに明示的なGSLBサービスを追加し、それに応じて構成する必要があります。
親子トポロジの詳細については、「 MEP プロトコルを使用した親子トポロジの展開」を参照してください。
CLIを使用してHTTPCookieに基づいて永続性を設定するには
コマンドプロンプトで入力します。
set gslb service <serviceName> -sitePersistence (ConnectionProxy [-sitePrefix <prefix>] | HTTPredirect -sitePrefix <prefix>)
<!--NeedCopy-->
例:
set gslb service service-GSLB-1 -sitePersistence ConnectionProxy
set gslb service service-GSLB-1 -sitePersistence HTTPRedirect -sitePrefix vserver-GSLB-1
<!--NeedCopy-->
GUIを使用してCookieに基づいて永続性を設定するには
- Traffic Management > GSLB > Servicesに移動し、サイト永続性を設定するサービス(service-GSLB-1 など)を選択します。
- [サイトの永続性] セクションをクリックし、Cookie に基づいて永続性を設定します。
共有
共有
This Preview product documentation is Cloud Software Group Confidential.
You agree to hold this documentation confidential pursuant to the terms of your Cloud Software Group Beta/Tech Preview Agreement.
The development, release and timing of any features or functionality described in the Preview documentation remains at our sole discretion and are subject to change without notice or consultation.
The documentation is for informational purposes only and is not a commitment, promise or legal obligation to deliver any material, code or functionality and should not be relied upon in making Cloud Software Group product purchase decisions.
If you do not agree, select I DO NOT AGREE to exit.