Разумно ли использовать NFS на рабочем веб-сервере?

Разумно ли использовать NFS на рабочем веб-сервере?

Можно ли обоснованно использовать NFS на производственных серверах в качестве средства подключения вычислительного сервера к серверу хранения данных, предполагая, что соединение осуществляется по локальной сети со скоростью 1Gbe или 10Gbe?

Очевидно, что есть некоторые сетевые издержки, и NFS выглядит особенно медленно при записи, если у вас включен режим синхронизации. В остальном он кажется достаточно легким и масштабируемым, насколько я могу судить, но у меня мало личного опыта с ним. Я не прав?

Проблема в том, что у меня сейчас есть сервер, который действует как хранилище и веб-сервер, но в будущем мне, скорее всего, придется разделить эти два сервера, а учитывая, что некоторые запросы должны проходить через уровень веб-приложений для аутентификации перед инициализацией передачи файлов, с этим программным обеспечением становится довольно сложно. Сетевое монтирование fs — это самый простой вариант, я просто... не знаю, хороший ли он.

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

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

решение1

NFS подходит, если не соблюдены некоторые другие критерии, а именно:

  • Обе задействованные системы могут использовать NFS изначально. Windows здесь не в счет, онавродеработает, но у него много странностей, и с ним часто трудно работать, когда имеешь дело с NFS в кроссплатформенной среде (и если этотолькоWindows, используйте SMB3, он устраняет большинство других проблем с NFS). Обратите внимание, что на стороне клиента это означает поддержку на уровне ядра, поскольку реализация на уровне пользователя должна либо решать проблемы эффективности, присущие использованию чего-то вроде FUSE, либо должна быть напрямую связана с приложением, которому требуется доступ к общему ресурсу.
  • Вы правильно проверили, как клиент NFS обрабатывает перезапуск сервера NFS. Это включает в себя как саму ОС (котораядолженв большинстве случаев будет в порядке), и программное обеспечение, которое будет получать доступ к общему ресурсу. В частности, особая осторожность необходима на некоторых клиентских платформах, когда программное обеспечение, использующее общий ресурс, удерживает файлы открытыми в течение длительного времени, поскольку не все реализации клиента NFS изящно обрабатывают перезагрузки сервера, явно перемонтируя и перепроверяя блокировки и дескрипторы файлов, как они должны (что приводит к различным проблемам для клиентского программного обеспечения). Обратите внимание, что вам следует перепроверять это каждый раз, когда какая-либо часть стека обновляется или перенастраивается.
  • Вы готовы настроить правильное сопоставление идентификаторов пользователей/групп. Это важно, потому что без этого вам либо придется зеркалировать сопоставления UID/GID между системами (это выполнимо, но я бы поостерегся настраивать SSO для внутренней сети для системы, подключенной к Интернету), либо вы столкнетесь с потенциально серьезными проблемами безопасности (а именно, то, что вы видите в одной системе для разрешений, не будет соответствовать тому, что вы видите в других).
  • Вы работаете через защищенное сетевое соединение или хотите правильно настроить аутентификацию для общего ресурса. Без аутентификации любой, кто находится по ссылке, может получить к нему доступ (а вредоносный клиент может легко обойти базовые дискреционные средства управления доступом UNIX).

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

решение2

NFS абсолютно приемлем и предпочтительнее iSCSI, поскольку NFS гораздо проще в управлении, совместном использовании и резервном копировании.

решение3

Мы годами используем NFS для подключения нашего SAN к нашим серверам VMware ESXi, запуская на нем сотни виртуальных машин. Никаких проблем.

Узким местом является скорее система хранения данных, чем сетевой протокол.

Сетевое соединение должно быть достаточно быстрым, конечно, имеется в виду 10Gb Ethernet или оптоволокно. Мы даже больше не заморачиваемся с отдельной сетью хранения.

решение4

iSCSI может быть немного быстрее...

https://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/techpaper/storage_protocol_comparison-white-paper.pdf

https://www.hyper-v.io/whos-got-bigger-balls-testing-nfs-vs-iscsi-performance-part-3-test-results/

...но NFS, как и любой другой сетевой редиректор (SMB3, AFS/AFP и т. д.), допускает одновременный множественный доступ, что затруднительно при использовании iSCSI или других блочных протоколов.

https://forums.starwindsoftware.com/viewtopic.php?f=5&t=1392

Связанный контент