Балансировка на прикладном уровне
На этом уровне балансировщик работает в режиме «умного прокси», он анализирует клиентские запросы и перенаправляет их на разные серверы в зависимости от характера запрашиваемого контента. Так работает, например, Nginx, распределяя запросы между фронтендом и бэкендом. За балансировку в Nginx отвечает модуль Upstream.
Nginx. Установка и дополнительные способы эффективного распределения нагрузки
Nginx можно быстро установить с помощью apt-get (при наличии соответствующих привелегий, естественно):
sudo apt-get install nginxДля настройки round robin нам потребуется использовать модуль upstream. Включим конфигурацию в настройки nginx, например:
sudo nano /etc/nginx/sites-available/defaultДобавляем файл конфигурации
upstream backend { server backend1.example.ru; server backend2.example.ru; server backend3.example.ru; }Ссылаемся на этот модуль:
server { location / { proxy_pass http://backend; } }Перезапускам nginx:
sudo service nginx restartПри наличии всех виртуальных частных серверов балансировщик начнет равномерно распределять посетителей между связанными серверами.
Выглядит хорошо, но можно лучше.
Чтобы более точно распределять пользователей по серверам нужно назначить определенный вес для тех или иных машин. Nginx позволяет назначить число, определяющее долю трафика, которая должна быть направлена на каждый сервер.
Настройка балансировки нагрузки с учетом веса сервера может выглядеть следующим образом:
upstream backend { server backend1.example.ru weight=1; server backend2.example.ru weight=2; server backend3.example.ru weight=4; }По умолчанию вес равен 1. При весе 2 на backend2.example будет отправляться в два раза больше трафика, чем на backend1, а backend3 с весом 4 будет обрабатывать в два раза больше трафика, чем backend2, и в четыре раза больше, чем backend1.
IP-хэш позволяет серверам отвечать клиентам в соответствии с их IP-адресом, отсылая посетителей к одному и тому же VPS при каждом посещении (если только этот сервер не отключен). Если известно, что сервер не работает, он должен быть помечен как неработающий. При этом все IP-адреса, которые должны были направляться на неработающий сервер, перенаправляются на другой:
upstream backend { ip_hash; server backend1.example.ru; server backend2.example.ru; server backend3.example.ru down; }По умолчанию nginx будет отправлять данные на серверы, даже если они не отвечают. Max fails позволяет автоматически предотвратить это, переводя не отвечающие серверы в нерабочее состояние на заданный промежуток времени.
С max fails связаны два фактора: max_fails и fall_timeout.
Max fails означает максимальное количество неудачных попыток подключения к серверу, которое должно произойти, прежде чем он будет признан неактивным.
Fall_timeout определяет время, в течение которого сервер считается неработоспособным. По истечении этого времени новые попытки связаться с сервером начнутся снова, по умолчанию 10 секунд.
upstream backend { server backend1.example.ru max_fails=3 fail_timeout=15s; server backend2.example.ru weight=2; server backend3.example.ru weight=4;Что есть еще?
В качестве ещё одного примера инструмента балансировки на прикладном уровне можно привести pgpool — промежуточный слой между клиентом и сервером СУБД PostgreSQL. С его помощью можно распределять запросы серверам баз данных в зависимости от их содержания, например, запросы на чтение будут передаваться на один сервер, а запросы на запись — на другой.
Установив Cloudlink в периметре своей организации вы можете за 5 минут в несколько кликов получить сервер с предустановленным Nginx и PostreSQL любой версии и любой конфигурации, в том числе отказоустойчивый геораспределенный кластер СУБД👏🏻
Забудьте про потенциальные ошибки при ручном конфигурировании, доверьте свою инфраструктуру умной автоматизации Cloudlink 👍🏻
Записывайтесь на демо в комментариях
#engineering #прикладная_балансировка #nginx