Comments 41
Спасибо, познавательно! Интересно было бы провернуть подобное с FreeBSD.
А почему образ храните в RAM?
Я реализовал сетевую загрузку с помощью pxe+nfsroot(ro)+aufs+init-скрипт. Обошелся без initrd. Работает на 30+серверах и 30+ офисных компах. Образы, конечно же, разные.
NFS в целом удобнее — нет ограничений на размер, удобнее обновлять.
Я реализовал сетевую загрузку с помощью pxe+nfsroot(ro)+aufs+init-скрипт. Обошелся без initrd. Работает на 30+серверах и 30+ офисных компах. Образы, конечно же, разные.
NFS в целом удобнее — нет ограничений на размер, удобнее обновлять.
Было бы интересно почитать относительно реализации. Не оформите?
Давно собирался, но, видимо, так никогда и не соберусь. Если есть конкретные вопросы, то попробую ответить.
Конкретно интересует формирование образа системы с загрузкой посредством pxe, с которого будет возможность нормально пользоваться флешками, подключатся по RDP и расшаривать локально подключенные принтеры/МФУ. Т.е. все то, что должно было бы работать в thinstation, но стабильно и без костылей…
Храним в RAM, чтобы не беспокоиться о том, отвалится у нас сеть или нет. В вашем случае, если поломается nfs-сервер, то будет грустно…
По опыту — если отвалится сеть, то система продолжает работать, ибо уже загруженное в память никто насильно не выгрузит. Но с другой стороны — зачем работающий сервер, у которого отвалилась сеть?
А отдельно nfs-сервер ни разу не падал.
А отдельно nfs-сервер ни разу не падал.
Сеть может моргнуть, например. может отвалиться на пару минут. Да что угодно может случиться.
Еще раз: если отваливается сеть, то всё продолжает работать. В крайнем случае при желании системы что-то прочитать и наличии опции hard, система будет ждать ответа сервера. Да, «неприятно», но при отвалившейся сети это уже второстепенно.
Дабы прояснить ситуацию: я нисколько не настаиваю на nfsroot, просто делюсь мнением и опытом. С initrd+wget+squashfs+aufs тоже дело имел, но не понравилось.
Дабы прояснить ситуацию: я нисколько не настаиваю на nfsroot, просто делюсь мнением и опытом. С initrd+wget+squashfs+aufs тоже дело имел, но не понравилось.
а что не понравилось?
Мы такую схему использовали и вполне удачно, интересно, какие проблемы у людей возникают)
Мы такую схему использовали и вполне удачно, интересно, какие проблемы у людей возникают)
1) Самое главное: ограничение на размер. К примеру, офисный образ весит около 7Гб (несколько IDE, браузеры, офис и прочее).
2) Поддержка. Актуально для десктопов, на серверах другие законы :)
Мне достаточно поменять конфиг в файле, доустановить пакет и не надо ничего переупаковывать и перезагружаться.
2) Поддержка. Актуально для десктопов, на серверах другие законы :)
Мне достаточно поменять конфиг в файле, доустановить пакет и не надо ничего переупаковывать и перезагружаться.
Ясно. Для ваших задач, я думаю самое оно. У нас они были совсем другие)
Вы сами ответили на все свои вопросы. Это решение для небольшого образа (200-300Мб), который крутится на сервере, а он в свою очередь должен работать, даже если патч-корд поломался, а дцшник спит и никак не может его заменить, Другой вопрос это как сделать так, чтобы это не порушило все остальное (можно грузить систему по отдельному интерфейсу, если средства позволяют), но зато тут я уверена, что сервер будет работать и без сети.
кроме этого есть ещё проблема с NFS: он вообще никак не работает из под докера.
Если в компании пошли всё запаковывать, то тут станет больно.
Если в компании пошли всё запаковывать, то тут станет больно.
Когда упадёт NFS — станете делать по другому?
Падает всё. Нет исключений.
Падает всё. Нет исключений.
Когда упадет nfs — поднимется копия виртуалки с nfs-сервером на другом хосте. А как я уже сказал, серверы не заметят подмены.
Так сразу говорите, что у вас построен отказоустойчивый NFS.
Кроме того, получится всё равно не очень красиво. Из-за падения отдельного NFS-стораджа виртуалка (и видимо далеко не одна...) почувствует hard-reboot (или я вас вновь плохо понимаю из-за недостатка информации).
upd: я понял, кажется. вы храните сам NFS-сервер на виртуалке. Ок, решение как решение. Только автор как раз указывает, что он с помощью сетевой загрузки создаёт распределенное хранилище.
Кроме того, получится всё равно не очень красиво. Из-за падения отдельного NFS-стораджа виртуалка (и видимо далеко не одна...) почувствует hard-reboot (или я вас вновь плохо понимаю из-за недостатка информации).
upd: я понял, кажется. вы храните сам NFS-сервер на виртуалке. Ок, решение как решение. Только автор как раз указывает, что он с помощью сетевой загрузки создаёт распределенное хранилище.
Нет-нет-нет, никакого ребута. Просто клиенты «висят» на чтении.
NFS сервер живет на вируталке и обеспечивает загрузку других 30+ серверов. Что не так?
Разговор про сетевую загрузку, а не про отказоустойчивость :)
NFS сервер живет на вируталке и обеспечивает загрузку других 30+ серверов. Что не так?
Так сразу говорите, что у вас построен отказоустойчивый NFS.
Разговор про сетевую загрузку, а не про отказоустойчивость :)
Эм.
Окей, у вас отказоустойчивая NFS-шара в виде виртуалки. Её локальным диском является некоторый распределенный блочный сторадж.
Зачем же тогда возиться с NFS, когда можно просто использовать iSCSI сразу к блочному стораджу, монтировать файловую систему в ro, и поднимать aufs поверх этой файловой системы? Получите то же самое (много места, нормальная гибкость), только без промежуточного звена в виде виртуалки, предоставляющей NFS.
Окей, у вас отказоустойчивая NFS-шара в виде виртуалки. Её локальным диском является некоторый распределенный блочный сторадж.
Зачем же тогда возиться с NFS, когда можно просто использовать iSCSI сразу к блочному стораджу, монтировать файловую систему в ro, и поднимать aufs поверх этой файловой системы? Получите то же самое (много места, нормальная гибкость), только без промежуточного звена в виде виртуалки, предоставляющей NFS.
только если это pNFS4 или выше, иначе будет очень неприятно клиентам…
Действительно, у вас просто пока не «моргала» сеть…
Если NFS сервер отвалился в момент ожидания возврата из write/read, то процесс-обработчик уснёт непробудным сном. Как побочный эффект будет мёртвый mount в худшем случае до ближайшего ребута.
Да и вообще появляется лишняя сущность, сильно зависимая от погоды в сегменте сети, что есть нехорошо.
Да и вообще появляется лишняя сущность, сильно зависимая от погоды в сегменте сети, что есть нехорошо.
>NFS в целом удобнее — нет ограничений на размер, удобнее обновлять.
Если падает сеть, nfs отваливается. Если у вас на nfs root, то привет.
Если падает сеть, nfs отваливается. Если у вас на nfs root, то привет.
Вот есть проект для терминал сервера с загрузкой посети (тонкий и толстый клиенты) ltsp.org/. Возможно будет немного меньше велосипедов. Но есть ограничение по дистрибутивам.
А что хостит эти 14 дисков? СХД же какая-нибудь наверняка. Не логичнее ли грузится сразу с iSCSI? Если образ системы весит 200МБ (да хоть 1GB) расход места на загрузочные тома ничтожен, а геморрою меньше, да и сложность системы поменьше, а следовательно мест для ошибки и траблшутинга, если что, тоже меньше. А то что сеть моргает, так у меня статистически железо в серверах летит чаще, чем сеть моргает.
Не вижу смысла сжимать в SquashFS, разница пусть даже в 500 Мбайт занятой оперативки для современного сервера вообще ни о чём. Зато куда проще будет обновлять файлы и не потребуется AuthFS.
А можно было просто грузиться с флешки =)
Но с сетевой загрузкой есть свои плюсы, безусловно.
Но с сетевой загрузкой есть свои плюсы, безусловно.
Sign up to leave a comment.
Бездисковая загрузка по сети и жизнь после нее