web-dev-qa-db-ja.com

複数のロードバランサーを使用してトラフィックをアプリケーションサーバーにリダイレクトすることはできますか？

ロードバランシングは初めてですが、複数のロードバランサーを使用してトラフィックをアプリケーションサーバーにリダイレクトできるかどうか疑問に思っています。どうすればいいのか分かりません。ドメイン名は、特定のサーバーのIPアドレス（この場合は1つのロードバランサーのIP）と1対1で一致する必要はありませんか？各ロードバランシングサーバーのIPが異なる場合、両方のロードバランサー（または10ロードバランサーまたは50または100）がリクエストをどのように受信できますか？

domain-name-systemnginxload-balancinghaproxyhigh-load
9
user3790827

ラウンドロビンDNSの使用は、高可用性にとってそれほど優れたものではありません。1つのサーバーがオフラインになった場合でも、クライアントはそのサーバーに接続を試み、タイムアウトを待機します。

これを達成する他の方法があります。
1）アクティブ/パッシブロードバランサー
基本的に、1つのロードバランサーが1つのIPアドレスのすべてのトラフィックを処理します。
そのバランサーがダウンすると、パッシブノードが飛び込み、IPを引き継ぎます。
ロードバランサはほとんどトラフィックを転送するだけなので、小規模から中規模のサイトでは問題なく機能することに注意してください。

2）アクティブ/アクティブロードバランサー
同じトラフィックIPが両方（またはそれ以上）のロードバランサーで構成されています。
受信トラフィックはすべてのロードバランサーに送信されますが、アルゴリズムはどのバランサーが応答するかを選択し、他のすべてはそのトラフィックを破棄します。
簡単に考えると、2つのロードバランサーがあります。
リクエスト元のIPが偶数で終わる場合、ロードバランサーAが応答し、そうでない場合、ロードバランサーBが応答します。

もちろん、インフラストラクチャがこれをサポートする必要があり、トラフィックが送信されても​​破棄されるためにオーバーヘッドが発生します。
詳細情報。ここ： http://community.brocade.com/t5/SteelApp-Docs/Feature-Brief-Deep-dive-on-Multi-Hosted-IP-addresses-in-Stingray/ta-p/73867

12
faker

ロードバランサーを使用した高可用性は、一般的に 仮想IPアドレス （VIP）プロトコルを使用して実装されます。 /パッシブ、アクティブ/アクティブ）。

これらのプロトコルにはかなりの数がありますが、通常のロードバランサーで最も多く見たのは [〜＃〜] vrrp [〜＃〜] と [〜＃〜] nlb [です。 〜＃〜] （およびアプライアンスの多くの説明のないブラックボックス化プロトコル）。ルーターやファイアウォールに拡張すると、 [〜＃〜] carp [〜＃〜] 、 [〜＃〜] hrsp [〜＃〜] 、 [〜＃〜] glsp [〜＃〜] たとえば。

この戦略には、DNS負荷分散よりも多くの利点があります。これは、より単純な戦略です（別の答えで対処されます）。

DNSロードバランシングは、たとえば次のような負荷がかかります。

  • dNSキャッシングメカニズムのターンオーバーが遅い
  • 制限された負荷分散アルゴリズム（通常はラウンドロビンのみ）
  • クライアントへの負荷分散決定のアウトソーシング（dnsレコードのキャッシュを介して）
  • サーバー（つまり、ロードバランサー）がローテーションから外れると、サービスキューのドレインが遅くなります（DNSレコードTTLに基づいて、ISPおよびクライアントによって処理されます）
  • ロードバランサー障害時のフェイルオーバーが遅い

HAに仮想IPプロトコルを使用することで、たとえば、次のような選択を行うことができます。

  • ロードバランサー間のロードバランシングアルゴリズムの選択
  • サーバー中心の負荷分散の決定（たとえば、サービスの状態に基づく測定とルーティングを容易にする）
  • ロードバランサーがローテーションから外れた場合のサービスキューの迅速なドレイン。
  • ロードバランサーの障害時のインスタントフェイルオーバー

シナリオに最も適した戦略とプロトコルを知っているのはあなただけです。

6
ErikE

要件：クラウドまたはハードウェアロードバランサー、BGPプロトコルなどにアクセスできない、あらゆるタイプの環境で機能する実用的なソリューションを用意します。

アプリケーションの収入要求番号は不明ですが、恐れることなく増加する負荷の期待に応えるのに十分な高さである必要があります。

ログストアや検索アプリなど、同様の負荷の性質を持つアプリケーションを見つけましょう。 one が見つかりました。

彼らが望むこと：

  1. コレクタ間で負荷を分散する
  2. フォールトトレランスを提供し、コレクターの1つが停止した場合や問題が発生した場合でもデータの取り込みを継続できるようにします
  3. ログ量の増加に合わせて水平方向にスケーリングします

彼らはELBについて何を試して学びましたか：

  1. 期待どおりに機能しない
  2. 負荷の増加による待ち時間の問題
  3. 十分な監視機能がない
  4. 制限が多すぎる（開いているポートとプロトコルの数）

Route53を選んだ理由：

  1. 「ラウンドロビンはかなり基本的なロードバランシングですが、効率の観点からはうまく機能します。」
  2. 「Route 53フェイルオーバーヘルスチェックを利用しています。」
  3. 「コレクターに問題がある場合、Route 53は自動的にそれをサービスから除外します。お客様には影響がありません。」
  4. Route 53では事前ウォームアップは不要

Route 53は、膨大なログボリューム、予測できない変動、およびビジネスの絶え間ない成長を考えると、Logglyが高性能コレクターを活用するための最良の方法であることが判明しました。これは、コレクターの主要な目的と一致します。データをネットワーク回線速度で損失なしで収集することにより、Logglyで使用するすべてのAWSサービスの弾力性を活用できます。

この特定の例は、一部のシナリオ（ログコレクター、広告サービスなど）でロードバランサーが冗長であり、「DNSヘルスチェックラウンドロビンソリューション」が非常にうまく機能することを示しています。

どのAWS say re DNS failoverを見てみましょう：

DNSフェイルオーバーを使用すると、Route 53はWebサイトの停止を検出し、エンドユーザーを指定した代替またはバックアップの場所にリダイレクトできます。 Route 53 DNSフェイルオーバーは、世界中の複数の場所から定期的にアプリケーションエンドポイントへのインターネット要求を行うヘルスチェックに依存して、アプリケーションの各エンドポイントがアップしているかダウンしているかを判断します。

その手法はまた、ELB（メモのためだけに必要ではない）をより堅牢にします。これも、RR +ヘルスチェックに基づいています。

Route 53 DNSフェイルオーバーは、舞台裏でELBと統合することにより、これらすべての障害シナリオを処理します。 Route 53を有効にすると、個々のELBノードのヘルスチェックが自動的に構成および管理されます。

仕組み を舞台裏で見てみましょう。明らかな問題は、DNSキャッシングの処理方法です。

ただし、TTLがクライアントとRoute 53の間のすべてのレイヤーで尊重されていない場合は、ここでもDNSキャッシュが問題になる可能性があります（以前の投稿の「ロングテール」問題が取り上げられている以前の投稿を参照））。次に、「キャッシュ無効化」手法を適用します。リクエストを一意のドメインに送信します

("http://<unique-id>.<your-domain>")

ワイルドカードリソースを定義します

Record "*.<your-domain>" to match it.

Algolia 導入済み "クライアント再試行戦略"これは、クライアント（あなたの場合はJS）がそれを処理できる場合に非常にうまく機能します。

最終的に、APIクライアントに基本的な再試行戦略を実装しました。各APIクライアントは、3つの異なるマシンにアクセスできるように開発されました。各ユーザーを表す3つの異なるDNSレコード：USERIDID-1.algolia.io、USERID-2.algolia.ioおよびUSERID-3.algolia.io。最初の実装では、レコードの1つをランダムに選択し、失敗した場合は別のレコードで再試行しました。

2
Anatoly