Лучшие практики для монтирования Sun SAN NFS в Linux (Debian Squeeze)

Кто-нибудь получил лучшие практики, как смонтировать nfsshare от Sun(Oracle) Unified Storage? Мы запускаем обычный хард и nfs4 на debian squeeze. Мы запускаем наши виртуальные машины через этот общий ресурс NFS с Xen. Когда наша сеть SAN в пятницу потеряла диск и начала переворачивать (перестраивать), все общие ресурсы nfs остались прежними, и один из наших Dom0 вышел из строя довольно плохо, а общий ресурс nfs привел к падению большого количества vms. Есть ли варианты монтирования, которые делают это более легко ошибочным?

Источник

2 ответа

Я не знаю много о Debian и ни о NFSv4.

Но если параметры монтирования все те же, что и в NFSv3, мои любимые варианты (для любого nfs-client-mount и любого os):

  • трудно (поэтому продолжайте повторять без экспоненциального отсрочки повторных попыток)
  • bg (продолжайте пробовать в фоновом режиме, не останавливая что-либо "позади" монтировки)
  • intr (если вы действительно хотите - вы можете убить монтирование без перезагрузки вашего клиента)

В настоящее время rsize и wsize настроены на разумные размеры по умолчанию - посмотрите на вашу man-страницу lokcal.

Раньше я использовал "wsize = 32768, rsize = 32768", чтобы получить лучшие ставки трансфера до этого.

Вы также должны позаботиться о стороне сервера nfs (если NFSv4 здесь такой же, как NFSv3):

  1. Сначала запустите все NFS-сервисы
  2. Последний запуск Service-IP для NFS-Services

В противном случае клиент попытается восстановить соединение с пустым "nfs-сервисом" и потерпит неудачу вместо повторной попытки.

Кстати, какое отношение имеет SAN (в данном случае) к Sun Unified Storage? Что случилось, когда вы "потеряли" свой SAN? Почему процесс восстановления сломал вещи? Хранилище не было избыточным?

Источник

У меня была похожая проблема с XenServer не так давно, и я провел некоторые исследования по этому вопросу. Очевидно, по некоторым причинам XenServer использует мягкие монтирования с относительно коротким таймаутом для своих монтировок NFS. Некоторые люди предлагали изменить скрипт монтирования непосредственно на сервере xen, так как опции монтирования не могут быть изменены любым другим способом. Видимо, это единственный способ. У нас больше нет этой проблемы, так как сейчас мы на 100% используем vmware, и она более устойчива к замедлению работы NFS.

Однако настоящая проблема заключается в снижении производительности записи нижележащего хранилища, и она сильно зависит от вашего RAID-контроллера (т. Е. Насколько снижается производительность во время перестроений). Вы можете попробовать поиграть с приоритетными настройками перестройки массива, однако это не имеет значения на моем контроллере (Adaptec 5085). Вы можете немного улучшить ситуацию, купив больше памяти для сервера NFS. Таким образом, демон NFS будет записывать только записи журнала, но он будет хранить данные в кэше FS до лучших времен, но, опять же, это может или не может помочь в зависимости от вашей ситуации.

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

Источник
Другие вопросы по тегам