Ozon мигрирует петабайты внутри S3 без простоя

Ozon построил собственный механизм перемещения бакетов между зонами S3-хранилища объёмом 130 ПБ. Система переносит данные, не прерывая чтение и запись, и не требует действий от пользователей. Решение появилось из-за неравномерной загрузки зон и ограничений Ceph-кластеров. Для компаний, которые рассматривают похожие миграции, важно понять масштаб задачи: S3 здесь выступает как объектное хранилище, где данные хранятся в виде объектов с ключами, а Ceph обеспечивает базовую отказоустойчивость и распределение. Без простоя перенос критичных бакетов позволяет сохранить работу сервисов, зависящих от постоянного доступа к данным, но требует оценки затрат на доработку фронтального слоя и метаданных.

Почему зоны загружаются неравномерно

S3 Ozon состоит из десятков независимых зон. Каждая зона — это отдельный Ceph-кластер для объектов, своя база метаданных и сервис S3-протокола. Единый s3front распределяет запросы по зонам, поэтому клиенты не знают, где физически лежит бакет. Такая схема позволяет добавлять ёмкость простым вводом новых зон. Ceph-кластеры в зонах изолированы, что упрощает масштабирование, но создаёт жёсткие границы: данные не могут свободно перетекать между зонами без специальных механизмов.

Однако независимость зон приводит к перекосу. В одной зоне может быть занято 70 % дисков и высокая нагрузка на метаданные, в другой — 30 %. Ceph не рекомендуется растить сверх нескольких петабайт из-за усложнения эксплуатации доменов отказа. Домены отказа здесь — это логические группы серверов, чей одновременный выход из строя не должен приводить к потере данных. Поэтому единственный способ выровнять утилизацию — переносить уже записанные данные между зонами. При принятии решения о миграции стоит оценить, насколько неравномерность уже влияет на latency и стоимость дисков: если диски в перегруженных зонах простаивают реже, а метаданные замедляют запросы, то перенос оправдан даже при высоких разовых затратах на разработку.

Два подхода к переносу данных

Можно мигрировать объекты через обычный S3-протокол: GetObject из исходной зоны и PutObject в целевую. Такой способ не требует знания внутренней реализации, но создаёт двойную нагрузку на сеть и Ceph. Альтернатива — использовать внутренние интерфейсы Ceph и базы метаданных, зная схему размещения. Ozon выбрал второй путь, потому что объёмы миграции измеряются десятками петабайт. Для команд, которые решают, стоит ли повторять подход, важно учитывать: внешний способ проще внедрить на старте и не требует прав на кластер, но при петабайтных объёмах он приводит к избыточному трафику и удвоению расходов на сеть. Внутренний способ снижает нагрузку, однако привязывает решение к конкретной версии Ceph и схеме метаданных, что усложняет обновления и поддержку.

При этом нужно сохранить возможность записи в мигрируемый бакет. Любая блокировка бакета на время переноса неприемлема. Поэтому разработали отдельный сервис s3-migrator, который перехватывает запросы и координирует перемещение объектов. Перед внедрением стоит посчитать, как часто потребуется мигрировать бакеты: если неравномерность возникает раз в год и объёмы не превышают нескольких петабайт, то готовые инструменты ребалансировки Ceph могут оказаться достаточными без создания отдельного сервиса.

Как работает маршрутизация во время миграции

s3-migrator V1 отслеживал статус каждого объекта и при получении запроса проверял, перенесён ли он уже. Если объект ещё в исходной зоне, запрос шёл туда; после переноса — в новую. Это требовало постоянных обращений к базе и создавало заметную задержку при большом количестве мелких объектов. V2 изменил подход: во время миграции бакет переводится в специальный режим, при котором s3front сразу направляет все запросы в обе зоны. Запись всегда идёт в целевую зону, чтение — сначала в исходную, потом в новую. Статус переноса хранится не по каждому объекту, а по диапазонам ключей, что снизило нагрузку на метаданные. Для тех, кто оценивает применимость решения, важно понимать влияние на consistency: параллельные записи во время переноса диапазона требуют точного учёта, чтобы избежать потери или дублирования данных. Если приложение уже полагается на строгую consistency S3, то переход на диапазоны может потребовать дополнительных проверок в клиентском коде.

Что важно учесть при внедрении в свой контур

Решение Ozon рассчитано на десятки зон и Ceph-кластеры по несколько петабайт. В меньших установках накладные расходы на s3-migrator могут превысить выгоду от выравнивания. Перед внедрением нужно оценить, насколько часто будет возникать потребность в миграции и хватает ли уже имеющихся инструментов ребалансировки Ceph. Если в инфраструктуре уже используется похожая схема с фронтальным роутером и изолированными зонами, то подход с диапазонами ключей можно взять за основу. Главное ограничение — необходимость доработки s3front и точного учёта consistency при параллельных записях во время переноса диапазона. Командам стоит также взвесить риски: добавление нового сервиса увеличивает поверхность отказов, а зависимость от внутренней схемы Ceph усложняет будущие обновления хранилища. Если текущая утилизация зон остаётся в пределах 50-60 % и нет планов на рост до десятков петабайт, то проще ограничиться планированием размещения новых бакетов.

Источник

Это краткий разбор материала Ozon. Полная версия с примерами кода, схемами и деталями реализации — в оригинале: Ozon мигрирует петабайты внутри S3 без простоя.

Курс по теме — Каталог курсов Школы Больших Данных