Комментарии 17
Отличная статья, очень полезно, глубокий анализ проблемы и сразу методы решения.
Удивлен тем, что универсальный nginx позволяет балансировку настраивать тоньше специализированного haproxy.
И снова я вернулся к этой статье, благодаря поиску — искал почему у меня nginx с параметром proxy_next_upstream_tries 1; не переключает запросы на второй бэкенд. У меня возникли подозрения, что это попытка соединения с мертвым бэкендом учитывается, и из данной статьи я понял что так и есть. Из описания параметра в доке nginx это никак не выводится логически.
Второй раз прочитал с не меньшим интересом чем в первый, и снова(!!) почерпнул полезной инфы.
Вот это я понимаю качественный материал.
Все балансировщики, кроме HAProxy, умеют обрабатывать, если все-таки бэкенд вам ответил, но каким-то ошибочным кодом.
Как насчет опции
observe layer7 доступной как минимум с версии 1.4? cbonte.github.io/haproxy-dconv/1.9/configuration.html#5.2-observe
Даже если сервис полностью лежит одну минуту в день (ситуация хуже, чем на первом графике), он все равно находится в зоне трёх девяток по надёжности. В то же время, надёжность, скажем, мобильной связи — 2 девятки. Это значит, что из 10 проблем с загрузкой, когда пользователю приходится ругаться и перезагружать страничку, всего 1 приходится на серверную аварию.
В то же время, чем ближе сервис приближается к абсолютной надёжности, тем дороже становится каждое последующее улучшение. Где-то надо остановиться. Так вот, если надо потратить кучу денег, чтобы снизить серверные ошибки вдвое, но у юзеров всего на 5% снизится число видимых отказов, то оно может того и не стоить.
Все зависит от сервиса, конечно. Это может быть система управления полетами или биржевая система — там другие требования по надёжности. Но во многих случаях я бы согласился с бизнесом — причины проблемы понятны (Вася кабель переключил), повторяться она часто не должна (мы кабели трогаем раз в месяц), на юзеров оно влияет ниже уровня шума — соответственно можно не фиксить и потратить время инженеров более эффективно.
Мораль такая — бугорок на графике ошибок — еще не достаточная причина, чтобы чинить проблему, особенно если цена этого — усложнение системы.
Борюсь вот с отказом сервиса под 100k+ RPM из-за разваливания кластера Apache Ignite под низом, со стороны своего кода уже все на non-blocking io, обмазано таймаутами и хелсчеками, gc затюнен, память и cpu в норме, бекенд здоровый, а вот Apache Ignite все нервы съел :(
Потихоньку шерсчу интернеты на тему похожего материала про настройку Apache Ignite/Hazelcast/Redis, буду рад рекомендациям
3. HTTP status
Все балансировщики, кроме HAProxy, умеют обрабатывать, если все-таки бэкенд вам ответил, но каким-то ошибочным кодом.
Но как же http-check expect status 200?
Речь шла о пользовательском запросе, а не о health check.
http-check expect status 200 отвечает за выкидывания сервера из балансировки при ответе не 200 статусом на health check (синтетический запрос от haproxy на бэкенд, выполняемый раз в интервал времени).
Retry — повторная попытка отправить пользовательский запрос на другой бэкенд, если один из бэкендов уже ответил не200 статусом на этот запрос.
В статье говорится о том, что haproxy не умеет делать именно retry.
Тонкая настройка балансировки нагрузки