グローバルサービスロードバランシングGSLBの機能

投稿者 Zevenet | 16年2018月XNUMX日

GSLBの概要

今日、ITサービスの高可用性は必須であり、それが企業や組織が世界中に分散したコンピューティングシステムを開発し、複数のデータセンターでサービスをホストする理由は次のとおりです。

フォールトトレランス:データセンターでホストされているサービスが失敗すると、そのサービスは他の利用可能なサイトのいずれかで続行されます。
自動データセンター復旧:1つのデータセンターに障害が発生すると、サービスは他の利用可能なデータセンターに自動的にリダイレクトされます。
ロードバランシング:利用可能なすべてのサイトに負荷を分散することでトラフィックを最適化し、待ち時間を短縮し、サービス配信を高速化することができます。
改善された待ち時間:クライアントアプリケーションのトラフィックは実サーバーと直接やり取りされるため、すべてのアプリケーションデータをロードバランサに渡す必要はありません。

クラウドでのITサービスの採用と実装には、WANベースの方法が、地理的に高い場所にある高可用性ソリューションを提供するための最良の選択肢であることが必要です。 それが私たちが呼ぶものです グローバルサービスロードバランシング or GSLB.

GSLBを使用する場合

GSLBサービスは、以下のユースケースに使用することをお勧めします。

WANを介して複数のデータセンターでサービスをホストしている企業。
高可用性のサービスまたはデータセンターを作成する必要がある企業。
ユーザーが使用するインバウンド負荷分散サービスを作成するためのインターネットサービスプロバイダ。

間違いなく、障害が発生することなく世界中のサーバー間でユーザーとトラフィックを共有する必要がある場合、GSLBは正しいソリューションです。

GSLBはどのように機能しますか

GSLB 負荷分散メカニズム DNS それが使用するのでプロトコル、それは速くそして信頼できます UDP プロトコルとクライアントの応答はほぼリアルタイムです。

たとえば、一般的なDNS要求では www.zvnlb.netクライアントは、ローカルに設定されたDNSサーバーにDNS要求解決を送信します(たとえば、 8.8.8.88.8.4.4 そして、クライアントシステムは、要求に対抗してクエリを送信するためにサーバのうちの1つをランダムに選択する。

選択したDNSサーバーがクライアントからの要求を受信します(たとえば、IPアドレスは www.zvnlb.net? )そしてローカルに設定されたDNSサーバーは誰がDNSゾーンを解決する責任があるかを見つけようとします zvnlb.net.

クライアントが使用しているDNS 8.8.8.8 or 8.8.4.4 この場合は、 ns1.zvnlb.netns2.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.3194.23.52.21 私たちの場合には)。 もし ns1.zvnlb.net or ns2.zvnlb.net いくつかの実サーバの健全性ステータスをチェックする問題を検出すると、利用不可能なサーバは一定時間非アクティブ化され、そのIPアドレスは再び利用可能になるまでDNSクエリに表示されません。

次の図は、GSLB機能を使用して説明した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.

1つのデータセンターにGSLBファームを作成する

ファームが作成されたら、それを編集してタブに移動してください。 ゾーン この場合、GSLBモジュールによって管理されるDNSゾーンを作成します。 zvnlb.net、 次のように:

最初のデータセンターにGSLBゾーンを作成する

このゾーンが作成されたら、以下に示すように最初の設定を行ってください。

最初のデータセンターのGSLB編集ゾーン

注意してください ns1ns2 ゾーンのDNS解決を担当するネームサーバー zvnlb.net (私たちの場合は、フランクフルトとトロントの2つのGSLBサービス)。

次に、データセンター2のZevenet Webパネルに接続し、メインメニューで次のように選択します。 GSLB 新しい 農場、私達の場合では呼ばれます DNS2-トロント 仮想ポート内 53.

2番目のDRデータセンターにGSLBファームを作成する

新しいGSLBファームを編集してタブに移動します ゾーンこのGSLBサービスによって管理されるDNSゾーンをここに作成します。 zvnlb.net 次のように:

2番目のデータセンターでGSLBゾーンを設定

この新しいゾーンが作成されたら、次のように最初の設定を行います。

トロントのGSLB編集ゾーン

GSLBの場合のように データセンター1ネームサーバ n1n2 両方のGSLBサービスを指すでしょう データセンター1データセンター2それぞれ。

次にタブをクリックします Services たとえば、新しいサービスを作成します。 ウェブ優先:

優先的にGSLBサービスを作成する

現在地に最も近い アルゴリズム オプション 優先順位:常に利用可能な最も優先度の高いものへの接続 次のようにサービスを設定します。

GSLB編集サービスの優先順位

ファームを再起動して変更を適用します。 両方のデータセンターで同じGSLBサービス構成を適用する必要があります。

もし 農場の保護者 ヘルスチェックを適用するように設定されていない場合、GSLBサービスはデフォルトを使用します。 check_tcp サービス設定のヘルスチェックフィールドで定義されているTCPポートへ。

新しいサービスを有効にするには、作成したゾーンに移動します(zvnlb.net 私たちの場合))を作成し、新しい リソース。 それから新しいを選択してそれを作成します サービス 以下に示すように。

GSLBはサービス優先度を使用

最後に、変更を保存してください。 両方のデータセンターでこの設定を適用する必要があります。

この時点で、ホストは 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サービスの共有方法を使用してください。 ラウンドロビンロードバランシング という新しいサービスの例にあるように ウェブ:

共有データセンターとアクティブデータセンターでGSLBサービスを構築

今、それをゾーンに追加します zvnlb.net リソース構成を変更します WWW 次のように:

ラウンドロビンでGSLBサービス用のDNSリソースを作成する

変更を保存し、要求されたらファームを再起動します。

それをテストするには、ホストを解決してみます 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)そのようなドメインのパブリックDNSサーバーによって認識される必要があるネームサーバーリゾルバーとしてGSLBサービスを提供し、それはそれからあなたのドメインのレジストラにGSLBサービスによって使用されるパブリックIPアドレスを登録することを要求されます。 。 次のリンクでは、ドメインレジストラー手順でGSLB IPをNameServerとして登録する方法について説明しています。

ホストをネームサーバーとして登録する

与えられた手順に従って登録する必要があります ns1.zvnlb.netns2.zvnlb.net 与えられたIPで。

GSLB専用のサブゾーンを作成する

念のために、DNS解決をZevenetのGSLBサービスに委任することができない場合は、以下に説明する設定を実行することができます。 次の例は、ビルド方法を示しています。 サブゾーン for 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サーバーで:

bind9 DNSサブゾーンを作成します。

今セクションに従ってください Zevenet GSLBサービスでゾーンを委任する 保つために 159.89.7.124159.203.12.35 この例では、ゾーンの認識されたネームサーバーとして cluster.zvnlb.net パブリックDNSサーバーによって。

その後、ドメインについて説明したように設定を適用できます。 zvnlb.net 上のセクションで データセンターの災害復旧のためのGSLBの設定.

GSLBサービスを参照している私たち自身のDNS内のホストを指す

前のセクションでは、という名前のホストを作成しました。 www.zvnlb.net 優先度とラウンドロビンモードでの負荷分散なので、デフォルトではこの機能をサポートしていない別のDNSネームサーバにGSLB機能を提供するためにこの設定を再利用できます。

この設定を達成するために私達は新しいを作成する必要があるだけです リソース GSLBオプションをサポートしていないDNSゾーンで zevenet.io Bind9によって管理されている 正規名 or CNAME 以下に示すように:

GSLBゾーンへのCNAMEを作成する

変更が適用されたら、 www.zevenet.io 指しているでしょう www.zvnlb.netしかし、ホストの解像度が www.zvnlb.net 自動的に変わる www.zevenet.io 同様に変わるでしょう。

この例はBind9 DNSサーバーで行われていますが、Canonical NamesまたはCNAMESはすべてのDNSサーバーサービス実装によってサポートされているDNSホスト構成です。

この簡単な説明は、現在のDNSサービスがGSLB機能を提供していない場合でも、GSLBサービスを使用できることを示しています。非GSLゾーン内の特定のホストの解決をZevenet Load BalancerのGSLBサービスに転送するだけです。

上の共有:

GNU Free Documentation Licenseの条項に基づくドキュメンテーション。

この記事は役に立ちましたか?

関連記事