x2openeuler. Часть 2: обновление ОС
x2openeuler upgrade: Технология миграции операционных систем без переустановки
Это наша вторая статья по использованию инструмента x2openeuler. В прошлой версии мы установили и настроили x2openeuler. Если вы не читали, то можете ознакомится со статьёй по ссылке.
Представьте на минуту, что вам нужно заменить двигатель у самолета, пока он летит. А именно эту задачу мы будем сегодня решать 🙂
Функция upgrade в инструменте x2openeuler представляет собой технологию миграции операционной системы (in-place upgrade). Она предназначена для преобразования существующей инсталляции устаревшего дистрибутива (к примеру, как CentOS версии 7 или 8), в актуальную версию openEuler без необходимости полной переустановки и ручного переноса данных.
Данная процедура критически важна для эксплуатации серверного оборудования, где требуется обеспечить непрерывность работы служб и сохранить сложившуюся программную среду. Ручная миграция подобного уровня сопряжена с высокими трудозатратами и рисками, которые инструмент x2openeuler призван минимизировать. Да, миграция «на месте» (in-place) всегда считалась уделом отчаянных смельчаков. Слишком много переменных: пакеты, зависимости, конфигурационные файлы, которые могут рассыпаться как карточный домик. x2openeuler, со своей функцией upgrade, пытается привнести в этот хаос элемент предсказуемости и, представьте себе, даже комфорта.
Перед началом миграции инструмент выполняет глубокую предварительную диагностику. Он идентифицирует установленные пакеты, анализирует их зависимости и конфигурации, выявляя потенциальные конфликты и проблемы совместимости с репозиториями openEuler.
При этом надо учесть, что самое сложное в миграции – это не ядро, а пользовательское пространство. Ваш любимый “nginx”, “postgresql” и даже кастомные скрипты, написанные в далеком 2016-м. Upgrade-функция содержит мощный механизм сопоставления и преобразования пакетов. Инструмент управляет заменой пакетов, обновлением их версий и разрешением зависимостей, используя официальные репозитории новой платформы. Он знает, что пакет “super-server” из CentOS должен превратиться в “hyper-server” в openEuler, а зависимости подтянуть уже из репозиториев новой ОС.
Алгоритмы функции стремятся сохранить модифицированные конфигурационные файлы основных системных служб. При необходимости они адаптируются под особенности openEuler. Однако актуальность резервных копий перед началом процесса остается обязательным требованием.
Процесс разделен на строгие этапы: проверка, подготовка, загрузка пакетов, выполнение замены и пост-настройка. Такая структура обеспечивает прозрачность, позволяет отслеживать прогресс и упрощает диагностику в случае возникновения сложностей.
Инструмент автоматически обновляет конфигурацию загрузчика GRUB для корректной инициализации ядра openEuler после первой перезагрузки мигрированной системы.
Функция upgrade оптимизирована для работы со стандартными инсталляциями, где управление пакетами осуществлялось исключительно через штатный менеджер (yum, dnf). Наиболее стабильные результаты достигаются на системах без глубоких модификаций ядра или системных библиотек.
«А если что-то пойдет не так?» – спросит параноик опытный системный администратор. И будет прав. Инструмент старается быть осторожным и предоставляет логи, много логов. Все действия протоколируются. В идеале, если предварительная проверка прошла успешно, то и сам процесс должен завершиться победой. Но мир IT – место непредсказуемое, поэтому наличие этих логов – ваш главный козырь для разбора полетов.
Основным сценарием применения x2openeuler является массовая миграция виртуальных машин или физических серверов, развернутых на идентичных или близких по конфигурации образах. Это позволяет стандартизировать процесс и значительно сократить операционные издержки по сравнению с ручными методами.
Upgrade – сложнейшая процедура. Она не всесильна. Кастомные сборки ядер, глубоко модифицированные системные библиотеки, софт, установленный в обход менеджера пакетов (просто “make install” в “/usr/local”) – все это зона повышенного риска. Инструмент работает лучше всего со «стерильными», хорошо оформленными системами, где царит диктатура пакетного менеджера.
После успешного выполнения процедуры система становится полноценной частью экосистемы openEuler: получает поддержку, подключается к актуальным репозиториям и может использовать все преимущества дистрибутива, включая современные инструменты управления и актуальные обновления безопасности.
Таким образом, функция “upgrade” в x2openeuler — это специализированный инструмент для решения конкретной задачи планового перехода на новую платформу. Его использование требует тщательной подготовки, тестирования в изолированной среде и понимания принципов его работы, но при соблюдении этих условий он является эффективным средством для масштабируемой и управляемой миграции серверной инфраструктуры.
Тест №1. Миграция с Ubuntu 18.04 на openEuler 22.03 LTS SP4
Ну, от слов к делу, давайте попробуем протестировать миграцию узла под управлением устаревшей на данный момент Ubuntu 18.04 (более поздние версии ОС Ubuntu x2openeuler не поддерживает) на openEuler 22.03 LTS SP4. При этом на Ubuntu у нас развёрнут PGSQL сервер с созданной тестовой БД.
Давайте установим сервер pgsql на нашу ubuntu и создадим простенькую тестовую БД:
Рисунок 2.1.1 Установка pgsql
Рисунок 2.1.2 Создание тестовой БД
Теперь заходим в веб-интерфейс x2openeuler (как заходить — мы знаем из первой части нашей серии статей по x2openeuler) и создаём task типа «Upgrade»:
Рисунок 2.1.3 Создание задачи на Upgrade
Заполняем поля для подключения к обновляемому узлу по ssh:
Рисунок 2.1.4 Подключение к хосту по ssh
Выбираем «Source OS» как UBUNTU, а «target OS» как «openEuler 22.03 LTS SP4»
Рисунок 2.1.5 Целевая ОС
Нажимаем Select при выборе репозитория, выбираем слева «migrate-x86.repo» и нажимаем значок редактирования:
Рисунок 2.1.6 Используемые репозитории при обновлении
Соглашаемся с предупреждением:
Рисунок 2.1.7 Редактирование репозитория
Отредактируем файл репозитория следующим образом (изменим адрес на российское зеркало):
Рисунок 2.1.8 Редактирование репозитория openEuler
Нажимаем ОК, и проверяем, что репозиторий добавлен:
Рисунок 2.1.9 Добавлен репозиторий для обновления
Остальные поля мы не трогаем и можем нажимать OK:
Рисунок 2.1.10 Service Software
Нажимаем OK на окне, демонстрирующем fingerprint нашего хоста с ubuntu 18.04:
Рисунок 2.1.11 Подключение по ssh
Завершаем создание задачи, и нажимаем OK:
Рисунок 2.1.12 Завершение создания задачи
После создания задачи начинается проверка переменных среды:
Рисунок 2.1.13 Environment check
Мы можем нажать View details и увидеть подробности:
Рисунок 2.1.14 Подробности задачи
После завершения проверки переменных мы видим краткий отчёт, из которого мы видим главное — нет «красных» элементов, которые говорят о том, что что-то пошло не так. В колонке слева мы можем почерпнуть информацию по обновляемому серверу, которую x2openeuler получил уже сам при опросе этого хоста.
Рисунок 2.1.15 Пройден Environment check
Мы нажимаем «Start check» и запускаем проверку перед обновлением:
Рисунок 2.1.16 Проверка перед обновлением
После завершения проверки мы можем ознакомится с логом проверки:
Рисунок 2.1.17 Лог выполнения проверки
Пройдя по вкладкам увидеть (или, что лучше, не увидеть) обнаруженные конфликты и несовместимости при планируемом обновлении:
Рисунок 2.1.18 Отчёты о проверке
Если интересно, то мы можем увидеть каким конкретным пакетов из репозитория opeeuler будет заменён каждый пакет, установленный на наш сервер с ubuntu 18.04:
Рисунок 2.1.19 Список пакетов
Нажимаем кнопку «upgrade» и уходим пить чай (или кофе, кому что нравится), потому что обновление займёт довольно продолжительное время.
Рисунок 2.1.20 Запускаем upgrade
Следим за обновлением (попивая чай):
Рисунок 2.1.21 Процесс обновления
Когда x2openeuler сообщит, что «upgrade completed (pending restart)», то система попросит нажать кнопку «Restart node». Но, пока подождём её нажимать!
Рисунок 2.1.22 Ожидание перезагрузки
Давайте зайдём по ssh на наш обновляемый сервер и посмотрим, что на нём произошло.
Для начала, убеждаемся, что у наша ubuntu ещё пока никуда не делась:
Рисунок 2.1.23 ubuntu 18.04
Также, мы видим, что есть временное древо новой системы:
Рисунок 2.1.24 Временные файлы
А в конфиге загрузчика grub появились 2 записи:
Рисунок 2.1.25 Новые записи в GRUB2
То есть, мы видим, что обновления самой системы пока не произошло, а на лицо подготвка к действию, которое будет выполняться как раз при перезагрузке системы.
Вот теперь давайте выполним перезагрузку:
Рисунок 2.1.26 Перезагрузка
Так как у нас обновление тестируется в виртуальной машине, то нам удобно следить за всем происходящим непосредственно через консоль. И мы видим, что после перезагрузки в GRUB2 стоит по умолчанию для запуска пункт«upgrade»:
Рисунок 2.1.27 меню GRUB2
После запуска которого и начинается, собственно настоящий процесс обновления с ubuntu на openeuler:
Рисунок 2.1.28 Процесс обновления системы
Дождавшись окончания, мы увидим, что процесс обновления автоматически перезагружает сервер и в этот раз в меню GRUB2 уже стоит для загрузки по умолчанию пункт меню openeuler:
Рисунок 2.1.29 GRUB2: openEuler
И после загрузки мы видим в консоли уже приветствие от openEuler:
Рисунок 2.1.30 Первая загрузка openEuler
Теперь давайте зайдём по ssh на этот сервер и нас уже встретит не ubuntu, а openEuler 22.03 SP4:
Рисунок 2.1.31 Проверка версии openEuler
Давайте вернёмся в веб-интерфейс x2openeuler и посмотрим на отчёты по процедуре обновления:
Рисунок 2.1.32 Отчёты обновления
Запускаем проверку, которую следует выполнить после обновления. Для этого нажимаем «start check» и дожидаемся её окончания:
Рисунок 2.1.33. Завершение post-upgrade проверки.
И нам остаётся только удалить с системы все временные файлы, нажав на «clean up»:
Рисунок 2.1.34 Очистка временных файлов
Всё. Осталось только вспомнить, что у нас же там PostgreSQL работал, давайте проверим, что с ним. 🙂 Пакет postgresql, который в ubuntu содержит только changelog и copyright и, уже по зависимости тащит пакеты с серверной частью и утилитами, при обновлении сопоставился пакету postgresql из репозитория openEuler, включающим в себя только утилиты управления. А собственно серверный пакет postgresql-server в системе не обнаружен.
Рисунок 2.1.35 Пакет postgresql
Но даже установив его вручную всё равно пришлось бы вмешиваться для переноса каталога данных (/var/lib/postgresql/ в /var/lib/pgsql/data). Получается, что у нас операционная система обновилась безупречно, но обновление и перенос данных postgresql придётся выполнять вручную. Мы попробуем далее повторить этот опыт с centos8.
Тест №2. Миграция с CentOS8 на openEuler 24.03 LTS
Что же, теперь давайте проведём обновление с CentOS 8 до openEuler 24.03 LTS.
Пояснений и текста в этом тесте будет поменьше (по сути все пояснения тут дублируются от теста с ubuntu). Но где есть отличия — мы их обязательно укажем.
Наш сервер с CentOS:
Рисунок 2.2.1 версия CentOS
Для начала, надо сразу заметить, что postgresql у нас установлен и в нём создана тестовая БД:
Рисунок 2.2.2 тестовая БД
Мы также создаём задачу типа Upgrade в интерфейсе x2openeuler, но выбираем при заполнении тип «Source OS» как CentOS8, а «target OS» как «openEuler 24.03-LTS».
Рисунок 2.2.3 Создание задачи Upgrade
При этом, при выборе репозитория мы не выбираем существующий, а добавляем новый:
Рисунок 2.2.4 добавление репозитория
Создаём задачу:
Рисунок 2.2.5 Создание задачи
Дожидаемся окончания проверки переменных:
Рисунок 2.2.6 Проверка переменных
Запускаем и дожидаемся окончания проверки перед обновлением:
Рисунок 2.2.7 Проверка перед обновлением
Запускаем процесс upgrade:
Рисунок 2.2.8 Запуск процесса upgrade
Дожидаемся запроса на перезагрузку:
Рисунок 2.2.9 Запрос на перезагрузку
И также отправляем сервер на перезагрузку:
Рисунок 2.2.10 Процесс перезагрузки
В консоли виртуальной машины мы видим сам процесс обновления:
Рисунок 2.2.11 Процесс обновления в консоли виртуальной машины
После завершения обновления в интерфейсе x2openeuler мы читаем бравурные отчёты об успешном обновлении:
Рисунок 2.2.12 отчёт об обновлении
Выполняем проверки после обновления и выполняем чистку временных файлов:
Рисунок 2.2.13 Шаги после обновления
После завершения обновления мы заходим по ssh на наш сервер и видим там уже не CentOS, а openEuler:
Рисунок 2.2.14 openEuler
Проверяем, что у нас с postgresql. В этот раз всё гораздо лучше, но, как говорится, есть нюанс. Пакет с postgresql у нас сопоставился и обновился успешно, но стартовать он всё же не смог, так как на centos8 postgresql был версии 10, а в openEuler 24.03 postgresql уже 15. И, совершенно ожидаемо, что для такого большого скачка между версиями потребуется сделать нечто большее, чем просто стартовать БД.
Рисунок 2.2.15 версия postgresql
Итоговый вердикт.
Функция upgrade в x2openeuler – это не «серебряная пуля», решающая все миграционные проблемы одним щелчком. Это мощный, умный и, что важно, прагматичный инструмент. Он для тех, кто ценит время, предпочитает автоматизацию рутине и готов к небольшому, но управляемому риску ради большого скачка вперед. Он снимает с вас 80% рутинной технической работы, оставляя 20% на контроль, принятие решений и, конечно, создание и проверку бекапов.
Так стоит ли пробовать? Если ваша инфраструктура не состоит сплошь из уникальных и самописных артефактов – определенно да. Начните с тестового стенда, прочувствуйте процесс, изучите логи. А потом, с чувством выполненного долга наблюдайте как ваши старые серверы молодеют на глазах. x2openeuler upgrade – это ваш билет в мир openEuler, без билетной кассы и долгой очереди на посадку. Главное – пристегнуть резервные копии. Удачи в миграции!
