[devel] supervisor system

[devel] supervisor system

[Peter V. Saveliev]

...

Про термины. Дальше: 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

Re: [devel] supervisor system

[Michael Shigorin]

On Sat, Aug 05, 2006 at 06:41:42PM +0400, Peter V. Saveliev wrote:
> ?5) должен быть предусмотрен механизм контроля работы
> контекстов? Или это оставить на откуп monit внутри каждого
> контекстаа по отдельноcти?

Можно я как текущий майнтейнер и активный юзер monit вылезу опять
с предложением пакующим сервисы более активно зависеть от
monit-base? :)

> В общем, такая думка сейчас.

В нескольких местах, особенно по поводу временных контекстов,
аж немного дух захватило.

Надо обдумать и перещупать.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] supervisor system

[Igor Zubkov]

[-- Attachment #1: Type: text/plain, Size: 533 bytes --]

В сообщении от 5 августа 2006 20:15 Michael Shigorin написал(a):
> > ?5) должен быть предусмотрен механизм контроля работы
> > контекстов? Или это оставить на откуп monit внутри каждого
> > контекстаа по отдельноcти?
>
> Можно я как текущий майнтейнер и активный юзер monit вылезу опять
> с предложением пакующим сервисы более активно зависеть от
> monit-base? :)

Попробую в следующей сборке polypaudio/pulseaudio привинтить к нему monit. Для 
уверености что звуковой сервер уже никогда не отвалится. :)

-- 
Pain - Suicide Machine

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] supervisor system

[Michael Shigorin]

On Mon, Aug 07, 2006 at 12:42:33PM +0300, Igor Zubkov wrote:
> > > ?5) должен быть предусмотрен механизм контроля работы
> > > контекстов? Или это оставить на откуп monit внутри каждого
> > > контекстаа по отдельноcти?
> > Можно я как текущий майнтейнер и активный юзер monit вылезу
> > опять с предложением пакующим сервисы более активно зависеть
> > от monit-base? :)
> Попробую в следующей сборке polypaudio/pulseaudio привинтить к
> нему monit. Для уверености что звуковой сервер уже никогда не
> отвалится. :)

А что, есть такая тенденция? :)

PS: по мере возможности помощь с подобным прикручиванием берусь
оказывать.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] supervisor system

[Денис Смирнов]

On Mon, Aug 07, 2006 at 01:22:55PM +0300, Michael Shigorin wrote:

MS> PS: по мере возможности помощь с подобным прикручиванием берусь
MS> оказывать.

Раз уж берешься, сделаешь review monit в asterisk'е, и дашь мне по рукам
если что не так?

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------
Если у кого возникнут светлые мысли -- не стесняйтесь вешать
сразу в BTS.
		-- mike in devel@

Re: [devel] supervisor system

[Michael Shigorin]

On Mon, Aug 07, 2006 at 05:01:38PM +0400, Денис Смирнов wrote:
> MS> PS: по мере возможности помощь с подобным прикручиванием берусь
> MS> оказывать.
> Раз уж берешься, сделаешь review monit в asterisk'е, и дашь мне
> по рукам если что не так?

Давай.  Собсно там ключевое -- тест на (не)работоспособность
и знание, как корректно пнуть сервис.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] supervisor system

[Денис Смирнов]

On Mon, Aug 07, 2006 at 04:26:19PM +0300, Michael Shigorin wrote:

MS> Давай.  Собсно там ключевое -- тест на (не)работоспособность
MS> и знание, как корректно пнуть сервис.

Тогда он давно уже в пакете asterisk :)

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------
 Грамотное и безопасное программирование как-то плохо сочетается
с C/C++.
		-- vsl in devel@