ALT Linux Team development discussions
 help / color / mirror / Atom feed
From: "Peter V. Saveliev" <peet@altlinux.ru>
To: devel@lists.altlinux.org
Subject: [devel] supervisor system
Date: Sat, 5 Aug 2006 18:41:42 +0400
Message-ID: <200608051841.42587.peet@altlinux.ru> (raw)

...

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

             reply	other threads:[~2006-08-05 14:41 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-08-05 14:41 Peter V. Saveliev [this message]
2006-08-05 17:15 ` Michael Shigorin
2006-08-07  9:42   ` Igor Zubkov
2006-08-07 10:22     ` Michael Shigorin
2006-08-07 13:01       ` Денис Смирнов
2006-08-07 13:26         ` Michael Shigorin
2006-08-07 17:07           ` Денис Смирнов

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200608051841.42587.peet@altlinux.ru \
    --to=peet@altlinux.ru \
    --cc=devel@lists.altlinux.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

ALT Linux Team development discussions

This inbox may be cloned and mirrored by anyone:

	git clone --mirror http://lore.altlinux.org/devel/0 devel/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 devel devel/ http://lore.altlinux.org/devel \
		devel@altlinux.org devel@altlinux.ru devel@lists.altlinux.org devel@lists.altlinux.ru devel@linux.iplabs.ru mandrake-russian@linuxteam.iplabs.ru sisyphus@linuxteam.iplabs.ru
	public-inbox-index devel

Example config snippet for mirrors.
Newsgroup available over NNTP:
	nntp://lore.altlinux.org/org.altlinux.lists.devel


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git