Проблема постоянно растущих объемов данных превратилась сегодня в одну из самых насущных, и на многочисленных конференциях и в СМИ чаще всего в качестве средств для ее решения рассматривают либо облачные сервисы, либо стек решений 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 48 файлов размером до 16 экзабайт каждый (2 64 байт). Для обозначения этого чудовищного объема соответствующих единиц измерения еще не придумано, а 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.

 

Файловые системы — от ящиков для перфокарт до Unix

Магнитные ленты, из прошлого в будущее

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

В англоязычных странах файлом (file) называют способ хранения документов в определенном порядке; для специальных стандартных шкафов с выдвижными ящиками в Англии используют filing cabinet, а в США — file cabinet. Первыми широко распространенными носителями данных стали перфокарты, поэтому с 1952 года слово «файл» перекочевало в компьютерный мир в приложении к шкафам с выдвижными ящиками для перфокарт. Затем по аналогии с ними и первые диски стали называть "дисковыми файлами". В современном смысле слово "файл" стало использоваться начиная с 1962 года, его ввели в оборот разработчики операционной системы с разделением времени Compatible Time-Sharing System (CTSS), созданной в Массачусетском технологическом институте. Ими была предложена современная структура имени, состоящая из собственно имени и типа файла. Термин файловая система (File System) возник примерно тогда же, одновременно с мини-ЭВМ Linc, в которой файловая система выполняла привычную теперь функцию установки связи между именами массивов данных и блоками на съемной ленте, куда данные записывались. Но программист должен был сам помнить, по каким физическим адресам расположены блоки интересующих его данных, — создание настоящей файловой системы можно сравнить с изобретением языка ассемблера, позволившего заменить адреса переменных идентификаторами. Файловая система в том смысле, как мы понимаем ее сейчас, появилась в 1964 году на легендарной мини-ЭВМ PDP-8. Устройства TU55 и ТU56 типа DECtape, которыми она комплектовалась, были чем-то средним между дисками и лентами, то есть лентами по физическим признакам, но дисками по логическим, перемотка взад-вперед дюймовой ленты обеспечивала считывание нужного блока примерно так, как сейчас перемещение головок дисков.

Огромная часть новаций 70-80-х была родом из Digital Equipment Corporation. Семейство PDP-11, классика эпохи мини, создавалось с целью управления разного рода объектами, соответственно была разработана операционная система реального времени RT-11 (Real Time), в которой была настоящая файловая система Files-11, пережившая RT-11 и саму DP-11. Усовершенствованная Files-11 «переехала» в другие ОС, работавшие на PDP-11 (RSRS/E и RSX 11), потом в OpenVMS (Open Virtual Memory System для машин VAX), а сейчас живет в продуктах HP. Под именем Files-11 скрывается пять поколений файловых систем:

  • ODS-1 — плоская файловая система для операционных систем, стоявших на PDP-11;
  • ODS-2, 3 и 4 — последовательные модернизации для VAX VMS;
  • ODS-5 — для платформ Alpha vailable и IA-64.

Памяти Digital Equipment Corporation

По времени, в течение которого разные модификации PDP-11 находились в производстве, их можно сравнить разве что с автомобилем «Фольксваген Жук». Это семейство установило рекорд долголетия, который вряд ли будет побит. Системы PDP-11 выпускались более 25 лет: первая модель, 11/20, была запущена в 1970 году, последняя, 11/94, стартовала в 1990 году, а продажа PDP закончилась 30 сентября 1996 года. Уже одного этого достаточно, чтобы корпорация Digital Equipment вошла в историю.

Имена каталогов в первых версиях Files-11 стояли из двух групп трехзначных чисел, первую мог создать только привилегированный пользователь, а имена файлов, помимо расширения, имели еще и автоматически назначаемые версии. О защите от ошибок оператора речи не шло, и, выполнив команду DEL [*,*]*.*;*, можно было удалить все файлы из всех каталогов без надежды на их восстановление.

За последующие десятилетия было разработано и внедрено порядка сотни файловых систем. Часть из них не получила широкого распространения, а первой массовой стала файловая система CP/M, существовавшая в составе одноименной операционной системы Control Program for Microcomputers, которую в 1974 году создал Гари Килдалл, основатель компании Digital Research. Килдаллу пришлось решать непонятные для нынешнего пользователя задачи, например то, что не существовало одного стандарта на диски диаметром 5,25 дюйма — они с завода выходили форматированными, но в каждом компьютере использовались хоть немного, но по-своему. Но это не помешало ему сделать то, чем впоследствиии пользовались во всем мире, в частности именно Килдалл предложил формат имени файла "8.3", состоящий из индивидуального идентификатора файла — восемь символов ASCII и три символа расширения. Он же предложил именовать устройства буквами a, b, c и т. д. Формат "8.3» сохранился в файловых системах FAT12 и FAT16, а в FAT32 появилась поддержка длинных имен файлов LFN, но в OS/2 и Unix-подобных операционных системах таких ограничений не было. Этот же формат содержал таблицу Directory table, в которую записывались метаданные о файле (его атрибуты и свойства).

Самым заметным событием 80-х годов стало создание файловой системы Unix File System (UFS) или Berkeley Fast File System (FFS). До ее появления операционная система Unix имела весьма ограниченную по своему функционалу и неустойчивую к сбоям систему FS. Как и в случае с CP/M, всю работу по созданию UFS выполнил Кирк Маккьюсак, который не просто связал блоки, где хранятся данные с именами, но и нашел решение, как работать с дисками большого объема, выдвинув идею разделения всего диска на соседние окрестности (цилиндры), что позволило уменьшить сегментацию дискового пространства. Среди других изобретений Маккьюсака: перемещение блоков непосредственно перед записью для снижения фрагментации дискового пространства; прием, получивший название soft update, — более быстрый, но не менее надежный, чем синхронное журналирование, способ сохранения записанных данных в аварийных ситуациях. Система UFS оказалась настолько удачной, что крупные производители проприетарных клонов Uniх с небольшими изменениями и дополнениями включили UFS в свои продукты (SunOS/Solaris, System V Release 4, HP-UX, Tru64 UNIX). В последующем были разработаны усовершенствованные версии UFS1 и UFS1, адаптированные Apple и Sony в своих игровых приставках.

Родословная многих современных распределенных файловых систем уходит корнями в проект Andrew Project, датируемый серединой 80-х годов и названный в честь двух тезок — основателей Университета Карнеги-Меллона. Проект предполагал создание всей университетской информационной инфраструктуры, от собственных рабочих станций до сетей и коммутационного ПО, но реальным наследием оказалась лишь Andrew File System (AFS). Среди ее разработчиков был и автор языка Java Джеймс Гослинг, поэтому не случайно именно в Sun Microsystems была потом создана популярная сетевая файловая система Network File System (NFS). Непосредственная коммерциализация AFS привела к созданию компании Transarc и файловой системы DCE (Distributed File System). Впоследствии эта компания была куплена IBM, и ее продукты поддерживались вплоть до появления у IBM собственной файловой системы General Parallel File System (GPFS).

Кстати, Lustre также имеет достойные корни — ее основной разработчик Питер Браам работал в Университете Карнеги-Меллона, потом в Sun Microsystems и Oracle, а сейчас создал компанию Whamcloud, вся деятельность которой посвящена Lustre.

 

Купить номер с этой статьей в PDF