Всем привет! На связи Виктор Стародуб — технический лидер команды S3, один из авторов и создателей объектного СХД в Cloud.ru. Недавно вышла статья, в которой мой коллега Сергей Лысанов @LysanovSergey рассказал, как мы сделали собственный Software-Defined Storage для дисков виртуальных машин в публичном облаке Cloud.ru Evolution. А в этой статье я расскажу о том, как мы написали свое объектное хранение, имея отказоустойчивое блочное хранилище в качестве базового слоя, с какими сложностями столкнулись, как их решили и какие сделали выводы.
Что такое объектное хранение
Не существует строгого определения объектного хранения. Под объектным хранилищем обычно подразумевается сервис, который обладает типичным набором характеристик:
1. Immutable-данные — объект можно перезаписать только целиком, поменять пару байт в середине объекта нельзя.
2. Key-value — данные доступны только по пользовательскому ключу без каких-либо дополнительных индексов.
3. Универсальность — данные не имеют никакой семантики с точки зрения хранилища. Это не ограничивает сферу применимости, но часто требует дополнительной application-логики.
4. Отказоустойчивость — есть конкретный уровень (или уровни) отказоустойчивости.
5. AWS S3 — де-факто стандарт. Есть базовый набор операций: put, get, list, delete. Есть типичная схема организации хранилища в бакеты и определенные подходы к аутентификации и авторизации.
Зачем мы создали свое объектное хранилище
Зачем мы решили написать свое объектное хранилище? Во-первых, пользователи нашей платформы Cloud.ru Evolution хотят напрямую использовать такое хранилище для своих данных. Во-вторых, данные нужно хранить самим сервисам платформы — как пользовательские, так и дополнительные, которые нужны для их работы.
Конечно, для этого есть уже готовые решения, но с ними не все так гладко, как может показаться. Зачастую они плохо масштабируются, когда речь идет о размере даже до десятков, не говоря уже о сотнях петабайт. Возможно, вы и сами слышали истории про то, как разваливаются кластеры CEPH, про разные сложности с его настройкой и поддержанием работоспособности. В случае с коммерческими решениями от различных вендоров многое тоже не идеально — мы уже сталкивались с проблемами совместимости, масштабирования и утилизации оборудования.
Кажется, что можно просто доработать какое-то из имеющихся open source решений. Но с большой вероятностью это выльется в необходимость поддерживать свой форк, который в том числе включает и ненужный функционал. И наверняка тот, кто пытался коммитить в какие-то большие open source проекты, знает, что зачастую maintainer-ов нужно долго уговаривать, чтобы они приняли большие изменения.
Писать систему хранения совсем с нуля — сложная и долгая задача. Однако низкоуровневая часть такого хранения у нас уже была написана. Была готова наша собственная SDS и мы не могли этим не воспользоваться
Интересные статьи
Интересные статьи
