Доступ к файлам, расположенным в базовой файловой системе точки монтирования NFS

8

Возможно, это странный запрос, но он противоположен вопросу, подробно изложенному по адресу:

Можно ли просмотреть содержимое базового монтирования NFS без размонтирования содержимого NFS?

У меня есть договоренность, где серверы Linux на нескольких удаленных сайтах монтируют общий ресурс NFS с центрального сервера (все CentOS 5.x). Подумайте: /opt/softwareили что-то подобное.

Если все хорошо, клиентские системы монтируют экспорт NFS с главного сервера и работают без инцидентов. Данные, содержащиеся в общем ресурсе, меняются не часто (возможно, еженедельно).

Я обеспокоен ситуацией, когда происходит потеря подключения к основному NFS-серверу (перерыв в работе NFS-сервера, отключение оптоволокна и т. Д.). В связи с тем, что общие данные меняются не часто, я бы хотел, чтобы эти системы могли работать автономно, если они теряют монтирование NFS.

Скажем, монтирование прошло, я хотел бы использовать локальные файлы, которые находятся /opt/softwareпод монтированием NFS в том же месте. Кроме того, я бы ежедневно синхронизировал эти файлы.

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

Это возможно? Как получить доступ (или перезаписать) файлы в базовом каталоге? Будут ли проблемы с тайм-аутом? Есть ли варианты / советы по монтированию, которые могут помочь с этим?

— ewwhite
источник

16

mount -o bind / /mnt

Когда вы посмотрите на / mnt / opt / software, вы найдете файлы (если таковые имеются), которые находятся под монтированием в / opt / software.

— Сет Робертсон
источник

Но это смонтирует всю корневую файловую систему в / mnt. Хм ...

— Ewwhite

1

Так? Какой вред это собирается сделать? Это просто позволяет синхронизировать файлы, которые вы хотите. Вы даже можете поместить его в / private / root, где / private равно 700 root, чтобы никто другой не смог получить доступ к этим файлам, не то чтобы это принесло бы вред, если бы они могли, поскольку у них точно такие же разрешения. Это похоже на точный ответ на ваш вопрос. Теперь, если ваш вопрос заключается в том, как восстановить систему после того, как NFS-сервер исчезнет, это будет совсем другое дело и, вероятно, включает принудительное отключение. Это лишит законной силы и таким образом сломает половину ваших процессов, заставляя перезагрузку так или иначе.

— Сет Робертсон

Это было близко, но я решил просто смонтировать каталог, к которому мне нужен доступ, с параметром bind, в другое место в файловой системе.

— ewwhite

На самом деле это очень полезно в конкретном случае, и я хотел бы знать об этой опции давным-давно. Я просто столкнулся с этой ситуацией снова. По сути, у меня был каталог / usr, который был привязан к корневой файловой системе, и я хотел переместить его в свою собственную файловую систему, чтобы освободить место в корневом каталоге. Итак, сделав usr и перенеся туда данные и перезагрузившись, чтобы смонтировать новый usr, как легко удалить старые данные / usr? Один из способов - использовать однопользовательский режим и надеяться, что файлы там не используются. Другой способ - использовать этот трюк связывания и удалить каталог данных из альтернативного пути.

— Deltaray

8

Это возможно с помощью mount --bindопции.

Since Linux 2.4.0 it is possible to remount part of the file hierarchy somewhere else. The call is
   mount --bind olddir newdir
After this call the same contents is accessible in two places.

Так я смог mount --bind /opt/software /foo

А затем примените монтирование NFS /opt/software, сохраняя возможность видеть базовые файлы в /foo.

— ewwhite
источник

3

Что вам может понадобиться, так как файлы относительно статичны, это rsync. Если несколько удаленных клиентов не имеют возможности изменять файлы. Если данные в основном предназначены только для чтения, почему бы просто не выполнять rsync пару раз в день с помощью какого-либо cron-подобного задания на каждой машине. Опять же, я могу упустить момент, но если данные в NFS в основном предназначены только для чтения, это может сделать это.

— Slashdot
источник

Rsync традиционно имеет смысл, но есть вероятность, что файлы будут изменены на любом сайте. Если бы я монтировал только для чтения, rsync был бы лучшим выбором. Если вы не знаете о решении двусторонней синхронизации ...

— ewwhite

Одна вещь, которую вы можете сделать с помощью rsync, это настроить работу cron, которая проверяет временные метки ваших файлов на каждой машине и, возможно, делает это каждые 5 минут. Как только замечено обновление, отправьте файлы в nfs, и в то же время, возможно, создайте файл триггера, который проверяется на всех других машинах через фиксированный период времени. Как только они видят этот триггер, все они запускают rsync для получения большинства обновленных файлов из NFS.

— Слэшдот

Я могу попробовать Unison как подход к решению этой проблемы.

— Ewwhite