У нас есть следующая настройка: Nginx -> Varnish -> HAProxy -> App Server A / App Server B.
Большинство обрабатываемых нами запросов передаются HAProxy на сервер приложений A. Это делается на основе значений заголовка хоста. Несколько хостов должны быть перенаправлены на сервер приложений B. Трафик на сервер приложений B очень низкий.
Большинство запросов работают нормально. Время от времени запросы, которые должны быть переданы на сервер приложений B, дают код состояния 404. Эти запросы отображаются в журналах Nginx, Varnish и App Server A, но не HAProxy.
Запросы к серверу приложений A и B, которые работают нормально, должным образом регистрируются HAProxy.
Кажется, что Varnish повторно использует подключения к серверу приложений A, установленному HAProxy, предотвращая повторную оценку этих запросов и их отправку на соответствующий сервер. Это вероятная причина моих проблем? Есть ли способ заставить Varnish повторно подключиться к бэкэнду или HAProxy оставаться между этими серверами? Каковы преимущества / недостатки каждого решения?
Спасибо!
Редактировать:
Это часть моего файла журнала Varnish:
12 SessionClose c Connection: close
12 StatSess c 127.0.0.1 54331 0 1 1 0 0 1 652 0
0 CLI - Rd ping
0 CLI - Wr 200 PONG 1329319173 1.0
12 SessionOpen c 127.0.0.1 54334 :6081
12 ReqStart c 127.0.0.1 54334 1884874126
12 RxRequest c GET
12 RxURL c /path/to/page
12 RxProtocol c HTTP/1.0
12 RxHeader c Host: www.example.com
12 RxHeader c Connection: close
12 RxHeader c User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.7 (KHTML, like Gecko) Chrome/16.0.912.77 Safari/535.7
12 RxHeader c Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
12 RxHeader c Referer: http://www.example.com/path/to/previous/
12 RxHeader c Accept-Encoding: gzip,deflate,sdch
12 RxHeader c Accept-Language: en-US,en;q=0.8
12 RxHeader c Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3
12 RxHeader c Cookie: 71666-bl0098f964_r=0; 71666-bl0098f964_s=145818062; _advocaten-cms_session=BAh7BjoPc2Vzc2lvbl9pZCIlMmRhNGFhMWY3MDRlMzljNGRkZTQ0MTI3MjJhN2E2NzY%3D--5d089ff2c72e4ad91d415cb14020834387c2077e; 71666-bl0098f964_i=272; 71666-bl0098f964_vt=1329319215438
12 VCL_call c recv
12 VCL_return c pass
12 VCL_call c hash
12 VCL_return c hash
12 VCL_call c pass
12 VCL_return c pass
12 Backend c 14 default default
14 TxRequest b GET
14 TxURL b /path/to/page/
14 TxProtocol b HTTP/1.0
14 TxHeader b Host: www.example.com
14 TxHeader b User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.7 (KHTML, like Gecko) Chrome/16.0.912.77 Safari/535.7
14 TxHeader b Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
14 TxHeader b Referer: http://www.example.com/path/to/previous/
14 TxHeader b Accept-Encoding: gzip,deflate,sdch
14 TxHeader b Accept-Language: en-US,en;q=0.8
14 TxHeader b Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3
14 TxHeader b Cookie: 71666-bl0098f964_r=0; 71666-bl0098f964_s=145818062; _advocaten-cms_session=BAh7BjoPc2Vzc2lvbl9pZCIlMmRhNGFhMWY3MDRlMzljNGRkZTQ0MTI3MjJhN2E2NzY%3D--5d089ff2c72e4ad91d415cb14020834387c2077e; 71666-bl0098f964_i=272; 71666-bl0098f964_vt=1329319215438
14 TxHeader b X-Forwarded-For: 127.0.0.1
14 TxHeader b X-Varnish: 1884874126
14 RxProtocol b HTTP/1.1
14 RxStatus b 404
14 RxResponse b Not Found
14 RxHeader b Date: Wed, 15 Feb 2012 15:20:06 GMT
14 RxHeader b Server: Apache
14 RxHeader b Vary: Accept-Encoding
14 RxHeader b Content-Encoding: gzip
14 RxHeader b Content-Length: 243
14 RxHeader b Connection: close
14 RxHeader b Content-Type: text/html; charset=iso-8859-1
12 TTL c 1884874126 RFC 120 1329319174 0 0 0 0
12 VCL_call c fetch
12 VCL_return c pass
12 ObjProtocol c HTTP/1.1
12 ObjStatus c 404
12 ObjResponse c Not Found
12 ObjHeader c Date: Wed, 15 Feb 2012 15:20:06 GMT
12 ObjHeader c Server: Apache
12 ObjHeader c Vary: Accept-Encoding
12 ObjHeader c Content-Encoding: gzip
12 ObjHeader c Content-Type: text/html; charset=iso-8859-1
14 Length b 243
14 BackendClose b default
12 VCL_call c deliver
12 VCL_return c deliver
12 TxProtocol c HTTP/1.1
12 TxStatus c 404
12 TxResponse c Not Found
12 TxHeader c Server: Apache
12 TxHeader c Vary: Accept-Encoding
12 TxHeader c Content-Encoding: gzip
12 TxHeader c Content-Type: text/html; charset=iso-8859-1
12 TxHeader c Content-Length: 243
12 TxHeader c Date: Wed, 15 Feb 2012 15:19:34 GMT
12 TxHeader c X-Varnish: 1884874126
12 TxHeader c Age: 0
12 TxHeader c Via: 1.1 varnish
12 TxHeader c Connection: close
12 Length c 243
12 ReqEnd c 1884874126 1329319174.638826609 1329319174.639825106 0.000061750 0.000943899 0.000054598
12 SessionClose c Connection: close
12 StatSess c 127.0.0.1 54334 0 1 1 0 1 1 260 243
0 CLI - Rd ping
0 CLI - Wr 200 PONG 1329319176 1.0
HAProxy - это серверная часть по умолчанию.
Может ли это иметь какое-то отношение к тому факту, что HAProxy не регистрирует последующие запросы для того же сеанса? Я предположил, что, поскольку HAProxy не регистрировал их, они не проходили через него, но, согласно документации, это предполагаемое поведение. Поскольку Varnish является клиентом для HAProxy, несколько запросов (от нескольких посетителей) могут принадлежать одному сеансу?
Изменить 2: похоже, что если я добавлю
option forceclose
option http-pretend-keepalive
в моей конфигурации HAProxy проблема исчезает или становится намного реже. Это похоже на решение более глубокой проблемы, связанной с взаимодействием Varnish / HAProxy. Лак получает Connection: Close заголовок, но не указывает этот заголовок в запросе к бэкэнду. Принудительное закрытие соединения гарантирует, что HAProxy будет оценивать каждый запрос от Varnish.