25

ロード バランサーを使用してトラフィックを分散する Amazon で実行されているサーバー インスタンスのクラウドがあります。現在、ブラウザ側で接続エラーを引き起こすことなく、ネットワークを適切にスケールダウンする良い方法を探しています。

私の知る限り、ロードバランサーから削除されると、インスタンスの接続は無作法に終了します。

インスタンスがシャットダウンされる 1 分前にインスタンスに通知する方法、またはロード バランサーが死にかけているインスタンスへのトラフィックの送信を停止する方法が必要ですが、既存の接続を終了する必要はありません。

私のアプリは、Ubuntu 上で動作する node.js ベースです。また、いくつかの特別なソフトウェアを実行しているので、node.js ホスティングを提供する多くの PAAS を使用したくありません。

ヒントをありがとう。

4

6 に答える 6

17

これは古い質問であることは承知していますが、Amazon が最近 のサポートを追加したことに注意してくださいconnection draining。つまり、インスタンスがロードバランサーから削除されると、インスタンスは、インスタンスがロードバランサーから削除される前に進行中だったリクエストを完了します。 . 削除されたインスタンスに新しいリクエストがルーティングされることはありません。これらのリクエストにタイムアウトを指定することもできます。つまり、タイムアウト ウィンドウよりも長く実行されるリクエストは最終的に終了します。

この動作を有効にするにInstancesは、ロードバランサーのタブに移動してConnection Draining動作を変更します。

于 2014-04-09T09:46:55.650 に答える
16

このアイデアは、ELB の機能を使用して異常なノードを検出し、プールから削除しますが、以下の仮定で期待どおりに動作する ELB に依存しています。これは、私が自分でテストすることを意味しているものですが、まだ時間がありません. 私がそうするとき、私は答えを更新します。

プロセスの概要

次のロジックは、ノードをシャットダウンする必要があるときにラップして実行できます。

  1. nodeX への新しい HTTP 接続をブロックしますが、既存の接続は引き続き許可します
  2. アプリケーションへの既存の接続を監視するか、「安全な」時間を確保して、既存の接続が排出されるのを待ちます。
  3. EC2 API を直接使用するか、抽象化されたスクリプトを使用して、nodeX EC2 インスタンスでシャットダウンを開始します。

アプリケーションによっては「安全」と判断できない場合があります。

テストが必要な前提

ELB が異常なインスタンスをプールから削除することはわかっています。

  1. 最近閉じられたポートへの新しい接続は、プール内の次のノードに正常にリダイレクトされます
  2. ノードが Bad とマークされている場合、そのノードへのすでに確立されている接続は影響を受けません。

可能なテストケース:

  • ELB で HTTP 接続を起動し (例: curl スクリプトから)、ノードの HTTP ポートの 1 つをスクリプトで開いたり閉じたりする際の結果をログに記録します。ELB が状態の変化を常に判断できる許容可能な時間を見つけるために実験する必要があります。
  • 新しい HTTP 接続をブロックしている間、長い HTTP セッション (ファイルのダウンロードなど) を維持します。長いセッションが続くことを願っています。

1. HTTP 接続をブロックする方法

nodeX でローカル ファイアウォールを使用して新しいセッションをブロックしますが、確立されたセッションは引き続き許可します。

たとえば、IP テーブル:

iptables -A INPUT -j DROP -p tcp --syn --destination-port <web service port>
于 2011-10-11T10:20:55.957 に答える
7

ELB からトラフィックを分散するための推奨される方法は、複数のアベイラビリティ ゾーンに同じ数のインスタンスを配置することです。例えば：

ELB

  • インスタンス 1 (us-east-a)
  • インスタンス 2 (us-east-a)
  • インスタンス 3 (us-east-b)
  • インスタンス 4 (us-east-b)

現在、プログラムで (またはコントロール パネルを介して) インスタンスをデタッチできるようにする 2 つの興味深い ELB API が提供されています。

  1. インスタンスの登録解除
  2. アベイラビリティーゾーンを無効にする (その後、そのゾーン内のインスタンスを無効にします)

ELB 開発者ガイドには、可用性ゾーンを無効にした場合の影響について説明するセクションがあります。そのセクションの注記は特に興味深いものです。

ロードバランサーは常に、有効なすべてのアベイラビリティーゾーンにトラフィックを分散します。アベイラビリティーゾーンがロードバランサーに対して無効になる前に、アベイラビリティーゾーン内のすべてのインスタンスが登録解除されているか異常である場合、そのアベイラビリティーゾーンに送信されたすべてのリクエストは、DisableAvailabilityZonesForLoadBalancer がそのアベイラビリティーゾーンを呼び出すまで失敗します。

上記のメモで興味深いのは、DisableAvailabilityZonesForLoadBalancer を呼び出すと、ELB が即座に利用可能なゾーンのみにリクエストの送信を開始できることを意味する可能性があることです。その結果、無効なアベイラビリティ ゾーンのサーバーでメンテナンスを実行している間、ダウンタイムがゼロになる可能性があります。

上記の「理論」には、詳細なテストまたは Amazon クラウド エンジニアによる承認が必要です。

于 2011-11-03T07:47:02.520 に答える
4

ここにはすでに多くの回答があり、そのうちのいくつかは良いアドバイスを持っているようです. しかし、一般的にあなたのデザインには欠陥があると思います。サーバーをシャットダウンする前にクライアント接続が確実に閉じられるようにシャットダウン手順をどれほど完璧に設計しても、依然として脆弱です。

  1. サーバーの電源が失われる可能性があります。
  2. ハードウェアの障害により、サーバーに障害が発生します。
  3. ネットワークの問題によって接続が閉じられた可能性があります。
  4. クライアントがインターネットまたは Wi-Fi を失います。

リストを続けることもできますが、私のポイントは、システムが常に正しく動作するように設計するのではなく、ということです。障害を処理するように設計します。サーバーの電力がいつでも失われるのを処理できるシステムを設計すると、非常に堅牢なシステムが作成されます。これは ELB の問題ではなく、現在のシステム アーキテクチャの問題です。

于 2012-10-04T16:03:43.187 に答える
2

既存の回答で説明されていない注意点は、ELB も 60 秒の TTL を持つ DNS レコードを使用して、複数の ELB ノード (それぞれに 1 つ以上のインスタンスが接続されている) 間で負荷を分散することです。

これは、2 つの異なるアベイラビリティ ゾーンにインスタンスがある場合、ELB の A レコードに 60 秒の TTL を持つ 2 つの IP アドレスがある可能性があることを意味します。このようなアベイラビリティ ゾーンから最後のインスタンスを削除すると、クライアントは少なくとも 1 分間は古い IP アドレスを引き続き使用する可能性があり、DNS リゾルバーに障害があると、動作がさらに悪化する可能性があります。

ELB が複数の IP を使用して同じ問題を抱えている別のケースとして、1 つのアベイラビリティ ゾーンに非常に多くのインスタンスがあり、1 つの ELB サーバーで処理するには多すぎる場合があります。その場合、ELB は別のサーバーも作成し、その IP を 60 秒の TTL で A レコードのリストに追加します。

于 2012-10-04T14:15:27.410 に答える