что такое объектное хранилище
Зачем и как хранить объекты на примере MinIO
Наша биг дата проанализировала Telegram-чаты, форумы и разговоры в кулуарах IT-мероприятий и пометила объектные хранилища как инструмент, который ещё не все осмеливаются использовать в своих проектах. Хочу поделиться с вами своим опытом в формате статьи-воркшопа. Если вы пока не знакомы с этой технологией и паттернами её применения, надеюсь, эта статья поможет вам начать использовать её в своих проектах.
Зачем вообще говорить о хранении объектов?
С недавних пор я работаю Golang-разработчиком в Ozon. У нас в компании есть крутая команда админов и релиз-инженеров, которая построила инфраструктуру и CI вокруг неё. Благодаря этому я даже не задумываюсь о том, какие инструменты использовать для хранения файлов и как это всё поддерживать.
Но до прихода в Ozon я сталкивался с довольно интересными кейсами, когда хранение разных данных (документов, изображений) было организовано не самым изящным образом. Мне попадались SFTP, Google Drive и даже монтирование PVC в контейнер!
Использование всех этих решений сопряжено с проблемами, в основном связанными с масштабированием. Это и привело меня к знакомству с объектными хранилищами, ведь с их помощью можно красиво и удобно решать целый ряд задач.
Объектное хранилище – это дополнительный слой абстракции над файловой системой и хостом, который позволяет работать с файлами (получать доступ, хранить) через API.
Объектное хранилище может помочь вам в кейсах, когда необходимо хранить файлы пользователей в ваших приложениях, складывать статику и предоставлять доступ к ней через Ingress или хранить кеши вашего CI.
Все материалы к статье (исходники, конфиги, скрипты) лежат вот в этой репе.
Что такое объектное хранилище
Хранить данные нашего приложения можно различными способами, от хранения данных просто на диске до блоба в нашей БД (если она это поддерживает, конечно). Но будет такое решение оптимальным? Часто есть нефункциональные требования, которые нам хотелось бы реализовать: масштабируемость, простота поддержки, гибкость. Тут уже хранением файлов в БД или на диске не обойтись. В этих случаях, например, масштабирование программных систем, в которых хранение данных построено на работе с файловой системой хоста, оказывается довольно проблематичной историей.
И на помощь приходят те самые объектные хранилища, о которых сегодня и пойдёт речь. Объектное хранилище – это способ хранить данные и гибко получать к ним доступ как к объектам (файлам). В данном контексте объект – это файл и набор метаданных о нём.
Основное преимущество хранения данных в объектах – это возможность абстрагирования системы от технических деталей. Нас уже не интересует, какая файловая (или тем более операционная) система хранит наши данные. Мы не привязываемся к данным какими-то конкретными способами их представления, которые нам обеспечивает платформа.
В этой статье мы не будем сравнивать типы объектных хранилищ, а обратим наше внимание на класс S3-совместимых стораджей, на примере MinIO. Выбор обусловлен тем, что MinIO имеет низкий порог входа (привет, Ceph), а ещё оно Kubernetes Native, что бы это ни значило.
На мой взгляд, MinIO – это самый доступный способ начать использовать технологию объектного хранения данных прямо сейчас: его просто развернуть, легко управлять и его невозможно забыть. На протяжении долгого времени MinIO может удовлетворять таким требованиям, как доступность, масштабируемость и гибкость.
Вообще S3-совместимых решений на рынке много. Всегда есть, из чего выбрать, будь то облачные сервисы или self-hosted-решения. В общем случае мы всегда можем перенести наше приложение с одной платформы на другую (да, у некоторых провайдеров есть определённого рода vendor lock-in, но это уже детали конкретных реализаций).
Disclaimer: под S3 я буду иметь в виду технологию (S3-совместимые объектные хранилища), а не конкретный коммерческий продукт. Цель статьи – показать на примерах, как можно использовать такие решения в своих приложениях.
Кейс 1: прокат самокатов
В рамках формата статьи-воркшопа знакомиться с S3 в общем и с MinIO в частности мы будем на практике.
На практике часто возникает вопрос хранения и доступа к контенту, который генерируется или обрабатывается вашим приложением. Правильно выбранный подход может обеспечить спокойный сон и отсутствие головной боли, когда придёт время переносить или масштабировать наше приложение.
Давайте перейдём к кейсу. Представим, что мы пишем сервис для проката самокатов и у нас есть user story, когда клиент фотографирует самокат до и после аренды. Хранить медиаматериалы мы будем в объектном хранилище.
Для начала развернём наше хранилище.
Самый быстрый способ развернуть MinIO – это наш любимчик Docker, само собой.
С недавнего времени Docker – не такая уж и бесплатная штука, поэтому в репе на всякий случай есть альтернативные манифесты для Podman.
Запускать «голый» контейнер из терминала – нынче моветон, поэтому начнём сразу с манифеста для docker-compose.
Теперь мы можем управлять нашим хранилищем с помощью web-ui. Но это не самый удобный способ для автоматизации процессов (например, для создания пайплайнов в CI/CD), поэтому сверху ещё поставим CLI-утилиту:
$ go get github.com/minio/mc
И да, не забываем про export PATH=$PATH:$(go env GOPATH)/bin.
Cоздадим алиас в mc (залогинимся):
$ mc alias set minio http://localhost:9000 ozontech minio123
Теперь создадим bucket – раздел, в котором мы будем хранить данные нашего пользователя (не стоит ассоциировать его с папкой). Это скорее раздел, внутри которого мы будем хранить данные.
Назовем наш бакет “usersPhotos”:
$ mc mb minio/usersPhot
$ mc ls minio > [0B] usersPhotos
Теперь можно приступать к реализации на бэке. Писать будем на Golang. MinIO любезно нам предоставляет пакетик для работы со своим API.
Disclaimer: код ниже – лишь пример работы с объектным хранилищем; не стоит его рассматривать как набор best practices для использования в боевых проектах.
Начнём с подключения к хранилищу:
Теперь опишем ручку добавления медиа:
Нам надо как-то разделять фото до и после, поэтому мы добавим записи в базу данных:
Ну и сам метод обновления записи в БД:
Также мы могли бы напрямую через сервис вытаскивать и отдавать фото по запросу. Выглядело бы это примерно так:
Ну и само получение файла из хранилища:
Но мы можем и просто проксировать запрос напрямую в MinIO, так как у нас нет причин этого не делать (на практике такими причинами могут быть требования безопасности или препроцессинг файлов перед передачей пользователю). Делать это можно, обернув всё в nginx:
Получать ссылки на изображения мы будем через ручку rent_info:
И сам метод обогащения:
Упакуем всё в docker-compose.yaml:
Протестируем работу нашего приложения:
Изображение полученное при переходе по URL от ответа сервиса
Кейс 2: хранение и раздача фронта
Ещё одна довольно популярная задача, для решения которой можно использовать объектные хранилища, – хранение и раздача фронта. Объектные хранилища пригодятся нам тут, когда захотим повысить доступность нашего фронта или удобнее им управлять. Это актуально, например, если у нас несколько проектов и мы хотим упростить себе жизнь.
Небольшая предыстория. Однажды я встретил довольно интересную практику в компании, где в месяц релизили по несколько лендингов. В основном они были написаны на Vue.js, изредка прикручивался API на пару простеньких ручек. Но моё внимание больше привлекло то, как это всё деплоилось: там царствовали контейнеры с nginx, внутри которых лежала статика, а над всем этим стоял хостовый nginx, который выполнял роль маршрутизатора запросов. Как тебе такой cloud-native-подход, Илон? В качестве борьбы с этим монстром мной было предложено обмазаться кубами, статику держать внутри MinIO, создавая для каждого лендинга свой бакет, а с помощью Ingress уже всё это проксировать наружу. Но, как говорится, давайте не будем говорить о плохом, а лучше сделаем!
Представим, что перед нами стоит похожая задача и у нас уже есть Kubernetes. Давайте туда раскатаем MinIO Operator. Стоп, почему нельзя просто запустить MinIO в поде и пробросить туда порты? А потому, что MinIO-Operator любезно сделает это за нас, а заодно построит High Availability-хранилище. Для этого нам всего лишь надо три столовые ложки соды. воспользоваться официальной документацией.
Для простоты установки мы вооружимся смузи Krew, который всё сделает за нас:
$ kubectl krew update
$ kubectl krew install minio
$ kubectl minio init
После прокидывания портов до нашего оператора мы получим в вывод терминала JWT-токен, с которым и залогинимся в нашей панели управления:
Интерфейс управления тенантами
Далее нажимаем на кнопку «Добавить тенант» и задаём ему имя и неймспейс:
Интерфейс настройки тенанта
После нажатия на кнопку «Создать» мы получим креденшиалы, которые стоит записать в какой-нибудь Vault:
Теперь для доступа к панели нашего кластера хранилищ, поднимем прокси к сервису minio-svc и его панели управления:
Вот так у нас будет выглядеть джоба для CI/CD на примере GitLab CI (целиком конфиг лежит в репе):
Для того чтобы отдавать статику, добавим Ingress-манифест:
А если вдруг потребуется доступ из других неймспейсов, то мы можем создать ресурс ExternalName:
Вместо вывода
Объектные хранилища – это класс инструментов, которые позволяют наделить систему высокодоступным хранилищем данных. Во времена cloud-native это незаменимый помощник в решении многих задач. Да, на практике могут случаться кейсы, в которых использование объектного хранения данных будет избыточным, но вряд ли это можно считать поводом совсем игнорировать этот инструментарий в других своих проектах.
Отдельно я бы посоветовал обратить внимание на S3-совместимые решения, если вы занимаетесь машинным обучением или BigData и у вас есть потребность в хранении большого количества медиаданных для их последующей обработки.
Рассмотренное в статье MinIO – это не единственный достойный инструмент, который позволяет работать с данной технологией. Существуют решения на основе Ceph и Riak CS и даже S3 от Amazon. У всех инструментов свои плюсы и минусы.
Желаю вам успехов в создании и масштабировании ваших приложений и надеюсь, что объектные хранилища вам будут в этом помогать!
Делитесь в комментариях о вашем опыте работы с объектными хранилищами и задавайте вопроы!
Object Storage — Ближайшее будущее систем хранения данных
Девять лет назад «Международный день телекоммуникаций» был переименован в «Международный день телекоммуникаций и информационного общества». Для золотого миллиарда будущее уже наступило: интернет стал одной из важнейших частей нашей жизни. Ежесекундно по всему миру создаются и потребляются колоссальные объёмы информации, а рынок всевозможных онлайн-сервисов является одним из самых быстрорастущих.
Одной из главных тенденций последнего времени стало развитие облачных технологий. Они используются повсеместно, от файлообменников и видеохостингов до мобильных приложений, сервисов заказа услуг и внутренних корпоративных систем. Подавляющее большинство подобных проектов оперируют неструктурированной информацией, причём ёмкость файловых хранилищ ежегодно увеличивается примерно на 53%. И с ростом объёмов генерируемой и хранимой информации трансформируются и требования к системам хранения данных.
По прогнозу компании Cisco, в 2016 году объём мирового интернет-трафика достигнет 1,1 зеттабайта (в среднем 91,3 экзабайта в месяц). И к 2018 году половина мирового интернет-трафика придётся на сети доставки контента. Мобильный сегмент также переживает этап бурного развития. По данным той же Cisco, в 2014 году мобильный трафик вырос на 69%, достигнув 2,5 экзабайт. И уже в 2012 году половину мобильного трафика составляло видео.
С ростом объёмов хранимой и передаваемой информации на первый план, помимо надёжности, выходят простота архитектуры, лёгкость масштабирования и высокая производительность. Однако сложность архитектур (блокировки, репликация, высокая доступность) и доступа в распределённых сетях, большое разнообразие оборудования и технологий, предназначенных для хранения разных типов данных, снижают эффективность традиционных файловых СХД и делают их слишком дорогими в обслуживании и масштабировании.
Например, при хранении текстовой и визуальной информации (графика, видео) обычно используют две базы данных: отдельно для текста и для контента. Но при размере в сотни терабайт производительность и отказоустойчивых контентных БД существенно снижается.
В результате всё большую популярность обретают объектные СХД, лишённые недостатков файловых хранилищ, обеспечивающие высокую производительность и отказоустойчивость при работе с большим объёмом неструктурированных данных. Одним из подобных решений является EMC Elastic Cloud Storage (ECS).
Архитектура Elastic Cloud Storage
EMC ECS — это программно-определяемое хранилище, которое может поставляться как в виде программного решения, так и программно-аппаратной системы.
В основе системы лежит программный модуль хранения неструктурированных данных. Он может устанавливаться на любое стандартное оборудование. На данный момент модуль хранения обеспечивает управление объектными данными и HDFS.
Важными особенностями ECS является неограниченная масштабируемость системы с помощью простого добавления новых узлов. А за счёт исключения единой точки отказа обеспечивается высокая доступность.
В ECS обеспечивается одновременный доступ к данным через различные интерфейсы, а также совместимость с такими API, как Amazon S3, OpenStack Swift, EMC Atmos и Centera CAS. Кроме того, поддерживаются и расширения API: Byte-Range updates, Atomic appends, Rich ACLs и т.д.
Модуль хранения данных может вести журналирование, делать снэпшоты и отслеживать версионность. Все данные хранятся в логических контейнерах — чанках (chunk). Размер каждого чанка составляет 128 Мб. При этом все операции защиты данных осуществляются с чанками, а не с самими объектами.
Информация о хранящихся объектах — их имена и адреса чанков — хранится в индексе. При этом каждый объект получает уникальное имя, а само пространство имён является единым для всех узлов системы, где бы они ни находились. Индекс также хранится в чанках, а его актуальные копии доступны на каждом узле системы.
Алгоритмы записи, чтения и обновления данных
Давайте рассмотрим подробнее, как в ECS осуществляется запись, чтение и обновление данных.
Здесь всё просто: после получения запроса на чтение, модуль хранения получает из индекса информацию о расположении объекта, считывает его и отправляет пользователю.
Поскольку в ECS данные не перезаписываются и не изменяются, то обновление уже имеющихся объектов осуществляется в диапазоне байтов. После этого модуль хранения обновляет информацию об объекте в индексе, а старая версия помечается для последующего фонового удаления.
Процесс Erasure code
Этот процесс применяется только к полностью заполненным чанкам. Он осуществляет кодирование данных для защиты от потерь и снижения избыточности. Не кодируется только индекс, поскольку система постоянно обращается к нему. Поэтому защита индекса осуществляется с помощью трёхкратной репликации в разные чанкы и кэширования в памяти.
В основе Erasure process лежит алгоритм Рида-Соломона. Чанк разбивается на 16 модулей, — 12 модулей данных и 4 модуля кода, — которые записываются на разные узлы. При этом чем больше количество узлов, те выше отказоустойчивость. Обратите внимание, что блоки записываются в одном экземпляре.
Процедура декодирования используется только для восстановления после сбоев, для операций чтения этого не требуется. Более того, для чтения небольших объектов системе даже не нужно обращаться ко всем содержащим его чанкам. Всё это положительно сказывается на общей производительности системы.
Защита данных и доступ с нескольких площадок
В ECS применена распределённая защита данных, состоящая из двух компонентов: модуля защиты и механизма управления избыточностью. Для защиты от сбоя на площадке используется резервное копирование каждого чанка:
Механизм управления избыточностью работает в фоновом режиме. Для уменьшения количества копий между площадками применяется сжатие данных с помощью операции XOR.
После создания набора данных Е, исходные наборы A и D удаляются. В случае возникновения сбоя на одной из площадок, извлекается тот набор данных, что стал недоступен. Для этого второй из исходных наборов снова пересылается на площадку, где хранится сжатый набор. Восстановленный из копии набор копируется на другую площадку.
В отличие от традиционных систем, в которых данные реплицируются на несколько площадок, в ECS избыточность снижается по мере увеличения количества площадок.
В результате всех применяемых мер, данные сохраняются даже при выходе из строя одной площадки целиком. А в системе из 8 и более площадок возможен безболезненный выход из строя двух узлов на каждой площадке. Также каждая площадка позволяет осуществить локальный ребилд, что позволяет снизить нагрузку на сеть и увеличить производительность в случае сбоя.
Механизм распределённой защиты, помимо своей основной функции, в сочетании с глобальным пространством имён позволяет записывать и читать данные с любой из площадок, вне зависимости от их реального расположения. При этом в ECS обеспечивается строгая консистентность данных между всеми площадками.
ECS Appliance
Зачастую многие компании создают объектные хранилища своими силами, на базе типового оборудования и Open Source-продуктов. Причина очевидна — экономия. Однако максимальная дешевизна может обернуться низкой надёжностью. Кроме того, поддержка работоспособности как оборудования, так и Open Source-решений целиком и полностью ложится на самих пользователей.
Как уже упоминалось, ECS может поставляться в виде программно-аппаратного комплекса ECS Appliance. Он полностью изготовлен из типовых элементов: 4 server nodes in 2U и 3,5-дюймовых SATA-дисков. Притом доступно 2 конфигурации.
U-Series – диски с данными находятся в подключенных дисковых полках.
Доступны пять конфигураций, различающиеся количеством серверов и дисков.
C-Series – диски с данными находятся в самих серверах. Расширение производится однотипными 2U модулями.
При данном типе поставки осуществляется поддержка как программного обеспечения, так и оборудования. Масштабирование СХД возможно, как путём простого добавления новых стоек ECS Appliance, так и стороннего оборудования. Однако в последнем случае развёртывание и настройку ECS делает сам пользователь.
Что такое объектное хранилище?
Упорядочение неструктурированных данных в плоской среде
Объектное хранилище — это способ хранения данных без иерархии, который обычно используется в облачной среде. В отличие от остальных способов хранения данных, объектное хранилище не использует дерево каталогов. Отдельные единицы данных (объекты) сосуществуют в пуле данных на одном уровне. Каждый объект имеет уникальный идентификатор, используемый приложением для обращения к нему. Кроме того, каждый объект может содержать метаданные, получаемые вместе с ним.
Почему именно объектное хранилище
Масштабируемость
Объектное хранилище может содержать практически любое количество данных без необходимости в разбиении набора данных на разделы.
Эффективность
Отсутствие иерархии означает отсутствие узких мест, возникающих вследствие использования сложных систем каталогов.
Доступность
Объектные системы хранения имеют механизмы для сохранения целостности данных, обеспечивают репликацию данных, последовательные обновления и отсутствие простоев.
Замечания по объектным хранилищам
Ограниченные возможности
API объектов для доступа к данным часто очень простые. Приложения должны отвечать большему числу требований к управлению данными.
Совместимость
Инструменты файловой системы, такие как утилиты на основе POSIX, не имеют возможности взаимодействовать с объектными системами хранения без дополнительных промежуточных уровней.
Типы данных
Объектное хранилище идеально для неструктурированных данных, таких как медиаданные и веб-материалы. Оно не подходит для данных, которые регулярно изменяются.
Поддержка API
Для того чтобы воспользоваться преимуществами объектного хранилища, требуется доработка приложений. Многие вендоры выпускают версии со встроенной поддержкой объектных хранилищ.
Откройте для себя гибридное облачное объектное хранилище, которое отличается гибкостью, соответствующей сегодняшним требованиям к данным.
Взгляд IBM. Свежий подход к объектному хранилищу
По мере того как сотрудники создают все больше материалов, ИТ-отделы предприятий отмечают экспоненциальный рост требований к хранилищам данных. Создание мультимедийных ресурсов — ключевой фактор.
Спрос на объектные системы хранения будет расти из-за необходимости архивировать больше неструктурированных данных. Этот рост будет стимулировать развертывание новых, экономически эффективных решений распределенных систем хранения, которые могут масштабироваться до сотен петабайтов.
Требования рынка
Десять лет назад мы ожидали, что объем данных в мире превысит уровень петабайта для большинства организаций, а для некоторых из них достигнет даже эксабайта. Сегодня мы живем в мире, где облачные технологии привели к наступлению эпохи революционного новаторства, а Интернет вещей (IoT) позволил миллионам устройств создавать, собирать и отправлять данные каждую секунду. Этот прогноз стал реальностью.
Для управления беспрецедентным объемом создаваемых данных предприятиям необходимо определить, каким образом можно эффективно защищать, хранить, анализировать и максимально повышать ценность своих неструктурированных данных. Предназначение объектного хранилища — делать это в масштабе Интернета.
Интернет спроектирован таким образом, чтобы технология распространения информации была полностью децентрализованной. Каждый объект в системе объектного хранилища уникален. Объекты идентифицируются по ИД, который однозначно определяет способ поиска объектов.
В данной системе хранения существует несколько физических узлов, работающих независимо друг от друга. В любой момент в систему можно добавить дополнительные узлы. Эта структура позволяет предприятиям масштабировать вместимость и производительность независимо друг от друга.
В этом процессе данные, записываемые в систему объектного хранилища приложением, передаются через уровень доступа, на котором они шифруются, разделяются на части и распределяются.
Уникальный ИД объекта используется для получения объекта через уровень доступа путем нахождения порогового номера хранимых частей и воссоздания объекта.
Технология хранения
Благодаря ссылкам на объекты по ИД, а не по именам файлов, систему можно масштабировать. Этот подход не имеет ограничений по размеру, а получать данные проще, поскольку в объект можно добавить большое количество метаданных.
Система объектного хранилища гарантирует, что ИТ могут пользоваться текущими инвестициями. Кроме того, она позволяет организации не упустить будущие возможности независимо от того, хранятся ли данные локально, в облаке или и там и там.
Обзор рынка
По мере того как организации пересматривают свои стратегии хранения данных, чтобы справиться с ростом скорости создания и потребления данных, объектное хранилище предоставляет предприятиям защищенное, адаптивное и экономное решение для управления данными.
Чем больше пул данных, тем выше стоимость долговременного владения. Информация доступна постоянно, а упрощенная платформа управления ускоряет обслуживание и дополнительные операции.
Облачные технологии, IoT и мобильные устройства являются движущей силой наполненного данными мира, и многие организации поймут, что инвестиции в завтрашний день начинаются сегодня. Объектное хранилище позволяет организациям, которым требуется работать с данными в масштабах Интернета, реализовать масштабируемое дальновидное решение для хранения данных, которое даст предприятиям возможность развиваться в течение следующих 20 лет и более.