Объектное хранение: 10 лет эволюции — от масштабируемости к отказоустойчивости

Введение

В новом выпуске Twitch #VeryTechTalk Реми (Tech Evangelist) пригласил Антонена (Product Manager) и Эдуарда (IT Team Leader), чтобы разобрать решение Object Storage от OVHcloud.

В ходе обсуждения они вернулись к истокам сервиса, объяснили, как он был переработан с учётом совместимости с S3, подробно описали механизмы обеспечения отказоустойчивости и представили новые функции, запланированные на ближайшие месяцы. Эта статья в блоге обобщает ключевые моменты обсуждения, чтобы дать вам представление об этой технологии и, возможно, вдохновить вас попробовать её!

История проекта

В 2014 году OVH предлагала HubiC — потребительское решение на основе файлового хранилища (NAS) с доступом через WebDAV. Модель работала, пока объёмы оставались скромными, но как только начали поступать терабайты, команда поняла, что масштабирование ограничено.

Затем решение переключилось на OpenStack Swift — объектную составляющую проекта OpenStack. Это позволило предоставить клиентам услугу Object Storage и управлять объектами в облачном масштабе.

В 2020 году OVHcloud приобрела OpenIO, стартап, уже бывший экспертом в области S3-совместимого хранения. Это приобретение стало катализатором проекта.

OpenStack Swift был сохранён для старых сценариев использования, и появилось S3-совместимое предложение, отвечающее требованиям рынка (например, инструменты, CI/CD, ИИ). Первый класс S3-совместимого хранилища стал доступен через полтора года после покупки, затем последовали другие классы (infrequent-access, hyper-performance), сформировав мультиклассовый портфель.

«Крайне важно ускорить развитие этого API: инструменты S3 стали стандартом де-факто» – Антонен

Цель состояла в том, чтобы превратить Object Storage в универсальное (многоцелевое) предложение, способное покрывать обычные резервные копии, рабочие нагрузки машинного обучения, юридические архивы...

Сегодня сервис позиционируется как точка опоры для многих внутренних решений: образы инстансов, Logs Data Platform, хранение логов и т.д.

Архитектура и масштабируемость: виртуальная «бесконечность»

Команда управляет сотнями тысяч дисков, распределённых по дата-центрам OVHcloud. Такая плотность позволяет обеспечить почти бесконечную масштабируемость. Одна из сильных сторон и намерение OVHcloud — пользователь никогда не замечает момента добавления или замены диска, никаких перебоев не ощущается.

«Развитие должно быть максимально незаметным. Пользователь никогда не должен видеть „просадок“ во время добавления диска.» – Эдуард

Однако эта почти бесконечность в отношении объёма должна быть контролируемой, усиленной и устойчивой к сбоям отдельных элементов, при этом продолжая предоставлять услугу.

Вместо простого копирования данных сервис разделяет каждый объект на несколько фрагментов и добавляет чанки чётности (Erasure Coding). В случае сбоя на диске, стойке или целом дата-центре (в случае хранилища 3-AZ) оставшиеся фрагменты позволяют восстановить исходный файл без потерь. Это одна из сильных сторон Object Storage.

В рамках сервиса OVHcloud гарантирует долговечность (данные остаются нетронутыми) и доступность (постоянный доступ) данных. Клиенты, в свою очередь, выбирают уровень отказоустойчивости: количество копий, асинхронная репликация, версионирование, object-lock...

Такая детализация позволяет подстроить стоимость под уровень критичности данных.

• Долговечность: данные остаются нетронутыми благодаря Erasure Coding и мультисайтовой репликации.
• Доступность: доступ к объектам гарантирован, даже если одна зона доступности (AZ) выходит из строя.

Производительность и ключевые метрики

В инфраструктуре такого размера существует множество метрик, которые можно анализировать. Однако некоторые привлекают особое внимание операционных команд. Эдуард подробно рассказывает о трёх из них, которые также можно отслеживать, если у вас есть инфраструктура, в которой вы самостоятельно управляете платформой хранения.

Уровень ошибок — первый сигнал тревоги

Уровень ошибок (500/503) — это первый индикатор здоровья сервиса.

Всплеск немедленно запускает встроенные механизмы повторных попыток в SDK, незаметно для пользователя. Эти последовательные попытки выполняются на стороне клиента, чтобы гарантировать, что чтение (или запись) происходит в надлежащих условиях.

Time-to-First-Byte (TTFB): настоящий барометр задержки

TTFB измеряет время, необходимое для доставки первого байта, независимо от размера файла.

Рост TTFB часто сигнализирует о насыщении или инциденте в инфраструктуре. Команда отслеживает этот KPI в реальном времени, чтобы предвидеть аномалии. Это важный внутренний показатель производительности и здоровья платформы.

IOPS против ёмкости диска

В последние годы ёмкость дисков продолжает расти, но IOPS остаются относительно стабильными.

Эта эволюция создаёт снижающийся показатель IOPS/ТБ, что обуславливает необходимость держать эти метрики под наблюдением, чтобы предвидеть возможные заторы.

Конкретные примеры использования

Пример №1: резервное копирование и архивирование

Клиенты могут выполнять резервное копирование непосредственно в bucket, пользоваться версионированием и object-lock, а затем восстанавливать данные в несколько кликов. Ленточное архивирование, предлагаемое с 2025 года, обеспечивает стоимость 1–2 €/ТБ с TTFB порядка часа, что идеально подходит для юридических обязательств по долгосрочному хранению.

• Версионирование: каждое изменение создаёт новую версию, защищая от потери из-за случайного удаления.
• Object Lock (неизменяемость): однократная запись, неограниченное чтение; идеально против программ-вымогателей.

Пример №2: Big Data и ИИ

Массивные объёмы данных, необходимые для обучения моделей машинного обучения, хранятся в «холодном» хранилище Object Storage, а затем перемещаются в вычислительные кластеры, когда они требуются.

Пример №3: внутренние сервисы OVHcloud

Сценарии использования Object Storage становятся всё более распространёнными. Это нормально и необходимо, чтобы продукты OVHcloud также использовали преимущества этой технологии.

Действительно, многие сервисы полагаются на неё: образы инстансов, логи Logs Data Platform, хранение холодных данных и т.д.

План развития и будущие инновации

Object Storage 2.0

Полностью переработанный backend (кодовое имя Object Storage 2.0) находится на стадии закрытого бета-тестирования. Цель — устранить текущие программные ограничения («soft limits»), минимизировать TTFB и обеспечить более высокую производительность для сценариев использования с высокой детализацией (тысячи маленьких файлов).

Прозрачность через публичную дорожную карту

Все обновления публикуются на OVHcloud GitHub. Пользователи могут отслеживать тикеты, оставлять комментарии и записываться на бета-версии через сервер Discord.

Заключение

OVHcloud Object Storage прошёл долгий путь и теперь является мультиклассовой платформой, способной управлять сотнями тысяч дисков, обеспечивая отказоустойчивость корпоративного уровня. Интеграция OpenIO позволила добавить API, совместимый с S3, отвечающий требованиям рынка к интероперабельности. Благодаря Erasure Coding, версионированию, object-lock и опциям репликации каждый клиент может настроить долговечность и доступность своих данных под свою стоимость.

У вас есть проект cloud native или нужна масштабная резервная копия? Испытайте Object Storage от OVHcloud, изучите различные стратегии отказоустойчивости и поделитесь своими отзывами: техническое сообщество растёт благодаря вашему опыту.