Восстановление Apache из смонтированного, недоступного монтирования NFS

У меня есть несколько веб-приложений в производстве, которые используют монтирование NFS для обмена ресурсами (обычно файлами статических ресурсов) между веб-головами. В случае, если монтирование NFS станет недоступным, Apache будет зависать, запрашивая файлы, к которым нет доступа, ядро ​​будет логировать:

Nov 2 14:21:20 server2 kernel: nfs: server server1 not responding, still trying

Я воспроизвел поведение в RHEL5 с NFS v3 и Apache 2.2.3:

  1. Создайте монтирование NFS на Server1 (содержимое моего /etc/exports)

    /srv/test_share server2(rw)

  2. Смонтируйте общий ресурс NFS на Server2 (содержимое моего /etc/fstab)

    server1:/srv/test_share /mnt/test_share nfs defaults 0 0

  3. Настройте виртуальный хост в Apache с помощью простого HTML-файла, ссылающегося на файлы изображений, хранящиеся в общем ресурсе NFS.

  4. Загрузите сайт, файлы html и изображения возвращают 200

  5. Размонтируйте общий ресурс NFS, загрузка страницы возвращает 404 для изображений, на которые есть ссылки.

  6. Перемонтируйте общий ресурс NFS

  7. Смоделируйте сбой NFS, отключив NFS на сервере 1 — перезагрузка сайта зависает при получении файлов, на которые есть ссылки.

Поиски в Интернете пока не дали хорошего решения. По сути, желательно, чтобы веб-сервер возвращал 404 и не зависал до тех пор, пока не восстановится монтирование NFS.

Ваше здоровье,

Бен


apache recovery nfs
person benr75    schedule 02.11.2009    source источник

Ответы (2)


arrow_upward
2
arrow_downward

пара вариантов:

  • Получите правильные параметры монтирования nfs, вам нужно выполнить мягкое монтирование, чтобы доступ к nfs мог быть прерван. попробуйте soft,intr,timeo=10 вместо default
  • синхронизируйте корни ваших документов с чем-то еще, например rsync, или создайте сценарий полуавтоматической проверки/экспорта из вашего SCM, если вы его используете. В любом случае рекомендуется использовать SCM, что дает вам возможность, например, вернуться к последней рабочей версии.
  • использовать настоящую распределенную файловую систему (желательно отказоустойчивую, например coda) или даже распределенная система блочных устройств, такая как drdb

Варианты 2 и 3 обеспечивают автономную работу и, следовательно, гораздо более надежны, чем nfs. drdb сексуален, но я бы посоветовал вариант 2 с чем-то вроде git или svn, простым и надежным.

person pfote    schedule 02.11.2009
comment
Мягкое монтирование и установка значения тайм-аута позволяют apache возвращать 404 с. Следующий шаг: отслеживание монтирования... Я установил тайм-аут немного ниже, равный 2. Когда монтирование NFS стало доступным, все снова обслуживалось должным образом. - person benr75; 04.11.2009
comment
у меня тоже сработало, но мне также пришлось добавить «proto=udp», чтобы избежать больших задержек в тайм-аутах. С «proto=tcp» (по умолчанию на моей машине) тайм-ауты сначала появлялись достаточно быстро, но особенно под нагрузкой они имеют тенденцию ухудшаться, появляясь только через 20 секунд или около того. Я рад, что нагрузил конфиг (простым вызовом ab), иначе бы не заметил этого странного поведения. - person Clemens Klein-Robbenhaar; 06.07.2013

arrow_upward
0
arrow_downward

Я бы не стал напрямую обслуживать с монтирования NFS, а вместо этого из вашей локальной файловой системы.

Было бы несложно настроить задание cron, которое каждые несколько минут синхронизировало бы монтирование NFS с локальной файловой системой. Apache будет обслуживать свой контент оттуда, независимо от монтирования NFS. Если монтирование выйдет из строя, Apache все равно сможет обслуживать активы, хотя они могут быть устаревшими, пока не восстановится монтирование NFS.

person Cullen Walsh    schedule 02.11.2009
comment
Это было бы идеально, и решение, которое мы использовали, не будет работать в ситуации, когда веб-голова имеет небольшой жесткий диск на 50 ГБ и активы на 250 ГБ. Мы также использовали S3 в качестве альтернативы, но многие файлы требуют манипулирования и представляют собой нечто большее, чем просто статические активы. - person benr75; 03.11.2009