Продолжаем публиковать блог нашего друга Алеся Носека.
В первая часть мы говорили о конвейерах CI/CD, охватывающих несколько кластеров OpenShift. И сегодня мы поговорим об архитектуре системы Apache Airflow на платформе OpenShift, рассмотрим функции ее ключевых компонентов и способы их развертывания применительно к Apache Airflow версии 1.10.12. Напоминаем, что любой вопрос после прочтения Алеси вы можете задать в комментариях.
За самый оригинальный вопрос - туристический набор с картой маршрута от Red Hat - в подарок.
И шляпа!
Архитектура воздушного потока
Apache Airflow состоит из трех основных компонентов: веб-сервера, планировщика и воркеров.Веб-сервер отвечает за веб-интерфейс, который является основным инструментом работы с Airflow и позволяет пользователю визуализировать свои DAG (Directed Acyclic Graph) и контролировать их выполнение.
Кроме того, Webserver предоставляет экспериментальный REST API, который позволяет управлять Airflow программно, а не через веб-интерфейс.
Второй компонент, Airflow Scheduler, координирует выполнение групп DAG, обеспечивая их запуск в нужное время и в правильном порядке.
И веб-сервер, и планировщик — долгоживущие службы, но третий компонент Airflow, так называемые рабочие, — это эфемерные модули.
Они создаются Kubernetes Executor и служат только для выполнения одной задачи DAG. После завершения задачи ее Worker-pod уничтожается.
Архитектура Aiflow на платформе OpenShift показана на рисунке ниже: 
Общая база данных
Как видно из схемы, компоненты Airflow взаимодействуют друг с другом не напрямую, а путем чтения и изменения состояний в общая база данных .Например, веб-сервер берет текущее состояние выполнения DAG из этой базы данных и отображает его в веб-интерфейсе.
Когда вы запускаете группу обеспечения доступности баз данных в веб-интерфейсе, веб-сервер обновляет состояние групп доступности базы данных в базе данных.
Планировщик периодически проверяет эти состояния и, обнаружив запуск и проверив, что для этого подходящее время, отправляет на выполнение новые задачи.
После выполнения задачи Worker присваивает ей соответствующий статус в базе данных, а веб-интерфейс считывает этот статус и показывает пользователю, что задача выполнена.
Архитектура общей базы данных обеспечивает полностью согласованное представление о состоянии системы для всех компонентов Airflow. Однако по мере увеличения количества выполняемых задач база данных становится узким местом в производительности, поскольку к ней подключается все больше и больше воркеров.
Чтобы снизить нагрузку на базу данных, подключения к ней можно осуществлять через пул соединений, например PgBouncer , который будет поддерживать относительно небольшое количество подключений к базе данных и повторно использовать их для обслуживания запросов от разных воркеров.
Что касается выбора СУБД, то в производстве, как правило, используется PostgreSQL или MySQL. База данных может работать непосредственно на платформе OpenShift, в этом случае она должна располагаться на постоянном томе RWO (ReadWriteOnce), организованном, например, средствами Контейнерное хранилище OpenShift .
Или вы можете использовать внешнюю базу данных, например, если ваш OpenShift размещен в облаке AWS, вы можете использовать сервис управляемой СУБД.
Как предоставить компонентам Airflow доступ к группам обеспечения доступности баз данных
Все три основных компонента Airflow — веб-сервер, планировщик и рабочие — построены на предположении, что определения DAG можно прочитать из локальной файловой системы.Но как обеспечить доступ к DAG, когда локальная файловая система находится в контейнере? Есть два пути.
Первый — создать общий том для хранения всех DAG и подключить его к модулям Airflow. Второй подход предполагает, что группы обеспечения доступности баз данных размещаются в репозитории git, а боковые контейнеры развертываются рядом с сервером Airflow и планировщиком, периодически синхронизируя репозиторий с локальной файловой системой.
Что касается модулей Worker, DAG извлекаются из репозитория только один раз, и это делается контейнером инициализации перед запуском Worker. Обратите внимание, что начиная с версии Airflow 1.10.10 вы можете использовать функцию Сериализация DAG .
В этом случае планировщик считывает группы DAG из локальной файловой системы и сохраняет их в базе данных.
И веб-сервер затем читает эти DAG из базы данных, а не из локальной файловой системы.
То есть можно обойтись без подключения общего тома к контейнеру Webserver и без настройки git-sync. Для синхронизации DAG с локальной файловой системой мы предпочитаем использовать git-sync, а не общие тома.
Во-первых, DAG и все остальное лучше держать в системе контроля версий, во-вторых, git-sync, на наш взгляд, гораздо проще с точки зрения устранения неполадок и восстановления после сбоев.
Мониторинг воздушного потока
Как известно, без контроля производство не производство.
Как отслеживать Apache Airflow, работающий на OpenShift? Мы рекомендуем использовать для этого Прометей – Система мониторинга рабочей нагрузки Kubernetes. Airflow генерирует метрики с помощью протокола statsd, поэтому вам необходимо будет развернуть statsd_exporter как прослойка между Airflow и Prometheus, которая будет собирать метрики statsd, преобразовывать их в формат Prometheus и затем предоставлять их на сервер Prometheus.
Сбор логов Airflow
По умолчанию Apache Airflow записывает журналы в локальную файловую систему.Если у вас есть постоянный том RWX (ReadWriteMany), вы можете подключить его к веб-серверу, планировщику и рабочему устройству и писать туда логи.
Поскольку логи Worker записываются в общий том, они сразу же доступны веб-серверу, что позволяет просматривать их в веб-интерфейсе в режиме реального времени.
Или вы можете использовать альтернативный подход — удаленное ведение журнала Airflow. В этом случае логи Worker отправляются в какое-то другое место, например, на S3, откуда Веб-сервер затем их забирает и отображает в веб-интерфейсе.
Обратите внимание, что если такое удаленное место является объектным хранилищем, логи Worker загружаются туда только после завершения задачи.
До тех пор они не будут видны в веб-интерфейсе, а значит, контроль в реальном времени будет утерян.
Удаленное ведение журналов Airflow занимается журналами Worker, но что делать с журналами веб-сервера и планировщика, если у нас нет постоянного тома? Тогда Airflow можно настроить так, чтобы он сбрасывал логи на stdout, а OpenShift уже их соберет и отправит в какое-то центральное хранилище.
Заключение
До сих пор мы рассматривали архитектуру Apache Airflow на платформе OpenShift, роли ее отдельных компонентов и то, как они взаимодействуют друг с другом, а также всю базу данных Airflow. Кроме того, мы показали, как сделать DAG доступными для компонентов Airflow, и рассказали о мониторинге и ведении журналов Ariflow. Теги: #Виртуализация #git #облачные сервисы #с открытым исходным кодом #Kubernetes #postgresql #prometheus #MySQL #Red Hat #apache airflow #Openshift #Amazon RDS-
Резервное Копирование Во Freenas
19 Oct, 24 -
Краткая Версия Социальной Сети
19 Oct, 24 -
Должны Ли Android И Symbian Объединиться?
19 Oct, 24 -
Обзор Китайского Планшета На Android
19 Oct, 24 -
.Net-Детектив: Об Интерфейсах И Рефлексии
19 Oct, 24 -
Коллекционер Дизайна Вернулся
19 Oct, 24
