web-dev-qa-db-ja.com

GCP HTTP負荷分散でのいくつかの502エラー

ロードバランサーが一部のリクエストに対して502エラーを返しています。これはリクエスト全体の非常に低い割合であり、1時間あたり約36000リクエスト、1時間あたり約40エラーがあるため、リクエストの0.01％だけがエラーを返します。

エラーが発生し、ロードバランサーのファイアウォールにこの転送ルールを追加した場合、インスタンスは正常です。 130.211.0.0/22 tcp：1-5000すべてのターゲットに適用

アプリケーションはこのようなエラーを許容するため、それほど深刻な問題ではありませんが、なぜエラーが発生するのかを知りたいのですが。

どんな助けでも感謝します。

google-compute-engine
20
Jordi

これに対する簡単な解決策はないようです。

Mike Fotinakisが このブログ で説明しているように（この情報をありがとうJasonG :)）：

Google Cloud HTTP（S）ロードバランサとNGINXのデフォルトのキープアライブタイムアウト65秒の間に競合状態があることがわかりました。ロードバランサーが別のHTTPリクエストに接続を再利用しようとすると同時にNGINXタイムアウトに到達する可能性があり、接続が切断され、ロードバランサーから502 Bad Gateway応答が返されます。

私の場合、私はmpm_preforkモジュールでApacheを使用しています。提案された解決策は、接続キープアライブタイムアウトを650秒に増やすことですが、接続ごとに1つの新しいプロセスが開かれるため、これは不可能です（これはリソースの大きな浪費を意味します）。

UPDATE：
この問題に関する新しいドキュメントがロードバランサーの公式ドキュメントページにあるようです（「タイムアウトと再試行」を検索してください）： https://cloud.google.com/compute/docs/load-balancing/http /

どちらの場合も（ApacheとNginx）、KeepAliveTimeout値を620に設定することをお勧めします。

10
Jordi

ロードバランサーとバックエンドの構成を再作成した後、原因が説明できない502秒の問題が発生しました。非管理対象インスタンスのバックエンドとインスタンスグループを再作成しましたが、これで問題が解決したようです。 GCPの構成で問題を特定できませんでした:(

しかし、私にはもっと多くのエラーがありました-1/10。原因が何であるかを説明するロードバランサーログと、ドキュメントが原因を説明しています。

たとえば、次のとおりです：jsonPayload：{statusDetails： "failed_to_pick_backend" @type： "type.googleapis.com/google.cloud.loadbalancing.type.LoadBal‌ ancerLogEntry"}

Nginxを使用していて、POSTS上にあり、エラーが「backend_connection_closed_before_data_sent_to_client」として報告される場合は、nginxタイムアウトを変更することで修正できる場合があります。この優れたブログ投稿をご覧ください。

https://blog.percy.io/tuning-nginx-behind-google-cloud-platform-http-s-load-balancer-305982ddb340#.btzyusgi6

9
JasonG

バックエンドファイアウォールがGoogleのクラウドCDN IPアドレスをブロックするかどうかを確認します（130.211.0.0/22だけではありません）。これらのアドレスはすべてここにあります： https://cloud.google.com/compute/docs/faq #find_ip_range

0
Harris Tailor