Конспект раздела: upstream

Раздел про то, что происходит, когда бэкенд не один.

Две задачи группы

БАЛАНСИРОВКА   кому отдать этот запрос      → метод + веса
УСТОЙЧИВОСТЬ   что делать, когда упал       → max_fails, next_upstream, backup, down

Выбор метода

Липкость - не отказоустойчивость. Настоящее лечение - сессии снаружи (Redis, база), тогда любой метод годится.

Что настраивают всегда

upstream app {
    zone app 64k;                       # общие счётчики на всех воркеров
    resolver 127.0.0.11 valid=5s;       # если бэкенды по именам в docker
    server app-1:8000 max_fails=3 fail_timeout=15s resolve;
    server app-2:8000 resolve;
    keepalive 32;                       # с 1.29.7 по умолчанию
}

location /api/ {
    proxy_pass http://app;
    proxy_set_header Host $host;        # иначе Host: app
    proxy_next_upstream error timeout;  # коды добавляют осознанно, см. ловушку
}

Выкладка без простоя

пометить сервер down  →  nginx -s reload  →  обновить  →  вернуть в строй  →  reload

Что показал стенд

Свежее

• keepalive 32 в upstream включён по умолчанию с 1.29.7, но только в группе;
• least_time открыт для всех с 1.31.0;
• sticky (cookie, route, learn) с drain доступен с 1.29.6;
• resolve у сервера группы работает в открытой версии с ветки 1.27 (нужны zone и resolver внутри группы);
• backup несовместим с hash, ip_hash, random;
• slow_start в открытой версии по-прежнему нет.

Чек-лист: что ты должен уметь объяснить

• Почему round-robin может перегрузить один сервер при простое соседнего.
• Что увидит бэкенд в Host, если не поставить proxy_set_header.
• Как nginx узнаёт, что сервер упал, без активных проверок.
• Чем опасен non_idempotent в proxy_next_upstream.
• Что означает no live upstreams и почему это не всегда «всё упало».
• Зачем группе строка zone и что меняется без неё.
• Когда nginx спрашивает DNS про имена бэкендов и что будет, если имя не резолвится.