Ответ
Я настраиваю Nginx как reverse proxy и балансировщик нагрузки (LB) для кластера бэкенд-серверов (например, приложений на Python/Go). Конфигурация пишется с учетом отказоустойчивости и мониторинга.
Базовый пример upstream блока в /etc/nginx/nginx.conf:
upstream backend_cluster {
# least_conn; # Алгоритм 'наименьших соединений' для равномерной нагрузки
server 10.0.1.10:8080 weight=3 max_fails=2 fail_timeout=30s; # Основной инстанс с большим весом
server 10.0.1.11:8080 weight=2 max_fails=2 fail_timeout=30s;
server 10.0.1.12:8080 backup; # Резервный сервер, включается при падении основных
}
server {
listen 80;
location / {
proxy_pass http://backend_cluster;
proxy_next_upstream error timeout invalid_header http_500 http_502 http_503; # Условия для перенаправления запроса
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
}
}
Ключевые практики, которые я применяю:
- Health Checks: Параметры
max_failsиfail_timeoutпозволяют Nginx автоматически исключать не отвечающие ноды из ротации. - Сессии: Для stateful-приложений использую
ip_hashилиhash $cookie_jsessionidдля sticky sessions. - Динамический upstream: Интеграция с Consul или etcd через модуль
nginx-upsync-moduleдля автоматического обновления списка серверов без перезагрузки Nginx. - Мониторинг: Сбор метрик (активные соединения, статусы апстримов) в Prometheus через
nginx-exporterдля визуализации в Grafana.
Такой подход превращает Nginx из простого балансировщика в управляемый компонент инфраструктуры.