Документ описывает типовые конфигурации аппаратных ресурсов для развертывания продукта Почта VK WorkSpace. Документ предназначен для системных архитекторов, инженеров эксплуатации и пресейл-специалистов.
В гайде представлены пять типовых конфигураций на разное количество пользователей с отказоустойчивостью (ОУ):
- 1000 пользователей
- 5000 пользователей
- 10 000 пользователей
- 15 000 пользователей
- 20 000 пользователей
Расчеты выполнены для релиза продукта 26.3 по методике, основанной на результатах нагрузочного тестирования референсных инсталляций.
Схема установки: инсталляция выполняется в кластер Kubernetes; ресурсные нормы релиза 26.3 включают накладные расходы Kubernetes. Docker-инсталляция с релиза 26.3 не поддерживается.
VK Почта WorkSpace — почтовый продукт, обеспечивающий прием, обработку, хранение и доставку электронной почты, а также полнотекстовый поиск по почтовым сообщениям.
Группа серверов | Сервисы | Назначение |
|---|---|---|
Фронты | SMTP-транспорт, IMAP-фронты, WebMail API (mrim/web) | Прием исходящей почты, выдача почты клиентам (IMAP/POP3), веб-интерфейс, маршрутизация запросов |
Базы данных | Tarantool (аккаунты, сессии, настройки, метаданные), PostgreSQL, Kafka, etcd, scylla | Хранение учетных записей, сессий, индексов писем, настроек пользователей |
Хранилища | mescalito/xtaz (шардируемое хранилище скелетов писем), zepto-индексы (zepto_main, zepto_opt, zepto_del, zepto_metad, zepto_skel), облачные хранилища (mailcloud, blobcloud, cldst) | Постоянное хранение скелетов и тел писем, вложений, файловых индексов |
Crow-index | crow (индексация), поисковые сниппеты (zepto_search) | Полнотекстовая индексация входящих писем и поиск по почтовым сообщениям |
Мониторинг и установщик | VictoriaMetrics, cAdvisor, zabbix-exporter, deployer | Сбор метрик, развертывание и обновление системы |
Kubernetes Control Plane | kube-apiserver, kube-controller-manager, kube-scheduler, cluster state / orchestration services | Оркестрация кластера Kubernetes, хранение и обработка состояния кластера, планирование pod'ов, управление жизненным циклом workloads |
Системы миграции (AD/Exchange) не входят в постоянный состав: на больших инсталляциях на период миграции выделяются отдельные ВМ миграции, которые после ее завершения передаются фронтам (см. раздел Коэффициенты расчета).
Группа серверов | Ресурс | Сервисы с пиковой нагрузкой | Комментарий |
|---|---|---|---|
Фронты | CPU | IMAP/SMTP-фронты, WebMail API | Пики CPU при массовых переподключениях клиентов (утренний пик) и обработке SMTP-сессий |
Базы данных | RAM | Tarantool (резидентные индексы и кэш метаданных), Kafka (очереди сообщений), PostgreSQL (кэш) | RAM — основной лимитирующий ресурс, потребление растет с числом пользователей и объемом метаданных/писем. Tarantool держит данные в памяти |
Хранилища | IOPS (SSD) + пропускная способность | mescalito/zepto (запись скелетов и индексов писем), Tarantool (чувствителен к задержкам диска), mailcloud/blobcloud (запись тел писем и вложений) | Лимитирующий фактор — IOPS и пропускная способность SSD при записи/чтении почтовых тел, скелетов и индексов. Tarantool чувствителен к latency диска |
Crow-index | CPU + объем/пропускная способность диска | crow (индексация писем), zepto_skel (тела писем), mailcloud/blobcloud (вложения) | Пиковая нагрузка CPU при прохождении очереди на индексацию. Объем и пропускная способность диска — на телах писем и вложениях |
Мониторинг и установщик | CPU/RAM (умеренно) | мониторинг (сбор метрик, дашборды), установщик/ansible (деплой) | Ресурсопотребление умеренное. Пики CPU/RAM возникают при массовом сборе метрик и во время операций развертывания/обновления |
Kubernetes Control Plane | CPU/RAM + SSD | kube-apiserver, scheduler, controller-manager, состояние кластера | Нагрузка умеренная и определяется числом узлов и объектов Kubernetes. Компонент не обрабатывает пользовательский почтовый трафик напрямую, но критичен для оркестрации и операций управления кластером |
Witness-сервер (сервер-свидетель) — выделенный узел, на котором размещаются вспомогательные сервисы инфраструктуры (координация, обнаружение, кэш, брокер, хранилище метрик). Он не обрабатывает пользовательский почтовый трафик напрямую, но критичен для работоспособности и наблюдаемости кластера. В отказоустойчивых конфигурациях Witness обеспечивает кворум и разрывает схемы отказа.
Сервисы | Описание | Комментарий |
|---|---|---|
etcd | Распределенное хранилище ключ-значение. Координация и конфигурация кластера, leader election | Кворум etcd критичен для доступности кластера |
consul | Обнаружение сервисов и реестр. Health-checks компонентов | Обеспечивает маршрутизацию и контроль состояния сервисов |
extz | Внешний Zookeeper-подобный координатор (координация распределенных компонентов/очередей) | Используется для координации распределенных процессов |
redis | In-memory кэш и брокер временных данных/сессий | Ускоряет доступ к часто используемым данным. Данными можно пожертвовать при перезапуске |
clickhouse | Колоночная БД для хранения метрик, логов и аналитики мониторинга | Хранилище телеметрии и исторических метрик. Основной потребитель диска на Witness |
kafka | Брокер сообщений для асинхронных задач и очередей между сервисами | Буферизация событий. При сбое часть событий может быть повторно обработана |
Control Plane — выделенные серверы управления кластером Kubernetes, обеспечивающие оркестрацию, планирование и управление жизненным циклом компонентов продукта. Control Plane не обрабатывает пользовательский почтовый трафик, но обязателен для штатной работы инсталляции в Kubernetes начиная с релиза 26.3. Ресурсы control plane — 3 сервера (по одному на каждый домен отказа/ЦОД); размер сервера определяется числом воркер-узлов кластера: до ~30 узлов — 16 vCPU / 32 ГБ RAM, далее 16 vCPU / 64 ГБ (до 100 узлов), 24 vCPU / 96 ГБ (до 250), 32 vCPU / 128 ГБ (до 500), 64 vCPU / 256 ГБ (свыше 500); SSD — 140 ГБ на сервер. Один из серверов допускается размещать на Witness.
Сервисы | Описание | Комментарий |
|---|---|---|
kube-apiserver | Основная точка управления кластером Kubernetes; API для всех операций оркестрации | Критичен для управления объектами кластера и взаимодействия компонентов |
kube-controller-manager | Контроллеры фоновых задач Kubernetes: reconciliation, управление desired state | Обеспечивает поддержание целевого состояния кластера |
kube-scheduler | Планировщик pod'ов по рабочим узлам кластера | Влияет на распределение нагрузки и запуск сервисов |
cluster state services | Службы, обеспечивающие обработку и публикацию состояния control plane | Требуют стабильных CPU/RAM и локального диска под системные данные |
В качестве базовой характеристики (Primary Sizing Metric) используется количество активных пользователей почтовой системы. Метрика отражает реальную нагрузку на систему (фронты, БД, хранилище, поиск). Выделяемые ресурсы масштабируются пропорционально росту этой характеристики.
Sizing Unit: «на 1000 активных пользователей».
Примечание: пиковые сценарии (раздел Пиковые нагрузки (Spike)) определяются в первую очередь интенсивностью потока новых писем (писем в час), а не только числом пользователей. Динамика потока писем учтена в профиле нагрузки (раздел Профиль нагрузки) и используется при расчете пиковых нагрузок.
Параметры базового профиля, заложенные в расчет:
Параметр | Значение | Описание |
|---|---|---|
Квота почтового ящика | 5 ГБ | Размер ящика пользователя |
Средний размер письма | ~239 КБ (средневзвешенный, с учетом вложений) | Используется для расчета объемов хранения. По данным производственной почты: медиана (p50) ~52 КБ, p90 ~121 КБ, p95 ~183 КБ — большинство писем маленькие, объем определяют письма с вложениями |
Средний размер вложения | ~915 КБ | 0,25 вложения на письмо |
Писем на ящик (за срок хранения) | ~21 000 | С учетом всей истории хранения |
Доля одновременного онлайна | 10% | От числа пользователей |
Процент резерва ресурсов | 20% | Запас на каждый сервер (headroom) |
Схема установки | Kubernetes | Инсталляция в кластер Kubernetes; Docker-инсталляция не поддерживается с релиза 26.3 |
Продукт | Только Почта | Настоящий гайд охватывает исключительно почтовый компонент |
Динамика нагрузки (объем генерируемого трафика):
Параметр | На пользователя | На 1000 пользователей |
|---|---|---|
Отправлено писем (исходящие, рабочий день) | ~2–3 в день | ~2 000–3 000 / сутки |
Получено писем (входящие) | ~8–10 в день | ~8 000–10 000 / сутки |
Создано календарных событий | ~1–2 в неделю | ~1 000–2 000 / неделю |
Писем в час (среднесуточная интенсивность) | ~0,4 | ~400–500 |
Писем в час (пиковый час, ×3 от среднего) | до ~1,2 | до ~1 200–1 500 |
Календарные события генерируют почтовые приглашения (iCal): каждое событие с приглашениями создает дополнительно 2–10 писем, что учитывается в общем почтовом трафике.
Система должна корректно обрабатывать прогнозируемые пики потребления. Типовые пиковые сценарии:
- Утренний пик подключений: массовое подключение клиентов в начале рабочего дня — до ×3 от среднего RPS на фронты/IMAP в течение 10–30 минут.
- Массовая синхронизация после обновлений: при обновлении почтовых клиентов все пользователи одновременно подключаются и синхронизируют ящики.
- Массовые рассылки: пиковая нагрузка на SMTP-транспорт и очередь индексации crow.
Описание пикового часа: утренний пик 09:00–11:00 (по местному времени основных пользователей). В этот интервал приходится до 25–30% суточного количества IMAP/SMTP-подключений и отправляемых писем. Интенсивность в пиковый час — до ×3 от среднечасовой. Длительность пика — 1–2 часа.
Количество писем в час: на 1000 пользователей — в среднем ~400–500 писем/час, в пиковый час — до ~1 200 – 1 500 писем/час (×3). Масштабируется линейно с числом пользователей (на 20 000 — соответственно ~8 000 – 10 000 средн. / до ~24 000 – 30 000 пик).
Критерий прохождения пика: при ×3 от расчетной нагрузки фон ошибок 5xx — не более 0,1%, допустим рост p95 latency до ×2 от штатных значений. После пика работоспособность полностью восстанавливается. Пиковые подключения должны равномерно распределяться между фронтами балансировщиком.
Заявленные конфигурации должны обеспечивать следующие SLO при расчетной нагрузке:
Метрика | SLO | Метод измерения |
|---|---|---|
IMAP p95 latency | ≤ 500 мс | Нагрузочное тестирование IMAP-операций |
SMTP p95 latency | ≤ 1000 мс | Нагрузочное тестирование SMTP-операций |
HTTP API p95 latency | ≤ 300 мс | Нагрузочное тестирование Web-интерфейса |
Поиск p95 latency (p95 при spike) | ≤ 300 мс (≤ 600 мс) | Нагрузочное тестирование полнотекстового поиска |
Фон ошибок 5xx | ≤ 0,1% | Мониторинг HTTP-ошибок |
Утилизация CPU (steady-state) | p95 ≤ 75% | Метрики cAdvisor/VictoriaMetrics |
Утилизация IOPS | p95 ≤ 80% от лимита | iostat / метрики СХД |
- Запрещена переподписка CPU (overcommit) для сред с требованиями к предсказуемой латентности. Опираться на Hyper-Threading как на эквивалент физического ядра. CPU/vCPU считаются по физическим ядрам.
- Рекомендуется отключать энергосберегающие режимы (p-state/c-state), влияющие на латентность.
- Рекомендуется фиксировать: модель CPU, базовую/турбо частоты, NUMA-топологию.
- Эталонный процессор: Intel Xeon Gold 6338 (коэффициент 100%). При использовании других моделей CPU применять нормирование (см. раздел «Нормирование CPU»).
Примечание: утилита tuned по умолчанию отключается. Профиль tuned virtual-guest потенциально может повысить производительность ВМ — возможность его использования согласовывается с технической поддержкой (влияние на сайзинг требует верификации).
- Запрещено использование ballooning и агрессивного overcommit RAM для продуктивных нагрузок.
- Память должна быть зарезервирована за сервисом (не shared).
- Swap не допускается (противоречит официальной документации и пререквизитам).
- Для компонентов, чувствительных к задержкам, необходимо задавать целевые значения latency (p95/p99), а не только IOPS/MBps.
- При использовании общей СХД рекомендуется фиксировать гарантии QoS либо выделение пула под продукт.
- SSD: NVMe или SATA SSD. Поддерживаются два подхода к дисковой подсистеме:
- Аппаратный RAID (RAID 1/RAID 10) на каждом узле — рекомендуется, если вы ориентируетесь на простоту эксплуатации и единый стандарт. Обеспечивает избыточность на уровне диска.
- Без аппаратного RAID (прямое подключение дисков / JBOD) с избыточностью на уровне софтового рейда (Ceph, ZFS) — допустимо, когда избыточность обеспечивается на уровне кластера/программного стека.
- Внутренний трафик между ВМ: не менее 10 Гбит/с.
- Для multi-DC схем фиксируются требования к межузловой пропускной способности, latency и jitter.
- Рекомендуется фиксировать: скорость линков, oversubscription, наличие QoS, MTU.
- Входящие порты: TCP 80/443 (HTTP/HTTPS), TCP 25/465/587 (SMTP), TCP 143/993 (IMAP), TCP 110/995 (POP3).
Параметр | Требование | Комментарий |
|---|---|---|
Канал на пользователя (WebMail/IMAP-клиент) | не менее 1–2 Мбит/с | Для комфортной работы с веб-интерфейсом и синхронизации IMAP-клиентов |
Совокупный канал на фронт-группу | ~10 Мбит/с на 100 одновременно активных пользователей | Оценивается от доли одновременного онлайна (базово 10%) |
Задержка (RTT) до фронтов | ≤ 100 мс | Для сохранения SLO по latency пользовательских операций |
Потери пакетов | ≤ 0,1% | Влияет на переподключения IMAP-сессий |
- Для отказоустойчивого балансирования входящих соединений (SMTP/IMAP/HTTPS) при размещении в VK Cloud обязательно использование VIP-агрегатов.
- При размещении в сторонних облаках требуется функциональный аналог: балансировщик L4/L7 с плавающим IP (floating IP / VIP) и health-check'ами бэкендов.
- Балансировщик должен равномерно распределять длительные IMAP-сессии между всеми фронтами (consistent hashing / leastconn).
Внимание: механизм VIP-агрегатов на сети может направлять весь трафик в один VIP (выбирается ближайший узел) — при использовании требуется контроль равномерности распределения трафика между VIP.
Используемые в гайде флейворы ВМ валидированы для развертывания в VK Cloud. При развертывании на bare metal или сторонних платформах виртуализации указанные конфигурации являются ориентировочными и требуют обращения в техническую поддержку.
- Обязательно использование NTP/chrony. Допустимое расхождение часов — не более 50 мс.
- Критично для кворумов и сервисов Tarantool.
Для конфигураций с отказоустойчивостью (ОУ):
- Witness сервер: включен — обеспечивает кворум кластера хранилищ.
- Crow-index: вынесен на отдельные серверы.
- Резервирование: «Половина» (×2) — полное дублирование ВМ по фронтам, БД, хранилищам и crow-index.
Все типовые конфигурации в данном гайде выполняются с отказоустойчивостью (ОУ): включен Witness, включен отдельный Crow-index, применяется резервирование (×2).
При развертывании учитываются домены отказа (Fault Domains) — группы узлов, которые могут выйти из строя одновременно. Доменами отказа являются ЦОД (при развертывании в двух ЦОДах — два домена, по одному на ЦОД) и/или кластер виртуализации (при развертывании в одном ЦОД). Применяются следующие подходы:
- Два домена отказа по двум ЦОД: при развертывании с отказоустойчивостью создаются два домена отказа, распределенные по двум ЦОД — по одному домену отказа в каждом ЦОД. Это обеспечивает работоспособность системы при полной потере одного ЦОД.
- Один домен отказа (один ЦОД): используется типовая конфигурация из раздела Детальные конфигурации. При этом отказоустойчивость ограничена пределами одного ЦОД — система защищена от отказа отдельных узлов, но не от потери всего ЦОД.
Размещение серверов по разным стойкам/питающим линиям не является обязательным требованием и может выполняться при наличии соответствующих требований.
Режим | Описание | Ожидаемый эффект |
|---|---|---|
Нормальный | Все компоненты работают штатно, полная репликация/синхронизация данных | Обеспечивается полная производительность и SLO |
Отказ компонента (ОУ) | Один или несколько узлов отключены (питание, maintenance, graceful shutdown) | Нагрузка перераспределяется на оставшиеся узлы. Производительность может быть снижена, но доступность сохраняется. Допускается частичное ограничение функциональности |
Переходный (восстановление) | Возвращение узлов после отказа, добавление нод под нагрузкой | Синхронизация данных, перераспределение ролей. Допускается частичное ограничение функциональности |
Переходный (обновление) | Rolling update без полной остановки системы | Поэтапное обновление по зонам доступности с контролем доступности и механизмами отката. Длительность обновления зависит от масштаба инсталляции и фиксируется в плане обновления. Допускается частичное ограничение функциональности. |
Расчет ресурсов ведется относительно эталонного ядра. Эталонный процессор — Intel Xeon Gold 6338 (32 ядра / 64 потока, 2.0 ГГц). Рекомендуемая конфигурация сервера — 2× Intel Xeon Gold 6338 (~124 vCPU). Производительность процессоров существенно различается, поэтому для расчетов рекомендуется:
- Либо указывать конкретную модель CPU в SG и в отчетах по тестам.
- Либо приводить ресурсы к нормированной шкале по таблице ниже.
Модель | Поколение | Ядер/Потоков | Базовая (ГГц) | Турбо (ГГц) | Коэф. на ядро (%) |
|---|---|---|---|---|---|
Xeon Gold 6338 | 3rd Gen | 32/64 | 2.0 | 3.2 | 100 (эталон) |
Xeon Gold 6448Y | 4th Gen | 32/64 | 2.1 | 4.1 | 122 |
Xeon Platinum 8580 | 5th Gen | 60/120 | 2.0 | 4.0 | 149 |
Xeon Gold 6548N | 5th Gen | 32/64 | 2.8 | 4.1 | 134 |
Xeon Platinum 8468 | 4th Gen | 48/96 | 2.1 | 3.8 | 129 |
Xeon Platinum 8462Y+ | 4th Gen | 32/64 | 2.1 | 4.1 | 130 |
Xeon Gold 6530 | 5th Gen | 32/64 | 2.1 | 3.9 | 116 |
Xeon Gold 6442Y | 4th Gen | 24/48 | 2.6 | 4.1 | 112 |
Xeon Gold 6444Y | 4th Gen | 16/32 | 3.6 | 4.0 | 102 |
Xeon Gold 6430 | 4th Gen | 32/64 | 2.1 | 3.4 | 101 |
Xeon Gold 5418Y | 5th Gen | 24/48 | 2.0 | 3.8 | 98 |
Xeon Silver 4410Y | 4th Gen | 12/24 | 2.0 | 3.9 | 67 |
Коэффициенты пересчитаны относительно эталона Intel Xeon Gold 6338, носят оценочный характер и подлежат верификации на стенде.
Примечание: коэффициенты и набор CPU требуется поддерживать в актуальном состоянии (переоценка при добавлении новых моделей).
Выделяются два стандартных уровня хранения по соотношению цена/производительность:
Уровень | Тип | IOPS на узел | Latency |
|---|---|---|---|
Быстрые диски | SSD NVMe / Enterprise Flash | 50 000–1 000 000+ | менее 0,5 мс |
Нормальные диски | SSD SATA / Enterprise SSD | 5 000–50 000 | 0,5–2 мс |
Требования задаются по каждому сервису отдельно — это позволяет проектировать размещение лунов (LUN) по СХД при внедрении и эксплуатации:
Сервис / хранилище | Уровень | Назначение | Доля от объема уровня |
|---|---|---|---|
Tarantool (БД) | Быстрые диски (NVMe) | Резидентные данные, xlog/WAL БД | отдельный лун БД (500–1000 ГБ на ВМ) |
crow-index | Быстрые диски | Хранилище индексов поиска | ~45% быстрого пула |
zepto_main | Быстрые диски | Файловый индекс основной информации о письмах | ~20% быстрого пула |
zepto_opt | Быстрые диски | Файловый индекс метаинформации о письмах | ~15% быстрого пула |
zepto_del | Быстрые диски | Файловый индекс удаленных писем | ~10% быстрого пула |
zepto_metad | Быстрые диски | Хранилище файловых деревьев пользователей | ~10% быстрого пула |
mailcloud | Нормальные диски (SSD) | Вложения размером до 25 МБ | ~62% нормального пула |
zepto_skel | Нормальные диски (SSD) | Тела писем | ~25% нормального пула |
zepto_search | Нормальные диски (SSD) | Поисковые сниппеты | ~6% нормального пула |
cldst | Нормальные диски (SSD) | Хранилище файлов Диска и S3 | ~5% нормального пула |
blobcloud | Нормальные диски (SSD) | Временные вложения | ~2% нормального пула |
Уровень хранения | p95 read | p95 write | p99 write | Комментарий |
|---|---|---|---|---|
Быстрые диски (NVMe) | ≤ 0,5 мс | ≤ 1 мс | ≤ 2 мс | Для кворумов, БД (Tarantool), crow-index |
Нормальные диски (SSD) | ≤ 2 мс | ≤ 5 мс | ≤ 10 мс | Для индексов mescalito/zepto |
Коэффициент | Значение | Описание |
|---|---|---|
Коэффициент копий (copy factor) | ×2 | Каждая порция данных хранится в двух экземплярах на разных ВМ хранилищ (мастер + реплика). Обеспечивает сохранность данных при отказе одной ВМ |
Коэффициент истории файлов (history factor) | ×1.2 | Запас +20% на версии/историю изменений файлов: при перемещении писем между папками и изменении флагов обновляются файловые индексы, дельта-структуры и метаданные. Накладные расходы на операции с историей |
RAID factor | ×1.0 | Резервирование на уровне RAID не закладывается (отказоустойчивость обеспечивается репликами на уровне приложения). При использовании RAID на ВМ учитывать отдельно |
Максимум диска на одну ВМ | 240 ТБ | Ограничение максимального размера флейвора ВМ хранилища в VK Cloud. При превышении — горизонтальное масштабирование (добавляется новая ВМ хранилища) |
Правила масштабирования диска по сервисам:
- БД (Tarantool): SSD кластера БД — 200 ГБ (базово). Объем под Tarantool невелик и слабо зависит от числа пользователей: для типовых конфигураций до 20 000 пользователей достаточно 200–400 ГБ на кластер. Точное значение уточняется при верификации.
- Хранилища (mescalito/zepto/mailcloud): объем диска растет пропорционально числу пользователей и квоте ящика. Масштабирование — добавлением ВМ хранилищ (шард mescalito — 5000–7000 пользователей).
- Crow-index: поисковый индекс ~50 КБ на каждое письмо. Масштабирование — добавлением ВМ crow (при ОУ — из расчета с резервированием ×2).
- Мониторинг: SSD +200 ГБ на каждые 5 000 пользователей (максимум 3 000 ГБ).
Место под Tarantool по конфигурациям (оценочно):
Конфигурация | Пользователей | SSD под Tarantool |
|---|---|---|
1000 (с ОУ) | 1 000 | 200 ГБ |
5000 | 5 000 | 200 ГБ |
10000 | 10 000 | 300 ГБ |
15000 | 15 000 | 400 ГБ |
20000 | 20 000 | 400 ГБ |
Компонент | Флейвор | vCPU | RAM, ГБ | SSD | Диск |
|---|---|---|---|---|---|
Фронты | flavor-1 (16-64) | 16 | 64 | 575 ГБ | — |
Базы данных | flavor-3 (16-128) | 16 | 128 | 575–1075 ГБ | — |
Хранилища | flavor-1 (16-128) | 16 | 128 | 700 ГБ | до 240 ТБ |
Crow-index | flavor-3 (32-128) | 32 | 128 | 575 ГБ | до 240 ТБ |
Witness | flavor-1 (16-32) | 16 | 32 | 700 ГБ | — |
Мониторинг и установщик | flavor-1 (16-40) | 16 | 40 | 575–1375 ГБ | — |
Control Plane | flavor-1 (16-32) — flavor-2 (64-256) по числу воркер-узлов | 16–64 | 32–256 | 140 ГБ | — |
С релиза 26.3 инсталляция выполняется только в Kubernetes: флейворы описывают группы узлов кластера Kubernetes (node groups) под компоненты, а не виртуальные машины Docker-инсталляции.
Флейворы применимы для развертывания в VK Cloud. На bare metal / сторонних платформах — конфигурации ориентировочные и требуют верификации продуктовой командой.
Рекомендуемый эталонный сервер — 2× Intel Xeon Gold 6338 (~124 vCPU).
Параметр | 1000 (с ОУ) | 5000 (с ОУ) | 10000 (с ОУ) | 15000 (с ОУ) | 20000 (с ОУ) |
|---|---|---|---|---|---|
Пользователей | 1000 | 5000 | 10000 | 15000 | 20000 |
Всего узлов | 13 | 21 | 31 | 43 | 55 |
Всего vCPU | 240 | 368 | 528 | 720 | 944 |
Всего RAM, ГБ | 1064 | 1832 | 2856 | 4232 | 5512 |
SSD, ГБ | 6545 | 11845 | 18545 | 26395 | 36245 |
HDD, ГБ | 12667 | 63337 | 126674 | 190012 | 253349 |
Всего диск, ГБ | 19212 | 75182 | 145219 | 216407 | 289594 |
Фронты | 2 узла | 6 узлов | 10 узлов | 14 узлов | 18 узлов |
Базы данных | 2 узла | 2 узла | 2 узла | 4 узла | 4 узла |
Хранилища | 2 узла | 6 узлов | 12 узлов | 18 узлов | 24 узла |
Crow-index | 2 узла | 2 узла | 2 узла | 2 узла | 4 узла |
Witness | 1 узел | 1 узел | 1 узел | 1 узел | 1 узел |
Мониторинг | 1 узел | 1 узел | 1 узел | 1 узел | 1 узел |
Control Plane | 3 узла | 3 узла | 3 узла | 3 узла | 3 узла |
Общий объем диска складывается из: SSD фронтов + SSD БД + (SSD + Диск) хранилищ + SSD Witness + SSD Crow-index + SSD мониторинга и установщика + SSD Control Plane; строки SSD и HDD показывают распределение общего объема по типам дисков. Узлы — узлы кластера Kubernetes (группы узлов) под компоненты; в таблицах раздела Детальные конфигурации они обозначены как «ВМ».
Отказоустойчивая конфигурация: включен Witness, включен отдельный Crow-index, применяется резервирование (×2).
Компонент | Кол-во ВМ | vCPU на ВМ | RAM на ВМ, ГБ | SSD на ВМ, ГБ | Диск на ВМ, ГБ | Итого vCPU | Итого RAM, ГБ | Итого диск, ГБ |
|---|---|---|---|---|---|---|---|---|
Фронты | 2 | 16 | 64 | 575 | — | 32 | 128 | 1150 |
Базы данных | 2 | 16 | 128 | 575 | — | 32 | 256 | 1150 |
Хранилища | 2 | 16 | 128 | 700 | 5209 | 32 | 256 | 11819 |
Witness | 1 | 16 | 32 | 700 | — | 16 | 32 | 700 |
Crow-index | 2 | 32 | 128 | 575 | 1124 | 64 | 256 | 3399 |
Мониторинг и установщик | 1 | 16 | 40 | 575 | — | 16 | 40 | 575 |
Control Plane | 3 | 16 | 32 | 140 | — | 48 | 96 | 420 |
Итого | 13 | — | — | — | — | 240 | 1064 | 19212 |
Отказоустойчивая конфигурация: включен Witness, отдельный Crow-index, полное резервирование (×2).
Компонент | Кол-во ВМ | vCPU на ВМ | RAM на ВМ, ГБ | SSD на ВМ, ГБ | Диск на ВМ, ГБ | Итого vCPU | Итого RAM, ГБ | Итого диск, ГБ |
|---|---|---|---|---|---|---|---|---|
Фронты | 6 | 16 | 64 | 575 | — | 96 | 384 | 3450 |
Базы данных | 2 | 16 | 128 | 575 | — | 32 | 256 | 1150 |
Хранилища | 6 | 16 | 128 | 700 | 8682 | 96 | 768 | 52895 |
Witness | 1 | 16 | 32 | 700 | — | 16 | 32 | 700 |
Crow-index | 2 | 32 | 128 | 575 | 5621 | 64 | 256 | 11971 |
Мониторинг и установщик | 1 | 16 | 40 | 775 | — | 16 | 40 | 775 |
Control Plane | 3 | 16 | 32 | 140 | — | 48 | 96 | 420 |
Итого | 21 | — | — | — | — | 368 | 1832 | 75182 |
Компонент | Кол-во ВМ | vCPU на ВМ | RAM на ВМ, ГБ | SSD на ВМ, ГБ | Диск на ВМ, ГБ | Итого vCPU | Итого RAM, ГБ | Итого диск, ГБ |
|---|---|---|---|---|---|---|---|---|
Фронты | 10 | 16 | 64 | 575 | — | 160 | 640 | 5750 |
Базы данных | 2 | 16 | 128 | 575 | — | 32 | 256 | 1150 |
Хранилища | 12 | 16 | 128 | 700 | 8682 | 192 | 1536 | 112870 |
Witness | 1 | 16 | 32 | 700 | — | 16 | 32 | 700 |
Crow-index | 2 | 32 | 128 | 575 | 11243 | 64 | 256 | 23636 |
Мониторинг и установщик | 1 | 16 | 40 | 975 | — | 16 | 40 | 975 |
Control Plane | 3 | 16 | 32 | 140 | — | 48 | 96 | 420 |
Итого | 31 | — | — | — | — | 528 | 2856 | 145219 |
Компонент | Кол-во ВМ | vCPU на ВМ | RAM на ВМ, ГБ | SSD на ВМ, ГБ | Диск на ВМ, ГБ | Итого vCPU | Итого RAM, ГБ | Итого диск, ГБ |
|---|---|---|---|---|---|---|---|---|
Фронты | 14 | 16 | 64 | 575 | — | 224 | 896 | 8050 |
Базы данных | 4 | 16 | 128 | 575 | — | 64 | 512 | 2300 |
Хранилища | 18 | 16 | 128 | 700 | 8682 | 288 | 2304 | 168282 |
Witness | 1 | 16 | 32 | 700 | — | 16 | 32 | 700 |
Crow-index | 2 | 32 | 128 | 575 | 16865 | 64 | 256 | 34378 |
Мониторинг и установщик | 1 | 16 | 40 | 1175 | — | 16 | 40 | 1175 |
Control Plane | 3 | 16 | 64 | 140 | — | 48 | 192 | 420 |
Итого | 43 | — | — | — | — | 720 | 4232 | 216407 |
Компонент | Кол-во ВМ | vCPU на ВМ | RAM на ВМ, ГБ | SSD на ВМ, ГБ | Диск на ВМ, ГБ | Итого vCPU | Итого RAM, ГБ | Итого диск, ГБ |
|---|---|---|---|---|---|---|---|---|
Фронты | 18 | 16 | 64 | 575 | — | 288 | 1152 | 10350 |
Базы данных | 4 | 16 | 128 | 1075 | — | 64 | 512 | 4300 |
Хранилища | 24 | 16 | 128 | 700 | 8682 | 384 | 3072 | 224721 |
Witness | 1 | 16 | 32 | 700 | — | 16 | 32 | 700 |
Crow-index | 4 | 32 | 128 | 575 | 11243 | 128 | 512 | 47215 |
Мониторинг и установщик | 1 | 16 | 40 | 1375 | — | 16 | 40 | 1375 |
Control Plane | 3 | 16 | 64 | 140 | — | 48 | 192 | 420 |
Итого | 55 | — | — | — | — | 944 | 5512 | 289594 |
В терминах релиза 26.3 «ВМ» означает узлы кластера Kubernetes (группы узлов) под компоненты; инсталляция выполняется только в Kubernetes, Docker-инсталляция не поддерживается.
На больших инсталляциях на период миграции с AD/Exchange дополнительно выделяются ВМ миграции. После завершения миграции они передаются фронтам.
Для релиза 26.3 также необходимо закладывать отдельные серверы Kubernetes Control Plane: 3 сервера во всех типовых конфигурациях. Флейвор выбирается по числу воркер-узлов кластера: при числе воркер-узлов до ~30 — 16 vCPU / 32 ГБ RAM / 140 ГБ SSD на сервер; при ~31–100 воркер-узлах — 16 vCPU / 64 ГБ RAM / 140 ГБ SSD; при 101–250 — 24 vCPU / 96 ГБ; при 251–500 — 32 vCPU / 128 ГБ; свыше 500 — 64 vCPU / 256 ГБ.
Компонент | Основной лимит | Метрика насыщения | Порог | Рекомендованное действие |
|---|---|---|---|---|
Фронты | CPU | p95 CPU ≥ 75% | ≥ 70% | Добавить ВМ фронтов (горизонтальное масштабирование) |
Базы данных (Tarantool) | RAM / SSD | p95 write-latency > 5 мс, заполнение SSD ≥ 80% | RAM ≥ 80% | Репликация / вертикальное масштабирование. ВАЖНО: решардирование Tarantool после установки невозможно — число шардов фиксируется один раз при развертывании и должно закладываться с запасом на рост (5000–7000 пользователей на шард) |
Хранилища | Диск объем | Заполнение диска ≥ 80% | ≥ 80% | Добавить ВМ хранилищ (с учетом коэффициента копий ×2) |
Crow-index | Диск / CPU | Заполнение диска поиска ≥ 80% или p95 CPU ≥ 75% | ≥ 80% / ≥ 75% | Добавить ВМ Crow-index (1 сервер 16/64 на ~2300 пользователей, при ОУ — с резервированием) |
Мониторинг | Диск метрик | Заполнение SSD ≥ 80% | ≥ 80% | Увеличить SSD или добавить ВМ мониторинга |
Kubernetes Control Plane | CPU/RAM etcd и kube-apiserver | p95 CPU ≥ 75% или рост latency API-сервера | ≥ 75% | Вертикальное масштабирование серверов control plane по таблице флейворов (зависит от числа воркер-узлов) |
Важно: решардирование Tarantool после установки не поддерживается (одноразовая операция при развертывании) — число шардов БД выбирается при планировании инсталляции с запасом на рост числа пользователей.
Вертикальное масштабирование (scale-up) предпочтительно, если:
- Компонент ограничен RAM (кэш/буферы) или CPU без сильной конкуренции.
- Нет явных архитектурных ограничений на конкурентность.
Горизонтальное масштабирование (scale-out) предпочтительно, если:
- Компонент stateless (фронты) и масштабируется линейно.
- Есть ограничение по single-thread/локам, где добавление CPU не помогает.
- Достигнут лимит диска на ВМ (240 ТБ диска) — необходимо увеличивать количество инстансов.
Компонент | Граница вертикального масштабирования | Граница горизонтального масштабирования |
|---|---|---|
Сервисы сборщиков писем (rimap/picker) | — | Выносятся на отдельные серверы при более 100 одновременных сборщиков: 1 сервер 8/32 на 2000 сборщиков |
Сервисы поиска и индексирования (crow) | — | 1 сервер 16/64 на ~2300 пользователей |
mescalito/xtaz | — | Шардирование: 5000–7000 пользователей на шард |
Фронты | 16 vCPU / 64 ГБ RAM на ВМ | 1 ВМ на ~800 пользователей (с ОУ, резервирование «Половина») |
Хранилища | 16 vCPU / 128 ГБ RAM / 240 ТБ диска на ВМ | При активации raft (2n+1) — округление до нечетного числа (минимум 3) |
При развертывании с ОУ конфигурация размещается в двух ЦОД: два домена отказа, по одному в каждом ЦОД (см. раздел Домены отказа), что обеспечивает работоспособность при полной потере одного ЦОД:
- Фронты, БД и хранилища — равномерно распределены между ЦОД.
- Witness — в третьем ЦОД (или изолированном сегменте).
- Мониторинг — в одном из ЦОД.
Допускается развертывание в одном ЦОД (один домен отказа) — типовая конфигурация из раздела Детальные конфигурации. При этом отказоустойчивость ограничена пределами одного ЦОД.
Дополнительно к расчетным ресурсам требуется сервер резервного копирования:
- CPU: 10 vCPU
- RAM: 20 ГБ
- Диск: ~0.145 ГБ на пользователя (для 20 000 пользователей — ~2.9 ТБ)
Расчет ресурсов основан на коэффициентах потребления, полученных по результатам нагрузочного тестирования релиза 26.3 на референсных инсталляциях. Нормы учитывают инсталляцию в Kubernetes и включают накладные расходы Kubernetes:
Компонент | CPU на пользователя | RAM на пользователя, ГБ |
|---|---|---|
Frontend | 0.01258 | 0.06475 |
Database | 0.00144 | 0.00753 |
Storage | 0.00487 | 0.07405 |
Crow | 0.00066 | 0.01110 |
Witness | 0.00015625 | 0.00148438 |
Миграция с AD/Exchange: для миграции с Microsoft Exchange / AD выделяются отдельные ВМ миграции. На больших инсталляциях ВМ миграции выделяются дополнительно к типовой конфигурации. После завершения миграции они передаются во фронты. Ресурсы и количество ВМ миграции зависят от объема и сроков миграции и уточняются при планировании (обращение в техническую поддержку).
В расчет включен следующий функционал Почты VK WorkSpace (релиз 26.3):
- Веб-интерфейс (WebMail) и доступ по протоколам IMAP/SMTP/POP3.
- Полнотекстовый поиск по почтовым сообщениям (crow).
- Антиспам-фильтрация и базовая транспортная обработка.
- Хранение писем и вложений в рамках квоты ящика (5 ГБ).
- Штатное журналирование и метрики (observability).
Не включено в расчет (оценивается отдельно):
- Импорт из Exchange (exchange-importer) и миграция данных.
- Сборщики писем с внешних ящиков (rimap/picker) — свыше 100 одновременных сборщиков.
- S/MIME-шифрование и ГОСТ TLS (дополнительная нагрузка на CPU при активном использовании).
Включение/отключение отдельных фич существенно влияет на потребление ресурсов — при изменении функционального состава требуется верификация конфигурации продуктовой командой.
- Гайд охватывает исключительно Почту VK WorkSpace. Документ не описывает сайзинг других продуктов платформы.
- Объем диска зависит от квоты почтового ящика (в расчете — 5 ГБ). При увеличении квоты объем диска растет линейно.
- С релиза 26.3 инсталляция выполняется только в Kubernetes; ресурсные нормы релиза 26.3 уже включают накладные расходы Kubernetes. Docker-инсталляция не поддерживается.
- При несоответствии инфраструктуры базовым допущениям (overcommit CPU, ballooning RAM, общая СХД без QoS) конфигурация требует верификации продуктовой командой.