Обновление платформы виртуализации часто планируют как небольшую аварию: назначают ночное окно, предупреждают пользователей и надеются к утру вернуть всё в рабочее состояние. Для инфраструктуры, на которой держатся приложения и рабочие места, это слишком высокая цена за обычную эксплуатационную задачу. Стоит стремиться к другому сценарию: службы обновляются по очереди, виртуальные машины продолжают работать, а при ошибке платформа сама возвращается в рабочее состояние. Администратору остаётся устранить причину и повторить попытку.
Такое поведение нужно закладывать в архитектуру. Микросервисы позволяют уменьшить масштаб изменений, проверки и автоматический откат ограничивают последствия ошибки. За результат отвечают и разработчик платформы, и тот, кто её эксплуатирует.
Обновлять службы по отдельности
Если любое изменение требует обновить платформу целиком, даже небольшое исправление затрагивает компоненты, которые исправно работают. Возникает желание отложить обновление. Исправления копятся, разрыв между версиями растёт, и следующий переход становится ещё сложнее.
Микросервисная архитектура помогает разорвать этот круг. Консоль управления, планировщик, брокер подключений, агенты на узлах выполняют разные задачи. Если их жизненные циклы разделены, можно обновить конкретную службу и проверить результат, прежде чем переходить к следующей. Чем меньше компонентов меняется одновременно, тем проще найти причину ошибки.
Но одного деления на микросервисы мало. Вендор должен обеспечить совместимость компонентов на время перехода и возврат к предыдущей версии. Особенно чувствительны изменения конфигурации и базы данных: новая служба не должна лишать старую возможности продолжить работу после отката. Разбирать эти зависимости во время обновления администратор не должен.
Обновление по службам сочетается с обновлением по узлам. Сначала меняется ограниченная часть кластера, затем система проверяет её состояние и продолжает. Работа на разных версиях должна быть предусмотрена разработчиком. Возможность безопасно остановиться между шагами здесь важнее скорости установки.
Что происходит с работающими машинами
Для пользователя главный вопрос прост: продолжит ли работать приложение? Ответ зависит от того, какой компонент обновляется и участвует ли он в выполнении уже запущенной виртуальной машины.
При разделении управления кластером и выполнения ВМ перезапуск управляющей службы не останавливает гостевую операционную систему. На время могут стать недоступны создание машины или изменение её параметров. Доступность новых подключений тоже нужно проверять отдельно: она может зависеть от обновляемого шлюза.
Некоторые компоненты можно обновить, сохранив для работающих ВМ прежние процессы. Новая версия начнёт использоваться при новом запуске процесса машины; обычной перезагрузки гостевой ОС для этого может быть недостаточно. Пользователь продолжает сессию, а администратор видит, что обновление установлено, но ещё не применено ко всей нагрузке.
Сеть, хранилище и ядро требуют отдельного подхода. Если перезапуск компонента разрывает путь к дискам или останавливает ВМ, наличие микросервисов не спасёт. Перед обновлением узла может потребоваться живая миграция машин на соседние серверы. Для неё нужны совместимые узлы, доступные данные и запас ресурсов; допустимость краткой паузы при переключении зависит от приложения. Если безопасный перенос невозможен, нужен согласованный перерыв.
Сначала подготовка и проверка
Большую часть работы можно выполнить до переключения версий: доставить и распаковать пакет, проверить целостность, совместимость и доступное место. Затем убедиться, что серверы отвечают, кластер работоспособен, а текущие операции не конфликтуют с обновлением.
Пробный прогон сокращает риск, но не гарантирует, что через минуту не пропадёт связь. Он дополняет защиту во время обновления. Если проблема найдена заранее, система сохраняет текущую версию и объясняет, что мешает начать.
Администратору важно видеть, какие службы уже переключены, какой сервер обрабатывается и где возникла ошибка. При остановке должно быть понятно, можно ли продолжить после устранения причины. Сообщение «задача завершилась неуспешно» без этой информации оставляет основную работу человеку.
Если сервер перестал отвечать
Если сервер перестал отвечать, возможно, отказало оборудование. А возможно, оборвалась только связь с управлением, и виртуальные машины продолжают работать. Обновлять остальные узлы без проверки опасно: проблема может распространиться, а состояние кластера станет ещё труднее определить.
Платформа должна обнаружить потерю связи, остановить дальнейшие изменения и запустить предусмотренный для этого сценария откат. Его задача — вернуть службы и конфигурацию в согласованное рабочее состояние. Для этого нужны журнал действий и проверенные способы их отмены. Некоторые изменения нельзя обратить установкой старого пакета; такие ограничения обязан учитывать разработчик.
Команда отката не может немедленно исполниться на выключенном или полностью недоступном сервере. Система должна обработать доступную часть кластера и показать, где возврат подтверждён, а где нужно восстановить связь или вмешаться вручную. Статус «откат завершён» требует проверки результата.
Откат относится к изменениям платформы. Он не возвращает гостевые диски в прошлое и не отменяет операции приложений. Резервное копирование остаётся необходимым. Сам процесс обновления управляющих служб нужно строить так, чтобы он не требовал возврата пользовательских данных.
Как откат сработал на демонстрации
Во время демонстрации на одном мероприятии произошёл сбой, который хорошо показал работу отката. На стенде запустили обновление серверного компонента: выбрали пакет, создали задачу, прошли подготовку и пробный прогон. Во время переключения один из серверов перестал отвечать по сети.
Платформа остановила задачу и автоматически запустила возврат. Изменения были отменены, система осталась на прежней версии. Виртуальные машины продолжали работать, кластер сохранил работоспособность, доступ к хранилищу не прервался. Консоль показала ошибку и проблемный сервер. Оставалось проверить сеть и повторить обновление.
Слушателей интересовало, что увидит пользователь. В этом сценарии его сессия продолжалась: обновляемые компоненты не требовали остановки машин, а изменения, связанные с их новым запуском, могли подождать.
Успешная установка на подготовленном стенде ещё мало говорит о восстановлении. Здесь ошибка возникла на глазах у аудитории, и стало видно, какую часть работы система берёт на себя и что остаётся администратору.
Когда автоматического возврата недостаточно
В практике встречались обновления, которые не применялись на отдельных аппаратных конфигурациях. Платформа откатывала изменения, работа продолжалась на прежней версии. Затем выходил патч, учитывающий особенности оборудования, и повторное обновление проходило успешно. Именно такой цикл и нужен администратору: сохранить рабочую среду, получить исправление и продолжить.
Границу возможностей автоматики разберём на условном примере. Во время обновления отказал системный диск, узел больше не загружается, штатный механизм возврата на нём запустить невозможно. Сначала потребуется восстановить оборудование и загрузку сервера, затем вернуть узел в согласованное с кластером состояние. Сам откат физическую неисправность не устранит.
Для подобных ситуаций нужны актуальная копия конфигурации и управляющих компонентов, проверенная инструкция ручного восстановления. Вендор обязан описать процедуру, обеспечить диагностику и помочь её пройти. Администратору должно быть понятно, какие действия безопасны, чтобы не перезапускать службы наугад в надежде вернуть кластер к жизни.
Как разделить ответственность
Разработчик отвечает за поведение продукта: какие изменения применяются отдельно, как проверяется совместимость, что произойдёт при потере связи и как вернётся работоспособность. Если ошибка возникла в поддерживаемом сценарии, заказчик не должен восстанавливать систему в одиночку. Вендор должен предусмотреть автоматический возврат, а за его пределами обеспечить процедуру восстановления и инженерную помощь. Тогда администратор сможет устранить исходную проблему и продолжить обновление.
Пользователь отвечает за условия эксплуатации: поддерживаемую конфигурацию, исправную сеть и хранилище, резервные копии, свободные ресурсы и соблюдение порядка обновления. Начинать стоит со стенда с нагрузкой, похожей на рабочую, затем переходить к ограниченной части производственной среды. Расширять обновление можно после проверки результата. Запас мощности для миграции нужен до начала работ.
Если исправление безопасности требует нового запуска ВМ или перезапуска узла, отсрочка может сохранять уязвимость. Срок применения нужно выбирать с учётом риска, согласовывать с владельцами приложений и заранее сообщать пользователям. Установленный пакет ещё не означает, что защита уже действует.
У поставщика стоит просить показать весь процесс: подготовку, переключение службы, потерю связи с узлом и восстановление. Проверить, что происходит с приложениями, что видно в консоли и что потребуется от администратора. Это делает границы ответственности конкретными до первой нештатной ситуации.
Для критичной инфраструктуры обновление без прерывания сервиса должно стать требованием к архитектуре и эксплуатации. Микросервисы позволяют менять платформу небольшими частями, автоматический откат возвращает её в рабочее состояние при предусмотренных сбоях. А согласованные процедуры и участие вендора помогают сохранить контроль там, где автоматика закончилась.
