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

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

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

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

  • CPU

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

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

    • при росте нагрузки ресурсы масштабируются горизонтально за счет увеличения количества pod’ов или вертикально за счет увеличения ресурсов pod’а.

  • RAM

    • основной параметр — Xmx JVM;

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

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

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

  • Диск

    • в кластере ориентир — 20 ГБ на pod;

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

    • для standalone-решения — не менее 120 ГБ на ВМ.

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

    • используется NFS или S3-совместимое хранилище;

    • минимальные ресурсы: CPU — от 4, RAM — от 4 ГБ;

    • объем определяется отдельно.

  • База данных

    • используется PostgreSQL;

    • рекомендуемая версия — 17 и выше;

    • минимальная версия — 14;

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

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

    • возможные решения: Pacemaker или Postgres Pro Cluster.

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

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

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

  • Сеть

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

    • такая пропускная способность должна быть обеспечена между нодами приложений, базой данных и файловым хранилищем;

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

Принципы нарезки кластера#

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

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

Пример расчета на 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-инструмент.

Содержание