x2openeuler. Часть 3: Сбор и оценка информации о системе

/ /

«Сбор и оценка информации о системе» в x2openEuler: ваш первый шаг к миграции

x2openEuler — это специализированный инструмент, разработанный для облегчения и автоматизации процесса миграции операционных систем на openEuler. О нём у нас уже вышли 2 статьи: часть1 (про установку) и часть2 (обновление ОС).

Одним из ключевых и наиболее важных этапов любой миграции является предварительный аудит существующей системы. В x2openEuler эту задачу выполняет модуль «System Information Collection and Assessment» (Сбор и оценка информации о системе).

Эта функция играет роль «разведчика», позволяя ИТ-специалистам заглянуть вглубь своей инфраструктуры и понять, насколько гладко пройдет переход, прежде чем будут предприняты какие-либо активные действия. В этой статье мы поверхностно рассмотрим, что представляет собой данный функционал, как он работает и в каких сценариях его применение наиболее эффективно.

Что такое «System Information Collection and Assessment»?

Это встроенный механизм x2openEuler, предназначенный для всестороннего анализа исходной системы (например, CentOS 6/7/8) перед ее миграцией на openEuler. Вместо того чтобы рисковать стабильностью рабочей среды, администратор может запустить эту функцию и получить подробный «инфослепок» системы.

С технической точки зрения, при запуске задачи x2openEuler подключается к целевому узлу по SSH и разворачивает на нем вспомогательный агент (’x2openEuler-client’). Этот агент выполняет сбор данных, а затем передает их обратно на сервер x2openEuler для анализа .

Что именно собирает и оценивает этот инструмент?

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

1. Оценка аппаратного обеспечения (Hardware Assessment): Инструмент проверяет, поддерживается ли текущее оборудование (серверы x86 или AArch64, а также платы расширения: RAID-контроллеры, сетевые карты, FC, IB, GPU, SSD, TPM) в списке совместимости openEuler. Это фундаментальный этап: если «железо» не поддерживается, миграция теряет смысл.

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

  • Конфигурация загрузчика: Анализируются файлы ’/boot/grub2/grub.cfg’ и ’/etc/default/grub’.

  • Параметры ядра: Оцениваются настройки из ’/etc/sysctl.conf’ и системные интерфейсы ’proc’ и ’sys’.

  • Монтирование дисков: Изучается файл ’/etc/fstab’.

  • Переменные окружения.

  • Сервисы, процессы и порты: Собирается информация о том, какие службы работают, какие сетевые порты открыты.

3. Оценка программного обеспечения (Software Assessment): Модуль сканирует установленные RPM-пакеты, а также приложения, установленные из исходных кодов (по указанным пользователем директориям). Он проверяет, существуют ли аналоги этих пакетов в репозиториях openEuler или совместимы ли текущие версии с новой ОС.

Где это можно использовать?

1. Инвентаризация и аудит перед EOL (End of Life): Компании, использующие CentOS 6 или 7, которые достигли конца жизненного цикла. Функция позволяет быстро провести инвентаризацию устаревших серверов и понять, какие из них можно мигрировать как есть, а какие требуют доработки или замены ПО.

2. Планирование ресурсов: Понимание того, какие RPM-пакеты не имеют аналогов в openEuler, позволяет оценить трудозатраты разработчиков на портирование или поиск замены еще до начала реальной миграции.

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

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

Практическое применение: Пошаговый сценарий

Давайте попробуем собрать данные с узла под управлением CentOS 8.2.

Но для интереса, мы установим на него из фирменного репозитория ps-80-release (https://repo.percona.com/ps-80/yum/release/) percona сервер:

Рисунок 3.1. Установленный percona сервер

Для того, чтобы выполнить оценку возможности миграции, мы уже привычно заходим в веб-интерфейс нашего x2openeuler и создаём задачу (task) «System Information Collection and Assessment»:

Рисунок 3.2. Выбор задачи

нажимаем «add node»

Рисунок 3.3. Добавление узла

Заполняем форму подключения к узлу по ssh. Выберем, что анализировать хост с CentOS8 мы будем для попытки миграции на openEuler 24.03-LTS SP1:

Рисунок 3.4. Заполнение полей подключения по ssh

Нажимаем кнопку «OK», просмотриваем отпечатки сервера и нажимаем «ОК»

Рисунок 3.5. Подключение к серверу

После добавления узла, нам надо завершить создание задачи нажатием ещё раз кнопки «ОК».

Рисунок 3.6. Завершение создания задачи

Начинается опрос хоста, сбор базовых сведений:

Рисунок 3.7. Начало выполнение задачи

Для получения подробностей по выполнению задачи, надо нажать на «View details»

Рисунок 3.8. Подробности по выполнению задачи

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

Рисунок 3.9. Завершение проверки переменных

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

Для начала анализа возможности миграции нажимаем «Start»:

Рисунок 3.10. Запуск анализа возможности миграции

Дожидаемся окончания анализа. И после этого мы можем посмотреть отчёты по возможности миграции хоста с CentOS8 на openEuler 24.03 LTS SP1.

Рисунок 3.11. Завершение анализа

На вкладке «Pre-upgrade Check Report» мы видим отчёт по завершению проверок, из которого мы узнаём, что у нас есть ошибка при загрузке ключа GPG из репозитория openEuler (причин для этого может быть много) и есть проваленная проверка по проверке свободного места на хосте для скачивания пакетов, необходимых при миграции с centos8 на openEuler 24.03 LTS SP1. Видимо, придётся докинуть свободного пространства.

На вкладке «Hardware Compatibility Assessment Report» мы можем ознакомиться с отчётом по совместимости «железа» при обновлении на openEuler 24.03 LTS SP1.

В нашем сервере установлен следующий SCSI контроллер:

Рисунок 3.12. SCSI контроллер

И при анализе возможности миграции, для нашего SCSI контроллера мы видим предупреждение «подлежит подтверждению». То есть полная совместимость при миграции не гарантируется и требуется проверка:

Рисунок 3.13. Hardware Compatibility Assessment Report

По программной части никаких конфликтов не обнаружено:

Рисунок 3.14. Software conflict Check Report

Если интересно, можем повернуть переключатель «Show only conflicts that affect the upgrade» и увидеть конфликты, которые не повлияют на процесс обновления.

Рисунок 3.15. Не критичные для миграции конфликты

Вспоминаем, что у нас на сервере есть установленный percona server. Прокручиваем отчёт на перечень «Removed packages» и с глубочайшим прискорбием обнаруживаем в его в списке пакетов, подлежащих безоговорочному удалению:

Рисунок 3.16. Удаляемые при миграции пакеты

Что же, придётся после миграции устанавалить percona server заново 🙂

Заключение

Функция «System Information Collection and Assessment» в x2openEuler — это не просто техническая опция, а полноценный инструмент управления рисками. Она превращает миграцию ОС из гадания («заработает — не заработает») в предсказуемый инженерный процесс. Собирая данные об оборудовании, конфигурациях и программном обеспечении, она дает администратору дорожную карту и позволяет заранее подготовиться к решению проблем, экономя время и нервы в день «X». Использование этого модуля — самый первый шаг для любого проекта по переходу на openEuler.