Linux update with 5min downtime

Mykola Marzhan, Kyiv, Ukraine, PortaOne, Inc.

LVEE 2012

The analysis is presented for the operating system update process in the modern Linux distros, covering the options of resolving the related problems. An example of corporate sector requirements for updates is given. Author suggests his way of resolving the issue and describes its advantages and disadvantages.

Одной из важных проблем современного мира Linux является проблема обновления всего дистрибутива с версии на версию. В дистрибутивах, нацеленных на корпоративный сектор (RHEL, Ubuntu), этими проблемами занимаются и решают их довольно успешно. В некоторых других дистрибутивах мы можем сталкиваться с серьезными трудностями при обновлении, или даже с продолжительным простоем сервисов (downtime). Простота, надежность и скорость процедуры обновления дистрибутива особенно важны на серверах, при простое которых останавливаются бизнес-процессы. Зачастую обновление дистрибутива на таких серверах проводят только в случаях крайней необходимости. Мотивами могут служить такие факторы, как ошибки программного обеспечения (ПО), наличие проблем безопасности в текущем ПО, а также нередки ситуации, когда для работы новой версии используемого проприетарного решения необходима более новая версия дистрибутива или ядра.

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

Автору было предложено реализовать систему обновления ПО, которая отвечала бы следующим требованиям:

Возможность возврата к состоянию “до обновления” через произвольный промежуток времени.
Время простоя сервисов не более 5 минут.
Возможность проводить все необходимые действия удаленно, без возможности физического доступа к оборудованию.
Решение должно легко автоматизироваться, чтобы максимально исключить человеческий фактор.

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

Возможен вариант с применением снимков файловой системы (snapshot), но этот подход приводит к большой потере произвольности дисковой подсистемы, а подход с заменой обычных внутренних жестких дисков на более производительную (или внешнюю) дисковую подсистему неприемлем.

Установка новой версии дистрибутива на неиспользуемый раздел HDD была одним из рассмотренных вариантов. Была предложена следующая последовательность действий на конечном сервере:

Скачивание образа дистрибутива или готовых для установки пакетов;
Установка дистрибутива на свободный раздел;
Копирование конфигурационных файлов с рабочего раздела на новый, включение сервисов в автозагрузку;
Настройка конфигурационного файла GRUB;
Перезагрузка в новый раздел.

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

Используемая дисковая подсистема должна иметь следующие логические разделы:
- Корневой раздел, на который будет установлена операционная система (ОС) со всем необходимым ПО.
- Раздел для обновлений, идентичный корневому по размеру. На этот раздел будет выполняться установка новой версии.
- Раздел для данных. Это самый большой раздел, на котором будут храниться данные, которые нельзя терять после обновления. Например, файлы баз данных, отчеты, лог-файлы бизнес-приложений, которые должны храниться продолжительное время и т.д.
Знание списка конфигурационных файлов, которые нужно скопировать на новый раздел.
Наличие KVM over IP (Remote KVM). Для случаев, если была допущена ошибка на стадии редактирования конфигурационного файла GRUB.

Плюсами данного метода являются:

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

Текст тезисов доступен под лицензией Creative Commons Attribution-ShareAlike 3.0.