S3 совместимое хранилище что это
Что такое хранилище S3?
С увеличением объема данных растет потребность в использовании надежных хранилищ, которые обеспечивали бы гарантированную безопасность и доступность информации.
Локальные диски, съемные носители, ленточные накопители не всегда удовлетворяют требованиям бизнеса. Ведь с такими скоростями и ритмом жизни нужно быть максимально гибкими и мобильными.
Компании по всему миру давно практикуют облачный подход к хранению данных. Но в последнее время популярность набирает объектная модель, представленная в виде S3 хранилища.
Просто о сложном
S3 хранилище – это сервис хранения объектов, предлагаемый поставщиками облачных услуг. Основное преимущество решения – возможность хранить файлы любого типа, любого объема, с высоким уровнем надежности и доступности.
Принцип работы с S3 хранилищем сводится к созданию контейнеров и добавлению туда необходимых файлов, которые представляются в виде объектов. Таким образом все, что попадает в контейнер, можно просматривать, перемещать или удалять. Сами контейнеры, в случае необходимости, тоже могут быть удалены.
Важный момент: в object-хранилищах помимо самих объектов хранятся метаданные, определяющие свойства объекта и глобальный уникальный идентификатор в виде присвоенного адреса. Эти атрибуты хранятся в плоском адресном пространстве, позволяя избавиться от проблем, которые встречаются при работе с иерархической файловой системой на основе сложных путей к файлам. Примечательно, что один объект может содержать разнородные метаданные, которые наиболее подробным образом его характеризуют. Например, это может быть аудиофайл с заданными метаданными в виде исполнителя, названии песни,альбома и прочей информации. В дальнейшем метаданные файлов индексируются, что в значительной степени облегчает и в разы ускоряет поиск нужных объектов по заданным признакам.
Зачем использовать объектное хранилище
Теперь, когда вы знаете как устроено объектное хранилище, может возникнуть вопрос: зачем его использовать? Основная задача, которую решает объектная СХД связана с масштабированием и более рациональным хранением информации.
Нетрудно заметить, что природа данных в последние годы сильно изменилась. Если раньше можно было хранить файлы на традиционных хранилищах, то теперь мы имеем дело с постоянным ростом информации и этим процессом довольно сложно управлять. С такой задачей справляется облачное хранилище, подстраиваясь под любые темпы роста. Неудивительно, что сегодня многие БД работают с объектами, поддерживая тип данных BLOB (Binary Large Object). Таким образом хранение информации в виде объектов происходит более рационально.
Как подключиться к S3 хранилищу
Стоит отметить, что объектные хранилища не предназначены для обработки данных внутри себя, поскольку здесь может быть выполнена операция размещения либо получения объектов. Важно понимать, что с такими хранилищами взаимодействуют не сами пользователи, а приложения или отдельные системы, а основой API выступает протокол HTTP.
Для того, чтобы выполнить подключение к S3 хранилищу, можно воспользоваться несколькими способами. Какой из них окажется удобным, решать вам. Приведем пример наиболее часто используемых вариантов:
S3Browser
Программа S3Browser позволяет подключиться к хранилищу по протоколу S3, скачать ее можно с официального сайта компании. Процедура стандартная: необходимо задать имя аккаунту, выбрать тип подключения S3 Compatible Storage, указать адрес подключения, ID ключа доступа, значение секретного ключа и активировать в случае необходимости опцию шифрования данных при подключении. Все. После чего можно работать с хранилищем.
Swift API
Подключиться к S3 хранилищу можно с помощью Swift API через программу Cyberduck, скачав ее предварительно с официального сайта разработчика. После установки и запуска приложения, необходимо выполнить новое подключение. Для этого нужно указать, что вы подключаетесь к объектному хранилищу Swift (OpenStack Object Storage), задать название сервера, номер порта 443, ключ доступа и пароль.
Эластичное избыточное S3-совместимое хранилище за 15 минут
S3 сегодня не удивишь наверное никого. Его используют и как бэкенд хранилище под веб сервисы, и как хранилище файлов в медиа индустрии, так и как архив для бэкапов.
Рассмотрим небольшой пример развертывания S3-совместимого хранилища на основе объектного хранилища Ceph
Краткая справка
Ceph — это open source разработка эластичного легко масштабируемого петабайтного хранилища. В основе лежит объединение дисковых пространств нескольких десятков серверов в объектное хранилище, что позволяет реализовать гибкую многократную псевдослучайную избыточность данных. Разработчики Ceph дополняют такое объектное хранилище еще тремя проектами:
Описание примера
Приступим
Шаг 0. Подготовка Ceph
Так как я продолжаю использовать уже развернутый кластер Ceph, мне необходимо только немного поправить конфигурацию /etc/ceph/ceph.conf — дописать определение для RADOS Gateway
и обновить ее на других нодах
Шаг 1. Инсталлируем Apache2, FastCGI и RADOS Gateway
Шаг 2. Конфигурация Apache
Включаем необходимы модули
Создаем VirtualHost для RADOS Gateway /etc/apache2/sites-available/rgw.conf
Включаем созданный VirtualHost и выключаем дефолтный
Создаем FastCGI скрипт /var/www/s3gw.fcgi :
и делаем его исполняемым
Шаг 3. Подготавливаем RADOS Gateway
Создаем необходимую директорию
Генерируем ключ для нового сервиса RADOS Gateway
и добавляем его в кластер
Шаг 4. Запуск
Рестартуем Apache2 и RADOS Gateway
Шаг 5. Создаем первого пользователя
Что бы использовать S3 клиент нам необходимо получить ключи access_key и secret_key для нового пользователя
смотрите вывод команды и скопируйте ключи в ваш клиент
Шаг 6. DNS
Для того что бы заработали buckets нам необходимо что бы DNS сервер при запросе любого субдомена для s3.ceph.labspace.studiogrizzly.com указывал на IP адрес хоста где запущен RADOS Gateway.
Например, при создании bucket с названием mybackups — домен mybackups.s3.ceph.labspace.studiogrizzly.com. должен указывать на IP адрес node01, что есть — 192.168.2.31.
В моем случае я просто добавлю CNAME запись
Послесловие
За 15 минут мы успели развернуть S3-совместимое хранилище. Теперь попробуйте подключить ваш любимый S3 клиент.
Бонусная часть
Я попросил sn00p рассказать о его опыте использовании RADOS Gateway в продакшн в компании 2GIS. Ниже его отзыв:
Общее описание
У нас стоит варниш, варнишу бекендами подцеплены 4 апача радосгейтвеев. Приложение сначала лезет в варниш, если там облом, то раундробином ломится напрямую в апачи. Эта штука жмет 20000 рпс без проблем по синтетическим тестам jmeter c access логом за месяц. Внутри полмиллиона фоточек, рабочая нагрузка на фронтенд около 300 рпс.
Ceph пока что на 5 машинах, там отдельный диск под osd и для журнала отдельный ssd. Репликация дефолтная, ^2. Система без проблем переживает падение двух нод одновременно и там дальше с вариациями. За полгода ни одной ошибки еще клиенту не показали.
Нет проблем с гибкостью — размер хранилища, иноды, раскладка по каталогам — это все в прошлом осталось.
Особенности решения
Планы на будущее
4-200кб. С S3 это весьма не удобно — там нет операций bulk-copy, нельзя удалить bucket с данными, чтобы первоначально хранилище наполнить — это медленно ппц. Исследуем как это подкрутить.
Но главная задача — геокластер, мы сами в Сибири и хотим отдавать данные из географически близкой точки клиенту. До Москвы у нас контент летит с задержкой уже — до 100мс плюсом, это не годится. Ну у разработчиков Ceph вроде все в планах такое.
Как устроено S3 хранилище DataLine
Не секрет, что в работе современных приложений задействованы огромные объемы данных, и их поток постоянно растет. Эти данные нужно хранить и обрабатывать, зачастую с большого числа машин, и это непростая задача. Для ее решения существуют облачные объектные хранилища. Обычно они представляют из себя реализацию технологии Software Defined Storage.
В начале 2018 года мы запускали (и запустили!) собственное 100% S3-совместимое хранилище на основе Cloudian HyperStore. Как оказалось, в сети очень мало русскоязычных публикаций о самом Cloudian, и еще меньше — о реальном применении этого решения.
Сегодня я, основываясь на опыте DataLine, расскажу вам об архитектуре и внутреннем устройстве ПО Cloudian, в том числе, и о реализации SDS от Cloudian, базирующейся на ряде архитектурных решений Apache Cassandra. Отдельно рассмотрим самое интересное в любом SDS хранилище — логику обеспечения отказоустойчивости и распределения объектов.
Если вы строите свое S3 хранилище или заняты в его обслуживании, эта статья придется вам очень кстати.
В первую очередь, я объясню, почему наш выбор пал на Cloudian. Всё просто: достойных вариантов в этой нише крайне мало. Например, пару лет назад, когда мы только задумывали строительство, опций было всего три:
И да, самое (безусловно!) главное — у DataLine и Cloudian похожие корпоративные цвета. Согласитесь, перед такой красотой мы не могли устоять.
К сожалению, Cloudian — не самое распространенное ПО, и в рунете информации о нём практически нет. Сегодня мы исправим эту несправедливость и поговорим с вами об особенностях архитектуры HyperStore, изучим его наиболее важные компоненты и разберемся с основными архитектурными нюансами. Начнем с самого основного, а именно — что же находится у Cloudian под капотом?
Как устроено хранилище Cloudian HyperStore
Давайте взглянем на схему и посмотрим, как устроено решение от Cloudian.
Основная компонентная схема хранилища.
Как мы видим, система состоит из нескольких основных компонентов:
Под common services в схеме выше имеются в виду сервисы S3, HyperStore, CMC и Apache Cassandra. На первый взгляд, все красиво и аккуратно. Но при более детальном рассмотрении выясняется, что эффективно отрабатывается только одиночный отказ ноды. А одновременная потеря сразу двух нод может стать фатальной для доступности кластера — у Redis QoS (на node 2) есть только 1 slave (на node 3). Такая же картина с риском потери управления кластером — Puppet Server есть только на двух нодах (1 и 2). Впрочем, вероятность отказа сразу двух узлов очень невысока, и с этим вполне можно жить.
Тем не менее, для повышения надежности хранилища мы в DataLine используем 4 ноды вместо минимальных трёх. Получается следующее распределение ресурсов:
Сразу бросается в глаза еще один нюанс — Redis Credentials ставится не на каждую ноду (как можно было предположить из официальной схемы выше), а только на 3 из них. При этом Redis Credentials используется при каждом входящем запросе. Получается, из-за необходимости ходить в чужой Redis есть некоторый перекос в производительности четвертой ноды.
Для нас это пока несущественно. При нагрузочном тестировании значительных отклонений в скорости отклика ноды замечено не было, но на больших кластерах в десятки рабочих нод есть смысл поправить этот нюанс.
Вот так выглядит схема миграции на 6 нодах:
Из схемы видно, как реализована миграция сервиса при отказе ноды. Учитывается только случай отказа одного сервера каждой роли. Если упадут оба сервера, потребуется ручное вмешательство.
Здесь дело тоже не обошлось без некоторых тонкостей. Для миграции ролей используется Puppet. Поэтому, если вы потеряете его или случайно сломаете, automatic failover может не сработать. По этой же причине не стоит вручную править манифесты встроенного Puppet. Это не совсем безопасно, изменения могут быть внезапно перетерты, так как манифесты редактируются с помощью админки кластера.
С точки зрения сохранности данных всё значительно интереснее. Метаданные объектов хранятся в Apache Cassandra, и каждая запись реплицирована на 3 ноды из 4-х. Для хранения данных также используется фактор репликации 3, но можно настроить и больший. Это гарантирует сохранность данных даже при одномоментном отказе 2-х нод из 4-х. А при наличии времени на перебалансировку кластера можно и с одной оставшейся нодой ничего не потерять. Главное, чтобы хватило места.
Вот что происходит при отказе двух нод. На схеме хорошо видно, что даже в этой ситуации данные остаются сохранными
При этом доступность данных и хранилища будет зависеть от стратегии обеспечения консистентности. Для данных, метаданных, чтения и записи она настраивается отдельно.
Допустимые варианты — хотя бы одна нода, кворум или все ноды.
Эта настройка определяет, сколько нод должны подтвердить запись/чтение, чтобы запрос считался успешным. Мы используем кворум как разумный компромисс между временем на обработку запроса и надежностью записи/противоречивостью чтения. То есть из трех нод, задействованных в операции, для безошибочной работы достаточно получить непротиворечивый ответ от 2-х. Соответственно, чтобы остаться на плаву при отказе более чем одной ноды, понадобится перейти в стратегию единичной записи/чтения.
Отработка запросов в Cloudian
Ниже мы рассмотрим две схемы отработки входящих запросов в Cloudian HyperStore, PUT и GET. Это основная задача для S3 Service и HyperStore.
Начнем с того, как обрабатывается запрос на запись:
Наверняка вы отметили, что каждый запрос генерирует очень много проверок и извлечений данных, минимум 6 обращений от компонента к компоненту. Именно отсюда появляются задержки записи и высокий расход времени CPU при работе с маленькими файлами.
Крупные файлы передаются чанками. Отдельные чанки не рассматриваются как отдельные запросы и часть проверок не проводится.
Нода, получившая исходный запрос, дальше самостоятельно определяет, куда и что писать, даже если непосредственно на нее запись не производится. Это позволяет скрыть от конечного клиента внутреннюю организацию кластера и использовать внешние балансировщики нагрузки. Всё это положительно сказывается на удобстве обслуживания и отказоустойчивости хранилища.
Как видите, логика чтения не слишком отличается от записи. В ней наблюдается такая же высокая чувствительность производительности к размеру обрабатываемых объектов. Следовательно, из-за существенной экономии на работе с метаданными извлекать один мелко нарезанный объект значительно проще, чем множество отдельных объектов того же общего объема.
Хранение и дублирование данных
Как видно из приведенных выше схем, Cloudian поддерживает различные схемы хранения и дублирования данных:
Репликация — с помощью репликации возможно поддерживать в системе настраиваемое количество копий каждого объекта данных и хранить каждую копию на разных узлах. Например, с помощью 3X репликации создается 3 копии каждого объекта, и каждая копия «лежит» на своей ноде.
Erasure Coding — с помощью erasure coding каждый объект кодируется в настраиваемое количество (известное как число K) фрагментов данных плюс настраиваемое количество кода избыточности (число M). Каждые K + M фрагменты объекта уникальны, и каждый фрагмент хранится на своем узле. Декодирован объект может быть с помощью любых K фрагментов. Другими словами, объект остается читаемым, даже если M узлов недоступны.
Например, в erasure coding по формуле 4+2 (4 фрагмента данных плюс 2 фрагмента кода избыточности) каждый объект расщепляется на 6 уникальных фрагментов, хранящихся на шести различных узлах, и этот объект может быть восстановлен и прочтен, если любые 4 из 6 фрагментов доступны.
Плюс Erasure Coding по сравнению с репликацией состоит в экономии места, пусть и ценой значительного роста нагрузки на процессор, ухудшения скорости отклика и необходимости работы фоновых процедур по контролю консистентности объектов. В любом случае, метаданные хранятся отдельно от данных (в Apache Cassandra), что повышает гибкость и надежность работы решения.
Кратко о прочих функциях HyperStore
Как я уже писал в начале статьи, в HyperStore встроено несколько полезных инструментов. Среди них:
Логика работы Cloudian HyperStore
Теперь мы погрузимся еще глубже и посмотрим на самое интересное в любом SDS хранилище — логику распределения объектов по нодам. В случае с хранилищем Cloudian, метаданные хранятся отдельно от самих данных. Для метаданных используется Cassandra, для данных — проприетарное решение HyperStore.
К сожалению, пока что в интернете отсутствует официальный перевод документации Cloudian на русский язык, поэтому ниже я помещу свой перевод наиболее интересных частей этой документации.
Роль Apache Cassandra в HyperStore
В HyperStore Cassandra используется для хранения метаданных объекта, данных учетной записи пользователя и данных об использовании сервиса. При типичном развертывании на каждом узле HyperStore данные Cassandra хранятся на том же диске, что и ОС. Система также поддерживает данные Cassandra на выделенном диске на каждом узле. Данные Cassandra не хранятся на дисках данных HyperStore. Когда vNodes назначаются хост-машине, они распределяются только по узлам хранения данных HyperStore. vNodes не выделяются на диск, где хранятся данные Cassandra.
Внутри кластера метаданные в Cassandra реплицируются в соответствии с политикой (стратегией) вашего хранилища. Репликация данных Cassandra использует vNodes таким образом:
Как работает хранилище HyperStore
В «классическом» хранилище, основанном на консистентном хэшировании, один токен присваивается одному физическому узлу. Система Cloudian HyperStore использует и расширяет функциональность «виртуального узла» (vNode), введенную в Cassandra в версии 1.2, — каждому физическому хосту присваивается большое количество токенов (максимум 256). По сути, кластер хранилища состоит из очень большого количества «виртуальных узлов» с большим количеством виртуальных узлов (токенов) на каждом физическом хосте.
Система HyperStore назначает отдельный набор токенов (виртуальных узлов) каждому диску на каждом физическом хосте. Каждый диск на хосте отвечает за свой набор реплик объектов. Сбой на диске затрагивает только те реплики объектов, которые находятся на нем. Другие диски на хосте продолжат работать и выполнять свои обязанности по хранению данных.
Приведем пример и рассмотрим кластер из 6 хостов HyperStore, на каждом из которых находится по 4 диска S3-хранилища. Предположим, что каждому физическому хосту назначено 32 токена и существует упрощенное пространство токенов от 0 до 960, а значения 192 токенов в этой системе (6 хостов по 32 токена) — это 0, 5, 10, 15, 20 и так далее до 955.
На приведенной ниже схеме приводится одно возможное распределение токенов по всему кластеру. 32 токена каждого хоста распределены равномерно по 4 дискам (8 токенов на диск), а сами токены случайным образом распределены по кластеру.
Теперь предположим, что вы настроили HyperStore на 3X репликацию объектов S3. Условимся, что объект S3 загружается в систему, и алгоритм хеширования, примененный к его имени, дает нам хеш-значение 322 (в этом упрощенном хэш-пространстве). На приведенной ниже схеме показано, как три экземпляра или реплики объекта будут храниться в кластере:
Добавлю комментарий: с практической точки зрения эта оптимизация (распределение токенов не только по физическим нодам, но и по отдельным дискам) нужна не только для обеспечения доступности, но и для равномерности распределения данных между дисками. При этом RAID-массив не используется, всей логикой размещения данных на дисках управляет сам HyperStore. С одной стороны, это удобно и контролируемо, при потере диска всё самостоятельно перебалансируется. С другой стороны, лично я хорошим RAID-контроллерам доверяю больше — всё-таки их логика работы оптимизируется уже много лет. Но это всё лично мои предпочтения, на реальных косяках и проблемах мы HyperStore ни разу не ловили, если соблюдать рекомендации вендора при установке ПО на физические сервера. А вот попытка использовать виртуализацию и виртуальные диски поверх одного и того же луна на СХД окончилась неудачей, при перегрузке СХД во время нагрузочного тестирования HyperStore сходил с ума и раскидывал данные совершенно неравномерно, забивая одни диски и не трогая другие.
Устройство диска внутри кластера
Напомним, что у каждого хоста по 32 токена, а токены каждого хоста равномерно распределены между его дисками. Давайте детально рассмотрим hyperstore2:Disk2 (на схеме ниже). Мы видим, что этому диску присвоены токены 325, 425, 370 и так далее.
Так как кластер сконфигурирован для 3X-репликации, на hyperstore2:Disk2 будет храниться следующее:
Как было замечено ранее, при размещении вторых и третьих реплик HyperStore может в некоторых случаях пропускать токены, чтобы не хранить больше одной копии объекта на одном физическом узле. Это исключает использование hyperstore2:disk2 как хранилища для вторых или третьих реплик одного и того же объекта.
При сбое Диска 2 на Дисках 1, 3 и 4 продолжат храниться данные, и объекты на Диске 2 сохранятся в кластере, т.к. были реплицированы на другие хосты.
Комментарий: в итоге, распределение реплик и/или фрагментов объектов в кластере HyperStore строится на доработанном под нужды файлового хранилища дизайне Cassandra. Чтобы понять, куда поместить объект физически, берется некий хэш от его имени и, в зависимости от его значения, выбираются пронумерованные «токены» для размещения. Токены заранее случайно распределены по кластеру с целью балансировки нагрузки. При выборе номера токена для размещения учитываются ограничения на размещение реплик и частей объекта на одни и те же физические ноды. К сожалению, у такого дизайна возникает побочный эффект: если нужно добавить или убрать ноду в кластере, придется заново перетасовывать данные, а это достаточно ресурсоемкий процесс.
Единое хранилище в нескольких ЦОД
Теперь давайте посмотрим, как у HyperStore работает геораспределенность в нескольких ЦОДах и регионах. В нашем случае мультиЦОД-режим от мультирегионального отличается использованием одного или нескольких пространств токенов. В первом случае пространство токенов едино. Во втором каждый регион будет иметь независимое пространство токенов с (потенциально) своими собственными настройками уровня консистентности, емкости и конфигурациями хранилища.
Чтобы понять, как это работает, снова обратимся к переводу документации, раздел «Multi-Data Center Deployments».
Рассмотрим развертывание HyperStore в двух дата-центрах. Назовем их DC1 и DC2. В каждом дата-центре расположено по 3 физических узла. Как и в наших предыдущих примерах, каждый физический узел имеет четыре диска, каждому хосту назначаются 32 токена (vNodes), и мы предполагаем упрощенное пространство токенов от 0 до 960. Согласно такому сценарию с несколькими дата-центрами, пространство токенов делится на 192 токена — по 32 токена на каждый из 6 физических хостов. По хостам токены распределены абсолютно случайно.
Также предположим, что репликация объектов S3 в данном случае настроена на двух репликах в каждом дата-центре.
Давайте рассмотри, как гипотетический объект S3 со значением хэша 942 будет реплицироваться в 2 дата-центрах:
Комментарий: еще одно свойство приведенной выше схемы в том, что для нормальной работы политик хранения, затрагивающих оба ЦОДа, объем места, количество нод и дисков на ноде должно совпадать в обоих ЦОДах. Как я уже говорил выше, мультирегиональная схема такого ограничения не имеет.