複数のインスタンス間でリクエストを分割するために、AWS でElastic Load Balancing (ELB)をセットアップしようとしています。同じ AMI に基づいて Web サーバーのイメージをいくつか作成しました。それぞれに個別に SSH 接続し、それぞれのパブリック DNS を介してサイトにアクセスできます。
Status: Out of Service各インスタンスをロード バランサーに追加しましたが、ヘルス チェックに失敗したため、すべて戻ってきます。パブリック DNS から各インスタンスにアクセスできるため、ほとんど混乱していますが、ロード バランサーの DNS 名にアクセスするたびにタイムアウトが発生します。
私はすべてのドキュメントを読んでグーグルで検索しようとしましたが、行き詰まっています。正しい方向へのポインタやリンクは大歓迎です。
この同じ問題について AWS サポートに連絡しました。どうやら彼らのシステムは、ELB の背後にあるすべてのインスタンスが長時間停止した場合の処理方法を認識していません。ステータスがすぐに必要な場合は、AWS サポートがステータスを手動で更新できます。
提案された修正は、EC2 インスタンスを単に停止して再起動するときに再登録するのではなく、ELB から登録解除することです。
ヘルスチェックは（デフォルトでは）ロードバランサーに組み込まれた各インスタンスの index.html にアクセスすることで行われます。インスタンスのドキュメント ルートに index.html がない場合、デフォルトのヘルス チェックは失敗します。エラスティック ロード バランサーを作成するときに、ヘルス チェック用のカスタム プロトコル、ポート、およびパスを設定できます。
最後に、これを機能させました。ポート 80 へのアクセスを開発エリアの少数のマシンに制限し、ロード バランサーがインスタンスの Apache サーバーにアクセスできなかったため、問題はAmazon セキュリティ グループにありました。ロードバランサーがインスタンスにアクセスできるようになると、In Serviceになります。
インスタンスでチェックしてtail -f /var/log/apache2/access.log、ロードバランサーがサーバーにアクセスしようとしているかどうかを確認し、サーバーがロードバランサーに提供している応答を確認しました。
お役に立てれば。
Web アプリケーションのホスティングに関する AWS チュートリアルに取り組んでいたときに、この問題に遭遇しました。ステップ 7bには、次のように記載されています。
「Ping パスを / に設定します。これにより、index.html などの名前のデフォルト ページにクエリが送信されます。」
この「/」のようにスラッシュを引用符で囲むこともできます。この「/」ではなく、ヘルスチェックにそれがあることを確認してください。.
この問題を解決するための一般的な方法を提供したいと思います。Apache や nginx などの Web サーバーをセットアップしたら、アクセス ログ ファイルを読み取って、何が起こったかを確認してください。私の場合、401 errornginxに基本認証を追加したため、報告されます。もちろん、@ivankoni が思い出したように、チェックしたドキュメントが存在しないことが原因である可能性があります。
同様の問題がありました。この問題は、HTTP ヘルス チェックを使用し、サイトをパスワード保護するために .htaccess を使用したために発生したようです。
これがリストされていないので、このスレッドを見ている他の人のために：
ヘルスチェックが、応答サーバーがリッスンしているポートをチェックしていることを確認します。
たとえば、ポート 3000 で実行されている node.js -> ヘルスチェックをポート 3000 にポイントします。
ポート 80 または 443 ではありません。これらは、ALB が使用するものです。
私はこれで朝を過ごしました。はい。