
Я планирую развернуть несколько компьютеров-киосков и хотел бы оставить им небольшую флешку в качестве загрузочного диска, а остальное разместить на сервере, где легко сделать резервную копию, например.ЛТСП.
Сейчас я обдумываю два варианта. NFSed /home/ или локальная копия ~/, скопированная при входе в систему и синхронизированная при выходе из системы.
Я опасаюсь, что работа с файлами может стать слишком медленной или моя сеть может выйти из строя.засорен.
решение1
Я использую 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.
решение2
Будьте осторожны с мягким монтированием! Мягкое монтирование файловой системы NFS означает, что IO-завершение произойдет после тайм-аута. Будьте уверены, что это именно то, что вам нужно в домашних каталогах пользователей! Я думаю, что нет. Использование жесткого монтирования в домашних каталогах в сочетании с опцией intr здесь кажется намного безопаснее.
Hard не будет тайм-аута: операции ввода-вывода будут повторяться бесконечно. Параметр intr позволяет прервать процесс монтирования. Поэтому, если вы монтируете экспорт и сталкиваетесь с ошибкой, hard-mount заблокирует ваш сеанс. Параметр intr позволит прервать монтирование, поэтому комбинация довольно безопасна и гарантирует, что вы не потеряете данные пользователя.
В любом случае, autofs делает все это еще проще.
решение3
HowtoForge опубликовал статью под названиемСоздание автономного сервера хранения данных типа NFS с GlusterFS на Debian Lenny, возможно, вам захочется это проверить.
Вот краткое описание того, почему это хорошая «осуществимая» альтернатива NFS, отGlusterFSстраница проекта:
GlusterFS самовосстанавливается на лету. Нет fsck. Хранилище доступно напрямую, как обычные файлы и папки (стиль NFS). При включенной репликации GlusterFS может выдерживать аппаратные сбои.
Более подробную информацию можно найти в проектной документации.
Еще одним преимуществом использования GlusterFS является то, что если вам нужно больше места в SAN, вы просто добавляете еще один блок хранения (узел сервера) и можете масштабировать/увеличивать свое хранилище параллельно по мере необходимости.
решение4
Несколько общих советов, которые будут актуальны независимо от того, какую сетевую файловую систему вы выберете: многие программы кэшируют данные в домашнем каталоге пользователя, что обычно приносит больше вреда, чем пользы, когда доступ к домашнему каталогу осуществляется по сети.
В наши дни вы можете указать многим программам хранить свои кэши в другом месте (например, на локальном диске), установив XDG_CACHE_HOME
переменную окружения в скрипте входа. Однако многие программы (например, Firefox) по-прежнему требуют ручной настройки, поэтому вам, вероятно, придется проделать дополнительную работу, чтобы идентифицировать и настроить их единообразно для всех ваших пользователей.