Балансировщик нагрузки

В современных сетях с виртуализацией и автоматизацией широкое применение получило туннелирование трафика. Однако, туннелирование ориентировано на построение сети и обеспечение надежной передачи данных, а вопросы информационной безопасности и мониторинга обычно остаются за скобками. Проблема невидимости туннелированного трафика для систем информационной безопасности давно известная проблема уже в 2011 году было опубликовано RFC 6169 Security Concerns with IP Tunneling, указывающее на потенциальные риски применения туннелей. Непосредственно средства DPI не отстают от инфраструктуры и уже давно разбирают туннели и смотрят пользовательский трафик (когда это в целом технически возможно), однако, остается узкое место передача данных из инфраструктуры на эти системы.

Туннелирование и передача трафика в системы мониторинга и информаицонной безопасности

GTP, GRE, L2TP, PPPoE, VXLAN и другие аббревиатуры туннелей знакомы любому сетевому инженеру. Туннелирование трафика позволяет:

• Обеспечить управление потоками данных за счёт построения сети на 3 уровне модели OSI
• Связывать удаленные офисы в единую сеть с общими ресурсами
• Упрощать администрирование сети за счёт разделения на уровень инфраструктуры и уровень пользователей
• Строить единые сети на базе различных технологий
• Обеспечивать мобильность пользователей (мобильные сети, миграция виртуальных машин в дата-центрах)

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

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

1. Пакеты дублируются посредством дополнительных функций сетевого оборудования и отправляются в выделенные (SPAN) порты
2. В оптическую линию устанавливаются пассивные ответвители трафика (TAP), разделяющие оптическую мощность на две линии изначальному получателю и в систему DPI
3. В инфраструктуру добавляется брокер сетевых пакетов, выполняющий функцию зеркалирвания пакетов, как и в случае с TAP изначальному получателю и в систему DPI

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

Чаще всего применяется комбинация из пассивных оптических ответвителей и брокеров сетевых пакетов.



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

Фильтрация и классификация туннелированного трафика

Без возможности анализа брокером сетевых пакетов вложенных заголовков туннелированных пакетов бессмысленно говорить об оптимизации средств DPI. Фильтрация и классификация, позволяющие снизить нагрузку на системы DPI и уменьшить их количество, должны работать именно по полям пользовательского трафика (вложенных заголовков). Иначе отделить IP-адреса конкретных пользователей, требуемые протоколы или шифрованный трафик невозможно по внешним полям это будет просто туннель. Попытка очистить трафик на системы DPI от нецелевого по внешним полям только создаст дыру в безопасности целевой трафик проскользнет мимо информационной безопасности и мониторинга в туннеле.



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

Балансировка туннелированного трафика

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



Возьмём 2 сессии (AB-ВА и CD-DC) и передадим их через туннелированные каналы T1, T2 и T3. Допустим, речь идёт об абонентах мобильного оператора, гуляющих между базовыми станциями. Пакеты этих сессий окажутся в разных туннелях и при попадании туннелированного трафика на брокер сетевых пакетов есть 2 варианта их балансировки с сохранением целостности сессий:

1. Балансировка по внешним заголовкам. Фактически брокер сетевых пакетов при этом разделит разные туннели между системами DPI: Т1 и Т3 в DPI 1, а Т2 в DPI 2. При этом пакеты запросов (AB) информационного потока AB-BA, инкапсулированные в туннели Т1 и Т2 для обеспечения мобильности абонента, оказываются в разных системах DPI, а пакеты ответов (BA) в туннелях Т2 и Т3, соответственно, попадут в DPI 1 и DPI 2. Аналогичная ситуация произойдет и с информационным потоком CD-DC. Большинство систем DPI для корректной работы требуют все данные информационного обмена. Декапсулируя трафик, каждая из систем DPI увидит обрывки информационного обмена, посчитает его не требующим обработки (как несостоявшегося) или обработает некорректно. Данная балансировка может быть интересна для мониторинга состояния отдельных участков инфраструктуры (когда в систему анализа на самом деле должны прийти именно все пакеты заданного туннеля), но для этого обычно используется фильтрация.
2. Балансировка по вложенным заголовкам. Брокер сетевых пакетов для балансировки игнорирует внешние заголовки и распределяет пакеты между системами DPI с сохранением целостности сессий AB-BA и CD-DC. При этом для мониторинга состояния отдельных участков инфраструктуры можно настроить фильтрацию по внешним заголовкам. Таким образом каждое средство DPI получит цельный поток информационного обмена пользователей, а средства мониторинга все пакеты заданного туннеля.

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



То есть, если сессии AB и CD по 10 Гбит/с каждая инкапсулированы в туннель T1, то получается 20 Гбит/с трафика (которые могут передаваться по интерфейсу 40GbE/100GbE или через агрегированные каналы LAG 10GbE). После копирования и попадания данного потока в брокер сетевых пакетов возникает необходимость разбалансировать этот трафик на несколько систем DPI по интерфейсам 10 GbE. Сделать это с сохранением целостности сессий используя внешние заголовки невозможно поток превысит пропускную способность выходного интерфейса и пакеты начнут теряться.

Балансировка по вложенным заголовкам обеспечивает возможность разделить поток на более мелкие без ущерба для целостности информационного обмена и качества работы систем DPI.

Балансировка фрагментированного туннелированного трафика

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



Когда на вход туннелирующего устройства приходит пакет с размером равным MTU, то после добавления туннельных заголовков пакет начинает MTU превышать (на количество байт туннельного заголовка) и делится на фрагменты. Причём вложенный заголовок содержится только в первом фрагменте. В результате два пакета одной сессии (AB1 и AB2), попавшие в разные туннели (T1 с заголовком XY и T2 с заголовком XZ) превращаются в четыре пакета:

• с внешним заголовком XY и вложенным заголовком AB
• с внешним заголовком XY без признаков туннелирования
• с внешним заголовком XZ и вложенным заголовком AB
• с внешним заголовком XZ без признаков туннелирования

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

Столкнувшиеся с указанными проблемами в большой части трафика понимают их и решают. Как обычно хуже всего, когда проблема касается менее 10% трафика она может быть незаметна и создается иллюзия, что всё в безопасности. А под безопасностью туннель.

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

---

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

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

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

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

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

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

sudo yum info haproxy

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

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

sudo yum install gcc pcre-devel tar make -y

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

wget http://www.haproxy.org/download/2.0/src/haproxy-2.0.7.tar.gz -O ~/haproxy.tar.gz

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

tar xzvf ~/haproxy.tar.gz -C ~/

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

cd ~/haproxy-2.0.7

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

make TARGET=linux-glibc

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

sudo make install

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

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

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

sudo mkdir -p /etc/haproxysudo mkdir -p /var/lib/haproxy sudo touch /var/lib/haproxy/stats

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

sudo ln -s /usr/local/sbin/haproxy /usr/sbin/haproxy

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

sudo cp ~/haproxy-2.0.7/examples/haproxy.init /etc/init.d/haproxysudo chmod 755 /etc/init.d/haproxysudo systemctl daemon-reload

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

sudo chkconfig haproxy on

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

sudo useradd -r haproxy

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

haproxy -vHA-Proxy version 2.0.7 2019/09/27 - https://haproxy.org/

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

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

sudo firewall-cmd --permanent --zone=public --add-service=httpsudo firewall-cmd --permanent --zone=public --add-port=8181/tcpsudo firewall-cmd --reload

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

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

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

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

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

sudo vi /etc/haproxy/haproxy.cfg

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

global   log /dev/log local0   log /dev/log local1 notice   chroot /var/lib/haproxy   stats timeout 30s   user haproxy   group haproxy   daemondefaults   log global   mode http   option httplog   option dontlognull   timeout connect 5000   timeout client 50000   timeout server 50000frontend http_front   bind *:80   stats uri /haproxy?stats   default_backend http_backbackend http_back   balance roundrobin   server server_name1 private_ip1:80 check   server server_name2 private_ip2:80 check

Это определяет балансировщик нагрузки транспортного уровня (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 с помощью текстового редактора:

sudo vi /etc/haproxy/haproxy.cfg

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

frontend http_front   bind *:80   stats uri /haproxy?stats   acl url_blog path_beg /blog   use_backend blog_back if url_blog   default_backend http_backbackend http_back   balance roundrobin   server server_name1 private_ip1:80 check   server server_name2 private_ip2:80 checkbackend blog_back   server server_name3 private_ip3:80 check

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

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

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

sudo systemctl restart haproxy

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

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

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

http://load_balancer_public_ip/haproxy?stats

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

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

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

sudo systemctl status haproxy

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

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

listen stats   bind *:8181   stats enable   stats uri /   stats realm Haproxy\ Statistics   stats auth username:password

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

sudo systemctl restart haproxy

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

http://load_balancer_public_ip:8181

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

http://load_balancer_public_ip/

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

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

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

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

---

Подробнее о курсе Администратор Linux. Виртуализация и кластеризация***

---