分散型のマルチアクティブ データ センターは、DNS ドメイン名解決と負荷分散をどのように実装するのでしょうか?

今日のトピックでは、アクティブ/アクティブ データ アクセスの観点から、ドメイン名解決と負荷分散について説明します。

DNS ドメイン名解決は、B/S アプリケーション アーキテクチャの重要なサービスです。 C/S アーキテクチャ アプリケーションは通常、IP アドレスを介してサービスに直接アクセスします。クラウド コンピューティングの時代では、サービスは主に B/S、分散、マルチアクティブ アーキテクチャを通じて提供されます。ただし、Web サイト運営者やサービス プロバイダーにとって、DNS ドメイン名解決の安定性と信頼性は、ビジネス エクスペリエンスの向上と、アクセス トラフィックの向上と増加を意味します。

[[211090]]

クラウド コンピューティングと分散システムの発展に伴い、DNS は、マルチデータ センターや分散アプリケーション アーキテクチャにおける負荷分散およびフェイルオーバー アプリケーションにおいてますます重要になっています。今日は、DNS の概念、アプリケーション、原則を整理して分析します。

DNS は、ドメイン名と IP アドレスを相互にマッピングするインターネット上の分散データベースです。 DNS を使用すると、ユーザーは煩雑で扱いにくい IP 番号文字列を覚える必要がなくなり、インターネットやアプリケーションに便利にアクセスできるようになります。ドメイン名を通じてドメイン名に対応する IP アドレスを取得するプロセスをドメイン名解決と呼びます。次の図は、DNS ドメイン名解決のプロセス全体を詳細に示しています。

1. 通常は、コンピューターのブラウザを開き、ドメイン名を入力します。たとえば、www.163.com と入力すると、コンピューターはローカル DNS サーバーに DNS 要求を送信します。ローカル DNS サーバーは通常、China Telecom や China Mobile などのネットワーク アクセス サーバー プロバイダーによって提供されます。

2. www.163.com を照会する DNS 要求がローカル DNS サーバーに到達すると、ローカル DNS サーバーはまずキャッシュ レコードを照会します。キャッシュ内にこのレコードがある場合は、結果を直接返すことができます。そうでない場合、ローカル DNS サーバーは DNS ルート サーバーにクエリを実行します。

3. ルート DNS サーバーは、ドメイン名と IP アドレスの具体的な対応関係を記録しませんが、ドメイン サーバーでクエリを続行できることをローカル DNS サーバーに伝え、ドメイン サーバーのアドレスを提供します。

4. ローカル DNS サーバーはドメイン サーバーに要求を送信し続けます。この例では、リクエストは .com ドメイン サーバーに送信されます。 .com ドメイン サーバーは、リクエストを受信すると、ドメイン名と IP アドレスの対応関係を直接返すのではなく、ドメイン名の解決サーバーのアドレスをローカル DNS サーバーに伝えます。

5. 最後に、ローカル DNS サーバーはドメイン名解決サーバーに要求を送信し、ドメイン名と IP アドレスの対応関係を受信できます。ローカル DNS サーバーは、ユーザーのコンピューターに IP アドレスを返すだけでなく、この対応をキャッシュに保存します。これにより、他のユーザーが次にクエリを実行するときに、結果を直接返すことができ、ネットワーク アクセスが高速化されます。

実は、インターネット上の DNS サーバーも階層的に配置されています。各ドメイン ネーム サーバーは、ドメイン ネーム システムの一部のみを管理します。ドメイン ネーム サーバーが果たす役割に応じて、ドメイン ネーム サーバーは、ルート ドメイン ネーム サーバー、トップ ドメイン ネーム サーバー、権威ドメイン ネーム サーバー、およびローカル ドメイン ネーム サーバーの 4 つの異なるタイプに分けられます。

ルート ドメイン ネーム サーバーは、最高レベルのドメイン ネーム サーバーであり、最も重要なドメイン ネーム サーバーです。すべてのルート ドメイン ネーム サーバーは、すべてのトップ ドメイン ネーム サーバーのドメイン名と IP アドレスを認識しています。どのローカル ドメイン ネーム サーバーを使用する場合でも、インターネット上のドメイン名を解決する場合は、自分で解決できない限り、まずルート ドメイン ネーム サーバーに支援を求めることになります。したがって、ルート ドメイン ネーム サーバーは最も重要なドメイン ネーム サーバーです。すべてのルート ドメイン ネーム サーバーがダウンしていると仮定すると、DNS システム全体が機能しなくなります。

DNS 解決を構成するときは、DNS 解決の TTL (Time To Live) パラメータを指定する必要があります。このパラメータは、ローカル DNS サーバーにドメイン名キャッシュの最大時間を指示します。 Alibaba Cloud Resolution を例に挙げてみましょう。 Alibaba Cloud Resolution のデフォルトの TTL は 10 分です。 10 分は、ローカル DNS サーバーがドメイン名を 10 分間キャッシュすることを意味します。 10 分後、ローカル DNS サーバーはレコードを削除します。削除後、ユーザーがドメイン名にアクセスする場合、上記の複雑なプロセスを繰り返す必要があります。

ウェブサイトが安定した開発状態に入り、IP アドレスが簡単に変更されない場合は、TTL をプロトコルの最高値である 24 時間に設定できます。利点は、ドメイン名解決レコードをローカル DNS サーバーに長期間保存できるため、すべてのユーザーのアクセスが高速化されることです。

分散型のマルチアクティブ データ センターが外部データ サービスを提供する場合、別のパラメーター RTT (ラウンド トリップ時間) が関係します。物理的に隔離されたエリア A と B にあるデータ センターが同時に外部にサービスを提供する場合、顧客のサービス要求にデータ センター A が応答するか、データ センター B が応答するかは、どちらの RTT が小さくなるかによって決まります。例を通して技術的な原理を分析してみましょう。

1. まず、クライアントはオペレータのローカル DNS に対して www.abc.com ドメイン名の DNS 要求を開始します。

2. オペレータのローカル DNS サーバーは、RootDNS から、www.abc.com が DNS-CTC、DNS-CNC、DNS-USA1、および DNS-USA2 によって解決されることを学習します。つまり、RootDNS はこれらの 4 つの DNS サーバーのアドレスを同時にローカル DNS に返します (DNS の動作原理では、要求に関するすべてのレコードを返す必要があるため、4 つの DNS サーバーを返すことになります。返される DNS が 1 つだけで、この DNS がサービス停止中の場合、ローカル DNS は解決に失敗する可能性があります)。

3. ローカル DNS ポーリングは、データが返されるまで、これらの 4 つの DNS サーバーにドメイン名解決要求を送信します。

4. ここで、DNS-CTC がローカル DNS のドメイン名解決要求に応答すると、2 つの GTM (ローカル リスニング Web サービス) のアドレスを同時に返します。

5. ローカル DNS 要求を受信すると、GTM はまず、ローカル DNS の近接エントリがローカルに存在するかどうかを照会します。そうであれば、最も高速なサーバー アドレスをローカル DNS に直接返します。存在しない場合は、別の GTM に通知され、ローカル DNS のクエリが開始されます。

6. 2 つの DNS がそれぞれローカル DNS をプローブします。たとえば、GTM-A がローカル DNS を照会する RTT 時間が 50 ミリ秒で、GTM-B が同じローカル DNS を照会する RTT 時間が 100 ミリ秒の場合、ローカル DNS の対応する近接テーブル レコードが両方の GTM に形成されます。

7. 近接原則に基づき、ローカル DNS によって要求された GTM-A は、システムの近接テーブルに従って、対応するデータセンター内の Web サーバー アドレス (つまり 1.1.1.1) を返します。

8. ローカル DNS はアドレスを取得した後、そのアドレスをユーザーに返し、DNS 要求プロセスが終了します。

9. ユーザーはウェブサイト www.albc.com (1.1.1.1) へのアクセスを開始します。

分散型のマルチアクティブ データ センターでは、1 つのドメイン名が 2 つのビジネス IP アドレスに対応し、それぞれ 2 つのデータ センターに展開されます。 GSLB または DNS を使用して、サイト間のアクセス負荷分散を実現します。

GSLB は専用の F5 GTM デバイスを使用できます。業務量が少ない場合は、Windows に付属の DNS サーバーを使用して、単純な負荷分散 (ポーリング) を実現することもできます。通常、GSLB クロスサイト負荷分散戦略は 2 つあります。

1. ローカル DNS 要求の地理的な場所に基づきます。

2. GSLB とローカル DNS に基づく RTT は最小です。

GSLB は、主に近接性判断を使用して、ネットワーク全体の中で最も近いノード (またはエリア) にユーザー要求を送信します。主な方法には、DNS、アプリケーション層リダイレクト、トランスポート層リダイレクトなどがあります。ただし、SLB は主にサービス ノードの範囲内にあり、デバイス ノードの状態、現在の負荷、サービス容量、分布などに基づいて、ユーザー要求を特定のサービス ノード デバイスに割り当てます。