Что такое object storage
Зачем и как хранить объекты на примере 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. У всех инструментов свои плюсы и минусы.
Желаю вам успехов в создании и масштабировании ваших приложений и надеюсь, что объектные хранилища вам будут в этом помогать!
Делитесь в комментариях о вашем опыте работы с объектными хранилищами и задавайте вопроы!
Принципы организации объектных хранилищ
Наш коллега недавно написал об архитектуре объектного S3-хранилища Mail.ru Cloud Storage. Теперь мы переводим хорошую статью об общих особенностях и ограничениях объектных хранилищ.
Объектные хранилища более масштабируемые, отказоустойчивые и надежные, чем параллельные файловые системы, кроме того, у них ошеломляющая пропускная способность для некоторых рабочих нагрузок. Такие характеристики производительности достигаются за счет отказа от файлов и каталогов.
В отличие от файловых систем, объектные хранилища не поддерживают вызовы ввода-вывода POSIX: открытие, закрытие, чтение, запись и поиск файла. Вместо этого у них только две основные операции: PUT и GET.
Ключевые особенности объектных хранилищ
Поскольку у объектного хранилища всего несколько доступных операций, появляются важные ограничения:
Эта нарочитая простота приводит к ряду ценных последствий в контексте высокопроизводительных вычислений:
Обратите внимание, что во многих реализациях объектных хранилищ к неизменяемости объектов подходят с некоторой гибкостью. Например, режим доступа только с добавлением по-прежнему устраняет узкие места блокировки, улучшая при этом полезность хранилища.
Ограничения объектных хранилищ
Простота организации объектного хранилища делает его масштабируемым, но также ограничивает его функциональность:
Поскольку объектное хранилище не пытается сохранить совместимость с POSIX, реализации шлюзов — удобные места для хранения метаданных объектов, превосходящие те, что традиционно предоставлялись ACL POSIX и NFSv4.
Например, S3 API предоставляет средства для связывания произвольных пар ключ-значение с объектами в качестве определяемых пользователем метаданных. А WOS DDN — запрашивать базу метаданных объектов, чтобы выбрать все объекты, соответствующие критериям запроса.
На базе объектных хранилищ можно построить и гораздо более сложные интерфейсы. Большинство параллельных файловых систем, включая Lustre, Panasas и BeeGFS, построены на концепциях, вытекающих из объектного хранилища. Они идут на компромиссы во внешнем и внутреннем интерфейсе, чтобы сбалансировать масштабируемость с производительностью и удобством использования. Но такая гибкость обеспечивается за счет построения поверх объектно-ориентированных, а не блочных, представлений данных.
Хотя отделение пользовательского интерфейса от базового объектного представления данных обеспечивает гибкость, не все такие шлюзы — шлюзы с двойным доступом. Двойной (или, например, тройной) доступ позволяет получать доступ к одним и тем же данным через несколько интерфейсов. Например, записывать объект с помощью PUT, но читать его обратно, как если бы это был файл. Шлюзы с двойным доступом стараются делать согласованными, однако, возможна ситуация, когда после записи данных они не сразу видны через все интерфейсы.
Реализации объектных хранилищ
Хотя принципы организации объектного хранилища достаточно просты, конкретные продукты отличаются. В частности, для обеспечения устойчивости, масштабируемости и производительности могут использоваться различные способы перемещения данных при получении запроса PUT или GET.
ShellStore: простейший пример
В этом разделе я хочу проиллюстрировать простоту базового хранилища объектов с помощью ShellStore Яна Киркера. Оно представляет собой хотя и безумную, но удивительно лаконичную реализацию объектного хранилища. Прелесть в том, что он демонстрирует основные тонкости работы хранилища с помощью простого bash.
DDN WOS
DDN WOS создавали как высокопроизводительное масштабируемое объектное хранилище, ориентированное на рынок высокопроизводительных систем хранения. Поскольку DDN WOS создавали с нуля, его конструкция проста, разумна и учитывает недостатки дизайна более ранних продуктов.
Простота WOS делает его отличной моделью для иллюстрации того, как в целом работают объектные хранилища. WOS используют очень крупные компании (например, считается, что на нем работает Siri), оно имеет такие примечательные особенности:
Openstack Swift
OpenStack Swift — одна из первых крупных реализаций объектного хранилища корпоративного уровня с открытым исходным кодом. Это то, что сегодня стоит за многими частными облаками. Но поскольку хранилище писали давно, в его архитектуре много неоптимальных решений:
RedHat/Inktank Ceph
Ceph использует детерминированный хэш, называемый CRUSH, который позволяет клиентам напрямую связываться с серверами хранилища объектов. Искать местоположение объекта для каждой операции чтения или записи не нужно.
Общая схема потока данных
Объекты сопоставляются с группами размещения с помощью простой хеш-функции. Группы размещения (PG) — логические абстракции. Через хэш CRUSH они сопоставляются с демонами хранения объектов, которые владеют коллекциями физических дисков.
CRUSH уникален тем, что позволяет добавлять дополнительные OSD без перестройки всей структуры карты объект-PG-OSD. Переназначать на недавно добавленные OSD нужно только часть групп размещения, что обеспечивает гибкую масштабируемость и отказоустойчивость.
Группы размещения содержат собственные политики устойчивости объектов, а алгоритм CRUSH позволяет физически реплицировать объекты и географически распределять их по нескольким OSD.
Ceph реализует политику устойчивости на стороне сервера, так что клиент, выполняющий PUT или GET объекта, общается только с одним OSD. После помещения объекта в OSD этот OSD отвечает за его репликацию в другие OSD, выполнение сегментирования, кодирования стиранием и распределения закодированных сегментов. Хорошее описание (с диаграммами) путей данных репликации и кодирования стиранием Ceph опубликовали в Intel.
Ещё несколько ресурсов с информацией об архитектуре Ceph:
Scality RING
Я почти ничего не знаю о Scality RING. Но эта платформа быстро проникает в сферу High-Performance Computing и используется в Национальной лаборатории Лос-Аламоса, которая ведет разработки в области ядерного вооружения.
Scality RING — исключительно программный продукт (в отличие от DDN WOS), который работает на любом оборудовании. У него есть все стандартные шлюзовые интерфейсы (S3, NFS / CIFS и REST, называемые «коннекторами»), кодирование со стиранием и масштабируемый дизайн. Кажется, он основан на детерминированном хеш-коде, который отображает данные на определенный узел хранения в кластере. Все узлы хранения — одноранговые, и с помощью внутренней одноранговой передачи любой узел может отвечать на запросы данных, хранящихся на любом другом узле.
Некоторые архитектурные детали и ссылки на конкретные патенты — в презентации Scality RING.
Другие продукты
Хочу рассказать еще о нескольких платформах объектного хранения. Правда, они менее актуальны для индустрии высокопроизводительных вычислений из-за их направленности или особенностей проектирования.
NetApp StorageGRID
Платформа хранения объектов StorageGRID от NetApp появилась после покупки компании Bycast. StorageGRID в основном используют в бизнесе, связанном с хранением медицинских записей. NetApp особо не рассказывает о StorageGRID, и, насколько я могу судить, отметить нечего, кроме использования Cassandra в качестве прокси-базы данных для отслеживания индексов объектов.
Cleversafe
Cleversafe — платформа для хранения объектов, ориентированная на корпоративный рынок и обладающая исключительной надежностью. Они продают программный продукт, но по своеобразной модели.
Кластеры Cleversafe нельзя легко масштабировать, поскольку вы должны заранее купить все узлы хранения объектов (sliceStors). Всё, что вы можете — увеличивать емкость каждого узла хранения. Заполните до предела емкость каждого узла — придется покупать новый кластер. Такой подход нормален для организаций, которые масштабируются целыми стойками, но менее практичен за пределами высокопроизводительных центров HPC. Среди известных клиентов Cleversafe — Shutterfly.
Cleversafe не так функциональна, как другие платформы хранения объектов (если судить по последней инструкции, которую я читал). Она предоставляет несколько интерфейсов REST («устройств доступа»), включая S3, Swift и HDFS. Но доступ на основе NFS/CIFS осуществляется сторонними приложениями поверх S3/Swift. Впрочем, крупные компании часто пишут собственное ПО для работы с S3, так что это небольшое препятствие при масштабировании.
Периферийные технологии
Представленные ниже решения хоть и не являются строго платформами объектного хранения, дополняют или отражают дух объектных хранилищ.
iRODS: объектное хранилище без объектов или хранилища
iRODS обеспечивает уровень шлюза объектного хранилища без хранилища объектов под ним. Он способен превратить набор файловых систем во что-то, похожее на хранилище объектов, отказавшись от соответствия POSIX в пользу более гибкого и ориентированного на метаданные интерфейса. Однако iRODS предназначен для управления данными, а не для высокой производительности.
MarFS: POSIX-интерфейс к объектному хранилищу
MarFS — платформа, разработанная в Национальной лаборатории Лос-Аламоса. Предоставляет интерфейс для объектного хранилища, включающий знакомые операции POSIX. В отличие от шлюза, который находится перед хранилищем объектов, MarFS предоставляет интерфейс непосредственно на клиентских узлах и прозрачно транслирует операции POSIX в вызовы API, понятные хранилищу объектов.
Спроектированная как легкая, модульная и масштабируемая, MarFS во многом выполняет те же функции, что, например, клиент llite, сопоставляя вызовы POSIX на клиенте хранилища, с вызовами, понятными базовому представлению данных Lustre.
В текущей реализации, которую используют в LANL, — файловая система GPFS для хранения метаданных, которые обычная файловая система POSIX будет предоставлять своим пользователям. Вместо того чтобы хранить данные в GPFS, все файлы в этой индекс-системе являются заглушками — они не содержат данных, но имеют владельца, разрешения и другие атрибуты POSIX-объектов, которые они представляют.
Сами же данные находятся в хранилище объектов (предоставляемом Scality в реализации LANL), а демон MarFS FUSE на каждом клиенте хранилища использует файловую индекс-систему GPFS для связывания вызовов ввода-вывода POSIX с данными, находящимися в хранилище объектов.
Поскольку он подключает клиентов хранилища напрямую к хранилищу объектов, а не действует как шлюз, MarFS предоставляет только подмножество операций ввода-вывода POSIX. В частности, поскольку базовые данные хранятся как неизменяемые объекты, MarFS не позволяет пользователям перезаписывать данные, которые уже существуют.
Посмотрите презентацию MarFS на MSST 2016, чтобы узнать больше.
Объектные системы хранения – что, зачем и для чего
Если погуглить по ключевым словам «объектные системы хранения» или object storage, то можно найти много текстов, объясняющих, что такое объектное хранилище и как оно работает, как объектные системы опережают в росте объемов другие типы систем хранения: блочные и файловые. Но мало кто говорит, чем такой рост вызван, какие практические преимущества могут дать ИТ-бизнесу объектные системы хранения, для решения каких проблем они создаются.
Чтобы избавить вас от попыток составить единую картину из разрозненных фактов, которые к тому же надо искать преимущественно в англоязычных источниках, мы постараемся дать краткое и, по возможности, полное объяснение, что такое объектные системы хранения, зачем и в каких случаях они нужны.
Зачем?
Не секрет, что рост объемов хранимых данных в последние годы происходит экспоненциально. По результатам опроса, проведенного исследовательской компанией «451 Research» в 2017 году, более 60 % организаций заявили, что объемы их систем хранения превышают 50 Петабайт, и процент их роста выражен двузначной цифрой. Если читатель работает инженером по системам хранения, ему не нужно объяснять, что традиционные системы хранения (блочные и файловые) просто не рассчитаны на такие темпы роста объемов данных, которые нужно надежно хранить и защищать.
Объемы хранимых данных (источник: 451 Research, Western Digital, 2017 г.)
Традиционный подход
Традиционный подход к хранению данных – системы SAN (Storage Area Network) или NAS (Network attached Storage), если не рассматривать совсем простые системы DAS (Direct Attached Storage) – это, например, внешняя дисковая полка, подключенная напрямую к RAID-контроллеру сервера.
Различия SAN и NAS
Такой метод подойдет при относительно небольших объемах хранения. При росте дискового хранилища возникают проблемы с файловой системой. Традиционные файловые системы разбивают каждый файл на маленькие блоки, обычно объемом 4 килобайта, и сохраняют месторасположение каждого блока в таблицах просмотра (lookup table) файловой системы. Для небольших объемов данных это хорошо, но как только вы расширите систему хранения до петабайта и больше, таблицы станут непомерно огромными. Это сильно замедляет поиск нужного блока и увеличивает возможность ошибок.
Поэтому пользователи вынуждены разбивать свои наборы данных на многочисленные логические узлы LUN (Logical Unit Number), чтобы как-то поддержать быстродействие на приемлемом уровне. Однако при этом значительно увеличиваются сложность и затраты на администрирование и поддержку ИТ-системы, а проблемы быстродействия, потери данных и простои системы сказываются на бизнес-процессах.
Распределенная файловая система
Для решения этой проблемы стали использовать так называемые горизонтально-масштабируемые (Scale-out) файловые системы, такие как HDFS (Hadoop Distributed File System). Это распределенная файловая система на базе Hadoop, свободно распространяемого набора утилит для создания распределенных систем, работающих на кластерах из сотен и тысяч узлов. Проблема масштабирования при этом решается, однако поддержка таких систем также довольно трудоемка. Они конструктивно сложны и требуют постоянного обслуживания. К тому же в них чаще всего используется механизм репликации данных, то есть попросту хранения копий одних и тех же данных в разных местах системы. Стандартно сохраняются три копии каждого файла. Излишне говорить, что это увеличивает требуемый дисковый объем на целых 200 %! Хотя цены на диски все время снижаются, но объемы данных, которые необходимо хранить, растут еще быстрее. Это напрочь съедает экономию на недорогих дисках. Для петабайтов информации такой подход неприемлем.
Облачное хранение
Для минимизации этих проблем многие стали прибегать к использованию облачных хранилищ. Модель оплаты по мере потребления (pay-as-you-go) работает отлично, но опять-таки – для относительно небольших объемов данных и при нечастом их использовании. При постоянном масштабировании объемов данных, интенсивной работе с ними этот подход также становится весьма затратным, не дешевле HDFS. Дело в том, что многие облачные провайдеры берут плату не только за объем хранимых данных, но и за трафик извлекаемых/записываемых данных, а также и за число транзакций (обращений) к хранилищу. Поэтому, когда приходится иметь дело с анализом больших данных, передачей массивных объемов данных, то хранилище в публичном облаке – наверное, самый дорогой подход. Кроме того, могут возникнуть проблемы конфиденциальности данных и производительности системы, если много других пользователей также будут интенсивно использовать ресурсы данного облака.
Что делать?
Выходом в такой ситуации может быть объектная система хранения (object storage), в которой используются примерно те же технологии, что в публичном облаке (HTTP, API). Объектные хранилища можно легко масштабировать до объемов петабайта в одном домене, без какой-либо деградации производительности. Кроме того, объектные хранилища имеют функционал управления данными, чего нет в традиционных системах: управлении версиями, кастомизации метаданных и встроенной аналитике.
Такие характеристики достигаются за счет абстрагирования уровней системы – общий подход, который сейчас используется практически во всех ИТ- и телеком-системах, не только в системах хранения. Каждый диск на нижележащем уровне форматируется простой локальной файловой системой, такой как EXT4. На верхнем уровне, абстрагированном от нижнего, размещаются средства управления, что позволяет интегрировать все элементы в едином унифицированном томе. Файлы различного вида хранятся как «объекты», а не как файлы в файловой системе. Поскольку низкоуровневое управление блоками передано локальной файловой системе, объектное хранилище ведает только функциями управления высокого уровня, которые управляют нижележащим уровнем через стандартный интерфейс прикладного программирования API (Application Programing Interface).
Объектная система хранения
Принцип объектного хранения можно сравнить с услугой парковки, когда вы просто оставляете машину (объект) для ее размещения на парковочном пространстве и получаете карточку, по которой вы можете получить машину обратно. В карточку могут быть внесены «метаданные»: ваше имя, номер и марка машины. Где именно запаркуют машину, вам неинтересно (абстрагирование), и вам не нужно кружить по парковке в поисках свободного места.
Такой подход позволяет сохранять таблицы просмотра файловой системы каждого узла нижележащего уровня в пределах легко управляемого размера. Это позволяет масштабировать систему до сотен петабайт без заметного снижения производительности.
Структурированные и неструктурированные данные
Понятие «структурированные» и «неструктурированные» данные – весьма относительно. Все файлы с данными имеют ту или иную структуру, тип файла. Поэтому, с этой точки зрения, все файлы – структурированные. Когда говорят, что данные – неструктурированные, имеется в виду, что они не хранятся в единой базе и содержат разные типы данных. Это просто набор разнородных файлов, созданных в различных приложениях и полученных из разных источников. Если открыть на компьютере папку «Мои документы», то примерно это там и будет.
Объектное хранилище предназначено в основном для работы с неструктурированными данными. Объекты неструктурированных данных можно пометить метаданными, которые описывают их содержимое и помогают быстро извлечь из хранилища нужный объект. В этом случае сами метаданные будут структурированы, т. е. будут иметь стандартную форму, определенную в API. Это позволяет отслеживать и индексировать объекты, без необходимости применять внешние программы или базы данных. Использование метаданных открывает новые возможности для аналитики. Файлы (объекты) можно индексировать и искать в объектном хранилище, не зная структуру их содержимого или того, в какой программе они были созданы.
Защита данных
Нужна ли репликация данных для надежного хранения в объектной системе? Да, нужна, но при этом не требуется утраивать объем дискового пространства, как в блочной системе. Для максимизации доступного дискового пространства и защиты данных используется технология Erasure Coding (ЕС). Упрощенно ее можно назвать следующим поколением хорошо известного метода защиты данных RAID, при котором необходимо двойное или тройное резервирование.
В методе ЕС файлы объектов разделяются на фрагменты (shards). Для некоторых из них создаются копии избыточности в формате N+M. Например, если для шести из десяти фрагментов создаются копии, это будет формат 10+6. Данные, для которых нужно, например, N дисков, копии избыточности распределяются по N+M дискам (в данном случае 16). При потере любых шести дисков, оставшихся десяти достаточно для восстановления исходных данных. Таким образом, избыточность объема хранения получается не такой большой, как в RAID, и она может противостоять множественным отказам дисков без риска потери данных. Тома ЕС могут выдерживать больше отказов дисков, чем дисковые массивы RAID. При этом петабайтное масштабирование системы не будет приводить к столь большим затратам на закупку дисков, как в файловых системах.
Для чего?
Объектное хранилище часто выбирается для данных WORM, которые пишутся один раз, но читаются много раз (Write Once Read Many). Оно подходит не для всех объемов данных и сценариев использования, но, безусловно, имеет много применений.
Объектные системы хранения целесообразно использовать в следующих случаях:
Таким образом, мы видим, что объектные системы хранения хорошо подходят для хранения массивных разнородных (неструктурированных) данных и отвечают запросам бурного роста объемов данных, которые нужно хранить, обрабатывать и анализировать в различных отраслях. Именно поэтому объемы объектных систем хранения растут значительно быстрее объемов файловых систем.
В следующей статье мы представим обзор рынка объектных СХД на примере популярных систем объектного хранения: