Базовые возможности
В этом разделе перечислены возможности HAProxy: одни обычно ожидаются от любого современного балансировщика нагрузки, другие непосредственно вытекают из архитектуры HAProxy. Более сложные возможности подробно рассматриваются в следующем разделе.
3.3.1. Базовые возможности: проксирование
Проксирование — передача данных между клиентом и сервером по двум независимым соединениям. HAProxy поддерживает следующие базовые возможности проксирования и управления соединениями:
Предоставление серверу корректного соединения для защиты от любых ошибок или атак со стороны клиента.
Прослушивание нескольких IP-адресов и/или портов, в том числе диапазонов портов.
Прозрачный приём: перехват трафика к произвольному IP-адресу, даже не принадлежащему локальной системе.
Порт сервера не обязан быть связан с прослушиваемым портом и может даже преобразовываться с фиксированным смещением, что удобно для диапазонов.
Прозрачное подключение: при необходимости подстановка IP-адреса клиента или любого другого адреса при соединении с сервером.
Предоставление серверам надёжного IP-адреса для обратного трафика при балансировке между несколькими площадками.
Снижение нагрузки на сервер за счёт буферов и, при необходимости, короткоживущих соединений, уменьшающих число одновременных соединений и потребление памяти.
Оптимизация стеков TCP, например SACK, управления перегрузкой и уменьшение влияния RTT.
Поддержка разных семейств протоколов по обе стороны, например IPv4/IPv6/Unix.
Соблюдение тайм-аутов: HAProxy поддерживает несколько уровней тайм-аутов в зависимости от этапа соединения, чтобы неработающий клиент, сервер или злоумышленник не удерживал ресурсы слишком долго.
Проверка протокола: анализ HTTP, SSL или полезной нагрузки с отклонением некорректных элементов протокола, если явно не предписано их принимать.
Применение политик: пересылается только разрешённый трафик.
Ограничение входящих и исходящих соединений определёнными сетевыми пространствами имён (только Linux), упрощающее создание балансировщика между контейнерами для нескольких арендаторов.
Протокол PROXY передаёт серверу IP-адрес клиента даже для трафика, отличного от HTTP. Это расширение HAProxy уже принято рядом сторонних продуктов; на момент написания как минимум следующими:
- клиент: haproxy, stud, stunnel, exaproxy, ELB, squid;
- сервер: haproxy, stud, postfix, exim, nginx, squid, node.js, varnish.
3.3.2. Базовые возможности: SSL
Инженеры Google считают стек SSL HAProxy одним из самых функциональных (http://istlsfastyet.com/ ). Наиболее часто используемые возможности, обеспечивающие его полноту:
Обслуживание нескольких сайтов на основе SNI без ограничения их числа и с упором на производительность. Известно как минимум одно развёртывание с 50000 доменов и отдельными сертификатами для них.
Поддержка сертификатов с подстановочными знаками, уменьшающая необходимое число сертификатов.
Аутентификация клиентов по сертификатам с настраиваемыми действиями при отсутствии действительного сертификата. Например, можно направить клиента на другую серверную ферму для повторного выпуска его сертификата.
Аутентификация сервера бэкенда, подтверждающая, что это настоящий сервер, а не посредник.
Аутентификация перед сервером бэкенда, позволяющая ему убедиться, что подключается именно ожидаемый узел haproxy.
Расширения TLS NPN и ALPN, позволяющие надёжно завершать зашифрованные соединения SPDY/HTTP2 и передавать их серверам бэкенда в открытом виде.
OCSP stapling, дополнительно сокращающий время загрузки первой страницы за счёт передачи ответа OCSP вместе с остальными данными, когда клиент запрашивает Certificate Status Request.
Динамический размер записей, обеспечивающий одновременно высокую производительность и низкую задержку и заметно сокращающий время загрузки страницы: браузер может начинать получать новые объекты, пока предыдущие пакеты ещё находятся в пути.
Постоянный доступ ко всем существенным сведениям уровня SSL/TLS для журналирования, контроля доступа, отчётности и т. п. Эти сведения можно включать в заголовки HTTP или даже в расширение протокола PROXY, чтобы сервер получил всю информацию, доступную ему при самостоятельном завершении SSL.
Обнаружение, запись в журнал и блокировка известных атак даже при уязвимых библиотеках SSL, например атаки Heartbleed на некоторые версии OpenSSL.
Поддержка возобновления сеансов без хранения состояния (расширение TLS Ticket из RFC 5077). Билеты TLS можно обновлять через CLI, что позволяет реализовать совершенную прямую секретность, часто меняя билеты.
3.3.3. Базовые возможности: мониторинг
HAProxy уделяет большое внимание доступности, поэтому следит за состоянием серверов и сообщает собственное состояние другим сетевым компонентам:
Состояние серверов постоянно контролируется с параметрами, заданными для каждого сервера. Это подтверждает работоспособность пути к серверу для обычного трафика.
Проверки работоспособности поддерживают два порога гистерезиса для переходов в рабочее и нерабочее состояния, защищая от частого переключения состояний.
Проверки можно отправлять на другой адрес, порт или по другому протоколу. Это позволяет проверять одну службу как показатель работоспособности нескольких, например порт HTTPS у сервера HTTP+HTTPS.
Серверы могут отслеживать другие серверы и одновременно переходить в нерабочее состояние. Так сервер, предоставляющий несколько служб, исключается целиком, и никто не направляется на частично отказавший сервер.
На сервере можно разместить агент для контроля нагрузки и работоспособности. Серверу может потребоваться сообщать о нагрузке, рабочем и административном состоянии независимо от того, что видят проверки работоспособности. Простой агент позволяет учитывать собственную оценку сервера в дополнение к проверкам всего пути.
Доступны разные методы проверки: соединение TCP, запрос HTTP, приветствие SMTP, приветствие SSL, LDAP, SQL, Redis, сценарии send/expect — все с SSL или без него.
Изменение состояния отражается в журналах и на странице статистики с указанием причины отказа, например полученного при обнаружении ошибки ответа HTTP. При изменении также можно отправлять письмо на настраиваемый адрес.
Состояние сервера отображается в интерфейсе статистики и может использоваться при маршрутизации: трафик можно направлять на разные фермы в зависимости от их размера и/или работоспособности, например при потере связи между ЦОД.
Через запросы проверки работоспособности HAProxy может передавать серверам сведения: их имена, вес, число других серверов в ферме и т. п. Серверы могут учитывать их при ответах и принятии решений, например отложить резервное копирование, чтобы сохранить больше ресурсов CPU.
Через проверки работоспособности серверы могут сообщать более подробное состояние, чем просто включён/выключен: например, запросить остановку направления новых посетителей перед своим выключением.
Сам HAProxy может сообщать состояние внешним компонентам — маршрутизаторам или другим балансировщикам, что позволяет строить полноценные инфраструктуры с несколькими путями и уровнями.
3.3.4. Базовые возможности: высокая доступность
Как любой серьёзный балансировщик нагрузки, HAProxy уделяет большое внимание доступности и максимальной непрерывности обслуживания:
Используются только работоспособные серверы, остальные автоматически исключаются из ферм балансировки. Однако при определённых условиях их всё же можно принудительно использовать.
Поддерживается плавный вывод серверов из фермы без воздействия на существующие соединения.
При отказе активных серверов автоматически используются резервные, заменяя их так, чтобы по возможности сохранить сеансы. Это также позволяет создать несколько путей к одному серверу, например через разные интерфейсы.
Можно сообщать об общем отказе фермы, если не работает слишком много серверов. Вместе с мониторингом это позволяет вышестоящему компоненту выбрать другой узел балансировки для данной службы.
Архитектура без сохранения состояния упрощает создание кластеров: HAProxy стремится обеспечить максимальную непрерывность обслуживания без хранения сведений, которые можно потерять при отказе. Благодаря этому передача обслуживания происходит максимально плавно.
Хорошая интеграция со стандартным демоном VRRP keepalived: HAProxy легко сообщает ему своё состояние и хорошо работает с плавающими виртуальными IP-адресами. Примечание: предпочитайте протоколы резервирования IP (VRRP/CARP) кластерным решениям (Heartbeat и т. п.), поскольку они обеспечивают наиболее быстрое, плавное и надёжное переключение.
3.3.5. Базовые возможности: балансировка нагрузки
HAProxy предлагает довольно полный набор средств балансировки нагрузки, многие из которых, к сожалению, отсутствуют в других продуктах:
Поддерживается не менее 10 алгоритмов балансировки, некоторые из которых используют входные данные и дают неограниченное число вариантов применения. Наиболее распространены round-robin — поочерёдный выбор серверов для коротких соединений; leastconn — выбор наименее недавно использовавшегося сервера среди серверов с минимальным числом соединений, подходящий для длительных соединений; source — прямой выбор по исходному адресу клиента для ферм SSL или терминальных серверов; URI — прямой выбор по URI HTTP для кешей HTTP; hdr — прямой выбор по содержимому определённого поля заголовка HTTP; first — сосредоточение всех соединений на минимальном числе серверов, чтобы неиспользуемые короткоживущие виртуальные машины можно было выключить.
Все перечисленные алгоритмы поддерживают вес каждого сервера, позволяя сочетать в ферме разные поколения серверов или направлять небольшую долю трафика на отдельные серверы для отладки, работы следующей версии программы и т. п.
Для round-robin, leastconn и согласованного хеширования поддерживаются динамические веса. Их можно менять на лету через CLI или даже с помощью агента на сервере.
Везде, где поддерживается динамический вес, доступен slow-start — постепенное принятие сервером трафика. Это важно для чувствительных серверов приложений, которым нужно компилировать классы во время работы, и холодных кешей, которые необходимо заполнить перед полной нагрузкой.
Хеширование может применяться к разным элементам: исходному адресу клиента, компонентам URL, элементу строки запроса, значениям полей заголовков, параметру POST, cookie RDP.
Согласованное хеширование защищает фермы от массового перераспределения нагрузки при добавлении или удалении серверов. Это особенно важно для больших кеширующих ферм и позволяет использовать slow-start для заполнения холодных кешей.
Внутренние метрики, например число соединений на сервер и бэкенд или число свободных мест для соединений в бэкенде, позволяют строить очень сложные стратегии балансировки.
3.3.6. Базовые возможности: привязка сеансов
Без привязки сеансов балансировка нагрузки приложений была бы бесполезна. HAProxy предоставляет широкий набор средств для закрепления посетителя за одним сервером даже при добавлении и удалении серверов, отказах и восстановлении. Некоторые методы устойчивы к расстояниям между узлами балансировки, поскольку не требуют репликации:
При необходимости сведения для привязки можно независимо сопоставлять и запоминать из разных источников. Например, JSESSIONID можно искать и в cookie, и в URL. Одновременно можно запоминать до 8 источников, каждый из которых может указывать на отдельную таблицу stick-table.
Источником привязки может быть всё, что видно в запросе или ответе: исходный адрес, смещение и длина полезной нагрузки TCP, элементы строки запроса HTTP, значения полей заголовков, cookie и т. п.
Таблицы stick-tables реплицируются между всеми узлами в режиме с несколькими ведущими узлами.
Часто используемые элементы, например SSL-ID или cookie RDP для ферм TSE, доступны непосредственно, что упрощает работу с ними.
Все правила привязки могут динамически зависеть от условий ACL.
Можно отказаться от привязки к определённым серверам, например резервным, чтобы после возвращения основного сервера нагрузка автоматически перешла к нему. Это часто используется в средах с несколькими путями.
В HTTP часто предпочитают ничего не запоминать, а управлять специальным cookie привязки. Такой cookie можно обнаруживать, переписывать, вставлять или дополнять префиксом, чтобы клиент запомнил назначенный сервер.
Сервер может изменить или очистить cookie привязки при выходе пользователя, автоматически снимая привязку уходящих посетителей.
Правила ACL позволяют выборочно игнорировать или принудительно применять привязку независимо от состояния сервера. Вместе с расширенными проверками работоспособности это помогает администратору убедиться, что устанавливаемый сервер работает, прежде чем открыть его всем.
Специальный механизм ограничения времени бездействия и срока действия cookie позволяет плавно прекращать привязку на устройствах, которые никогда не закрываются, — смартфонах, телевизорах, бытовой технике, — без хранения этих сведений в постоянном хранилище.
Несколько записей серверов могут иметь одинаковые ключи привязки, чтобы при отказе одного пути в многопутевой среде привязка сохранялась.
soft-stop гарантирует, что к назначенному серверу продолжат обращаться только пользователи, уже имеющие сведения о привязке, а новые туда не попадут.
3.3.7. Базовые возможности: ведение журнала
Ведение журнала исключительно важно для балансировщика нагрузки. Во-первых, его часто ошибочно обвиняют в проблемах, которые он лишь выявляет. Во-вторых, он находится в критической точке инфраструктуры, где нужно анализировать всю обычную и аномальную активность и сопоставлять её с другими компонентами.
HAProxy предоставляет очень подробные журналы с миллисекундной точностью и точным временем приёма соединения, которое можно найти в журналах межсетевого экрана, например для сопоставления NAT. По умолчанию журналы TCP и HTTP содержат все необходимые для устранения неполадок сведения: исходный IP-адрес и порт, фронтенд, бэкенд, сервер, таймеры получения запроса, ожидания в очереди, установки соединения, получения заголовков ответа и передачи данных; общее состояние процесса; число соединений; состояние очередей; число повторных попыток; подробные действия привязки и причины отключения; захваченные заголовки с безопасным кодированием вывода. Формат можно расширить или заменить, включив любые извлечённые образцы, переменные и захваченные значения, чтобы получить очень подробные сведения. Например, можно записывать суммарное число запросов клиента или число посещённых им разных URL.
Уровень журналирования можно настраивать для каждого запроса обычными ACL: автоматически подавлять шумные записи и повышать уровень до предупреждения при аномальном поведении небольшой части трафика, например при слишком большом числе URL или ошибок HTTP с одного исходного адреса. Административные сообщения также имеют свои уровни и сообщают, например, об отказе или восстановлении сервера.
Каждый фронтенд и бэкенд может использовать несколько независимых направлений вывода журналов, что упрощает обслуживание нескольких арендаторов. Журналы предпочтительно отправлять по UDP, возможно в JSON, обрезая строки до настраиваемой длины для гарантированной доставки. Их также можно отправлять в stdout/stderr, любой файловый дескриптор или кольцевой буфер, на который клиент может подписаться для получения записей.
3.3.8. Базовые возможности: статистика
HAProxy предоставляет веб-интерфейс статистики с аутентификацией, уровнями безопасности и областями видимости. Поэтому каждому заказчику хостинга можно дать отдельную страницу только с его экземплярами. Её можно разместить по скрытому URL обычного сайта, не открывая новый порт. Страница также может показывать доступность других узлов HAProxy, позволяя с первого взгляда оценить работоспособность всей системы. Представление компактно, но доступны многочисленные подробности: причины ошибок, время с последнего обращения и изменения и т. п. Те же данные доступны в виде таблицы CSV, которую другие инструменты могут импортировать для построения графиков. Страница может автоматически обновляться для использования как панели мониторинга на большом экране. В административном режиме она также позволяет менять состояние серверов, упрощая обслуживание.
Также предоставляется экспортёр Prometheus, позволяющий получать статистику в другом формате в зависимости от развёртывания.