Основные приложения АрмАдм¶

Основные приложения установки OpenStack АрмАдм, не связаны с консолью управления облаком. Основные приложения, связанные с обслуживанием системы запускаются из консоли управления Horizon. Все приложения могут иметь собственные серверы и СУБД и предоставляют доступ по WEB интерфейсу.

Система управления облаком OpenStack¶

Графическая Web консоль управления системы OpenStack/AccentOS позволяет управлять облаком и сервисными подсистемами. Существующая графическая Web консоль управления облаком OpenStack/AccentOS Horizon привычна для администраторов, имеет расширенный набор возможностей, интеграционных возможностей, но имеет ряд проблем с CVE движка Gjango и производительностью, поэтому к ней целесообразно подключаться администратору системы по терминальному протоколу. Новая графическая Web консоль управления облаком OpenStack/AccentOS Skyline не имеет проблем с CVE и производительностью, но пока не имеет расширенного набора возможностей, поэтому к ней целесообразно подключаться администраторам проектов по HTTP-протоколу

Интеграция приложений в интерфейсе системы управления облаком¶

Для получения доступа к сервисным приложениям обслуживанием системы необходимо предусмотреть кнопки в Horizon.

Система проверки инфраструктуры (ICar)¶

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

Действия выполняемые в ходе проверки:

Сначала идет проверка установлены ли пакеты для работы скрипта в ОС:

    "availability": "Available 0 from 0",
    "available_servers": "",
    "problem_servers": "not found"
},
"/var/www/html/ha/stable/astra/1.7/initrc_.controller": {
    "availability": "Available 1 from 2",
    "available_servers": "10.252.40.166",
    "problem_servers": "10.252.43.2"

————————————————-<CHECK_MTU>————————————————–

«DESTINATION»: «10.252.43.12», «OK»: [ «1500, OK»,

«1400, OK», «1300, OK», «1200, OK», «1100, OK», «1000, OK», «900, OK», «800, OK», «700, OK», «600, OK», «500, OK», «400, OK», «300, OK», «200, OK», «100, OK»

], «FAILED»: []

Система автоустановки (FirstBoot)¶

С помощью Firstboot выполняется первоначальная инсталляция Облака, восстановление облака в случае аварии и масштабирование Системы. Данную работу он выполняет с помощью функционала, реализованного на использовании скриптов bash и сервера сетевой установки и обновления «Cobbler». Данная система позволяет гибко дополнять сценарий установки, что и было сделано инженерами Компании. В частности, были созданы следующие модули:

Установка и настройка системы мониторинга Zabbix;
Установка и настройка системы резервного копирования Bacula;
Выполнение проверки работоспособности Облака инструментами Tempest.

Система тестирования Облака (Tempest)¶

Tempest — это официальный фреймворк для интеграционного тестирования OpenStack. Он представляет из себя набор автоматических тестов, который проверяет, что ваше облако OpenStack работает правильно, что все его сервисы (Nova, Neutron, Cinder и т.д.) корректно взаимодействуют друг с другом и соответствуют заявленному API. Ключевые функции Tempest:

- Проверка API: Tempest гарантирует, что API каждого сервиса OpenStack соответствует официальной спецификации. Это критически важно для совместимости с другими инструментами и клиентами (например, Horizon, CLI-утилитами).
- Проверка сценариев: Он не просто проверяет, что сервис "живой", а выполняет сложные пользовательские сценарии. Например:

Создать сеть -> запустить в ней виртуальную машину -> прикрепить к ВМ диск -> сделать снимок диска -> и т.д.

Методика «Черный ящик»: Tempest работает с OpenStack как «снаружи», через его публичное API, точно так же, как это делал бы обычный пользователь или программа. Ему не нужен доступ к внутреннему коду сервисов.
Для кого он предназначен:
Разработчики OpenStack: Они запускают Tempest в CI/CD-пайплайнах, чтобы убедиться, что их изменения в коде не сломали существующую функциональность. Администраторы облаков: С его помощью можно проверить работоспособность развернутого облака после установки или обновления, а также регулярно мониторить его здоровье.

Система журналирования (Syslog)¶

Централизованный сбор журналов требуется для повышения безопасности системы, удобства администрирования и для снижения риска переполнения локальных журналов на хостах и ВМ. Централизованный сбор журналов с физических хостов, контроллеров облака, базы данных облака, гипервизоров, модулей AccentOS, контейнеров и других элементов осуществляется с помощью утилиты syslog в отдельную папку (том) на АрмАдм со следующих источников:

- хостовых ОС серверов облака, включая события безопасности сети, гипервизора, аутентификации, файловой системы
- ОС контроллеров и СУБД (если контроллеры и СУБД запущены на ВМ)
- приложений AccentOS - модулей OpenStack, модулей AccentOS, СУБД, Redis, Rabbit, HA-Proxy
- контейнеров с приложениями
- журналов событий и приложений АрмАдм.

В средствах rsyslog/syslog-ng должна быть включена компрессия «на лету» для эффективного использования дискового пространства. Syslog на АрмАдм настраивается с параметрами log rotate и переносом архивов в папку резервного копирования для исключения переполнения журнала.

Система анализа журналов событий (OpenSearch, Grafana)¶

Обработка журнала событий, поиск, фильтрация, сортировка информации, формирование отчетов должно производиться для соответствия требованиям регулятора. В качестве средства анализа журналов событий, в зависимости от используемой сертифицированной ОС, должны использоваться rsyslog/syslog-ng и OpenSearch/Grafana. В средствах OpenSearch/Grafana должно использоваться кеширование для ускорения поиска и компрессия (Loki) для уменьшения размеров журналов данных. Для уменьшения количества устанавливаемых агентов и размера трафика, источником данных лучше указать централизованный журнал syslog с АрмАдм.

Система мониторинга (Zabbix)¶

Мониторинг физических хостов, контроллеров облака, базы данных облака, гипервизоров, сети, СХД, LDAP, функциональных модулей облака, журнала событий должен выполняться средствами Zabbix. Zabbix должен запускаться в виде контейнера и содержать в себе PostgreSQL. В качестве средства отображения может использоваться webserver Zabbix или Grafana (если она уже используется как инструмент анализа журнала). В качестве СУБД Zabbix должна использоваться PostgreSQL из дистрибутива ОС, расположенная в отдельной папке. PostgreSQL должна работать в режиме TimeScale DB с включенным алгоритмом компрессии таблиц pglz. Zabbix должен поддерживать извлечение данных из syslog при отображении информации. Zabbix должен поддерживать выполнение скриптов комплексного тестирования и тестов Tempest. Результаты критических неисправностей должны направляться администраторам по почте и другим каналам.

Система резервного копирования (Bacula)¶

Резервное копирование конфигурации облака (узлов, контроллеров, БД, хостовых ОС, системы мониторинга, журналирования, обработки журналов) должен выполняться средствами Bacula. Bacula должна запускаться в виде контейнера и содержать в себе PostgreSQL. Результаты работы Bacula должны фиксироваться в журнале событий.

Система управления СХД (Ceph)¶

Ceph Dashboard предназначен для управления и мониторинга SDS Ceph. Панель управления Ceph Dashboard использует фреймворк CherryPy и реализует собственный REST API. Реализация WebUI основана на Angular/TypeScript. Ceph Dashboard поддерживает:

- RBAC, правила безопасности при подключении, LDAP, SSO, SSL/TLS
- кастомизацию языков
- настройку требуемых журналируемых событий
- отображение общего состояния кластера, производительности и емкости, пулов, репликаций, OSD, мониторов, хостовОсновные приложения установки OpenStack/AccentOS АрмАдм, не связаны с консолью управления облаком.

Основные приложения, связанные с обслуживанием системы запускаются из консоли управления Horizon/Skyline. Все приложения могут иметь собственные серверы и СУБД и предоставляют доступ по WEB интерфейсу.