web-dev-qa-db-ja.com

冗長ロードバランサーを作成する方法？

ロードバランサーの目的は、サーバー間で負荷を分散し、インスタンスの正常性などを追跡することであると理解しています。しかし、ロードバランサー自体が失敗した場合はどうなりますか？冗長ロードバランサーをどのように設定しますか？ （ロードバランシングロードバランサー？）

DNSヘルスチェックがどのように役立つかはわかりましたが、明らかに大きなレイテンシの問題がありますよね。

これは、AWS ELBなどのサードパーティのサービスを使用していないことを前提としています。 Nginxだけを使用している場合はどうしますか？

nginxload-balancingredundancyload-balance
28
Sherzod

ロードバランサーのHA（高可用性）を実現するには、いくつかの方法があります。または、サービスに関しては、いくつかの方法があります。 IPアドレスが設定された2台のマシンがあるとします。

  • 192.168.100.101
  • 192.168.100.102

ユーザーはIPに接続するので、実行したいことは特定のボックスからIPを分離することです。たとえば、仮想IPを作成します。そのIPは192.168.100.100になります。

これで、IPアドレスの自動フェイルオーバー/フェイルバックを処理するHAサービスを選択できます。 unixの最も単純なサービスには、（u）carpとkeepalivedがあります。たとえば、RedHat Cluster SuiteやPacemakerなど、より複雑なサービスがあります。

Keepalivedを例にしてみましょう-2つのkeepalivedサービス-それぞれが独自のボックスで実行されており、それらは一緒に通信します。その通信はしばしばハートビートと呼ばれます。

|   VIP   |                           |         |
|  Box A  | ------v^-----------v^---- |  Box B  |
|   IP1   |                           |   IP2   |

1つのkeepalivedが応答を停止した場合（何らかの理由でサービスが停止するか、ボックスがバウンスまたはシャットダウンする）、他のボックスでkeepalivedがハートビートの欠落に気づき、他のノードが停止していると見なして、フェイルオーバーアクションを実行します。私たちの場合、そのアクションはフローティングIPを表示します。

                                      |   VIP   |
    ------------------ -------------- |  Box B  |
                                      |   IP2   |

この場合に起こり得る最悪のケースは、クライアントのセッションの損失ですが、クライアントは再接続できます。それを避けたい場合は、2つのロードバランサーがセッションデータを同期できる必要があります。同期できる場合、ユーザーは少しの遅れを除いて何も気付きません。

このセットアップのもう1つの落とし穴は、スプリットブレインです。両方のボックスがオンラインであるが、リンクが切断されており、両方のボックスで同じIPが表示される場合です。これは多くの場合、何らかのフェンシングメカニズム（SCSI予約、IPMI再起動、スマートPDUパワーカットなど）、またはサービスを開始するためにクラスターメンバーの大部分を有効にする必要がある奇数のノードによって解決されます。

|   VIP   |                           |   VIP   |
|  Box A  |                           |  Box B  |
|   IP1   |                           |   IP2   |

より複雑なクラスター管理ソフトウェア（Pacemakerなど）はサービス全体を移動できます（例：1つのノードで停止して別のノードで開始）-これはデータベースのようなサービスのHAを実現する方法です。

別の可能な方法-ロードバランサーの近くにあるルーターを制御している場合は、ECMPを利用します。このアプローチでは、ロードバランサーを水平方向にスケーリングすることもできます。これは、2つのボックスのそれぞれがルーターとBGPを通信することで機能します。各ボックスは仮想IP（192.168.100.100）を通知する必要があり、ルーターはECMPを介してトラフィックの負荷を分散します。マシンが停止すると、VIPのアドバタイズが停止し、ルーターがそのマシンにトラフィックを送信できなくなります。この設定で注意する必要があるのは、ロードバランサー自体が停止した場合にIPのアドバタイズを停止することだけです。

33
Jakov Sosic

ロードバランサーとしてNginxを使用すると、構成を変更して無応答タイムアウトを検出することにより、この投稿で詳しく説明されているリダイレクトに従うことができます。

nginx自動フェイルオーバーロードバランシング

理論的には、HA環境がある場合、クラスター化された複数のロードバランサーにより、サービスに障害が発生した場合でもサービスを維持できるはずです。

お役に立てれば。

3
user4657

ハードウェアロードバランサーは、「アクティブ/パッシブ」または「アクティブ/アクティブ」セットアップを何年もサポートしてきました。どちらの場合も、レイヤー1/2の観点から並行してセットアップされます...アクティブ/パッシブは、説明されているようにモニタリング/キープアライブメカニズムを使用します、アクティブ/アクティブは、さまざまな方法で実装できます。フロントエンドで単一のIPとして表示するには、すべてまたは両方がオンラインである限り、2つ以上のバランサーが次のようなことを行う可能性があります。

  • クライアントが同じネットワーク上にある場合、ソースMACまたはIPアドレスの所有に基づいて、共有IPへのARP要求に選択的に応答します
  • 特定の新しいTCP接続のトラフィックを処理するお互いの間で交渉します
  • 重複または誤ったレイヤー3〜7のトラフィックを無謀に発生させ、クライアント/ルーターに依存させるTCPスタックで整理する

そして、パートナーデバイスとの通信が失われたときに、すべてのトラフィックを受け入れるようにモードを変更します。

バックエンド側：

  • 各バランサーは、通常の操作では、アプリケーションサーバーの特定のサブプールのみを使用する場合があります。
  • または、重複したリクエストがここでも生成される可能性があります...
  • または、バランサー間の交渉が行われる可能性があります
2
rackandboneman