☰

冗長ロードバランサーを作成するにはどうすればよいですか?

tag-icon • tag-icon nginx load-balancing redundancy load-balance
冗長ロードバランサーを作成するにはどうすればよいですか?

ロード バランサーの目的は、サーバー間の負荷を分散し、インスタンスの状態などを追跡することだと理解しています。しかし、ロード バランサー自体に障害が発生した場合はどうなりますか? 冗長ロード バランサーをどのように設定しますか? (ロード バランサーの負荷分散?)

DNS ヘルスチェックが役に立つことはわかりますが、明らかに大きな遅延の問題があるのではないですか?

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

答え1

ロード バランサー、あるいはあらゆるサービスの 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 のアドバタイズを停止することだけです。

答え2

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

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

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

お役に立てれば。

答え3

ハードウェア ロード バランサは長年にわたり「アクティブ/パッシブ」または「アクティブ/アクティブ」設定をサポートしてきましたが、どちらの場合も、レイヤ 1/2 の観点からは並列に設定されます... アクティブ/パッシブは、前述のように監視/キープアライブ メカニズムを使用し、アクティブ/アクティブはさまざまな方法で実装できます。フロントエンドで単一の IP として表示されるように、2 つ以上のバランサは、すべてまたは両方がオンラインである限り、次のような処理を実行します。

  • クライアントが同じネットワーク上にある場合、送信元MACアドレスまたはIPアドレスに基づいて共有IPへのARP要求に選択的に応答する
  • 与えられた新しいTCP接続のトラフィックを誰が処理するかを互いに交渉する
  • 重複またはエラーのあるレイヤー3～7トラフィックが無謀に発生し、クライアント/ルーターTCPスタックに依存して整理される

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

バックエンド側:

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

関連情報