Принципы организации объектных хранилищ

Storage by Phade01

Наш коллега недавно написал об архитектуре объектного S3-хранилища Mail.ru Cloud Storage. Теперь мы переводим хорошую статью об общих особенностях и ограничениях объектных хранилищ.

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

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

Ключевые особенности объектных хранилищ

Поскольку у объектного хранилища всего несколько доступных операций, появляются важные ограничения:

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

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

Эта нарочитая простота приводит к ряду ценных последствий в контексте высокопроизводительных вычислений:

1. Блоки данных предназначены для однократной записи, поэтому узлу не нужно блокировать объект перед чтением содержимого. Нет риска, что другой узел что-то запишет в объект во время чтения.
2. Единственная ссылка на объект — уникальный идентификатор объекта. Значит, для определения физического местоположения объекта (диска или узла хранения) можно использовать простой хэш идентификатора объекта. Чтобы узнать, на каком сервере фактически размещено содержимое объекта, вычислительному узлу не нужно связываться с сервером метаданных.

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

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

Ограничения объектных хранилищ

Простота организации объектного хранилища делает его масштабируемым, но также ограничивает его функциональность:

1. Из-за неизменяемости объектов сценарии использования ограничены однократной записью и многократным чтением. Значит, объектное хранилище нельзя использовать для временного или горячего хранения, а его приложения ограничиваются архивированием данных.
2. Объект состоит из данных и идентификатора объекта. Любые метаданные (логическое имя файла, время создания, владелец, права доступа) нужно размещать вне хранилища. Это может быть неудобно.

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



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

Поскольку объектное хранилище не пытается сохранить совместимость с POSIX, реализации шлюзов — удобные места для хранения метаданных объектов, превосходящие те, что традиционно предоставлялись ACL POSIX и NFSv4.

Например, S3 API предоставляет средства для связывания произвольных пар ключ-значение с объектами в качестве определяемых пользователем метаданных. А WOS DDN — запрашивать базу метаданных объектов, чтобы выбрать все объекты, соответствующие критериям запроса.

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

Хотя отделение пользовательского интерфейса от базового объектного представления данных обеспечивает гибкость, не все такие шлюзы — шлюзы с двойным доступом. Двойной (или, например, тройной) доступ позволяет получать доступ к одним и тем же данным через несколько интерфейсов. Например, записывать объект с помощью PUT, но читать его обратно, как если бы это был файл. Шлюзы с двойным доступом стараются делать согласованными, однако, возможна ситуация, когда после записи данных они не сразу видны через все интерфейсы.

Реализации объектных хранилищ

Хотя принципы организации объектного хранилища достаточно просты, конкретные продукты отличаются. В частности, для обеспечения устойчивости, масштабируемости и производительности могут использоваться различные способы перемещения данных при получении запроса PUT или GET.

ShellStore: простейший пример

В этом разделе я хочу проиллюстрировать простоту базового хранилища объектов с помощью ShellStore Яна Киркера. Оно представляет собой хотя и безумную, но удивительно лаконичную реализацию объектного хранилища. Прелесть в том, что он демонстрирует основные тонкости работы хранилища с помощью простого bash.

DDN WOS

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

Простота WOS делает его отличной моделью для иллюстрации того, как в целом работают объектные хранилища. WOS используют очень крупные компании (например, считается, что на нем работает Siri), оно имеет такие примечательные особенности:

1. Четкое разделение бэкенд-серверов хранения объектов и фронтенд-шлюзов. API, обеспечивающий доступ к бэкенду, прост и доступен через C ++, Python, Java и raw REST.
2. Объекты хранятся на блочных устройствах без использования файлового слоя, например ext3. DDN позиционирует это как «NoFS».
3. Кодирование со стиранием поддерживается как первоклассная функция, хотя скорость кодирования фиксирована. Настройка отказоустойчивости с помощью кодирования со стиранием должна выполняться на нескольких узлах.
4. Доступные для поиска метаданные объектов встроены в бэкенд, поэтому вы можете не только помечать объекты, но и извлекать их на основе запросов. Это важно: в большинстве хранилищ нельзя искать объекты по метаданным.
5. Активная очистка данных происходит на бэкенде. В большинстве других объектных хранилищ предполагается, что целостность данных проверяют чем-то находящимся ниже уровня системы хранения объектов.
6. Шлюз S3 построен на основе Apache HBase.
7. Шлюзы NFS масштабируются до восьми серверов. У каждого есть локальный дисковый кэш записи и глобальная согласованность с помощью функции сохранения при закрытии.

Вот несколько слайдов, которые показывают общую архитектуру WOS.

Openstack Swift

OpenStack Swift — одна из первых крупных реализаций объектного хранилища корпоративного уровня с открытым исходным кодом. Это то, что сегодня стоит за многими частными облаками. Но поскольку хранилище писали давно, в его архитектуре много неоптимальных решений:

1. Swift хранит объекты в блочных файловых системах, таких как ext3. И для хранения метаданных полагается на функции файловой системы, в частности xattrs.
2. Его внутренняя база данных сопоставлений объектов и местоположений хранится в файлах .gz, которые реплицируются на все хранилища и прокси-узлы.
3. Серверы контейнеров и учетных записей хранят подмножество метаданных объектов (атрибуты контейнера и учетной записи) в реплицированных базах данных sqlite.
4. Отсутствуют важные функции, например, кодирование со стиранием.

Вы можете прочитать официальную документацию по архитектуре OpenStack Swift.

RedHat/Inktank Ceph

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


Общая схема потока данных

Объекты сопоставляются с группами размещения с помощью простой хеш-функции. Группы размещения (PG) — логические абстракции. Через хэш CRUSH они сопоставляются с демонами хранения объектов, которые владеют коллекциями физических дисков.

CRUSH уникален тем, что позволяет добавлять дополнительные OSD без перестройки всей структуры карты объект-PG-OSD. Переназначать на недавно добавленные OSD нужно только часть групп размещения, что обеспечивает гибкую масштабируемость и отказоустойчивость.

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

Ceph реализует политику устойчивости на стороне сервера, так что клиент, выполняющий PUT или GET объекта, общается только с одним OSD. После помещения объекта в OSD этот OSD отвечает за его репликацию в другие OSD, выполнение сегментирования, кодирования стиранием и распределения закодированных сегментов. Хорошее описание (с диаграммами) путей данных репликации и кодирования стиранием Ceph опубликовали в Intel.

Ещё несколько ресурсов с информацией об архитектуре Ceph:

• Официальная документация по архитектуре Ceph.
• «Создание органичной службы хранения блоков в CERN с помощью Ceph», доклад, представленный на CHEP2013.
• «RADOS: масштабируемая и надежная служба хранения для петабайтных кластеров хранения». Документ от PDSW'07, описывающий платформу хранения объектов, которая работает под Ceph (RADOS).

Scality RING

Я почти ничего не знаю о Scality RING. Но эта платформа быстро проникает в сферу High-Performance Computing и используется в Национальной лаборатории Лос-Аламоса, которая ведет разработки в области ядерного вооружения.

Scality RING — исключительно программный продукт (в отличие от DDN WOS), который работает на любом оборудовании. У него есть все стандартные шлюзовые интерфейсы (S3, NFS / CIFS и REST, называемые «коннекторами»), кодирование со стиранием и масштабируемый дизайн. Кажется, он основан на детерминированном хеш-коде, который отображает данные на определенный узел хранения в кластере. Все узлы хранения — одноранговые, и с помощью внутренней одноранговой передачи любой узел может отвечать на запросы данных, хранящихся на любом другом узле.

Некоторые архитектурные детали и ссылки на конкретные патенты — в презентации Scality RING.

Другие продукты

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

NetApp StorageGRID

Платформа хранения объектов StorageGRID от NetApp появилась после покупки компании Bycast. StorageGRID в основном используют в бизнесе, связанном с хранением медицинских записей. NetApp особо не рассказывает о StorageGRID, и, насколько я могу судить, отметить нечего, кроме использования Cassandra в качестве прокси-базы данных для отслеживания индексов объектов.

Cleversafe

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

Кластеры Cleversafe нельзя легко масштабировать, поскольку вы должны заранее купить все узлы хранения объектов (sliceStors). Всё, что вы можете — увеличивать емкость каждого узла хранения. Заполните до предела емкость каждого узла — придется покупать новый кластер. Такой подход нормален для организаций, которые масштабируются целыми стойками, но менее практичен за пределами высокопроизводительных центров HPC. Среди известных клиентов Cleversafe — Shutterfly.

Cleversafe не так функциональна, как другие платформы хранения объектов (если судить по последней инструкции, которую я читал). Она предоставляет несколько интерфейсов REST («устройств доступа»), включая S3, Swift и HDFS. Но доступ на основе NFS/CIFS осуществляется сторонними приложениями поверх S3/Swift. Впрочем, крупные компании часто пишут собственное ПО для работы с S3, так что это небольшое препятствие при масштабировании.

Периферийные технологии

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

iRODS: объектное хранилище без объектов или хранилища

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

Подробнее про iRODS — в руководстве пользователя системы.

MarFS: POSIX-интерфейс к объектному хранилищу

MarFS — платформа, разработанная в Национальной лаборатории Лос-Аламоса. Предоставляет интерфейс для объектного хранилища, включающий знакомые операции POSIX. В отличие от шлюза, который находится перед хранилищем объектов, MarFS предоставляет интерфейс непосредственно на клиентских узлах и прозрачно транслирует операции POSIX в вызовы API, понятные хранилищу объектов.

Спроектированная как легкая, модульная и масштабируемая, MarFS во многом выполняет те же функции, что, например, клиент llite, сопоставляя вызовы POSIX на клиенте хранилища, с вызовами, понятными базовому представлению данных Lustre.

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

Сами же данные находятся в хранилище объектов (предоставляемом Scality в реализации LANL), а демон MarFS FUSE на каждом клиенте хранилища использует файловую индекс-систему GPFS для связывания вызовов ввода-вывода POSIX с данными, находящимися в хранилище объектов.

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

Посмотрите презентацию MarFS на MSST 2016, чтобы узнать больше.

Успехов!

Об объектном хранилище Mail.ru Cloud Solutions: Архитектура S3. 3 года эволюции Mail.ru Cloud Storage.

Что еще почитать:

1. Пример event-driven приложения на основе вебхуков в объектном S3-хранилище Mail.ru Cloud Solutions.
2. Больше чем Ceph: блочное хранилище облака MCS.
3. Организация бэкапа PostgreSQL из Kubernetes в S3-хранилище.
4. Наш Телеграм-канал с новостями об обновлениях S3-хранилища и других продуктов.