Балансировка L4 и L7, proxy_pass

Раздача, падение и привязка

По умолчанию запросы раздаются по кругу: первый первому, второй второму, третий третьему, четвёртый снова первому. На 60 запросах это дало идеальные 20 на каждый из трёх. Ровно так же считаются и веса, если бэкенды разной мощности.

Интереснее, что происходит при падении. Я удалил один бэкенд из трёх. С настройками по умолчанию балансировщик готов ждать установки соединения очень долго, поэтому попавшие на мёртвого клиенты просто висели: из 10 запросов три не дождались ответа, а весь прогон занял 18 142 миллисекунды. Тот же стенд, где я поставил предел на установку соединения 1 секунду и разрешил при неудаче идти к следующему бэкенду, отдал все 30 ответов успешно за 2039 миллисекунд - запросы разошлись по двум живым, 14 и 16.

// Третий режим - привязка клиента к бэкенду по его адресу. Проверил: 12 запросов с одного адреса ушли на один и тот же бэкенд. Это спасает приложения, которые держат данные о вошедшем пользователе у себя в памяти, но взамен ломает равномерность и делает обновление версии болезненным: у каждой копии свои привязанные клиенты. Правильнее вынести эти данные в общее хранилище, а привязку оставить как временную подпорку.

раздача по кругу

каждый следующий запрос уходит следующему бэкенду

переход к следующему

при неудаче повторить запрос на другом бэкенде

привязка по адресу

запросы одного клиента всегда идут на один бэкенд

Что видит бэкенд: путь и адрес клиента

В nginx форма записи адреса бэкенда решает судьбу пути, и это ловит всех. Правило целиком: если в proxy_pass указан путь, хотя бы одиночный слэш, то совпавшая с правилом часть заменяется на него. Если пути нет, адрес считается «как есть» и путь уходит целиком. Проверил на стенде: правило /rr/ с адресом, оканчивающимся слэшем, превратило запрос /rr/echo/users/42 в /echo/users/42 на бэкенде. Правило /noslash без пути отдало бэкенду /noslash/echo/users/42, вместе с префиксом.

Заодно видно, что бэкенду уезжает имя из настройки прокси, а не то, что писал клиент. То есть приложение, которое строит ссылки по полученному имени, за прокси начнёт выдавать внутренние адреса, если ему это имя не передать явно.

// Адрес клиента за прокси приложение тоже само не увидит: до него доходит адрес прокси. Настоящий передают отдельным заголовком, и вот тут ловушка. Отправил запрос с заголовком X-Forwarded-For, где написал 1.2.3.4 - бэкенд увидел «1.2.3.4, 172.19.0.1». Прокси ДОПИСАЛ настоящий адрес в конец, а не заменил список. Значит, доверять можно только тем значениям, которые дописали твои прокси, то есть читать список с конца и ровно столько шагов, сколько у тебя своих прокси. Наивное чтение первого значения означает, что любой клиент назначает себе любой адрес - а на этом висят ограничения по частоте, блокировки и геолокация.

proxy_pass

куда проксировать; наличие пути в нём меняет путь запроса

X-Forwarded-For

цепочка адресов клиента и прокси; каждый прокси дописывает в конец

доверенные прокси

свои прокси, чьим записям в цепочке можно верить

L4, L7 и чего стоит проверка здоровья

Балансировщик уровня соединений (его называют L4) разводит соединения по адресам и портам. Он быстрый, дешёвый и работает с любым протоколом, но внутрь не смотрит. Балансировщик уровня приложения (L7) разбирает сам запрос: умеет маршрутизировать по пути и заголовкам, повторять безопасные запросы на другом бэкенде, пускать часть трафика на новую версию, считать коды ответов. Платит он за это процессором и лишним звеном в цепочке.

Отсюда практический выбор: L4 хорош на входе и для протоколов, которые не разбираются, L7 нужен там, где решения принимаются по содержимому запроса. Часто ставят оба: снаружи L4 раскидывает по зонам, внутри L7 маршрутизирует по сервисам.

// И главное про проверки здоровья. Проверка на уровне соединения подтверждает ровно одно: порт открыт. Я поднял бэкенд, который на каждый запрос отвечает пятисотым кодом, - порт у него открыт, соединения принимаются, из раздачи он не выпадает, и клиенты продолжают получать ошибки. Значит, проверка должна быть на уровне приложения и на отдельном адресе. Но и тут есть край: если такая проверка ходит в базу, то падение базы выведет из раздачи все бэкенды разом, и сервис умрёт целиком вместо частичной деградации.

L4

балансировка по адресам и портам, без разбора содержимого

L7

балансировка с разбором самого запроса

проверка здоровья

запрос, по ответу на который решают, держать ли бэкенд в раздаче

Как отвечать: «Запрос уходит на бэкенд с префиксом, хотя ждали без. Что в конфиге?»

В proxy_pass не указан путь. Правило такое: если в proxy_pass есть путь, хотя бы одиночный слэш, nginx заменяет им ту часть, что совпала с правилом, поэтому /rr/echo/users/42 уходит как /echo/users/42. Если пути нет, адрес считается как есть и путь передаётся целиком, с префиксом. Я это проверял на стенде: одна и та же пара правил, разница только в слэше, и бэкенд получает разные пути. Поэтому добавление или удаление слэша меняет маршруты, и это первое, что я смотрю. Заодно проверяю, что бэкенду передано имя из запроса клиента, а не имя из настройки прокси, иначе приложение начнёт строить ссылки на внутренний адрес.

Ответ формулирует правило целиком, а не запоминалку про слэш, и добавляет соседнюю ошибку про имя, которая всплывает сразу после починки путей.

На чём валятся

• −Добавляют или убирают слэш в proxy_pass наугад и ломают маршруты.
• −Берут первое значение из цепочки адресов клиента как истину и получают подделку.
• −Считают открытый порт признаком здоровья сервиса.
• −Оставляют пределы ожидания по умолчанию: один мёртвый бэкенд подвешивает часть запросов надолго.
• −Ставят проверку здоровья, которая ходит в базу: падение базы выводит из раздачи всех сразу.