Всем привет! Меня зовут Никита, я старший разработчик в команде Storage. Мы делаем собственное S3-совместимое хранилище в Ozon, которое уже хранит 130 PB данных. Какое-то время назад мы очень подробно рассказали почему нам перестали подходить коробочные решения, по каким критериям мы выбирали технологии для собственной реализации и с деталями описали основную схему получившегося хранилища.

Хранилище постоянно растёт, и вместе с ним появляются задачи, которых раньше просто не существовало в таком масштабе. Одна из них звучит довольно просто: как перенести огромный бакет из одной части S3 в другую, продолжая принимать запросы на чтение и запись и не заставляя пользователей вообще думать о том, что где-то идёт миграция.

Слона будем есть по частям. Чтобы понять, зачем нам понадобилось перемещать данные, сначала коротко разберём архитектуру.

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

Внутри коварный cephadm shell, контрольные суммы XXH3, решардинг как способ лечения и три правила, которые стоило знать заранее.