Новая версия АРМ администратора

Общая информация

1.1. Назначение АРМ Администратора

АРМ Администратора (далее АА) предназначен для централизованного администрирования и контроля серверной инфраструктуры. Основные задачи АА:

Основные задачи АА:

Законченный цикл разворачивания и настройки
- Оборудования
- Операционной системы (ОС)
- Подсистемы виртуализации, хранения и сети
- Сервисной инфраструктуры
централизованный мониторинг серверов и сервисов;
контроль доступности и состояния инфраструктуры;
сбор и анализ системных и сервисных журналов;
централизованное резервное копирование серверов;
восстановление данных из резервных копий;
централизованная настройка и управление серверами;
предоставление администратору единой точки доступа к основным системам через веб- интерфейсы.

1.2. Реализуемые функции и продукты

Набор функций АА и используемые продукты приведены в таблице.

Функция АА	Продукт	Что выполняет
Установка необходимого ПО на АА	Набор скриптов и плей- буков Ansible
Установка ОС на вычислительные узлы	Cobbler IPMI RedFish
Настройка сетевого окружения	Скрипты АА
Установка Серч	Cephadm
Тестирование узлов	Тесты оборудования и сервисов Linux
Установка облака	Kolla Ansible FirstBoot
Тестирование облака	Self-diagnostics AccentOS Tempest
Мониторинг инфраструктуры	Zabbix	Сбор метрик с серверов, контроль состояния, обнаружение проблем, алерты администратору
Агентский мониторинг	Zabbix Agent / Agent 2	Передача данных с серверов на АА
Резервное копирование	Bacula	Создание резервных копий серверов
Хранение резервных копий	Bacula Storage / PostgreSQL	Хранение backup на выделенном хранилище Хранение информации о заданиях, файлах и носителях Bacula
Анализ/Визуализация/ отчеты логов и данных логов	OpenSearch Dashboards Grafana Rsyslog / syslog-ng	Централизованное хранение и поиск в журналах Просмотр и анализ данных OpenSearch Визуализация данных и создание дашбордов
Тестирование настроенного сетевого окружения	iCar	Проверка доступности сетевых портов и сервисов для всех узлов облака
Автоматизация администрирования	Ansible	Установка, настройка и изменение конфигурации серверов
Инвентаризация	NetBox + Zabbix	Инвентаризация оборудования и сетей
Миграция VMware хостов в AccentOS	Набор скриптов и приложений
Автоматизация ПМИ	Набор скриптов для тестирования функций AccentOS
Живучесть системы	Kolla Ansible Vitality	Автоматическое восстановление неисправных сервисов
Веб-администрирование Bacula	Webmin	Единая веб-точка доступа к административным сервисам
Интегрированная консоль управления через WEB- браузер	Vivaldi	Все приложения в единой консоли администратора
Средства удаленного доступа	Xrdp и VNC	Удаленное подключение к рабочему столу АА
Средства защищенного доступа	Open VPN	Удаленное подключение к АА
Средства аутентификации администраторов	FreeIPA	Идентификация, аутентификация, авторизация администраторов

1.3. Требования к АА (оборудование и ВМ)

Требования к оборудованию и ОС АА приведены в таблице.

В качестве ОС используется RedOS 8 Сертификат ФСТЭК (ввиду наличия в сертифицированном дистрибутиве большинства используемых пакетов) для последующей аттестации.

Параметры оборудования АА описаны в таблице

Параметр	Требование
ОС	RedOS 8.0
Размещение	ВМ (виртуальная машина), либо железо (ноутбук, пк)
CPU	8 ядер x86 CPU
RAM	16 - 32 гб
Сетевой адаптер	1 GbE, желательно второй 10 GbE при большом количестве миграций и бакап
Системный диск	SSD 960 -1920 Gb
Диск хранения	SSD / HDD 2 000 – 6 000 Gb в зависимости от нагрузки

1.4. Структура файлового хранения АА

Структура файлов и папок, размещаемая на диске хранения АА описана в таблице.

Раздел	Назначение
Репозиторий используемой ОС	Пакеты ОС Пакеты виртуализации Python Пакеты сетевых сервисов(OvS/OvN), HA Proxy, NGinx СУБД, кластеризация СУБД, сервисы кеширования, брокеры очереди сообщений Инфраструктурные сервисы из раздела функции и продукты
Репозиторий OpenStack и AccentOS	Пакеты модулей облачной платформы
ВМ или репозиторий для Kolla Ansible	Файлы, собранные под целевую AccentOC
Репозиторий Серh	Пакеты Серh, собранные под целевую ОС
Пакеты для тестирования	Self-diagnostics Tempest iCar
Пакеты для миграции ВМ	Пакеты Серh собранные под целевую ОС
Плейбуки и скрипты для установки
Тестовые ВМ и продукты	Тестовая ВМ целевой ОС Linux, Windows
СУБД Zabbix и Bacula	Возможно, лучше использовать SSD
Хранилище для syslog /opensearch/ grafana	Возможно, лучше использовать SSD
Хранилище для миграции ВМ	Возможно, лучше использовать SSD
Хранилище для бакап	Хранилище NFS / Glance для тестов

2.Установка АА

2.1. Установка АА на физическом оборудовании

Инструкция по установке ОС REDOS:

Необходимо загрузить на USB-накопитель образ REDOS и подключить к устройству
При запуске нас встречает меню boot, выбираем “Проверить установочный носитель и установить РЕД ОС”, нажимает enter

Выбираем язык (обычно предустановлен и добавлять не требуется), нажимает “Готово”
Обзор установки, 4 пункта подсвечены, их надо будет задать

Место установки, переходим, выбираем интересующий нас диск и нажимаем “Готово”
Учетная запись root, мы ее включаем и задаем пароль, после чего, 2 раза нажимаем “Готово” (опционально можно выдать возможность подключения по ssh с пользователем root)
Создание пользователя, создаем пользователя, заполняя все поля и нажимаем 2 раза “Готово”
Для установки лицензии, заходим и ставим галочку “Принимаю лицензионное соглашение”, нажимаем “Готово”
Выбор программ, надо добавить только “Клиент виртуализации”, остальное уже предустановлено и не трогаем
По завершению установки необходимо будет отправить систему в перезагрузку, нажать кнопку “Перезагрузка системы”
Переходим к “Конфигурирование ОС АА”

2.2. Установка АА на ВМ

Инструкция по установке ОС REDOS:

Необходимо загрузить на облако, либо загрузить BM из образа REDOS 8.0, либо с заранее подготовленного образа qcow2(в этом случае, последующую инструкцию можно пропустить до “Конфигурирование ОС АА”)
При запуске нас встречает меню Boot, выбираем “Проверить установочный носитель и установить РЕД ОС”, нажимает enter

Выбираем язык (обычно предустановлен и добавлять не требуется), нажимает “Готово”
Обзор установки, 4 пункта подсвечены, их надо будет задать

Место установки, переходим, выбираем интересующий нас диск и нажимаем “Готово”
Учетная запись root, мы ее включаем и задаем пароль, после чего, 2 раза нажимаем “Готово” (опционально можно выдать возможность подключения по ssh с пользователем root)
Создание пользователя, создаем пользователя, заполняя все поля и нажимаем 2 раза “Готово”
О лицензии, заходим и ставим галочку “Принимаю лицензионное соглашение”, нажимаем “Готово”
Выбор программ, надо добавить только “Клиент виртуализации”, остальное уже предустановлено и не трогаем
По завершению установки необходимо будет отправить систему в перезагрузку, нажать кнопку “Перезагрузка системы”
Переходим к “Конфигурирование ОС АА”

2.3. Конфигурирование ОС АА

Настройка сети:

Через консоль, последовательно введя:

sudo -i
nmtui

Либо же через графику: Выбираем вращающийся значок в трее Нажимаем “Параметры соединений”, далее выбираем интересующий нас интерфейс (скорее всего единственный) и нажимаем шестеренку (внизу) В открывшемся окне переходим во вкладку “Параметры IPv4” и заполняем всю информацию о конфигурации сети АА, можно сделать по аналогии с картинкой (если поле “Адреса” пустое, нажимаем кнопку “Добавить”):

После чего, нажимаем сохранить и проверяем доступность машины через ping или ssh.

3.Установка облака

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

https://www.intel.com/content/dam/www/public/us/en/documents/reference-architectures/redhat- cloud-blocks-reference-architecture.pdf .

3.1. Раскатка хостовых ОС и узлов Ceph

Раскатка хостовых ОС и узлов Ceph — установка и первичная настройка операционных систем на физических серверах, предназначенных для работы в качестве вычислительных хостов и узлов Ceph. Включает подготовку дисков, сетевых интерфейсов и базовых системных параметров. Она может быть выполнена 4 способами:

Ручная установка операционной системы с CD ROM / USB на сервер с использованием локально или с помощью консоли KVM и заранее подготовленного ISO-образа. В процессе выполняется выбор параметров установки, разметка диска и базовая настройка ОС в локальном режиме.
Ручная/автоматизированная установка операционной системы на сервер через интерфейс управления ВМС с использованием протокола Redfish. Позволяет управлять питанием, подключать ISO-образ и выполнять установку ОС в удаленном режиме.
Автоматизированная установка операционной системы на серверы по сети с использованием PXE и сервера Cobbler. Cobbler предоставляет загрузочный профиль и необходимые файлы установки, после чего ОС разворачивается с заданными параметрами.

3.1.1. Раскатка ОС через KVM. ISO образ

Ручная установка операционной системы с CD ROM / USB на сервер локально или с с помощью консоли KVM и заранее подготовленного ISO-образа. Практически полностью совпадают. Единственное отличие для KVM – предварительная настройка ВМС и организация удаленного подключения.

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

Общее замечание – для установки 5 – 8 хостов в одной локации локальная установка с CD ROM / USB самая предсказуемая по времени.

3.1.2. Раскатка ОС через RedFish

Установка ОС с помощью Redfish заключается в установке ОС через WEB сервер, работающий в ВМС котроллере по протоколу https. Преимуществом данного метода является отсутствие требований к специальным портам ввода-вывода, клиентскому ПО и возможность удобного выполнения операций одновременно для многих хостов что удобно в ЦОД.

Протокол является зрелым и присутствует в ВМС ведущих вендоров серверов.

Недостатком протокола является

Сложная настройка дополнительной инфраструктуры, сертификатов, множества действий с ВМС
Отсутствие гарантии повторяемости из-за собственной реализации протокола вендорами что создает риски несовместимости.

В настоящее время установка ОС через RedFish и ISO образ реализуется в ручном режиме. Предусмотрена реализация функционала раскатки в автоматизированном режиме в случае специального заказа для однотипного оборудования.

Порядок раскатки ОС описан в разделе 6.12.1

3.1.3. Раскатка ОС через Cobbler

Установка ОС с помощью Cobler заключается в установке ОС через РХЕ сервер, работающий на одном из сетевых адаптеров и РХЕ сервере. Преимуществом данного метода является удобный вид загрузки и развертывания.

Недостатком является проблема наличия сети РХЕ, настроек коммутаторов, отсутствие LACP, ограничения ОС Linux со старым загрузчиком на работу в гетированных VLANS.

Протокол является зрелым и присутствует в BIOS вендоров серверов и сетевых карт.

3.2. Подготовка и тестирование хостов облака

Перед использованием хостов с установленными ОС Администратор проводит конфигурирование, обновление, настройку, BIOS и компонентов серверов.

Далее с помощью плейбуков осуществляется копирование утилит на хосты.

Далее Администратор запускает скрипт последовательного выполнения тестов сервера, проводит проверку соответствия заявленных характеристик, параметров компонентов, проводит стресс-тестирование хостовых ОС и узлов Серh.

После проведения тестов скрипт сообщает Администратору о полученных результатах и ошибках (grep).

3.2.1. Обновление и настройка BIOS сервера, адаптеров, микропрограмм HDD/SSD

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

Настройка считается выполненной, когда версии прошивок сетевых адаптеров, дисковых адаптеров и SSD одинаковы на всех серверах установки, а их версии соответствуют актуальным рекомендациям производителя.

3.2.2. Тестирование RAM

Для исключения ошибок RAM установки Администратор должен провести тест памяти с помощью утилиты memtest86+ на каждом сервере. Минимальная продолжительность теста - 2 часа.

Утилита изначально находится на АА и копируется в локальную папку на время проведения тестов.

Команды для проведения теста приведены в разделе 6.8.8.

Проверка считается успешно пройденной в случае, если в результате утилита не сообщила об ошибках RAM.

3.2.3. Тестирование CPU

Для исключения сбоев CPU установки Администратор должен провести нагрузочный тест с помощью утилиты stress-ng на каждом сервере с полной загрузкой всех ядер. Минимальная продолжительность теста - 2 часа. В ходе теста контролируется температура процессоров с помощью утилиты sensors

Команды для проведения теста приведены в разделе 6.8.8.

Проверка считается успешно выполненной, если результате утилита не сообщила о потере производительности и перегреве CPU.

3.2.4. Тестирование сети (физические сети, интерфейсы, VLANs, адреса, порты)

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

Проверка пропускной способности выполняется с помощью утилиты iperf3.

Команды для проведения теста приведены в разделе 6.8.8.

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

Проверка считается успешно пройденной в случае, если пропускная способность соответствует номинальной, а потери пакетов отсутствуют.

3.2.5. Тестирование SSD/HDD и установка резервного размера областей SSD

Для подтверждения корректной работы дисков и исключения проблем при эксплуатации Администратор должен проверить параметры каждого накопителя с помощью утилиты smartctl на отсутствие битых блоков, а также нагрузочный тест случайной записи блоком 4К с помощью утилиты fio.

Команды для проведения теста приведены в разделе 6.8.8.

Проверка считается успешно пройденной в случае, если smartctl показывает статус PASSED, битые блоки отсутствуют, резервная область установлена, а время задержки на случайном тесте записи fio не превышает 0,5 мс.

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

3.3. Проверка сетевого взаимодействия хостовых ОС, узлов Серh.

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

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

Она включает в себя как минимум:

Сеть установки, настройки и управления облаком
Сеть хранения (iSCSI или SDS)
Вспомогательную сеть синхронизации данных (для Серчь)
Сеть виртуальных машин
Сеть для подключения к WAN/Internet

Тестирование делает следующие проверки:

Проверка DHCP-серверов
Проверка DNS-серверов
Проверка NTP-серверов
Проверка MTU в определенной сети
Проверка LDAP-серверов
Проверка доступности СХД-консолей

Выполнение теста производится Администратором с помощью скриптов с АА

Порядок запуска описан в разделе 6.12.1

3.4. Установка Серчь

Развёртывание кластера Серчь начинается с подготовки первого узла, который становится начальным монитором. После инициализации кластера остальные узлы добавляются поочерёдно, на них разворачиваются необходимые сервисы (MON, OSD, MDS), после чего запускается веб-консоль управления Серчь Manager Dashboard для мониторинга и администрирования кластера.

Детали установки описаны в разделе 6.2.

Описание Серчь приведено на сайте вендора.

https://docs.ceph.com/en/latest/releases/tentacle/

3.5. Настройка устройств хранения

Подключение к облачной платформе блочных устройств по SAN сетям с протоколами iSCSI, FCoE, FC, NVME-oF-TCP или по фирменным протоколам вендоров необходимо выполнять с использованием их рекомендаций.

Подключение к облачной платформе блочных устройств по протоколу RBD и NVME-oF-TCP необходимо выполнять с использованием рекомендаций Серчь.

Подключение к облачной платформе сетевых разделяемых папок по Ethernet сетям с протоколами NFS, SMB или по фирменным протоколам вендоров необходимо выполнять с использованием рекомендаций разработчиков ОС.

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

3.6. Начальная раскатка плейбуков для сервисной инфраструктуры

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

## Установка подробно описана в разделе 6.1.2.1.

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

3.7. Раскатка облака с помощью Kolla Ansible (включая Rabbit)

Для установки модулей облака AccentOS, OpenStack администратор должен запустить ПО Kolla Ansible.

В установку наряду с модулями AccentOS bOpenStack входят:

СУБД облака,
OVS/OVN,
HA Proxy,
Memcached.
Galera, а также пакеты зависимостей

Установка подробно описана в разделах 6.3, 6.4 (Kolla-Ansible). В результате установки Kolla Ansible проведет установку на хостах облака и запустит службы Keystone, Nova, Neutron, Glance, Cinder, Horizon и модули AccentOS в виде контейнеров

Установка считается успешной если в результате установке система не сообщила в консоли об ошибках.

3.8. Завершение раскатки плейбуков сервисной инфраструктуры

На завершающей стадии установки система должна провести установку сервисов инфраструктуры на АА, перечисленных в разделе 1.2. На хостовых ОС устанавливаются агенты для этих сервисов и конфигурируются.

Администратор должен установить параметры и IP адрес в файле конфигурации, что подробно описано в разделе 6.1.2.2 и пройти установку согласно инструкции.

Установка считается успешной если в результате установке система не сообщила в консоли об ошибках.

3.9. Графическая интегрированная консоль АА

Для запуска сервисных приложений Администратор выполняет пункты 9 и 10 скрипта start.sh из предыдущего раздела 3.10

Повторно запускает скрипт start.sh, выполняем п.6 и п.8 (п.8 выполнять после обнаружения в дашборде Zabbix служб OpenStack P.S. скрин приложен)

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

Zabbi

http://IP_VM/zabbix

логин/пароль : Admin/zabbix

WebMin (Bacula)

https://IP_VM:10000

логин/пароль : как у вм/ноута

Opensearch

http://IP_VM:5601

логин/пароль : admin/Opense@rch123456

Grafana

http://IP_VM:3000

логин/пароль : admin/admin

Таюке администратору необходимо настроить WebMin для работы с бакулой:

В левой панели раскрывает System и нажимает на Bacula Backup System

В открывшемся окне нажимаем на шестеренку:

•Выбирает Bacula database settings:

•Указывает пароль bacula и нажимаем save:

Далее идет опциональная установка пунктов: 7, 9 и 10 (можно не устанавливать)

Графическая интегрированная консоль АА использует WEB консоли управления установленных выше и дополнительных продуктов:

AccentOS Dashboard/ OpenStack Horizon
Ceph Dashboard
Zabbix
Grafana
OpenSearch
Bacula / WebMin
NetBox
Vitality

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

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

Особенности настройки, требования к ресурсам, методика проверки работоспособности, описание эксплуатации приведены в разделе 6

4. Проверка системы перед запуском

4.1. Тестирование системы через API

Проверка функционала модулей через API AccentOS и OpenStack проводится с помощью утилиты Tempest.

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

Проверка считается успешно пройденной в случае отсутствия ошибок тестирования.

4.2. Тестирование системы через GUI

Для проверки работоспособности AccentOS Dashboard и OpenStack Horizon Администратор должен проверить работоспособность базовых функций, которые задействуют и проверяют работу модулей облака.

К этим модулям относятся:

Horizon
Nova
Neutron
Cinder
Glance
CloudManager и др

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

Данные проверки подробно описаны в п. 6.14.

Тест считается успешно пройденным если все проверки прошли без ошибок.

4.3. Резервное копирование развернутой системы

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

Проверка считается успешно пройденной в случае, если отображаемая информация аналогична информации из п.6.5.4.

4.4. Организация терминального доступа к АА

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

Администратор выполняет установку ОС АА, согласно п.2 (если в п.2 выбрана возможность подключения с пользователем root, то можно использовать данного пользователя для подключения)
Администратор выполняет установку необходимых компонентов и настройку сети согласно п.3.8
Администратор может проверить возможность подключения к АА по ссш: ssh AA_NAME@IP_AA AA_NAME - имя пользователя (может быть root, если ранее была выдана такая возможность) IP_AA - IP адресс АА Проверка считается успешно пройденной в случае, если администратор смог подключиться по ssh к АА.

5. ПМИ

Система проведения автоматизированного ПМИ предполагает проведение расширенных по сравнению с Tempest комплексных проверок для ускорения процедуры ПМИ при сдаче приемке системы, в случае восстановления системы после аварии, в случае расширения облачной платформы и в случае перенастройки сетей облачной платформы.

6. Использование модулей

6.1. АРМ Администратора

6.1.1. Общая информация

6.1.2. Плейбуки

6.1.2.1 Предварительная конфигурация АА:

Важно

Предварительная настройка АРМ-админа включает в себя редактирование visudo для sudo -i, настраивает сеть, скачивает миррор и устанавливает пакеты. В данном файле нас интересует только блок “Глобальные переменные”, их надо исправить согласно сети, ниже описание каждой переменной:

# Пользователь, которому будет выдан sudo без пароля
SUDO_USER="u"
# Что именно разрешить через sudo
# ALL = любые команды
NOPASSWD="ALL"
# Имя сетевого интерфейса
# пробел = автоопределение через nmcli
INTERFACE="
# Использовать DHCP
# yes = DHCP
# no = статический IP
USE_DHCP="no"
# Статический IP адрес сервера
STATIC_IP="10.40.17.31"
# Шлюз по умолчанию
GATEWAY="10.40.17.254"
# DNS сервера
# Указывать через запятую БЕЗ пробелов
DNS="10.40.116.1.10.40.116.2.8.8.8.8.1.1.1.1"
# Полный URL архива mirror
# Если заполнен — используется wget
# Если пусто — используется SCP
FULL_URL="ЕСЛИ_ЗАГРУЗКА_C_GIT_РЕПОЗИТОРИЯ_ВСТАВИТЬ_ССЫЛКУ"
# IP сервера где лежит mirror архив
SERVER_IP="10.40.16.6"
# Путь до mirror архива на удалённом сервере
REMOTE_PATH="/home/u/mirror-redos-base.tar.gz"
# Пользователь для SCP подключения
LOGIN="u"
# Пароль для SCP подключения  PASSWORD="12345678"  # Начальный пароль OpenSearch admin  # Используется при первой установке OpenSearch  OPENSEARCH_INITIAL_ADMIN_PASSWORD="Opense@rch123456"

После предварительного редактирования переменных, необходимо запустить установку, для этого нужно: 1. sudo -i 2. перейти в папку arm 3. запустить сам скрипт: sh 0-installer.sh

6.1.2.2 Завершение раскатки плейбуков сервисной инфраструктуры

Важно

Для заключительной раскатки служб необходимо предварительно отредактировать в папке arm/inventory.yml:

После редактирования inventory.yml, можно начать установку последовательно:

sudo -i
sh start.sh
Вводим на клавиатуре 1 и нажимаем Enter, после чего, пойдет установка (ВЫПОЛНЯТЬ ПОСЛЕ УСТАНОВКИ Kolla Ansible)

6.1.3. Консоли управления сервисами инфраструктуры

6.1.4. Резервное копирование и восстановление

Не предусмотрено.

6.1.5. Обслуживание ОС АА

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

6.1.6. Документация по терминальному протоколу

6.1.7. Документация по VPN

6.1.8. Документация по эксплуатации ОС

6.1.9. Полная документация по РЕД ОС: https://redos.red-soft.ru/base/redos-8_0/

6.2. Установка ОС узлов облачной платформы с помощью Redfish и ISO

Требования к инфраструктуре:

• Baseboard management controller целевого сервер должен поддерживать redfish (обычно включен по умолчанию). Известен пароль в ВМС. Сеть на ВМС настроена, с admin box доступны TCP 22, 443. Не помешает ICMP для диагностики.
• Сервис публикации образов по https, например ВМ с nginx. Соответственно, с ВМС на нем доступен TCP 443. Должно быть достаточно места для размещения установочных образов
• Admin box с клиентом ssh и утилитами curl, jq. Желательно иметь на admin box графику и браузер для контроля процесса установки и настройки сервера через KVM.
• Утилиты для выпуска сертификатов (могут располагаться на admin box, как и nginx с образами)
• Время между узлами должно быть синхронизировано (используйте NTP или хотя бы назначьте через ВМС на глаз)

Подготовка nginx

Redfish не будет монтировать образ по http или с сервера с самоподписанным сертификатом, поэтому сразу нужно делать сервер с настроенным SSL, например, создав с CA помощью openssl:

Выпуск сертификата для CA :

Генерация файла конфигурации сертификата:

Генерация ключа для сервера::

sudo openssl genrsa -out /root/provision-ca/provision-server.key 3072

Генерация запроса::

sudo openssl req -new -key /root/provision-ca/provision-server.key -out /root/provision-ca/provision-server.csr -config /root/provision-ca/provision-server.cnf

Генерация файла конфигурации для расширений::

~/provision-ca/provision-server-ext.cnf basicConstraints = critical,CA:FALSE keyUsage = critical,digitalSignature,keyEncipherment extendedKeyUsage = serverAuth subjectAltName = DNS:provision,DNS:provision.tos-mgmt.loc,IP:10.224.104.200

Выпуск сертификата::

sudo openssl x509 -req -sha256 -days 825 -in /root/provision-ca/provision-server.csr -CA /root/provision-ca/provision-root-ca.crt -CAkey /root/provision-ca/provision-root-ca.key -CAcreateserial -out /root/provision-ca/provision-server.crt -extfile /root/provision-ca/provision-server-ext.cnf

Установка, настройка nginx и публикация папки::

sudo apt install -y nginx sudo mkdir -p /srv/provision/images sudo mkdir -p /srv/provision/preseed

sudo install -m 644 /root/provision-ca/provision-server.crt /etc/ssl/certs/provision-server.crt

sudo install -m 600 /root/provision-ca/provision-server.key /etc/ssl/private/provision-server.key

Добавление сайта /etc/nginx/sites-available/provision::

server {

listen 443 ssl; server_name provision;

ssl_certificate /etc/ssl/certs/provision-server.crt; ssl_certificate_key /etc/ssl/private/provision-server.key; root /srv/provision; location / {

autoindex on;

}

sudo rm -f /etc/nginx/sites-enabled/default sudo ln -s /etc/nginx/sites-available/provision

/etc/nginx/sites-enabled/provision

sudo nginx -t sudo systemctl restart nginx

2. Копирование сертикатов CA на bmc BMC по умолчанию не доверяет стороннему CA. Необходимо скопировать сертификат в bmc по ssh в файл по умолчанию с глобальными CA:

sshpass -p$BmcPass scp -O -o StrictHostKeyChecking=accept-new -o
HostKeyAlgorithms=+ssh-rsa ~/provision-ca/provision-root-ca.crt  root@$Bmc:/tmp/

Через окружение shell BMC интерактивно дать команды::

sshpass -p$BmcPass ssh -o HostKeyAlgorithms=+ssh-rsa root@$Bmc

Сохранить оригинальный файл с сертификатами::: cp /etc/ssl/certs/ca-certificates.crt /tmp/ca-certificates.crt.orig

Объединить оригинальный файл с сертификатами с выпущенным сертификатом CA::

cat /etc/ssl/certs/ca-certificates.crt /tmp/provision-root-ca.crt > /tmp/ca-certificates.crt.new

Заменить оригинальный сертификат на объединенный::

cp /tmp/ca-certificates.crt.new /etc/ssl/certs/ca-certificates.crt

Смонтировать образ, назначить порядок загрузки и перезагрузки через redfish

Пример файла переменных::: ==> 04redfish_env <== BmcUser=root Bmc='10.224.96.84' System="/redfish/v1/Systems/system" echo "$System=$System" Vm="/redfish/v1/Managers/bmc/VirtualMedia/USB1" echo "$Vm=$Vm" #read -p "Enter BMC password: " BmcPass BmcPass=OpenBmc

Перезагрузить BIOS:::

==> JSON/boot-bios.json <== {

"Boot": {
"BootSourceOverrideEnabled": "Once", "BootSourceOverrideTarget": "BiosSetup" }

}

Загрузиться с USB:::

==> JSON/boot-usb.json <== {

"Boot": {
"BootSourceOverrideEnabled": "Once", "BootSourceOverrideTarget": "Usb" }

}

Выполнить команду на одну загрузку::

curl -ksu "${BmcUser}:${BmcPass}" -X PATCH -H 'Content-Type: application/json' --data- binary @JSON/boot-usb.json "https://${Bmc}${System}"

Посмотреть текущие параметры загрузки::

curl -ksu "${BmcUser}:${BmcPass}" "https://${Bmc}${System}" | jq '.Boot'

Примеры монтирования разных файлов образов или oemdrv для anaconda::

==> JSON/insert-astra184di.json <== {

"Image": "https://10.224.104.200/images/installation-1.8.4.48-30.10.25_09.18-di.iso", "Inserted": true, "WriteProtected": true }

==> JSON/insert-ipxe-min.json <== {

"Image": "https://10.224.104.200/images/ipxe.iso"

}

==> JSON/insert-ipxe.json <== {

"Image": "https://10.224.104.200/images/ipxe.iso", "Inserted": true,

"WriteProtected": true

}

==> JSON/insert-oemdrv.json <== {

"Image": "https://10.224.104.200/images/cami-ceph-03-oemdrv.img", "Inserted": true, "WriteProtected": true

}

==> JSON/insert-redos.json <== {

"Image": "https://10.224.104.200/images/redos-8-20250711.7-Everything-x86_64-DVD1.iso", "Inserted": true, "WriteProtected": true

}

Выполнить монтирование::

curl -ksu "${BmcUser}:${BmcPass}" -H 'Content-Type: application/json' -X POST --data-binary @JSON/insert-astra184di.json "https://${Bmc}${Vm}/Actions/VirtualMedia.InsertMedia"

Посмотреть список доступных для монтирования устройств virtual media::

curl -ksu "${BmcUser}:${BmcPass}" "https://${Bmc}/redfish/v1/Managers/bmc/VirtualMedia/USB0" | jq

Метод InsertMedia должен присутствовать (могут быть устройства, которые предназначены только для монтирования через websocket, для них монтирование делается иначе):

Для проверки параметров можно использовать ssh и проверять через busctl или ps::: ps ww | grep -Ei '[n]bdkit|[n]bd-client|[v]irtual.?media'
Пример процессов смонтированного образа в BMC:::: 305 root 6192 S /usr/sbin/virtual-media 2591 root 134m S /usr/sbin/nbdkit --unix /tmp/nbd2.sock --run /usr/sbin/nbd-client -t 30 -u /tmp/nbd2.sock /dev/nbd2 -n --readonly curl url=https://10.224.104.200/images/installation-1.8.4.48-30.10.25_09.18-di.iso sslverify=true 2592 root 145m S /usr/sbin/nbdkit --unix /tmp/nbd2.sock --run /usr/sbin/nbd-client -t 30 -u /tmp/nbd2.sock /dev/nbd2 -n --readonly curl url=https://10.224.104.200/images/installation-1.8.4.48-30.10.25_09.18-di.iso sslverify=true 2593 root 1604 S /usr/sbin/nbd-client -t 30 -u /tmp/nbd2.sock /dev/nbd2 –n

6.2.1.Тестирование оборудования физических узлов облака

Тестирование RAM Для проверки RAM администратор выполняет действия

Установка утилиты:: sudo dnf install -y memtest86+

Добавление memtest86+ в загрузочное меню GRUB:: sudo memtest-setup sudo grub2-mkconfig -o /boot/grub2/grub.cfg

Перезагрузка сервера и выбор пункта memtest86+ в меню GRUB:: sudo reboot

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

Тестирование CPU

Установка утилиты:: sudo dnf install -y stress-ng lm_sensors
Запуск нагрузочного теста на все ядра на 2 часа:: stress-ng --cpu $(nproc) --cpu-method all --metrics --timeout 2h
В отдельном терминале - мониторинг температуры CPU:: watch -n 5 sensors

В результате теста утилита не должна сообщить об ошибках вычислений, а температура CPU не должна превышать допустимых значений.

Тестирование сети (физические сети, интерфейсы, VLANs, адреса, порты)

Установка утилиты sudo dnf install -y iperf3
На принимающем узле запустить сервер iperf3 -s
На отправляющем узле запустить тест пропускной способности iperf3 -c <IP-принимающего-узла> -t 60
Проверка потерь пакетов ping -c 1000 <IP-целевого-узла>

В результате теста скорость должна соответствовать номинальной для используемых сетевых интерфейсов. В выводе ping значение packet loss должно быть 0%.

Установка и тестирование SSD и установка резервного размера областей

Установка утилиты sudo dnf install -y smartmontools fio
Проверка SMART-параметров диска sudo smartctl -a /dev/sdX
Проверка конкретных параметров на битые блоки sudo smartctl -A /dev/sdX | grep -i "Reallocated_Sector|Current_Pending"
Нагрузочный тест случайной записи 4K (5 минут) sudo fio --name=randwrite --ioengine=libaio --rw=randwrite --bs=4k --numjobs=16 --size=1G -- runtime=300 --time_based --direct=1 --iodepth=64 —filename=/dev/sdX

В результате теста smartctl должен показать статус PASSED, значения Reallocated_Sector_Ct и Current_Pending_Sector должны быть равны 0, а средняя задержка (avg latency) в выводе fio не должна превышать 0,5 мс.

6.2.1. Консоль управления

6.2.2. Резервное копирование и восстановление

6.2.3. Документация по эксплуатации

6.3. Kolla Ansible

6.3.1. Общая информация

6.3.2. Требуемые ресурсы

6.3.3. Установка

6.3.4. Тестирование работоспособности

6.3.5. Консоль управления

6.3.6. Резервное копирование и восстановление

6.3.7. Документация по эксплуатации

6.4. Система мониторинга Zabbix

6.4.1. Общая информация

Zabbix — это программное обеспечение для мониторинга параметров сети, жизнеспособности и целостности серверов, виртуальных машин, приложений, сервисов, баз данных, веб-сайтов, облачных сред и многого другого. Zabbix использует гибкий механизм оповещений, что позволяет пользователям настраивать уведомления практически на любое событие. Zabbix предлагает отличные функции отчётности и визуализации данных, основанные на данных истории. В АА используется Zabbix версии 7.0 для операционной системы RedOS 8. Для хранения исторических данных используется база данных PostgreSQL 14.

6.4.2. Требуемые ресурсы

Для работы Zabbix-сервера требуется минимум 2 ядра, 8 Гб ОЗУ, и ориентировочно не менее 30 Гб для установки РедОС 8 с Zabbix-сервером. Ресурсы, требуемые Zabbix-серверу зависят от объема собираемой информации. Размер требуемых ресурсов зависит от количества источников и длительности хранения. В Zabbix можно регулировать период хранения данных. Для гибкости Zabbix поддерживаниет два типа данных:

• История (History): Хранит каждое полученное значение метрики. По умолчанию задается равной 7 дням. Минимальный срок — 1 час, максимальный — 25 лет.

• Тренды / Динамика изменений (Trends): Хранит сгруппированные часовые агрегированные данные (минимальное, максимальное, среднее и количество за час). Используется для построения графиков за длительные периоды. По умолчанию хранится 365 дней. Максимальный срок — 25 лет.

У любого из этих типов данных можно изменить период хранения. Для ориентировочной оценки требуемых ресурсов можно пользоваться официальной документацией Zabbix: https://www.zabbix.com/documentation/7.0/ru/manual/installation/requirements

6.4.3. Установка

Установка пакетов Zabbix-сервера и базы данных PostgreSQL 14 выполняется автоматизированно по п.3.8 «Начальная настройка и установка необходимых пакетов для сервисной инфраструктуры». Далее по п.3.10 «Завершение раскатки плейбуков сервисной инфраструктуры» автоматизированно с помощью скрипта запуска ansible-плейбуков выполняются: - Завершающая настройка и формирование конфигурации Zabbix-сервера и базы данных PostgreSQL 14; - Установка агента zabbix-agent 2 на compute-нодах; - Импортирование шаблонов; - Создание виртуальных узлов сети в Zabbix; - Создание пользователя мониторинга в облаке Openstack, настройка его прав, создание для него учетных данных приложений (application credential). Настройка виртуального узла Cloud-API для мониторинга облака через API Openstack. - Установка скриптов check_hypervisor_load.py и zabbix_iotop.py на compute-нодах, настройка периодичности их работы; - Установка пакета chromedriver на AA для веб-мониторинга; - Импортирование в Zabbix панели (дашборда) «Cloud». Выполняется после завершения остальных этапов настройки, когда пользователь убедится, что данные из API Openstack загружены в Zabbix — см. п. 3.11 «Графическая интегрированная консоль AA»

6.4.4. Тестирование работоспособности

После завершающей настройки администратор открывает в браузере веб- интерфейс Zabbix по адресу http://<IP-адрес_AA>/zabbix и выполняет вход по своим учетным данным, которые были созданы при установке Zabbix. Проверка работоспособности считается успешной, если:

- В любом из окон веб-интерфейса нет сообщений об ошибках.

- В меню «Сбор данных — Узлы сети» находятся все требуемые виртуальные узлы сети.

- В узлах сети служб Openstack, и других виртуальных узлах сети zabbix-сервером автоматически обнаружены элементы данных — более 2-х. - см. п. 3.11 «Графическая интегрированная консоль AA».

- К виртуальным узлам сети compute-нод прикреплены шаблоны «Docker by Zabbix agent 2», «Linux by Zabbix agent active», «Linux process IO iotop».

Пример окна меню «Сбор данных — Узлы сети»:

В окно «Мониторинг — Последние данные» у любого узла есть значения в колонке «Последнее значение», в колонке «Последняя проверка» время последней проверки отображается черным цветом, а в колонке «Инфо» нет сообщений об ошибке.

Пример окна «Мониторинг — Последние данные»:

6.4.5. Оповещения

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

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

- Email
- SMS
- Пользовательские скрипты
- Вебхук

Способы оповещений хранятся в меню «Оповещения → Способы оповещений» («Alerts → Media types»).

Пример окна меню «Оповещения → Способы оповещений»:

Подробнее о настройке оповещений Вы можете узнать из документации Zabbix: https://www.zabbix.com/documentation/7.0/ru/manual/config/notifications

6.4.6. Консоль управления

Для управления Zabbix-сервером администратор использует веб-интерфейс по адресу http://<IP-адрес_AA>/zabbix.

6.4.7. Резервное копирование и восстановление

Резервное копирование и восстановление реализуется с помощью программного обеспечения Bacula, установленного на AA.

6.4.8. Документация по эксплуатации

Документация по эксплуатации Zabbix доступна по веб-адресу: https://www.zabbix.com/documentation/7.0/ru/manual

6.5. Система резервного копирования Bacula

6.5.1. Общая информация

Bacula — это клиент-серверная система резервного копирования, предназначенная для автоматического создания, хранения, проверки и восстановления резервных копий данных с серверов и рабочих станций. Она состоит из:

- Director (Bacula-Dir) - управляет заданиями резервного копирования, расписанием, клиентами, наборами файлов и правилами хранения
- Storage Daemon (Bacula-Sd) - принимает данные от клиентов и записывает их на дисковое хранилище. При восстановлении, наоборот, читает данные из хранилища и передает их клиенту.
- File Daemon / Client (Bacula-Fd) - устанавливается на каждый сервер, с которого необходимо делать резервные копии. Он собирает указанные файлы и передает их Storage Daemon.
- Catalog (PostgreSQL) - хранит метаданные о клиентах, заданиях, файлах, томах и выполненных резервных копиях. Благодаря каталогу Bacula может определить, где находятся нужные данные, и использовать их для восстановления.
- Webmin - это основной компонент, который предоставляет веб- интерфейс и обрабатывает действия администратора.

6.5.2. Требуемые ресурсы

6.5.3. Установка

Установка модуля Bacula производится автоматически (плейбуками) в модуле 3.10.

6.5.4. Тестирование работоспособности

Для проверки корректности установки и работы модуля Bacula, необходимо:

Администратор переходит в WEB-интерфейс:
```
Webmin,
https://IP_AA:10000
IP_AA - IP адрес AA
```
Авторизуется

Важно

(используется логин/пароль, который был задан в процессе раскатки АА)

Администратор переходит в панель Bacula Backup System:

Администратор проверяет статус выполнения заданий, а имеено должны появиться 3 выполненный incremental бэкапа и появиться задачи, которые будут выполняться по расписанию.

6.5.5. Консоль управления

6.5.6. Мониторинг

6.5.7. Резервное копирование и восстановление

Не предусмотрено.

6.5.8. Документация по эксплуатации

Полная документация по модулю Webmin: https://webmin.com/docs/ Полная документация по Bacula: https://www.bacula.org/13.0.x-manuals/en/main/index.html

6.6. Система журналирования Syslog/OpenSearch/Grafana

6.6.1. Общая информация - кратко о сервисах

6.6.2. Требуемые ресурсы - тут думаю понятно

6.6.3. Установка - тип установка выполняется плейбуком из такого-то пункта

6.6.4. Тестирование работоспособности - как проверить, что работает

6.6.5. Консоль управления

Консоль управления отображает следующие группы ресурсов::: Services Star/Stop VM Control VM Drift Report Действия пользователей Подключения Подключения к консоли BM (Horizon) Подключения пользователей События Keystone События Keystone (DELETE)

6.6.6. Дополнительные настройки – CADF

Для настройки журналирования (аудита) API-запросов к модулям OpenStack (например, Nova) в стандартизированном формате CADF используется встроенный в библиотеку keystonemiddleware фильтр audit. В настоящее время такая цепочка на Арм Администратора не востребована, но может быть включена, т.к. требует только переконфигурирования существующих компонентов АА. Процесс настройки состоит из трех основных шагов: интеграция фильтра в конвейер WSGI (через Paste Deploy), привязка карты API и настройка вывода событий (в лог-файл или очередь сообщений). https://docs.openstack.org/keystonemiddleware/pike/audit.html Настройка конвейера в api-paste.ini Создание карты маппинга nova_api_audit_map.conf. Фильтру необходимо понимать, какие HTTP-методы и URL-пути соответствуют конкретным действиям CADF. Установите способ вывода CADF-событий в nova.conf (По умолчанию фильтр audit использует библиотеку oslo.messaging для отправки уведомлений но можно направить напрямую в файл лога nova-api, либо брокеру сообщений RabbitMQ). Перезапуск службы nova-api после сохранения всех конфигурационных файлов, чтобы изменения вступили в силу. Чтобы данные поступили в OpenSearch и далее в Grafana необходимо настроить получение событий из RabbitMQ в OpenSearch с помощью Fluentbit или Logstash и далее передать их в Grafana.

6.6.7. Требуемые ресурсы - тут думаю понятно

6.6.8. Резервное копирование и восстановление - просто указать, что такое не применяется

6.6.9. Документация по эксплуатации - ссылка на офф доку

6.7. Ceph

6.7.1. Общая информация

Серh - распределённая программно-определяемая система хранения данных, обеспечивающая блочное (RBD), файловое (СерhFS) и объектное (RGW) хранение на базе единого кластера RADOS. Серh спроектирован для работы на стандартном оборудовании, обеспечивает автоматическую репликацию, самовосстановление при отказах и горизонтальное масштабирование без единой точки отказа. Версия Tentacle (v20) текущий активный релиз.

6.7.2. Требуемые ресурсы

## Минимальные ресурсы:

•    ceph-osd:

    - для HDD OSD - Процессор: мин 1 поток на HDD OSD, рек 3.

    - для NVMe SSD OSD - мин 4, рек 6.

• RAM: 4 ГБ+ на демон (больше - лучше). 2-4 ГБ может работать, но будет медленно. Менее 2 ГБ не рекомендуется.

• Диски: 1 диск на OSD в большинстве случаев. PCIe Gen 4+ SSD объёмом более 30 ТБ может быть разделён на два и более OSD.

• DB/WAL offload (опционально): 1 SSD-раздел на HDD OSD. 4-5 HDD OSD на 1 DB/WAL SATA SSD, до 15 HDD OSD на 1 DB/WAL NVMe SSD.

•    Сеть: 1x 1 Гбит/с (рекомендуется bonded 25+ Гбит/с).

•    ceph-mon:

    - Процессор: минимум 2 ядра.

    - RAM: 5 ГБ+ на демон (большим/продуктивным кластерам нужно больше).

    - Диски: 100 ГБ на демон, SSD настоятельно рекомендуется.

    - Сеть: 1x 1 Гбит/с (рекомендуется 10+ Гбит/с).

•    ceph-mds:

    - Процессор: минимум 2 ядра, высокая частота важнее количества ядер.

    - RAM: 8 Гиб+ на демон.

    - Сеть: 1x 1 Гбит/с (рекомендуется 10+ Гбит/с).

6.7.3. Подготовка к установке

Перед установкой Серh на каждый узел будущего кластера необходимо установить следующие зависимости: Python 3, systemd, контейнерный движок (Podman или Docker), средство синхронизации времени (Chrony или ntpd) и LVM2 для управления дисковыми устройствами.:

dnf install -y python3 systemd
dnf install -y docker-ce docker-ce-cli
systemctl enable --now docker
dnf install -y chrony
systemctl enable --now chronyd
dnf install -y lvm2

На каждом узле добавляем в /etc/hosts адреса всех 3 узлов Дать cephadm возможность подключиться по SSH к новой ноде под пользователем root, чтобы выполнить ssh-copy-id и записать туда публичный ключ cephadm /etc/ssh/sshd_config -> _PermitRootLogin yes /etc/ssh/sshd_config.d/50-cloud-init.conf -> _PasswordAuthentication yes _systemctl restart sshd passwd root_ задаем пароль для root пользова, если не делали этого

6.7.4. Установка

Устанавливаем утилиту cephadm - основной инструмент для развёртывания и управления кластером Ceph:
```
dnf install ceph cephadm
```
Проверяем, что первый узел кластера готов к установке самого cephadm:
```
sudo cephadm check-host
```

Инициализация кластера (bootstrap):

cephadm bootstrap --mon-ip <IP-первого-узла>

Устанавливает набор командных утилит Ceph на бутстрап узле с label _admin:
```
cephadm install ceph-common
```

Добавление остальных узлов (все выполняется на первом узле кластера с label _admin):

ssh-copy-id -f -i /etc/ceph/ceph.pub root@<IP-нового-узла>
ceph orch host add <имя-узла> <IP-нового-узла>

Ceph автоматически разворачивает мониторы (MON) на добавленных узлах (рекомендуется 3 или 5 MON).

Добавление дисков (OSD):

ceph orch apply osd —all-available-devices

Автоматически добавляться все свободные диски

Проверка состояния кластера:
```
ceph status
ceph health detail
```

6.7.5. Консоль управления

Ceph Manager Dashboard - встроенная веб-консоль для мониторинга и администрирования кластера. Предоставляет визуальный контроль состояния кластера, OSD, пулов, RBD-образов, CephFS и объектного хранилища. Dashboard включается как модуль Ceph Manager и доступен по HTTPS после настройки учётных данных администратора.

https://<IP-адрес-первого-узла>:8443

Логин и пароль создаются автоматически при bootstrap и выводятся в терминал в конце процесса. Посмотреть логин пользователя для доступа к Ceph Manager Dashboard:

ceph dashboard ac-user-show

Создание нового пароля для пользователя:

echo 'новый-пароль' > /tmp/pwd.txt
ceph dashboard ac-user-set-password admin -i /tmp/pwd.txt

6.7.6. Резервное копирование и восстановление

Резервное копирование конфигурации кластера. Сохраняет карту мониторов, CRUSH карту и конфигурационные файлы ceph:
```
ceph mon dump > mon-map-backup.txt
ceph osd getcrushmap -o crushmap-backup.bin
cp -r /etc/ceph /backup/etc-ceph-\$(date +\%F)
```

Резервное копирование RBD образов:

rbd snap create <pool></image>@backup-\$(date +\%F)
rbd export <pool></image>@backup-\$(date +\%F) /backup</image>.raw

Резервное копирование CephFS:

ceph fs subvolume snapshot create <fs-name> <subvolume> backup-\$(date +\%F)

Восстановление RBD образа:

rbd import /backup</image>.raw <pool></image>

6.7.7. Документация по эксплуатации

Для глубокого изучения Ceph используйте официальную документацию https://docs.ceph.com/en/latest/

6.8. Система тестирования Tempest

6.8.1. Общая информация

Утилита Tempest представляет собой инструмент интеграционного тестирования для облачных платформ на базе OpenStack. Она выполняет комплексные сценарии (функциональные, API, сценарии очистки и деструктивные тесты), взаимодействуя с компонентами облака через официальные API-интерфейсы.

При запуске тестов с использованием механизма динамических учетных данных (Dynamic Credentials) утилита автоматически изолирует окружение, создавая временные сущности в различных сервисах OpenStack:

• Identity (Keystone): временные проекты (tempest-test-project-*), пользователи (tempest- usr-*) и роли (tempest-role-*).
• Compute (Nova): виртуальные инстансы (tempest-server-*), ключевые пары (tempest- keypair-*), типы инстансов (tempest-flavor-*) и серверные группы.
• Network (Neutron): сети (tempest-network-*), подсети (tempest-subnet-*), порты, роутеры (tempest-router-*), плавающие IP-адреса (Floating IP) и группы безопасности (tempest-secgroup- *) и дефолтные default для каждого временного проекта.
• Image (Glance): тестовые образы (tempest-image-*).
• Volume (Cinder): тома (tempest-volume-*) и снашоты (tempest-snapshot-*).
• По завершении корректного цикла тестирования созданные сущности удаляются автоматически средствами встроенных механизмов деструктуризации (tearDownClass). Для внештатных ситуаций предусмотрены процедуры ручной и полуавтоматической очистки.

6.8.2. Требуемые ресурсы

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

Программные пакеты:

• Система контроля версий git.

• Интерпретатор python3 (строго версии 3.7.15 обязателен).

• Менеджер пакетов pip.

Проверка окружения (команды должны выполняться без ошибок):

git --version
python3 --version
python3 -m venv --help

Важно

Размещение Tempest допускается на любом доступном хосте, наличие утилиты непосредственно на контроллере OpenStack не является обязательным.

Сетевые требования и резолвинг:

На хосте размещения необходимо настроить корректное сопоставление IP-адресов управляющего контура. В файл /etc/hosts требуется внесить IP-адреса и доменные имена контроллеров (номер ctrlX должен соответствовать реальному номеру ноды).

Пример записи в /etc/hosts:

10.40.67.67 controller.accentos.loc ctrl2.accentos.loc

6.8.3. Установка

Процесс развертывания Tempest и плагинов состоит из следующих последовательных шагов:

1) Авторизуйтесь на корпоративном ресурсе Gerrit по адресу: http://gerrit.tnxos.loc.
2) Перейдите в раздел Browse -> Repositories.
3) Используя строку фильтра, найдите репозиторий tempest и скопируйте предоставленный URL-адрес для клонирования (git clone).
4) Перейдите в рабочую директорию на сервере назначения и выполните команду клонирования, после чего зайдите в созданную папку проекта.
5) Отредактируйте конфигурационный файл tempest.conf в соответствии с параметрами вашего стенда. В случае одноидовой инсталляции поля конфигурации ctrl1-3 и db1-3 необходимо оставить пустыми.
6) Инициализируйте окружение, запустив скрипт из корневой директории: ./setup_env
7) Активируйте созданное виртуальное окружение Python: source .venv/bin/activate
8) Выполните установку сопутствующего плагина в режиме редактирования: python -m pip install -e ./plugin

6.8.4. Тестирование работоспособности

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

Экспортируйте авторизационные переменные окружения OpenStack из файла проекта (openrc) и проверьте валидность токена:
```
source /path/to/<project>-openrc.sh
env | grep '\^OS_'
openstack token issue # Проверка, ожидаем вывод
```
Задайте переменную пути к файлу конфигурации и выполните базовую валидацию структуры:
```
export TEMPEST_CONFIG=/путь/к/директории/с/tempest.conf
tempest verify-config
```

Если команда tempest verify-config не выдает ошибки, значит базовая проверка конфигурации пройдена успешно.

6.8.5. Консоль управления

Вся работа с утилитой Tempest осуществляется через CLI-интерфейс терминала в активном виртуальном окружении (.venv). Специализированная графическая консоль управления в рамках данной утилиты не предусмотрена. Пользователь управляет процессом, передавая аргументы и конфигурационные списки тестов напрямую бинарному файлу tempest.

6.8.6 Резервное копирование и восстановление

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

Фиксация состояния (снапшот инфраструктуры):

Перед проведением любых тестов необходимо перейти в директорию ./tempest и инициализировать снимок текущего состояния облака OpenStack:

tempest cleanup --init-saved-state

Данная команда обходит все OpenStack облако и сохраняет снимок текущего состояния в файл saved_state.json. Этот файл выступает «точкой восстановления», гарантируя, что созданные до начала тестов объекты не будут затронуты механизмами очистки Tempest. Рекомендация: Регулярно создавайте архивные копии конфигурационного файла tempest.conf, чтобы избежать потери кастомных настроек стенда.

6.8.7. Документация по эксплуатации

Варианты запуска тестов

Стандартный запуск (подходит в том числе для однонодовой инсталляции):

tempest run --config-file ~/nytb/k/tempest/tempest.conf --load-list
~/путь/к/tests/train/platform.2020.11-test-list.txt

Запуск деструктивных тестов (Не подходит для однонодовой инсталляции!) .. important:: Внимание: Запуск данных тестов может негативно повлиять на стабильность контроллеров. Выполнять строго изолированно с одного контроллера!:

tempest run --config-file ~/путь/к/tempest/tempest.conf --load-list
~/путь/к/tests/train/destructive_tests.txt

Запуск одного целевого теста:

tempest run --config-file ~/путь/к/tempest/tempest.conf --regex "Скопируйте строку из файла platform.2020.11-test-list.txt/destructive_tests.txt, id необязателен"

Запуск тестов на конкретной вычислительной ноде (Compute)

Цель: Прогнать Tempest так, чтобы все создаваемые инстансы шли на один заранее выбранный compute-узел. Полезно для изолированного тестирования конкретной ноды.

Подготовка Перед началом обязательно выполнить:

tempest cleanup --init-saved-state

Шаг 1. Выбрать целевую ноду Посмотреть список compute-сервисов и определить hostname нужного узла:

openstack compute service list --service nova-compute

В примере ниже используется node1.accentos.loc. Подставьте свой hostname.

Шаг 2. Отключить остальные compute-сервисы Шедулер Nova не сможет рассматривать отключенные хосты как кандидатов. Это единственный способ, который дает 100% детерминированный однонодовый режим независимо от того, какие именно тесты запускаются:

openstack compute service set --disable --disable-reason "tempest single-node run"
node2.accentos.loc nova-compute

Команд должно быть столько, сколько у вас лишних compute-нод. Hostname берутся из вывода Шага 1.

Шаг 3. Проверить состояние:

openstack compute service list --service nova-compute

Ожидаемая картина::

node1.accentos.loc — Status: enabled, State: up
остальные узлы — Status: disabled, State: up

Шаг 4. Запустить тесты:

tempest run --config-file ~/path/to/tempest.conf ...

Все успешно созданные инстансы будут на node1.accentos.loc.

Шаг 5. Проверить распределение (по желанию) После выполнения тестов можно убедиться, что все инстансы располагавались на нужной ноде:

# Задать время перед началом тестов
START=$(date -u +%Y-%m-%dT%H:%M:%SZ)

# Проверка
echo "$START"

# Сводка по хостам
openstack server list --all-projects --deleted --long --changes-since "$START" -f value -c Host | sort | uniq -c | sort -rn

# Сводка по статусам
openstack server list --all-projects --deleted --long --changes-since "$START" -f value -c Status | sort | uniq -c | sort -rn

В колонке Host должны быть только node1.accentos.loc и пустые значения (для ERROR). node2/node3 и пр. появляться не должны.

Шаг 6. Откат — вернуть остальные ноды в работу После завершения тестов обязательно включить отключённые сервисы (nodeX.accentos.loc - пример названия, подставьте свое):

openstack compute service set --enable nodeX.accentos.loc nova-compute

Итоговая проверка:

openstack compute service list --service nova-compute

Все compute-сервисы должны вернуть статус enabled / up.

3. Очистка ресурсов после тестирования (Cleanup) После завершения тестов для очистки не удаленных ресурсов используйте команды:

tempest cleanup --dry-run # Записывает ресурсы, которые могут быть удалены в файл dry_run.json
tempest cleanup # добирает безымянные ресурсы

Если по каким-то причинам не удалились порты и security groups, то используйте команду в главной директории tempest/:

python -m clean_up

4. Парсинг логов и формирование отчетности Для получения отчета о тестах, завершившихся неудачно, используйте команды из основной директории tempest/:

make compilemessages
python -m parser
python -m parser_fail

Описание скриптов:

python -m parser — данная команда подготовит текстовый документ tempest_report.txt с отчетом по всем тестам.
python -m parser_fail — данная команда подготовит текстовый документ tempest_report_fail.txt с отчетом по всем неудачным тестам.

6.9. Система миграции с физических хостов на BM AccentOS

6.9.1. Общая информаци

Утилита миграции предназначена для автоматизированного переноса (P2V/V2V) физических серверов или виртуальных машин сторонних платформ в облачную инфраструктуру OpenStack. Процесс миграции выполняется без полной остановки источника путем посекторного или файлового копирования операционной системы и последующей адаптации под виртуальную среду. Автоматизированный процесс, управляемый главным скриптом migrate.sh, включает в себя следующие ключевые этапы:

• Анализ источника: автоматическое определение операционной системы, сбор параметров CPU, RAM, разметки и размера дискового пространства.
• Подготовка целевой инфраструктуры: генерация SSH-ключей, создание кастомного типа инстанса (flavor) в OpenStack на основе параметров источника, создание Cinder-диска и целевой виртуальной машины с поддержкой cloud-init.
• Сетевая настройка: динамическое получение IP-адреса целевой BM и отключение функции Port Security для беспрепятственной передачи данных.
• Синхронизация данных: разметка диска в файловую систему ext4 на целевой BM и двухуровневая или прямая передача данных (rootfs) с источника с помощью утилиты rsync.
• Адаптация системы (fix-rootfs.sh): запуск скрипта исправления конфигурации внутри изолированного окружения целевой BM. Скрипт очищает привязки MAC/UUID, перестраивает fstab (удаляя LVM/swap), переустанавливает загрузчик GRUB через chroot, пересобирает образ initramfs с драйверами virtio, переводит SELinux в режим permissive и очищает системные идентификаторы (machine-id, логи, кэш).
• Финальный этап: создание Glance-образа из готового Cinder-диска (опционально) и перезагрузка целевой машины в рабочем режиме.

6.9.2. Требуемые ресурсы

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

• утилиты sshpass (для автоматизации ввода паролей к источнику) и rsync.

• утилиты командной строки OpenStack CLI (пакет python3-openstackclient).

• текстовый редактор (vim или аналогичный).

Доступы и учетные данные:

• К источнику: SSH-доступ с правами суперпользователя (root) по IP-адресу.

• К OpenStack: Доступ к Keystone API и права на создание инстансов, дисков, типов инстансов (flavors), сетей и образов.

Дисковое пространство:

• При использовании рекомендуемого двухэтапного режима миграции

(RSYNC_DIRECT="false") на хосте миграции в директории STAGING_DIR должно быть свободно не менее N + DISK_SIZE_EXTRA_GB Гб пространства, где N — объем данных на источнике.

6.9.3. Установка

Развертывание утилиты на хосте миграции выполняется вручную по следующему алгоритму:

Создайте рабочую директорию и перейдите в нее:
```
mkdir -p /opt/migration
cd /opt/migration
```
Скопируйте в созданную директорию файлы компонентов утилиты: migrate.sh, migrate.cfg и fix-rootfs.sh.
Назначьте исполняемые права на скрипты автоматизации:
```
chmod +x migrate.sh fix-rootfs.sh
```
Откройте конфигурационный файл для редактирования обязательных параметров:
```
vim migrate.cfg
```

Заполните блоки параметров авторизации OpenStack, параметры подключения к источнику и конфигурацию целевой ВМ:

# — OpenStack ————————————————————————————————————————
export OS_AUTH_URL="http://ВАШ_KEYSTONE:5000/v3"
export OS_PROJECT_NAME="имя_проекта"
export OS_USERNAME="ваш_логин"
export OS_PASSWORD="ваш_пароль"

# — Источник (физический сервер) ——————————————————————
SRC_HOST="10.10.10.100"   # IP физического сервера
SRC_SSH_USER="root"       # SSH пользователь
SRC_SSH_PASS="пароль"     # SSH пароль

# — Целевая ВМ ————————————————————————————————————————
 VM_NAME="migrated-server1"   # Имя ВМ в OpenStack
 VM_IMAGE="centos9-cloud"     # Образа с cloud-init
 KEY_NAME="mykey"             # SSH keypair в OpenStack
 NETWORK_ID="provider"        # Сеть OpenStack
 TARGET_USERNAME="admin"      # Пользователь на ВМ
 TARGET_PASSWORD="пароль_вм"  # Пароль на ВМ

6.9.4. Тестирование работоспособности

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

Проверка связи с источником: убедитесь, что хост миграции имеет доступ к физическому серверу по SSH и может считывать данные:
```
sshpass -p 'пароль' ssh root@10.10.10.100 'hostname && df -h'
```
Проверка авторизации в OpenStack: импортируйте параметры конфигурации и выполните тестовые запросы к сервисам облака для подтверждения прав:
```
source migrate.cfg
openstack token issue
openstack image list
openstack network list
```

Если все команды вернули корректные списки объектов без ошибок авторизации, утилита готова к запуску.

6.9.5. Консоль управления

Утилита функционирует исключительно в режиме интерфейса командной строки (CLI). Графическая панель управления отсутствует. Все управление параметрами миграции

6.9.6. Резервное копирование и восстановление

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

Безопасность источника: утилита выполняет чтение данных с физического сервера в режиме read-only с помощью rsync, что исключает повреждение исходной системы. Тем не менее, перед миграцией критически важных систем рекомендуется выполнить штатный бэкап данных источника силами существующих в организации систем резервного копирования.
Изоляция staging-зоны: при сбое на этапе копирования в промежуточную директорию (STAGING_DIR), ее содержимое может быть безопасно удалено вручную, так как является временной копией.
Контроль состояния OpenStack: в случае аварийного прерывания migrate.sh, на целевой платформе могут остаться частично созданные объекты (диски, флейворы, запущенные ВМ). Их удаление и очистка окружения для повторного запуска производятся вручную инженером через стандартный пульт управления OpenStack (Horizon) или CLI.

6.9.7. Документация по эксплуатации

Тонкая настройка параметров миграции (migrate.cfg)

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

Режим rsync (RSYNC_DIRECT): по умолчанию используется безопасный двухэтапный режим ("false"), копирующий данные через хост миграции. Если между источником и создаваемой ВМ настроена прямая L3-маршрутизация, установите "true" для прямой передачи данных.
Размер диска (DISK_SIZE_EXTRA_GB): задает объем в Гб, который будет добавлен к итоговому размеру Cinder-диска сверх реального размера диска источника (например, DISK_SIZE_EXTRA_GB="5").
Статический IP (STATIC_IP): оставьте пустым для получения адреса по DHCP, либо укажите адрес в формате 192.168.1.100/24.
Создание Glance-образа (CREATE_IMAGE): при значении "true", после окончания копирования ВМ будет временно остановлена для создания эталонного образа диска в Glance с именем, заданным в IMAGE_NAME.
Ограничение скорости (RSYNC_BW_LIMIT): лимитирует пропускную способность rsync в Кб/с для снижения нагрузки на сеть (значение "0" — без ограничений, "51200" — 50 МБ/с).

## 2. Запуск процесса миграции

Для старта процедуры перейдите в каталог утилиты и запустите главный скрипт, перенаправив вывод в лог-файл для истории:

cd /opt/migration
sudo ./migrate.sh 2>&1 | tee /var/log/migration-${date +%Y%m%d-%H%M %S}.log

Мониторинг процесса в реальном времени:

# Просмотр лога миграции
tail -f /var/log/migration-*.log

# Оперативный вывод только ошибок и предупреждений
grep -E "\[FATAL\]|\[ERROR\]|\[WARN\]" /var/log/migration-*.log

3. Действия после успешного завершения миграции После того как скрипт отрапортует об успешном окончании работы, выполните постабработку:

Подключитесь к созданной ВМ по SSH: ssh user@VM_IP.

Проверьте статус системных служб, дисковых разделов и сети::
systemctl list-units --failed df -h ip addr

Типичные проблемы и методы их решения

А. Целевая ВМ не загружается (черный экран в консоли)

Диагностика: Выведите последние строки консольного лога через CLI OpenStack:
```
openstack console log show migrated-vm1 | tail -50
```
Причины: Некорректный UUID в grub.cfg, отсутствие virtio-драйверов в initramfs, либо неверные пути к ядру.

Решение: Решение (ручная загрузка через GRUB shell):

grub> ls (hd0,msdos1)/boot/
grub> linux (hd0,msdos1)/boot/vmlinux-5.14.0-xxx root=UUID=ваш-uuid ro net.ifnames=0
grub> initrd (hd0,msdos1)/boot/initramfs-5.14.0-xxx.img
grub> boot

Б. Отсутствует сетевое подключение на ВМ после старта

Диагностика: Через VNC-консоль OpenStack проверьте состояние интерфейсов:
```
nmcli device status
ip link show
cat /etc/NetworkManager/system-connections/eth0.nmconnection
```
Решение: Перезапустите сетевой стек или принудительно запросите адрес:
```
systemctl restart NetworkManager
dhclient eth0
```

В. Скрипт rsync завершился со статусом ошибки

Анализ кодов возврата: Анализ кодов возврата:
Код 23 / Код 24: Являются штатными. Свидетельствуют о пропуске специфичных xattr/SELinux файлов или изменении файлов (например, логов) непосредственно во время копирования. Миграция считается успешной.
Код 11 (Ошибка ввода/вывода): Свидетельствует об аппаратной или файловой проблеме на диске источника.
Решение для Кода 11: Проверьте состояние дисков физического сервера:
```
sshpass -p 'пароль' ssh root@источник 'dmesg | grep -i error | tail -20'
```

Г. Использование адаптационного скрипта fix-rootfs.sh в автономном режиме

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

# Монтаж корневой файловой системы целевого диска
mount /dev/vdb1 /mnt/rootfs

# Автономный запуск адаптации
sudo ./fix-rootfs.sh /mnt/rootfs

Примечание: Скрипт автоматически примонтирует виртуальные директории /proc, /sys, /dev, /run, выполнит chroot-трансформацию и корректно размонтирует ресурсы по завершении (через обработчик trap EXIT).

Инструкция Инструкция описывает процесс переноса физической машины (ФМ) в TOS(Openstack). В процессе используются прилагаемый скрипт и конфигурационный файл:

migrate.sh – скрипт миграции ФМ. Используется совместно с конфигурационным файлом migrate.cfg. migrate.cfg – конфигурационный файл с параметрами подключения к ФМ и Openstack;

Выполнение скрипта предполагается на какой-либо linux-машине. В случае отсутствия пакета «sshpass» скрипт «постарается» его установить.

Необходимо отредактировать конфиг migrate.cfg

Выполнение скрипта отражено в схеме:

Запуск скрипта Например, bash migrate.sh В процессе выполнения будет создана в Openstack виртуальная машина (ВМ) с параметрами как у ФМ. На диск ВМ с помощью chroot и rsync будет перенесена файловая система основного диска ФМ.

Приложение Листинг скрипта:

#!/bin/bash
set -e

CONFIG='/migrate.cfg'
if [ ! -f "$CONFIG" ]; then
  echo "Нет файла конфигурации $CONFIG"
  exit 1
fi
source "$CONFIG"
export $(grep ^OS_ $CONFIG | xargs)

 export PATH=$PATH:/usr/local/bin

 # --- Автоустановка зависимостей ---
 echo "[0/10] Проверка и установка sshpass, pip, openstackclient..."
 install_tools() {
    if grep -qi ubuntu /etc/os-release || grep -qi debian /etc/os-release; then
     PKG_MANAGER="apt-get"
     INSTALL_CMD="sudo apt-get install -y"
     UPDATE_CMD="sudo apt-get update"
    elif grep -Eqi 'centos|rhel|almalinux|rocky|fedora' /etc/os-release; then
      PKG_MANAGER="yum"
      INSTALL_CMD="sudo yum install -y"
      UPDATE_CMD="sudo yum makecache"
     else
       echo "Неизвестная ОС. Установите sshpass и OpenStack CLI вручную!"
       exit 1
     fi

     if ! command -v sshpass >/dev/null 2>&1; then
        echo "  Устанавливаем sshpass..."
        $UPDATE_CMD
        $INSTALL_CMD epel-release || true
        $INSTALL_CMD sshpass
     fi

     if ! command -v openstack >/dev/null 2>&1; then
        echo "  Устанавливаем pip и openstackclient (pip)..."
        $UPDATE_CMD
        $INSTALL_CMD python3 python3-pip || true
        sudo pip3 install --ignore-installed python-openstackclient
        export PATH=$PATH:/usr/local/bin
     fi
 }
 install_tools

 SSH_CMD="sshpass -p $SRC_SSH_PASS ssh -o StrictHostKeyChecking=no
 $SRC_SSH_USER@$SRC_HOST"
 RSYNC_CMD="sshpass -p $SRC_SSH_PASS rsync"

 # === Гарантируем наличие SSH-ключа локально ===
 SSH_KEY_PATH="${HOME}/.ssh/id_rsa.pub"
 if [[ ! -f "$SSH_KEY_PATH" ]]; then
     echo "[!] ~/.ssh/id_rsa.pub не найден, создаём новый ключ..."
     mkdir -p ~/.ssh
     chmod 700 ~/.ssh
     ssh-keygen -q -t rsa -b 4096 -N "" -f ~/.ssh/id_rsa
 fi
 if [[ ! -f "$SSH_KEY_PATH" ]]; then
     echo "[ОШИБКА] Не удалось создать SSH-ключ $SSH_KEY_PATH !"
     exit 1
 fi
 SSH_PUB_KEY_CONTENT=$(cat "$SSH_KEY_PATH")

 # === Создаём/проверяем ключевую пару в OpenStack ===
 OS_KEY_NAME="migration_baremetal"
 EXISTING_KEY=$(openstack keypair list -f value -c Name | grep -w "$OS_KEY_NAME" || true)
 if [[ -z "$EXISTING_KEY" ]]; then
     echo "Загружаем публичный ключ в OpenStack как $OS_KEY_NAME ..."
     openstack keypair create --public-key "$SSH_KEY_PATH" "$OS_KEY_NAME"
 else
    echo "Ключевая пара $OS_KEY_NAME уже зарегистрирована в OpenStack"
 fi

 echo "[1/10] Определяем основной диск и разметку исходного сервера..."

 SRC_MAIN_DISK=$($SSH_CMD "lsblk -nd -o NAME,TYPE | awk '\$2==\"disk\" {print \"/dev/\"\$1; exit}'")
 SRC_DISK_NAME="${SRC_MAIN_DISK##*/}"

 SRC_DISK_SIZE_GB=$($SSH_CMD "lsblk -nd -b -o NAME,SIZE,TYPE | awk -v d=\"$SRC_DISK_NAME\" '\$1==d && \$3==\"disk\" {print int(\$2/1024/1024/1024); exit}'")
 if [[ -z "$SRC_DISK_SIZE_GB" || "$SRC_DISK_SIZE_GB" == "0" ]]; then
     SRC_DISK_SIZE_GB=$($SSH_CMD "fdisk -l $SRC_MAIN_DISK 2>/dev/null | awk '/Disk $SRC_MAIN_DISK: / {gsub(/,/,\"\"); print int(\$5/1024/1024/1024)}'")
 fi

 echo "SRC_MAIN_DISK=$SRC_MAIN_DISK"
 echo "SRC_DISK_SIZE_GB=$SRC_DISK_SIZE_GB"

 echo "[2/10] CPU/RAM autodetect..."
 if [[ "$VM_FLAVOR" == "auto" ]]; then
     VM_CPU=$($SSH_CMD nproc)
     VM_RAM_MB=$($SSH_CMD "awk '/MemTotal/ {print int(\$2/1024)}' /proc/meminfo")
 fi
 echo "  CPU: $VM_CPU, RAM: $VM_RAM_MB МБ, Диск: $SRC_MAIN_DISK $SRC_DISK_SIZE_GB GB"

 echo "[3/10] Создаём flavor, если нужно..."
 if [[ "$VM_FLAVOR" == "auto" ]]; then
     FLAVOR_NAME="migrated-${VM_CPU}cpu-${VM_RAM_MB}mb-${SRC_DISK_SIZE_GB}gb"
     FOUND=$(openstack flavor list -f value -c Name | grep -w "$FLAVOR_NAME" || true)
     if [[ -z "$FOUND" ]]; then
         openstack flavor create --ram "$VM_RAM_MB" --vcpus "$VM_CPU" --disk "$SRC_DISK_SIZE_GB" "$FLAVOR_NAME"
     fi
     VM_FLAVOR="$FLAVOR_NAME"
 fi
 echo "  Используем flavor: $VM_FLAVOR"

 echo "[4/10] Генерируем cloud-init user-data с нужным IP..."
 CLOUD_INIT=cloud-init-userdata.yaml
 cat > $CLOUD_INIT << EOF
 #cloud-config
 preserve_hostname: false
 hostname: $VM_NAME
 manage_etc_hosts: true
 users:
  - default
  - name: $TARGET_USERNAME
    groups: sudo
    shell: /bin/bash
    sudo: ALL=(ALL) NOPASSWD:ALL
    ssh-authorized-keys:
     - $SSH_PUB_KEY_CONTENT
  EOF

  if [[ -n "$STATIC_IP" ]]; then
  cat >> $CLOUD_INIT << EOF
  network:
  version: 2
  ethernets:
    eth0:
     addresses: [$STATIC_IP/24]
     gateway4: ${STATIC_IP%.*}.1
     nameservers:
      addresses: [8.8.8.8,8.8.4.4]
  EOF
  fi

  echo "[5/10] Создаём виртуальную машину в OpenStack..."
  openstack server create \
    --image "$VM_IMAGE" \
    --flavor "$VM_FLAVOR" \
    --network "$NETWORK_ID" \
    --key-name "$OS_KEY_NAME" \
    --user-data $CLOUD_INIT \
    "$VM_NAME"

  #echo "[*] Отключаем port security на всех портах ВМ $VM_NAME..."
  #for PORT_ID in $(openstack port list --server "$VM_NAME" -f value -c ID); do
  #  openstack port set --disable-port-security "$PORT_ID"
  #  echo "  - port $PORT_ID: port security выключен"
  #done

  echo "  Ожидаем получения IP-адреса созданной VM..."
  while true; do
    VM_IP=$(openstack server show "$VM_NAME" -f value -c addresses | grep -Eo "([0-9]{1,3}\.){3}[0-9]{1,3}" | head -n1)
  if [[ -n "$VM_IP" ]]; then
      echo "  VM IP: $VM_IP"
      break
  fi
      echo "    [$(date +%H:%M:%S)] Ждём выдачи адреса от облака..."
      sleep 5
  done
  echo "[6/10] Ожидание доступности SSH на VM ($VM_IP)..."
  for i in {1..30}; do
      ssh -o StrictHostKeyChecking=no -o ConnectTimeout=4 $TARGET_USERNAME@$VM_IP 'echo up' && break || sleep 5
  done

  echo "[7/10] Установка rsync на целевой VM"
  ssh $TARGET_USERNAME@$VM_IP "sudo apt-get update && sudo apt-get install -y rsync || sudo yum install -y rsync"

  echo "[8/10] Копирование rootfs с исходника на VM (rsync+sshpass)..."
  ssh $TARGET_USERNAME@$VM_IP "sudo mkdir -p /mnt/rootfs"
  $RSYNC_CMD -axHAX --numeric-ids --progress \
   --exclude={"/dev/*","/sys/*","/proc/*","/tmp/*","/run/*","/mnt/*","/media/*","/lost+found"} \
   -e "ssh -o StrictHostKeyChecking=no" \
   $SRC_SSH_USER@$SRC_HOST:$SRC_ROOTFS $TARGET_USERNAME@$VM_IP:/mnt/rootfs/

  echo "[9/10] Chroot-правки (initramfs, grub). При необходимости меняйте команды."
  ssh $TARGET_USERNAME@$VM_IP "sudo mount --bind /dev /mnt/rootfs/dev; sudo mount --bind /proc /mnt/rootfs/proc; sudo mount --bind /sys /mnt/rootfs/sys;\
  sudo chroot /mnt/rootfs /bin/bash -c '
  update-initramfs -cu || dracut --force || true
  update-grub || grub2-mkconfig -o /boot/grub2/grub.cfg || true
  passwd || true
  exit
  '; \
  sudo umount /mnt/rootfs/dev; \
  sudo umount /mnt/rootfs/proc; \
  sudo umount /mnt/rootfs/sys"

  echo "[10/10]
  --- Миграция завершена! ---
  Обязательно проверьте на VM:
  - /etc/fstab (UUID, названия устройств)
  - /etc/network/*
  - /etc/hostname, /etc/hosts
  - grub/initrd
  - свои сетевые настройки
  - удалите старые ssh_host_* ключи

  После всех правок перезагрузите VM и проверьте доступ.
  "

6.10. Система миграции BM VMware в BM AccentOS

6.10.1. Общая информация

Утилита миграции представляет собой комплекс автоматизации для переноса виртуальных машин (BM) с гипервизоров VMware ESXi в облачную инфраструктуру TOS (OpenStack). Инструмент позволяет автоматизировать опрос хостов, пакетно выгружать конфигурации и диски BM, а также конвертировать проприетарные форматы хранения данных в открытые стандарты для последующего развертывания в целевом облаке.

В состав утилиты входит набор специализированных bash-скриптов и единый файл конфигурации:

esxi_list_vm.sh — скрипт инвентаризации, выполняющий опрос целевого хоста ESXi. На основе полученных данных он формирует структурированный файл vm_paths.txt, содержащий перечень зарегистрированных BM, их уникальные идентификаторы (VM_ID), пути к конфигурационным файлам VMX и сопутствующим виртуальным дискам VMDK.
export_vm.sh — скрипт выгрузки, осуществляющий изолированный экспорт файлов конкретной BM по ее имени. Поддерживает как локальное сохранение данных, так и передачу на удаленный целевой сервер хранения.
convert_to_openstack.sh — скрипт трансформации данных, который конвертирует полученные образы дисков VMware в формат qcow2, оптимизированный для работы в среде QEMU/KVM под управлением OpenStack.
export_config.conf — централизованный конфигурационный файл, содержащий параметры сетевого доступа к хостам VMware ESXi, учетные данные и директивы путей назначения для экспортируемых объектов.

6.10.2. Требуемые ресурсы

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

Программные требования:

Операционная система семейства Linux (с поддержкой интерпретатора bash).
Установленная утилита sshpass для автоматизации интерактивного ввода паролей при SSH-подключениях к закрытым хостам.
Наличие установленного пакета qemu-img (интегрирован в логику скрипта конвертации) для пересборки дисковых образов.
Утилиты командной строки OpenStack CLI (пакет python3-openstackclient) для возможности загрузки образов через терминал.

Сетевые доступы и учетные записи:

Сетевой L3-доступ с хоста миграции до управляющего интерфейса хоста VMware ESXi (ESXI_HOST) по протоколу SSH.
Учетная запись на хосте ESXi (обычно root) с правами на чтение хранилищ данных (datastore) и выполнение консольных команд.
При удаленном режиме экспорта — сетевой доступ и учетные данные к целевому серверу хранения (REMOTE_HOST) по протоколу SSH/SFTP.

6.10.3. Установка

Развертывание и первичная настройка утилиты миграции на Linux-машине осуществляется по следующему алгоритму:

Убедитесь в наличии утилиты sshpass. В случае ее отсутствия выполните установку из штатных репозиториев ОС (например, sudo apt install sshpass или sudo dnf install sshpass).
Создайте рабочую директорию и распакуйте в нее архив с компонентами утилиты:
```
mkdir -p /root/esxi
tar -zxvf esxi.tar.gz -C /root/esxi
cd /root/esxi
```
Откройте конфигурационный файл export_config.conf для настройки параметров среды:
```
vim export_config.conf
```

Отредактируйте параметры подключения в соответствии со спецификой инфраструктуры:

# IP-адрес или DNS-имя ESXi-хоста
ESXI_HOST="10.40.22.124"
# Имя пользователя на ESXi (обычно root)
ESXI_USER="root"
# Пароль от пользователя ESXi
ESXI_PASSWORD="Pa$$w0rD!!!"

# Тип экспорта: local (на текущую машину) или remote (на удаленный хост)
EXPORT_TYPE="local"
# Каталог для локального экспорта (должен обладать достаточным дисковым пространством)
LOCAL_EXPORT_PATH="/vms"
# Имя сторэйджа, как оно отображается в квадратных скобках на ESXi-хосте
STORAGE_NAME="datastore1"

# Настройки для удалённого экспорта (применяются, если EXPORT_TYPE="remote")
REMOTE_HOST="10.0.0.5"
REMOTE_USER="backup"
REMOTE_PASSWORD="remote_password"
REMOTE_PATH="/data/vm_exports"

6.10.4. Тестирование работоспособности

Перед инициацией массового экспорта ВМ необходимо провести валидацию доступности инфраструктуры и синтаксиса конфигурации: 1. Проверка инвентаризации: Запустите скрипт первичного опроса гипервизора VMware:

bash esxi_list_vm.sh

Верификация результатов опроса: Проверьте факт создания и корректность структуры выходного файла vm_paths.txt:
```
cat vm_paths.txt
```

Ожидаемый результат: Файл должен содержать заголовки и строки с разделением точкой с запятой (;), описывающие параметры ВМ:

VM_NAME;VM_ID;VMX_PATH;VMDK_PATH
test_vm1;1;[storage] test_vm1/test_vm1.vmx;[storage] test_vm1/test_vm1.vmdk
astra_vmware;2;[storage] astra_vmware/astra_vmware.vmx;[storage]
astra_vmware/astra_vmware.vmdk

Тест авторизации OpenStack: Если загрузка образов планируется через CLI, импортируйте переменные окружения и проверьте доступ к сервису Glance:
```
source admin-openrc
openstack image list
```

6.10.5. Консоль управления

Инструментарий миграции представляет собой консольную утилиту, работающую в CLI- режиме терминала операционной системы Linux. Интерактивная графическая панель для запуска самих скриптов не предусмотрена. Ход выполнения операций, процент копирования данных и ошибки транслируются непосредственно в стандартный поток вывода (stdout/stderr) текущей сессии командной строки. Полноценный веб-интерфейс (OpenStack Dashboard / Horizon) задействуется пользователем только на финальном этапе — при регистрации полученного образа диска в облачной платформе.

6.10.6. Резервное копирование и восстановление

Утилита осуществляет операции экспорта исходных виртуальных машин в режиме чтения, не модифицируя конфигурационные файлы внутри хранилищ данных VMware ESXi, что гарантирует сохранность исходных систем.

Правила обеспечения отказоустойчивости процесса миграции:

Резервирование конфигурации: Все настройки утилиты сосредоточены в файле export_config.conf. Рекомендуется создавать резервную копию данного файла перед внесением изменений.
Управление дисковым пространством: На хосте миграции в директории LOCAL_EXPORT_PATH (или на удаленном сервере REMOTE_PATH) должно быть зарезервировано свободное место, превышающее суммарный объем физически занятого пространства мигрирующих ВМ. При аварийном прерывании процесса экспорта (например, при нехватке места), незавершенные файлы дисков (с расширением -flat.vmdk) необходимо удалить вручную перед повторным запуском.
Изоляция образов: Файл vm_paths.txt динамически перезаписывается при каждом запуске esxi_list_vm.sh. Если вам необходимо сохранить историю путей, скопируйте файл под уникальным именем.

6.10.7. Документация по эксплуатации

## 1. Пошаговая процедура экспорта и конвертации ВМ

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

Шаг А: Экспорт файлов ВМ. Запустите скрипт передачи, указав точное имя целевой машины из файла vm_paths.txt:

bash export_vm.sh test_vm1

По окончании процесса в директории экспорта (например, /vms/test_vm1) сформируется полный набор файлов конфигурации и данных, включая дескриптор .vmdk и основной бинарный диск -flat.vmdk.

Шаг Б: Конвертация диска. Преобразуйте дисковую подсистему машины в формат OpenStack, передав в качестве аргументов путь к каталогу экспортированной ВМ и желаемое имя результирующего файла:

bash convert_to_openstack.sh /vms/test_vm1/ test_vm1.qcow2

## 2. Импорт полученного образа в платформу TOS (OpenStack)

Созданный образ диска qcow2 может быть зарегистрирован в сервисе Glance двумя альтернативными способами:

Вариант А. Импорт через веб-интерфейс Horizon

Авторизуйтесь в веб-интерфейсе OpenStack.
Перейдите по пути: Проект -> Вычислительные ресурсы -> Образы.
В правом верхнем углу нажмите кнопку [+ Create Image].
В открывшейся форме заполните ключевые поля:

Image Name: укажите сетевое имя образа (например, test).
Source Type: выберите переключатель File.
File: нажмите кнопку Browse... и выберите файл test_vm1.qcow2.
Format: строго выберите QCOW2 – QEMU Emulator из выпадающего списка.

Нажмите кнопку [✓ Create Image] внизу формы и дождитесь перехода статуса образа в Active.

Вариант Б. Импорт через интерфейс командной строки (CLI)

Для минимизации времени передачи больших файлов рекомендуется выполнять загрузку напрямую с хоста миграции через OpenStack Client:

# Авторизация в облаке под административной учетной записью
source admin-openrc

# Команда регистрации и загрузки образа диска
openstack image create \
    --file test_vm1.qcow2 \
    --disk-format qcow2 \
    --container-format bare \
    --public \
    test_vm1

Возможные ошибки при эксплуатации и их устранение

Ошибка: "sshpass: command not found" при запуске скрипта. Утилита автоматизации не установлена на хосте миграции. См. подраздел 6.10.3 для установки пакета.
Скрипт esxi_list_vm.sh отрабатывает, но файл vm_paths.txt пуст. Проверьте правильность написания директивы STORAGE_NAME в конфигурационном файле. Имя должно строго соответствовать названию Datastore на стороне ESXi (чувствительно к регистру букв).
Ошибка конвертации диска. Убедитесь, что процесс экспорта export_vm.sh завершился корректно и файл данных -flat.vmdk не является поврежденным (размер файла должен быть равен реальному объему занятого пространства диска на гипервизоре).

6.10.1. Документация по эксплуатации

Инструкция миграции ВМ VMware в OpenStack

Инструкция описывает процесс экспорта виртуальной машины (ВМ) гипервизора vmware и последующего её импорта в TOS(Openstack).

В процессе используются прилагаемые скрипты и конфигурационный файл:

esxi_list_vm.sh – скрипт «опроса» esxi-хоста и составления списка расположенных на нём ВМ. Используется совместно с конфигурационным файлом export_config.conf. Скрипт создаёт файл vm_paths.txt, в который вносит имена ВМ и их диски.

export_vm.sh – скрипт экспорта ВМ. Используется с параметром «имя ВМ» и служит для экспорта только одной указанной ВМ.

convert_to_openstack.sh – скрипт конвертации диска ВМ в формат qcow2. Используется с параметрами «путь к папке экспортированной ВМ» и «имя диска с расширением .qcow2»

export_config.conf – конфигурационный файл с параметрами подключения к ESXI-хосту и экспорта:

# IP-адрес или DNS-имя ESXi-хоста
ESXI_HOST="10.40.22.124"

# Имя пользователя на ESXi (обычно root)
ESXI_USER="root"

# Пароль от пользователя ESXi
ESXI_PASSWORD="Pa$$w0rD!!!"

# Tип экспорта: local ulu remote
EXPORT_TYPE="local"

# Каталог для локального экспорта
LOCAL_EXPORT_PATH="/vms"

# Имя сторэйджа, как оно отображается в квадратных скобках на esxi-хосте (например, [datastore1])
STORAGE_NAME="datastore1"

# Настройки для удалённого экспорта
REMOTE_HOST="10.0.0.5"
REMOTE_USER="backup"
REMOTE_PASSWORD="remote_password"
REMOTE_PATH="/data/vm_exports"

Выполнение скриптов предполагается на какой-либо linux-машине. Перед запуском необходимо проверить наличие установленного пакета «sshpass» и в случае отсутствия установить его.

Необходимо распаковывать архив esxi.tar.gz в папку. Например, в /root/esxi. Далее отредактировать конфиг export_config.conf

Первым запускается скрипт листинга машин с vmware. Например:

bash esxi_list_vm.sh

Далее необходимо проверить файл vm_paths.txt. В нём расписаны имена вм и их диски. Пример содержимого файла представлен на рисунке.

Для экспорта выбранной вм запускается скрипт export_vm.sh. Например:

bash export_vm.sh test_vm1

Локально экспортированные ВМ сохраняются в $LOCAL_EXPORT_PATH, например /vms

После экспорта необходимо выполнить конвертацию в формат qcow2. Например:

bash convert_to_openstack.sh /vms/test_vm1/ vm1.qcow2

Получившийся образ диска qcow2 можно использовать в glance openstack. Можно добавить образ через webui:

Можно добавить через CLI:

source admin-openrc
openstack image create --file test_vm1.qcow2 --disk-format qcow2 --container-format bare -- public test_vm1

Приложения - Содержимое скриптов и конфигурационного файла

Convert_to_openstack.sh

#!/bin/bash

# Папка с экспортированной ВМ (после копирования с ESXi)
VM_DIR="$1"
# Имя итогового qcow2 без пути (например, myvm.qcow2)
QC0W2_NAME="$2"

if [[ -z "$VM_DIR" || -z "$QC0W2_NAME" ]]; then
     echo "Использование: $0 /путь/к/именно_к_папке_экспорт_вм myvm.qcow2"
     exit 1
fi

# Поиск основного дескриптора .vmdk (ИГНОРИРУЕМ -f lat.vmdk!)
VMDK_FILE=$(find "$VM_DIR" -maxdepth 1 -type f -name '*.vmdk' ! -name '*- flat.vmdk' ! -name '*-delta.vmdk' | head -n 1)

if [[ ! -f "$VMDK_FILE" ]]; then
    echo "X VMDK дескриптор не найден в $VM_DIR"
    exit 2
fi
echo "Найден VMDK дескриптор: $VMDK_FILE"

# Папка с финальным образом
OUTPUT_DIR=$(pwd)

echo "Конвертация $VMDK_FILE → $OUTPUT_DIR/$QC0W2_NAME ..."
qemu-img convert -p -0 qcow2 "$VMDK_FILE" "$OUTPUT_DIR/$QC0W2_NAME"
if [ $? -eq 0 ]; then
    echo " Готово: $OUTPUT_DIR/$QC0W2_NAME"
else
    echo " Ошибка конвертации!"
    exit 3
fi

# (опционально) проверить образ
echo "Проверка итогового образа:"
qemu-img info "$OUTPUT_DIR/$QC0W2_NAME"

esxi_list_vm.sh

#!/bin/bash

CONFIG_FILE="export_config.conf"
OUTFILE="vm_paths.txt"
log() { echo "[$(date '+%Y-%m-%d %H:%M:%S')] $1"; }
source "$CONFIG_FILE"

echo "VM_NAME;VM_ID;VMX_PATH;VMKD_PATH" > "SOUTFILE"

log "Получаем список ВМ:"
VM_LIST=$(sshpass -p "$ESXI_PASSWORD" ssh -o StrictHostKeyChecking=no
"$ESXI_USER@$ESXI_HOST" "vim-cmd vmsvc/getallvms | tail -n+2")

IFS=$'\n'
for line in $VM_LIST; do
    log "Исходная строка: |$line|"
    # Разбиваем на поля
    VM_ID=$(echo "$line" | awk '{print $1}')
    # VM_NAME - всё до первого файла с квадратными скобками
    VM_NAME=$(echo "$line" | awk '{print $2}')
    # VMX_PATH - первый вхождение [...] ...\vmx
    VMX_PATH=$(echo "$line" | grep -oE '\[[^\]]+\) [^ ]+\.vmx')
    if [[ -z "$VMX_PATH" ]]; then
        log "Δ VMX_PATH не найден в строке, пропуск."
        continue
    fi

    log "VM_ID: $VM_ID"
    log "VM_NAME: $VM_NAME"
    log "VMX_PATH: $VMX_PATH"

    # STORE и DIR
    STORE_NAME=$(echo "$VMX_PATH" | grep -oE '^[^\]]+\) | tr -d '[]')
    VM_PATH_ONLY=$(echo "$VMX_PATH" | sed -E 's/^\[[^\]]+\) ?//')
    VM_DIR=$(dirname "$VM_PATH_ONLY")
    VMKD_DIR="/vmfs/volumes/$STORE_NAME/$VM_DIR"

    log "STORE_NAME: $STORE_NAME"
    log "VM_DIR: $VM_DIR"
    log "Путь поиска VMKD: $VMKD_DIR"

    # Получить основной дескриптор vmdk (одно или несколько, без flat/delta)
    VMKD_PATH=$(sshpass -p "$ESXI_PASSWORD" ssh -o StrictHostKeyChecking=no  "$ESXI_USER@$ESXI_HOST" \
        "ls \"$VMKD_DIR\"/*.vmdk 2>/dev/null | grep -v - - '-flat.vmdk' | grep  -v - - ' -delta.vmdk' | grep -v - - '.sesparse.vmdk' | xargs -n 1 basename | awk  -v s=\"$STORE_NAME\" -v d=\"$VM_DIR\" ' {printf(\"[%s] %s/%s,\",s,d,\$0)}' " | sed 's/,$//'')
    log "Найденные VMKD_PATH: $VMKD_PATH"

    echo "$VM_NAME;$VM_ID;$VMX_PATH;$VMKD_PATH" >> "$OUTFILE"
done
log "Готово! cat $OUTFILE"

export_vm.sh

#!/bin/bash
CONFIG_FILE="export_config.conf"
VM_NAME="$1"

log() {
    echo "[$(date '+%Y-%m-%d %H:%M:%S')] $1"
}

if [ -z "$VM_NAME" ]; then
    log "X Не указано имя ВМ! Пример запуска: ./export_vm_full_dir.sh  <vmname>"
    exit 1
fi

if [ ! -f "$CONFIG_FILE" ]; then
    log "X Нет файла конфигурации $CONFIG_FILE!"
    exit 2
fi

source "$CONFIG_FILE"

if [ -z "$LOCAL_EXPORT_PATH" ]; then
    log "X В конфиге не задана переменная LOCAL_EXPORT_PATH!"
    exit 3
fi

if [ -z "$STORAGE_NAME" ]; then
    log "X В конфиге не задан storage (STORAGE_NAME)!"
    exit 4
fi

# 1. Определить vmsvcid по имени ВМ
log "Получаем список ВМ для поиска ID нужной машины..."

VMID=$(sshpass -p "$ESXI_PASSWORD" ssh -o StrictHostKeyChecking=no
"$ESXI_USER@$ESXI_HOST" "vim-cmd vmsvc/getallvms | grep -w '$VM_NAME' | awk
'{print \$1}'")

if [ -z "$VMID" ]; then
    log "X Не могу найти ВМ '${VM_NAME}' на ESXi!"
    exit 5
fi

log "ID вашей ВМ: $VMID"

# 2. Проверить статус питания, выключить если включена
POWER_STATE=$(sshpass -p "$ESXI_PASSWORD" ssh -o StrictHostKeyChecking=no "$ESXI_USER@$ESXI_HOST" "vim-cmd vmsvc/power.getstate $VMID | tail -1}")

if [ [ "$POWER_STATE" =~ "Powered on" ]]; then
     log "ВМ ${VM_NAME сейчас включена. Отключаем..."
     sshpass -p "$ESXI_PASSWORD" ssh -o StrictHostKeyChecking=no "$ESXI_USER@$ESXI_HOST" "vim-cmd vmsvc/power.off $VMID"
     # Ждем выключения — цикл ожидания (по 3 сек, не более 60 раз: 3*60=180  секунд максимальное ожидание)
     COUNT=0
     while true; do
         SLEEP_TIME=3
         sleep $SLEEP_TIME
         CUR_STATE=$(sshpass -p "$ESXI_PASSWORD" ssh -o  StrictHostKeyChecking=no "$ESXI_USER@$ESXI_HOST" "vim-cmd vmsvc/power.getstate  $VMID | tail -1")
         log "Текущее состояние питания: $CUR_STATE"
         if [[ "$CUR_STATE" =~ "Powered off" ]]; then
             log "ВМ успешно выключена!"
             break
         fi
         ((COUNT++))
         if [[ $COUNT -ge 60 ]]; then
             log "Х Превышено максимальное ожидание выключения ВМ. Прерываем  экспорт."
             exit 10
         fi
     done
else
     log "ВМ уже выключена."
fi

# 3. Копирование всей папки vm через tar
REMOTE_VM_DIR="/vmfs/volumes/${STORAGE_NAME}/${VM_NAME}"
LOCAL_DIR="${LOCAL_EXPORT_PATH}"
mkdir -p "${LOCAL_DIR}"

log "Экспорт всей папки ВМ: $REMOTE_VM_DIR → ${LOCAL_DIR}"

# Архивируем и копируем всю папку
sshpass -p "$ESXI_PASSWORD" ssh -o StrictHostKeyChecking=no  "$ESXI_USER@$ESXI_HOST" \
    "cd /vmfs/volumes/${STORAGE_NAME} && tar cf - '${VM_NAME}' " | \
    (cd "${LOCAL_DIR}" && tar xf -)

RESULT=$?
if [[ $RESULT -eq 0 ]]; then
    log "☑ Папка ВМ экспортирована: ${LOCAL_DIR/$VM_NAME}"
else
    log "☑ Ошибка экспорта! Код: $RESULT"
fi

export_config.conf

# export_config.conf

###########################################################
# ESXi сервер для экспорта ВМ
###########################################################
# IP-адрес или DNS-имя ESXi-хоста
ESXI_HOST="10.40.22.124"

# Имя пользователя на ESXi (обычно root)
ESXI_USER="root"

# Пароль от пользователя ESXi
ESXI_PASSWORD="Pa$$w0rD!!!"

# Тип экспорта: local или remote
EXPORT_TYPE="local"

# Каталог для локального экспорта
LOCAL_EXPORT_PATH="/vms"

# Имя сгорадка, как оно отображается в квадратных скобках (например, [datastore1])
STORAGE_NAME="datastore1"

# Настройки для удалённого экспорта
REMOTE_HOST="10.0.0.5"
REMOTE_USER="backup"
REMOTE_PASSWORD="remote_password"
REMOTE_PATH="/data/vm_exports"

6.11. Централизация управления

6.11.1. Общая информация

Управление облаком является обязательным условием при увеличении его размера. Также это является важной задачей в мультиоблачных конфигурациях, когда обеспечить онлайн синхронизацию между ЦОДами становится невозможным. Чтобы обеспечить автоматизацию операций необходимо иметь доступ к информации от каждой из систем (в том числе распределенных) и иметь возможность применять управляющие воздействия. Инструментом автоматизации облаков наряду с контроллером управления самим облаком является АА, автоматизирующий сервисную инфраструктуру. В ряде случаев управление каждым из облаков мультиклауда (многорегионального облака) в виде отдельных сущностей становится более предпочтительным вариантом, поскольку снижает «цену ошибки» и делает облака более устойчивыми и автономными. В таком случае размещение АА должно привязываться к соответствующим локациям. При этом управление облаком должно оставаться скоординированным и выполняться из единого центра для исключения разнонаправленных шагов и эффективного использования знаний высоко квалифицированных специалистов. К сожалению, AccentOS и OpenStack используют для реализации того или иного функционала полноценной облачной инфраструктуры ПО разных вендоров, что приводит к необходимости размещения консолей управления в едином многооконном WEB интерфейсе (Vivaldi). Решение о группировке консолей управления от разных облаков делает Заказчик. В частности,

вариант группировки консолей управления по функциональному принципу. Например, можно сгруппировать в одной консоли управления все системы мониторинга Zabbix от всех облаков (площадок)
вариант группировки консолей управления по географическому принципу. В одной консоли управления объединяются все системы одного облака (площадки)
вариант группировки нескольких логически связанных консолей управления с точки зрения какой-то высокоуровневой задачи Заказчика
иерархическая группировка

Автоматизация может относиться к разовым операциям (например, раскатка облака) и к периодическим операциям, выполняемым по расписанию. В AccentOS для автоматизации разовых операций, могут быть использованы такие инструменты как Heat и Ansible В AccentOS для автоматизации периодических операций наряду с утилитой cron из состава Linux, которая как правило выполняет действия в пределах отдельного хоста, может использоваться специальный модуль планировщик Scheduler. Описание модуля приведено в документации Наряду с заложенными операциями автоматизации, Scheduler может выполнять произвольные задачи.

6.11.2. Требуемые ресурсы

Для установки и работы модуля Scheduler требуется наличие настроенных, функционирующих и доступных компонентов:

Система на платформе OpenStack Antelope;
Python версии 3.7 и выше;
SQL база данных, например, MySQL;
Брокер сообщений RabbitMQ и очередь заданий Celery;
Система управления пакетами - pip3.

6.11.3. Установка

Установка AccentOS Scheduler выполняется в процессе установки облачных модулей AccentOS с помощью Kolla Ansible и затем автоматически настраивается на взаимодействие с другими модулями.

Также Администратор может выполнить ручную установку и настройку согласно инструкции по ссылке

http://docs.tnxholding.com/2.4.2/ru/modules/scheduler/installSettings.html

6.11.4. Консоль управления

Для выполнения настройки преднастроенной или произвольной операции Администратор должен выполнить следующие действия из консоли управления AccentOS.

6.11.5. Тестирование работоспособности

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

http://docs.tnxholding.com/2.4.2/ru/modules/scheduler/modules_tasks.html

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

Запустить curl-запрос. Он обеспечивает возможность запуска HTTP запроса. В теле и адресе запроса возможно использовать шаблоны {object_id} - для автоподстановки ID объекта, над которым выполняется задача и {tenant_id} или {project_id} - для ID проекта, в котором выполняется задача.

6.11.6. Резервное копирование и восстановление

Резервное копирование и восстановление производится в рамках данной процедуры по ссылке http://docs.tnxholding.com/2.4.2/ru/modules/scheduler/installSettings.html#recovery-plan-for-scheduler

6.11.7. Документация по эксплуатации

Документация по эксплуатации приведена по ссылке http://docs.tnxholding.com/2.4.2/ru/modules/scheduler/index.html

6.10. Система автоматического восстановления OpenStack (Vitality)

Назначение: Автоматизация обнаружения деградации сервисов OpenStack и их оперативное восстановление без участия человека (Self-Healing).

Набор систем диагностики (Observability Stack) Система агрегирует метрики, логи и результаты синтетического тестирования для формирования полной картины «здоровья» облака: • TOS-Tempest: Проведение регулярных API и интеграционных тестов OpenStack. Главный триггер для выявления функциональной деградации. • Zabbix: Мониторинг инфраструктурного уровня (нагрузка на CPU/RAM/Диски нод, статус системных служб systemd, доступность портов). • OpenSearch: Сбор, индексация и анализ логов компонентов OpenStack (Nova, Neutron, Keystone и др.) для поиска аномалий и стктрейсов ошибок.

TOS-Selenium: Эмуляция действий пользователя в UI-панели (Horizon). Обнаружение проблем с фронтендом и доступностью консоли. Оркестратор диагностики (Дополнительный компонент): Prometheus + Alertmanager (или внутренний кастомный демон-контроллер), который собирает результаты из всех систем, сопоставляет их (корреляция событий) и принимает решение о наличии деградации.

## Набор систем для восстановления (Automation Stack)

Kolla Ansible: Выступает в качестве главного исполнительного механизма. Поскольку сервисы OpenStack развернуты в Docker/Podman контейнерах, Kolla Ansible позволяет точечно и безопасно перезапускать, переконфигурировать или обновлять конкретные компоненты (например, выполнение kolla-ansible -i hosts restart -v nova).

## Методика взаимодействия с системами (Workflow)

Взаимодействие строится по классическому замкнутому циклу MAPE-K (Monitor- Analyze-Plan-Execute):

Сбор данных (Monitor): Тесты Tempest и Selenium запускаются по расписанию (например, каждые 5-15 минут). Zabbix и OpenSearch шлют метрики и логи в реальном времени.
Анализ и Триггер (Analyze): При завершении критического теста с ошибкой (например, создание виртуальной машины в Tempest) система сверяет данные с Zabbix и OpenSearch, чтобы локализовать проблему (например, упал контейнер nova_compute на конкретном хосте).
Принятие решения (Plan): Система выбирает сценарий из матрицы реакций, начиная с простых перезапусков контейнеров/служб. Если это не помогает, эскалирует до уведомления администратора.
Исполнение (Execute): Система генерирует динамический inventory для Ansible и запускает плейбук Kolla Ansible через Ansible Runner (API) для восстановления упавшего сервиса.

## Интерфейс взаимодействия с пользователем (UI/UX)

Дашборд оператора (Web UI): Экран (можно реализовать как плагин к Grafana или Horizon, либо легковесное SPA на React/Vue), отображающий:

o Текущий статус здоровья сервисов (Зеленый/Желтый/Красный).

o Ленту событий автоматического восстановления (например: «14:02 Ошибка Tempest -> 14:03 Запуск Kolla Ansible (Restart nova-api) -> 14:05 Сервис восстановлен»).

o Кнопку переключения режима: «Автоматический» (система чинит сама) / «Ручной» (система только предлагает действие, админ подтверждает кликом).

Система уведомлений: Интеграция с Telegram/Rocket.Chat/Почтой через Alertmanager или Zabbix для мгновенного информирования команды эксплуатации о фактах деградации и проведенных работах.

## Ограничения и Стек:

Базовая ОС: РедОС 7.3/8 или Astra Linux Special Edition 1.7/1.8. Все компоненты мониторинга и управления адаптируются под требования безопасности и пакетную базу выбранной ОС.

Текущий стек технологий: Python (для связующих скриптов и интеграций), Ansible, Docker/Podman.

6.11. Система инвентаризации NetBox

6.11.1. Общая информация

6.11.2. Требуемые ресурсы

6.11.3. Установка

6.11.4. Тестирование работоспособности

6.11.5. Консоль управления

6.11.6. Мониторинг

6.11.7. Резервное копирование и восстановление

6.11.8. Документация по эксплуатации

6.12. Визуальное тестирование базовых функций системы

Тестирование работоспособности Тестирование функциональности проводится в Horizon. Сначала нужно залогиниться под пользователем admin ## Создание проекта Меню “Идентификация” — Кнопка “Проекты” — Кнопка “Создать проект” — Ввести имя в поле — Кнопка “Создать проект”

## Создание пользователя Меню “Идентификация” — Меню “Пользователи” — Кнопка “Создать пользователя” — Ввести данные в поля — Выбрать основной проект — Назначить роль в основном проекте — Кнопка “Создать пользователя” Загрузка образа Меню “Проект” — Меню “Вычислительные ресурсы” — Кнопка “Образы” — Кнопка “Создать образы” — Ввести имя образа — Загрузить образ — Выбрать формат (обычно QCOW2 или Raw) — При необходимости ввести минимальное количество CPU, RAM, Дискового пространства — Кнопка “Создать образ”

## Создание провайдерской сети Меню “Администратор” — Меню “Сетевые ресурсы” — Кнопка “Сети” — Кнопка “Создать сеть” — Ввести имя сети — Выбрать проект — Выбрать тип сети провайдера “VLAN” — Ввести имя физического интерфейса (обычно physnet1) — Ввести ID сегментации — Поставить галочку “Внешняя сеть” — Перейти на страницу “Подсеть” — Ввести имя подсети, сетевой адрес и адрес шлюза — Перейти на страницу “Детали подсети” — Кнопка “Создать сеть”

## Создание оверлейной сети Меню “Администратор” — Меню “Сетевые ресурсы” — Кнопка “Сети” — Кнопка “Создать сеть” — Ввести имя сети — Выбрать проект — Выбрать тип сети провайдера “VXLAN” — Ввести ID сегментации — Перейти на страницу “Подсеть” — Ввести имя подсети, сетевой адрес и адрес шлюза — Перейти на страницу “Детали подсети” — Кнопка “Создать сеть” Подключение оверлейной сети к провайдерской сети для выхода в интернет Меню “Администратор” — Меню “Сетевые ресурсы” — Кнопка “Маршрутизатор” — Кнопка “Создать маршрутизатор” — Выбрать проект — Выбрать внешнюю сеть (провайдерская сеть из предыдущего пункта) — Кнопка “Создать маршрутизатор” — Выбрать маршрутизатор (нажать на него) в списке — Страница “Интерфейсы” — Кнопка “Создать интерфейс” — Выбрать оверлейную подсеть — Ввести адрес шлюза — Кнопка “Отправить”

## Создание флейворов Меню “Администратор” — Меню “Вычислительные ресурсы” — Кнопка “Типы инстансов” — Кнопка “Создать тип инстансов” — Ввести данные — Кнопка “Создать тип инстансов”

## Создание ВМ Меню “Проект” — Меню “Вычислительные ресурсы” — Кнопка “Виртуальные машины” — Кнопка “Запустить машину” — Страница “Источник” — Выбрать источник — Страница “Тип машины” — Выбрать тип инстанса — Страница “Сети” — Выбрать оверлейную сеть — Кнопка “Запустить виртуальную машину” Проверка сети (пинг адреса вне сети) Зайти на ВМ (SSH или через встроенный VNC/консоль), залогиниться и запустить ping 8.8.8.8 Проверка связи (пинг ВМ между собой) Зайти на ВМ (SSH или через встроенный VNC/консоль), залогиниться и запустить ping с адресом другой ВМ в облаке