Apache httpd は毎回新しいセッションを作成します (2.2.16 および 2.4.6)

Question 1

あなたが説明しているようなことが起こるのは、実際にはかなり難しいようです。ルートは、受信クッキー/パラメータから解析されますが、これはかなり単純なようです。次に、バランスメンバーでルートが検索されます。ルートが見つからない場合にのみ、より複雑な負荷ベースのメンバー選択に入ります。そのため、メンバーがダウンして検索が失敗するか、httpd がバランスメンバーに関する知識を失う可能性があります。これは、httpd スレッド間の共有データに関係するため、常に問題の原因となる可能性があります。

標準を試してみるといいかもしれない2.2.26リリース、公平に言えば、バランサーまたはプロキシコードもっている2.2.16 以降に変更Debian には、主にセキュリティ関連のものが少しずつバックポートされているので、何か奇妙なことが起きている可能性があります。

httpd問題が発生している間に、を正常に再起動できるかどうかを確認してくださいLogLevel debug。エラー状態が続く場合は、バランサーメンバーの選択に関する詳細な情報がエラーログに大量に記録され、その下で何が起こっているかをより正確に把握できるようになります。

ログ記録に失敗した場合は、バランサー環境変数を定義に追加して、LogFormatに取り込むようにしてaccess.logください。これにより、何が起こっているかをより適切に追跡できる可能性があります。

\"%{BALANCER_NAME}e\"
\"%{BALANCER_WORKER_NAME}e\"
\"%{BALANCER_WORKER_ROUTE}e\"
\"%{BALANCER_SESSION_STICKY}e\"
\"%{BALANCER_SESSION_ROUTE}e\"
\"%{BALANCER_ROUTE_CHANGED}e\"

Answer

あなたが説明しているようなことが起こるのは、実際にはかなり難しいようです。ルートは、受信クッキー/パラメータから解析されますが、これはかなり単純なようです。次に、バランスメンバーでルートが検索されます。ルートが見つからない場合にのみ、より複雑な負荷ベースのメンバー選択に入ります。そのため、メンバーがダウンして検索が失敗するか、httpd がバランスメンバーに関する知識を失う可能性があります。これは、httpd スレッド間の共有データに関係するため、常に問題の原因となる可能性があります。

標準を試してみるといいかもしれない2.2.26リリース、公平に言えば、バランサーまたはプロキシコードもっている2.2.16 以降に変更Debian には、主にセキュリティ関連のものが少しずつバックポートされているので、何か奇妙なことが起きている可能性があります。

httpd問題が発生している間に、を正常に再起動できるかどうかを確認してくださいLogLevel debug。エラー状態が続く場合は、バランサーメンバーの選択に関する詳細な情報がエラーログに大量に記録され、その下で何が起こっているかをより正確に把握できるようになります。

ログ記録に失敗した場合は、バランサー環境変数を定義に追加して、LogFormatに取り込むようにしてaccess.logください。これにより、何が起こっているかをより適切に追跡できる可能性があります。

\"%{BALANCER_NAME}e\"
\"%{BALANCER_WORKER_NAME}e\"
\"%{BALANCER_WORKER_ROUTE}e\"
\"%{BALANCER_SESSION_STICKY}e\"
\"%{BALANCER_SESSION_ROUTE}e\"
\"%{BALANCER_ROUTE_CHANGED}e\"

Question 2

あなたのコメントに基づくと、実際の問題は、stickysession がクライアントに対して機能しないことがあるということです。

ここで動作します:

[client IP:56456] AH01160: Found value 4A0775A9DDFBFB1FE2B6AE14F62C5904.tomcat2 for stickysession JSESSIONID, referer: https://www.x.com/vefsms/
[client IP:56456] AH01161: Found route tomcat2, referer: https://www.x.com/vefsms/
[client IP:56456] AH01172: balancer://ssl-cluster: worker (ajp://tomcat2.x.com:9108) rewritten to ajp://tomcat2.x.com:9108/vefsms-portlets/dwr/interface/Controller.js, referer: https://www.x.com/vefsms/

ここでは機能しません（注：いいえFound route）

[client IP:56456] AH01160: Found value (J2EE4847100)ID1435349250DBfa8033a3ce4db1f64ba8d682cf8c5736533dc780End for stickysession JSESSIONID, referer: http://www.x.com/
<------ no Found route here, so balancing decision happens instead ----->
[client IP:56456] AH01172: balancer://ssl-cluster: worker (ajp://tomcat1.x.com:9108) rewritten to ajp://tomcat1.x.com:9108/vefsms/, referer: http://www.x.com/

明らかに、原因は競合する Cookie であり(J2EE4847100)ID1435349250DBfa8033a3ce4db1f64ba8d682cf8c5736533dc780End、これはおそらくアプリケーションサーバー側で挿入されます。

Answer

あなたのコメントに基づくと、実際の問題は、stickysession がクライアントに対して機能しないことがあるということです。

ここで動作します:

[client IP:56456] AH01160: Found value 4A0775A9DDFBFB1FE2B6AE14F62C5904.tomcat2 for stickysession JSESSIONID, referer: https://www.x.com/vefsms/
[client IP:56456] AH01161: Found route tomcat2, referer: https://www.x.com/vefsms/
[client IP:56456] AH01172: balancer://ssl-cluster: worker (ajp://tomcat2.x.com:9108) rewritten to ajp://tomcat2.x.com:9108/vefsms-portlets/dwr/interface/Controller.js, referer: https://www.x.com/vefsms/

ここでは機能しません（注：いいえFound route）

[client IP:56456] AH01160: Found value (J2EE4847100)ID1435349250DBfa8033a3ce4db1f64ba8d682cf8c5736533dc780End for stickysession JSESSIONID, referer: http://www.x.com/
<------ no Found route here, so balancing decision happens instead ----->
[client IP:56456] AH01172: balancer://ssl-cluster: worker (ajp://tomcat1.x.com:9108) rewritten to ajp://tomcat1.x.com:9108/vefsms/, referer: http://www.x.com/

明らかに、原因は競合する Cookie であり(J2EE4847100)ID1435349250DBfa8033a3ce4db1f64ba8d682cf8c5736533dc780End、これはおそらくアプリケーションサーバー側で挿入されます。

Apache httpd は毎回新しいセッションを作成します (2.2.16 および 2.4.6)

答え1

答え2

関連情報