Требования к нарезанию машин в кластере

Требования к нарезанию машин в кластере#

В рамках кластера учитываются не только pod’ы серверов приложений, но и все инфраструктурные компоненты, необходимые для работы системы: балансировщик, брокер очередей, планировщик заданий, компоненты маршрутизации, а также системы мониторинга и логирования, например Prometheus, Grafana, Loki.

Отдельно учитываются база данных и файловое хранилище.

Приведенные далее требования и рекомендации относятся к системе в целом, однако основная часть ресурсов, как правило, приходится на серверы приложений.

Для точного расчета используйте sizing-инструмент.

База данных#

В качестве СУБД используется PostgreSQL.

Рекомендуемая версия PostgreSQL — 17 и выше. Минимальная поддерживаемая версия — 14.

Нагрузка на базу данных зависит от количества пользователей, интенсивности пользовательских операций и количества интеграционных потоков.

Ресурсы базы данных#

Для стартовой оценки ресурсов базы данных учитываются:

  • количество одновременных пользователей;

  • количество интеграционных потоков;

  • объем данных;

  • интенсивность чтения и записи;

  • требования к отказоустойчивости и резервному копированию.

Для контура с 500 одновременными пользователями и 10–20 интеграционными потоками ориентировочная конфигурация PostgreSQL:

  • основной узел — 8–16 vCPU;

  • RAM — 32–64 ГБ.

База данных, как правило, масштабируется вертикально, а также за счет использования реплик, обслуживающих запросы на чтение.

Отказоустойчивость PostgreSQL#

Для обеспечения отказоустойчивости PostgreSQL могут использоваться следующие решения:

  • Pacemaker;

  • Postgres Pro Cluster.

Резервное копирование#

Для баз данных до 1.5 ТБ можно использовать логические и бинарные дампы.

Для баз данных более 1.5 ТБ используются потоковая репликация и физические бэкапы с WAL.

Серверы приложений#

Серверы приложений являются основным потребителем ресурсов в кластере. Их ресурсы рассчитываются от пользовательской нагрузки и интеграционных потоков.

Основной способ масштабирования серверов приложений — горизонтальный, за счет увеличения количества pod’ов и балансировки нагрузки между ними. Вертикальное масштабирование используется ограниченно, когда необходимо увеличить CPU и RAM конкретного pod’а.

При такой схеме pod’ы не должны хранить пользовательское состояние в локальной памяти. Сессии, данные и другие рабочие состояния должны размещаться во внешних компонентах, например в базе данных, кэше или файловом хранилище. Это позволяет свободно перераспределять нагрузку между pod’ами и упрощает отказоустойчивость.

CPU#

CPU рассчитывается от нагрузки пользователей и интеграций.

Минимальное значение — 2 vCPU на pod/инстанс.

При росте нагрузки ресурсы масштабируются:

  • горизонтально — за счет увеличения количества pod’ов;

  • вертикально — за счет увеличения ресурсов pod’а.

RAM#

Основной параметр при расчете RAM — Xmx JVM.

Требования и рекомендации:

  • Xmx не должен превышать 32 ГБ;

  • общий объем RAM должен быть не менее Xmx + 10%;

  • не рекомендуется выделять память без запаса.

Диск#

Для pod’ов серверов приложений ориентир — 20 ГБ на pod.

Общий объем диска зависит от количества pod’ов.

Для standalone-решения рекомендуется не менее 120 ГБ на ВМ.

Пример расчета серверов приложений на 500 одновременных пользователей#

Для контура с 500 одновременными пользователями и 10–20 интеграционными потоками можно использовать следующую стартовую конфигурацию:

  • слой приложений — 4 pod’а по 4 vCPU, 16 ГБ RAM и 20 ГБ диска на каждый pod;

  • Xmx для каждого pod — порядка 12–14 ГБ;

  • Kubernetes worker-ноды, варианты:

    • 4 ноды по 8 vCPU и 24 ГБ RAM;

    • или 3 ноды по 8 vCPU и 48 ГБ RAM;

  • диск на каждой ноде — не менее 120 ГБ.

Конфигурация является ориентировочной и используется для предварительной оценки.

Дополнения по конкретным микросервисам и компонентам#

Для отдельных компонентов могут задаваться дополнительные требования к ресурсам.

Файловое хранилище#

В качестве файлового хранилища используется NFS или S3-совместимое хранилище.

Минимальные ресурсы файлового хранилища:

  • CPU — от 4 vCPU;

  • RAM — от 4 ГБ.

Объем файлового хранилища определяется отдельно и зависит от объема прикрепленных файлов, документов, отчетов и других сохраняемых данных.

Для контура с 500 одновременными пользователями файловое хранилище рекомендуется размещать на отдельном NFS или S3-совместимом узле с параметрами не менее 4 vCPU и 4 ГБ RAM.

Мониторинг и логирование#

Компоненты мониторинга и логирования учитываются в составе инфраструктурных ресурсов кластера.

Объем ресурсов зависит от:

  • количества pod’ов и нод;

  • объема собираемых метрик;

  • объема логов;

  • срока хранения данных мониторинга и логирования;

  • интенсивности пользовательской и интеграционной нагрузки.

Для нагруженных систем ресурсы мониторинга и логирования рассчитываются отдельно.

Сеть#

Между всеми узлами требуется не менее 1 Гбит/с.

Такая пропускная способность должна быть обеспечена между:

  • нодами приложений;

  • базой данных;

  • файловым хранилищем;

  • инфраструктурными компонентами кластера.

Для нагруженных систем рекомендуется 10 Гбит/с.

Общий пример расчета на 500 одновременных пользователей#

Для контура с 500 одновременными пользователями и 10–20 интеграционными потоками можно использовать следующую стартовую конфигурацию:

  • слой приложений — 4 pod’а по 4 vCPU, 16 ГБ RAM и 20 ГБ диска на каждый pod;

  • Xmx для каждого pod — порядка 12–14 ГБ;

  • Kubernetes worker-ноды:

    • 4 ноды по 8 vCPU и 24 ГБ RAM;

    • или 3 ноды по 8 vCPU и 48 ГБ RAM;

  • диск на каждой ноде — не менее 120 ГБ;

  • PostgreSQL — 8–16 vCPU и 32–64 ГБ RAM на основной узел;

  • файловое хранилище — отдельный NFS или S3-совместимый узел с параметрами не менее 4 vCPU и 4 ГБ RAM;

  • сеть между узлами — не менее 1 Гбит/с.

Конфигурация является ориентировочной и используется для предварительной оценки. Для точного расчета используйте sizing-инструмент.

Содержание