77 lines
4.9 KiB
Markdown
77 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` под новый состав пула.
|