GSLB の概要と展開トポロジ
概要
高可用性、近接性ベースの負荷分散、およびスケーラビリティを確保するには、複数の分散Kubernetesクラスターにアプリケーションを展開する必要があります。地理的に分散した場所にまたがる複数のKubernetesクラスターにアプリケーションが展開されている場合、アプリケーションインスタンス間でトラフィックを分散するために負荷分散の決定を行う必要があります。
NetScaler GSLBコントローラーは、地理的に分散した場所間でサービスを負荷分散するようにNetScaler（GSLBデバイス）を構成します。GSLBソリューションは、イングレスまたはサービスタイプLoadBalancerを使用して公開されるKubernetesサービスに対して、より優れたパフォーマンスと信頼性を保証します。GSLBトポロジでは、各リージョンにGSLBデバイスが展開されます。GSLBデバイスの1つがプライマリADCとして機能し、その他はセカンダリADCとして機能します。GSLBプライマリADCは、サイト全体に展開された各クラスターに展開されたGSLBコントローラーによって構成されます。このGSLBデバイスは、複数のクラスターにわたって展開されたサービスを負荷分散します。
GSLBの詳細については、「グローバルサーバー負荷分散」を参照してください。
注:
NetScaler GSLBコントローラーイメージは、NetScaler Ingress Controllerのイメージと同じです。
展開トポロジ
GSLB展開トポロジのコンポーネントを以下に示します。
-
GSLBデバイス: NetScaler MPXまたはNetScaler VPXは、グローバルサーバー負荷分散（GSLB）デバイスとして使用されます。各データセンターにGSLBデバイスが構成されます。各GSLBデバイスでは、1つのサイトがローカルデータセンターを表すローカルサイトとして構成されます。他のサイトはリモートサイトとして構成されます。GSLBデバイスとして使用されるNetScaler MPXまたはNetScaler VPXは、NetScaler Ingress Controllerとともにイングレスデバイスとしても使用できます。
-
イングレスロードバランサー: NetScaler CPXまたはサードパーティ製アプリケーションは、各Kubernetesクラスターにイングレスロードバランサーとして展開されます。
-
イングレスコントローラー: イングレスコントローラーは、NetScaler Ingress Controllerまたはサードパーティ製イングレスコントローラーのいずれかです。
-
GSLBコントローラー: 展開内の各クラスターは、GSLBコントローラーインスタンスを実行します。各GSLBコントローラーは、それぞれのクラスターに展開されたアプリケーションのGSLBプライマリADCを構成します。グローバルサーバー負荷分散（GSLB）構成同期オプションは、プライマリサイトのGSLB構成をGSLBセットアップ内のすべてのGSLBサイトにコピーするために使用されます。GSLB同期を構成するNetScalerはプライマリサイトと呼ばれ、構成がコピーされるサイトはセカンダリサイトと呼ばれます。
次の展開図は、NetScaler GSLBコントローラーのサンプル構成を示しています。各サンプル構成には、異なるリージョンに2つのデータセンター（サイト）が含まれており、各データセンターにはKubernetesクラスターが含まれています。
GSLBサイトで使用されるイングレスコントローラーのタイプに基づいて、2つのサンプル展開トポロジを検討してみましょう。
-
両方のGSLBサイトにNetScaler® Ingress Controller(#netscaler-ingress-controller-in-both-gslb-sites)
-
両方のGSLBサイトにサードパーティのイングレスコントローラー(#any-third-party-ingress-controller-in-both-gslb-sites)
注:
GSLBコントローラーの展開は、一方のGSLBサイトにNetScaler Ingress Controller、もう一方のGSLBサイトにサードパーティのイングレスコントローラーがある場合もサポートされます。
両方のGSLBサイトにNetScaler Ingress Controller
注:
GSLBおよびイングレスまたはサービスタイプのLoadBalancerに使用されるNetScaler MPXまたはNetScaler VPXは、同じでも異なっていても構いません。以下の例では、GSLBおよびイングレスまたはサービスタイプのLoadBalancerに同じNetScalerが使用されています。
次の図は、NetScaler Ingress Controllerが存在する場合のNetScaler GSLBコントローラーの展開トポロジを示しています。
以下の手順の番号は、前の図の番号に対応しています。
-
各クラスターで、NetScaler Ingress Controllerは、
ingressを使用するか、service of type LoadBalancer構成を使用してNetScalerを構成します。 -
各クラスターで、NetScaler GSLBコントローラーは、プライマリサイトのGSLBデバイスをGSLB構成で構成します。
-
GSLB構成は、異なるGSLBサイトのGSLBデバイス間で自動的に同期されます。
-
アプリケーションのホスト名またはFQDNに対するDNSクエリは、NetScalerで構成されたGSLB仮想サーバーに送信されます。GSLB仮想サーバーでのDNS解決は、構成されたグローバル・トラフィック・ポリシー (GTP) に基づいて、いずれかのクラスター上のIPアドレスに解決されます。
-
DNS解決に基づいて、データトラフィックは、いずれかのクラスターのイングレスフロントエンドIPアドレスまたはサービスタイプLoadBalancer IPアドレスのいずれかに到達します。
-
必要なアプリケーションはGSLBデバイスを介してアクセスされます。
両方のGSLBサイトにおけるサードパーティ製Ingressコントローラー
次の図は、サードパーティ製Ingressコントローラーが存在する場合のNetScaler GSLBコントローラーの展開トポロジを説明しています。
次の項目は、前の図を説明しています。
-
NetScaler GSLBコントローラーは、プライマリサイトのGSLBプライマリADCにGSLB構成を設定します。
-
GSLB構成は、異なるGSLBサイトのGSLBデバイス間で自動的に同期されます。
-
アプリケーションのホスト名またはFQDNに対するDNSクエリは、NetScalerで構成されたGSLB仮想サーバーに送信されます。GSLB仮想サーバーでのDNS解決は、構成されたグローバル・トラフィック・ポリシー（GTP）に基づいて、いずれかのクラスター上のIPアドレスに解決されます。
-
DNS解決に基づいて、データトラフィックは、IngressフロントエンドIPアドレスまたはサービスタイプLoadBalancerフロントエンドIPアドレスのいずれかのクラスターに着信します。
-
必要なアプリケーションはプロキシを介してアクセスされます。
GSLBメソッドとサポートされる展開タイプ
次のグローバル負荷分散メソッドがサポートされています。
以下のデプロイタイプがサポートされています。
-
ローカル優先: ローカル優先デプロイメントでは、あるアプリケーションが別のアプリケーションと通信したい場合、同じクラスター内のローカルアプリケーションを優先します。アプリケーションがローカルで利用できない場合、リクエストは他のクラスターまたはリージョンに転送されます。
-
カナリア: カナリアリリースは、新しいソフトウェアバージョンを本番環境に導入する際のリスクを軽減するための手法で、まず変更を少数のユーザーに展開します。このソリューションでは、アプリケーションの新しいバージョンを本番環境に移行する前に、選択したクラスターに展開したい場合にカナリアデプロイメントを使用できます。
-
フェイルオーバー: フェイルオーバーデプロイメントは、アプリケーションをアクティブ/アクティブモードでデプロイできない場合に、アクティブ/パッシブ構成でデプロイしたいときに使用されます。
-
ラウンドトリップタイム (RTT): RTTデプロイメントでは、ネットワークのリアルタイムステータスが監視され、クライアントのリクエストは最も低いRTT値を持つデータセンターに動的に転送されます。
-
静的近接性: 静的近接性デプロイメントでは、IPアドレスベースの静的近接性データベースを使用して、クライアントのローカルDNSサーバーとGSLBサイト間の近接性を判断します。リクエストは、近接性基準に最も一致するサイトに送信されます。
-
ラウンドロビン: ラウンドロビンデプロイメントでは、GSLBデバイスはそれにバインドされているサービスリストを継続的にローテーションします。リクエストを受信すると、リストの最初のサービスに接続を割り当て、そのサービスをリストの最後に移動します。
注:
現在、IPv6はサポートされていません。
分散Kubernetesクラスターにデプロイされたアプリケーション向けNetScaler GSLBコントローラーを構成するためのCRD
KubernetesアプリケーションのGSLBを実行するためのNetScaler構成をサポートするために、以下のCRDが導入されています。
-
グローバル・トラフィック・ポリシー (GTP)
-
グローバル・サービス・エントリー (GSE)
GTP CRD
GTP CRDは、デプロイタイプ（カナリア、フェイルオーバー）、GSLBドメイン、イングレスのヘルスモニター、サービスタイプなど、NetScalerでGSLBを構成するためのパラメーターを受け入れます。
GTP CRD の仕様は
<https://github.com/netscaler/netscaler-k8s-ingress-controller/blob/master/gslb/Manifest/gtp-crd.yaml> で入手できます。
注:
GTP CRD は、特定のドメインのすべてのクラスターで同じです。
次の表は、GTP CRD 属性について説明しています。
| フィールド | 説明 |
|---|---|
ipType |
DNS レコードタイプを A または AAAA として指定します。現在、A レコードタイプのみがサポートされています。 |
serviceType |
GSLB サポートが適用されるプロトコルを指定します。 |
host |
GSLB サポートが適用されるドメインを指定します。 |
trafficPolicy |
GSLB 展開でサポートされるトラフィック分散ポリシーを指定します。 |
sourceIpPersistenceId |
一意の送信元IP永続性IDを指定します。この属性により、受信パケットの送信元IPアドレスに基づいて永続性が有効になります。sourceIpPersistenceId属性は100の倍数であり、一意である必要があります。 |
secLbMethod |
ローカルファースト、カナリア、またはフェイルオーバーにおけるグループ内のクラスター間でサポートされるトラフィック分散ポリシーを指定します。 |
destination |
各クラスターのIngressまたはLoadBalancerサービスエンドポイントを指定します。宛先名はGSEの名前と一致する必要があります。 |
weight |
クラスター間で分散されるトラフィックの割合を指定します。カナリアデプロイメントの場合、割合はパーセンテージで指定されます。 |
CIDR |
ローカルファーストで使用されるCIDRを指定して、ローカリティのスコープを決定します。 |
primary |
フェイルオーバーデプロイメントにおいて、宛先がプライマリクラスターであるかバックアップクラスターであるかを指定します。 |
monType |
GSLBエンドポイントの健全性を判断するためのプローブのタイプを指定します。モニタータイプがHTTPSの場合、TLSハンドシェイク中にSNIがデフォルトで有効になります。 |
uri |
HTTPおよびHTTPSプロトコル用のGSLBエンドポイントの健全性をプローブするパスを指定します。 |
respCode |
HTTPおよびHTTPSプロトコルでGSLBエンドポイントを正常とマークするために期待される応答コードを指定します。 |
customHeader |
GSLBエンドポイントの監視トラフィックに追加するカスタムヘッダーを指定します。 |
ingressHostName |
GTPがIngressルールと照合する必要がある正確なホスト値を指定します。GSLB FQDNがクラスター内のIngressホスト名と異なる場合、このオプションを使用します。 |
multipleIPResponse |
このオプションが有効な場合、GSLB DNSは1つのバックエンドIPアドレスではなく、すべての正常なバックエンドIPアドレスで応答します。 |
emptyDownResponse |
このオプションが有効な場合、すべてのメンバーがダウンしているときに、GSLBは空のDNS応答（NXDOMAINではなく）を返します。 |
GSE CRD
GSE CRDは、各クラスターのエンドポイント情報（クラスターにトラフィックをルーティングするKubernetesオブジェクト）を決定します。
GSE CRDの仕様は、NetScaler Ingress ControllerのGitHubリポジトリ（gse-crd.yaml）で入手できます。
次の表は、GSE CRDの属性について説明しています。
| フィールド | 説明 |
|---|---|
| IPv4アドレス | ローカルクラスターイングレスIPv4アドレス、またはLoadBalancerタイプのサービスエンドポイントIPv4アドレス |
| domainName | ローカルクラスターイングレスドメイン名、またはLoadBalancerタイプのサービスドメイン名 |
| monitorPort | ローカルクラスターイングレスのリスニングポート、またはLoadBalancerタイプのサービスのリスニングポート |
注:
-
GSE CRDはクラスター固有であり、各クラスターに対して個別のGSE CRDが作成されます。
-
Ingressを使用したGSE CRDの自動生成の場合、ホスト名はGTP CRDインスタンスで指定されたホスト名と一致する必要があります。
-
Ingressと
LoadBalancerタイプのサービスの両方について、GSE CRDは、指定された最初のポートに対してのみ生成されます。 -
GSE CRDは、対応するサービスまたはIngressに
status.loadBalancer.ingress.ip/hostnameフィールドが入力されている場合にのみ自動生成されます。
ローカルサイトの優先設定用ConfigMap
GSLBデバイスを構成する際、効率的なトラフィックルーティングと遅延の最小化のために、ADNS IPアドレスに地理的に最も近いKubernetesまたはOpenShiftクラスターにデプロイされた仮想IPアドレスとアプリケーションを選択することが重要です。
サービスが利用可能な場合、GSLBデバイスのローカルサイト優先設定を使用して、ローカル仮想IPアドレスに解決できます。このシナリオは、ロードバランシングポリシーコマンドを使用してGSLBサービスの優先順位を設定することで実現できます。詳細については、「ロードバランシングポリシーコマンドを使用してGSLBサービスの優先順位を構成する」を参照してください。
GSLBデバイス内のサービスまたはサービスグループの優先順位は、効果的なネットワークトラフィック管理と最適化を可能にします。これは通常、サービスグループをGSLB仮想サーバーにバインドする際に構成されます。特定のサービスまたはグループを優先することで、ロードバランシング中に、特に需要が高い場合や低遅延接続が必要な場合に、重要なアプリケーションが優先されるようになります。
ローカルサイトの優先設定を有効にするために、
Netscaler-gslb-controller HelmチャートにlocalSiteSelectionパラメーターが追加されます。このパラメーターをtrueに設定すると、GSLBデバイスに構成が自動的に追加されます。このパラメーターは、GSLBコントローラー用のConfigMapを作成し、構成のオンザフライでの追加、変更、削除をサポートします。
注記:
-
ConfigMapを介したローカルサイト優先設定の構成（追加、変更、削除のいずれか）では、サービスグループの優先順位を構成または非構成にする必要があるため、トラフィックに影響が出ます。
-
ConfigMapはすべてのクラスターで構成する必要があります。
GSLBデバイスのローカルサイト優先設定のサンプル：
add lb action <site1-act> -type SELECTIONORDER -value 1 2 3
add lb action <site2-act> -type SELECTIONORDER -value 2 3 1
add lb action <site3-act> -type SELECTIONORDER -value 3 1 2
add lb policy <site1-pol> -rule "CLIENT.IP.DST.EQ<site1_ip>" -action <site1-act>
add lb policy <site2-pol> -rule "CLIENT.IP.DST.EQ<site2_ip>" -action <site2-act>
add lb policy <site3-pol> -rule "CLIENT.IP.DST.EQ<site3_ip>" -action <site3-act>
bind gslb vserver <gslb_name> -serviceGroupName <sg_name_1> -order 1
bind gslb vserver <gslb_name> -serviceGroupName <sg_name_2> -order 2
bind gslb vserver <gslb_name> -serviceGroupName <sg_name_3> -order 3
bind gslb vserver <gslb_name> -policyName <site1-pol> -priority 1
bind gslb vserver <gslb_name> -policyName <site2-pol> -priority 2
bind gslb vserver <gslb_name> -policyName <site3-pol> -priority 3
Helmチャートを使用してConfigMapを構成する方法については、
<https://github.com/netscaler/netscaler-helm-charts/tree/master/netscaler-gslb-controller>を参照してください。
OpenShiftオペレーターを使用してConfigMapを構成する方法については、
<https://docs.netscaler.com/ja-jp/netscaler-k8s-ingress-controller/deploy/gslb-openshift-operator>を参照してください。