# Итоги: расширение пула до четырёх бэкендов

**Дата:** 2026-08-16
**Статус:** выполнено, проверено (64 из 64 проверок)
**План:** [CHANGE_POOL_4_MEMBERS_PLAN.md](CHANGE_POOL_4_MEMBERS_PLAN.md)

## Что сделано

Добавлено по одному бэкенду в каждый приватный сегмент — пул вырос с двух
членов до четырёх. Алгоритм балансировки оставлен прежним, `symmetric_l4`.

| Контейнер | Сеть | Адрес | MAC | ID члена | Слотов |
|---|---|---|---|---|---|
| `hpnn-be1` | priv2 | `10.20.0.2` | `02:42:0a:14:00:02` | 1 | 256 |
| `hpnn-be3` | priv2 | `10.20.0.3` | `02:42:0a:14:00:03` | 3 | 256 |
| `hpnn-be2` | priv3 | `10.30.0.2` | `02:42:0a:1e:00:02` | 2 | 256 |
| `hpnn-be4` | priv3 | `10.30.0.3` | `02:42:0a:1e:00:03` | 4 | 256 |

Дайджест раскладки: `0a16713c5a9eb94d` (был `2f0ca39d5f33efa6` на двух
членах).

Изменённые файлы: `docker-compose.yml`, `lb/topology.env`, `lb/pipeline.sh`
(DNAT в таблице 12 и adjacency в таблице 21 для новых членов),
`lb/entrypoint.sh` (статические ARP-записи для вторых бэкендов на портах
проб), `lb/hc-config.sh`, `scripts/verify.sh`.

## Результаты проверок

| Проверка | Результат |
|---|---|
| Обнаружение новых членов | оба перешли в `up` за 4 с после старта демона |
| Раскладка | ровно 256 / 256 / 256 / 256, сумма 1024 |
| Балансировка с клиента | в 24 запросах присутствуют все четыре бэкенда (7/5/6/6) |
| Транзит между сегментами | все четыре направления: be1↔be2, be3↔be4 и обратные |
| Маршруты бэкендов | у всех четырёх профиль A: default на шлюзе Docker |
| Отказ члена | `pause be1` → его 256 слотов разошлись по трём оставшимся (341/342/341), трафик без ошибок |
| Восстановление | дайджест вернулся к `0a16713c5a9eb94d` |
| Fail-close | при отказе всех четырёх таблица слотов пуста, клиент получает таймаут |

## Главное измерение: возмущение раскладки на четырёх членах

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

Вывод be1 из пула:

- переехали **256** слотов самого be1 — это его четверть таблицы, они обязаны
  сменить владельца;
- у трёх оставшихся членов сменили владельца **8** слотов из 768 — **1,0 %**
  их слотов, или 0,8 % всей таблицы.

Это ожидаемое поведение классического Maglev: алгоритм гарантирует *малое*, а
не строго нулевое возмущение. Проверка в `verify.sh` поэтому сформулирована
как порог (не более 20 слотов), а не как равенство нулю. Предыдущая
формулировка «ни один слот не сменил владельца» была верна только для пула из
двух членов и на четырёх уже не выполняется.

Для сравнения: группа `type=select` из шага 1 при изменении числа бакетов
переложила бы **все** соединения, а не 1 %.

## Отклонения от плана

Отклонений от плана нет. Уточнение по процедуре: `docker compose up -d
--build` не пересоздал контейнер балансировщика — он поднял только новые
бэкенды, и демон продолжил работать со старой конфигурацией на двух членах.
Потребовалось явное `docker compose up -d --build --force-recreate
lb-router`. Это стоит помнить при любых правках `topology.env` и
`hc-config.sh`.

## Ограничения

Все ограничения шага 2 сохраняются без изменений (stateful-датапас,
отсутствие кворума, статический состав пула, только HTTP/TCP-пробы). Новое:

- члены пула по-прежнему перечислены статически в трёх местах —
  `docker-compose.yml`, `lb/topology.env` и `lb/hc-config.sh`, плюс правила
  DNAT и adjacency в `lb/pipeline.sh`. Добавление пятого члена — снова ручная
  правка четырёх файлов. Это именно то, что снимет модель
  `Load_Balancer → Listener → Pool → Member` в OVSDB на следующем шаге.