13 520
правок
Изменения
Нет описания правки
Общие черты:
* Append-only volume-ы с переупаковкой. То есть, объекты хранятся в дописываемых всегда в конец больших файлах-томах вперемешку с заголовками, при удалении из тома сразу не удаляются, а только помечаются удалёнными - удалёнными — а потом, когда количество удалённого превышает определённый %, приходит отдельный процесс (называемый по вкусу compaction/defrag/gc/repack) и перезаписывает том целиком, на этот раз действительно удаляя удалённые объекты. Волюмы fallocate-ятся, чтобы исключить фрагментацию места в ФС.* Есть «шарды», являющие собой группы из N (2, 3 или ещё скольки-то) таких томов на разных машинах, связанных репликацией вместе. То есть, запись идёт в пары или тройки томов. В терминологии Ceph шард — по сути, PG (placement group). В терминологии zepto - "бакет" zepto — «бакет» (и сам волюм тоже, видимо, называется "бакет"«бакет»).
* Клиент хранит ID шарда (бакета) у себя и для чтения объекта обращается к конкретному шарду. Центральный сервер метаданных, знающий, какой объект где лежит, отсутствует.
* Запись через page cache. fsync-ов после каждой записи и строгой консистентности формально нет. fsync просто раз в секунду выполняется в отдельном потоке, чтобы стимулировать сброс данных на диск. Но так как бешеные уборщицы не ходят по залу и не дёргают в произвольном порядке целые датацентры из розеток - розеток — данные не теряются.
* Есть «прокси», предоставляющие API доступа к хранилищу. У них они называются zeptoproxy и ставятся прямо на клиентские машины.
* Есть отдельный слой управления кластером и он же отвечает за балансировку записи. У mail.ru он называется statusservice.
** А как же удаления, спросите вы, если смещение — это ID? А удаления реализуются через индекс удалений («индекс дырок»), добавляемый при сборке мусора. Видимо, вида «старое смещение → новое смещение». Ну такое… :) если сильно изрубить всё в труху удалениями, всё равно индекс большой получится.
** В zepto объекты нарезаются на странички по 4 КБ и от каждой странички считается контрольная сумма crc32.
** Размер одного бакета — 2 ГБ. Логично, ибо под смещение выделено 32 бита. Плюс ещё 32 бита - бита — ID бакета. Соответственно, общий лимит места в zepto-кластере - кластере — 16 ЭБ, чего хватает с головой :)** Бакеты складываются в 2 ТБ разделы дисков и один раздел (~1000 бакетов) обслуживается 1 процессом "bucketservice"«bucketservice». В ноде 72 диска по 18 ТБ, но под Zepto на них обычно выделено только 4-6 ТБ, так что на одной машине живёт примерно 216 bucketservice-ов.
** Процесс-переупаковщик бакетов называется bucketcompactor.
* Распределение объектов - объектов — перед каждой записью идём в statusservice и спрашиваем у него, в какой бакет писать. При этом бакет на запись блокируется. При удалении аналогично, тоже блокировка.* Консистентность удалений - удалений — если какой-то bucketservice лежит в момент удаления - удаления — другие сохраняют к себе запись типа "foreign delete"«foreign delete», т.е. "данный то есть «данный объект был удалён в другом месте" месте» и после его поднятия досылают ему записи удалений.* Восстановление - Восстановление — тупое, только полным копированием тома на отсутствующие/повреждённые реплики.
<pre>
