Автоматизация процессов

Автоматизация процессов#

Система автоматизации процессов (Automation Execution) является центральным компонентом Astra Automation. Обычно она представляет собой кластер, состоящий из управляющих и исполняющих узлов, а также переходных узлов для оптимизации сетевых соединений. Приводимые расчеты и рекомендации помогают оценить требуемое количество узлов и их характеристики в зависимости от объема выполняемых заданий автоматизации.

Расчеты основаны на усредненных показателях потребления системных ресурсов и предназначены для предварительного планирования инфраструктуры. Точные значения могут различаться в зависимости от сложности выполняемых заданий, используемых коллекций Ansible, частоты запуска и распараллеливания процессов.

Приведенная здесь методика позволяет оценить оптимальные параметры кластера для различных моделей развертывания центральной части Astra Automation. Под узлом подразумевается следующий ресурс:

  • при развертывании на ВМ или физических серверах – виртуальная машина или физический сервер соответственно;

  • при развертывании в Kubernetes – Pod.

Примечание

Независимо от модели развертывания исполняющими узлами являются ВМ или физические серверы, которые в общем случае удалены от центральной части Astra Automation.

Принципы расчета производительности#

Astra Automation использует capacity-based модель, в которой доступные ресурсы процессоров и памяти определяют допустимое количество параллельных процессов при выполнении заданий на узле. Этот подход применяется к обоим типам узлов – как управляющим, так и исполняющим.

Расчет мощности по памяти#

Следующая формула рассчитывает допустимое количество параллельных процессов на одном узле с учетом объема оперативной памяти:

\[mem\_capacity = (mem - 2048)\ /\ mem\_per\_fork\]

Здесь:

  • mem – общий объем оперативной памяти узла в мегабайтах;

  • 2048 – память, зарезервированная для системных служб и фоновых процессов;

  • mem_per_fork – объем памяти, потребляемый одним процессом (по умолчанию 100 МБ).

Например, узел с 16 ГБ памяти способен выполнять следующее количество параллельных процессов:

\[(16384 - 2048)\ /\ 100 = 143\]

Расчет мощности по CPU#

Следующая формула рассчитывает допустимое количество параллельных процессов на одном узле исходя из количества доступных ядер:

\[cpu\_capacity = cpus\ \times fork\_per\_cpu\]

Здесь:

  • cpus – количество ядер CPU;

  • fork_per_cpu – количество процессов, допускаемых на одно ядро (по умолчанию 4).

Например, узел с 4 ядрами способен выполнять следующее количество параллельных процессов:

\[4\ \times 4 = 16\]

Итоговая мощность узла#

Следующая формула объединяет показатели CPU и памяти, учитывая баланс между ними через коэффициент capacity_adjustment:

\[capacity\ = cpu\_capacity\ + (mem\_capacity\ - cpu\_capacity)\ \times capacity\_adjustment\]

Здесь:

  • cpu_capacity – рассчитанная мощность по CPU;

  • mem_capacity – рассчитанная мощность по памяти;

  • capacity_adjustment – коэффициент баланса (0.0–1.0):

    • 0.0 – учитывать только CPU;

    • 1.0 – учитывать только память;

    • промежуточные значения определяют смешанный расчет.

    Примечание

    В большинстве случаев используют расчет по памяти (capacity_adjustment = 1.0), но при большом количестве процессов, нагружающих процессор (компиляция, криптография, тяжелый Jinja2-rendering), значение можно уменьшить до 0.5.

Например, при capacity_adjustment = 1.0 итоговая мощность узла рассчитывается по следующей формуле:

\[16\ + (143 - 16)\ \times 1.0\ = 143\]

Расход мощности на задание#

Каждое задание, выполняемое на узле, потребляет часть его вычислительных ресурсов. Это потребление выражается в тех же единицах мощности (capacity units) – условных единицах, которые используются системой планирования Astra Automation для расчета доступной мощности узлов.

Если доступных единиц мощности на узле недостаточно, новое задание ставится в очередь. Ниже приведены типовые значения, показывающие количество единиц мощности, расходуемых на выполнение разных типов заданий:

Тип задания

Стоимость

Описание

Выполнение наборов сценариев

min(forks, number_of_hosts) + 1

Основной тип задания:

  • один управляющий процесс (control, exec)

  • до forks параллельных процессов (exec)

Обновление инвентаря

1

Служебное задание

Обновление проекта

1

Служебное задание для синхронизации проекта из SCM

Системные задания

5

Административные или технические процессы, такие как очистка журналов, обновление репозиториев и прочее

Здесь:

  • forks – параметр, задаваемый через шаблон задания и ограничивающий количество одновременных процессов административно;

  • number_of_hosts – количество целевых узлов из инвентаря, на которых должны выполняться задачи сценариев автоматизации.

Например, если задание набора сценариев содержит forks = 5 и запускается на 10 управляемых узлах, то расход условной мощности на выполнение одного задания (job) рассчитывают по следующей формуле:

\[job\_cost\ = min(5, 10)\ + 1\ = 5\ + 1\ = 6\]

Оценка ресурсов и количества управляющих узлов#

Управляющие узлы Astra Automation планируют задания, обрабатывают события, координируют кластер и обеспечивают работу пользовательского интерфейса (UI и API).

Минимальные системные требования#

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

Характеристика

Значение

Объем RAM, ГБ

16

Количество ядер CPU

4

Свободное дисковое пространство, ГБ

40 (не менее 20 под каталог /var/lib/awx/)

Производительность, IOPS

3000

Производительность управляющего узла#

Необходимо учитывать, что управляющие узлы не обрабатывают обычные сценарии автоматизации, а выполняют служебные задачи:

  • планирование, запуск и завершение заданий автоматизации;

  • обработка событий job events от заданий автоматизации (ведение журналов, обработка потока stdout, отслеживание состояния заданий);

  • выполнение служебных заданий (обновление проектов, очистка).

Для типовой конфигурации (4 CPU, 16 ГБ RAM и 3000 IOPS) расчетная мощность составляет 143 forks (см. расчет). Однако часть ресурсов постоянно занята фоновыми процессами: PostgreSQL, Redis, API, UI, receptor и так далее. Эти процессы потребляют около 5–10 % общей мощности узла. С учетом этих расходов эффективная производительность снижается до 130–140 forks. Для расчетов используется усредненное значение 137 forks, которое отражает практическую мощность типового управляющего узла Astra Automation.

При типовой конфигурации достигаются следующие показатели:

  • примерная мощность – 137 процессов или событий, обрабатываемых одновременно;

  • скорость обработки событий при 100% загрузке – 1100–1600 событий/сек;

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

Расчет количества управляющих узлов#

Чтобы рассчитать количество управляющих узлов, требуемых для обслуживания заданного количества параллельных процессов, воспользуйтесь следующей формулой:

\[control\_nodes = peak\_concurrent\_jobs\ / control\_capacity\]

Здесь:

  • peak_concurrent_jobs – максимальное количество заданий, выполняющихся одновременно;

  • control_capacity – мощность одного управляющего узла (в среднем 137).

Например, для 100 одновременных заданий необходимо следующее количество управляющих узлов:

\[100\ /\ 137\ = 0.73\]

Полученное значение необходимо округлить в большую сторону. В этом случае минимальное количество управляющих узлов равно 1, но для обеспечения высокой доступности (HA) рекомендуется использовать 2 узла.

Дополнительные правила#

В эмпирическом расчете нагрузки на управляющий узел уже учтены процессы обработки событий от заданий (job events) для усредненного случая, когда не требуется детальная информация от заданий, то есть параметр verbosity задания находится в диапазоне 0–2. Для учета повышенного уровня детализации необходимо к формуле применить коэффициент нагруженности по обработке событий (event_load_factor) со следующими значениями:

  • стандартная нагрузка (обычные сценарии автоматизации, verbosity 0–2): 1.0;

  • повышенное количество событий (verbosity 3–4, много задач в сценарии): 0.8;

  • экстремально подробная выходная информация (verbosity 4–5 почти всегда): коэффициент 0.6.

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

\[effective\_capacity\ = node\_capacity\ \times event\_load\_factor\]

Оценка ресурсов и количества исполняющих узлов#

Исполняющие узлы Astra Automation выполняют задания, затребованные управляющими узлами.

Минимальные системные требования#

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

  • объем RAM: 16 ГБ;

  • количество ядер CPU: 4;

  • свободное дисковое пространство: 60 ГБ;

  • производительность: 3000 IOPS.

Эффективная мощность типового исполняющего узла (4 CPU и 16 ГБ RAM) – 143 единицы – выше, чем у управляющего, потому что нет накладных расходов на UI, API, Redis.

Расчет необходимого количества исполняющих узлов#

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

  1. Определите рабочую нагрузку. Для корректного расчета необходимо собрать следующие исходные данные:

    • количество управляемых узлов;

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

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

    • количество параллельных процессов (forks);

    • скорость обработки событий.

    Пример исходных данных:

    Параметр

    Значение

    Управляемые узлы

    300

    Частота выполнения процессов

    ≈ 200 заданий в день

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

    10

    Forks

    5

  2. Вычислите требуемую производительность:

    \[execution\_capacity\_required\ = (peak\_concurrent\_jobs\ \times forks\_typical)\ + peak\_concurrent\_jobs\]

    Здесь:

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

    • forks_typical – типовое значение forks в шаблонах заданий;

    • peak_concurrent_jobs × forks_typical – рабочие процессы; слагаемое + peak_concurrent_jobs учитывает по одному управляющему процессу на задание.

    Например, для исходных данных, приведенных выше, производительность рассчитывается по следующей формуле:

    \[(10\ \times 5)\ + 10\ = 50\ + 10\ = 60\]

  3. Рассчитайте количество узлов:

    \[execution\_nodes\ = execution\_capacity\_required\ /\ capacity\]

    Здесь:

    • execution_capacity_required – требуемая суммарная производительность, рассчитанная на предыдущем шаге;

    • capacity – мощность одного исполняющего узла.

    Примечание

    Несмотря на одинаковую базовую формулу расчета мощности, реальные значения capacity для управляющих и исполняющих узлов различаются:

    • для исполняющего узла при конфигурации 4 CPU и 16 ГБ RAM теоретическая мощность составляет около 143 единиц;

    • для управляющего узла – около 137 единиц, так как часть ресурсов постоянно потребляют системные сервисы.

    Например, для исходных данных, приведенных выше, количество узлов рассчитывается по следующей формуле:

    \[60\ /\ 143\ = 0.42\]

    Полученное значение необходимо округлить в большую сторону. В этом случае минимальное количество исполняющих узлов равно 1, но для обеспечения высокой доступности рекомендуется использовать 2 узла.

Сегментирование#

Для поддержания существующего уровня защищенности и эффективного масштабирования исполняющие узлы располагают ближе к управляемым сегментам инфраструктуры, например в демилитаризованных зонах (DMZ). В расчетах необходимо учесть сегментацию:

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

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

В дальнейшем при настройке системы необходимо объединять исполняющие узлы в группы согласно принадлежности их к сегментам.

Переходные узлы#

Переходные узлы (hop nodes) маршрутизируют трафик в сети Mesh, не выполняя заданий. Их необходимо применять, когда исполняющие узлы расположены в сегментах, недоступных напрямую с управляющих узлов. Они позволяют создавать многоуровневую mesh-топологию (cascaded mesh), позволяющую сократить количество открытых входных портов в сегментах.

Производительность переходных узлов определяется не столько ресурсами в виде CPU и RAM, сколько пропускной способностью сети и задержкой пакетов. Минимальный объем ресурсов (4 CPU, 16 ГБ RAM, 60 ГБ SSD) подходит для трафика до ~1 Гбит/с.

Влияние настройки системы#

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

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

  • max_concurrent_jobs в группе исполняющих узлов (instance group) ограничивает количество одновременно выполняемых заданий (jobs) в этой группе.

  • max_forks в группе исполняющих узлов ограничивает общее количество одновременно выполняемых процессов автоматизации (forks) этой группой.

Эти настройки необходимы для оптимизации работы системы автоматизации, но могут привести к снижению общей производительности по сравнению с расчетными значениями из-за неравномерного распределения нагрузки.

Дисковое хранилище#

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

Тип данных

Примерный объем, МБ

ВМ, физические серверы

Kubernetes

Образы EE

1000–3000 на образ

/var/lib/awx/

Хранилище образов

Файлы проекта из SCM

100–2000 на проект

Управляющий узел: /var/lib/awx/projects/

Хранилище файлов проекта:

  • ephemeral – временное (по умолчанию)

  • permanent – постоянное (настраиваемое)

Временные артефакты задания (временное размещение файлов проекта и данные задания)

10 для больших проектов на задание

Исполняющий узел: /tmp/

Хранилище временных данных задания:

  • ephemeral – временное (по умолчанию)

  • permanent – постоянное (настраиваемое)

Журналы

Десятки–сотни МБ в сутки на топологию даже без выполнения заданий (для базовой топологии – около 240 МБ/сут), под нагрузкой – кратно больше; ротация по умолчанию покрывает не все журналы и не ограничивает их размер (см. Ротация журналов и дисковое пространство)

/var/log/; журнал аудита PostgreSQL – в /var/lib/postgresql/15/main/pg_log/

Инфраструктура ведения журналов

Временные файлы резервного копирования (backup staging)

Зависит от размера баз данных: несжатые дампы и архивы, для рабочих сред – десятки–сотни ГБ (см. Требования к дисковому пространству)

/var/backups/astra-automation/

Зависит от стратегии резервного копирования

Примечание

Каталоги журналов на рабочих узлах быстро растут. К ним относится /var/log/, а на узле базы данных – также /var/lib/postgresql/15/main/pg_log/. Размещать их на общем небольшом разделе с корневой файловой системой не рекомендуется, поскольку переполнение диска нарушает работу компонентов. Под журналы рекомендуется выделять отдельный том и контролировать свободное место (см. Ротация журналов и дисковое пространство).

База данных#

Система автоматизации процессов использует отдельную базу данных для хранения данных.

Объем#

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

Параметр

Влияние

Период хранения истории, retention_days

Увеличение объема хранимых данных

Количество заданий, выполняемых за день, jobs_per_day

Рост таблиц main_job и main_jobevent

Подробность отчетов от заданий, verbosity

Verbosity 3+ увеличивает объем в 5–20 раз

Следующая формула позволяет оценить объем базы данных в ГБ:

\[db\_size\_gb\ ≈ 0.2\ + (jobs\_per\_day\ × retention\_days\ × verbosity\_factor\ × 0.0005)\]

Для verbosity_factor необходимо задавать следующие значения в зависимости от выбранного режима:

  • 1.0 – Normal (verbosity 0)

  • 3.0 – Verbose (verbosity 1)

  • 8.0 – Debug (verbosity 3)

Количество одновременных подключений#

Оцените приближенно пиковое количество одновременных подключений:

\[max\_connections\ ≥ (control\_nodes\ × 30)\ + (execution\_nodes\ × 10)\ + 50\]

PostgreSQL по умолчанию имеет лимит max_connections = 100. При расширении парка узлов этот параметр необходимо увеличить, иначе под нагрузкой будут отказы вида FATAL: too many connections.

Возможности при минимальных ресурсах#

При минимально допустимом объеме ресурсов (4 CPU, 16 ГБ RAM, 150 ГБ SSD, ≥ 1500 IOPS) СУБД выдерживает до 1000 заданий в день.

Калькулятор ресурсов#

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

Если на этапе первичного развертывания платформы оценить приведенные выше показатели сложно, начните с минимально допустимого объема ресурсов, приведенных в описании этапов подготовки.