冗長ロードバランサーの作成方法


27

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

DNSヘルスチェックがどのように役立つかはわかりましたが、明らかに大きな遅延の問題がありますよね?

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


何もありません「ロードバランサをロードバランシング」あなたのアーキテクチャの最上部にはあなただけで、ほとんどのクラスタリング類型学がそうであるように、あなたのLBが冗長とハンドル障害に対する高可用性ソリューションを設定します。
ザビエルルーカス

回答:


32

Load Balancerの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つのキープアライブが応答を停止した場合(何らかの理由でサービスがダウンした場合、またはボックスがバウンスまたはシャットダウンした場合)-他のボックスでキープアライブされた場合、ハートビートが失われていることに気付き、他のノードが死んでいると推定し、フェイルオーバーアクションを実行します。この場合のアクションは、フローティングIPを起動することです。

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

この場合に発生する可能性のある最悪のケースは、クライアントのセッションの損失ですが、クライアントは再接続できます。それを避けたい場合は、2つのロードバランサーがそれらの間でセッションデータを同期できる必要があります。そうすることができる場合、ユーザーは少し遅れて壊れる以外に何も気付かないでしょう。

このセットアップの別の落とし穴はスプリットブレインです。両方のボックスがオンラインであるが、リンクが切断され、両方のボックスが同じIPを表示する場合です。多くの場合、これは何らかの種類のフェンシングメカニズム(SCSI予約、IPMI再起動、スマートPDUの電源切断など)、またはサービスを開始するためにクラスターメンバーの大半が稼働している必要がある奇数のノードによって解決されます。

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

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

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


3

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

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

理論的には、HA環境がある場合、クラスター化された複数のロードバランサーは、1つが失敗した場合にサービスを維持できるようにする必要があります。

お役に立てれば。


2

ハードウェアロードバランサーは、長年にわたって「アクティブ/パッシブ」または「アクティブ/アクティブ」セットアップをサポートしてきました。どちらの場合も、レイヤー1/2の観点から並行してセットアップされます。 、アクティブ/アクティブはさまざまな方法で実装できます。フロントエンドで単一のIPとして表示するには、2つ以上のバランサーが、すべて/両方がオンラインである限り、次のようなことを行います。

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

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

バックエンド側で:

  • 各バランサーは、通常の動作では、アプリケーションサーバーの特定のサブプールのみを使用する場合があります。
  • または、重複したリクエストが単にここでも生成される可能性があります...
  • または、バランサー間のネゴシエーションが行われる可能性があります
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.