Vitastor

• vitastor.io
• Распределённая ПСХД (SDS)
• Исходные цели:
  🚀 Низкая задержка (~0.1 мс)
  🚀 Низкое потребление CPU
• Блочная + ФС и S3
• «Умная», не сетевой RAID

Что появилось за 3 года

• Стабильность, CI
• Сайт и документация
• Куча новых фич
• Удобство

А что не изменилось?

Блочный слой хранения по американским чертежам

Старый слой хранения кратко

Контракт хранилища

• ID: inode:offset, 128 КБ объекты
• Частичное чтение/запись
• Номер версии++ при каждой записи...
• Атомарная запись!
  (сеть менее стабильна, чем диск)
• 2-фазная запись для EC (write → commit)
  (против "raid write hole")

Плюсы схемы

• Нет оверхеда файловой системы
  Нет оверхеда Copy on Write
  ⇒ Низкое потребление CPU
• Мало меты — 36 байт на объект (~290 МБ на 1 ТБ)
• Низкая задержка ≈ задержке диска
• Журнал ↔ буфер записи (SSD+HDD)

Минусы схемы

• Write Amplification по 4 КБ — 3-5x
  
• В памяти 2x меты
  
• EC: не коммитим → зависаем
• Недружелюбно к HDD (случайная запись)
• (!!!) Мету некуда расширять

Расширения меты

• Могилки 🪦
  • Атомарное удаление
  • Discard
  • Распределённый SSD-кэш (tiering)
• Динамические блоки данных
• Сжатие
• Локальный SSD-кэш (bcache)

Первая идея

Вторая идея

Писать в конец

Вторая идея

😊 Амортизация ⇒ память 1x, WA ↓↓

Вторая идея

😢 Нужен Compaction (LSM?..) ⇒ WA ↑↑, CPU ↑↑

Идея № 3

Вместо Compaction...

Можно просто отслеживать мусор

Побочный эффект

Как решить?

Все записи одного объекта в один блок...

...Но это не LSMeta, и WA ↑↑

Однако идея меня пленила

NonLSM: ветка heap-meta

• 65 files changed, 11489 insertions(+), 6655 deletions(-)
• Проходит все тесты
• cpp-btree → 🤣 swissmap robin_hood_map
• Атомики (см. дальше)
• Итого 176000 randwrite (~1.75x)
• 😢 Костыли (объект ограничен 1 блоком)
• 😢 WA — строго 3x или 2x

Возврат к LSMeta

Решил переписать ещё раз

Ради WA 1 можно потерпеть инвалидацию 😇

Вместо журнала — буферная область

В памяти — hashmap и связные списки

Лирическое отступление

Без оптимизации по CPU всё это бессмысленно!

Копирование памяти, (де)сериализация, потоки, блокировки... 👎👎👎

Write Amplification

Всё, делаем CoW FS?

Linux 6.11 To Introduce Block Atomic Writes –
Including NVMe & SCSI Support

• Добавлен флаг RWF_ATOMIC (неделимость запросов)
• Добавлены параметры в /sys/block/*/queue/

Атомарная запись в NVMe

Samsung PM9A3 😢

Micron 7450 / 7500

Kioxia (Toshiba) CD7-R / CD8-R

Где ещё есть атомарность

• SCSI: WRITE ATOMIC (enterprise)
• NVMe: атомарный_блок = (AWUPF+1) * блок
• SSD: 4 КБ — блок трансляции (иногда больше)

⇒ На SSD/NVMe 4 КБ атомарны всегда!
...хорошо, а то Vitastor на это уже полагается 🤣

SSD-переростки

D5-5536 на 122 TB — блок 16 КБ

HDD

Опыты с Micron 7450

Пишем по xxx КБ → рубим питание → проверяем

• USB-NVMe — не работает (буфер?)
• PCIe — ОК! но atomic_write_max_bytes = 128 КБ — ?
• max_hw_sectors_kb = 128 — ?
• Хардкод в ядре. iommu вкл → 128 КБ, выкл → 256 КБ
• Итого: РАБОТАЕТ!

Как задействовать

MySQL: innodb_doublewrite=OFF

Vitastor: ???

Как задействовать

Намерения записи (Write Intent)

1. "Сейчас обновлю блок, CRC32=..."
2. Пишем прямо на диск данных
3. Упали — сверяем CRC32
   Не совпадает ⇒ версия старая
   Совпадает ⇒ версия новая

Ветка LSMeta + Write Intent

• 36 files changed, 3229 insertions(+), 3708 deletions(-)
• WA ~1.0x!
• Micron/Kioxia или и ≤ 4 КБ запись
• 2x задержка на практике та же — ~29 μs!

Результаты randwrite 4 kb (fio_blockstore)

Потребление памяти

Потребление памяти на 1 ТБ*

* без учёта чексумм (ещё 128 МБ .. 1 ГБ на 1 ТБ)

Умная SDS со скоростью RAI(N)

• Релиз скоро 😊
• WA 1 — больше не узкое место!
• Новое хранилище — опция
• Нужны Micron/Kioxia
• Заходите в чат за тестовой версией 😇
• В прод лучше попозже 😇