Бездисковая загрузка по сети и жизнь после нее

[Yoda33]

Спасибо, познавательно! Интересно было бы провернуть подобное с FreeBSD.

[Dyr]

Вообще без проблем.
Тонкость была только одна, в имя загрузчика, который грузился по сети, пришлось добавить в конец псевдосимвол, который, уже не помню по какой причине, запрашивался по PXE.

[susanin]

А почему образ храните в RAM?
Я реализовал сетевую загрузку с помощью pxe+nfsroot(ro)+aufs+init-скрипт. Обошелся без initrd. Работает на 30+серверах и 30+ офисных компах. Образы, конечно же, разные.
NFS в целом удобнее — нет ограничений на размер, удобнее обновлять.

[morello]

Было бы интересно почитать относительно реализации. Не оформите?

[susanin]

Давно собирался, но, видимо, так никогда и не соберусь. Если есть конкретные вопросы, то попробую ответить.

[morello]

Конкретно интересует формирование образа системы с загрузкой посредством pxe, с которого будет возможность нормально пользоваться флешками, подключатся по RDP и расшаривать локально подключенные принтеры/МФУ. Т.е. все то, что должно было бы работать в thinstation, но стабильно и без костылей…

[susanin]

У нас на десктопах не совсем thinstation. Нормальные мощные компы, всё работает локально, /home монтируется локально, а остальное по сети в RO.
Есть и thinstation для RDP, но новый админ настраивал без меня и взял какое-то готовое решение.

[giner]

> /home монтируется локально, а остальное по сети в RO
как устанавливаете новый софт?

[Invariant]

Храним в RAM, чтобы не беспокоиться о том, отвалится у нас сеть или нет. В вашем случае, если поломается nfs-сервер, то будет грустно…

[susanin]

По опыту — если отвалится сеть, то система продолжает работать, ибо уже загруженное в память никто насильно не выгрузит. Но с другой стороны — зачем работающий сервер, у которого отвалилась сеть?
А отдельно nfs-сервер ни разу не падал.

[minicon]

Сеть может моргнуть, например. может отвалиться на пару минут. Да что угодно может случиться.

[susanin]

Еще раз: если отваливается сеть, то всё продолжает работать. В крайнем случае при желании системы что-то прочитать и наличии опции hard, система будет ждать ответа сервера. Да, «неприятно», но при отвалившейся сети это уже второстепенно.
Дабы прояснить ситуацию: я нисколько не настаиваю на nfsroot, просто делюсь мнением и опытом. С initrd+wget+squashfs+aufs тоже дело имел, но не понравилось.

[minicon]

а что не понравилось?
Мы такую схему использовали и вполне удачно, интересно, какие проблемы у людей возникают)

[susanin]

1) Самое главное: ограничение на размер. К примеру, офисный образ весит около 7Гб (несколько IDE, браузеры, офис и прочее).
2) Поддержка. Актуально для десктопов, на серверах другие законы :)
Мне достаточно поменять конфиг в файле, доустановить пакет и не надо ничего переупаковывать и перезагружаться.

[minicon]

Ясно. Для ваших задач, я думаю самое оно. У нас они были совсем другие)

[Invariant]

Вы сами ответили на все свои вопросы. Это решение для небольшого образа (200-300Мб), который крутится на сервере, а он в свою очередь должен работать, даже если патч-корд поломался, а дцшник спит и никак не может его заменить, Другой вопрос это как сделать так, чтобы это не порушило все остальное (можно грузить систему по отдельному интерфейсу, если средства позволяют), но зато тут я уверена, что сервер будет работать и без сети.

[erlyvideo]

кроме этого есть ещё проблема с NFS: он вообще никак не работает из под докера.

Если в компании пошли всё запаковывать, то тут станет больно.

[Aecktann]

Когда упадёт NFS — станете делать по другому?
Падает всё. Нет исключений.

[susanin]

Когда упадет nfs — поднимется копия виртуалки с nfs-сервером на другом хосте. А как я уже сказал, серверы не заметят подмены.

[Aecktann]

Так сразу говорите, что у вас построен отказоустойчивый NFS.
Кроме того, получится всё равно не очень красиво. Из-за падения отдельного NFS-стораджа виртуалка (и видимо далеко не одна...) почувствует hard-reboot (или я вас вновь плохо понимаю из-за недостатка информации).

upd: я понял, кажется. вы храните сам NFS-сервер на виртуалке. Ок, решение как решение. Только автор как раз указывает, что он с помощью сетевой загрузки создаёт распределенное хранилище.

[susanin]

Нет-нет-нет, никакого ребута. Просто клиенты «висят» на чтении.

NFS сервер живет на вируталке и обеспечивает загрузку других 30+ серверов. Что не так?

Так сразу говорите, что у вас построен отказоустойчивый NFS.

Разговор про сетевую загрузку, а не про отказоустойчивость :)

[Aecktann]

Эм.
Окей, у вас отказоустойчивая NFS-шара в виде виртуалки. Её локальным диском является некоторый распределенный блочный сторадж.
Зачем же тогда возиться с NFS, когда можно просто использовать iSCSI сразу к блочному стораджу, монтировать файловую систему в ro, и поднимать aufs поверх этой файловой системы? Получите то же самое (много места, нормальная гибкость), только без промежуточного звена в виде виртуалки, предоставляющей NFS.

[susanin]

У нас нет iSCSI. И вообще почти все сервера бездисковые.

[Aecktann]

Виртуалка с NFS поверх чего работает? Не на святом же духе.
Если то, поверх чего работает виртуалка с NFS, не отказоустойчиво, то у всё равно когда упадет это самое «то» и все ваши загруженные по сети машины умрут.

[qxfusion]

только если это pNFS4 или выше, иначе будет очень неприятно клиентам…

[susanin]

Не замечал недовольства nfs-клиентов при перезагрузке системы с nfs-сервером.

[deilux]

Действительно, у вас просто пока не «моргала» сеть…

[realloc]

Если NFS сервер отвалился в момент ожидания возврата из write/read, то процесс-обработчик уснёт непробудным сном. Как побочный эффект будет мёртвый mount в худшем случае до ближайшего ребута.

Да и вообще появляется лишняя сущность, сильно зависимая от погоды в сегменте сети, что есть нехорошо.

[minicon]

>NFS в целом удобнее — нет ограничений на размер, удобнее обновлять.
Если падает сеть, nfs отваливается. Если у вас на nfs root, то привет.

[MealstroM]

Вот есть проект для терминал сервера с загрузкой посети (тонкий и толстый клиенты) ltsp.org/. Возможно будет немного меньше велосипедов. Но есть ограничение по дистрибутивам.

[Invariant]

Мой велосипедик маленький, простой и сделан для того, чтобы убежать от nfs.

[MealstroM]

Все сводится к «ресурсы выделяемые на поддержку» данного решения. А это уже Вам решать.

[Invariant]

Спасибо за участие, но это решение не для терминального сервера, который думает за клиента, это просто способ загрузиться по сети, погасить интерфейс и спокойно работать дальше, а диски в сервере полностью отведены под хранение данных.

[Archangel]

А что хостит эти 14 дисков? СХД же какая-нибудь наверняка. Не логичнее ли грузится сразу с iSCSI? Если образ системы весит 200МБ (да хоть 1GB) расход места на загрузочные тома ничтожен, а геморрою меньше, да и сложность системы поменьше, а следовательно мест для ошибки и траблшутинга, если что, тоже меньше. А то что сеть моргает, так у меня статистически железо в серверах летит чаще, чем сеть моргает.

[Invariant]

Предназначение этих дисков — собрать raid10 и экспортировать этот md том наружу по iSCSI. Диски стоят в простом толстом сервере, это не готовая промышленная СХД.

[Archangel]

Т.е. одним разделяемым LUN-ом весь раздел «как есть»?
Тогда в принципе понятно.

[Invariant]

да, ОС не должна «жить» на этих дисках.

[Dyr]

Не вижу смысла сжимать в SquashFS, разница пусть даже в 500 Мбайт занятой оперативки для современного сервера вообще ни о чём. Зато куда проще будет обновлять файлы и не потребуется AuthFS.

[Invariant]

Там описаны разные вариации и никто не настаивает на том, что надо использовать именно squashfs.

[amc]

А можно было просто грузиться с флешки =)
Но с сетевой загрузкой есть свои плюсы, безусловно.

[aectann001]

Угу, особенно речь идет о некотором количестве серверов в нескольких удаленных датацентрах, с флешки, да )