dns - 将来を見据えたクライアントサーバーコード？

Question

Webベースのクライアントサーバー製品があります。クライアントは100万人以上のユーザーで使用されることが見込まれます（有名な会社が使用する予定です）。

私たちのサーバーはクラウドにセットアップされています。設計中の主要な質問の1つは、プログラム全体を将来にわたって利用できるようにする方法です。言う：

1. クラウドプロバイダーがダウンした後、自動的に別のクラウドのバックアップに移動します
2. 完全に別のサーバーに移動するなど

これまで考えていたオプションは次のとおりです。

1. DNS：自分たちでクラウド上でDNSネームサーバーを実行しています。
2. ディレクトリサーバー-ディレクトリサーバーもクラウド上に存在します
3. サーバーに将来の移動や将来のURLなどをクライアントに返してもらいます-クライアントはこれらのシナリオを処理するように特別に設計されています

これは通常の問題であるはずなので、同じための最良の解決策はどれですか？私たちの会社は非常に小さいので、技術的および経済的に最も安価なソリューション（たとえばオプション3など）を検討していますか？

誰かが同じものへのいくつかのポインタを提供できますか？

K

Answer 1

私はディレクトリサーバーオプションを選びます。その最も柔軟性があり、特定の状況で何が起こるかを最も制御できます。

ディレクトリ自体が単一障害点になるのを避けるために、3つまたは4つのディレクトリを異なるプロバイダーで異なる場所で実行します。クライアントアプリに、起動時にdirectoy URLの1つをランダムに選択させ、機能するものが見つかるまでそれらすべてを処理します。

将来にわたって利用できるようにするには、ディレクトリサーバーのリストを動的に更新するための単純なプロトコルが必要になる可能性がありますが、これが適切に実装されていない場合は、クライアントをあらゆる種類の悪意のあるなりすまし攻撃にさらすことになります。

Answer 2

再。DNS：リクエストはキャッシュでき、変更が反映されるまでに時間がかかる場合があります（数時間から数日）。

クライアントで更新できる優先IPのリストを探します。1つのIPに障害が発生した場合、クライアントは2番目、3番目などで再試行します。

Answer 3

あなたの質問を100％理解したかどうかはわかりませんが、要約すると、サーバーが移動した場合、クライアントはどのようにしてそれを見つけることができますか？

これは、DNSが過去30年近くに行ったこととまったく同じです。

選択できるすべての可能なシステムは、初期の作業データでブートストラップする必要があります。ディレクトリサーバーのアドレス、アドレスの更新されたリストを取得するための作業サーバーのアドレスなどです。これがルートDNサーバーの目的であり、OSベンダーが行います。あなたのためのブートストラップ部分。

確かに、DNSクエリはキャッシュされる可能性があります。これは、DNSクエリが機能する方法であり、インターネットサイズに合わせて拡張する方法です。キャッシングを制御し（TTLについて読んでください）、通常は適切な値に保つことができます（サーバーを別の場所に再デプロイするために必要な絶対最小時間よりも短くすることは意味がありません）。