объектное хранилище s3 что это
Петабайты данных и быстрый поиск: зачем хранить файлы в облачном объектном хранилище
Большая часть современных компаний работает с огромными объемами данных, которые надо, во-первых, где-то хранить, а во-вторых — не потерять среди них что-нибудь важное. Объектные облачные хранилища (object cloud storage) легко справляются с решением этих проблем. Рассказываем, чем они отличаются от других видов хранилищ и какую информацию там лучше всего хранить.
Что такое объектное S3-хранилище
Объектное хранилище, или object storage, подходит для хранения и управления большими объемами информации: аудио и видеофайлы, документы, сообщения чатов, письма. Его используют, когда традиционная система хранения с множеством файлов и папок становится неудобной и неэффективной.
Компании могут развернуть объектное хранилище в собственном центре обработки данных (ЦОД) или воспользоваться услугой облачных провайдеров. Объектные хранилища взаимодействуют с приложениями через программный интерфейс — то есть, через команды, которые хранилище и приложения передают друг другу. Как правило, это интерфейсы S3 API, Swift API или CDMI.
Наличие стандартного интерфейса у хранилища позволяет без проблем его использовать большинству приложений и систем. S3-совместимые хранилища (S3 compatible storage) сейчас используют чаще всего.
В чем плюсы объектного хранения данных
Бывает, что нужно предоставить доступ к объектам хранения одновременно многим пользователям. Например — видеохостинг должен выдерживать тысячи запросов к выложенному видеоролику. Для таких задач не подходят «обычные» хранилища данных, в том числе — жесткие диски и облачные хранилища других типов, например, такие, где пользователи хранят свои фото: они не оптимизированы под параллельный доступ многих пользователей.
Объектные хранилища реализованы таким образом, что число обращений пользователей к объектам практически не замедляет доступ к ним.
При этом доступ к самому облачному объектному хранилищу данных возможен из любой точки мира, а совокупный объем загружаемых файлов может достигать десятков и сотен петабайт. Посмотрим, для чего его можно использовать.
Облачное объектное хранилище S3: что это такое и как подобрать тариф
ИТ-маркетплейс Market.CNews запустил поиск тарифов по облачным объектным хранилищам S3 для компаний. В рамках данной статьи мы расскажем, что такое объектное хранилище, для чего оно используется, кому нужно и как подобрать тариф.
Что такое объектное хранилище
По мере развития любой организации, ее ИТ-специалисты все чаще сталкиваются с вопросом «Как справиться с постоянно возрастающим объемом данных, которые создают и потребляют пользователи компании?». Среди различных стратегий хранения данных объектное хранилище является одним из самых эффективных решений.
Объектной системой хранения данных называется такой тип хранилища, в котором хранятся данные различного формата и объема в виде объектов с метаданными. Каждый такой объект имеет уникальный идентификатор, благодаря которому приложения находят и обращаются к данным, что значительно упрощает работу систем. Отличительной особенностью является то, что данные хранятся в так называемой плоской среде или, другими словами, на одном уровне, т.е. без использования дерева каталогов.
Для чего нужно объектное хранилище
Объектное хранилище обеспечивают высокую скорость работы с большими объемами данных и тысячами объектов. Такой тип хранилища не подразумевает работу пользователей напрямую, доступ к данным организован на уровне приложений с помощью API.
Чаще всего объектное хранилище используется для целей резервного копирования и архивированная критически важных данных. Среди объектов хранения самыми распространенными являются: статический контент (изображения, видео, аудио, файлы JS и CSS), архивы и резервные копии систем, данные корпоративных, мобильных и веб-приложений (изображений, образов, обновлений ПО), электронный документооборот.
Каким компаниям нужно объектное хранилище
Среди самых частых пользователей объектных хранилищ встречаются компании, занимающиеся проектированием и разработкой, игровые порталы, издательства и информационные агентства, организации, предоставляющие медиаконтент для широкой аудитории, маркетплейсы, социальные сети, образовательные учреждения и многие другие, обладающие большими массивами данных.
Преимущества облачных объектных хранилищ
Основными преимуществами в пользу использования объектных хранилищ являются:
Недостатки облачных объектных хранилищ
Среди замечаний, которые называют ИТ-специалисты можно выделить следующие:
Особенности интерфейса
Несмотря на то, что в целом технологии объектного хранилища развиваются уже более 20 лет, до сих пор нет какого-то одного общепринятого стандарта интерфейса. Но за это время довольно прочно закрепилась тройка самых популярных интерфейсов:
Из чего складывается стоимость услуги
Основными параметрами, от которых зависит стоимость услуги являются:
Как выбрать провайдера облачного хранилища
Для выбора провайдера облачного хранилища воспользуйтесь гибким поиском тарифа на ИТ-маркетплейсе Market.CNews. На нем представлено более десятка поставщиков данной услуги.
Чтобы подобрать подходящий тариф, определите необходимый объем хранилища, тип, частоту и количество запросов к нему и трафик. Обычно холодное хранилище стоит дешевле горячего, но запросы к нему стоят дороже, чем запросы к горячему хранилищу. Подсказка о том, холодное это хранилище или горячее, часто содержится в названии тарифа.
Выводы
Объектное хранилище позволяет хранить любые типы данных в исходном виде, обеспечивает быстрое масштабирование и оптимизирует потребление ресурсов системами компании. Такая организация хранения данных делает инфраструктуру организации более отказоустойчивой и эффективной. Объектные хранилища позволяют обеспечить надежное и продолжительное хранение неограниченного количества данных и файлов, предоставляя доступ к ним через интернет из любой точки мира.
Объектное хранилище для извлечения любых объемов данных из любого места
5 ГБ в хранилище S3 Standard
Масштабируйте ресурсы хранилища, чтобы соответствовать меняющимся потребностям с надежностью данных 99,999999999 % (11 9 секунд).
Храните данные в разных классах хранилища Amazon S3, чтобы сократить затраты за счет отсутствия авансовых вложений или периодического обновления оборудования.
Защитите данные благодаря самым широким возможностям по обеспечению безопасности, соблюдению законодательных требований и аудиту.
С легкостью управляйте данными в любом масштабе с помощью надежных средств контроля доступа, гибких инструментов репликации и
видимости целой организации.
Как это работает
Примеры использования
Создание озера данных
Запустите приложения для аналитики больших данных, искусственного интеллекта (ИИ), машинного обучения (ML) и высокопроизводительных вычислений (HPC), чтобы получить полезную информацию.
Резервное копирование и восстановление критически важных данных
Выполняйте нормативы по времени восстановления (RTO), точкам восстановления (RPO) и законодательные требования с помощью надежных возможностей репликации S3.
Архивация данных по наименьшей цене
Переместите локальные архивы в недорогие классы хранения Amazon S3 Glacier и Amazon S3 Glacier Deep Archive, избавившись от операционных сложностей.
Запуск приложений с оптимизацией для облака
Создавайте быстрые, мощные мобильные и оптимизированные для облака интернет-приложения, которые автоматически масштабируются до самой высокой доступной конфигурации.
Как устроено 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 дата-центрах:
Комментарий: еще одно свойство приведенной выше схемы в том, что для нормальной работы политик хранения, затрагивающих оба ЦОДа, объем места, количество нод и дисков на ноде должно совпадать в обоих ЦОДах. Как я уже говорил выше, мультирегиональная схема такого ограничения не имеет.