NFS и CIFS: что выбрать?

Прежде всего выбор NAS-протокола определяется принадлежностью IT-инфраструктуры, использующей NAS-устройство, к одному из двух «царств» - «Windows» или «UNIX».
«Родной» (native) протокол для Windows – CIFS, для UNIX (Linux, Solaris, AIX, FreeBSD и т.п.) – NFS. Конечно, в большинстве OS существует поддержка протоколов соседнего «царства». Так, например, NFS для Windows поставляется в бесплатном ныне продукте MS Services for UNIX 3.5 (SFU, бесплатно скачивается с вебсайта Microsoft) или SAMBA (www.samba.org, включен ныне в большинство дистрибутивов UNIX) для поддержки CIFS на UNIX. Но, разумеется, родной протокол для системы почти всегда предпочтительнее, хотя бы просто из соображений минимизации настроек и инсталляций, а значит ошибок администраторов и неожиданных проблем с производительностью.

Stateless и Stateful протоколы. Что это и чем грозит.

Протоколы файлового доступа NFS и CIFS, кроме принадлежности к двум «лагерям» UNIX и Windows, различаются также принципиальной разницей способов обращения к данным: т.н. stateless и stateful.
NFS это протокол stateless. Это означает, прежде всего то, что он по своей природе не сохраняет состояние соединения, и каждое обращение к файлу начинается «как с чистого листа». Причиной этого было то, что NFS изначально создавался как протокол доступа к данным по априори ненадежным, «глобальным» сетям. Между обращениям к файлу мог случиться обрыв и восстановление соединения, маршрут к файлу, с точки зрения сети, мог поменяться (что нормальная ситуация для TCP-сети). Все это не должно было оказывать влияния на процесс доступа к данным.
Для правильной обработки таких ситуаций была выбрана так называемая «stateless» модель соединения. При этом каждое обращение делается предполагая, что состояние соединения не сохраняется или не известно. Операция изменения байта в файле производится как «обратиться к файлу – проверить его существование – открыть файл на запись – записать байт – закрыть файл». При этом между операциями файл может исчезнуть, быть вновь создан, переместиться на другое устройство и так далее. С точки зрения протокола NFS это совершенно неважно. Состояние соединения между приложением и его файлом не хранится, и каждое соединение создается заново. Казалось бы излишние усилия и накладные расходы? Однако при общей аскетичности NFS как протокола (а создавался он еще во времена, когда модем на 2400 бод был вполне приемлемым средством доступа к данным), во многих случаях эти дополнительные операции с файлами не слишком обременяют процесс.

CIFS – Common Internet File System - Обобщенная Интернетная Файловая Система (также ранее известный как SMB – Server Message Blocks - Блоки Сообщений Сервера) рожден уже в наше время. Изначально он разрабатывался как сетевой протокол, применявшийся в среде системы Microsoft LAN Manager, сперва для DOS, а потом для Windows, как совместная разработка MS и IBM. Унаследовав технологии LAN Manager и его протокол SMB со времен DOS, войдя в новую OS Microsoft Windows и пройдя длинный путь развития, протокол был стандартизирован в 1987 году в IETF (RFC1001, RFC1002, IETF STD 19) под названием CIFS.
Это более сложный, чем NFS, протокол. Его область применения это уже гораздо более надежная LAN. Она позволила выбрать для него во многом более выгодную модель «stateful», при этом соединение будучи открыто, например, подразумевается открытым, его состояние сохраняется в OS, и оно не требует для каждой записи проходить все операции с самого начала: «проверили существование – открыли – записали байт – закрыли». Однако вследствие того, что NFS протокол более простой, и во многих местах даже примитивный (не забудьте, для какой среды он изначально проектировался), зачастую в ряде случаев он, несмотря на все дополнительные «накладные расходы», оказывается более быстродействующим. А для операций, связанных, например, с переподключением хранилища данных в кластерной или иной отказоустойчивой конфигурации, еще и более предпочтительным, за счет того, что изначально предполагает соединение между потребителем данных и его источником ненадежным и способным исчезнуть или измениться в любой миг.

Для использования NFS в среде Windows можно использовать бесплатно распространяемый ныне Microsoft продукт MS Services for UNIX (SFU), в который включен клиент для NFS. Поддержка протокола NFS для среды UNIX же обычно включена по умолчанию во все дистрибутивы.
Поддержка же CIFS в среде UNIX осуществляется через продукт под названием SAMBA, это результат reverse engineering-а сетевого обмена протокола и воссоздания средств использования протокола в независимом свободно распространяемом продукте. Такое непростое и чреватое будущими проблемами совместимости решение было выбрано потому, что, несмотря на свою стандартизацию в IETF, протокол CIFS закрыт и является собственностью Microsoft, что ограничивает его использвание в ряде случаев в продуктах т.н. «свободного программного обеспечения» (GNU). Официально лицензией на его использование владеют в настоящий момент два крупнейших производителя NAS, такие как Network Appliance и EMC. Лишь только они используют полнофункциональный протокол CIFS в своих независимых от MS продуктах. Остальные вынуждены либо использовать SAMBA, либо применять для него версию Windows Storage Server, несущий в себе CIFS по умолчанию.

3 комментария

  1. ivs:

    Роман,
    а NFSv4 является Stateful ONLY? И другой вопрос - при создании NFS-шары на NetApp я могу выбрать версию протокола - к примеру NFSv3 для доступа каких-нибудь удаленных офисов, которые как раз могут отваливаться и т.д. (для чего и нужен stateless), а VMWare положить на NFSv4 (stateful в выделенной LAN)?

  2. У меня стоит в плане разобраться с этой темой детальнее, но пока могу посоветовать прошерстить, например, записи вот этого человека:

    http://blogs.netapp.com/eislers_nfs_blog/2008/07/part-i-since-nf.html

    Это один из разработчиков спецификации NFS4, кстати.
    Там у него есть много интересного в блоге.

  3. bbk:

    Cсылка изменилась. Теперь это здесь

Оставить комментарий

20/0.135

Данный блог не спонсируется, не аффилирован, и не санкционирован компанией NetApp, Inc. Излагаемая в этом блоге точка зрения выражает мнение исключительно его автора и может не совпадать с позицией NetApp, Inc.

This content is not endorsed, sponsored or affiliated with NetApp, Inc. The views expressed in this blog are solely those of the author and do not represent the views of NetApp, Inc.