Сайзинг установок
Актуально для: SimpleTwo 0.9.x · Проверено: 19.10.2026
Три размера, и они не выдуманы под документацию: это те же S / M / L, по которым снимается профиль нагрузки продукта.
| S | M | L | |
|---|---|---|---|
| Учётных записей | 150 | 800 | 4 000 |
| Активны в час пик (70%) | 105 | 560 | 2 800 |
| Одновременных соединений в пик | 150 | 800 | 4 000 |
| Групповых бесед | 19 | 100 | 500 |
| Личных переписок | 420 | 2 240 | 11 200 |
| Сообщений за год | 1,6 млн | 8,4 млн | 42 млн |
| Одновременных участников звонков | 15 | 70 | 350 |
В час пик живых соединений примерно столько же, сколько людей в организации: 0,7 активных × 1,4 устройства ≈ 1,0 на человека. Это число можно проверить в проде одной командой — счётчик соединений службы переписки должен совпасть с численностью.
1. Хосты на старт (размер S)
Все размеры — для x86-64 (amd64): серверная часть собирается только под эту архитектуру, хосты на ARM не поддерживаются.
| Роль | vCPU / RAM / диск | Сеть | Чем ограничена |
|---|---|---|---|
| координатор | 2 / 4 / 20 ГБ | 100 Мбит/с, публичный IPv4 | ничем |
messaging | 2 / 4 / 100 ГБ SSD | 100 Мбит/с, публичный IPv4 | диском, пока вложения на нём |
sfu, каждый | 4 / 8 / 20 ГБ | 1 Гбит/с, публичный IPv4 | каналом |
turn | 2 / 2 / 20 ГБ | 1 Гбит/с, публичный IPv4 | каналом |
calendar | 2 / 4 / 20 ГБ | 100 Мбит/с | опросом внешних календарей |
gateway, каждый | 1 / 1 / 20 ГБ | 1 Гбит/с | каналом |
postgres | 2 / 4 / 40 ГБ SSD | приватная сеть | диском |
redis | 1 / 1 / 10 ГБ | приватная сеть | ничем |
s3 | 2 / 4 / диск по медиа | приватная сеть | диском |
support | 2 / 4 / 20 ГБ | приватная сеть (DMZ) | памятью |
monitoring | 2 / 4 / 40 ГБ SSD (M — 50 ГБ, L — 4 / 8 / 80 ГБ) | приватная сеть | диском: журналы и трассы по потолку, метрики по сроку |
Для M и L растёт прежде всего медиа; служба переписки и база масштабируются заметно позже и в первую очередь диском.
identity, mail, mx, drive и mcu в таблице нет намеренно: нагрузочного прогона для них ещё не
было, а размер хоста без замера — догадка. Для почты главное — диск, и его можно посчитать
заранее: 1,87 ГБ на человека в год, 1,33 ГБ после дедупликации вложений, то есть за три года
0,6 ТБ для S, 3,1 ТБ для M и 15,6 ТБ для L. У mx своя очередь на диске: она держит письма, пока
почтовый кластер или сервер получателя их не принял; узлов mx по схеме два.
mcu считается по одновременным звонкам с терминалов переговорок, а не по участникам; сегодня
он пересылает медиа без перекодирования, так что упирается в сеть и диапазон портов, а не в
процессор. Растёт он вширь: каждый узел держит свой Предел звонков (по умолчанию — сколько
выдерживает диапазон портов) и отдаёт лишнее соседу; числа для пределов даст стенд.
2. Медиапул: арифметика, а не ощущение
Узел sfu упирается в канал, а не в процессор. Бюджет узла — 700 Мбит/с исходящего
(70% гигабитного интерфейса), участник конференции тянет ≈ 2 Мбит/с.
| S | M | L | |
|---|---|---|---|
| Исходящий поток в обычном режиме | 30 Мбит/с | 140 Мбит/с | 700 Мбит/с |
| Узлов для обычного режима | 1 | 1 | 1 — ровно в бюджет, запаса нет |
Доля через turn | 9 Мбит/с | 42 Мбит/с | 210 Мбит/с |
Но пул считают не по обычному режиму, а по общему собранию: зритель одного докладчика с демонстрацией экрана тянет ≈ 2,5 Мбит/с.
| Общее собрание | Участников | Исходящий поток | Узлов по бюджету | Ставить (N+1) |
|---|---|---|---|---|
| S | 150 | 375 Мбит/с | 1 | 2 |
| M | 800 | 2,0 Гбит/с | 3 | 4 |
| L | 4 000 | 10 Гбит/с | 15 | см. оговорку ниже |
Для организации в 4 000 человек общее собрание всех сразу упирается не в деньги на железо, а в архитектуру: такой сценарий требует другого способа раздачи, а не большего пула. Нагрузочный пр огон для большого размера выполняется на 500 участниках и экстраполируется, и в отчёте это написано прямо. Планируя L, планируйте либо меньшие собрания, либо трансляцию — не 15 узлов SFU.
N+1 — не перестраховка. Потеря узла роняет комнаты, которые на нём жили: живые сессии между узлами не переезжают. Организация, для которой звонки — рабочий инструмент, ставит на один узел больше расчёта.
3. Диск под вложения
Считается по медиа, а не по людям: ≈ 0,8 ГБ на человека в год при 8 файлах в рабочий день
и среднем размере 400 КБ. Для S это ≈ 120 ГБ в год, для M ≈ 640 ГБ, для L ≈ 3,2 ТБ — и именно
этот столбец решает, нужна ли роль s3 или внешнее хранилище.
Записи встреч считаются отдельно и сверх этого: одна запись конференции — это файл размером с запись экрана, а не с переписку.
4. XL: организация до 100 000 человек
Сразу и прямо: этот размер не измерен. Профиль нагрузки продукта заканчивается на 4 000, а медиа для этого размера прогоняется на 500 участниках и экстраполируется. Всё ниже — арифметика от тех же удельных чисел, и она полезна ровно тем, что показывает, что упрётся первым.
| L (4 000) | XL (100 000) | |
|---|---|---|
| Одновременных соединений в пик | 4 000 | ≈ 100 000 |
| Сообщений за год | 42 млн | ≈ 1 млрд |
| Вложений за год | 3,2 ТБ | ≈ 80 ТБ |
| Одновременных участников звонков | 350 | ≈ 8 700 |
| Исходящий поток SFU в обычном режиме | 700 Мбит/с | ≈ 17 Гбит/с |
Узлов sfu для обычного режима | 1 | ≈ 25 + 1 |
Что упирается первым
- Общее собрание. Оно не сходится уже на 4 000, а на 100 000 требует 250 Гбит/с исходящего потока — это не пул медиасерверов, это раздача. Организация такого размера проводит общие собрания трансляцией, а не конференцией, и трансляции в продукте пока нет. Планируя XL, планируйте её отдельно — это работа, а не настройка.
- Сокеты службы переписки. Служба масштабируется репликами: они делят Postgres, объектное хранилище и шину, а шина разносит события между ними и держит общее присутствие. Но предел открытых файлов в юните — 65 535, то есть одна реплика не примет 100 000 соединений даже теоретически. Считайте несколько реплик за балансировщиком и проверяйте, во что упирается шина: она получает публикацию на каждое событие и раздаёт её всем репликам.
- Postgres. Миллиард сообщений в год — это партиционирование, отдельный тюнингованный
кластер и своя стратегия резервного копирования. Роль
postgresиз поставки рассчитана на установку, а не на такой объём; для XL это внешний кластер и его администратор. - Объектное хранилище. 80 ТБ в год — это политика жизнен ного цикла и сроки хранения, а не «диск побольше». Именно на этом размере сроки хранения перестают быть теоретическим разделом.
- Пуши. Фан-аут на 100 000 устройств — вопрос пропускной способности к APNs и FCM и ограничений с их стороны; у нас он не измерялся.
- Каталог и плоскость управления. Координатор не стоит в пути сообщения и звонка, и это главное, что спасает: его нагрузка — вход, синхронизация каталога на 100 000 учётных записей и телеметрия. Но база у него одна и на одной машине; для XL это первое, что нужно проверить отдельно.
Что делать с этим списком
Он не говорит «нельзя». Он говорит, что XL — это проект, а не типоразмер: до обещаний заказчику такого масштаба нужны прогон на его профиле, ответ про трансляции и решение по кластеру Postgres. Если в тендере стоит 100 000 человек, показывайте эту страницу, а не таблицу для L, умноженную на 25.
5. Что растёт, а что нет
| Растёт с числом людей | Почти не растёт |
|---|---|
| медиапул, канал, диск под вложения | координатор: он не в пути звонка и не в пути сообщения |
| база: сообщения за год | redis: держит маршрутизацию комнат, а не данные |
| число VPN-узлов — по локациям, а не по людям | calendar: нагрузка от опроса внешних клиентов, а не от численности |