Особенности архитектуры

Содержание

Особенности архитектуры#

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

Компоненты топологии#

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

Архитектурно система состоит из двух логически независимых, но тесно связанных плоскостей:

плоскости управления (control plane);
плоскости исполнения (execution plane).

Плоскость управления#

Плоскость управления (control plane) реализует компонент Automation Controller. Он может быть установлен как отдельный узел или в виде кластера из нескольких узлов типа control для обеспечения отказоустойчивости и повышения производительности.

Пользователь может управлять ресурсами Automation Controller (описания инвентаря, проекты, задания, среды исполнения, политики доступа к ресурсам) с помощью следующих средств:

графический веб-интерфейс;
REST API;
командный интерфейс (CLI);
специализированную коллекцию Ansible.

Роль Automation Controller#

Automation Controller отвечает за организацию и координацию процессов автоматизации, но не выполняет сценарии напрямую (за исключением использования гибридных узлов). Его задачи включают:

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

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

Основные службы Automation Controller#

Каждый узел Automation Controller включает следующий набор служб:

HTTP служба (HTTP service) обеспечивает доступ пользователей и внешних систем к управлению и мониторингу через веб-интерфейс и REST API.
Служба обратных вызовов (Callback receiver) агрегирует статусы и результаты выполнения задач в реальном времени для внутреннего использования и последующего анализа.
Диспетчер (Dispatcher) управляет системой очередей, распределяя задания между исполнительными узлами и контролируя их выполнение.
Redis выполняет функции оперативного хранения временных данных.
Syslog NG подготавливает и отправляет журналы событий и операций во внешние центры для мониторинга, аудита и поиска инцидентов.

В каждом узле контроллера действует система самовосстановления, реализованная с помощью сервиса supervisord (a process control system). При сбое любой из служб эта система автоматически запускает заново соответствующий сервис или все сервисы Automation Controller в зависимости от степени влияния произошедшего отказа для восстановления работоспособности узла.

Automation Mesh#

Automation Mesh – это сеть прикладного уровня, обеспечивающая взаимодействие между плоскостью управления и плоскостью исполнения.

Automation Mesh определяет маршрут передачи управляющих команд и данных от Automation Controller к узлам плоскости исполнения и обратно. При нарушении сетевых соединений Mesh может автоматически перестроить маршрут между каждой парой взаимодействующих узлов через другие узлы сети Mesh. Это позволяет устанавливать соединений между двумя узлами, даже если между ними нет возможности установить прямой сеанс связи по TCP.

Каждый узел, участвующий в Automation Mesh, запускает процесс receptor. Receptor отвечает за установление, поддержку и мониторинг сетевых соединений между узлами Mesh.

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

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

Плоскость исполнения#

Плоскость исполнения (execution plane) представляет собой распределенную среду выполнения заданий от Automation Controller. Она объединяет узлы, которые непосредственно исполняют сценарии автоматизации в управляемой инфраструктуре.

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

Топология на базе ВМ

../../_images/vm-exec-topology-ac-exec-light.svg

../../_images/vm-exec-topology-ac-exec-dark.svg

../../_images/vm-exec-topology-exec-ac-light.svg

../../_images/vm-exec-topology-exec-ac-dark.svg

Топология в Kubernetes

../../_images/k8s-exec-topology-light.svg

../../_images/k8s-exec-topology-dark.svg

Описание процесса добавления см. в описании операционных задач.

Исполняющие узлы#

Исполняющие узлы (execution nodes) являются конечными точками выполнения заданий автоматизации. Именно на них запускаются сценарии Ansible в изолированных средах исполнения (EE), реализованных в виде контейнеров, управляемых через Podman.

Исполняющие узлы не хранят состояние системы и не используют базу данных. Все задания, параметры и образы EE они получают от Automation Controller через Automation Mesh.

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

Промежуточные узлы#

Промежуточные узлы (hop nodes) используются для обеспечения соединений между сегментами сети внутри Automation Mesh. Они не выполняют сценарии автоматизации и не запускают EE.

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

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

Размещение компонентов и среда развертывания#

Выбор среды развертывания влияет прежде всего на плоскость управления. Automation Controller может быть развернут как на виртуальных машинах, так и в кластере Kubernetes.

Использование Kubernetes относится исключительно к центральной части системы автоматизации. В этом случае кластер Kubernetes используется для размещения компонентов плоскости управления и не определяет архитектуру плоскости исполнения. Automation Controller внутри Kubernetes может устанавливать соединения с другими узлами Mesh по собственной инициативе, но не предоставляет возможности устанавливать такое соединение со стороны этих узлов. Для обеспечения такой возможности предусмотрена возможность установки внутреннего промежуточного узла, который может принимать запросы на установление соединения от исполняющих узлов.

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

Установление соединений в сети Mesh#

Automation Mesh не формируется автоматически. Для того чтобы узлы плоскости исполнения стали доступны Automation Controller, необходимо явно определить их взаимное расположение, роли и направление установления соединений.

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

Развертывание на ВМ#

В среде виртуальных машин формирование Automation Mesh выполняется на основе описания инвентаря. В описании инвентаря указываются узлы плоскости управления, исполняющие и промежуточные узлы, а также параметры их взаимодействия.

После внесения изменений в описание инвентаря выполняется сценарий установки или обновления системы. В ходе его выполнения на узлах запускаются процессы receptor, устанавливаются необходимые соединения и формируется заданная топология Mesh.

Таким образом, добавление или изменение узлов Mesh в среде ВМ осуществляется централизованно в два этапа:

Обновление описания инвентаря.
Запуск утилиты aa-setup.

Подробную инструкция по работе с утилитой aa-setup см. в разделе Развертывание Astra Automation.

Ниже приведены типовые примеры описания инвентаря для различных моделей установления соединений.

Пример 1. Соединение по инициативе плоскости управления.

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

Пример логики топологии:

Automation Controller инициирует соединение с исполняющим узлом напрямую;
промежуточные узлы не используются.

Фрагмент описания инвентаря:

---
# Control plane
automationcontroller:
  hosts:
    ctrl1.example.com:
  vars:
    node_type: control
    peers: execution_nodes

# Execution plane
execution_nodes:
  hosts:
    exec1.example.com:

При такой настройке Mesh строится по схеме control → execution.

Пример 2. Соединение по инициативе узлов плоскости исполнения.

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

Пример логики топологии:

исполняющий узел устанавливает соединение с промежуточным узлом;
в зависимости от расположения промежуточного узла он устанавливает соединение с Automation Controller или наоборот.

Фрагмент описания инвентаря:

---
# Control plane
automationcontroller:
  hosts:
    ctrl1.example.com:
    ctrl2.example.com:
  vars:
    node_type: control
    peers: instance_group_local

# Execution plane
execution_nodes:
  hosts:
    exec1.example.com:
    exec2.example.com:
    exec3.example.com:
    hop1.example.com:

# Execution nodes with direct connection to control nodes
instance_group_local:
  hosts:
    exec1.example.com:
    exec2.example.com:

# Hop node
hop:
  hosts:
    hop1.example.com:
  vars:
    node_type: hop
    peers: automationcontroller

# Remote execution node
instance_group_remote:
  hosts:
    exec3.example.com:
  vars:
    peers: hop

В этом случае Mesh строится по цепочке execution → hop → control. Плоскость управления не принимает запросы на установление сеанса связи, а весь маршрут формируется за счет исходящих подключений от узлов плоскости исполнения.

Развертывание в Kubernetes#

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

При формировании Automation Mesh в Kubernetes используются две основные модели установления соединений, выбор которых определяется сетевой доступностью узлов и требованиями безопасности:

Соединение по инициативе плоскости управления.

Данная модель применяется, если кластер Kubernetes имеет прямую сетевую доступность к узлам плоскости исполнения.

В этом случае контроллер устанавливает постоянное соединение с исполняющими узлами напрямую или через промежуточные узлы.
Соединение по инициативе узлов плоскости исполнения.

Наиболее распространенный сценарий для корпоративных и изолированных сетей.

В этом случае возможны следующие варианты установления постоянных сеансов связи:
- контроллер устанавливает соединение с внутренним промежуточным узлом, реализованным в виде отдельного Pod;
- внешние исполняющие узлы устанавливают соединение с внешними или внутренним промежуточными узлами;
- внешние промежуточные узлы устанавливают соединение с внутренним промежуточным узлом.

Для изменения сети Mesh путем подключения или отключения узлов плоскости исполнения используют следующие методы:

С помощью графической консоли Automation Controller, которая позволяет получить готовый сценарий и описание инвентаря для него.
Универсальный способ: описание требуемой топологии в файле описания инвентаря и выполнение сценария обновления Automation Mesh.

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

Ниже приведены типовые примеры описания инвентаря для различных моделей установления соединений.

Пример 1. Соединение по инициативе плоскости управления.

Этот вариант возможен, если кластер Kubernetes имеет прямую сетевую доступность к узлам плоскости исполнения. Инициатором соединения в этом случае выступает Automation Controller.

Пример логики топологии:

Automation Controller инициирует соединение с исполняющим узлом напрямую;
Mesh строится без промежуточных узлов.

Фрагмент описания инвентаря:

INI

[execution_nodes]
exec-01 ansible_host=10.20.30.40 peers_from_control_nodes=true

YAML

---
execution_nodes:
  hosts:
    exec-01:
      ansible_host: 10.20.30.40
      peers_from_control_nodes: true

Такой подход применяется в доверенных сетях или при наличии маршрутизации между кластером Kubernetes и управляемой инфраструктурой.

Пример 2. Соединение по инициативе узлов плоскости исполнения.

Наиболее распространенный сценарий для узлов, находящихся в DMZ – узлы плоскости исполнения находятся вне кластера и не могут принимать входящие соединения от Automation Controller. В этом случае используется промежуточный узел, размещенный внутри кластера Kubernetes.

Пример логики топологии:

исполняющий узел устанавливает соединение с промежуточным узлом (Mesh Ingress);
внутри кластера Kubernetes Automation Controller устанавливает постоянный сеанс связи с промежуточным узлом.

Фрагмент описания инвентаря:

INI

[hop_nodes]
mesh-ingress receptor_address=2

[execution_nodes]
exec-remote ansible_host=172.18.100.50 hop_node_related=mesh-ingress peers_from_control_nodes=false

YAML

---
hop_nodes:
  hosts:
    mesh-ingress:
      receptor_address: 2

execution_nodes:
  hosts:
    exec-remote:
      ansible_host: 172.18.100.50
      hop_node_related: mesh-ingress
      peers_from_control_nodes: false

В этом случае Mesh строится по схеме execution → hop → control. Это позволяет подключать удаленные или изолированные узлы плоскости исполнения без открытия входящих соединений в кластер Kubernetes.