Команда объектного S3-хранилища Mail.ru Cloud Storage перевела статью о том, какие критерии важны при выборе объектного хранилища. Далее текст от лица автора.
Когда заходит речь об объектном хранилище, как правило, люди думают только об одной характеристике цене за ТБ/ГБ. Конечно, эта метрика важна, но она делает подход однобоким и приравнивает объектное хранилище к инструменту для хранения архивов. Плюс такой подход уменьшает важность объектного хранилища для технологического стека предприятия.
Выбирая объектное хранилище, стоит обращать внимание на пять характеристик:
- производительность;
- масштабируемость;
- совместимость с S3;
- реакция на сбои;
- целостность.
Эти пять характеристик новые метрики объектного хранилища, наравне со стоимостью. Рассмотрим их все.
Производительность
Традиционные объектные хранилища не отличаются производительностью. Поставщики услуг постоянно жертвовали ей в погоне за низкими ценами. Однако с современными объектными хранилищами всё иначе.
Скорость различных хранилищ приближается к Hadoop или даже превосходит ее. Современные требования к скорости чтения и записи: от 10 ГБ/с для жестких дисков, до 35 ГБ/с для NVMe.
Такой пропускной способности достаточно для Spark, Presto, Tensorflow, Teradata, Vertica, Splunk и других современных вычислительных фреймворков в стеке аналитики. Тот факт, что MPP-базы данных настраивают на объектные хранилища, говорит о том, что оно всё чаще используется как основное хранилище.
Если ваша система хранения не обеспечивает нужную скорость, вы не можете использовать данные и извлекать из них значения. Даже если вы извлекаете данные из объектного хранилища в структуру обработки в памяти, всё равно потребуется пропускная способность для передачи данных в память и из нее. У устаревших объектных хранилищ ее недостаточно.
Это ключевой момент: новый показатель производительности пропускная способность, а не задержка. Она требуется для масштабируемых данных, и это норма в современной инфраструктуре данных.
И хотя тесты производительности хороший способ определения производительности, ее невозможно точно измерить до запуска приложения в среде. Только после него можно сказать, где именно узкое место: в программном обеспечении, дисках, сети или на уровне вычислений.
Масштабируемость
Под масштабируемостью понимают количество петабайт, которые помещаются в одно пространство имен. Поставщики заявляют о легкой масштабируемости, но умалчивают о том, что по мере масштабирования массивные монолитные системы становятся хрупкими, сложными, нестабильными и дорогими.
Новый показатель масштабируемости количество пространств имен или клиентов, которых вы можете обслуживать. Метрику берут непосредственно из гиперскейлеров, где строительные блоки хранилища небольшие, но масштабируются до миллиардов единиц. В общем, это облачная метрика.
Когда у стандартных блоков небольшие размеры, их легче оптимизировать, то есть обеспечить безопасность, контроль доступа, управление политиками, жизненным циклом и обновлениями без прерывания работы. И в итоге обеспечить производительность. Размер строительного блока функция управляемости области отказа, именно так строятся высокоустойчивые системы.
У мультиклиентности множество характеристик. Хотя параметр говорит о том, как организации предоставляют доступ к данным и приложениям, он также относится и к самим приложениям, и к логике их изоляции друг от друга.
Характеристики современного подхода к мультиклиентности:
- За короткое время количество клиентов может вырасти с нескольких сотен до нескольких миллионов.
- Клиенты полностью изолированы друг от друга. Это позволяет им запускать разные версии одного и того же ПО и хранить объекты с различными конфигурациями, разрешениями, функциями, уровнями безопасности и обслуживания. Это необходимо, когда масштабируются новые серверы, обновления и географические регионы.
- Хранилище эластично масштабируется, ресурсы предоставляются по запросу.
- Каждая операция управляется API и автоматизируется без участия человека.
- ПО можно разместить в контейнерах и использовать стандартные системы оркестрации, например Kubernetes.
Совместимость с S3
Amazon S3 API фактически стандарт для объектных хранилищ. Каждый поставщик ПО для объектного хранилища заявляет о совместимости с ним. Совместимость с S3 двоичная: либо она реализована в полном объеме, либо ее нет.
На практике возможны сотни и тысячи пограничных сценариев, когда при использовании объектного хранилища что-то идет не так. Особенно у поставщиков проприетарного ПО и услуг. Его основные сценарии использования прямое архивирование или резервное копирование, поэтому причин для вызова API немного, варианты использования однородны.
Значительные преимущества у ПО с открытым исходным кодом. Оно покрывает большинство пограничных сценариев, учитывая размер и разнообразие приложений, операционных систем и аппаратной архитектуры.
Всё это важно для разработчиков приложений, поэтому стоит тестировать работу приложения с поставщиками хранилищ. Открытый исходный код упрощает процесс легче понять, какая платформа подходит для вашего приложения. Поставщик может использоваться как единая точка входа в хранилища значит, он удовлетворит ваши потребности.
Открытый исходный код означает: приложения не привязаны к поставщику и более прозрачны. Это обеспечивает долгий жизненный цикл приложения.
И еще несколько замечаний насчет открытого исходного кода и S3.
Если вы запускаете приложение для работы с большими данными, S3 SELECT на порядок повышает производительность и эффективность. Это происходит за счет использования SQL для извлечения из хранилища только тех объектов, которые вам необходимы.
Ключевой момент поддержка уведомлений бакетов. Бакетные уведомления упрощают бессерверные вычисления важный компонент любой микросервисной архитектуры, которая предоставляется как услуга. Учитывая, что объектное хранилище фактически облачное хранилище, эта возможность становится решающей, когда объектное хранилище используют облачные приложения.
Наконец, реализация S3 должна поддерживать Amazon S3 API-интерфейсы шифрования на стороне сервера: SSE-C, SSE-S3, SSE-KMS. Еще лучше, если S3 поддерживает защиту от несанкционированного доступа, которая действительно безопасна.
Реакция на сбои
Показатель, который, вероятно, часто упускают из виду, то, как система обрабатывает сбои. Неудачи случаются по разным причинам, и объектное хранилище должно обрабатывать их все.
Например, есть единственная точка отказа, метрика этого равна нулю.
К сожалению, многие системы хранения объектов используют специальные узлы, которые должны быть активированы для правильной работы кластера. К ним относят узлы имен или серверы метаданных это создает единую точку отказа.
Даже там, где предусмотрено несколько точек отказа, первостепенное значение имеет способность выдерживать катастрофические отказы. Диски выходят из строя, серверы выходят из строя. Ключевой момент создание программного обеспечения, предназначенного для обработки сбоев как нормального состояния. При выходе из строя диска или узла такое ПО продолжит работать без изменений.
Встроенная защита от стирания и деградации данных гарантирует: вы можете потерять столько дисков или узлов, сколько у вас есть блоков четности обычно это половина дисков. И только тогда ПО не сможет возвращать данные.
Отказ редко проверяется под нагрузкой, но такая проверка обязательна. Моделирование сбоя под нагрузкой покажет совокупные затраты, понесенные после сбоя.
Консистентность
Показатель консистентности в 100% также называют строгой консистентностью. Консистентность ключевой компонент любой системы хранения, но строгая консистентность встречается довольно редко. Например, Amazon S3 ListObject не является строго консистентным, он консистентен только в конце.
Что подразумевается под строгой консистентностью? Для всех операций после подтвержденной операции PUT должно выполняться следующее:
- Обновленное значение видно при чтении с любого узла.
- Обновление защищено резервированием от сбоя узла.
Это означает: если выдернуть штекер в середине записи, то ничего не потеряется. Система никогда не возвращает поврежденные или устаревшие данные. Это высокая планка, которая имеет значение для многих сценариев: от транзакционных приложений до резервного копирования и восстановления.
Заключение
Это новые метрики объектного хранилища, которые отражают модели использования в современных организациях, где производительность, консистентность, масштабируемость, домены отказа и совместимость с S3 строительные блоки для облачных приложений и аналитики больших данных. Рекомендую использовать этот список в дополнение к цене при создании современных стеков данных.
Об объектном хранилище Mail.ru Cloud Solutions: Архитектура S3. 3 года эволюции Mail.ru Cloud Storage.
Что еще почитать:
- Пример event-driven приложения на основе вебхуков в объектном S3-хранилище Mail.ru Cloud Solutions.
- Больше чем Ceph: блочное хранилище облака MCS
- Работа с объектным S3-хранилищем Mail.ru Cloud Solutions как с файловой системой.
- Наш канал в Телеграме с новостями об обновлениях S3-хранилища и других продуктов.
