78 lines
4.9 KiB
Markdown
78 lines
4.9 KiB
Markdown
# План внедрения: расширение пула до четырёх бэкендов
|
||
|
||
**Дата:** 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` под новый состав пула.
|