Запланировать короткий период технического обслуживания сложно, когда на сервере SLES работает сервис, ориентированный на клиентов. SUSE поддерживает онлайн-миграцию пакетов обновлений с SLES 15 SP5 на SP6, но обновленной машине все равно требуется перезагрузка; «онлайн» не означает отсутствие перезагрузки. Чтобы приложение оставалось доступным, обновляйте резервные узлы по одному или создайте замену SP6 и перенаправьте трафик на нее. Отдельный сервер не может поддерживать доступность своей собственной операционной системы во время перезагрузки.
Иллюстративный сценарий: вымышленная команда запускает веб-приложение на трех узлах SLES 15 SP5 за балансировщиком нагрузки. Приложение может обрабатывать запросы с двух других узлов, пока один узел обслуживается. Приведенная ниже последовательность показывает, как эта команда могла бы мигрировать кластер; это пример, а не утверждение о том, что было проведено тестирование или что каждый кластер может выдержать сбой узла.
Для перехода с SLES 15 SP5 на SP6 компания SUSE описывает как онлайн, так и офлайн методы обновления. Онлайн-метод использует миграцию с помощью YaST или zypper migrationво время работы операционной системы, после чего требуется перезагрузка системы. Изменения пакетов также могут привести к перезапуску служб, поэтому одной только онлайн-миграции недостаточно для гарантии непрерывности работы приложений.
Используйте процедуру поэтапного обновления SLE High Availability только в том случае, если ваша рабочая нагрузка уже защищена поддерживаемым и работоспособным кластером. Кластер должен сохранять кворум и достаточную мощность для работы службы при отключенном узле. Обычный балансировщик нагрузки без резервирования приложений или двухузловой кластер, теряющий кворум при остановке одного узла, недостаточны. Если сервер работает автономно, используйте параллельный хост SP6 и проверенное переключение рабочей нагрузки/данных для поддержания доступности; в противном случае запланируйте время простоя для его перезагрузки.
Перед началом работы с кластером проверьте исходный релиз, регистрацию, репозитории и поддерживаемые расширения. SUSE указывает SLES 15 SP5 в качестве поддерживаемого пути. Для онлайн-миграции требуется регистрация машины в SUSE Customer Center или на локальном сервере RMT; клиенты SUSE Manager должны использовать процедуру миграции клиента Manager, а не запускать ее zypper migrationнапрямую. Доступная целевая среда может зависеть от зарегистрированных продуктов и расширений.
Согласно информации о релизах SUSE, с 1 января 2026 года SLES 15 SP6 переведен на LTSS. Перед планированием этой миграции убедитесь, что ваша подписка и источник регистрации в настоящее время предоставляют доступ к целевому серверу SP6. Если такой возможности нет, не следует принудительно изменять репозиторий, чтобы имитировать поддерживаемую миграцию.
Создайте резервную копию данных и конфигурации приложения, используя поддерживаемый приложением метод, и убедитесь, что вы можете их восстановить. Ознакомьтесь с руководством по обновлению SLE HA и примечаниями к выпуску SP6 для ваших расширений, баз данных, хранилища и оборудования. В вымышленном кластере оператор также проверяет кворум, изоляцию, состояние репликации, резервную мощность, работоспособность балансировщика нагрузки и проверенный способ перенаправления трафика с каждого узла. Снимок может помочь в откате к поддерживаемым конфигурациям корневой файловой системы Btrfs, но он не заменяет резервные копии приложений или баз данных.
Для каждого узла следуйте процедуре поэтапного обновления SLE HA и руководству по эксплуатации вашего кластера. Никогда не обновляйте несколько узлов одновременно, если это явно не разрешено процедурой, специфичной для данного продукта.
sudo crm cluster stop
sudo zypper migrationВыбирайте SLES 15 SP6 только в том случае, если он указан как доступный целевой пакет. Ознакомьтесь с репозиторием и планом установки пакетов, особенно с пакетами, предлагаемыми для удаления или понижения версии, и остановитесь, если изменения неожиданны. Не принимайте план, который вы не проверили. Точный список пакетов зависит от установленного программного обеспечения и зарегистрированных расширений.
sudo reboot
sudo crm cluster start
sudo crm statusДождитесь, пока кластер сообщит о подключении узла и работоспособности ресурсов, затем восстановите его работоспособность в соответствии с вашим руководством по эксплуатации. Проверьте приложение извне кластера. Только после этого повторите процесс для следующего узла. SUSE разрешает использование смешанных версий только в течение короткого периода во время поэтапного обновления и рекомендует администраторам завершить обновление кластера в течение одной недели.
После обновления всех узлов подтвердите их выпуск с помощью команды `git release` cat /etc/os-release, проверьте состояние кластера с помощью команды `git checkout` crm statusи проверьте неисправные модули systemd с помощью команды ` systemctl --failedgit checkout`. Затем протестируйте само приложение через его обычный адрес, обращенный к клиентам, включая проверки работоспособности, доступ к базе данных или хранилищу, а также любые запланированные задания, важные для пользователей. Просмотрите журналы миграции и убедитесь, что ожидаемые репозитории и расширения активны на каждом узле.
Успешная миграция ОС не доказывает совместимость всех зависимостей приложения или отсутствие прерываний запросов. Если приложение не может выдержать отказ узла, используйте сине-зеленое развертывание с проверенной репликацией данных и контролируемым переключением конечной точки или запланируйте окно технического обслуживания. Для получения точных параметров команд и условий поддержки обратитесь к онлайн-руководству по обновлению SUSE SLES 15 SP6 , поддерживаемым путям обновления , процедуре поэтапного обновления SLE HA и примечаниям к выпуску SUSE Multi-Linux Manager 5.1 для перехода на SP6.
Настройте правильный путь для установки патчей в режиме реального времени для SLES 16.0 или 15 SP7, примените подходящие исправления ядра и подтвердите, какие обновления активны, не путая их с обновлениями ядра, требующими перезагрузки.
SLES 15 SP5 можно перенести в онлайн-режиме на SP6, но для этого потребуется перезагрузка каждого узла. Используйте проверенное поэтапное обновление или переключение по принципу «сине-зеленого перехода», чтобы обеспечить доступность рабочих нагрузок.
Создайте, уточните и проверьте профиль AppArmor с минимальными привилегиями в SLES 15 SP7, с четким указанием на настройки SELinux по умолчанию в SLES 16.
Используйте поддерживаемый SUSE профиль STIG для сканирования SLES 15, тестирования исправлений, анализа оставшихся проблем и сохранения результатов оценки.
Отследите сбой подключения к Cockpit через DNS, порт 9090, сокет systemd, firewalld, TLS и параметры входа в систему, используя текущие рекомендации SUSE.
Создайте резервное Ethernet-соединение на SLES 15 с помощью YaST и Wicked, настройте активное резервирование и проверьте работу обоих портов и переключение на резервный канал.
Превратите существующую систему SLES 15 в проверенный профиль AutoYaST, проверьте его и используйте для развертывания тестового сервера с меньшим количеством ручных операций.
Установите инструменты SLES 15 KVM и libvirt, включите нужную службу хоста и настройте выбранные виртуальные машины для запуска после перезагрузки.
Используйте задания systemd и журнал предыдущей загрузки, чтобы найти медленно работающую службу, точку монтирования или зависимость хранилища, а затем устраните проблему, не скрывая причину.
Используйте firewall-cmd для проверки активной зоны, безопасного разрешения HTTP-трафика, сохранения доступа по SSH и проверки того, что правило сохраняется после перезагрузки в SLES 15.
