Выбор топологии

Выбор топологии#

Выбор топологии выполняется на двух уровнях:

  • Выбор модели развертывания – ВМ (или физические серверы) из deb-пакетов или Kubernetes;

  • Выбор масштаба развертывания – базовая топология или уровень предприятия.

ВМ или Kubernetes#

Дерево принятия решения выглядит следующим образом:

Используется ли в производственной среде организации кластер Kubernetes с поддержкой StorageClass SSD и операторов?
├── НЕТ ─ развертывание на ВМ
└── ДА: Требуется ли быстрое горизонтальное масштабирование подов при пиковых нагрузках?
        ├── ДА ─ Kubernetes
        └── НЕТ: Готова ли команда эксплуатации поддерживать AA внутри K8s?
                 ├── ДА ─ Kubernetes (ниже совокупная стоимость инфраструктуры)
                 └── НЕТ ─ развертывание на ВМ (ниже операционная сложность)

Важно

Плоскость исполнения (execution и hop nodes) при обеих моделях развертывают на ВМ. В кластере Kubernetes развертывают только центральные компоненты: Platform Gateway, Automation Controller, Private Automation Hub, EDA, Redis, опционально PostgreSQL.

Более подробно критерии выбора отражены в следующей таблице:

Критерий

ВМ из пакетов

Kubernetes

Kubernetes доступен

Нет

Да

Высокая плотность развертывания

Нет

Да

Автоматическое восстановление и масштабирование

Нет

Да

Команда готова к управлению Kubernetes

Нет

Да

Операционная сложность при небольшом количестве управляемых узлов

Низкая

Высокая

Операционная сложность при больших масштабах

Средняя

Относительно ниже

Базовая топология или уровень предприятия#

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

Критерий

Базовая (Growth)

Уровень предприятия (Enterprise with High Availability)

Целевая доступность

до 99.5%

от 99.9% и выше

Парк управляемых узлов

до 1000

от 1000 и выше

Одновременные задания

до 50

от 50 и выше

Дублирование компонентов

отсутствует

минимум 2–3 экземпляра каждого

СУБД

внутренняя (Pod+PV или одна ВМ)

внешний кластер PostgreSQL

Балансировщик

не требуется

обязателен (например HAProxy)

Минимальное количество ВМ (развертывание на ВМ)

7

13

Минимальное количество рабочих узлов (развертывание в Kubernetes)

1

3 (с автомасштабированием)

Развитие платформы#

Если на текущий момент сложно выбрать между предложенными вариантами, рассмотрите следующие рекомендуемые решения с возможностью дальнейшего масштабирования:

  • Kubernetes для центра + ВМ для исполняющих узлов в DMZ и частично изолированных сегментах – стандартная рекомендуемая модель;

  • Базовая топология сейчас + миграция на уровень предприятия через 12–18 месяцев – выгодно, если на старте парк составляет менее 500 узлов и есть план роста;

  • Многоуровневая mesh-топология – независимо от топологии центра по мере увеличения нагрузки на сегменты инфраструктуры увеличить количество исполняющих узлов с маршрутизацией через hop-узлы.

Дальнейшие шаги#

Далее рассмотрим особенности расчета ресурсов для каждого компонента Astra Automation.