Comments 24
судя по этому длинному описанию и выводов в конце система не решает того для чего предназначается — упрощения обновления такой кучей машин
+1
-2
Не. Локальные диски в крупных системах — зло.
+2
Не обязательно диск должен быть локальным.
В любом случае описание используемого вами решения лично меня смущает своим объёмом.
В любом случае описание используемого вами решения лично меня смущает своим объёмом.
-2
Почти любая примочка требует допиливания. KIWI — официальный инструмент для создания образов SuSE, поэтому ему было отдано предпочтение.
Я сильно сомневаюсь, что тот же g4l с разбегу соберет работающий образ, а также даст нормальную возможность грузиться с FlexBoot. А время допиливания в любом случае непредсказуемо.
Я сильно сомневаюсь, что тот же g4l с разбегу соберет работающий образ, а также даст нормальную возможность грузиться с FlexBoot. А время допиливания в любом случае непредсказуемо.
+2
Я прочитал внимательнее про G4L. Это же клон какого-нибудь Norton Ghost. Создание образа из набора пакетов и запуск dd с готовой системы — абсолютно непересекающиеся задачи.
+1
FAI под debian подобную задачу решает и принцип действия примерно такой же. кстати автор — немец.
0
пробовали делать xen-dom0 — черех pxe/nfs и на нем xen-domU pxe/nfs?
0
Dom0 — да. Работает замечательно.
pv-DomU (в силу специфики паравиртуализации) с PXE работать не может. Под hvm у меня тоже не получилось в свое время.
NFSRoot — огромная точка отказа. Кроме того, если обновлять его наживую, возможны артефакты, вызванные тем, что нужная библиотека внезапно обновилась. Поэтому мы решили держать образ в RAM.
pv-DomU (в силу специфики паравиртуализации) с PXE работать не может. Под hvm у меня тоже не получилось в свое время.
NFSRoot — огромная точка отказа. Кроме того, если обновлять его наживую, возможны артефакты, вызванные тем, что нужная библиотека внезапно обновилась. Поэтому мы решили держать образ в RAM.
+2
pv-DomU у меня вроде бы запустился как раз (через pypxeboot в promiscuous mode), т.е. стенд рабочий есть, но есть скользкое место как раз в момент поднятия бриджа для domu — т.к. надо между eth0 и peth0 перебрасывать айпишник это можно сделать только в initrd. работать вроде работает, но как в потом в продакшене это будет себя вести неясно. :(
0
pypxeboot — УГ, пытающееся как-то эмулировать поведение pxelinux. Эта поделка получает IP для домена по DHCP, выкачивает конфиг (примерно так, как это делает pxelinux), парсит его (при этом парсинг там очень убогий), скачивает ядро и инитрд, после чего отдает зену их местоположение.
Любое усложнение конфига приведет к удивлению со стороны pypxeboot, что даже для не-продакшна ужасно.
Любое усложнение конфига приведет к удивлению со стороны pypxeboot, что даже для не-продакшна ужасно.
+1
по поводу dom0 была мысль еще весь его засунуть в initrd и там и оставить
+1
почему, кстати, nfsroot точка отказа, думал drdb+ha+nfs — есть какие то подводные камни?
0
Да. Когда падает один из серверов, после переноса IP-адресов все файловые дескрипторы клиентов становятся невалидными. Я тестировал эту схему, клиенты не переживают даже рестарт NFS-сервера средствами инит-скрипта.
Возможно, дело в том, что для реконнекта нужны бинари mount и mount.nfs, которые лежат на отвалившейся к тому моменту файлухе.
Возможно, дело в том, что для реконнекта нужны бинари mount и mount.nfs, которые лежат на отвалившейся к тому моменту файлухе.
+2
Правильный вариант — это единый DAS в ro для всех тазиков ;)
0
Sign up to leave a comment.
KIWI Image System: атака клонов