Хранение объектов для облака OpenStack: сравнение Swift и Ceph

Автор: Дмитрий Уков

Обзор

Многие люди путают объектно-ориентированное хранение с блочным хранением, например, на основе iSCSI или FibreChannel (Storage Area Network, SAN), хотя на самом деле существует много различий между ними. В то время как в сети SAN система видит только блочные устройства (хороший пример имени устройства -/dev/sdb linux), доступ к хранилищу объектов можно получить только с помощью специализированного клиентского приложения (например, клиентского приложения box.com).

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

OpenStack Swift

Архитектура сети Swift

Объектное хранилище OpenStack (Swift) предоставляет масштабируемое распределенное объектное хранилище с резервированием, которое использует кластеры стандартизированных серверов. Под “распределением” понимается, что каждый фрагмент данных реплицируется по кластеру узлов хранения. Число реплик можно настроить, но оно должно составлять не менее трех для коммерческих инфраструктур.

Доступ к объектам в Swift осуществляется по интерфейсу REST. Эти объекты можно хранить, получать или обновлять по требованию. Хранилище объектов можно с легкостью распределить по большому числу серверов.

Путь доступа к каждому объекту состоит из трех элементов:

/account/container/object

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

Программное обеспечение Swift состоит из компонентов, в том числе серверов обработки аккаунтов, серверов обработки контейнеров и серверов обработки объектов, которые выполняют хранение, репликацию, управлением контейнерами и аккаунтами. Кроме того, другая машина под названием прокси-сервер предоставляет Swift API пользователям и выполняет передачу объектов от клиентов и к клиентам по запросу.

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

Кольца

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

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

Прокси-сервер

Прокси-сервер предоставляет доступ к публичному API-интерфейсу и обслуживает запросы к сущностям хранения. Для каждого запроса прокси-сервер получает информацию о местоположении аккаунта, контейнера и объекта, использующих кольцо. После получения местоположения сервер выполняет маршрутизацию запроса. Объекты передаются от прокси-сервера к клиенту напрямую без поддержки буферизации (если выразится ещё точнее: хотя в названии есть “прокси”, “прокси” сервер не выполняет “проксирование” как таковое, как например в http).

Сервер обработки объектов

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

Каждый объект хранится с использованием пути, полученного из контрольной суммы файла и метки времени операции. Последняя запись всегда перевешивает (в том числе в распределенных сценариях, что обуславливает глобальную синхронизацию часов) и гарантирует обслуживание последней версии объекта. Удаление тоже рассматривается как версия файла (файл размером 0 байт, заканчивающийся на ”.ts”, что означает tombstone (надгробный камень)). Это гарантирует правильную репликацию удаленных файлов. В этом случае старые версии файлов не появляются вновь при сбое.

Сервер обработки контейнеров

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

Специальный процесс—swift-container-updater—постоянно проверяет базы данных контейнеров на узле, на котором он работает, и обновляет базу данных аккаунта при изменении данных контейнера. Для поиска аккаунта, который необходимо обновить, он использует кольцо.

Сервер обработки аккаунтов

Работает по аналогии с сервером обработки контейнеров, но обрабатывает списки контейнеров.

Свойства и функции

— Репликация: число копий объектов, которое можно настроить вручную.

— Загрузка объекта представляет собой синхронный процесс: прокси-сервер возвращает HTTP-код “201 Created” только, если записаны более половины реплик.

— Интеграция с сервисом аутентификации OpenStack (Keystone): аккаунты ставятся в соответствие участникам.

— Проверка корректности данных: сумма md5 объекта в файловой системе по сравнению с метаданными, хранимыми в xattrs.

— Синхронизация контейнеров: становится возможным синхронизировать контейнеры на нескольких ЦОД.

— Механизм передачи: возможно использовать дополнительный узел для хранения реплики в случае отказа.

— Если размер объекта — более 5 ГБ, его необходимо разбить: эти части хранятся как отдельные объекты. Их можно прочесть одновременно.

Ceph

Ceph — это распределенное сетевое хранилище с распределенным управлением метаданными и семантикой POSIX. Доступ к хранилищу объектов Ceph можно получить с помощью различных клиентов, в том числе выделенного инструмента cmdline, клиентов FUSE и Amazon S3 (с помощью уровня совместимости под названием “S3 Gateway“). У Ceph высокая степень модульности – различные наборы функций предоставляются различными компонентами, которые можно сочетать и компоновать. В частности для хранилища объектов, доступ к которому осуществляется с помощью API-интерфейса s3, достаточно запустить три компонента: сервер обработки объектов, сервер мониторинга, шлюз RADOS.

Сервер мониторинга

ceph-mon – это облегченный рабочий процесс, который обеспечивает согласованность для распределенного принятия решений в кластере Ceph. Это также исходная точка контакта для новых клиентов, которая выдает информацию о топологии кластера. Обычно существует три рабочих процесса ceph-mon на трех различных физических машинах, изолированных друг от друга; например, на различных полках или в различных рядах.

Сервер обработки объектов

Фактические данные, размещенные в Ceph, хранятся поверх движка хранения кластера под названием RADOS, который развернут на наборе узлов хранения.

ceph-osd – это рабочий процесс хранения, который запущен на каждом узле хранения (сервере обработки объектов) в кластере Ceph.ceph-osd связывается с ceph-mon на предмет участия в кластере. Его основной целью является обслуживание запросов на чтение/запись и прочих запросов от клиентов. Также он взаимодействует с другими процессами ceph-osd для репликации данных. Модель данных относительно проста на этом уровне. Существует несколько именованных пулов, а в рамках каждого пула существует именованные объекты, в плоском пространстве имен (без директорий). У каждого объекта есть данные и метаданные. Данные объекта – это одна потенциально большая серия байтов. Метаданные – это неупорядоченный набор пар ключ-значение. Файловая система Ceph использует метаданные для хранения информации о владельце файла и т.п. Под ней рабочий процесс ceph-osd хранит данные в локальной файловой системе. Мы рекомендуем Btrfs, но подойдет любая файловая система POSIX с расширенными атрибутами.

Алгоритм CRUSH

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

Шлюз Rados

radosgw – это сервис FastCGI, предоставляющий API RESTful HTTP для хранения объектов и метаданных на кластере Ceph.

Свойства и функции

— Частичные или полные операции чтения и записи

— Снимки

— Атомарные транзакции для таких функций как добавление, усечение и клонирование диапазона

— Соотнесение ключ-значение на объектном уровне

— Управление репликами объектов

— Агрегация объектов (серий объектов) в группу и соотнесение группы серии OSD

— Аутентификация с помощью совместно используемых секретных ключей: и клиент и кластер мониторинга имеют копию секретного ключа клиента
— Сочетаемость с API S3/Swift

Обзор функциональности

	Swift	Ceph
Репликация	Да	Да
Максимальный размер объекта	5 ГБ (более крупные объекты сегментируются)	Неограничен
Установка multi DC (распределение между ЦОД)	Да (репликация только на уровне контейнеров, но предлагается схема для полной репликации между ЦОД)	Нет (требует асинхронной последующей репликации целостности данных, которую Ceph пока не поддерживает)
Интеграция с Openstack	Да	Частичное (отсутствие поддержки Keystone)
Управление репликами	Нет	Да
Алгоритм записи	Синхронный	Синхронный
API-интерфейс, совместимый с Amazon S3	Да	Да
Метод размещения данных	Кольца (статическая структура маппинга)	CRUSH (алгоритм)

Источники

Official Swift documentation – Источник описания структуры данных.
Swift Ring source code on Github – База исходного кода классов Swift Ring и RingBuilder.
Blog of Chmouel Boudjnah – Полезные советы по использованию Swift.
Official Ceph documentation– Основной источник описаний структур данных.

Оригинал статьи на английском языке