内容
GSLBの概要
今日、ITサービスの高可用性は必須であり、それが企業や組織が世界中に分散したコンピューティングシステムを開発し、複数のデータセンターでサービスをホストする理由は次のとおりです。
フォールトトレランス：データセンターでホストされているサービスが失敗すると、そのサービスは他の利用可能なサイトのいずれかで続行されます。
自動データセンター復旧：1つのデータセンターに障害が発生すると、サービスは他の利用可能なデータセンターに自動的にリダイレクトされます。
ロードバランシング：利用可能なすべてのサイトに負荷を分散することでトラフィックを最適化し、待ち時間を短縮し、サービス配信を高速化することができます。
改善された待ち時間：クライアントアプリケーションのトラフィックは実サーバーと直接やり取りされるため、すべてのアプリケーションデータをロードバランサに渡す必要はありません。
クラウドでのITサービスの採用と実装には、WANベースの方法が、地理的に高い場所にある高可用性ソリューションを提供するための最良の選択肢であることが必要です。 それが私たちが呼ぶものです グローバルサービスロードバランシング or GSLB.
GSLBを使用する場合
GSLBサービスは、以下のユースケースに使用することをお勧めします。
WANを介して複数のデータセンターでサービスをホストしている企業。
高可用性のサービスまたはデータセンターを作成する必要がある企業。
ユーザーが使用するインバウンド負荷分散サービスを作成するためのインターネットサービスプロバイダ。
間違いなく、障害点なしで世界中のサーバー間でユーザーとトラフィックを共有する必要がある場合、GSLBが適切なソリューションです。
GSLBはどのように機能しますか
GSLB 負荷分散メカニズム DNS それが使用するのでプロトコル、それは速くそして信頼できます UDP プロトコルとクライアントの応答はほぼリアルタイムです。
たとえば、一般的なDNS要求では www.zvnlb.netクライアントは、ローカルに設定されたDNSサーバーにDNS要求解決を送信します（たとえば、 8.8.8.8 や 8.8.4.4 そして、クライアントシステムは、要求に対抗してクエリを送信するためにサーバのうちの１つをランダムに選択する。
選択したDNSサーバーがクライアントからの要求を受信します（たとえば、IPアドレスは www.zvnlb.net？ ）そしてローカルに設定されたDNSサーバーは誰がDNSゾーンを解決する責任があるかを見つけようとします zvnlb.net.
クライアントが使用しているDNS 8.8.8.8 or 8.8.4.4 この場合は、 ns1.zvnlb.net や ns2.zvnlb.net のゾーン解決を担当しています zvnlb.net そのため、クライアントが受信したDNSクエリを送信します（たとえば、IPアドレスは何ですか）。 www.zvnlb.net？ ）それらのうちの1つに。
どちらかのネームサーバー ns1.zvnlb.net or ns2.zvnlb.net からDNSクエリを受信します。 8.8.8.8 or 8.8.4.4 そして、リクエストを受信したネームサーバーは、ホストの利用可能なサーバーをチェックします。 www.zvnlb.net そして、それは利用可能なアプリケーションサーバーのリストでDNSクエリに応答してホストの実際のアプリケーションにサービスを提供します。 www.zvnlb.netしたがって、この情報はクライアントによって最終的に受信されます。
これで、クライアントはDNSクエリで受信したリストからアプリケーションサーバーの1つをランダムに選択し、その要求をアプリケーションに直接送信します。 http://www.zvnlb.net.
ネームサーバー ns1.zvnlb.net （この例では、フランクフルトにあります） ns2.zvnlb.net （私たちの例では、トロントにあります）着実にホストの実際のアプリケーションの健康状態をチェックしています www.zvnlb.net (192.235.113.3 や 194.23.52.21 私たちの場合には）。 もし ns1.zvnlb.net or ns2.zvnlb.net いくつかの実サーバの健全性ステータスをチェックする問題を検出すると、利用不可能なサーバは一定時間非アクティブ化され、そのIPアドレスは再び利用可能になるまでDNSクエリに表示されません。
次の図は、GSLB機能を使用して説明したDNSトラフィックを示しています。
データセンターの災害復旧のためのGSLBの設定
この構成は、災害復旧用のデータセンターの高可用性を必要とするサービスに推奨されるため、特定の会社のすべてのサービスが1つのデータセンターにあり、そのようなデータセンターで障害が発生すると、システムは影響を受けるすべてのサービスを別の使用可能なデータセンターに移動します。 。
このGSLB構成の実例に従って、災害復旧用のアクティブ - パッシブデータセンターを構築してください。
フランクフルトの異なるサイトにある2つのデータセンターに2つのZevenet Load Balancerを配置しました。 159.89.7.124 とトロント 159.203.12.35 DNSホストに応答するWebサービスがあります www.zvnlb.net、で設定 データセンター1 や データセンター2。 このアーキテクチャの設計は、すべてのクライアントトラフィックをに送信することを許可しようとしています。 データセンター1 それでも失敗した場合は、クライアントをにリダイレクトします。 データセンター2.
この設定を達成するためには下記の手順に従って下さい。
でZevenet Webパネルに接続します。 データセンター1 （私たちの場合はフランクフルト）、メインメニューをクリック GSLB モジュール化して新しいを作成する 牧場、私たちの例ではと呼ばれます DNS1-フランクフルト 仮想ポート内 53.
ファームが作成されたら、それを編集してタブに移動してください。 ゾーン この場合、GSLBモジュールによって管理されるDNSゾーンを作成します。 zvnlb.net、 次のように：
このゾーンが作成されたら、以下に示すように最初の構成を行ってください。
注意してください ns1 や ns2 ゾーンのDNS解決を担当するネームサーバー zvnlb.net （私たちの場合は、フランクフルトとトロントの2つのGSLBサービス）。
次に、データセンター2のZevenet Webパネルに接続し、メインメニューで次のように選択します。 GSLB 新しい 牧場、私達の場合では呼ばれます DNS2-トロント 仮想ポート内 53.
新しいGSLBファームを編集してタブに移動します ゾーンこのGSLBサービスによって管理されるDNSゾーンをここに作成します。 zvnlb.net 次のように：
この新しいゾーンが作成されたら、次のように最初の設定を行います。
GSLBの場合のように データセンター1ネームサーバ n1 や n2 両方のGSLBサービスを指すでしょう データセンター1 や データセンター2それぞれ。
次にタブをクリックします サービス たとえば、新しいサービスを作成します。 ウェブ優先:
現在地に最も近い アルゴリズム オプション 優先順位：常に利用可能な最も優先度の高いものへの接続 次のようにサービスを設定します。
ファームを再起動して変更を適用します。 両方のデータセンターで同じGSLBサービス構成を適用する必要があります。
もし 農場の保護者 ヘルスチェックを適用するように設定されていない場合、GSLBサービスはデフォルトを使用します。 check_tcp サービス設定のヘルスチェックフィールドで定義されているTCPポートへ。
新しいサービスを有効にするには、作成したゾーンに移動します（zvnlb.net 私たちの場合））を作成し、新しい リソース。 それから新しいを選択してそれを作成します カスタマーサービス 以下に示すように。
最後に、変更を保存します。 この構成を両方のデータセンターに適用する必要があります。
この時点で、ホストは www.zvnlb.net GSLBモジュールによって管理されている 優先 つまり、すべてのトラフィックは データセンター1 そしてそれが失敗した場合、トラフィックは利用可能な他のものにリダイレクトされます データセンター2.
TTLは5に設定されています。これは、DNSレコードに設定される一種の有効期限です。 TTLは、再帰サーバーまたはローカルリゾルバーに、そのレコードをキャッシュに保持する期間を通知する働きをします。 そのため、低い値を設定すると、変更が早く検出されます。
この方法を適用すると、GSLBサービスを備えた新しいネームサーバーを含めることで、必要なだけデータセンターを追加できます。
次のDNS要求は、のネームサーバー設定を示しています。 zvnlb.net とホストのDNS解決 www.zvnlb.net.
user@client:# host -t ns zvnlb.net zvnlb.net name server ns2.zvnlb.net. zvnlb.net name server ns1.zvnlb.net.
両方のネームサーバーは、GSLBファームに設定されている仮想IPアドレスを使用します。
今、あなたの現在のDNSサーバーを使ってホストを解決しましょう（例えば WWW）このゾーンで：
user@client:# nslookup www.zvnlb.net Server: 8.8.8.8 Address: 8.8.8.8#53 Non-authoritative answer: Name: www.zvnlb.net Address: 188.166.230.211
示されているように、現在ホスト 188.166.230.211 アクティブな実際のアプリケーションノードは データセンター1。 すぐにホストに到達できなくなります（たとえば、httpサービスが 188.166.230.211 ダウンしている）DNS解決は、以下に示すように変更されます。
user@client:# nslookup www.zvnlb.net Server: 8.8.8.8 Address: 8.8.8.8#53 Non-authoritative answer: Name: www.zvnlb.net Address: 139.59.186.84
アプリケーションサーバーに障害が発生するとすぐに、DNS解決によってホストが データセンター2。 一度ホストに データセンター1 起動すると、フェールバックが自動的に適用されます。
アクティブ - アクティブデータセンター用のGSLBの設定
モード優先度の高可用性はディザスタリカバリシステムに適したオプションですが、リカバリに使用されるバックアップデータセンターはあまり使用されないため、通常、使用可能なデータ間のすべてのトラフィックの負荷を分散する方が効率的です。センター。
そのような場合は、GSLBサービスの共有方法を使用してください。 ラウンドロビンロードバランシング と呼ばれる新しいサービスの例に示されているように ウェブ:
今、それをゾーンに追加します zvnlb.net リソース構成を変更します WWW 次のように：
変更を保存し、要求されたらファームを再起動します。
それをテストするには、ホストを解決してみます www.zvnlb.net 出力は次のようになります。
user@client:# nslookup www.zvnlb.net Server: 8.8.8.8 Address: 8.8.8.8#53 Non-authoritative answer: Name: www.zvnlb.net Address: 188.166.230.211 Name: www.zvnlb.net Address: 139.59.186.84
DNSリゾルバは、Disaster Recoveryの場合のように1つではなく両方のアプリケーションサーバを返すことに注意してください。
ホストに障害が発生すると、DNS解決は自動的に変わります。 何が起こるのか、下記を見てください。
root@client:# nslookup www.zvnlb.net Server: 8.8.8.8 Address: 8.8.8.8#53 Non-authoritative answer: Name: www.zvnlb.net Address: 139.59.186.84
使用不可のアプリケーションサーバーは、DNS応答リストから非アクティブ化されています。
ホストとしてすぐ 188.166.230.211 再び利用可能です、それはDNS解決に戻って含まれるでしょう。
Zevenet GSLBサービスでゾーンを委任する
パブリックゾーンの場合 zvnlb.net）GSLBサービスをネームサーバーリゾルバーとして提供し、そのようなドメインのパブリックDNSサーバーによって認識される必要がある場合は、GSLBサービスが使用するパブリックIPアドレスをドメインのレジストラ（NameCheap、Goddadyなど）に登録する必要があります。 。 次のリンクは、ドメインレジストラプロシージャでGSLBIPをネームサーバーとして登録する方法を説明しています。
与えられた手順に従って登録する必要があります ns1.zvnlb.net や ns2.zvnlb.net 与えられたIPで。
GSLB専用のサブゾーンを作成する
DNS解決をZevenetのGSLBサービスに委任できない場合に備えて、以下で説明する構成を実行できます。 次の例は、を構築する方法を示しています サブゾーン を用意しました zvnlb.net これは、GSLBサービス内のこの新しいサブゾーンのNameServersを指しています。
ノード1 （例えば ns1.zvnlb.net IPを使って 162.243.5.109）と ノード2 （例えば ns2.zvnlb.net IPを使って 178.62.233.104）ネームサーバーが設定され、ゾーンに対してDNS解決サービスを提供している zvnlb.netこのゾーンはBind9パブリックDNSサービスの下にあり、インフラストラクチャの一部のホストにGSLB機能を提供したいので、DNSサブゾーンを作成することにしました。 cluster.zvnlb.net この目的のために、DNSネームサーバーのような2 GSLBファームを構成します。
ドメイン用のサブゾーンを作成しました cluster.zvnlb.net 次のように私たちのBind9 DNSサーバーで：
今セクションに従ってください Zevenet GSLBサービスでゾーンを委任する 保つために 159.89.7.124 や 159.203.12.35 この例では、ゾーンの認識されたネームサーバーとして cluster.zvnlb.net パブリックDNSサーバーによって。
その後、ドメインについて説明したように設定を適用できます。 zvnlb.net 上のセクションで データセンターの災害復旧のためのGSLBの設定.
GSLBサービスを参照している私たち自身のDNS内のホストを指す
前のセクションでは、という名前のホストを作成しました。 www.zvnlb.net 優先モードとラウンドロビンモードでの負荷分散。この構成を再利用して、デフォルトでこの機能をサポートしていない別のDNSネームサーバーにGSLB機能を提供できます。
この設定を達成するために私達は新しいを作成する必要があるだけです リソース GSLBオプションをサポートしていないDNSゾーン（たとえば zevenet.io Bind9によって管理されている 正規名 or CNAME 以下に示すように：
変更が適用されたら、 www.zevenet.io 指しているでしょう www.zvnlb.netしかし、ホストの解像度が www.zvnlb.net 自動的に変わる www.zevenet.io 同様に変わるでしょう。
この例はBind9 DNSサーバーで行われていますが、Canonical NamesまたはCNAMESはすべてのDNSサーバーサービス実装によってサポートされているDNSホスト構成です。
この簡単な説明は、現在のDNSサービスがGSLB機能を提供していなくても、GSLBサービスを使用できることを示しています。非GSLBゾーンの特定のホストの解像度をZevenet LoadBalancerのGSLBサービスに転送するだけです。