Стратегии балансировки нагрузки Nginx для обеспечения высокой доступности

Балансировка нагрузки Nginx обычно вводится после первого болезненного ограничения: один сервер приложений слишком загружен, требует обслуживания или выходит из строя, утягивая за собой весь сайт. Размещение Nginx перед несколькими бэкендами дает вам пространство для распределения запросов, вывода сервера из эксплуатации и выживания при обычных сбоях.

Сама по себе это не магическая высокая доступность. Open-source Nginx может прекратить отправку трафика на бэкенд после сбоев соединения, но он не понимает глубоко, исправна ли ваша страница оформления заказа, зависимость API или соединение с базой данных. Хорошая настройка сочетает конфигурацию upstream Nginx, разумные таймауты, конечные точки работоспособности на уровне приложения, внешний мониторинг и процесс развертывания, который может быстро удалить неисправный бэкенд.

Понимание балансировки нагрузки

По своей сути балансировка нагрузки заключается в интеллектуальном направлении клиентских запросов к пулу серверов. Вместо одного сервера, обрабатывающего весь трафик, несколько серверов работают совместно. Это дает несколько ключевых преимуществ:

• Высокая доступность: Если один сервер выходит из строя обнаруживаемым образом, другие могут продолжать обрабатывать запросы.
• Масштабируемость: При увеличении трафика вы можете добавить больше серверов в пул для обработки нагрузки.
• Производительность: Распределение трафика предотвращает перегрузку любого отдельного сервера, что приводит к более быстрому времени отклика.
• Надежность: Устраняя единые точки отказа, ваше приложение становится более устойчивым.

В конфигурации балансировки нагрузки Nginx действует как обратный прокси-сервер. Он получает входящие клиентские запросы и перенаправляет их на один из доступных серверов бэкенда в соответствии с настроенным алгоритмом. Он также получает ответ от сервера бэкенда и отправляет его обратно клиенту, делая процесс прозрачным для конечного пользователя.

Директивы балансировки нагрузки Nginx

Nginx использует определенные директивы в своем файле конфигурации (обычно nginx.conf или файлах, включенных из него) для определения групп серверов upstream и их поведения при балансировке нагрузки.

Блок upstream

Блок upstream используется для определения группы серверов, между которыми Nginx будет балансировать трафик. Этот блок обычно размещается в контексте http.

http {
    upstream my_backend_servers {
        # Конфигурации серверов размещаются здесь
    }

    server {
        listen 80;
        server_name example.com;

        location / {
            proxy_pass http://my_backend_servers;
        }
    }
}

Внутри блока upstream вы перечисляете серверы бэкенда с помощью директивы server, указывая их IP-адреса или имена хостов и порты.

upstream my_backend_servers {
    server backend1.example.com;
    server backend2.example.com;
    server 192.168.1.100:8080;
}

Директива proxy_pass

Директива proxy_pass, используемая внутри блока location, указывает на определенную вами группу upstream. Затем Nginx будет использовать настроенный алгоритм балансировки нагрузки для выбора сервера из этой группы для каждого запроса.

Алгоритмы балансировки нагрузки Nginx

Nginx поддерживает несколько алгоритмов балансировки нагрузки, каждый из которых имеет свой подход к распределению трафика. Алгоритмом по умолчанию является Round Robin.

1. Round Robin (по умолчанию)

В Round Robin Nginx последовательно распределяет запросы к каждому серверу в группе upstream. Со временем каждый сервер получает равную долю нагрузки. Это просто, эффективно для идентичных серверов и является наиболее часто используемым методом.

Конфигурация:

upstream my_backend_servers {
    server backend1.example.com;
    server backend2.example.com;
    server backend3.example.com;
}

Плюсы:

• Простота реализации и понимания.
• Равномерно распределяет нагрузку, если серверы имеют одинаковую мощность.

Минусы:

• Не учитывает загрузку сервера или время отклика. Медленный сервер все равно может получать запросы.

2. Weighted Round Robin

Weighted Round Robin позволяет назначить вес каждому серверу. Серверы с более высоким весом будут получать пропорционально большую долю трафика. Это полезно, когда у вас есть серверы с разной мощностью (например, более мощное оборудование).

Конфигурация:

upstream my_backend_servers {
    server backend1.example.com weight=3;
    server backend2.example.com weight=1;
}

В этом примере backend1.example.com будет получать в три раза больше запросов, чем backend2.example.com.

Плюсы:

• Позволяет балансировать в зависимости от мощности сервера.

Минусы:

• Все еще не учитывает загрузку сервера в реальном времени.

3. Least-Connected

Алгоритм Least-Connected направляет запросы на сервер с наименьшим количеством активных соединений. Этот метод более динамичен, так как учитывает текущую нагрузку на каждом сервере.

Конфигурация:

Чтобы включить Least-Connected, просто добавьте параметр least_conn в блок upstream:

upstream my_backend_servers {
    least_conn;
    server backend1.example.com;
    server backend2.example.com;
    server backend3.example.com;
}

Плюсы:

• Более интеллектуально распределяет нагрузку, учитывая текущую загрузку сервера.
• Хорошо подходит для приложений с различной продолжительностью соединений.

Минусы:

• Может быть немного сложнее в управлении, если количество соединений быстро колеблется.

4. IP Hash

С помощью IP Hash Nginx определяет, какой сервер должен обрабатывать запрос, на основе хэша IP-адреса клиента. Это гарантирует, что запросы от одного и того же IP-адреса клиента постоянно направляются на один и тот же сервер бэкенда. Это важно для приложений, которые полагаются на сохранение сессии (липкие сессии) без использования общего хранилища сессий.

Конфигурация:

Добавьте параметр ip_hash в блок upstream:

upstream my_backend_servers {
    ip_hash;
    server backend1.example.com;
    server backend2.example.com;
}

Плюсы:

• Обеспечивает сохранение сессии "из коробки".

Минусы:

• Может привести к неравномерному распределению нагрузки, если много клиентов используют один IP-адрес (например, за NAT-шлюзом).
• Если сервер выходит из строя, все клиенты, хэшированные на этот сервер, будут затронуты до тех пор, пока сервер не вернется в онлайн или хэш не будет пересчитан (хотя Nginx пытается перенаправить).

5. Generic Hash

Подобно IP Hash, Generic Hash позволяет указать ключ для хэширования. Этот ключ может быть переменной, такой как $request_id, $cookie_jsessionid или комбинацией переменных. Это обеспечивает большую гибкость для сохранения сессии или маршрутизации на основе определенных атрибутов запроса.

Конфигурация:

upstream my_backend_servers {
    hash $remote_addr consistent;
    server backend1.example.com;
    server backend2.example.com;
}

Использование consistent с hash реализует согласованное хэширование, которое минимизирует перераспределение ключей при изменении набора серверов.

Плюсы:

• Очень гибкий для пользовательской логики маршрутизации.
• Поддерживает согласованное хэширование для лучшей стабильности при изменениях серверов.

Минусы:

• Требует тщательного выбора ключа хэширования.

Проверки работоспособности и статус сервера

Для полезной высокой доступности Nginx должен избегать бэкендов, которые выходят из строя. Open-source версия в основном делает это пассивно: она замечает неудачные попытки при проксировании реального трафика. Это помогает с мертвыми хостами, отказами в соединении и некоторыми случаями таймаута. Это не то же самое, что активная проверка работоспособности, которая вызывает /healthz каждые несколько секунд до того, как пользователи обратятся к сервису.

max_fails и fail_timeout

Эти параметры, добавленные к директиве server внутри блока upstream, управляют тем, как Nginx обрабатывает отказавшие серверы.

• max_fails: Количество неудачных попыток связи с сервером в течение указанного периода fail_timeout. После max_fails неудач сервер помечается как недоступный.
• fail_timeout: Продолжительность, в течение которой сервер считается недоступным. По истечении этого периода Nginx попытается снова проверить его статус.

Конфигурация:

upstream my_backend_servers {
    server backend1.example.com max_fails=3 fail_timeout=30s;
    server backend2.example.com max_fails=3 fail_timeout=30s;
}

В этом примере, если backend1.example.com имеет три неудачных попытки в течение окна сбоя, Nginx временно его избегает. После таймаута Nginx может попробовать снова. Сбои основаны на попытках соединения/проксирования, а не на пользовательском ответе о работоспособности приложения, если вы не используете дополнительные инструменты или функции Nginx Plus.

Параметр backup

Параметр backup назначает сервер резервным. Он будет получать трафик только в том случае, если все другие активные серверы в группе upstream недоступны.

Конфигурация:

upstream my_backend_servers {
    server backend1.example.com;
    server backend2.example.com;
    server backup.example.com backup;
}

Если backend1 и backend2 не работают, backup.example.com возьмет на себя их функции.

Проверки работоспособности Nginx Plus

Nginx Plus, коммерческая версия, включает встроенные активные проверки работоспособности. Он может периодически отправлять запросы к бэкендам, оценивать ответы и удалять неработоспособные серверы до того, как пользовательский трафик будет направлен туда. Если вы используете open-source Nginx, вы все равно можете построить надежную систему, но обычно вы сочетаете ее с внешним мониторингом, обнаружением сервисов или автоматизацией, которая редактирует/удаляет цели upstream.

Практические примеры конфигурации

Давайте применим эти концепции на практике в распространенных сценариях.

Сценарий 1: Простая балансировка нагрузки Round Robin

Распределите трафик между двумя идентичными веб-серверами.

Конфигурация:

http {
    upstream web_servers {
        server 10.0.0.10;
        server 10.0.0.11;
    }

    server {
        listen 80;
        server_name yourdomain.com;

        location / {
            proxy_pass http://web_servers;
            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_set_header X-Forwarded-Proto $scheme;
        }
    }
}

Пояснение:

• upstream web_servers: Определяет группу с именем web_servers.
• server 10.0.0.10; и server 10.0.0.11;: Указывает серверы бэкенда.
• proxy_pass http://web_servers;: Направляет трафик в группу upstream web_servers.
• proxy_set_header: Эти директивы важны для передачи исходной информации о клиенте на серверы бэкенда, что часто требуется для ведения журнала или логики приложения.

Сценарий 2: Балансировка нагрузки с сохранением сессии (IP Hash)

Обеспечьте, чтобы пользователи оставались подключенными к одному и тому же серверу бэкенда, что полезно для приложений, хранящих данные сессии локально.

Используйте это только тогда, когда вы понимаете компромисс. Если многие пользователи приходят через один и тот же офисный NAT, шлюз мобильного оператора или корпоративный прокси, IP hash может отправлять слишком много трафика на один бэкенд. Общее хранилище сессий, подписанные stateless куки или репликация сессий на уровне приложения часто являются более чистыми решениями, чем привязка к IP-адресу клиента.

Конфигурация:

http {
    upstream app_servers {
        ip_hash;
        server 192.168.1.50:8000;
        server 192.168.1.51:8000;
    }

    server {
        listen 80;
        server_name api.yourdomain.com;

        location / {
            proxy_pass http://app_servers;
            # ... другие директивы proxy_set_header ...
        }
    }
}

Сценарий 3: Взвешенная балансировка нагрузки с отказоустойчивостью

Направляйте больше трафика на более мощный сервер и имейте резервный наготове.

Конфигурация:

http {
    upstream balanced_app {
        server app_server_1.local weight=5;
        server app_server_2.local weight=2;
        server app_server_3.local backup;
    }

    server {
        listen 80;
        server_name staging.yourdomain.com;

        location / {
            proxy_pass http://balanced_app;
            # ... другие директивы proxy_set_header ...
        }
    }
}

Здесь app_server_1.local получает 5 частей трафика, app_server_2.local получает 2 части, а app_server_3.local обслуживает запросы только в том случае, если два других недоступны.

Лучшие практики и советы

• Используйте proxy_set_header: Всегда устанавливайте заголовки, такие как Host, X-Real-IP, X-Forwarded-For и X-Forwarded-Proto, чтобы ваши серверные приложения знали исходные данные клиента.
• Обновляйте Nginx: Убедитесь, что вы используете стабильную, актуальную версию Nginx для повышения безопасности и производительности.
• Мониторьте серверы бэкенда: Внедряйте внешние инструменты мониторинга в дополнение к внутренним проверкам работоспособности Nginx. Nginx знает только, может ли он достичь сервера, но не обязательно, правильно ли работает приложение на сервере.
• Рассмотрите Nginx Plus: Для критически важных приложений Nginx Plus предлагает расширенные функции, такие как активные проверки работоспособности, сохранение сессий и мониторинг активности в реальном времени, что может упростить управление и повысить отказоустойчивость.
• DNS-балансировка нагрузки: Для распределения трафика между регионами или несколькими точками входа Nginx может помочь DNS, но отказоустойчивость DNS зависит от поведения резолвера и TTL. Не рассматривайте это как мгновенное переключение при отказе.
• Завершение SSL: Вы часто можете завершить SSL на балансировщике нагрузки (Nginx), чтобы снять нагрузку по обработке SSL с ваших серверов бэкенда.

Практическая отправная точка

Для двух или трех идентичных серверов приложений начните с простого round robin, консервативных таймаутов прокси и четкого журналирования upstream. Добавьте max_fails и fail_timeout, затем протестируйте, что происходит, когда вы останавливаете один бэкенд. Не ждите реального инцидента, чтобы узнать, как ведет себя Nginx.

Если запросы занимают очень разное время, попробуйте least_conn. Если один сервер больше других, используйте веса. Если приложение хранит состояние сессии локально, исправьте дизайн сессии, если можете; используйте ip_hash только тогда, когда вам нужен практический мост.

Лучшая стратегия балансировки нагрузки Nginx — это та, которая соответствует тому, как ваше приложение выходит из строя. Мертвая виртуальная машина, медленный бэкенд, сломанный релиз и отказ базы данных выглядят по-разному с точки зрения прокси. Настройте алгоритм, затем докажите поведение при сбоях с помощью небольших тестов, прежде чем называть настройку высокодоступной.