[devel] supervisor system

["Peter V. Saveliev" <peet@altlinux.ru>]

...

Про термины. Дальше: VPE == context == контекст == "пластинка" (кто был на 
круглом столе, тот помнит).

По следам круглого стола на конференции. На случай кого там не было, в двух 
словах: есть идея использовать виртуальные среды (VPE, или контексты, кому 
как нравится) для модульной организации решений. Заготовка контекста есть 
тарбол с "rootfs", которая будет установлена и запущена, внутри контекста 
будет работать некоторое забитое для запуска "из коробки" решение -- 
например, сервер сбора тех.статистики, связка mysql+php+apache или, например, 
zope.

Что мы имеем с гуся.
а) заготовки позволят минимизировать временые затраты на установку решений
б) повышается безопасность системы в целом
в) возможность одновременного запуска k контекстов --и вот самое главное --
г) контроль ресурсов машины на per-context basis

Конкретно для меня последний пункт идёт на первом месте по важности.

Соотв., уже имея опыт компиляции подобных систем (RAD), а также их "боевого" 
использования (на соём сервере) хочу попробовать сделать прототип 
системы-супервизора. В качестве первого шага, стало быть, нужно составить 
system requirements specification, и вот что у меня пока получается

1) время загрузки системы-супервизора не должно быть сильно дольше времени, 
необходимого дя инициализации самого ядра. Время загрузки контекстов сюда не 
входит. Дурацкая формулировка, но для верифицируемости, напишем -- не дольше, 
чем на 10% (от балды пока) от времени загрузки голого ядра.

2) административный доступ должен быть предоставлен ещё до загрузки 
контекстов, за исключением случаев, когда без загруженного контекста он не 
возможен. То есть, _сразу_ должен быть доступен логин на serial, local 
console и telnet/ssh. Вот это критично.

3) должен быть механизм простой инициализации контекстов. Под словом "простая" 
я понимаю одну команду в shell с id контекста и урл архива (если нужно). 
Инициализация в данном случае подразумевает не только запуск, но и установку 
по мере необходимости с
3.1) tftp
3.2) ftp/http
3.3) примонтированной ФС
3.4) блочного девайса с указанием смещения и размера архива

4) должен быть механизм сохранения конфигурации между запусками, должен быть 
предусмотрен откат по версиям конфигурации, в том числе автооткат на 
предпоследнюю версию в случае применения "неверной" конфигурации. В качестве 
критериев для автоотката можно использовать доступность сетевых ресурсов, 
наличие файлов или процессов.

5) нужно иметь возможность запускать контексты, как "временные" -- с корнем в 
tmpfs (у кого памяти довольно, да и некоторые много не требуют), так 
и "постоянные" (в смысле, не грохающиеся с перезагрузкой), расположенные на 
примонтированных ФС (откуда-то)

?5) должен быть предусмотрен механизм контроля работы контекстов? Или это 
оставить на откуп monit внутри каждого контекстаа по отдельноcти?

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

Очень понравилась идея собирать initramfs, т.к. это позволит довольно просто 
включить её в процесс сборки rpm ядра: с помощью системы, например, на базе 
сборки RAD, но без sudo можно собрать тарбол с нужными утилитами, дальше, его 
пихнуть в один из %source, распаковать с составлением списка файлов в дерево 
исходников перед сборкой, а затем сборка схомячит список файлов и сделает 
initramfs, но список к тому времени не без помощи скрипта прирастёт девайсами 
(которые иначе без sudo толком сделать сложно, хотя и можно). Минусом этого 
метода является то, что в initramfs много не запихаешь, и, хоть 
система-супервизор должна быть _очень_ скромной по размерам, всё равно для 
инициализации контекстов нужно иметь какие-то (именно какие-то -- для одного 
одни, для другого другие) модули. Куда их пихать? В initrd, а дальше 
монтировать их из initramfs через /dev/ram1? А смысл тогда городить 
initramfs, если можно без модификации пакета ядра сделать initrd? Вариант же 
с initrd нехорош тем, что поддержка разумных для таких целей файловых систем 
в ALT лежит в виде модулей (cramfs, squashfs), а если и пересобирать ядро по 
любому, то тут и initramfs уже можно сделать... В общем, такая думка сейчас.

-- 
Peter V. Saveliev