Добрый день!
Возникло желание переместить содержимое /var/calculate с локальных дисков calculate-сервера на шару, монтируемую по NFS с сетевого дискового массива. Соответственно, хочу узнать, существуют ли весомые причины НЕ делать так. Пропускная способность сетевых интерфейсов на сервере и на массиве - 1 Гбит/с, есть возможность задействовать “выделенный канал” (т.е. напрямую соединить интерфейсы сервера и массива).
С уважением, Сергей Мусорин.
Соответственно, хочу узнать, существуют ли весомые причины НЕ делать так.
Особых причин так не делать нет(я не вижу)
Единственное, что надо учесть - параметры шар на сервере
Для pxe-сервера я использую параметры
ro,no_root_squash,acl,insecure,async,no_subtree_check,crossmnt
Последний нужен чтоб смонтированные “поверх” поддиректорий шары пути были доступны через шару.
Позвольте поинтересоваться, зачем вам это необходимо?
Особого смысла вы от этого не получите, т.к. придётся делать ещё и шару на /var/cache/edb/dep/usr/portage см. Portage via NFS
и всё равно будут возникать коллизии разной степени обновлённости разных серверов.
Я уже с этим встречался, вдруг один из серверов переставал обновлятся из-за ошибок по зависимостям. Лечилось отказом от этих шар и обновлением сервера локально, потом монтированием обратно.
На самом деле ваш вопрос звучит так — Portage via NFS.
Но реально выход был бы, если создать в локальной сети зеркало calculate, например как в яндексе. И прописыванием в make.conf
GENTOO_MIRRORS="rsync://…"
PORTAGE_BINHOST="http://…"
Если у кого-то есть такое хавту, то буду благодарен.
P.S.
Да, если будете делать, то на dns лучше не рассчитывать и прописать в /etc/hosts всё что нужно.
К такому решению меня привел ряд объективных и субъективных факторов 
На самом деле я имею в виду не расшаривание portage для совместного его использования несколькими серверами, а именно вынос /var/calculate на внешнее (по отношению к серверу) хранилище.
Сервер был развернут примерно 3 года назад, его корневой раздел, своп и раздел calculate были размещены на md raid-зеркалах. Помимо стандартных сервисов calculate он используется как host system для 10-15 виртуальных машин (и эта его функция - основная).
За прошедшее время на сервере вышли из строя и были заменены 3 жестких диска. Также, за прошедшее время появились достаточно надежные SSD накопители, на которые были перенесены файлы ВМ, что радикально подняло их производительность. Помимо этого, около полугода назад был введен в строй дисковый массив, на котором сейчас доступно более дешевое (в пересчете на Мб), более быстрое (RAID10 вместо зеркала) и более надежное (за счет меньшего износа дисков) пространство. Закономерно возникает желание переложить на него все, кроме ВМ, свопа и корня.
В ближайшей перспективе это должно повысить надежность хранения данных на разделе calculate и позволит “более спокойно” перебрать дисковую систему сервера. В более отдаленной - позволит абстрагировать “готовые к употреблению” данные сервера от конкретного сервера (и при выходе его из строя достаточно будет включить другой, предварительно настроенный на монтирование шары calculate, сервер - и пользователи получат быструю и полноценную замену).
В принципе не столь важны причины.
Если у вас будет только эта машина писать на эту nfs-шару, то проблем конечно не будет.
PS:
У меня сложнее, у меня сервера в виртуалках. На данный момент это XCP. И с этим в gentoo вообще и calculate как частный случай вообще то плохо.
Всё хочу сам создать оверлей с xen/xapi, «правильным» ядром?чтобы был аналог XCP и вот таким централизованным обновлением, так как выпускать каждую виртуалку в инет накладно.
Но пока руки не доходят.
Да, в любой конкретный момент времени с шарой будет работать “на запись” только один сервер. То есть “резервный” может включаться только при выключенном “основном”. Просто хотелось уточнить, нет ли какой-нибудь “идеологической” причины, по которой на отдельном локальном дисковом разделе calculate держать можно, а на nfs-шаре - нельзя.
Сергей Мусорин wrote:
Просто хотелось уточнить, нет ли какой-нибудь “идеологической” причины
Это же gentoo. Тут таких причин нет по-умолчанию 