サーバーの ELB を構成する際に問題が発生しています。
まったく同じ設定で 2 つのマイクロインスタンスを起動し、ロード バランシングを試みます。ただし、ヘルス チェックに合格しません (HTTP ポート 80 パス: "/")。
- ウェブサイトでは Ping は正常です。80 の telnet も同様です。
ヘルスチェックはどのように機能しましたか? 何か本当に間違ったことをしているのでしょうか?
編集：
- ブラウザからの直接アクセスと GET (curl 経由) の両方が正常に動作します (ステータス 200)
答え1
私も同じ問題を抱えています。暫定的な解決策として TCP:80 をチェックしています (これで問題なく動作します)。
答え2
応答は、HTTP 200 応答であることとは別に、特定のヘッダーを含む必要があるという結論に達しました。インスタンスで実行されている Tomcat サーバーから返された HTTP 200 は機能しませんでしたが、httpd によって提供される静的 HTML ページ (これも 200 コードを返します) は正常に機能しました。ヘッダーを見ると、いくつかの違いの 1 つは、Tomcat のヘッダーにコンテンツ タイプが含まれていないことでした。ただし、それがなぜ違いを生むのかはわかりません。
答え3
各サーバーの指定されたパス「/」に対して HTTP GET 要求を実行し、成功した HTTP 応答コード (200) を検索するものと想定します。http://<backend_server_IP>:80/ブラウザ (または や などの CLI ツールwget)経由で に GET 要求を正常に行うことができますかcurl。
リクエストが正常に処理された場合、次に確認すべきことは、ポート 80 へのアクセスが特定のソース アドレスまたはサブネットに制限されるようにサーバーのセキュリティ グループを構成したかどうかです。その場合は、ELB のセキュリティ グループをフィルターに追加する必要があります。グループは常に次のように呼び出されます。
amazon-elb/amazon-elb-sg
したがって、AWS コンソールのセキュリティグループセクションの「ソース」フィールドにこれを追加するだけです。
答え4
そこで、静的 HTML ファイル (PHP ページではなく) を指定して、http チェックを機能させることにしました。
'/' は、curl などを使用すると有効な http ステータスを返すにもかかわらず機能しません。ただし、'/file.html' はヘルス チェックに合格します。