Я планирую развернуть несколько компьютеров-киосков и хотел бы оставить их с небольшим флеш-накопителем в качестве загрузочного диска, оставив остальные на легком для резервного копирования сервере, аля LTSP.
Прямо сейчас обдумываю два варианта. NFSed / home / или локальная копия ~ /, скопированная при входе в систему, синхронизированная при выходе из системы.
Я опасаюсь, что работа с файлами может стать слишком медленной или моя сеть забит.
Я использую NFS для своих домашних каталогов в нашей производственной среде. Есть пара хитростей.
Не монтировать NFS в /home - таким образом у вас может быть локальный пользователь, который позволит вам войти в случае, если сервер NFS выйдет из строя. Мы монтируемся на /mnt/nfs/home
Используйте мягкие крепления и очень короткий тайм-аут - это предотвратит блокировку процессов навсегда.
Использовать автомастерская. Это снизит использование ресурсов, а также означает, что вам не нужно беспокоиться о перезапуске служб, когда сервер NFS выходит из строя, если он по какой-то причине выходит из строя.
auto.master:
+auto.master
/mnt/nfs /etc/auto.home --timeout=300
auto.home
home -rw,soft,timeo=5,intr home.bzzprod.lan:/home
Используйте систему единого входа, чтобы не столкнуться с проблемами, связанными с разрешениями. У меня есть сервер OpenLDAP.
HowtoForge опубликовал статью под названием Создание NFS-подобного автономного сервера хранения с GlusterFS в Debian Lenny, возможно, вы захотите это проверить.
Вот краткое описание того, почему это хорошая «осуществимая» альтернатива NFS, из GlusterFS страница проекта:
GlusterFS самовосстанавливается на лету. Нет fsck. Серверная часть хранилища доступна напрямую в виде обычных файлов и папок (стиль NFS). При включенной репликации GlusterFS может выдерживать отказы оборудования.
Более подробную информацию можно найти в документации по проекту.
Кроме того, еще одна приятная вещь в использовании GlusterFS заключается в том, что если вам нужно больше места в вашей SAN, вы просто добавляете еще один блок хранилища (серверный узел), и вы можете параллельно масштабировать / увеличивать хранилище, когда это необходимо.
Будьте осторожны с мягкими креплениями! Мягкое монтирование файловой системы NFS означает, что ввод-вывод завершится с ошибкой по истечении тайм-аута. Будьте уверены, что это именно то, что вам нужно в домашних каталогах пользователей! Думаю, ты не знаешь. Здесь намного безопаснее использовать жесткое монтирование домашних каталогов в сочетании с опцией intr.
Жесткое отключение тайм-аута: операции ввода-вывода будут повторяться бесконечно. Опция intr позволяет прервать процесс монтажа. Поэтому, если вы смонтируете экспорт и обнаружите сбой, жесткое монтирование заблокирует ваш сеанс. Параметр intr позволяет прервать монтирование, поэтому комбинация довольно безопасна и гарантирует, что вы не потеряете данные пользователя.
В любом случае, autofs делает все это еще проще.
Следует отметить, что когда сервер NFS отключен - ваши монтирования будут зависать - выполнение мягкого монтирования не будет блокировать, поэтому самого «зависания» можно избежать, однако это не решит проблему домашних каталогов, как без дома. каталог, пользователь все равно облажался.
Даже когда сервер NFS восстанавливается, если вы что-то с этим не сделаете, проблема с зависанием останется - вам придется остановить процесс на монтируемой машине и перемонтировать. Причина этого в том, что когда сервер NFS возвращается в исходное состояние, ему назначается другой fsid - так что вы можете хотя бы решить эту проблему, жестко закодировав fsids на сервере NFS, например ...
#. Home Directories
/usr/users \
192.168.16.0/22(rw,sync,no_root_squash,fsid=1) \
192.168.80.0/22(rw,sync,no_root_squash,fsid=1)
#. Scratch Space
/var/ftp/scratch \
192.168.16.0/22(rw,async,no_root_squash,fsid=3) \
192.168.80.0/22(rw,async,no_root_squash,fsid=3) \
172.28.24.151(rw,async,root_squash,fsid=3)
В exports(5) страница руководства сообщает ...
fsid=num
This option forces the filesystem identification portion of the file handle
and file attributes used on the wire to be num instead of a number derived
from the major and minor number of the block device on which the filesystem
is mounted. Any 32 bit number can be used, but it must be unique amongst
all the exported filesystems.
This can be useful for NFS failover, to ensure that both servers of the
failover pair use the same NFS file handles for the shared filesystem thus
avoiding stale file handles after failover.
... Хотя это означает, что до тех пор, пока основные / второстепенные номера не меняются (что обычно не происходит, за исключением случаев, когда вы экспортируете тома SAN / multipath, где они могут измениться), я обнаружил, что полностью устранили проблему - то есть, если сервер NFS возвращается - соединение было восстановлено быстро - я до сих пор не знаю, почему это повлияло на такие устройства, как /dev/sdaX например.
Теперь я должен указать, что мои аргументы в основном анекдотичны - на самом деле не имеет смысла, почему он устранил проблему, но «кажется», что исправил ее - каким-то образом - вероятно, здесь есть другие переменные, которые я еще не обнаружено. знак равно
Несколько общих советов, которые будут применяться независимо от того, какую сетевую файловую систему вы используете: многие программы кэшируют данные в домашнем каталоге пользователя, что обычно приносит больше вреда, чем пользы, когда доступ к домашнему каталогу осуществляется по сети.
В наши дни вы можете указать многим программам хранить свои кэши в другом месте (например, на локальном диске), установив параметр XDG_CACHE_HOME переменная среды в сценарии входа в систему. Однако многие программы (например, Firefox) по-прежнему требуют ручной настройки, поэтому вам, вероятно, придется проделать некоторую дополнительную работу, чтобы идентифицировать и настроить их единообразно для всех ваших пользователей.
Во многих местах, где я работал, используются домашние каталоги, смонтированные по NFS. Обычно нет большой разницы в производительности (и пользователи киосков, вероятно, немного менее требовательны, чем разработчики, которые знают, как связаться со своим местным ИТ-специалистом). Одна проблема, которую я видел, - это то, что происходит, когда я захожу на рабочий стол Gnome, а сервер NFS отключается по каким-либо причинам. Вещи перестают отвечать.
Я использую домашний NFSed, и он отлично работает. но вы должны убедиться, что сеть достаточно быстра и никогда не выйдет из строя.
С практической точки зрения, NFS хорошо работает для домашнего каталога при наличии коммутируемой сети 100 Мбит или выше. Для более чем 10-20 киосков сервер должен иметь гигабитное соединение. Вы не выиграете соревнования по производительности, но такие вещи, как Firefox и Open Office, будут работать нормально.
Копирование в домашний каталог будет серьезной проблемой с точки зрения задержек при входе в систему (в сети 100 Мбит / с макс. 12 МБ / с. Домашний каталог 100 МБ близок к 10 секундам). Rsync будет мешать вам синхронизировать кеш веб-браузера ... 10 минут и 500 файлов болят.
Посмотри на cachefilesd. Сам не использовал, но выглядит многообещающе.
Демон cachefilesd управляет файлами и каталогами кеширования, которые используются сетевыми файловыми системами, такими как AFS и NFS, для постоянного кэширования на локальный диск.
Также не забудьте настроить параметры rsize и wsize и, если возможно, использовать Jumbo-кадры.