Автор: Дмитрий Уков
Обзор
Многие люди путают объектно-ориентированное хранилище с блочным хранилищем, таким как iSCSI или FibreChannel (сеть хранения данных, SAN), хотя на самом деле между ними существует много различий.Хотя в сети SAN система видит только блочные устройства (хороший пример имени устройства — /dev/sdb linux), доступ к объектному хранилищу возможен только с помощью специализированного клиентского приложения (например, клиентского приложения box.com).
Блочное хранилище — важная часть облачной инфраструктуры.
Основные способы его использования — хранение образов виртуальных машин или хранение пользовательских файлов (например, резервных копий различных типов, документов, изображений).
Основным преимуществом объектного хранилища является очень низкая стоимость внедрения по сравнению с хранилищем корпоративного уровня, обеспечивая при этом масштабируемость и избыточность данных.
Существует два наиболее распространенных способа реализации объектного хранилища.
В этой статье мы сравним два метода, для которых OpenStack предоставляет интерфейс.
OpenStack Swift
Сетевая архитектура Swift
Объектное хранилище OpenStack (Swift) обеспечивает масштабируемость распределенный избыточное объектное хранилище, использующее кластеры стандартизированных серверов.Под «распределением» мы подразумеваем, что каждая часть данных реплицируется в кластере узлов хранения.
Количество реплик можно настроить, но для коммерческих инфраструктур их должно быть не менее трех.
Доступ к объектам в Swift осуществляется через интерфейс REST. Эти объекты можно сохранять, извлекать или обновлять по требованию.
Объектное хранилище можно легко распределить по большому количеству серверов.
Путь доступа к каждому объекту состоит из трех элементов: /аккаунт/контейнер/объект Объект — это уникальное имя, идентифицирующее объект. Учетные записи и контейнеры позволяют группировать объекты.
Вложенность учетных записей и контейнеров не поддерживается.
Программное обеспечение Swift состоит из компонентов, включая серверы обработки учетных записей, серверы обработки контейнеров и серверы обработки объектов, которые выполняют хранение, репликацию, управление контейнерами и учетными записями.
Кроме того, другая машина, называемая прокси-сервером, предоставляет пользователям Swift API и обрабатывает передачу объектов клиентам и обратно по запросу.
Серверы обработки учетных записей предоставляют списки контейнеров для конкретной учетной записи.
Серверы обработки контейнеров предоставляют списки объектов в конкретных контейнерах.
Серверы обработки объектов просто возвращают или сохраняют сам объект, если указан полный путь.
Кольца
Поскольку пользовательские данные распределены по множеству компьютеров, важно точно отслеживать, где они находятся.Swift достигает этого, используя внутренние структуры данных, называемые кольцами.
Кольца располагаются на всех узлах кластера Swift (как в хранилищах, так и в прокси-серверах).
Таким образом, Swift решает проблему, заключающуюся в том, что многие распределенные файловые системы полагаются на централизованный сервер метаданных, где это хранилище метаданных становится узким местом для доступа к справочным метаданным.
Сохранение или удаление отдельного объекта не требует обновления кольца, поскольку кольца отражают членство в кластере лучше, чем центральная карта данных.
Это положительно влияет на операции ввода-вывода, что значительно снижает задержку доступа.
Существуют отдельные кольца для баз данных учетных записей, контейнеров и отдельных объектов, но все кольца работают одинаково.
Короче говоря, для данной учетной записи, контейнера или имени объекта кольцо возвращает информацию о его физическом местоположении на узле хранения.
Технически это действие осуществляется методом последовательное хеширование .
Подробное объяснение алгоритма звонка можно найти в наш блог И по этой ссылке .
Прокси сервер
Прокси-сервер обеспечивает доступ к общедоступному API и запросам служб к объектам хранения.По каждому запросу прокси-сервер получает информацию о местоположении аккаунта, контейнера и объекта, использующего кольцо.
После получения местоположения сервер направляет запрос.
Объекты передаются с прокси-сервера клиенту напрямую, без какой-либо поддержки буферизации (если говорить еще точнее: хотя в названии есть «прокси», но «прокси»-сервер не осуществляет «проксирование» как таковое, как в например http).
Сервер обработки объектов
Это простое хранилище BLOB (больших двоичных объектов), в котором можно хранить, извлекать и удалять объекты.Объекты хранятся в виде двоичных файлов в узлах хранения, а метаданные располагаются в расширенных атрибутах файла (xattrs).
Поэтому файловая система объектных серверов должна поддерживать xattrs для файлов.
Каждый объект сохраняется с использованием пути, полученного на основе контрольной суммы файла и метки времени операции.
Последняя запись всегда имеет преимущественную силу (в том числе в распределенных сценариях, которые обеспечивают глобальную синхронизацию часов) и гарантирует обслуживание последней версии объекта.
Удаление также рассматривается как версия файла (0-байтовый файл, заканчивающийся на «.
ts», что означает «надгробие»).
Это гарантирует правильную репликацию удаленных файлов.
В этом случае старые версии файлов не появляются повторно при сбое.
Сервер обработки контейнеров
Сервер обработки контейнеров обрабатывает списки объектов.Он не знает, где находятся объекты, только содержимое конкретного контейнера.
Списки хранятся в виде файлов базы данных sqlite3 и реплицируются по кластеру аналогично объектам.
Также отслеживается статистика, включая общее количество объектов и объем хранилища, используемого для данного контейнера.
Специальный процесс — Swift-Container-Updater — постоянно проверяет базы данных контейнеров на узле, на котором он запущен, и обновляет базу данных учетных записей при изменении данных контейнера.
Он использует кольцо, чтобы найти учетную запись, которую необходимо обновить.
Сервер обработки учетных записей
Работает аналогично серверу обработки контейнеров, но обрабатывает списки контейнеров.
Свойства и функции
— Репликация: количество копий объектов, которое можно настроить вручную.— Загрузка объекта — синхронный процесс: прокси-сервер возвращает HTTP-код «201 Created» только в том случае, если записано более половины реплик.
— Интеграция со службой аутентификации OpenStack (Keystone): учетные записи сопоставляются участникам.
- Проверка данных: сумма md5 объекта в файловой системе по сравнению с метаданными, хранящимися в xattrs. — Синхронизация контейнеров: появляется возможность синхронизировать контейнеры между несколькими дата-центрами.
- Механизм переноса: есть возможность использовать дополнительный узел для хранения реплики в случае сбоя.
- Если размер объекта превышает 5 ГБ, его необходимо разделить: эти части хранятся как отдельные объекты.
Их можно читать одновременно.
Цеф
Ceph — это распределенное сетевое хранилище с распределенным управлением метаданными и семантикой POSIX. Доступ к объектному хранилищу Ceph можно получить с помощью различных клиентов, включая выделенный инструмент cmdline, клиенты FUSE и Amazon S3 (с использованием уровня совместимости, называемого « S3-шлюз ").Ceph является высокомодульным — разные наборы функций предоставляются разными компонентами, которые можно комбинировать и составлять.
В частности, для хранилища объектов, доступ к которому осуществляется через API s3, достаточно запустить три компонента: сервер обработки объектов, сервер мониторинга, шлюз RADOS. 
Сервер мониторинга
ceph-mon — это облегченный рабочий процесс, обеспечивающий согласованность распределенного принятия решений в кластере Ceph. Он также является исходной точкой контакта для новых клиентов и предоставляет информацию о топологии кластера.Обычно существует три рабочих процесса ceph-mon на трех разных физических машинах, изолированных друг от друга; например, на разных полках или в разных рядах.
Сервер обработки объектов
Фактические данные, размещенные в Ceph, хранятся поверх механизма хранения кластера, называемого РАДОС , который развернут на наборе узлов хранения.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 реагировать на изменения в членстве в кластере.
Радос шлюз
radosgw — это служба FastCGI, предоставляющая RESTful HTTP API для хранения объектов и метаданных в кластере Ceph.Свойства и функции
- Частичные или полные операции чтения и записи - Картинки - Атомарные транзакции для таких функций, как добавление диапазона, усечение и клонирование.— Сопоставление ключ-значение на уровне объекта — Управление репликами объектов — Объединение объектов (серий объектов) в группу и соотнесение группы с сериями OSD - Аутентификация с использованием общих секретных ключей: и клиент, и кластер мониторинга имеют копию секретного ключа клиента.
— Совместимость с API S3/Swift
Обзор функциональности
| Быстрый | Цеф | |
| Репликация | Да | Да |
| Максимальный размер объекта | 5 ГБ (более крупные объекты сегментируются) | Не ограничен |
| Установка Multi DC (распределение между дата-центрами) | Да (репликация есть только на уровне контейнера, но предлагается схема полной репликации между дата-центрами) | Нет (требуется асинхронная последующая репликация целостности данных, которую Ceph пока не поддерживает) |
| Интеграция Openstack | Да | Частичный (без поддержки Keystone) |
| Управление репликами | Нет | Да |
| Алгоритм записи | синхронный | синхронный |
| Совместимый с Amazon S3 API | Да | Да |
| Способ размещения данных | Кольца (статическая структура отображения) | CRUSH (алгоритм) |
Источники
Официальная документация Swift – Источник описания структуры данных.Исходный код Swift Ring на Github – База исходного кода для классов Swift Ring и RingBuilder. Блог Шмуэля Буджны – Полезные советы по использованию Swift. Официальная документация Ceph – Основной источник описаний структур данных.
Оригинальная статья по-английски Теги: #Mirantis #Mirantis #openstack #open source #Swift #ceph #crush #rados #open source
-
Leos — Многозадачное Ядро Для Arduino
19 Oct, 24 -
Создание Компании. Миссия, Цели И Принципы
19 Oct, 24 -
Триксель Арт
19 Oct, 24
