![Разумно ли использовать NFS на рабочем веб-сервере?](https://rvso.com/image/756229/%D0%A0%D0%B0%D0%B7%D1%83%D0%BC%D0%BD%D0%BE%20%D0%BB%D0%B8%20%D0%B8%D1%81%D0%BF%D0%BE%D0%BB%D1%8C%D0%B7%D0%BE%D0%B2%D0%B0%D1%82%D1%8C%20NFS%20%D0%BD%D0%B0%20%D1%80%D0%B0%D0%B1%D0%BE%D1%87%D0%B5%D0%BC%20%D0%B2%D0%B5%D0%B1-%D1%81%D0%B5%D1%80%D0%B2%D0%B5%D1%80%D0%B5%3F.png)
Можно ли обоснованно использовать 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.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