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