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

**Дата:** 2026-08-16
**Основание:** стенд шага 2 ([STEP2_SUMMARY.md](STEP2_SUMMARY.md))

## Контекст

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

Задача: добавить по одному бэкенду в каждый приватный сегмент (всего четыре
члена пула) и оставить алгоритм балансировки `symmetric_l4`.

## Состав изменения

### Новые контейнеры

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

Образ и маршруты — те же, что у существующих бэкендов: через балансировщик
маршрутизируются только клиентские префиксы и соседний приватный сегмент,
`default` остаётся на шлюзе Docker (профиль A).

### Файлы

| Файл | Изменение |
|---|---|
| `docker-compose.yml` | сервисы `be3`, `be4` |
| `lb/topology.env` | `BE3_*`, `BE4_*` |
| `lb/pipeline.sh` | правила DNAT (таблица 12) и adjacency (таблица 21) для новых членов |
| `lb/entrypoint.sh` | статические ARP-записи для вторых бэкендов на портах-источниках проб |
| `lb/hc-config.sh` | члены пула 3 и 4 |
| `scripts/verify.sh` | проверки обобщаются с двух членов на четыре |

Алгоритм балансировки не меняется: `multipath(symmetric_l4, …)` уже стоит в
листенере, менять нечего.

### Что произойдёт автоматически

Раскладка слотов пересчитается сама: демон опросит новых членов, переведёт их
в `up` и зальёт таблицу слотов на четверых. Ожидаемое распределение — по 256
слотов на члена (1024 / 4).

## Отдельная проверка: минимальное возмущение на четырёх членах

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

Классический Maglev гарантирует **малое**, а не нулевое возмущение. Поэтому
проверка формулируется как порог: доля слотов, сменивших владельца среди
оставшихся членов, должна быть заметно меньше доли слотов выбывшего члена
(25 %). Фактическое значение измеряется при реализации и фиксируется в итогах
вместе с порогом.

## Верификация

1. `make health` — четыре члена `up`, по 256 слотов, сумма 1024.
2. Балансировка с клиента: в 20 запросах встречаются все четыре бэкенда.
3. `make slots` — счётчики пакетов растут у всех четырёх.
4. Транзит между сегментами работает для новых бэкендов тоже.
5. Отказ одного члена: его слоты уходят к трём оставшимся, трафик без ошибок.
6. Минимальное возмущение: измерить долю переехавших чужих слотов.
7. `make verify` — полный автоматический прогон.

## Артефакты

1. Этот план.
2. `docs/CHANGE_POOL_4_MEMBERS_SUMMARY.md` — итоги и измеренные значения.
3. Обновление `README.md` и `docs/MANUAL_TEST_PLAN.md` под новый состав пула.