Как провести обновление прошивки серверов без простоя

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

Я считаю обещание «обновим весь парк без влияния» опасным, пока у команды нет численного бюджета недоступности и проверенного способа удалить один узел из каждого домена отказа. Хороший план не скрывает перезагрузки. Он превращает их в последовательность контролируемых отказов, которые сервис уже умеет переносить.

Без отказоустойчивости обновления без простоя не бывает

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

До выбора прошивок запишите допустимую потерю емкости. Для пары узлов схема N+1 означает, что второй узел должен принять всю рабочую нагрузку, резервное копирование, фоновые задания и всплеск трафика. Для кворумного кластера важен не только объем ресурсов. После вывода узла должно оставаться большинство голосов, а реплики данных не должны переходить в состояние без запаса.

Microsoft описывает Cluster-Aware Updating именно как координацию, а не как магию: роли переносятся, узел обновляется и возвращается в кластер. Непрерывность заявлена для нагрузок, которые уже поддерживают Live Migration или прозрачное переключение SMB. Если роль нельзя перенести, автоматизация аккуратно организует простой, но не устраняет его.

Проверка готовности должна дать ответы на четыре вопроса:

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

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

Карта парка важнее списка доступных версий

План начинается с точной модели оборудования и зависимостей, а не с папки, куда скачали последние пакеты. У двух серверов с одинаковым названием модели могут различаться ревизия системной платы, сетевой адаптер, RAID-контроллер, накопители, процессорный степпинг и текущая цепочка версий. Эти различия определяют применимость пакета и путь перехода.

Для каждого узла зафиксируйте модель, серийный идентификатор, аппаратную ревизию, версии BIOS или UEFI, BMC, CPLD, RAID/HBA, сетевых карт, накопителей и блоков питания. Рядом нужны версии гипервизора или ОС, драйверов, агента управления и режимы Secure Boot, TPM, загрузки и хранения. Снимок конфигурации BIOS тоже обязателен: обновление иногда меняет значение по умолчанию или сбрасывает настройку, которая раньше казалась незаметной.

Redfish дает единый способ собрать часть этого инвентаря. В стандарте DMTF коллекция прошивок находится в UpdateService/FirmwareInventory, но конкретный сервер может использовать дополнительные свойства. Такой запрос не обновляет узел:

curl -sk -u "$RF_USER:$RF_PASS" \
  "https://$BMC/redfish/v1/UpdateService/FirmwareInventory" \
  | jq -r '.Members[]."@odata.id"'

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

/redfish/v1/UpdateService/FirmwareInventory/BIOS
/redfish/v1/UpdateService/FirmwareInventory/BMC
/redfish/v1/UpdateService/FirmwareInventory/NIC.Slot.1

Затем каждую ссылку надо запросить отдельно и сохранить поля Id, Name, Version, Updateable и состояние. Не считайте пустой ответ признаком соответствия. Он может означать, что контроллер не публикует компонент через Redfish, учетной записи не хватает прав или инвентаризация устарела.

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

Совместимость проверяют как единый стек

Целевая версия прошивки должна входить в подтвержденную комбинацию BIOS, BMC, контроллеров, драйверов и ОС. Правило «поставим самое новое на каждый компонент» популярно, потому что выглядит простым и закрывает номера уязвимостей. Оно неверно для производственного парка: независимые последние версии могли не тестироваться вместе, а нужный драйвер может отсутствовать в установленном гипервизоре.

Читайте не только страницу загрузки, но и примечания к выпуску, матрицу совместимости, список исправлений, известные ограничения и требования к промежуточным версиям. Lenovo в документации ThinkAgile называет согласованный набор Best Recipe и прямо пишет, что прошивки, драйверы и программное обеспечение тестируются вместе как стек. HPE Smart Update Manager перед запуском проверяет зависимости. Это полезная практика, но итоговую применимость к вашим платам, адаптерам и версии ОС все равно должен подтвердить ваш инвентарь.

Порядок компонентов задает производитель для конкретной платформы. Нельзя переносить последовательность с соседней модели. Например, на одной из страниц поддержки Supermicro указана строгая цепочка BMC, затем CPLD, затем BIOS. У другого семейства пакет сам управляет очередностью. Если документация говорит применить промежуточный BMC или сначала обновить драйвер хранилища, внесите это отдельными шагами с отдельными проверками.

Особое внимание нужно четырем связкам: BIOS и микрокод процессора, BMC и CPLD, прошивка сетевой карты и ее драйвер, RAID/HBA и драйвер хранилища. Ошибка в первых двух способна лишить удаленного управления или загрузки. Ошибка в последних двух часто проявляется позднее, под нагрузкой, как сброс интерфейса, рост задержки или исчезновение диска.

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

Очередность узлов задает домен отказа

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

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

Никогда не совмещайте в одной волне парные сетевые устройства, оба контроллера массива, две реплики базы или два узла одного шасси, если отказ шасси уже съедает тот же резерв. Формальное правило «один сервер за раз» недостаточно: один сервер может быть последним голосом в кворуме или единственным владельцем непереносимой виртуальной машины.

Kubernetes PodDisruptionBudget ограничивает добровольные удаления реплик, а kubectl drain использует Eviction API и повторяет отклоненные запросы. Документация Kubernetes отдельно предупреждает, что бюджет не защищает от всех отказов и нулевой допустимый простой может заблокировать drain. Это правильная остановка, а не повод применить принудительный режим или удалить поды напрямую. Сначала исправьте число реплик, селекторы, локальные данные либо доступность узлов назначения.

Для Windows Failover Cluster проверьте перенос ролей и состояние CSV до обновления. Для гипервизора убедитесь, что живая миграция проходит в обе стороны, а правила размещения не вернут нагрузку на узел раньше времени. Для базы данных проверяйте роль реплики, задержку применения журнала и возможность автоматического переключения. У каждой платформы свой глагол вывода, но смысл один: узел должен перестать принимать новую работу, отдать текущую и только затем исчезнуть.

Контрольный узел проходит полный цикл первым

Контрольный узел нужен для проверки всего маршрута обновления, включая возврат в пул и работу под нагрузкой. Лабораторный сервер полезен для проверки применимости пакета, но он редко воспроизводит реальные таблицы маршрутизации, SAN, политики планировщика и длительность инициализации оборудования.

Полный цикл выглядит так:

1. Зафиксируйте исходные метрики и синтетическую проверку, запретите новое размещение на узле, штатно перенесите нагрузку и подтвердите отсутствие активных сессий.
2. Проверьте консоль BMC, резервный канал доступа, питание, журнал аппаратных событий и актуальную копию конфигурации. Только после этого передайте пакет.
3. Примените компоненты в документированной очередности. Запишите идентификатор задания, время начала, все перезапуски BMC и фактический момент потери связи с хостом.
4. После загрузки сравните версии и настройки с целевым состоянием, проверьте устройства, сетевые пути, хранилище, синхронизацию времени и аппаратные ошибки.
5. Верните малую долю нагрузки, выдержите период наблюдения, затем снимите ограничение. Следующий узел не начинайте до закрытия всех отклонений.

Redfish UpdateService.SimpleUpdate обычно принимает сетевой адрес образа и возвращает 202 Accepted с адресом монитора задания. DMTF прямо описывает асинхронную модель. Код 202 означает, что запрос принят, а не что прошивка установлена. Автоматизация должна опрашивать задачу до конечного состояния, затем заново читать FirmwareInventory и проверять загрузившийся банк.

UEFI Specification описывает capsule update, который может сохраниться до перезапуска и обработаться во время следующей загрузки. Поэтому статус «пакет размещен» нельзя смешивать со статусом «новая версия активна». В журнале изменений нужны как минимум стадии staged, applied, rebooted, verified и returned_to_service.

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

Образ сначала передайте на контрольный узел тем же способом, который будет использовать автоматика. Не меняйте между тестом и массовой волной протокол, репозиторий, имя файла или права доступа. Если контроллер сам загружает образ по сети, проверьте разрешение имени, сертификат, маршрут и срок действия временных учетных данных. Если файл передает клиент, задайте ограничение времени и убедитесь, что повторный запрос не создает второе параллельное задание. DMTF допускает и pull через SimpleUpdate, и multipart push, но поддержка конкретного метода зависит от реализации.

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

Контрольный узел должен пережить хотя бы один обычный цикл нагрузки, который способен проявить ошибку. Для веб-узла это реальные запросы и фоновые задания. Для хоста виртуализации это миграция тестовой ВМ в обе стороны. Для хранилища это чтение, запись, проверка путей и восстановление репликации. Пустой ping доказывает только работу небольшой части сетевого стека.

Окно работ заканчивается после наблюдения

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

Разделите время на подготовку, вывод нагрузки, применение, перезагрузку, техническую проверку, возврат трафика и наблюдение. Для каждой стадии задайте предельную длительность. Если BMC обещал десять минут, а через двадцать задание не завершилось, оператор должен знать, продолжать ожидание по примечаниям производителя или объявлять сбой. Самовольное снятие питания во время записи флеш-памяти превращает задержку в неисправную плату.

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

В плане должны быть роли, а не только фамилии: руководитель работ принимает решение о продолжении, оператор выполняет команды, владелец сервиса смотрит пользовательские показатели, специалист по сети и хранилищу доступен для диагностики. Один человек не должен одновременно следить за консолью BMC и решать, допустим ли рост ошибок API.

За несколько часов до старта заморозьте несвязанные изменения. Новая версия приложения, переключение маршрута и прошивка сетевой карты в одном интервале лишают команду возможности быстро найти причину. Исключение допустимо только для заранее проверенной зависимости, например драйвера, который нужен целевой прошивке.

Откат готовят до передачи первого пакета

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

Dell Lifecycle Controller, например, показывает откат только для поддерживаемых компонентов. В руководстве iDRAC 8 перечислены BIOS, NIC, RAID, блоки питания и часть других устройств, но для Diagnostics, Driver Packs и CPLD откат недоступен. В другом руководстве Dell указано, что после нескольких обновлений заводской образ может быть перезаписан. Это хороший пример того, почему кнопка Rollback в интерфейсе не заменяет проверенный сценарий для конкретной ревизии.

До работ подготовьте:

• одобренный старый пакет и точный допустимый путь понижения;
• экспорт конфигурации BIOS, BMC, RAID и сетевых адаптеров;
• доступ к удаленной консоли, управляемому питанию и физическому дежурному;
• загрузочный или сервисный носитель, если BMC перестанет принимать образ;
• критерий, после которого вы откатываете, а не продолжаете диагностику.

Стоп-условия должны быть измеримыми. Примеры: узел не проходит POST дольше заданного времени, пропал один из путей хранения, версия активного банка не совпала с планом, появились новые аппаратные ошибки, реплика не догнала кластер за отведенный срок, частота ошибок сервиса превысила согласованный порог. Формулировка «если что-то пойдет не так» бесполезна ночью.

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

После отката узел снова проходит полный приемочный цикл. Возврат старого номера версии не доказывает, что RAID сохранил режим, Secure Boot включен, а оба сетевых порта поднялись. Незавершенный откат исключает узел из следующих волн и запускает разбор причины.

Сервис проверяют снаружи и изнутри

Успешная загрузка сервера не доказывает отсутствие влияния на сервис. Проверка должна соединять три слоя: аппаратное состояние узла, состояние кластера и результат пользовательской операции. Зеленая консоль BMC при растущих ответах HTTP 500 означает не успех, а плохо выбранный критерий.

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

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

На самом узле сравните до и после:

• состав устройств и активные версии прошивок;
• состояние массивов, дисков, multipath и файловых систем;
• скорость и ошибки сетевых портов, bonding или teaming;
• аппаратный журнал, датчики, вентиляторы и блоки питания;
• настройки загрузки, виртуализации, Secure Boot и времени.

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

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

Автоматизация обязана уметь остановиться

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

У каждого узла должен появиться журнал с исходными и целевыми версиями, хешем пакета, идентификатором задания, временем стадий, результатами проверок и именем принявшего решение. Для Redfish сохраните конечное состояние Task Monitor и повторный FirmwareInventory. Для оркестратора сохраните причину drain, список вытесненных нагрузок и момент uncordon или его аналога.

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

Состояние кампании лучше хранить отдельно от состояния задания прошивки. Задание может завершиться успешно, а узел не пройти приемку из-за потерянного сетевого пути. Используйте понятные состояния planned, drained, updating, verifying, observing, accepted, rolled_back и blocked. Переходы должны происходить только после измеряемой проверки, а не по таймеру. Если процесс перезапустился, он читает сохраненное состояние, сверяет его с фактическим и предлагает безопасное продолжение. Он не должен повторно передавать образ только потому, что потерял локальную память.

Пропуск узла не надо считать ошибкой всей кампании. Автоматизация должна отмечать ineligible, если модель, ревизия, исходная версия, состояние кластера или свободная емкость не соответствуют политике. Такой узел уходит на разбор, а однородная группа может продолжить работу после решения руководителя.

Не ставьте автоматический переход к следующему узлу сразу после статуса Completed. Между ними нужен шлюз: целевые версии активны, настройки совпали, аппаратных ошибок нет, кластер восстановил запас, синтетика успешна, метрики выдержали период наблюдения. Любой ответ unknown должен блокировать волну так же, как failed.

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

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

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

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