Pull to refresh

Comments 24

судя по этому длинному описанию и выводов в конце система не решает того для чего предназначается — упрощения обновления такой кучей машин
У системы большой порог вхождения. Когда обновление образов налажено, актуализация состоит в запуске одного скрипта плюс последовательной перезагрузке машин
Не. Локальные диски в крупных системах — зло.
Не обязательно диск должен быть локальным.

В любом случае описание используемого вами решения лично меня смущает своим объёмом.
Почти любая примочка требует допиливания. KIWI — официальный инструмент для создания образов SuSE, поэтому ему было отдано предпочтение.
Я сильно сомневаюсь, что тот же g4l с разбегу соберет работающий образ, а также даст нормальную возможность грузиться с FlexBoot. А время допиливания в любом случае непредсказуемо.
Я прочитал внимательнее про G4L. Это же клон какого-нибудь Norton Ghost. Создание образа из набора пакетов и запуск dd с готовой системы — абсолютно непересекающиеся задачи.
Насколько я помню, для создания набора образов из набора пакетов для разных систем в одной компании использовали Tinderbox.

Правда, в той же Mozilla позже разработали Buildbot.
Акжан, не надо путать автоматизированную сборку пакетов под разные архитектуры (с чем в нашем случае замечательно справляется OBS) со сборкой образов операционной системы, пригодных для загрузки.
Точно, я великий путаник )
FAI под debian подобную задачу решает и принцип действия примерно такой же. кстати автор — немец.
FAI решает задачу сетапа. KIWI с ней тоже справляется (режим «OEM»).
Корень полностью в RAM — специфичная задача, которая, согласно назначению FAI, для него если и доступна, то неприоритетна.
пробовали делать xen-dom0 — черех pxe/nfs и на нем xen-domU pxe/nfs?
Dom0 — да. Работает замечательно.
pv-DomU (в силу специфики паравиртуализации) с PXE работать не может. Под hvm у меня тоже не получилось в свое время.
NFSRoot — огромная точка отказа. Кроме того, если обновлять его наживую, возможны артефакты, вызванные тем, что нужная библиотека внезапно обновилась. Поэтому мы решили держать образ в RAM.
pv-DomU у меня вроде бы запустился как раз (через pypxeboot в promiscuous mode), т.е. стенд рабочий есть, но есть скользкое место как раз в момент поднятия бриджа для domu — т.к. надо между eth0 и peth0 перебрасывать айпишник это можно сделать только в initrd. работать вроде работает, но как в потом в продакшене это будет себя вести неясно. :(
pypxeboot — УГ, пытающееся как-то эмулировать поведение pxelinux. Эта поделка получает IP для домена по DHCP, выкачивает конфиг (примерно так, как это делает pxelinux), парсит его (при этом парсинг там очень убогий), скачивает ядро и инитрд, после чего отдает зену их местоположение.
Любое усложнение конфига приведет к удивлению со стороны pypxeboot, что даже для не-продакшна ужасно.
pypxeboot, конечно, пришлось доводить до ума руками
по поводу dom0 была мысль еще весь его засунуть в initrd и там и оставить
Это вариант, конечно. Но каково же будет pxelinux-у, если заставить его по TFTP выкачивать 200-мегабайтную initrd?
почему, кстати, nfsroot точка отказа, думал drdb+ha+nfs — есть какие то подводные камни?
Да. Когда падает один из серверов, после переноса IP-адресов все файловые дескрипторы клиентов становятся невалидными. Я тестировал эту схему, клиенты не переживают даже рестарт NFS-сервера средствами инит-скрипта.
Возможно, дело в том, что для реконнекта нужны бинари mount и mount.nfs, которые лежат на отвалившейся к тому моменту файлухе.
Правильный вариант — это единый DAS в ro для всех тазиков ;)
— Вы встретились с Глазом?
— Нет
— А он с Вами… повидался?
Sign up to leave a comment.

Articles