Astra linux балансировка нагрузки

Устанавливаем балансировщик нагрузки HAProxy на CentOS

Перевод статьи подготовлен в преддверии старта курса «Администратор Linux. Виртуализация и кластеризация»

Балансировка нагрузки — это распространенное решение для горизонтального масштабирования веб-приложений по нескольким хостам с предоставлением пользователям единой точки доступа к сервису. HAProxy является одной из самых популярных программ для балансировки нагрузки с открытым исходным кодом, которая также обеспечивает высокую доступность и функциональность проксирования.

HAProxy стремится оптимизировать использование ресурсов, максимизировать пропускную способность, минимизировать время отклика и избежать перегрузки каждого отдельно взятого ресурса. Она может быть установлена на множестве дистрибутивов Linux, таких как CentOS 8, на котором мы остановимся в этом руководстве, а также в системах Debian 8 и Ubuntu 16.

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

В качестве необходимого условия для достижения наилучших результатов у вас должно быть как минимум два веб-сервера и сервер для балансировки нагрузки. На веб-серверах должна быть запущена хотя бы базовая веб-служба, такая как nginx или httpd, для того чтобы можно было проверить балансировку нагрузки между ними.

Установка HAProxy на CentOS 8

В силу того, что HAProxy — быстро развивающееся приложение с открытым исходным кодом, дистрибутив, доступный вам в стандартных репозиториях CentOS, может оказаться не самой последней версией. Чтобы узнать актуальную версию, выполните следующую команду:

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

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

Загрузите исходный код с помощью команды ниже. Вы можете проверить, существует ли более новая версия, доступная на странице загрузки HAProxy.

После завершения загрузки распакуйте файлы с помощью приведенной ниже команды:

Перейдите в распакованный каталог с исходниками:

Затем скомпилируйте программу под вашу систему:

И, наконец, установите саму HAProxy:

Теперь HAProxy установлена, но для ее работы требуются некоторые дополнительные манипуляции. Продолжим настройку программного обеспечения и сервисов ниже.

Настройка HAProxy под ваш сервер

Теперь добавьте следующие каталоги и файл статистики для записей HAProxy:

Создайте символьную ссылку для двоичных файлов, чтобы вы могли запускать команды HAProxy от имени обычного пользователя:

Если вы хотите добавить прокси-сервер в систему в качестве службы, скопируйте файл haproxy.init из examples в свой каталог /etc/init.d. Отредактируйте права доступа к файлу, чтобы скрипт выполнялся, а затем перезагрузите демон systemd:

Вам также необходимо разрешить службе автоматическую перезагрузку при запуске системы:

В целях удобства также рекомендуется добавить нового пользователя для запуска HAProxy:

После этого вы можете еще раз проверить номер установленной версии с помощью следующей команды:

В нашем случае версия должна быть 2.0.7, как показано в примере вывода выше.

Наконец, файрвол в CentOS 8 по умолчанию довольно рестриктивен для этого проекта. Используйте следующие команды, чтобы разрешить необходимые службы и перезагрузить файрвол:

Настройка балансировщика нагрузки

Настройка HAProxy — довольно простой процесс. По сути, всё, что вам нужно сделать, это сообщить HAProxy, какие соединения он должен прослушивать и куда следует их ретранслировать.

Это делается путем создания файла конфигурации /etc/haproxy/haproxy.cfg с определяющими настройками. Вы можете почитать о параметрах конфигурации HAProxy на странице документации, если хотите узнать об этом больше.

Балансировка нагрузки на транспортном уровне (layer 4)

Начнем с базовой настройки. Создайте новый файл конфигурации, например, используя vi с командой ниже:

Добавьте в файл следующие разделы. Замените server_name тем, что должно вызывать ваши сервера на странице статистики, а private_ip — приватными IP-адресами серверов, на которые вы хотите направлять веб-трафик. Вы можете проверить приватные IP-адреса на панели управления UpCloud и на вкладке Private network в меню Network.

Это определяет балансировщик нагрузки транспортного уровня (layer 4) с внешним именем http_front, прослушивающий порт 80, который затем направляет трафик к бэкенду по умолчанию с именем http_back. Дополнительная статистика /haproxy?stats подключает страницу статистики по указанному адресу.

Различные алгоритмы балансировки нагрузки.

Указание серверов в разделе бэкенда позволяет HAProxy использовать эти серверы для балансировки нагрузки в соответствии с алгоритмом циклического перебора, когда это возможно.

Алгоритмы балансировки используются для определения того, на какой сервер в бэкенде передается каждое соединение. Вот некоторые из полезных опций:

• Roundrobin: каждый сервер используется по очереди в соответствии со своим весом. Это самый плавный и честный алгоритм, когда время обработки серверами остается равномерно распределенным. Этот алгоритм является динамическим, что позволяет регулировать вес сервера на лету.
• Leastconn: выбирается сервер с наименьшим количеством соединений. Циклический перебор выполняется между серверами с одинаковой нагрузкой. Использование этого алгоритма рекомендуется для длинных сеансов, таких как LDAP, SQL, TSE и т. д., но он не очень подходит для коротких сеансов, таких как HTTP.
• First: первый сервер с доступными слотами для подключения получает соединение. Серверы выбираются от самого низкого числового идентификатора до самого высокого, который по умолчанию соответствует положению сервера в ферме. Как только сервер достигает значения maxconn, используется следующий сервер.
• Source: IP-адрес источника хешируется и делится на общий вес запущенных серверов, чтобы определить, какой сервер будет получать запрос. Таким образом, один и тот же IP-адрес клиента будет всегда доставаться одному и тому же серверу, в то время как серверы остаются неизменными.

Настройка балансировки нагрузки на прикладном уровне (layer 7)

Еще одна доступная возможность — настроить балансировщик нагрузки для работы на прикладном уровне (layer 7), что полезно, когда части вашего веб-приложения расположены на разных хостах. Это может быть достигнуто путем регулирования передачи соединения, например, по URL.

Откройте файл конфигурации HAProxy с помощью текстового редактора:

Затем настройте сегменты фронтенд и бэкенд в соответствии с примером ниже:

Фронтенд объявляет правило ACL с именем url_blog, которое применяется ко всем соединениям с путями, начинающимися с /blog. Use_backend определяет, что соединения, соответствующие условию url_blog, должны обслуживаться бэкендом с именем blog_back, а все остальные запросы обрабатываются бэкендом по умолчанию.

Со стороны бэкенда конфигурация устанавливает две группы серверов: http_back, как и раньше, и новую, называемую blog_back, которая обслуживает соединения с example.com/blog.

После изменения настроек сохраните файл и перезапустите HAProxy с помощью следующей команды:

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

Тестирование настройки

Когда HAProxy настроен и запущен, откройте публичный IP-адрес сервера балансировщика нагрузки в браузере и проверьте, правильно ли вы подключились к бэкенду. Параметр stats uri в конфигурации создает страницу статистики по указанному адресу.

Когда вы загружаете страницу статистики, если все ваши серверы отображаются зеленым, то настройка прошла успешно!

Страница статистики содержит некоторую полезную информацию для отслеживания ваших веб-хостов, включая время работы/простоя и количество сеансов. Если сервер помечен красным, убедитесь, что сервер включен и что вы можете пропинговать его с машины балансировки нагрузки.

Если ваш балансировщик нагрузки не отвечает, убедитесь, что HTTP-соединения не блокируются файрволом. Также убедитесь, что HAProxy работает с помощью команды ниже:

Защита страницы статистики с помощью пароля

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

После добавления новой группы слушателей удалите старую ссылку на stats uri из фронтенд группы. Когда закончите, сохраните файл и перезапустите HAProxy.

Затем снова откройте балансировщик нагрузки с новым номером порта и войдите в систему с именем пользователя и паролем, которые вы указали в файле конфигурации.

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

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

Заключение: балансировщик нагрузки HAProxy

Поздравляем с успешной настройкой балансировщика нагрузки HAProxy! Даже с базовой настройкой балансировки нагрузки вы можете значительно повысить производительность и доступность вашего веб-приложения. Это руководство является лишь введением в балансировку нагрузки с помощью HAProxy, которая способна на гораздо большее, чем то, что можно описать в краткой инструкции по настройке. Мы рекомендуем поэкспериментировать с различными конфигурациями с помощью обширной документации, доступной для HAProxy, а затем приступить к планированию балансировки нагрузки для вашей производственной среды.

Используя несколько хостов для защиты вашего веб-сервиса с помощью запаса мощности, сам балансировщик нагрузки все равно может представлять точку отказа. Вы можете еще больше повысить высокую доступность, установив плавающий IP между несколькими балансировщиками нагрузки. Вы можете узнать больше об этом в нашей статье о плавающих IP-адресах на UpCloud.

Источник

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

Поговорим о горизонтальном масштабировании. Допустим, ваш проект вырос до размеров, когда один сервер не справляется с нагрузкой, а возможностей для вертикального роста ресурсов уже нет.

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

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

• Отказоустойчивость. Нужно как минимум два сервера, которые одновременно занимаются задачей распределения запросов/трафика. Без явного разделения ролей на ведущего и резервного.
• Масштабирование. Добавление новых серверов в систему должно давать пропорциональную прибавку в ресурсах.

Фактически, это описание кластера, узлами которого являются серверы-балансеры.

В этой статье мы хотим поделиться рецептом подобного кластера, простого и неприхотливого к ресурсам, концепцию которого успешно применяем в собственной инфраструктуре для балансировки запросов к серверам нашей панели управления, внутреннему DNS серверу, кластеру Galera и разнообразными микросервисам.

Договоримся о терминах:

— Серверы, входящие в состав кластера, будем называть узлами или балансерами.
— Конечными серверами будем называть хосты, на которые проксируется трафик через кластер.
— Виртуальным IP будем называть адрес, “плавающий” между всеми узлами, и на который должны указывать имена сервисов в DNS.

Что потребуется:

— Для настройки кластера потребуется как минимум два сервера (или вирт.машины) с двумя сетевыми интерфейсами на каждом.
— Первый интерфейс будет использоваться для связи с внешним миром. Здесь будут настроены реальный и виртуальный IP адреса.
— Второй интерфейс будет использоваться под служебный трафик, для общения узлов друг с другом. Здесь будет настроен адрес из приватной (“серой”) сети 172.16.0.0/24.
Вторые интерфейсы каждого из узлов должны находиться в одном сегменте сети.

Используемые технологии:

VRRP, Virtual Router Redundancy Protocol — в контексте этой статьи, реализация «плавающего» между узлами кластера виртуального IP адреса. В один момент времени такой адрес может быть поднят на каком-то одном узле, именуемом MASTER. Второй узел называется BACKUP. Оба узла постоянно обмениваются специальными heartbeat сообщениями. Получение или неполучение таких сообщений в рамках заданных промежутков дает основания для переназначения виртуального IP на “живой” сервер. Более подробно о протоколе можно прочитать здесь.

LVS, Linux Virtual Server — механизм балансировки на транспортном/сеансовом уровне, встроенный в ядро Linux в виде модуля IPVS. Хорошее описание возможностей LVS можно найти здесь и здесь.
Суть работы сводится к указанию того, что есть определенная пара “IP + порт” и она является виртуальным сервером. Для этой пары назначаются адреса реальных серверов, ответственных за обработку запросов, задается алгоритм балансировки, а также режим перенаправления запросов.

В нашей системе мы будем использовать Nginx как промежуточное звено между LVS и конечными серверами, на которые нужно проксировать трафик. Nginx будет присутствовать на каждом узле.

Для настроек VRRP и взаимодействия с IPVS будем использовать демон Keepalived, написанный в рамках проекта Linux Virtual Server.

КОНЦЕПЦИЯ

Система будет представлять собой связку из двух независимых друг от друга равнозначных узлов-балансеров, объединенных в кластер средствами технологии LVS и протокола VRRP.

Точкой входа для трафика будет являться виртуальный IP адрес, поднятый либо на одном, либо на втором узле.

Поступающие запросы LVS перенаправляет к одному из запущенных экземпляров Nginx — локальному или на соседнем узле. Такой подход позволяет равномерно размазывать запросы между всеми узлами кластера, т.е. более оптимально использовать ресурсы каждого балансера.

Работа Nginx заключается в проксировании запросов на конечные сервера. Начиная с версии 1.9.13 доступны функции проксирования на уровне транспортных протоколов tcp и udp.

Каждый vhost/stream будет настроен принимать запросы как через служебный интерфейс с соседнего балансера так и поступающие на виртуальный IP. Причем даже в том случае, если виртуальный IP адрес физически не поднят на данном балансере (Keepalived назначил серверу роль BACKUP).

Таким образом, схема хождения трафика в зависимости от состояния балансера (MASTER или BACKUP) выглядит так:

• запрос приходит на виртуальный IP. IPVS маршрутизирует пакет на локальный сервер;
• поскольку локальный Nginx слушает в том числе виртуальный IP, он получает запрос;
• согласно настройкам проксирования для данного виртуального IP Nginx отправляет запрос одному из перечисленных апстримов;
• полученный ответ отправляется клиенту.

• запрос приходит на виртуальный IP. IPVS маршрутизирует пакет на соседний сервер;
• на соседнем балансере этот виртуальный IP не поднят. Поэтому dst_ip в пакете нужно заменить на соответствующий серый IP из сети текущего балансера. Для этого используется DNAT;
• после этого локальный Nginx получает запрос на серый IP адрес;
• согласно настройкам проксирования для данного виртуального IP Nginx отправляет запрос одному из перечисленных апстримов;
• полученный ответ отправляется клиенту напрямую с src_ip равным виртуальному IP (при участии conntrack)

РЕАЛИЗАЦИЯ:

В качестве операционной системы будем использовать Debian Jessie с подключенными backports репозиториями.

Установим на каждый узел-балансер пакеты с необходимым для работы кластера ПО и сделаем несколько общесистемных настроек:

На интерфейсе eth1 настроим адреса из серой сети 172.16.0.0/24 :

Виртуальный IP адрес прописывать на интерфейсе eth0 не нужно. Это сделает Keepalived.

В файл /etc/sysctl.d/local.conf добавим следующие директивы:

Первая включает возможность слушать IP, которые не подняты локально (это нужно для работы Nginx). Вторая включает автоматическую защиту от DDoS на уровне балансировщика IPVS (при нехватке памяти под таблицу сессий начнётся автоматическое вычищение некоторых записей). Третья увеличивает размер conntrack таблицы.

В /etc/modules включаем загрузку модуля IPVS при старте системы:

Параметр conn_tab_bits определяет размер таблицы с соединениями. Его значение является степенью двойки. Максимально допустимое значение — 20.

Кстати, если модуль не будет загружен до старта Keepalived, последний начинает сегфолтиться.

Теперь перезагрузим оба узла-балансера. Так мы убедимся, что при старте вся конфигурация корректно поднимется.

Общие настройки выполнены. Дальнейшие действия будем выполнять в контексте двух задач:

• Балансировка http трафика между тремя веб-серверами;
• Балансировка udp трафика на 53 порт двух DNS серверов.

Вводные данные:

• В качестве виртуального IP адреса будем использовать 192.168.0.100 ;
• У веб-серверов будут адреса 192.168.0.101 , 192.168.0.102 и 192.168.0.103 соответственно их порядковым номерам;
• У DNS серверов 192.168.0.201 и 192.168.0.202 .

Начнем с конфигурации Nginx.

Добавим описание секции stream в /etc/nginx/nginx.conf :

И создадим соответствующий каталог:

Настройки для веб-серверов добавим в файл /etc/nginx/sites-enabled/web_servers.conf

Настройки для DNS-серверов добавим в файл /etc/nginx/stream-enabled/dns_servers.conf

Далее остается сконфигурировать Keepalived (VRRP + LVS). Это немного сложнее, поскольку нам потребуется написать специальный скрипт, который будет запускаться при переходе узла-балансера между состояниями MASTER/BACKUP.

Все настройки Keepalived должны находиться в одном файле — /etc/keepalived/keepalived.conf . Поэтому все нижеследующие блоки с конфигурациями VRRP и LVS нужно последовательно сохранить в этом файле.

Скрипт, который упоминался выше — /usr/local/bin/nat-switch . Он запускается каждый раз, когда у текущего VRRP инстанса меняется состояние. Его задача заключается в том, чтобы балансер, находящийся в состоянии BACKUP, умел корректно обработать пакеты, адресованные на виртуальный IP. Для решения этой ситуации используются возможности DNAT. А именно, правило вида:

При переходе в состояние MASTER, скрипт удаляет это правило.

Здесь можно найти вариант скрипта nat-switch , написанный для данного примера.

Настройки LVS для группы веб-серверов:

Настройки LVS для группы DNS-серверов:

В завершении перезагрузим конфигурацию Nginx и Keepalived:

ТЕСТИРОВАНИЕ:

Посмотрим как балансировщик распределяет запросы к конечным серверам. Для этого на каждом из веб-серверов создадим index.php с каким-нибудь простым содержимым:

И сделаем несколько запросов по http к виртуальному IP 192.168.0.100 :

Если в процессе выполнения этого цикла посмотреть на статистику работы LVS (на MASTER узле), то мы можем увидеть следующую картину:

Здесь видно как происходит распределение запросов между узлами кластера: есть два активных соединения, которые обрабатываются в данный момент и 6 уже обработанных соединений.

Статистику по все соединениям, проходящим через LVS, можно посмотреть так:

Здесь, соответственно, видим то же самое: 2 активных и 6 неактивный соединений.

ПОСЛЕСЛОВИЕ:

Предложенная нами конфигурация может послужить отправным пунктом для проектирования частного решения под конкретный проект со своими требованиями и особенностями.

Если у вас возникли вопросы по статье или что-то показалось спорным — пожалуйста, оставляйте свои комментарии, будем рады обсудить.

Источник