Файловые системы для Больших Данных

Проблема постоянно растущих объемов данных превратилась сегодня в одну из самых насущных, и на многочисленных конференциях и в СМИ чаще всего в качестве средств для ее решения рассматривают либо облачные сервисы, либо стек решений MapReduce, однако и эти подходы не без слабостей. У пользователей еще сохраняются сомнения в их конфиденциальности, но, даже если барьер недоверия будет преодолен, нельзя забывать и о других слабых сторонах сервисной модели, в частности о том, что данные должны быть загружены каким-то образом в облако, что скорость доступа к ним ограничена, но главное — сервисная модель не универсальна и хорошо соответствует только определенным классам приложений. Альтернатива в лице Google File System в большей степени ориентирована на поисковые задачи, а Hadoop Distributed File System и CloudStore удачно подходят для аналитических приложений. Но остаются приложения, которым ни одно из перечисленных средств не может удовлетворить в полной мере, и для них требуется распределенный доступ к данным, которые в свою очередь могут быть распределены между различными хранилищами, в том числе и географически. При этом для минимизации затрат желательно избегать избыточной миграции данных и хранить данные ближе к месту их использования в многоуровневой системе.

Среди технологий, предназначенных для обработки больших данных, можно отметить и распределенные файловые системы (Distributed File System, DFS). В качестве характерного примера применения DFS можно привести системы типа e-Science накопления и обработки научных данных в биологии или экспериментальной физике. В подобных системах имеется множество источников для потокового сбора экспериментальных данных. Полученные необработанные данные разумнее всего хранить ближе к экспериментальным установкам, но в то же время возможность для их использования не должна иметь географических ограничений. Один из основных принципов e-Science состоит в конвергенции различных сетей: сеть экспериментальных установок (Network of Instruments), сеть исследователей (Networks for Research), общая сеть для совместных работ (Research on Networks). Все вместе такие сети формируют пространство для обмена и распространения знаний (Knowledge Dissemination). Очевидно, что e-Science не одинока — аналогичный подход может быть распространен на экономические, государственные и другие системы, в том числе обеспечивающие безопасность, в которых накапливаются большие объемы данных, используемые большим числом сотрудников. От таких систем требуется:

• масштабируемость — возможность наращивания объемов хранения и числа пользователей без потери производительности;
• высокая готовность — доступность данных или приложений вне зависимости от возможных аппаратных или программных сбоев, что обеспечивается репликацией в географически разнесенных местах и возможностью перестраивания "на лету";
• долговременность хранения — выход из строя тех или иных устройств не должен приводить к потере данных;
• производительность — скорость обмена на уровне традиционных систем SAN/NAS и поддержка SSD, RAID дисков SAS/SATA;
• динамичность — возможность реконфигурации по запросу от приложений;
• следование открытым стандартам и протоколам (в основном POSIX) — возможность избежать зависимости от одного или группы производителей;
• множественный доступ — обеспечение одновременной работы пользователей из разных географических мест и их взаимодействие между собой.

Как уже было сказано, решением проблемы больших данных может быть использование современных файловых систем, которые можно разделить на две категории: распределенные, обычно устанавливаемые на MPP-кластеры, и традиционные, но рассчитанные на работу с большим объемами данных. Из первых наибольшую известность получили Lustre, GPFS и две системы, созданные "по мотивам" Lustre, — GlusterFS и Ceph. Система GPFS является коммерческой, остальные доступны в открытых кодах. Менее популярны системы XtreemFS, MogileFS, pNFS, ParaScale, CAStor и Tahoe-LAFS. Во второй категории безусловный лидер ZFS и близкая ей LZJB, дополненная алгоритмом сжатия данных без потерь. Кроме этого имеются еще NILFS, разработанная в Nippon Telephone and Telegraph CyberSpace Laboratories, и Veritas File System, разработанная компанией Veritas Software. Не исключено и паллиативное решение, где совмещаются файловые системы из обеих групп.

Lustre

Lustre (Linux и Clusters или Lustre File System, LFS) — распределенная файловая система в открытых кодах, представляющая собой сочетание взаимосвязанных элементов, взаимодействующих как целое. Lustre состоит из трех основных компонентов:

• клиент файловой системы — любая машина, получающая доступ к данным (сервер, виртуальная машина, десктоп), с точки зрения которой Lustre видится как обычная локальная или сетевая файловая система;
• сервисы метаданных, поддержанные сервером метаданных MDS (Metadata Server) и хранилищем MDT (Metadata Target), совместно образующие сервисное средство, обеспечивающее адресацию к данным и согласование работы клиентов с данными;
• сервисы объектного хранения, предоставляющие объектную архитектуру хранения данных и состоящие из сервера хранения объектов OSS (Object Storage Server) и хранилища OST (Object Storage Target), совместно обеспечивающих клиента данными (Lustre может иметь один или более сервер OSS, к которому подключаются от двух до восьми хранилищ).

Lustre задумана и спроектирована в расчете на работу с десятками тысяч клиентов, тысячами OSS и сотнями MDS, что позволяет обеспечить доступ к петабайтам данных. Упрощенная конструкция Lustre показана на рис. 1, а на рис. 2 приведена схема взаимодействия между компонентами.

Рис. 1. Три группы компонентов Lustre

Рис. 2. Схема взаимодействия компонентов Lustre

Lustre интерпретирует любые файлы как объекты, доступ к которым обеспечивается посредством MDS, осуществляющих все операции, связанные с пространством имен, в том числе такие, как поиск файлов, создание и уничтожение файлов, работа с каталогами. Реальное выполнение операций ввода-вывода перепоручается объектному хранилищу OST, которое в свою очередь оперирует входящими в его состав объектными дисками (Object-Based Disk, OBD). Кроме того, серверы метаданных поддерживают транзакционные записи об изменениях метаданных и состоянии кластера, а также контролируют свою собственную работоспособность таким образом, чтобы выход из строя одного MDS не повлиял на работоспособность файловой системы в целом. В Lustre, как и в большинстве других файловых систем, каждый обычный (регулярный) или специальный файл, каталог и символическая связь идентифицируются уникальным индексным дескриптором inode. Однако и в этом проявляется самобытность Lustre, дескрипторы регулярных файлов связаны не с самими файлами, а с объектами в хранилищах OST, поэтому здесь для создания нового файла клиент обращается к серверу MDS, который создает inode, а затем вступает в контакт с OST для создания объекта, хранящего данные. Если нужно внести изменения в пространство имен, то объект может быть распределен между несколькими OST для создания образа RAID.

Объектные хранилища OST обеспечивают взаимодействие между клиентскими данными и объектными дисками OBD. Объектный диск — условное название, это может быть и не диск, а что-то иное, поскольку в состав OST входит драйвер файлов Filter Driver. Управление посредством MDS позволяет легко наращивать количество подключенных OSS, OST и OBD.

Серверы MDS имеют дело с метаданными, описывающими файлы: сведениями об именах каталогов, служебными данными и т. п. Для хранения метаданных Lustre использует существующие в ядре Linux журнальные файловые системы ext3/ext4 и ReiserFSе. Непосредственный доступ к метаданным обеспечивается посредством Linux Virtual File System (VFS) или Filter Driver, драйверы которого реализуют дополнительную функциональность, например выполнение транзакций или поддержку RAID, поэтому все метаданные, за исключением дополнительных, хранятся в файловых системах MDS.

Клиент или пользователь Lustre File System вступает во взаимодействие с MDS для выполнения операций, связанных с метаданными, и с OST для выполнения непосредственно операций ввода-вывода данных. MDS поддерживает действия, связанные с поиском в каталогах, а также действия, обеспечивающие блокировку в случае возникновения коллизий. Схема доступа к данным с использованием метаданных и суперпозицией промежуточных файловых систем показана на рис. 3.

Рис. 3. Суперпозиция файловых систем

Система для зеттабайтов

До августа 2004 года единица для измерения объема данных Збайт почти не встречалась, вплоть до момента, пока Sun Microsystems не представила миру файловую систему Zettabyte File System (ZFS). Практическая возможность использовать ZFS в деле представилась в 2005 году, после ее интеграции в ОС Solaris, а несколько позже еще и в OpenSolaris. Сходство названий двух файловых систем порождает известную путаницу, помимо ZFS есть zFS (z/OS Distributed File Service zSeries File System) — распределенная файловая система, разработанная в IBM в стиле Unix/Linux, но для операционной системы z/OS. Зеттабайт в названии появился не случайно — таким образом подчеркивается готовность ZFS к наступающей эпохе больших данных. Теоретически ZFS способна хранить 2 ⁴⁸ файлов размером до 16 экзабайт каждый (2 ⁶⁴ байт). Для обозначения этого чудовищного объема соответствующих единиц измерения еще не придумано, а 1 Збайт уже стал реальностью, и если нынешние темпы роста сохранятся, то барьер 100 Збайт будет преодолен в начале третьего десятилетия нынешнего века. Тут ZFS будет как нельзя кстати с ее "безразмерностью", поддерживаемой 128-разрядной адресацией.

Рис. 4а. Традиционная организация систем хранения

Запредельный объем хранения — не самоцель, Джефф Босвик и Билл Мур, создатели ZFS, ставили перед собой две здравые задачи. Первая — избавиться от необходимости в надежных дисках, чтобы собрать надежную систему из ненадежных компонентов. Вторая — обеспечить простоту неограниченного масштабирования. Босвик и Мур приступили к работе над ZFS в 2000 году, осознав фундаментальное противоречие между ростом размера дисков, удваиваемого каждые 12-18 месяцев, и постоянным количеством ошибок в пересчете на терабайт. Из-за подобного разрыва рано или поздно с неизбежностью возникнет тупиковая ситуация, надежность дисков ограничит предельные объемы хранимых данных, поэтому исходной точкой стало недоверие к железу, и не случайно позже стали говорить, что ZFS любит дешевые диски SATA.

Рис. 4б. Архитектура ZFS

Разработчикам ZFS повезло, они получили возможность начать с нуля, учитывая лишь одно ограничительное условие — система должна соответствовать требованиям POSIX. Тем не менее они решили не оригинальничать и использовать давно известные методы обеспечения надежности: контрольные суммы и объектный подход с применением транзакционного механизма (рис. 4а), гарантирующего завершенность операций над данными (если операция не завершилась корректно, то данные остаются в исходном виде). Огромный потенциал масштабирования основывается на усовершенствованных методах виртуализации (рис. 4б). В совокупности все эти подходы обеспечивают ZFS целостность данных, простоту администрирования и неограниченную емкость.

Виртуализация. Разработчики ZFS пришли к выводу, что во всех существующих файловых системах допускается одна и та же ошибка — привязанность файловой системы к конкретному устройству или его разделу. В ZFS виртуализация была опущена буквально на уровень оборудования при помощи средства для резервирования блоков (Storage Pool Allocator, SPA). С использование SPA все доступные дисковые блоки объединяются в одно общее виртуальное пространство адресов данных (Data Virtual Addresses, DVA). Такое решение приближает дисковую память по логике работы к оперативной. Размер можно менять динамически, между кодами и адресами данных на диске вообще нет никакой связи, упрощается администрирование, а 128-разрядный адрес делает это пространство практически бесконечным.

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

Рис. 5. Сравнение обычной файловой системы с ZFS

Из сравнения двух решений (рис. 5) видно, что различия обнаруживаются в средних уровнях модели. Главное состоит в том, что SPA формирует виртуальный адрес данных, в то время как обычная система всего лишь заменяет физическое устройство логическим.

Гибрид Lustre и ZFS

Если узел файловой систем Lustre работает с внутренней файловой системой на ext3 или ext4, то его объем данных ограничен 8 Тбайт, что совсем немного; кроме того, не гарантируется целостность данных. В качестве выхода из ситуации можно предложить использовать ZFS в серверных компонентах OSS и MDS, таким образом получая гибрид Lustre и ZFS, сочетающий лучшее из двух подходов. По части целостности данных Lustre с поддержкой ZFS оказывается совершеннее по следующим двум позициям:

• защита данных при записи (сopy on write) — ZFS никогда не накладывает новые данные на существующие, а измененная информация записывается в новые блоки, и указатели блоков перемещаются только в том случае, если транзакция записи полностью завешена;
• нарушения данных (data corruption) — ZFS выполняет сквозную проверку контрольных сумм (end-to-end checksumming), а надежность обеспечивается тем, что сами контрольные суммы хранятся отдельно от данных.

Вместе с тем эксперименты с использованием проверки по контрольным суммам позволили выявить следующие нарушения в работе ZFS: фантомные записи — записи "в никуда"; ошибки в адресации — записи попадают не в те блоки; записи поверх "живых" данных. Было выявлено две причины ошибок: сбои в работе сетевых карт и нарушения в работе драйверов. Вместе с тем, кроме неограниченного масштабирования, в ZFS имеется ряд функциональных преимуществ: самолечение (Self-healing) — зеркалирование и RAID позволяют исправлять ошибки в данных; упрощенное администрирование; поддержка твердотельных дисков SSD.