Varnish 3.0 периодически возвращает 503, хотя внутренний сервер отвечает менее чем за 3 секунды.

У нас странная проблема с Varnish 3.0. Мы наблюдаем скорость 10-20 отказов на узел в минуту на нашей лаковой ферме. В данном случае Varnish общается с внутренним сервером, перед которым работает приложение балансировки нагрузки (F5). Мы взяли дампы TCP на уровне Varnish и уровне балансировщика нагрузки. Похоже, что внутренний сервер отвечает примерно через 3 секунды. В дампе TCP мы видим, что Varnish получает 200 Ok через 3 секунды. После этого мы видим странное поведение. Сервер Varnish отправляет сообщение ACK балансировщику нагрузки в течение миллисекунд. Сообщение FIN, ACK отправляется с задержкой около 10 секунд. На этот раз время соответствует 10-секундной конфигурации слоя Varnish, и мы видим, что из слоя Varnish возвращается ошибка 503. Это конфигурация серверной части Varnish. Бэкэнд был переименован из соображений безопасности.

    backend backend1{
        .host = "<load balancer virtual server name>"; 
        .port = "<port>";
        .first_byte_timeout     = 120s;    
        .connect_timeout        = 10s;     
        .between_bytes_timeout  = 10s;     
    }

Кто-нибудь из вас сталкивался с подобной проблемой. Будем очень признательны за любые советы по устранению этой проблемы.


tcp varnish f5 big-ip
person Abhilash    schedule 27.07.2016    source источник

Ответы (1)


arrow_upward
0
arrow_downward

Проблема, похоже, в конфигурации between_bytes_timeout. Вы установили его равным 10 секундам, и, по вашим словам, балансировщику нагрузки требуется 10 секунд для отправки сообщения FIN, ACK. Из документов по Varnish:

between_bytes_timeout
Единицы: с
По умолчанию: 60

Тайм-аут по умолчанию между байтами при получении данных от серверной части. Мы ждем только это количество секунд между байтами, прежде чем сдаться. Значение 0 означает, что время ожидания никогда не истечет. VCL может переопределить это значение по умолчанию для каждого бэкэнд-запроса и бэкэнд-запроса. Этот параметр не относится к трубе.

Попробуйте увеличить это число и посмотрите, что произойдет

person Redithion    schedule 29.07.2016