Object Storage: можно ли прожить без файлов?

АрхивСтатьи

Хоть нам и кажется, что файловая система - неизменная часть компьютера, без неё не просто можно обойтись, но и использовать новые возможности.

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

Статистика не врёт: объём цифровой информации удваивается каждые восемнадцать месяцев. И весь этот информационный вал по большей части состоит из неструктурированных данных. А если быть более точными, то девяносто пять процентов всей информации в мире хранится в неструктурированном виде, и лишь оставшиеся пять процентов составляют различные базы данных - тем или иным образом структурированную информацию.

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

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

Является ли хранение разнообразной неструктурированной информации в виде привычных нам файлов безальтернативным вариантом? Исследователи говорят: нет. И предлагают способ хранения, больше подходящий реалиям настоящего, чем каталоги и файлы. Концепция объектных хранилищ (object storage), появившаяся в середине девяностых годов прошлого столетия как академическая разработка, сегодня работает на уровне стандарта, принятого на вооружение ключевыми разработчиками устройств и технологий хранения.

Но смогут ли какие-то неведомые объекты потеснить привычные файлы? Или двум технологиям суждено сосуществовать?

Объектная идеология хранения. От идеи до стандартов

Проблема эффективного хранения неструктурированных данных в виде файлов связана с двумя ключевыми особенностями этих самых данных - их содержимым и контекстом, в котором должна осуществляться их поддержка. Ну в самом деле, если структурированные данные создаются именно с целью их дальнейшего эффективного извлечения из базы данных (например, реляционной), то в неструктурированных данных важнее их содержимое ("О, на этом фото я в отпуске, подпираю Пизанскую башню!") и то пространственно-временное окружение, в котором они созданы ("Ух ты, это же сто лет назад было! А вот тот, третий слева, кто такой?").

С записями базы данных всё значительно проще. Если клиент разместил заказ на поставку, то менеджеру по продажам не составляет труда по его имени извлечь из базы требуемый адрес и указать дату поставки для транспортного отдела.

Файловые системы можно считать лишь бледным подобием базы данных. Атрибуты файлов скудны и неочевидны: имя файла, его размер, дата последней модификации и, возможно, владелец. Взять, к примеру, томограммы, которые в больницах ныне сплошь и рядом хранят в цифровом виде. Врачу они нужны только на момент диагностирования проблемы. После выздоровления пациента необходимость в них отпадает. Нужно ли их удалять или отправить в архив? Всё зависит от контекста, то есть от тяжести заболевания. Будет ли продолжение лечения? Возможны ли рецидивы? На всякий случай складируются все файлы, зачастую бессмысленно заполняя дисковое пространство и усложняя поиск действительно нужной информации.

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

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

Впервые понятие объектного хранения данных было предложено научным сообществом в начале 90-х годов прошлого столетия. Все эти годы концепция продолжала развиваться и сегодня делает всё более серьёзные попытки утвердиться в качестве отраслевого стандарта.

Чем же объект отличается от файла? Вспомним, как хранятся файлы. Файловая система предоставляет пользователю высокоуровневую абстракцию файлового хранилища (иерархия каталогов и хранящихся в них файлов), преобразуя её для контроллера устройства хранения в блочно-ориентированную информацию (LBA-абстракцию), в которой каждый файл представлен массивом несмежных блоков данных, имеющих уникальные адреса. Контроллер устройства хранения работает с собственной низкоуровневой информацией (дорожки и сектора для дисковых накопителей; страницы, блоки и модули для твёрдотельных хранилищ).

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

Уровень управления объектами переносится из системного программного обеспечения в контроллер устройства хранения, унифицируя тем самым операции работы с данными в различных операционных средах.

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

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

Кроме того, метаданные объектов облегчат руководству больницы планирование выделения ресурсов, например, при сборе и обработке статистики по снимкам определённой болезни.

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

Поскольку метаданные объекта могут, среди прочего, содержать и указатели на другие связанные с ним объекты или традиционные файлы, объект можно рассматривать как агрегатор, объединяющий распределённые данные. В этом смысле он чем-то напоминает URL - один из столпов современного интернета. Сходство объекта с URL основано и на его уникальности. Каждый объект однозначно определяется Object ID (OID) - числовым идентификатором, служащим уникальным указателем на объект. Наличие OID позволяет программному обеспечению объектного хранилища сохранять объекты в обширной (зависит от разрядности OID) области простой адресации, исключая необходимость иерархической структуры каталогов. Фактически объекты могут перемещаться программным обеспечением объектного хранилища, не прерывая работы приложений и пользовательского доступа.

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

В корпоративных сетях объектный подход может стать отправной точкой достаточно простого масштабирования системы хранения и увеличения её производительности, поскольку исключает массу присущих сетевым хранилищам (NAS) операций - таких, например, как управление inode, организацию параллельного чтения и записи в файлах, их блокировку и управление правами доступа к ним.

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

Стандарты OSD. Трудности роста объектных хранилищ

Своим рождением идеология объектного хранения данных обязана финансируемой правительством США работе команды исследователей из университета Карнеги Меллона под руководством профессора Гарта Гибсона. Их разработка NASD (Network Atteched Secure Disk) преследовала цель создания контроллера дисковых накопителей, обладающего вычислительной мощностью, достаточной для решения задач не только блочного управления дисковым пространством, но и обеспечения поддержки абстракции операций чтения и записи на уровне гибких контейнеров данных - прообразов объектов. Основная задача разработки - стандартизация универсальной высокоуровневой единицы хранения, обеспечивающей формирование масштабитуемых и безопасных сетевых хранилищ.

Протокол системы безопасности объектного хранилища был разработан аспирантом профессора Гибсона Говардом Гобьовым - в будущем одним из создателей проприетарной Google File System.

Разработка команды Гибсона была представлена в Национальный институт стандартов ANSI, точнее, в его группу Т10, отвечающую за стандарт SCSI. Ведь несмотря на существенные подвижки в области физических интерфейсов SCSI, между устройствами хранения и компьютерами, такими, как SCSI Fiber Channel (FCP) и Serial Attached SCSI (SAS), и появление протокола iSCSI, работающего поверх сетей TCP/IP, в области логической организации стандарта (набора команд SCSI) мало что изменилось с далекого 1983 года.

Усилиями учёных университета Карнеги Меллона, а также специалистов отраслевой группы, организованной консорциумом NSIC (National Storage Industry Consortium), в которую входили представители IBM, HP, Intel, Seagate, Panasas и других заинтересованных компаний, в ANSI T10 был представлен черновик интерфейсной спецификации Т10/1355-D. В дальнейшем она была существенно переработана, и в сентябре 2004 года был ратифицирован ANSI в виде стандарта SCSI T10 OSD V1.

Стандарт OSD (Object Storage Device) определяет единицу хранения как виртуальный объект, управление которым осуществляется вместо файловой системы совместимым с OSD контроллером. Приложение получает доступ к объекту по его идентификатору OID, который в стандарте OSD V1 являлся 64-разрядным числом. Метаданные каждого объекта определяются 32-разрядным числом страниц на объект с 32-разрядным числом атрибутов на каждую страницу. Причём львиную долю этих атрибутов стандарт предлагает определять приложениям, работающим с объектами.

Важной особенностью стандарта стало определение протокола безопасности работы с объектами, являющегося развитием работы Говарда Гобьова. Протокол определяет проверку целостности запроса SCSI и его законность использования клиентом, работающим с объектом. Каждая команда SCSI сопровождается 160-разрядным хэш-кодом (ключ HMAC-SHA1), который однозначно идентифицирует и сам объект, и список операций, которые могут быть выполнены над ним.

OSD V1 определяет следующие виды объектов: корневой объект (root), соответствующий самому хранилищу OSD, пользовательские объекты (user), создаваемые приложениями, объекты-коллекции (collection), объединяющие объекты, принадлежащие одному проекту, и объекты-разделы (partition) - контейнеры для пользовательских объектов и коллекций, обеспечивающие их коллективную безопасность и единые правила управления данными.

В 2008 году ратифицирована вторая версия стандарта ANSI T10 OSD V2. В дополнение к спецификациям первой версии в стандарт были добавлены операции над множеством объектов, а также понятие "снимков" (snapshots) - образов объектов, коллекций или разделов, которые могут быть перенесены между множеством устройств хранения.

Благодаря стандартизации OSD разработчики получили возможность опробовать новую парадигму хранения в конкретных реализациях. Исследовательская лаборатория Компания IBM одной из первых разработала прототип объектно-ориентированного контроллера для сетевых хранилищ, названного ObjectStone. В нём абстракция объектно-ориентированной памяти реализована поверх стандартного блочно-ориентированного интерфейса и реализует все спецификации стандарта OSD.

Взаимодействие клиентов в ObjectStone сетях хранения данных (SAN) реализовано с использованием протокола iSCSI, для подключения контроллера к сетевым хранилищам данных (NAS), основанным на традиционных файловых системах, был реализован симулятор OSD. Разработка IBM носит исследовательский характер и позволяет проводить тестирование работы конкретных приложений с объектно-ориентированными хранилищами. В своих же интересах IBM использует стандарт OSD для разработки файловой системы zFS - распределённое бессерверное решение, обеспечивающее хранение объектов и управление ими на множестве равноправных компьютеров, связанных высокоскоростными каналами.

Более близкая к потребителю компания Dell анонсировала целую линейку объектно-ориентированных хранилищ DX Object Storage, включающую модели ёмкостью от двух до шестидесяти четырёх терабайт. DX Object Storage позиционируется компанией как масштабируемое решение для эффективного хранения и управления неструктурированными данными.

Поддержка стандартов OSD осуществляется также в open source проекте открытой облачной платформы OpenStack.

OSD vs NAS. Или вместе лучше?

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

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

Кроме того, работа с объектами эффективна в случае относительно статичных данных - например, тех, что хранятся в архивах. Исследования показали, что после создания более 70 процентов неструктурированной информации не подвергается модификации и доступ к ней осуществляется относительно редко, 20 процентов составляют "золотую середину" и только 10 активно используется и модифицируется. Именно с последним типом данных наиболее эффективно справляются файловые системы и поддерживающие их сетевые хранилища.

Кроме масштабируемости, эффективность объектных хранилищ дополнительно связана с интеллектуальным управлением данными. Богатая метаинформация объектов позволит оптимизировать процесс хранения и минимизировать затраты на него.

Ну а стремительный рост социальных сервисов и облачных хранилищ - кладезей неструктурированной информации, скорее всего, стимулирует прогресс в области стандартизации OSD и совершенствования парадигмы объектно-ориентированной памяти.