Масштабируем файловую систему при помощи Parallel NFS

Читайте и записывайте сотни гигабайт в секунду

Протокол NFS играет значительную роль в большинстве современных локальных сетей. Однако для требовательных к производительности приложений, интенсивно осуществляющих ввод/вывод информации (какие нередки в системах высокопроизводительных вычислений) NFS совершенно не подходит, — по крайней мере так было раньше. Последняя версия стандарта NFS включает в себя параллельный NFS (pNFS) — распараллеленную реализацию общего доступа к файлам, которая увеличивает скорость передачи данных пропорционально размерам системы. Вот небольшое введение.

Мартин Стрейчер, главный редактор, Linux Magazine

Мартин Стрейчер (Martin Streicher) -- главный редактор журнала Linux Magazine. Он имеет степень магистра компьютерных наук Университета Пардью (Purdue University) и с 1982 занимается программированием на языках Pascal, C, Perl, Java и (с недавнего времени) Ruby в UNIX-подобных операционных системах.



19.02.2009

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

На рисунке 1 показана типичная схема NFS в сети с компьютерами, имеющими различные ОС: Linux®, Mac OS X и Windows®. Все они поддерживают стандарт NFS (NFS - единственный стандарт файловой системы, поддерживаемый IETF (Internet Engineering Task Force).)

1. Простая конфигурация NFS
Простая конфигурация NFS

На рисунке 1 Linux машина представляет собой NFS-сервер; он предоставляет совместный доступ, или экспортирует (в терминах NFS) одну или несколько своих физических подсоединенных файловых систем. Машины Mac OS X и Windows являются NFS-клиентами. Каждый клиент поребляет (монтирует) файловую систему общего доступа. На самом деле монтирование файловой системы NFS дает тот же результат, что и монтирование раздела на локальном носителе — с примонтированной файловой системой приложения работают точно так же, как с локальной - просто читают и записывают файлы в соответствии с правами доступа, не ведая о механизмах, которые обеспечивают работу с ними.

При работе с файловой системой NFS операции чтения и записи фактически выполняются не клиентом, а сервером; именно он выполняет запросы, извлекает и сохраняет данные, изменяет метаданные файла (такие как права доступа или время модификации файла).

NFS — достаточно мощная система, что подтверждается широким использованием ее в качестве NAS (Network Attached Storage). Она работает как через протокол TCP, так и через UDP, и относительно проста в администрировании. Более того, NFSv4 — последняя официальная версия стандарта (утверждена в 2003 г.) — содержит улучшения в безопасности, обеспечивает лучшую совместимость Windows- и UNIX-®систем и обеспечивает лучшую эксклюзивность благодаря системе временных блокировок (lock leases). Инфраструктура для NFS также имеет невысокую стоимость, так как она может работать на обычных Ethernet-устройствах. NFS хорошо подходит для решения большинства задач.

Областью, в которой NFS работает плохо, традиционно считаются высокопроизводительные вычисления, где файлы данных обычно огромны, а количество NFS клиентов может исчисляться сотнями (представьте кластер, состоящий из нескольких сотен вычислительных узлов). Здесь использование NFS нежелательно, так как ограничения NFS-сервера —будь то пропускная способность, объем места для хранения или скорость процессора — снижают общую производительность вычислений. Здесь NFS является узким местом, «бутылочным горлышком».

По крайней мере, так было раньше.

Следующая версия NFS 4.1 включает в себя расширение Parallel NFS (pNFS), которое сочетает в себе преимущества NFS хранилища и высокие скорости передачи данных (которые обеспечиваются распараллеливанием операций ввода/вывода). При использовании pNFS клиенты, как и раньше, имеют доступ к файловой системе сервера, но непосредственно передачи данных с сервера не происходит. Вместо этого клиентская система и система хранения данных соединяются напрямую. При этом создается несколько параллельных высокоскоростных каналов передачи данных. Сервер pNFS участвует только в непродолжительной фазе инициализации соединения, после чего «устраняется» и уже не замедляет скорость передачи данных.

Конфигурация pNFS показана на рисунке 2. Наверху показаны узлы вычислительного кластера, например пул недорогих Linux машин. Слева – сервер NFSv4.1 (далее будем его называть просто pNFS-сервер.) Внизу показана большая параллельная файловая система.

Рисунок 2. Концепция организации pNFS
Концепция организации pNFS

Как и в NFS, сервер pNFS экспортирует файловую систему и хранит и поддерживает канонические метаданные, описывающие каждый файл хранилища данных. Как и в NFS, клиент pNFS (здесь узел кластера) монтирует файловую систему, экспортированную сервером, и в дальнейшем работает с ней как со своей локальной физической файловой системой. Изменения в метаданных передаются от клиента обратно на сервер pNFS. Однако, в отличие от NFS, операции чтения и записи данных осуществляются напрямую между вычислительным узлом и хранилищем данных, как показано на рисунке 2. Сервер pNFS не участвует в транзакциях по передаче данных, и это является несомненным преимуществом, улучшающим производительность.

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

Подробнее об устройстве pNFS

Итак, как же все это работает? Посмотрим повнимательнее.

Как показано на рисунке 3, pNFS реализуется как совокупность трех протоколов.

Рисунок 3. Триада протоколов pNFS.
Триада протоколов pNFS.

Протокол pNFS осуществляет передачу метаинформации о файлах, формально называемой layout (разметка), между сервером pNFS и клиентским узлом. Можно представлять себе разметку как отображение, описывающее то, как файл распределен в системе хранения данных, например, как он поделен между несколькими носителями. Еще разметка содержит атрибуты файла, такие как права доступа и т.д. Вся метаинформация о данных отражается в файлах разметки и хранится на сервере pNFS, а система хранения данных занимается только вводом/выводом информации.

Протокол доступа к системе хранения данных (Storage access protocol) регулирует то, как клиент работает с системой хранения данных. Как вы, возможно, уже догадались, каждый протокол доступа к системе хранения данных определяет свою собственную форму разметки. Протокол доступа и способ организации данных взаимосвязаны и должны соответствовать друг другу.

Протокол управления (Control protocol) служит для синхронизации между сервером метаданных и сервером данных. Синхронизация — например, реорганизация файлов на носителях— скрыта от клиентов. Протокол управления не описывается в NFSv4.1, он может принимать различные формы, что предоставляет производителям широкие возможности для оптимизации производительности, снижения стоимости или расширения функциональности.

Итак, процесс доступа клиента к данным выглядит так:

  1. Клиент запрашивает разметку файла, с которым предстоит работать.
  2. Клиент получает права доступа путем открытия файла на сервере метаданных
  3. Авторизовавшись и получив разметку файла, клиент может получать информацию непосредственно с сервера данных. Работа осуществляется в соответствии с протоколом доступа, требуемым для этого типа носителя. (Подробнее ниже)
  4. Если клиент изменяет файл, клиентская копия разметки изменяется необходимым образом, после чего передается на сервер метаданных.
  5. Когда клиент больше не нуждается в файле, он записывает оставшиеся изменения, передает свою копию разметки обратно на сервер метаданных и закрывает файл.

Более подробно операция чтения (READ) – это серия следующих операций протокола:

  1. Клиент посылает запрос LOOKUP+OPEN на сервер pNFS. Сервер возвращает дескриптор файла (file handle) и информацию о состоянии файла.
  2. Клиент запрашивает с сервера разметку с помощью команды LAYOUTGET. Сервер возвращает разметку файла.
  3. Клиент посылает запрос READ на устройства хранения, которые инициируют множество параллельных операций READ.
  4. Когда клиент заканчивает чтение, он посылает команду LAYOUTRETURN.
  5. Если клиентская копия разметки становится неактуальной (из-за изменения серверной разметки каким-либо другим, выполняющимся параллельно действием), сервер посылает команду CB_LAYOUTRECALL, сообщая, что разметка уже не действительна и ее надо обновить.

Операция Write выглядит также, за исключением того, что клиент шлет команду LAYOUTCOMMIT перед командой LAYOUTRETURN, чтобы «опубликовать» свои изменения файла на сервере pNFS.

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

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


Методы хранения данных

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

  • Файловое хранение часто реализуется на основе традиционных NFS-серверов, например, производства Network Appliance. Система хранения собирается из NFS-серверов и каждый файл разделяется между серверами (всеми или несколькими) таким образом, чтобы клиент мог извлекать одновременно разные части файла. Здесь в разметке для каждого куска файла указываются его размер, серверы, на которых он хранится, и NFS-дескрипторы (file handle) каждого сегмента.
  • Блочное хранение чаще всего реализуется в сети хранения данных (storage-area network - SAN) из множества RAID-массивов. SAN-решения предлагают многие производители, включая IBM и EMC. В случае блочного хранения данных файл делится на блоки и распределяется между накопителями. Здесь разметка представляет соответствие между блоками файлами и физическими блоками хранения. Протоколом доступа к системе хранения данных служат SCSI-команды по работе с блоками данных.
  • Объектное хранение схоже с файловым хранением, за исключением того, что дескрипторы файла заменяются идентификаторами объектов и разбиение файла здесь может быть более сложным и эффективным. Главным автором объектной реализации pNFS является компания Panasas. Кстати, именно она начала разработку pNFS, основываясь на своей архитектуре DirectFLOW.

Независимо от типа разметки pNFS использует для обращения к серверам общую схему. Вместо имени хоста или тома накопителя обращение к серверам происходит по уникальным идентификаторам. Этому идентификатору ставится в соответствие зависящая от конкретного протокола доступа ссылка на сервер.

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


Текущее состояние 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 обычно составляет несколько сотен мегабайт в секунду.

Рисунок 4. Roadrunner, первый в мире суперкомпьютер с производительностью более 1 петафлопа.
Roadrunner, первый в мире суперкомпьютер с производительностью более 1 петафлопа.

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

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

Ресурсы

Научиться

Получить продукты и технологии

  • Разработайте ваш следующий Linux-проект с помощью пробного ПО от IBM, которое можно загрузить непосредственно с сайта developerWorks.

Обсудить

Комментарии

developerWorks: Войти

Обязательные поля отмечены звездочкой (*).


Нужен IBM ID?
Забыли Ваш IBM ID?


Забыли Ваш пароль?
Изменить пароль

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Профиль создается, когда вы первый раз заходите в developerWorks. Информация в вашем профиле (имя, страна / регион, название компании) отображается для всех пользователей и будет сопровождать любой опубликованный вами контент пока вы специально не укажите скрыть название вашей компании. Вы можете обновить ваш IBM аккаунт в любое время.

Вся введенная информация защищена.

Выберите имя, которое будет отображаться на экране



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

Отображаемое имя должно иметь длину от 3 символов до 31 символа. Ваше Имя в системе должно быть уникальным. В качестве имени по соображениям приватности нельзя использовать контактный e-mail.

Обязательные поля отмечены звездочкой (*).

(Отображаемое имя должно иметь длину от 3 символов до 31 символа.)

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Вся введенная информация защищена.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=Linux
ArticleID=370640
ArticleTitle=Масштабируем файловую систему при помощи Parallel NFS
publish-date=02192009