WEBサーバがFINを返さないようのですが…

質問

FW－LB－Web×２台　の構成でサーバ構築、運用しています。

WebサーバはApacheです。
バージョンは今正確にわかりませんが、2.2だったように記憶しています。

Webサーバのログに200ステータスとして記録されている通信において、
LBからのFINに対してWebサーバがFINを返さないケースは何に起因する
と考えられるでしょうか。
また、その原因を調べる方法は何かありますでしょうか。
tcpdumpを使ってもWebサーバにはLBのIPが残らないので、問題究明
に時間がかかりそうで、他にも方法がないのか、と質問させていただ
いています。

質問の背景は下記のとおりです。
サイト監視サービスでエラーが発生するのでその原因を調査しています。
その中で、通信終了後にLBからFINを受けたWEBサーバがLBにFINを
返さないケースがある事がわかりました。
ただし、監視サービスからのアクセスに対しては毎回FINを返していない
ようですので、上記問題の原因ではないと思っています。

また、監視サービスからのHTTP1.1アクセスに対してのみFINが返って
いないようで、一般的なアクセス(ブラウザからの)の場合は返している
ようなのです。

監視サービスでは、GETコマンドをつかって直接（ブラウザを使わず）
アクセスしているようです。

以上何かお気づきの点があれば教えていただければと思います。

回答No.2

gamera4500 · ベストアンサー

こんちす
乙です

ロードバランサはBIG-IPとALTEONとIP-COMの
三機種実務経験あります。

(1)WebサーバにはLBのIPが残らないので
これは見方を変えた方がいいです。
Webサーバの通信は全てLBが送信・受信しています。

(2)Apacheに不具合があるとは思えません（多分）

(3)LBの設定が誤っている

(4)LBの設定は正しいがLBにバグがある

(5)理由は明確にはないですが、Webサーバを
　１台停止させて、同じ現象が起きるか
　見てみる

補足

乙さん
回答ありがとうございます！

（１）そうですね、LBでtcpdumpして解析しており、そこではWeb
　　　サーバの通信も受信しています。
　　　LBからFINを送っているのにWebがFINを返さないケースがあり、
　　　その際のWeb内での挙動を確認できるかと思って書きました。

（２）おっしゃる通りだと思います。

（３）設定等もメーカー側に確認をとっているので問題はないと思って
　　　います。

（４）この線が濃厚なのですが、現象が再現できないため問題のポイントを
　　　メーカー側がトレースできないでいます。

（５）監視サーバからのアクセスは片方のWebサーバにしか残っていないので
　　　おそらくは現象としては同じだと思われます。

監視スクリプトの仕様がよくわからないのですが、Connection:TE, Close
といったヘッダは通常のアクセスでよくあるものなのでしょうか…

回答No.4

pakuti

keep-aliveは、どことどこが張っていますか？

クライアント LB間？
LB WEBサーバー間？

NetScalerでkeep-aliveの問題で、通信障害が出た事があります。
それ以外にも、BIG-IPやServerIRON、そのほかのLBも経験がありますが
keep-aliveやセッションのkeep（HTTPに限らず）は、うまく調整しないと
バッファがあふれて障害になりやすいように思えます。

keep-aliveのチューニングでは無く、それに関連するそのほかの設定
（ネットワーク周りなど）が必要な場合もあります。

LBやWebサーバーはどのような設定になっているかが不明なため何とも言えませんが
IPの見え方（見せ方）によっては、keep-aliveの交換がうまくいっていない可能性があるかと思われます。

補足

回答ありがとうございます。

keep-aliveの設定は、Apacheに項目としてある程度の知識しか
持っていません…

メーカー側は分かっていることだとは思うのですが…

「うまく調整する」というのは、具体的にどうすればよいのでしょうか？
あるいは、どういう点に気をつければよいのでしょうか？

ちなみに、問題の発生する監視サーバからのリクエストパケットのヘッダ
は下記のようになっていました。

◆対象URL１　※アラート発生頻度　小
　HTTP1.1ではConnection:TE, Close
　HTTP1.0ではConnection: Keep-Alive
◆対象URL２　※アラート発生頻度　多
　HTTP1.1ではConnection: Close
　HTTP1.0ではConnection: Keep-Alive

また、その他のリクエストの中で、検索エンジン調査用リクエストでも
数件同種の問題が発生していることがわかりました。
User-Agent: DoCoMo/1.0/i-robot/c5/TC
Connection: close

同じ、Connection: closeの場合でも発生頻度が大きく異なるので、
ヘッダ情報の違いは今回の事象に影響していないと判断できるのでは
と思うのですが、いかがでしょう。。。

その他に調査すべきポイントがあれば、教えていただければ助かります。

どうぞよろしくお願いいたします。

回答No.3

himeta13

あんまりApacheは詳しくないのですが、HTTP/1.1から実装されているKeepAliveが思い浮かびました。
http://www.atmarkit.co.jp/flinux/rensai/apache16/apache16b.html
KeepAliveTimeoutの値を変えてみたらどうなるでしょうか。

自分ならネットワーク構築が専門なので、とりあえずLBの前後でパケットキャプチャとって見たくなります。

お礼

回答ありがとうございます！！

LBサーバ内でtcpdumpをとって解析しています。

問題の監視リクエストは、HTTP1.1ではConnection:TE, Close、
HTTP1.0ではConnection: Keep-Aliveが指定されていました。

himeta13さんのおっしゃるKeepAliveTimeoutはKeep-Aliveのケースの際に
影響するように思いますが、Connection:TE, Closeにも影響するものでしょう
か？

一応、Connection: Keep-Aliveのリクエストに対してもすぐにセッションは
切られているようです。

回答No.1

pakuti

keep-aliveの設定の問題では？
その手のチューニング情報はLBのサポートに聞くべきでしょう

お礼

回答ありがとうございます！！

メーカーサポートは受けていますが、原因が分からなくて困っています。

一応Connection: Keep-Aliveではセッションがすぐに切られているよう
なので、セッションが不必要に残ったりしていないようです。

keep-aliveの設定で他に起こりうる問題があるのでしょうか？？

ご存知でしたら教えていただけると助かります。