Документация HAProxy 3.4.4 on PIG.CENTER

Руководство для начинающих

Mon, 01 Jan 0001 00:00:00 +0000

Основы балансировки нагрузки

Mon, 01 Jan 0001 00:00:00 +0000

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

Что такое HAProxy и как он работает

Mon, 01 Jan 0001 00:00:00 +0000

Название «HAProxy» обозначает продукт, а «haproxy» — исполняемую программу, программный пакет или процесс. Однако оба варианта часто используются в обоих значениях и произносятся как H-A-Proxy. На раннем этапе «haproxy» расшифровывалось как «прокси высокой доступности», а название писалось в два отдельных слова, хотя сейчас оно означает только «HAProxy».

3.1. Чем является и чем не является HAProxy

HAProxy — это:

Базовые возможности

Mon, 01 Jan 0001 00:00:00 +0000

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

3.3.1. Базовые возможности: проксирование

Проксирование — передача данных между клиентом и сервером по двум независимым соединениям. HAProxy поддерживает следующие базовые возможности проксирования и управления соединениями:

Предоставление серверу корректного соединения для защиты от любых ошибок или атак со стороны клиента.

Стандартные возможности

Mon, 01 Jan 0001 00:00:00 +0000

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

3.4.1. Стандартные возможности: извлечение и преобразование сведений

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

Расширенные возможности

Mon, 01 Jan 0001 00:00:00 +0000

3.5.1. Расширенные возможности: управление

HAProxy спроектирован для исключительно стабильной работы и безопасного управления в обычной рабочей среде. Он поставляется одним исполняемым файлом и не требует процедуры установки. Несколько версий легко могут сосуществовать: экземпляры можно и рекомендуется обновлять постепенно, в порядке важности, вместо одновременного переноса всех экземпляров. Файлы конфигурации удобно хранить под контролем версий. Проверка конфигурации выполняется отдельно от работающей службы, поэтому не нужно перезапускать службу, рискуя получить сбой. При проверке могут обнаруживаться сложные ошибки (например, правило, скрывающее другое правило, или неработоспособная привязка сеансов); для их устранения выдаются подробные предупреждения и рекомендации. Обратная совместимость конфигурации охватывает очень давние версии: версия 1.5 полностью поддерживала конфигурации версии 1.1, написанные 13 лет назад, а в 1.6 прекращена поддержка лишь почти неиспользуемых устаревших директив, которые можно заменить другими средствами. Обновление конфигурации и программы происходит плавно и без прерывания обслуживания: старые и новые процессы могут сосуществовать в системе, каждый обрабатывая свои соединения. При запуске выводятся состояние системы, параметры сборки и сведения о совместимости библиотек.

Расчёт ресурсов и производительность

Mon, 01 Jan 0001 00:00:00 +0000

Типичные показатели использования CPU: в режиме TCP или HTTP с закрытием соединений на HAProxy приходится 15% времени обработки, а на ядро — 85%; в режиме постоянных соединений HTTP на HAProxy приходится около 30%, а на ядро — 70%. Это означает, что операционная система и её настройка сильно влияют на общую производительность.

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

Выпуски, пакеты и обновления

Mon, 01 Jan 0001 00:00:00 +0000

HAProxy — проект с открытым исходным кодом под лицензией GPLv2. Это означает, что его разрешено распространять при условии предоставления доступа к исходному коду по запросу, особенно если в него внесены изменения.

HAProxy развивается в основной ветке разработки «master» или «mainline», от которой создают новые ветки, когда код считается стабильным. Многие сайты добровольно используют ветки разработки в рабочей среде — чтобы участвовать в проекте или потому, что им нужна самая новая функция. Их обратная связь очень ценна для исправления ошибок и оценки общего качества и стабильности разрабатываемой версии.

Сопутствующие продукты и альтернативы

Mon, 01 Jan 0001 00:00:00 +0000

HAProxy хорошо сочетается с некоторыми перечисленными ниже продуктами. Поэтому они упомянуты здесь, хотя и не связаны непосредственно с HAProxy.

4.1. HTTP-сервер Apache

Apache — фактический стандарт среди серверов HTTP. Это очень функциональный модульный проект, поддерживающий как выдачу файлов, так и динамическое содержимое. Он может служить фронтендом для серверов приложений, а также проксировать запросы и кешировать ответы. Во всех этих сценариях перед ним обычно требуется балансировщик нагрузки. Apache может работать в разных режимах, одни из которых требуют больше ресурсов, чем другие. Некоторые модули до сих пор требуют более тяжёлой модели с заранее созданными процессами, что мешает Apache эффективно работать с большим числом соединений. В таком случае HAProxy может значительно помочь: он ограничивает число соединений с каждым сервером безопасным значением, заметно ускоряя сервер и сохраняя его ресурсы для приложения.

Документация и сообщество

Mon, 01 Jan 0001 00:00:00 +0000

1. Доступная документация

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

intro.txt (этот документ): здесь представлены основы балансировки нагрузки, HAProxy как продукт, его возможности и ограничения, известные подводные камни, которых следует избегать, некоторые ограничения конкретных ОС, способы получения, развитие проекта, способы убедиться, что используются все известные исправления, обновление, дополнения и альтернативы.

Руководство по конфигурации

Mon, 01 Jan 0001 00:00:00 +0000

1. Краткое напоминание об HTTP

Mon, 01 Jan 0001 00:00:00 +0000

Этот документ описывает язык конфигурации в реализации указанной выше версии. Он не содержит подсказок, примеров или рекомендаций. За такими сведениями обращайтесь к справочному руководству или руководству по архитектуре. Пронумерованные главы расположены в плоской боковой панели HAProxy для прямого перехода.

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

2. Настройка HAProxy

Mon, 01 Jan 0001 00:00:00 +0000

2.1. Формат файла конфигурации

Процесс конфигурации HAProxy включает 3 основных источников параметров:

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

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

1. a configuration file is an ordered sequence of statements

2. a statement is a single non-empty line before any unprotected "#" (hash)

3. a line is a series of tokens or "words" delimited by unprotected spaces or
 tab characters

4. the first word or sequence of words of a line is one of the keywords or
 keyword sequences listed in this document

5. all other words are all arguments of the first one, some being well-known
 keywords listed in this document, others being values, references to other
 parts of the configuration, or expressions

6. certain keywords delimit a section inside which only a subset of keywords
 are supported

7. a section ends at the end of a file or on a special keyword starting a new
 section

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

5. Параметры bind и server

Mon, 01 Jan 0001 00:00:00 +0000

Ключи “bind”, “server” и “default-server” поддерживают ряд настроек, зависящих от некоторых опций сборки и от системы, на которой был собран HAProxy. Эти настройки в целом состоят из одного слова, иногда сопровождаемого значением, записанным на той же строке, что и строка “bind” или “server”. Все эти опции описаны в этой секции.

5.1. Параметры bind

Ключ “bind” поддерживает определённое количество настроек, которые передаются как аргументы на той же строке. Порядок, в котором эти аргументы приводятся, не имеет значения, при условии, что они находятся после адреса привязки. Все эти параметры являются необязательными. Некоторые из них состоят из одного слова (логические значения), в то время как другие ожидает значение после них. В этом случае значение должно быть указано немедленно после имени настройки.

6. Кеш

Mon, 01 Jan 0001 00:00:00 +0000

HAProxy предоставляет кеш, предназначенный для небольших объектов (favicon, css и т. п.). Это минималистичный кеш в оперативной памяти, не требующий сложного обслуживания.

Кеш использует общую для всех потоков область памяти, разделённую на блоки по 1kB.

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

9. Поддерживаемые фильтры

Mon, 01 Jan 0001 00:00:00 +0000

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

См. также: «filter».

9.1. Трассировка

filter trace [name <name>] [random-forwarding] [max-fwd <max>] [hexdump]

Аргументы:

<name> is an arbitrary name that will be reported in
 messages. If no name is provided, "TRACE" is used.

<quiet> inhibits trace messages.

<random-forwarding> enables the random forwarding of parsed data. By
 default, this filter forwards all previously parsed
 data. With this parameter, it only forwards a random
 amount of the parsed data.

<max> is the maximum amount of data that can be forwarded at
 a time. "max-fwd" option can be combined with the
 random forwarding. <max> must be an positive integer.
 0 means there is no limit.

<hexdump> dumps all forwarded data to the server and the client.

Этот фильтр можно использовать как основу для разработки новых фильтров. Он определяет все обратные вызовы и для каждого из них выводит в стандартный поток ошибок (stderr) сообщение с полезными сведениями. Это может пригодиться для отладки работы других фильтров или самого HAProxy.

10. Приложения FastCGI

Mon, 01 Jan 0001 00:00:00 +0000

HAProxy может отправлять запросы HTTP приложениям FastCGI с ролью Responder. Эта возможность добавлена в HAProxy 2.1. Для её использования серверы необходимо настроить на протокол FastCGI (с помощью «proto fcgi» в строке server), а в управляющем ими бэкенде нужно настроить и подключить приложение FastCGI (с помощью «use-fcgi-app» в секции прокси). Можно определить несколько приложений FastCGI, но бэкенд одновременно может использовать только одно из них.

11. Таблицы привязок и одноранговые узлы

Mon, 01 Jan 0001 00:00:00 +0000

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

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

12. Другие секции

Mon, 01 Jan 0001 00:00:00 +0000

Секции, описанные ниже, реже используются и обычно поддерживают лишь несколько параметров. Между ними нет неявной связи. Они все начинаются с одного ключевого слова. Ни одна из них не допускается до секции “global”. Поддержка некоторых из них может зависеть от опций сборки (например, что касается SSL).

12.1. Трассировка

Для отладки можно включить трассировку подсистемы HAProxy. При этом выводятся отладочные сообщения об определённой подсистеме. Это мощное средство диагностики проблем. Трассировку можно динамически настраивать через CLI. Некоторые параметры также можно заранее задать в файле конфигурации, в отдельных секциях “traces”. Подробнее о трассировке см. руководство по управлению. Это инструмент разработчика для сложных сеансов отладки. Он выводит много сообщений и требует дополнительных ресурсов, поэтому используйте его осторожно. Поскольку это инструмент разработчика, обратная совместимость этой секции не гарантируется.

Руководство по управлению

Mon, 01 Jan 0001 00:00:00 +0000

1. Предварительные требования

Mon, 01 Jan 0001 00:00:00 +0000

В этом документе описаны запуск, остановка, управление HAProxy и устранение неполадок, а также некоторые известные ограничения и подводные камни, которых следует избегать. Настройка HAProxy здесь не рассматривается (об этом читайте в configuration.txt ).

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

2. Архитектура HAProxy

Mon, 01 Jan 0001 00:00:00 +0000

HAProxy — многопоточный неблокирующий демон с событийной архитектурой. Это означает, что для планирования всех своих действий он использует мультиплексирование событий, вместо того чтобы полагаться на системный планировщик при переключении между ними. Чаще всего он работает как один процесс, поэтому вывод “ps aux” в системе показывает только один процесс “haproxy”, кроме случаев, когда идёт плавная перезагрузка конфигурации и старый процесс завершает работу параллельно с новым. Поэтому его работу всегда легко отслеживать с помощью утилиты strace. Чтобы масштабироваться с ростом числа доступных процессоров, по умолчанию haproxy запускает по одному рабочему потоку на каждый процессор, на котором ему разрешено выполняться. Если явно не задана иная конфигурация, входящий трафик распределяется между всеми этими потоками, каждый из которых выполняет один и тот же цикл событий. Особое внимание уделяется сведению зависимостей между потоками к строгому минимуму, чтобы добиться масштабируемости, близкой к линейной. Это имеет ряд следствий, в частности каждое соединение обслуживается одним потоком. Поэтому для использования всей доступной вычислительной мощности необходимо как минимум столько же соединений, сколько потоков, что почти всегда обеспечивается.

3. Запуск HAProxy

Mon, 01 Jan 0001 00:00:00 +0000

HAProxy запускается путём вызова программы “haproxy” с передачей на командной строке нескольких аргументов. Фактический синтаксис следующий:

$ haproxy [<options>]*

где [<options>]* — произвольное число параметров. Параметр всегда начинается с ‘-’, за которым следуют одна или несколько букв и, возможно, один или несколько дополнительных аргументов. Без параметров HAProxy показывает страницу справки с перечнем поддерживаемых параметров. Доступные параметры могут немного различаться в зависимости от операционной системы. Многие из них имеют аналоги в секции “global”. В таком случае командная строка всегда имеет приоритет над файлом конфигурации, что позволяет быстро принудительно задать настройки, не изменяя конфигурационные файлы. Текущий список параметров:

4. Остановка и перезапуск HAProxy

Mon, 01 Jan 0001 00:00:00 +0000

HAProxy поддерживает плавную и жёсткую остановку. Жёсткая остановка проста: при отправке процессу haproxy сигнала SIGTERM он немедленно завершается, а все установленные соединения закрываются. Плавная остановка запускается сигналом SIGUSR1, отправленным процессу haproxy. При этом процесс лишь освобождает прослушиваемые порты, продолжая обрабатывать существующие соединения до их закрытия. После закрытия последнего соединения процесс завершается.

Жёсткая остановка используется для действий «stop» и «restart» сценария управления службой. Плавная остановка применяется для действия «reload», которое пытается незаметно для клиентов загрузить новую конфигурацию в новом процессе.

5. Ограничения файловых дескрипторов

Mon, 01 Jan 0001 00:00:00 +0000

Чтобы обеспечить успешное обслуживание всех входящих соединений, HAProxy при загрузке вычисляет общее число файловых дескрипторов, которые потребуются за время жизни процесса. Обычному процессу Unix по умолчанию обычно предоставляется 1024 файловых дескриптора, а привилегированный процесс может самостоятельно увеличить этот лимит. Это одна из причин запускать HAProxy от имени root и позволять ему настроить лимит. Лимит по умолчанию в 1024 файловых дескриптора позволяет обслуживать примерно 500 одновременных соединений. Расчёт основан на глобальном параметре maxconn, ограничивающем общее число соединений на процесс, числе слушателей, числе серверов с включённой проверкой работоспособности, агентских проверках, одноранговых узлах, получателях журналов и, возможно, нескольких других технических потребностях. Для грубой оценки достаточно удвоить значение maxconn и добавить несколько десятков: получится приблизительное число необходимых файловых дескрипторов.

6. Управление памятью

Mon, 01 Jan 0001 00:00:00 +0000

HAProxy использует простое и быстрое управление памятью на основе пулов. Поскольку он работает с небольшим числом различных типов объектов, гораздо эффективнее брать новые объекты из пула, уже содержащего объекты подходящего размера, чем вызывать malloc() для каждого отдельного размера. Пулы организованы как стек, или LIFO: при выделении используются недавно освобождённые объекты, которые ещё находятся в кэшах CPU. Пулы близких размеров объединяются, чтобы ограничить фрагментацию памяти.

7. Использование CPU

Mon, 01 Jan 0001 00:00:00 +0000

Обычно HAProxy проводит большую часть времени в системном режиме, а меньшую — в пользовательском пространстве. Тщательно настроенный CPU с частотой 3.5 GHz способен поддерживать около 80000 установок и закрытий сквозных соединений в секунду при загрузке CPU 100% на одном ядре. При полной загрузке одного ядра типичны следующие показатели:

95% в системном режиме, 5% в пользовательском — для длительных соединений TCP или больших объектов HTTP;
85% в системном режиме и 15% в пользовательском — для коротких соединений TCP или маленьких объектов HTTP в режиме закрытия соединений;
70% в системном режиме и 30% в пользовательском — для маленьких объектов HTTP в режиме постоянных соединений.

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

8. Ведение журнала

Mon, 01 Jan 0001 00:00:00 +0000

Для ведения журнала HAProxy всегда использует сервер syslog, поскольку сам не обращается к файловой системе. Стандартный способ — отправлять журналы по UDP на сервер журналирования (по умолчанию на порт 514). Очень часто используется адрес 127.0.0.1, где работает локальный демон syslog, но также применяется передача по сети на центральный сервер. Центральный сервер даёт дополнительные преимущества, особенно в схемах active-active, где желательно объединять журналы в порядке поступления. HAProxy может отправлять журналы локальному демону syslog и через сокет UNIX, но это совершенно не рекомендуется: если сервер syslog перезапустить во время работы haproxy, сокет будет заменён, а новые записи журналов будут теряться. Поскольку HAProxy изолирован в окружении chroot, он не сможет повторно подключиться к новому сокету. На практике также наблюдалось, что буферы журналирования сокетов UNIX очень малы, из-за чего сообщения теряются даже при очень низкой нагрузке. Однако для тестирования такой вариант вполне допустим.

10. Упрощение управления конфигурацией

Mon, 01 Jan 0001 00:00:00 +0000

Очень часто два узла HAProxy, образующие кластер, используют совершенно одинаковую конфигурацию, за исключением нескольких адресов. Вместо того чтобы сопровождать отдельную копию конфигурации для каждого узла, которые неизбежно начнут различаться, можно включить в конфигурацию переменные окружения. Тогда несколько конфигураций смогут использовать один и тот же файл, различаясь лишь несколькими общесистемными переменными окружения. Эта возможность появилась в версии 1.5, где переменные окружения допускались только в адресах; версия 1.6 расширяет их поддержку на все параметры. Синтаксис такой же, как в оболочке UNIX: переменная начинается со знака доллара (’$’), за которым следуют открывающая фигурная скобка (’{’), имя переменной и закрывающая скобка (’}’). За исключением адресов, переменные окружения интерпретируются только в аргументах, заключённых в двойные кавычки (это ограничение было необходимо, чтобы не нарушить работу существующих конфигураций с регулярными выражениями, содержащими знак доллара).

11. Известные подводные камни, которых следует избегать

Mon, 01 Jan 0001 00:00:00 +0000

Время от времени кто-нибудь сообщает, что после перезагрузки системы служба haproxy не запустилась, но при ручном запуске работает. Чаще всего такие пользователи применяют механизм кластерного IP-адреса, например keepalived, чтобы назначать IP-адрес службы только главному узлу. Пока haproxy был привязан к адресу 0.0.0.0, всё работало, но после привязки к виртуальному IP-адресу запуск перестал удаваться. Причина в том, что при запуске службы виртуальный IP-адрес ещё не принадлежит локальному узлу, и, когда HAProxy пытается к нему привязаться, система отклоняет запрос, поскольку адрес не локальный. Решение состоит не в задержке запуска службы haproxy (это не помогло бы при перезапуске), а в правильной настройке системы, разрешающей привязку к нелокальным адресам. В Linux это легко сделать, установив параметр sysctl net.ipv4.ip_nonlocal_bind в 1. Это также необходимо для прозрачного перехвата IP-трафика, проходящего через HAProxy к определённому адресу назначения.

12. Отладка и проблемы производительности

Mon, 01 Jan 0001 00:00:00 +0000

При запуске HAProxy с параметром «-d» процесс остаётся на переднем плане и выводит по строке на каждое событие — входящее соединение, завершение соединения, каждую встреченную строку заголовка запроса или ответа. Этот отладочный вывод формируется до обработки содержимого, поэтому локальные изменения в нём не учитываются. Основное назначение — показывать запросы и ответы без запуска анализатора сетевого трафика. При одновременной обработке нескольких соединений вывод читается хуже, но скрипты «debug2ansi» и «debug2html» из каталога examples/ заметно помогают, раскрашивая его.

13. Соображения безопасности

Mon, 01 Jan 0001 00:00:00 +0000

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

Чтобы выполнить chroot, процесс сначала нужно запустить от имени root. Создавать окружения chroot вручную и запускать процесс уже внутри них бессмысленно: их трудно создавать, их никогда не сопровождают должным образом, и ошибок в них всегда гораздо больше, чем в основной файловой системе. Кроме того, при компрометации злоумышленник сможет воспользоваться специально подготовленной файловой системой. К сожалению, многие администраторы путают «запустить от имени root» и «работать от имени root», из-за чего меняют UID ещё до запуска haproxy и тем самым ослабляют действующие ограничения безопасности.