openstack swift что это

Обзор облачного хранения данных в OpenStack Swift

298 просмотров 2 2021-04-14

Введение

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

Логическая организация хранения данных в OpenStack Swift.

Основные логические сущности Swift:

И как они связаны между собой:
В аккаунте может содержаться несколько пользователей (users). Принадлежит владельцу (владельцем может быть компания, субъект и т.п.). Владелец (tenant) может создавать дополнительных пользователей. Учетная запись содержит в себе контейнеры (container). Контейнеры в свою очередь содержат в себе объекты (object).
Контейнеры в пределах одной учетной записи должны иметь уникальные имена. Но могут иметь одинаковые имена, если они располагаются в разных учетных записях.
Объект – это атомарная единица хранения данных. Объект может представлять из себя любые разношерстные данные, будь то текстовый файл, изображение, снимок виртуальной машины и т.п. По умолчанию в Swift у объекта три репликации (с возможностью физического разделения по разным ЦОД). Для того чтобы обратиться к объекту нам необходима связка из 3 элементов: account, container и object.

Физическая организация хранения данных в OpenStack Swift.

Физическая структура реализована в виде иерархии: Region – Zone – Storage Server – Disk.
Каждый регион соответствует отдельной площадке или ЦОД. Если у нас несколько ЦОД и они географически разделены, то кластер Swift будет содержать несколько регионов.
Зона (Zone) – множество серверов региона, имеющее общий параметр доступности. В качестве этого параметра может выступать подключение серверов к одному коммутатору или ряд стоек с серверами с силовой линией от одного автомата.
Сервер хранения (Storage Server) – любой linux-сервер, участвующий в хранении данных Swift.
Диск (Disk) – диск сервера, где физически хранятся данные (рекомендуется файловая система ext4 или XFS, а также большой размер inode для метаданных).

Как извлекаются данные из хранилища Swift.

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

Заключение.

Итак, вкратце мы рассмотрели принцип организации одного из компонентов OpenStack – облачное хранилище Swift и его основные сущности. В следующей статье мы расскажем развернуть инфраструктуру OpenStack на одном сервере.

Источник

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

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

Обзор

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

OpenStack Swift

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

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

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

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

Объект (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 — это распределенное сетевое хранилище с распределенным управлением метаданными и семантикой 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

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

Источники

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

Источник

Национальная библиотека им. Н. Э. Баумана
Bauman National Library

Персональные инструменты

OpenStack Swift

Объектное хранилище Swift (OpenStack Object Storage) – один из двух самых первых сервисов OpenStack. Swift – это программно определяемое «безграничное» облачное хранилище (software-defined storage, SDS), работающее с объектами; характеризуется отказоустойчивостью и высокой надежностью. [Источник 1]

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

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

Стоит отметить, что Swift является стабильным и востребованным на рынке продуктом: такие компании, как Cisco, IBM, NASA, PayPal, HP, Symantec, Dreamworks и многие другие поддерживают в промышленной эксплуатации кластеры размерами в петабайты.

Содержание

Ключевые особенности OpenStack Swift

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

Основным преимуществом объектного хранения является очень низкая стоимость реализации по сравнению с хранилищем корпоративного уровня, одновременно с обеспечением масштабируемости и избыточности данных. [Источник 3]

Основные свойства архитектуры Swift

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

Рассмотрим более подробно архитектуру Swift.

Основные функции

Логическая структура

Рисунок 1 – Структурная схема

Логическая структура Swift представлена структурной схемой на рисунке 1. Она состоит из трех уровней:

Физическая структура

Физическая структура Swift состоит из следующих компонентов:

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

Метод размещения данных

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

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

Доступные сервисы

Рассмотрим, какие сервисы обслуживают Swift. Сервисы могут работать на всех узлах, или же под отдельные сервисы могут выделяться отдельные узлы. Как правило, openstack-swift-proxy выносится на отдельные узлы, а три остальных сервиса работают на всех узлах кластера.

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

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

Хранилищем данных управляют несколько выполняемых по расписанию служебных процессов, к которым относятся сервисы репликации, а также процессы аудита и процессы обновления. Рассмотрим их:

Пример настройки хранилища

Рисунок 2 – Cхема организации виртуальных машин

Для установки сервиса OpenStack Swift предлагается использовать три виртуальные машины, каждой из которых выделено по 1 Гб оперативной памяти. Cхема организации виртуальных машин представлена на рисунке 2. Серверу sw1.test.local назначена роль Swift proxy, а два оставшихся sw2.test.local и sw3.test.local будут использованы в качестве серверов хранения. Для начала необходимо установить на все три виртуальные машины CentOS. Также необходимо убедиться, что все четыре виртуальные машины могут разрешать имена друг друга и между ними есть IP-связанность. В отсутствие DNS-сервера можно просто реализовать это через общий файл /etc/hosts. Далее на сервере os1.test.local необходимо проделать следующее: создать нового пользователя, добавить его с ролью admin в проект service, создать сервис и с использованием идентификатора сервиса создать точку входа в сервис:

Далее можно подключиться к виртуальной машине sw1.test.local, где мы будет настроен сервис Swift-proxy.

Установка сервиса Swift-proxy

В первую очередь необходимо установить необходимые пакеты на виртуальную машину sw1.test.local:

В конфигурационном файле прокси требуется прописать сервер Keystone (это сервис OpenStack, который предоставляет API для аутентификации):

Далее следует указать имя проекта, пользователя и пароль в Keystone:

Следующим этапом требуется определить, какие роли имеют право изменять данные в учетной записи (проекте):

Остальные параметры предлагается оставить по умолчанию. В частности, местоположение сервиса memcached (memory cache daemon) – базы данных в памяти для кэширования информации клиентов, прошедших аутентификацию.

Установка узлов хранения Swift

Необходимо установить необходимые пакеты на две оставшиеся виртуальные машины: sw2.test.local и sw3.test.local. Команды нужно выполнять на обоих серверах:

Каждой из двух виртуальных машин добавим по два локальных диска и на каждом из них создадим по одному разделу. Имена блочных устройств зависят от системы виртуализации и типа эмулируемого устройства. В случае KVM VirtIO это /dev/vdb и /dev/vdc. Создадим на обоих разделах виртуальных машин sw2 и sw3 файловую систему XFS:

Файловые системы необходимо смонтировать в поддиректории /srv/node:

Если SELinux не отключен, то требуется восстановить контекст на директорию /srv/node:

Для того чтобы Swift выполнял репликацию, необходимо настроить демон rsyncd. Для этого необходимо создать на обоих узлах файл /etc/rsyncd.conf следующего содержания:

Далее запускаем и активируем сервис:

В случае, если SELinux не был отключен, необходимо выполнить команду:

Проверка работы демона rsync для обоих серверов:

Теперь на каждом из двух узлов узлов необходимо создать по три конфигурационных файла оставшихся сервисов. Для управления конфигурацией сервисов Swift используется система Paste.deploy. Значения опций описаны на странице официальной документации OpenStack. Содержание конфигурационного файла /etc/swift/account-server.conf:

Содержание конфигурационного файла /etc/swift/object-server.conf:

Содержание конфигурационного файла /etc/swift/container-server.conf:

Создание сервисных колец Swift

Далее добавляем каждый из двух дисков на узлах sw2 и sw3, указывая их IP-адреса с помощью команды swift-ring-builder add:

Проверка содержимого кольца:

Распределяем разделы по устройствам в кольце:

Затем подобные же команды повторяем для колец container и object. После этого копируем файлы колец на обе виртуальные машины sw2 и sw3:

Завершение настройки

В файл /etc/swift/swift.conf необходимо добавить два случайных параметра, которые следует держать в секрете. Они играют роль аналога «соли» файла /etc/shadow и будут добавляться к имени объекта для предотвращения DoS-атаки. Если злоумышленник будет знать значение этих параметров, то он сможет узнать реальное расположение объектов в разделах Swift.

Копия этого файла должна быть на каждом сервере:

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

Источник