Важно
Все приведённые конфигурации являются предварительными оценками для планирования ресурсов, а не гарантией производительности при указанном числе пользователей. Фактический сайзинг требует уточнения со стороны команды DevOps с учётом профиля нагрузки, объёма данных, интеграций, требований к доступности и инфраструктуры заказчика.
Значения для разных размеров инсталляции не являются результатами подтверждённых испытаний на предельную нагрузку. Перед закупкой и выделением ресурсов необходимо согласовать итоговую спецификацию с командой DevOps.
| Размер | Общее число пользователей | Назначение |
|---|---|---|
| Минимальная | До 50 | Тестирование или небольшая эксплуатационная инсталляция |
| Малая | 51–100 | Небольшая команда |
| Средняя | 101–250 | Несколько команд или подразделений |
| Крупная | 251–1 000 | Работа нескольких подразделений организации |
| Очень крупная | 1 001–3 000 | Масштабное использование; требуется индивидуальное уточнение профиля |
| Индивидуальная | Более 3 000 | Отдельный расчёт совместно с командой DevOps |
Число пользователей означает общую аудиторию системы, а не одновременные сессии или запросы. Для предварительной оценки предполагается, что активность распределена в течение рабочего дня, а массовые импорты, интеграции и тяжёлые отчёты не создают постоянную пиковую нагрузку.
| Что влияет на сайзинг | Что необходимо уточнить |
|---|---|
| Активность пользователей | Число активных пользователей в пиковые интервалы, частота и состав операций |
| Данные | Объём БД вместе с индексами, число и сложность проектов, глубина истории |
| Отчёты и интеграции | Частота, длительность, параллельность, объём импорта и экспорта |
| ИИ | Объём индексации, частота обновлений, число обращений к ассистенту |
| Доступность | Допустимое время восстановления и допустимая потеря данных |
| Инфраструктура | Доступные CPU/RAM, производительность дисков и сети, существующие сервисы |
Увеличение числа пользователей не означает пропорционального увеличения всех ресурсов: часть памяти и CPU необходима постоянно работающим компонентам независимо от активности.
Вариант предназначен для функционального тестирования, знакомства с системой или эксплуатации с общим числом пользователей до 50. Он не предназначен для воспроизведения производительности крупного продуктивного контура.
HA и отказоустойчивость не предусмотрены. Сервисы работают без резервных экземпляров. При отказе ВМ или компонента система либо отдельные функции будут недоступны до восстановления. Резервное копирование необходимо и не заменяет HA.
| ВМ | Компоненты | vCPU | RAM | Диск для сервисов и данных |
|---|---|---|---|---|
| Основная платформа | Сервисы Timetta, Redis, RabbitMQ | 4 | 16 ГБ | 100 ГБ SSD |
| База данных | PostgreSQL | 4 | 16 ГБ | 100 ГБ SSD |
| ИИ | Эмбеддинги на CPU и AI Client | 4 | 16 ГБ | 60 ГБ SSD |
| Итого | 3 ВМ | 12 | 48 ГБ | 260 ГБ SSD |
Эмбеддинги выполняются на CPU, без GPU. Генерация ответов использует внешний или корпоративный LLM API. Размещение самой языковой модели в этот расчёт не входит.
Объём диска PostgreSQL в примере предполагает начальную БД около 10 ГБ вместе с индексами. Системные диски ВМ, файловое хранилище и резервные копии учитываются отдельно.
Для размещения в существующем Kubernetes используйте бюджет приложений из раздела ниже и дополнительно учтите ИИ. Характеристики ВМ нельзя автоматически переносить в requests контейнеров.
В расчётах основной платформы учитываются Client Host, API, Passport, WebSocket Hub, Consumer, Scheduler и Reporting, а также Redis и RabbitMQ. PostgreSQL показан отдельно. Admin CLI запускается по необходимости; на обслуживание и обновление нужен дополнительный свободный ресурс.
Компоненты ИИ добавляются отдельно. Векторы и индексы семантического поиска размещаются в основной PostgreSQL с расширением pgvector; отдельная векторная БД в расчёт не включается.
Состав и настройку сервисов уточняйте по версии поставки: Поставка on-premises.
В таблицах запись «3 × 4 / 16» означает три ВМ, каждая с 4 vCPU и 16 ГБ RAM. CPU предполагается с гарантированной доступностью; ресурсы с ограниченной долей CPU требуют отдельной оценки. Значения включают предварительный запас для ОС и среды выполнения, но не отдельную систему мониторинга и хранения логов.
| Размер | ВМ платформы, включая Redis и RabbitMQ: количество × vCPU / RAM, ГБ | ВМ PostgreSQL: количество × vCPU / RAM, ГБ | Всего vCPU / RAM, ГБ |
|---|---|---|---|
| Минимальная | 1 × 4 / 16 | 1 × 4 / 16 | 8 / 32 |
| Малая | 1 × 4 / 16 | 1 × 4 / 16 | 8 / 32 |
| Средняя | 1 × 6 / 24 | 1 × 4 / 24 | 10 / 48 |
| Крупная | 1 × 8 / 32 | 1 × 8 / 48 | 16 / 80 |
| Очень крупная | 1 × 16 / 64 | 1 × 16 / 64 | 32 / 128 |
Для минимальной и малой инсталляций предложен одинаковый начальный бюджет: уменьшение аудитории не устраняет затраты на постоянно работающие сервисы. Для очень крупной инсталляции одна ВМ платформы — отправная точка расчёта без HA; DevOps может распределить сервисы по нескольким ВМ по результатам анализа нагрузки.
| Размер | ВМ платформы, включая Redis и RabbitMQ: количество × vCPU / RAM, ГБ | ВМ PostgreSQL: количество × vCPU / RAM, ГБ | Всего vCPU / RAM, ГБ |
|---|---|---|---|
| Малая | 3 × 4 / 16 | 3 × 4 / 16 | 24 / 96 |
| Средняя | 3 × 4 / 24 | 3 × 4 / 24 | 24 / 144 |
| Крупная | 3 × 8 / 32 | 3 × 8 / 48 | 48 / 240 |
| Очень крупная | 3 × 16 / 64 | 3 × 16 / 64 | 96 / 384 |
Это пример топологии для переноса отказа одного узла, при условии достаточности оставшихся ресурсов. Для аудитории до 50 пользователей, которой требуется HA, используйте малую HA-конфигурацию как отправную точку.
ВМ размещаются на независимых физических хостах. Резервирование входной точки, хранилищ и сетевых зависимостей рассчитывается отдельно. Простое увеличение числа ВМ не обеспечивает HA: необходима настройка, описанная ниже.
Для Kubernetes разделяйте бюджет приложений и полную ёмкость узлов. В таблицах ниже приведён суммарный ориентир доступной ёмкости для подов платформы, включая Redis и RabbitMQ, без ИИ. Это не готовые значения requests или limits каждого контейнера.
PostgreSQL для сопоставимости показан на отдельных ВМ. При размещении PostgreSQL внутри Kubernetes его ресурсы добавляются к бюджету подов, а также учитываются оператор, постоянные тома и требования к размещению.
| Размер | Бюджет подов платформы: vCPU / RAM, ГБ | PostgreSQL: количество ВМ × vCPU / RAM, ГБ |
|---|---|---|
| Минимальная | 4 / 16 | 1 × 4 / 16 |
| Малая | 4 / 16 | 1 × 4 / 16 |
| Средняя | 6 / 24 | 1 × 4 / 24 |
| Крупная | 8 / 32 | 1 × 8 / 48 |
| Очень крупная | 16 / 64 | 1 × 16 / 64 |
Предполагается один экземпляр каждого сервиса. Перезапуск пода Kubernetes не обеспечивает непрерывность работы единственного экземпляра.
| Размер | Суммарный бюджет подов платформы: vCPU / RAM, ГБ | Размещение | PostgreSQL: количество ВМ × vCPU / RAM, ГБ |
|---|---|---|---|
| Малая | 12 / 48 | Не менее 3 worker-узлов | 3 × 4 / 16 |
| Средняя | 12 / 72 | Не менее 3 worker-узлов | 3 × 4 / 24 |
| Крупная | 24 / 96 | Не менее 3 worker-узлов | 3 × 8 / 48 |
| Очень крупная | 48 / 192 | Не менее 3 worker-узлов | 3 × 16 / 64 |
Бюджет приведён для всех реплик в штатном состоянии. Его нельзя целиком считать свободным резервом на отказ. DevOps должен проверить размещение и производительность после потери одного worker-узла, а также возможность запуска дополнительных подов во время обновлений.
| Слой | Что учитывать |
|---|---|
| Приложения | Сервисы Timetta, Redis, RabbitMQ, выбранное число реплик |
| Дополнительные компоненты | ИИ; PostgreSQL, если он размещается в Kubernetes |
| Worker-узлы | ОС, kubelet, среда контейнеров, резервы памяти и пороги вытеснения |
| Инфраструктурные поды | Сетевые и дисковые агенты, ingress, DNS, мониторинг и сбор логов |
| Запас | Пиковая нагрузка, обновления; для HA — отказ узла |
| Control plane | Отдельный расчёт для нового кластера; проверка существующего кластера |
Планировщик размещает поды по requests в пределах Node Allocatable. Уже занятые ресурсы и requests инфраструктурных подов также должны быть учтены. Limits определяют ограничения контейнеров и не заменяют расчёт доступной ёмкости.
В существующем кластере необходимо проверить свободную ёмкость и квоты. Для отдельного кластера команда DevOps рассчитывает полные характеристики worker-узлов и control plane. Таблицы выше не являются спецификацией размера ВМ Kubernetes.
HA основной платформы в этой статье означает проектирование на отказ одного узла. Отказ целой площадки и аварийное восстановление в другой площадке требуют отдельной схемы.
| Компонент | Что необходимо предусмотреть |
|---|---|
| Входная точка | Отказоустойчивый балансировщик или ingress и стабильный адрес |
| Сервисы обработки запросов | Не менее двух экземпляров, распределённых по независимым узлам |
| Consumer и Scheduler | Восстановление фоновой обработки; режим параллельного запуска и координация заданий согласно версии поставки |
| PostgreSQL | В примере — primary и две реплики, автоматическое переключение, защита от split-brain, стабильная точка подключения |
| Координация PostgreSQL | Например, Patroni и три участника etcd, размещённые на трёх ВМ БД; ресурсы уточняются вместе с БД |
| Redis | Primary и реплика, автоматическое переключение; например, три Sentinel на независимых узлах при поддержке выбранной конфигурацией |
| RabbitMQ | Три узла и реплицируемые quorum queues для очередей, которым необходима устойчивость к отказу |
| Диски и файловое хранилище | Доступность и восстановление данных при отказе узла; соответствующая схема PVC или внешнего хранилища |
| Резервные копии | Хранение вне узлов приложения и БД, установленный срок хранения и процедура восстановления |
Три экземпляра PostgreSQL — выбранная для таблиц самостоятельная схема, а не универсальный минимум PostgreSQL. Возможны две копии БД с отдельной отказоустойчивой службой координации; такую конфигурацию DevOps рассчитывает отдельно. Режим синхронной или асинхронной репликации выбирается по допустимой потере данных и требованиям к доступности записи.
Реплики PostgreSQL не означают автоматического распределения запросов на чтение: это зависит от поддержки и настройки приложения. Увеличение числа API или Reporting также не устраняет ограничений дисков и БД.
Ресурсы ниже добавляются к основной платформе. Размер сервиса эмбеддингов зависит от объёма индексируемых данных и интенсивности обновлений, поэтому не привязан напрямую к категории пользователей.
| Вариант | Пример отдельной ВМ | GPU | Назначение |
|---|---|---|---|
| Эмбеддинги на CPU и AI Client | 4 vCPU, 16 ГБ RAM, 60 ГБ SSD | Не требуется | Начальная конфигурация; используется в минимальной инсталляции |
| Эмбеддинги на GPU и AI Client | 8 vCPU, 32 ГБ RAM, 80 ГБ SSD | 1 совместимый GPU с 16 ГБ видеопамяти | Альтернатива для ускорения индексации; необходимость уточняется по нагрузке |
| LLM | Отдельный расчёт либо внешний/корпоративный API | Зависит от модели и способа размещения | Генерация ответов |
Для CPU-сервиса эмбеддингов в текущей инструкции предусмотрено 4 vCPU и 8 ГБ RAM непосредственно контейнеру. Характеристики ВМ включают дополнительное место для AI Client, ОС и среды выполнения. В Kubernetes ресурсы каждого контейнера и накладные расходы узлов рассчитываются отдельно.
AI-логика работает в основных сервисах Timetta, а векторы хранятся в основной PostgreSQL. Индексация увеличивает нагрузку на БД и фоновые процессы; отдельный сервер эмбеддингов не снимает эту нагрузку.
По умолчанию в таблице предусмотрен один экземпляр сервиса эмбеддингов без HA, в том числе при HA основной платформы. При его отказе связанные с ним функции ИИ и индексации могут быть недоступны. Изоляцию ошибок и таймауты необходимо настроить так, чтобы отказ ИИ не блокировал обычные операции платформы. HA всего ИИ-контура, включая LLM, рассчитывается отдельно.
Подробнее: AI on-premises.
Объём хранилища не определяется только числом пользователей. В CPU/RAM-таблицы выше не включены системные диски, хранилища вложений, архивы WAL и резервные копии.
| Назначение | Основа расчёта |
|---|---|
| PostgreSQL | Фактический размер всех БД, индексы, рост данных, WAL, временные файлы и свободное место для обслуживания |
| Redis и RabbitMQ | Объём сохраняемых данных, максимальное накопление очередей, срок хранения и репликация |
| Образы и логи контейнеров | Размер образов, число сохраняемых версий, интенсивность и ротация логов |
| Вложения / S3 | Объём файлов, прирост, версии и политика хранения |
| Резервные копии | Размер полных и инкрементальных копий, срок хранения, архив WAL и место для восстановления |
| Назначение | Предварительный бюджет |
|---|---|
| Текущие данные и индексы | 10 ГБ |
| Рост данных и индексов | 20 ГБ |
| WAL | 20 ГБ |
| Временные файлы и обслуживание | 20 ГБ |
| Свободный резерв | 30 ГБ |
| Всего на экземпляр | 100 ГБ SSD |
Это пример эксплуатационного запаса, а не фиксированное правило «диск в десять раз больше БД». WAL зависит от скорости изменений и времени отставания реплик или недоступности архивации. Его удержание и оповещения о заполнении диска необходимо настроить отдельно.
При трёх экземплярах PostgreSQL требуется три полных копии данных: для этого примера — 3 × 100 ГБ SSD. Резервные копии и архив WAL хранятся отдельно и в эти 300 ГБ не входят. Производительность SSD, IOPS и задержки требуют отдельной оценки.
Итоговая спецификация должна фиксировать следующие параметры.
| Область | Результат уточнения |
|---|---|
| Нагрузка | Пользовательский профиль, пики, интеграции и фоновые операции |
| Вычислительные ресурсы | Количество ВМ или узлов, vCPU/RAM, реплики, requests и limits |
| Доступность | Схема переключения, размещение по хостам, допустимые сроки восстановления и потеря данных |
| Хранение | Ёмкость, производительность, рост, PVC, архивы и резервные копии |
| Эксплуатация | Мониторинг, пороги оповещений, обновление и возможность расширения |
После запуска оценки уточняются по фактическому потреблению CPU/RAM, задержкам запросов, состоянию очередей, дисковым операциям и росту данных.
Похоже, вам удобнее русский язык. Перейти на русскую версию?