# Как работает HAProxy в кластере Принтум

# Как работает HAProxy в кластере Принтум

## Назначение

HAProxy (Отказоустойчивая конфигурация Proxy) — программный балансировщик нагрузки и прокси уровней L4/L7. В кластере Принтум используется для распределения запросов между узлами ПринтМенеджера.

## Алгоритмы балансировки

<table id="bkmrk-%D0%90%D0%BB%D0%B3%D0%BE%D1%80%D0%B8%D1%82%D0%BC-%D0%9E%D0%BF%D0%B8%D1%81%D0%B0%D0%BD%D0%B8%D0%B5-%D0%9A%D0%BE"><thead><tr><th>Алгоритм</th><th>Описание</th><th>Когда применять</th></tr></thead><tbody><tr><td>`roundrobin`</td><td>Запросы распределяются поочерёдно</td><td>Однородная нагрузка, равноценные узлы</td></tr><tr><td>`leastconn`</td><td>Запрос идёт к узлу с наименьшим числом соединений</td><td>Долгоживущие соединения</td></tr><tr><td>`source`</td><td>Хэш по IP клиента, клиент всегда попадает на один узел</td><td>Sticky sessions без cookies</td></tr><tr><td>`uri`</td><td>Хэш по URI</td><td>Кэшируемые сервисы</td></tr><tr><td>`random`</td><td>Случайный выбор из N лучших</td><td>Упрощённое распределение</td></tr><tr><td>`first`</td><td>Первый доступный узел в порядке списка</td><td>Active-passive</td></tr></tbody></table>

## Health Check

HAProxy периодически проверяет доступность backend-узлов.

<table id="bkmrk-%D0%A2%D0%B8%D0%BF-%D0%9E%D0%BF%D0%B8%D1%81%D0%B0%D0%BD%D0%B8%D0%B5-tcp-che"><thead><tr><th>Тип</th><th>Описание</th></tr></thead><tbody><tr><td>TCP check</td><td>Проверяет только открытие TCP-соединения</td></tr><tr><td>HTTP check</td><td>Отправляет HTTP-запрос, проверяет статус ответа</td></tr><tr><td>Agent check</td><td>Опрашивает внешний агент на узле для получения веса</td></tr></tbody></table>

Параметры проверки:

- `inter` — интервал между проверками (например, 2s);
- `rise` — количество успешных проверок для возврата в пул;
- `fall` — количество неудачных проверок для исключения из пула.

## Failover

```text
Штатная работа:
  Клиент → HAProxy → [PM1] [PM2]

Отказ PM1:
  HAProxy детектирует неудачу health check (после N попыток)
  PM1 помечается DOWN
  Все новые запросы → PM2

Восстановление PM1:
  HAProxy детектирует успех health check (после M попыток)
  PM1 возвращается в пул
  Запросы снова распределяются между PM1 и PM2

```

Во время failover активные соединения к PM1 прерываются — клиент получает ошибку или retry.

## Sticky Sessions

Если ПринтМенеджер хранит сессионное состояние локально, необходима привязка клиента к узлу:

- `cookie` — HAProxy вставляет cookie с идентификатором узла;
- `source` — привязка по IP.

В Active-Active кластере Принтум сессионное состояние хранится в Redis — sticky sessions не требуются.

## Роль HAProxy в Active-Active конфигурации Принтум

```text
                ┌─────────┐
Клиент ПМ ──→  │  HAProxy │
                └────┬────┘
           ┌─────────┴─────────┐
           ▼                   ▼
    ПринтМенеджер 1     ПринтМенеджер 2
           │                   │
           └────────┬──────────┘
                    ▼
              Shared Redis
              Shared NFS

```

- Оба узла активны, обрабатывают запросы одновременно.
- HAProxy распределяет входящие HTTP-запросы (Клиент ПМ, API, Встроенное приложение).
- При отказе одного узла HAProxy автоматически направляет весь трафик на второй.

В стандартной конфигурации используется алгоритм **Round Robin** с включением **Sticky Session**. Параметры таймаутов: сервера — 30 сек, клиента — 30 сек, соединения — 5 сек. Повторы (retries) не требуются. Принтум.