Надежное хранилище с drbd9 и proxmox (часть 1: nfs)

Настройка nfs в Ubuntu 16.04

Сетевая файловая система NFS или Network File System, это популярный протокол сетевой файловой системы, который позволяет пользователям подключать удаленные сетевые каталоги на своей машине и передавать файлы между серверами.

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

По сути, это альтернатива общего доступа Windows для Linux, в отличие от Samba реализована на уровне ядра и работает более стабильно.

В этой статье будет рассмотрена установка nfs в Ubuntu 16.04. Мы разберем установку всех необходимых компонентов, настройку общей папки, а также подключение сетевых папок.

Немного теории

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

В отличие от других протоколов NFS предоставляет прозрачный доступ к удаленным файлам.

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

Установка компонентов NFS

Перед тем как мы сможем работать с NFS, нам придется установить несколько программ. На машину, которая будет сервером нужно установить пакет nfs-kernel-server, с помощью которого будет выполнено открытие шары nfs в ubuntu 16.04. Для этого выполните:

sudo apt install nfs-kernel-server

Теперь давайте проверим правильно ли установился сервер. Сервис NFS слушает соединения как для TCP, так и для UDP на порту 2049. Посмотреть действительно ли сейчас используются эти порты можно командой:

rpcinfo -p | grep nfs

Также важно проверить поддерживается ли NFS на уровне ядра:

cat /proc/filesystems | grep nfs

Видим, что работает, но если нет, нужно вручную загрузить модуль ядра nfs:

modprobe nfs

Давайте еще добавим nfs в автозагрузку:

sudo systemctl enable nfs

На клиентском компьютере вам нужно установить пакет nfs-common, чтобы иметь возможность работать с этой файловой системой. Вам необязательно устанавливать компоненты сервера, достаточно будет только этого пакета:

sudo apt install nfs-common

Вот и все, дальше настройка nfs ubuntu.

Настройка сервера NFS в Ubuntu

Мы можем открыть NFS доступ к любой папке, но давайте создадим для этих целей новую:

sudo mkdir /var/nfs

Дальше нас интересует настройка ubuntu nfs server. Все общие папки и другие настройки nfs находятся в файле /etc/exports. Синтаксис записи папки такой:

адрес_папки клиент (опции)

Адрес папки – это та папка, которую нужно сделать доступной по сети. Клиент – ip адрес или адрес сети, из которой могут получить доступ к этой папке. А вот с опциями немного сложнее. Рассмотрим некоторые из них:

• rw – разрешить чтение и запись в этой папке
• ro – разрешить только чтение
• sync – отвечать на следующие запросы только тогда, когда данные будут сохранены на диск (по умолчанию)
• async – не блокировать подключения пока данные записываются на диск
• secure – использовать для соединения только порты ниже 1024
• insecure – использовать любые порты
• nohide – не скрывать поддиректории при, открытии доступа к нескольким директориям
• root_squash – подменять запросы от root на анонимные
• all_squash – превращать все запросы в анонимные
• anonuid и anongid – указывает uid и gid для анонимного пользователя.

Например, для нашей папки эта строка может выглядеть вот так:

/var/nfs 127.0.0.1(rw,sync,no_subtree_check)

Когда все было настроено, осталось обновить таблицу экспорта NFS:

sudo exportfs -a

Вот и все, открытие шары nfs в ubuntu 16.04 завершено. Теперь попытаемся настроем клиента и попытаемся ее примонтировать.

Подключение NFS

Мы не будем подробно останавливаться на этом вопросе в сегодняшней статье. Это довольно большая тема, заслуживающая отдельной статьи. Но пару слов я все же скажу.

Чтобы подключить сетевую папку вам не нужен никакой nfs клиент ubuntu, достаточно использовать команду mount:

 sudo mount 127.0.0.1:/var/nfs/ /mnt/

Теперь вы можете попытаться создать файл в подключенной директории:

touch /mnt/test

Также мы посмотрите подключенные файловые системы с помощью df:

df -h

127.0.0.1:/var/nfs 30G 6,7G 22G 24% /mnt

Чтобы отключить эту файловую систему достаточно использовать стандартный umount:

sudo umount /mnt/

Предварительные требования

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

• Два сервера Ubuntu 20.04. На каждом из них должен быть настроен пользователь без прав root с привилегиями , брандмауэр UFW и частные сети, если они вам доступны.

  • Указания по настройке пользователя без прав root с привилегиями и брандмауэра можно найти в руководстве «Начальная настройка сервера Ubuntu 20.04».
  • Если вы используете для своих сервера и клиента дроплеты DigitalOcean, вы можете узнать больше о настройке частной сети в нашей документации по созданию VPC.

В этом обучающем модуле мы будем называть хостом сервер, который предоставляет доступ к своим каталогам, а клиентом — сервер, который монтирует эти каталоги. Вам нужно будет знать IP-адреса обеих систем. Обязательно используйте адрес частной сети, если он известен.

В этом обучающем модуле мы будем замещать эти IP-адреса сокращениями и . Замените эти сокращения необходимыми IP-адресами.

NFS версии 4

Протокол NFSv4 является, как мы отметили, протоколом, сохраняющим свое состояние. Такое поведение сделали возможным несколько радикальных изменений. Мы уже упоминали, что должны вызываться вспомогательные протоколы, так как процессы пользовательского уровня были устранены. Вместо них все операции по открытию файла и довольно много RPC-вызовов были реализованы в виде операций файловой системы уровня ядра.

Все NFS-версии определяли каждую единицу работы в понятиях операций RPC-клиента и сервера. Каждый NFSv3-запрос требовал довольно значительного количества RPC-вызовов и вызовов операций открытия портов для выдачи результата. Версия 4 упростила это, введя понятие так называемой составной (compound) операции, к которой относится большое количество операций над объектами файловой системы. Прямым эффектом, разумеется, стало значительно меньшее количество RPC-вызовов и меньший объем данных, которые нужно передавать по сети, даже при том, что каждый RPC-вызов нес, по сути, больше данных, выполняя значительно больший объем работы. Было приблизительно подсчитано, что RPC-вызовы в NFSv3 требовали в пять раз большее количество клиент-серверных взаимодействий по сравнению с составными RPC-процедурами.

RPC, на самом деле, больше не имеет такой важности и, по существу, служит оболочкой (wrapper) над несколькими операциями, инкапсулированными в NFSv4-стеке. Также это изменение сделало стек протокола намного менее зависимым от семантики используемой файловой системы

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

Удаленный вызов процедуры (RPC) – основа NFS

RPC является библиотекой процедур. Процедуры позволяют клиенту напрямую отправлять серверу процедурные вызовы так, как если бы процесс клиента выполнял все вызовы в своем адресном пространстве. Так как клиент и сервер являются двумя отдельными процессами, им не нужно находиться на одной физической системе

Поскольку процессы клиента и сервера могут находиться на двух различных системах, которые могут работать на двух различных аппаратных платформах, RPC должен обращать внимание на возможность того, что две системы могут не поддерживать одновременно один и тот же формат данных. Поэтому RPC использует типы данных, определенные протоколом eXternal Data Representation (стандарт для аппаратно-независимых структур данных, XDR)

До AIX 4.2.1, UDP (User Datagram Protocol) был единственным транспортным протоколом для NFS-пакетов. TCP (Transmission Control Protocol) был добавлен в качестве альтернативного протокола в AIX 4.2.1. UDP хорошо работает в «чистых» сетях и на надежных серверах. Для больших или загруженных сетей или сетей с медленными серверами TCP может обеспечить лучшую производительность, поскольку его встроенная возможность управления потоками может уменьшить повторную передачу данных по сети.

Также до AIX 4.3, UDP был транспортным протоколом по умолчанию для NFS Version 2 и 3. В AIX 4.3 и более поздних версиях, TCP является протоколом по умолчанию для NFS Version 3, но, используя новую опцию монтирования (proto), клиент может выбрать TCP или UDP. Например:

Из-за более высокой скорости и простоты UDP является предпочтительным протоколом для NFS. Однако, хотя этот протокол и быстрый, он ненадежный. Сеть не гарантирует что пакеты, передаваемые через UDP, будут доставлены или что они будут доставлены по порядку. NFS пытается устранить эту проблему, требуя от NFS-сервера, чтобы он подтверждал прием каждой команды RPC отправкой клиенту кода, который должен указывать успешно была выполнена команда или нет. Если NFS-клиент не получает подтверждения в течение какого-либо определенного периода времени, он повторно передает команду.

Каковы последствия применения этого метода? Если клиент не получил подтверждения, значит UDP потерял или исходную команду RPC, или подтверждение приема RPC команды. Если исходная команда RPC была потеряна, сервер обработает эту команду как в первый раз после того, как она была повторно передана. Но если было утеряно подтверждение о приеме, сервер обработает одну и ту же команду RPC дважды.

Для большинства команд NFS это дублирование запросов не представляет проблемы. С , например, не будет иметь никакого значения, если один и тот же блок данных будет прочитан один или несколько раз. Другие команды, однако, не могут быть выполнены два раза подряд. Например, во второй раз выполнена не будет. Для команд, подобных этой, некоторые NFS-серверы содержат кэш последних 400 команд, которые были выполнены. Когда сервер получает запрос , он сначала проверяет кэш, чтобы узнать, не получал ли он только что другой запрос . Если так оно и есть, сервер только повторно передает подтверждение. Если клиент NFS так и не получил подтверждения, клиент будет передавать команду серверу раз за разом, удваивая время повторения запроса. Если сетевая файловая система была смонтирована с опцией soft, то, в конечном счете, время выполнения запроса истечет; если с опцией hard – клиент будет продолжать отсылать запрос до тех пор, пока его не перезагрузят или не придет подтверждение. (Более подробно об этих опциях будет рассказано позже).

Что такое NFS и зачем это нужно

Каждый знает, что в UNIX-системах файловая система логически представляет собой набор физических файловых систем, подключенных к одной точке. Одна из самых основных прелестей такой организации, на мой взгляд, состоит в возможности динамически модифицировать структуру существующей файловой системы. Также, благодаря усилиям разработчиков, мы на сегодняшний день имеем возможность подключить ФС практически любого типа и любым удобным способом. Говоря «способом», я прежде всего хочу подчеркнуть возможность работы ядра ОС с файловыми системами посредством сетевых соединений.

Множество сетевых протоколов предоставляют нам возможность работы с удаленными файлами, будь то FTP, SMB, Telnet или SSH. Благодаря способности ядра, в конечном итоге, не зависеть от типа подключаемой ФС, мы имеем возможность при помощи программы mount подключать что угодно и как угодно.

Сегодня мне хочется рассказать об NFS — Network File System. Эта технология позволяет подключать отдельные точки ФС на удаленном компьютере к файловой системе локального компьютера. Сам протокол NFS позволяет выполнять операции с файлами достаточно быстро, безопасно и надежно. А что нам еще нужно?

Критика NFS

Критика способствует улучшению

Критика, связанная с защищенностью NFS, была причиной многих улучшений в NSFv4. Создатели новой версии провели реальные мероприятия по усилению защищенности клиент-серверных взаимодействий. Фактически, они решили реализовать абсолютно новую модель системы защиты.

Для понимания модели системы защиты вы должны ознакомиться с интерфейсом прикладного программирования Generic Security Services (GSS-API) версии 2, редакции 1. GSS-API полностью описан в RFC 2743, который, к сожалению, является одним из наиболее сложных для понимания RFC-документов.

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

Соединения между NFS-клиентами и серверами защищаются посредством так называемой (довольно поверхностно) системы защиты strong RPC. NFSv4 использует стандарт Open Network Computing Remote Procedure Call (ONCRPC), определенный в RFC 1831. Система защиты должна была быть усилена, поэтому вместо простой аутентификации (известной как AUTH_SYS) как обязательная часть протокола NFSv4 была определена и реализована разновидность основанной на GSS-API системы защиты, известная под названием RPCSEC_GSS. К наиболее важным доступным в NFSv4 механизмам защиты относятся Kerberos версии 5 и LIPKEY.

Если Kerberos имеет ограничения при использовании в Интернет, то у LIPKEY есть приятное преимущество — работая как Secure Sockets Layer (SSL), он запрашивает у пользователей их имена и пароли, избегая, в то же время, TCP-зависимости от SSL — зависимости, которую NFSv4 не разделяет. Вы можете настроить NFS на реализацию разновидностей системы защиты, если RPCSEC_GSS не требуется. Предыдущие версии NFS не имели такой возможности и, следовательно, не могли обеспечить качественную защиту, целостность данных, требования по аутентификации или типы шифрования.

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

Сделав порт 2049 обязательным для NFS, стало возможным использование NFSv4 с брандмауэрами (firewall) без необходимости уделять слишком большое внимание тому, какие порты прослушивали другие протоколы, например, протокол Mount. Таким образом, исключение протокола Mount имело несколько положительных эффектов:

• Обязательные механизмы строгой аутентификации: NFSv4 сделал механизмы строгой аутентификации обязательными. Разновидности Kerberos довольно распространены. Также должен поддерживаться Lower Infrastructure Public Key Mechanism (LIPKEY). NFSv3 никогда не поддерживал что-то большее, чем стандартное UNIX-шифрование для аутентификации доступа — это порождало основные проблемы защиты в больших сетях.
• Обязательные схемы списков контроля доступа (access control list — ACL) в стиле Microsoft Windows NT: Хотя NFSv3 позволял реализовать строгое шифрование для аутентификации, он не использовал схемы ACL-доступа в стиле Windows NT. Списки ACL в стиле Portable Operating System Interface (POSIX) иногда реализовывались, но никогда не были общепринятыми. NFSv4 сделал ACL-схемы в стиле Windows NT обязательными.
• Договорные механизмы и стили аутентификации: NFSv4 предоставил возможность договариваться о механизмах и стилях аутентификации. В NSFv3 было невозможно сделать что-то большее, чем ручное определение используемого стиля шифрования. Системный администратор должен был затем согласовывать протоколы шифрования и защиты.

Поднимаем NFS сервер на Ubuntu

Сетевые файловые системы

4 минуты чтения

Рассказываем как быстро и просто поднять свой NFS сервер на Ubuntu Linux Server 14-04.1, а также разберёмся с принципами работы протокола NFS и рассмотрим теорию.

Теория

Аббревиатура NFS расшифровывается как Need for Speed — Network File System. Это протокол для доступа к распределённым сетевым файловым системам, с помощью которого можно подмонтировать удалённые директории к своему серверу. Это позволяет использовать дисковое пространство другого сервера для хранения файлов и регулярно производить запись данных на него с нескольких серверов.

Протокол имеет клиент-серверную модель, то есть один сервер (ещё его называют “шара” от слова share), с установленным пакетом NFS, будет обеспечивать доступ к своим каталогам и файлам, а клиентские компьютеры будут подключаться к нему по сети. Закрепим прочитанное схемкой:

Обращения к серверу NFS осуществляются в виде пакетов протокола RPC (Remote Call Procedure), который позволяет выполнить различные функции или процедуры в другом сетевом пространстве, то есть на удалённом сервере.

Авторизация пользователей, которые подключаются к серверу осуществляется по IP-адресу, а также по специальным идентификаторам пользователя UID и группы GID. Это не лучший способ относительно безопасности хранимых файлов, в сравнении с классической моделью «логин/пароль». Зато, благодаря такой архитектуре и тому, что NFS использовал протокол UDP без установления сессии, он практически невосприимчив к сбоям сети и самих клиентских компьютеров. Так, при каком-либо сбое, передача файла просто приостановится, а когда связь будет налажена, то передача возобновиться без необходимости какой-либо перенастройки.

Настройка

Думаю, с теорией понятно, так что давайте переходить к практике. Как было сказано, все настройки будет проводить на Ubuntu 14.04.1

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

Итак, скачиваем пакет nfs-kernel-server , с помощью которого мы сможем раздать доступ (“расшарить”) директории. Для этого на будущем NFS сервере вводим команды:

Теперь создаём собственно директорию к которой хотим раздать доступ. Стоит отметить, что можно также “расшарить” уже имеющиеся на сервере директории, но мы создадим новую:

Далее мы должны сделать так, чтобы владельцем директории /var/nfs и группе, к которой он принадлежит стали все пользователи в нашей системе. Для этого вводим на сервере команду:

Следующим шагом необходимо изменить конфигурацию самого NFS, она лежит в файле /etc/exports , открываем его для редактирования любимым редактором:

Перед вами откроется конфигурационный файл с закомментированными строками, которые содержат примеры настройки для разных версий NFS.

Нам необходимо внести в этот файл следующие не закомментированные строки:

• /var/nfs — Директория, которую мы хотим расшарить
• 10.10.0.10 — IP-адрес и маска клиентского компьютера, которому нужно раздать доступ к директории
• rw — Разрешает клиенту читать (r) и записывать (w) файлы в директории
• sync — Этот параметр заставляет NFS записывать изменения на диск перед ответом клиенту.
• no_subtree_check — Данная опция отключает проверку того, что пользователь обращается именно к файлу в определённом подкаталоге. Если это проверка включена, то могут возникнуть проблемы, когда, например, название файла или подкаталога было изменено и пользователь попробует к ним обратиться.

После этого, нужно создать таблицу соответствия расшаренных директорий и клиентов, а затем запустить NFS сервис. Для этого вводим следующие команды:

После выполненных действий расшаренные директории должны стать доступными для доступа с клиентов.

Пожалуйста, расскажите почему?

Нам жаль, что статья не была полезна для вас Пожалуйста, если не затруднит, укажите по какой причине? Мы будем очень благодарны за подробный ответ. Спасибо, что помогаете нам стать лучше!

Подпишитесь на нашу еженедельную рассылку, и мы будем присылать самые интересные публикации Просто оставьте свои данные в форме ниже.

Типичные настройки NFS-клиента и NFS-сервера

• Для клиента одинаково представлены локальные и NFS-файлы, ядро определяет, когда файл открыт.
• NFS-клиент отправляет RPC-запросы NFS-серверу через стек TCP/IP. NFS обычно использует UDP, однако более новые реализации могут использовать TCP.
• NFS-сервер получает запросы от клиента в виде UDP-датаграмм на порт 2049. Несмотря на то, что NFS может работать с преобразователем портов, что позволяет серверу использовать динамически назначаемые порты, UDP-порт 2049 жёстко закреплён за NFS в большинстве реализаций.
• Когда NFS-сервер получает запрос от клиента, он передается локальной подпрограмме доступа к файлу, которая обеспечивает доступ к локальному диску на сервере.
• Серверу может потребоваться время для того, чтобы обработать запросы клиента. Даже доступ к локальной файловой системе может занять некоторое время. В течение этого времени сервер не хочет блокировать запросы от других клиентов, которые также должны быть обслужены. Чтобы справиться с подобной ситуацией, большинство NFS-серверов запускаются несколько раз, то есть внутри ядра существует несколько NFS-серверов. Конкретные методы решения зависят от операционной системы. В большинстве ядер Unix-систем не используется несколько NFS-серверов, вместо этого запускается несколько пользовательских процессов (которые обычно называются nfsd), которые осуществляют один системный вызов и остаются внутри ядра в качестве процесса ядра.
• Точно так же, NFS-клиенту требуется время, чтобы обработать запрос от пользовательского процесса на узле клиента. RPC выдается на узел сервера, после чего ожидается отклик. Для того, чтобы пользовательские процессы на узле клиента могли в любой момент воспользоваться NFS, существует несколько NFS-клиентов, запущенных внутри ядра клиента. Конкретная реализация также зависит от операционной системы. Unix-система обычно использует технику, напоминающую NFS-сервер: пользовательский процесс, называемый biod, осуществляет один единственный системный вызов и остаётся внутри ядра как процесс ядра.
• Большинство Unix-узлов может функционировать и как NFS-клиент, и как NFS-сервер. Большинство мейнфреймов IBM предоставляет только функции NFS-сервера.

Инновации в NFS

Наибольший интерес представляют две последние версии NFS – 4 и 4.1, на примере которых можно изучить наиболее важные аспекты эволюции технологии NFS.

До появления NFSv4 для выполнения таких задач по управлению файлами, как монтирование, блокировка и т.д. существовали специальные дополнительные протоколы. В NFSv4 процесс управления файлами был упрощен до одного протокола; кроме того, начиная с этой версии UDP больше не используется в качестве транспортного протокола. NFSv4 включает поддержку UNIX и Windows-семантики доступа к файлам, что позволяет NFS «естественным» способом интегрироваться в другие операционные системы.

В NFSv4.1 для большей масштабируемости и производительности была введена концепция параллельной NFS (parallel NFS — pNFS). Чтобы обеспечить больший уровень масштабируемости, в NFSv4.1 реализована архитектура, в которой данные и метаданные (разметка) распределяются по устройствам аналогично тому, как это делается в кластерных файловых системах. Как показано на , pNFS разделяет экосистему на три составляющие: клиент, сервер и хранилище. При этом появляются два канала: один для передачи данных, а другой для передачи команд управления. pNFS отделяет данные от описывающих их метаданных, обеспечивая двухканальную архитектуру. Когда клиент хочет получить доступ к файлу, сервер отправляет ему метаданные с «разметкой». В метаданных содержится информация о размещении файла на запоминающих устройствах. Получив эту информацию, клиент может обращаться напрямую к хранилищу без необходимости взаимодействовать с сервером, что способствует повышению масштабируемости и производительности. Когда клиент заканчивает работу с файлом, он подтверждает изменения, внесенные в файл и его «разметку». При необходимости сервер может запросить у клиента метаданные с разметкой.

С появлением pNFS в протокол NFS было добавлено несколько новых операций для поддержки такого механизма. Метод используется для получения метаданных с сервера, метод «освобождает» метаданные, «захваченные» клиентом, а метод загружает «разметку», полученную от клиента, в хранилище, так что она становится доступной другим пользователям. Сервер может отозвать метаданные у клиента с помощью метода . Метаданные с «разметкой» распределяются между несколькими запоминающими устройствами, чтобы обеспечить параллельный доступ и высокую производительность.

Рисунок 4. Архитектура pNFS в NFS версии 4.1

Данные и метаданные хранятся на запоминающих устройствах. Клиенты могут выполнять прямые запросы ввода/вывода на основе полученной , а сервер NFSv4.1 хранит метаданные и управляет ими. Сама по себе эта функциональность и не нова, но в pNFS была добавлена поддержка различных методов доступа к запоминающим устройствам. Сегодня pNFS поддерживает использование блочных протоколов (Fibre Channel), объектных протоколов и собственно NFS (даже не в pNFS-форме).

Развитие NFS продолжается, и в сентябре 2010 года были опубликованы требования к NFSv4.2. Некоторые из нововведений связаны с наблюдающейся миграцией технологий хранения данных в сторону виртуализации. Например, в виртуальных средах с гипервизором весьма вероятно возникновение дублирования данных (несколько ОС выполняют чтение/запись и кэширование одних и тех же данных). В связи с этим желательно, чтобы система хранения данных в целом понимала, где происходит дублирование. Такой подход поможет сэкономить пространство в кэше клиента и общую емкость системы хранения. В NFSv4.2 для решения этой проблемы предлагается использовать «карту блоков, находящихся в совместном доступе» (). Поскольку современные системы хранения все чаще оснащаются собственными внутренними вычислительными мощностями, вводится копирование на стороне сервера, позволяющее снизить нагрузку при копировании данных во внутренней сети, когда это можно эффективно делать на самом запоминающем устройстве. Другие инновации включают в себя субфайловое кэширование для флэш-памяти и рекомендации по настройке ввода-вывода на стороне клиента (например, с использованием ).

Протокол NFS

Когда клиент начинает работать с NFS, первым действием выполняется операция , которая представляет собой монтирование удаленной файловой системы в пространство локальной файловой системы. Этот процесс начинается с вызова процедуры (одной из системных функций Linux), который через VFS перенаправляется в NFS-компонент. Затем с помощью RPC-вызова функции на удаленном сервере определяется номер порта, который будет использоваться для монтирования, и клиент через RPC отправляет запрос на монтирование. Этот запрос на стороне сервера обрабатывается специальным демоном , отвечающим за протокол монтирования (mount protocol). Демон проверяет, что запрошенная клиентом файловая система имеется в списке систем, доступных на данном сервере. Если запрошенная система существует и клиент имеет к ней доступ, то в ответе RPC-процедуры указывается дескриптор файловой системы. Клиент сохраняет у себя информацию о локальной и удаленной точках монтирования и получает возможность осуществлять запросы ввода/вывода. Протокол монтирования не является безупречным с точки зрения безопасности, поэтому в NFSv4 вместо него используются внутренние RPC-вызовы, которые также могут управлять точками монтирования.

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

После того как файл идентифицирован в удаленной файловой системе, клиент может выполнять RPC-запросы типа . Этот запрос состоит из дескриптора файла, состояния, смещения и количества байт, которое следует считать. Клиент использует состояние (state), чтобы определить может ли операция быть выполнена в данный момент, т.е. не заблокирован ли файл. Смещение (offset) указывает, с какой позиции следует начать чтение, а счетчик байт (count) определяет, сколько байт необходимо считать. В результате RPC-вызова сервер не всегда возвращает столько байт, сколько было запрошено, но вместе с возвращаемыми данными всегда передает, сколько байт было отправлено клиенту.

Текущее состояние pNFS

Прежде чем готовить деньги для покупки, давайте взглянем на нынешнее состояние pNFS.

На сегодняшний день (октябрь 2008 г.) черновая версия RFC (Request For Comments) для NFSv4.1 готова к стадии «last call» — двухмесячный период, который отводится на то чтобы собрать и изучить комментарии перед тем, как RFC будет опубликован и открыт всей отрасли для детального изучения. Формальное рассмотрение RFC часто длится около года со времени публикации.

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

Уже сейчас можно ознакомиться с реализацией pNFS с открытым кодом, доступной в git-репозитории университета Мичигана (см. ссылку в разделе Ресурсы). IBM, Panasas, Netapp и University of Michigan Center for Information Technology Integration (CITI) возглавляют разработку NFSv4.1 и pNFS для Linux.

Потенциал pNFS как параллельной файловой системы с открытым кодом огромен. Самый быстрый суперкомпьютер в мире (по рейтингу обзора Top500) и первый компьютер с производительностью более 1 петафлопа (тысяча триллионов операций в секунду) использует параллельную файловую систему, компании Panasas (сторонника объектной реализации pNFS). На рисунке 4 показан известный суперкомпьютер Roadrunner, находящийся в Лос-Аламосской Национальной лаборатории. Эта громадная система имеет 12960 процессоров, работает под Linux и является первым суперкомпьютером, состоящим из процессоров различных типов. Вычисления осуществляют совместно процессоры AMD Opteron X64 и IBM Cell Broadband Engine. В 2006 году, Roadrunner показал максимальную скорость передачи данных 1,6 гигабайт в секунду, при использовании ранней версии параллельной файловой системы Panasas. В 2008 г. параллельная система хранения данных Roadrunner уже может поддерживать скорость в несколько сотен гигабайт в секунду. Для сравнения, пиковая скорость в традиционной NFS обычно составляет несколько сотен мегабайт в секунду.

Стандарт NFSv4.1 в целом и pNFS в частности являются значительным шагом вперед в развитии стандарта NFS. Это наиболее радикальные изменения в технологии с более чем двадцатилетней историей, разработанной в 1980-х годах Биллом Джоем из Sun Microsystems. Совсем скоро NFSv4.1 и pNFS, разрабатывавшиеся 5 лет, будут готовы предоставить для суперкомпьютеров сверхскорости передачи данных.

Мы заглянули в будущее и знаем, что оно за параллельными системами хранения данных.