kmorph: замена ядра Linux за 2 секунды без перезагрузки сервера

Что случилось

Разработчики проекта Multikernel выпустили инструментарий kmorph: он позволяет заменить работающее ядро Linux запасным, уже загруженным в память, — при аварийной остановке или при плановом обновлении, без перезагрузки. Проект развивает Конг Ванг, сопровождающий подсистему управления трафиком (TC) в ядре Linux.

Детали

Multikernel даёт одному физическому серверу несколько независимых экземпляров ядра без гипервизора, каждый на своём наборе процессорных ядер. kmorph использует эту схему так: рядом с рабочим ядром (predecessor) заранее готовится преемник (successor) с минимальным системным окружением.

• kmorph работает в активном окружении: собирает образ преемника, взводит его и синхронизирует сетевую конфигурацию;
• kmorphd живёт внутри преемника и следит за предшественником;
• при panic или зависании преемник фиксирует молчание — по умолчанию около половины секунды — останавливает чужие CPU и забирает память, PCI-устройства, сеть и корневую ФС;
• устройства принимаются по одному через FLR или сброс питания, при необходимости снимается Bus Master Enable, чтобы остановить DMA мёртвого ядра;
• память сбойного ядра сохраняется как vmcore для посмертного разбора.

В тестах сервер с nginx после сбоя ядра возвращался к работе примерно за две секунды: преемник держит типовые сервисы уже загруженными в память и начинает обслуживать запросы сразу после переключения сетевой карты и смены корневой ФС. Команда kmorph upgrade выполняет ту же передачу по запросу — это обновление ядра без перезагрузки. Поддержаны архитектуры x86_64 и ARM64, ведётся работа над RISC-V; установка задумана по образцу kdump, через dracut, initramfs-tools, kernel-install и systemd.

Механизмы Kexec HandOver и Live Update Orchestrator в ядре решают похожую задачу, но требуют живого ядра для сохранения состояния и перезагружают его через kexec, а потому не спасают при сбое и переключаются медленнее.

Что это значит

Для серверов, где минуты простоя на счету, меняется сам сценарий аварии: вместо двух перезагрузок — на дамп через kexec и на рабочее ядро — остаётся одно переключение, а обновление ядра перестаёт быть окном обслуживания. Пока это не готовый продукт: нужно ядро с CONFIG_MULTIKERNEL и интерфейсом host-tree, для дампа — CONFIG_CRASH_DUMP, а после перехвата преемник не взводит следующего без kmorph.service. Ограничения перечислены в документации: нет вторичного сброса шины для принятых устройств, память забирается целыми гранулами, дамп не фильтруется и его приходится ужимать makedumpfile. Кроме того, преемник не может работать на ядре без поддержки multikernel, так что первое внедрение всё равно начинается с обычной перезагрузки — уже с новым ядром в конфигурации.