Операційні вимоги для «NVMe-накопичувачі для валідатора: вибір та налаштування» перевірено 2 серпня 2026 року. Для production використовуйте тільки реліз Agave, рекомендований для конкретного кластера, і звіряйте параметри з agave-validator --help . Офіційні вимоги Anza на цю дату орієнтують операторів на Ubuntu 24.04, щонайменше 12 ядер/24 потоки, 256 ГБ RAM, окремі швидкі NVMe та симетричний канал від 2 Гбіт/с; це рекомендації, а не гарантія достатньої продуктивності.

Накопичувач визначає, чи встигне валідатор обробити потік слотів, чи почне відставати й отримувати skip-голосування. Цей довідник зводить вибір NVMe, його налаштування та моніторинг до конкретних параметрів, команд і перевірок, які можна застосувати на реальному вузлі.

Середовище: Agave-валідатор (gRPC-клієнт Solana) на Ubuntu 24.04 LTS або 24.04 LTS, кластер mainnet-beta. Перевірено станом на червень 2025 року. Перед застосуванням команд переконайтеся, що актуальна версія Agave не змінила рекомендацій щодо файлової системи або монтування.

Чому NVMe критичний для валідатора

Solana-валідатор виконує два дисково-інтенсивних процеси: підтримку бази даних рахунків (Accounts DB) та запис леджера (ledger). Accounts DB — це ключовий вузол: під час обробки слота клієнт виконує тисячі випадкових читань і записів невеликими блоками (4–16 КБ). Жоден HDD чи SATA SSD не забезпечує потрібної комбінації latency та IOPS для цього навантаження.

Крім того, під час завантаження валідатора (після перезапуску або оновлення) клієнт читає snapshot — стиснутий дамп Accounts DB. Швидкість цього читання безпосередньо визначає час простою: на повільному диску завантаження може тривати годинами, на якісному NVMe — хвилини.

Третій фактор — зростання леджера. Mainnet-леджер безперервно збільшується, і накопичувач має мати запас ємності, інакше валідатор зупиниться з помилкою відсутності місця на диску.

Ключові параметри накопичувача

Читання/запис: послідовний та випадковий

Для валідатора випадковий читання (random read) значно важливіше за послідовний. Саме випадкові операції з малим розміром блоку визначають, чи встигає Accounts DB обслуговувати запити під час пікового навантаження. Послідовна швидкість впливає переважно на завантаження snapshot та розпакування леджера — це важливо, але не є вузьким місцем у стабільному стані.

Орієнтовний мінімум для випадкового читання 4K з чергою глибини 1 (QD1) — не нижче 40–50 тис. IOPS. Значення нижче 20 тис. IOPS при QD1 свідчать про те, що накопичувач не підходить для production-валідатора.

IOPS при черговій черзі

Виробники часто вказують IOPS при черзі глибини 32 або 128 (QD32, QD128), що дає вражаючі цифри, але не відображає реальне навантаження валідатора. Типова черга для Accounts DB — QD1–QD4. Тому при виборі шукайте специфікації саме для низької глибини черги або перевіряйте накопичувач незалежним бенчмарком (наприклад, fio) у режимі, що імітує роботу валідатора.

Команда для базової перевірки випадкового читання 4K QD1 на незайманому диску (не запускайте на диску з леджером — це створить навантаження):

fio --name=rand-read --ioengine=libaio --iodepth=1 --rw=randread --bs=4k --direct=1 --size=1G --numjobs=1 --runtime=30 --group_reporting

TBW (Total Bytes Written) та довговічність

TBW — гарантований виробником обсяг даних, який можна записати на накопичувач за весь термін служби. Валідатор постійно пише в леджер та Accounts DB, тому споживання TBW відчутне. Для оцінки достатності TBW потрібно знати фактичний обсяг записів на вашому вузлі — його можна отримати з SMART-атрибута (див. розділ про моніторинг).

Enterprise-накопичувачі зазвичай мають TBW у діапазоні одиниць або десятків петабайтів, споживчі M.2 — від сотень терабайт до кількох петабайтів. Вибір залежить від того, скільки часу ви плануєте експлуатувати диск до заміни та який запас довговічності вважаєте прийнятним.

Ємність: скільки потрібно для ledger

Поточний розмір mainnet-леджера перевіряйте безпосередньо на работаючому вузлі або за даними експлорерів, оскільки він змінюється щотижня. Не покладайтеся на цифри з минулих місяців.

Команда для перевірки зайнятого місця на точці монтування леджера:

df -h /mnt/ledger

Загальне правило: ємність накопичувача має бути щонайменше вдвічі більшою за поточний розмір леджера. Це дає запас на зростання, місце для тимчасових файлів під час snapshot-процесу та зменшує вплив зносу через перерозподіл записів на менш заповненому диску.

Рекомендовані моделі NVMe

У спільноті операторів Solana склався перелік накопичувачів, які масово deployed на mainnet-вузлах і показують стабільну роботу. Цей перелік не є офіційною рекомендацією Solana Labs — це спостереження з практики операторів.

Enterprise U.2/U.3 (PLP, високий TBW):

  • Samsung PM9A3 — широко використовується на вузлах з високим навантаженням, має Power Loss Protection (PLP), високий TBW.
  • Solidigm D7-P5520 та D7-P5810 — стабільні показники випадкового читання при низькій черзі, гарантована довговічність.
  • Micron 7450 PRO / 7450 MAX — добре поєднання IOPS та ціни, підтримка PLP.

Споживчі M.2 (без PLP, нижчий TBW, але доступніші):

  • Samsung 990 PRO — високі показники випадкового читання, але без PLP та з обмеженим TBW (приблизно 1.2 PB для 2TB-версії).
  • WD Black SN850X — подібний клас, без PLP.

Важливе застереження щодо PLP: Power Loss Protection — апаратна можливість накопичувача завершити незавершені записи при раптовому відключенні живлення. Без PLP рапове знеструмлення може призвести до пошкодження леджера або Accounts DB. Якщо використовуєте споживчий M.2 без PLP, обов'язково забезпечте безперебійне живлення (UPS) з достатньою ємністю для коректного завершення роботи валідатора.

RAID чи окремі диски: компроміси

Офіційна документація Agave рекомендує використовувати один NVMe-накопичувач для леджера та Accounts DB без програмного чи апаратного RAID. Це не випадковість — RAID додає складність без реальної користі для цього конкретного навантаження.

Чому не апаратний RAID (HW RAID):

  • Контролери HW RAID додають власний шар кешування та обробки, що збільшує latency. Для випадкових операцій 4K це прямий удар по продуктивності.
  • Багато HW-контролерів не підтримують TRIM, що призводить до деградації продуктивності SSD з часом.
  • Складність відновлення: якщо контролер виходить з ладу, потрібен ідентичний замінник для доступу до масиву.

Чому не програмний RAID (mdadm, ZFS):

  • mdadm (RAID0) дає лінійне збільшення послідовної швидкості, але не покращує випадкове читання при низькій черзі — саме те, що потрібно валідатору.
  • ZFS додає значні витрати RAM на ARC та обчислювальні накладні витрати на checksumming. Для вузла, де кожен гігабайт RAM потрібен для Accounts DB, це недоречно.

Єдиний виняток — ZFS у режимі single-disk vdev з увімкненим ZIL для захисту від втрати даних при знеструмленні. Це дає переваги journaling без накладних витрат RAID. Проте ця конфігурація вимагає ретельного налаштування та розуміння ZFS, тому для більшості операторів просте монтування на ext4 або xfs залишається найбезпечнішим вибором.

Рекомендована стратегія: один високоякісний NVMe-накопичувач, відформатований у ext4 або xfs, з регулярними бекапами snapshot на окремий диск. Якщо потрібна відмовостійкість — тримайте готовий до підключення запасний накопичувач із свіжим snapshot, а не будуйте RAID.

Моніторинг стану NVMe (SMART)

Регулярний моніторинг SMART-атрибутів дозволяє виявити деградацію диска до того, як він вплине на роботу валідатора. Основний інструмент — smartctl з пакета smartmontools.

Встановлення (якщо ще не встановлено):

sudo apt install smartmontools

Перевірка загального стану здоров'я:

sudo smartctl -H /dev/nvme0n1

Очікуваний результат: PASSED. Будь-яке інше значення — сигнал для негайної заміни диска.

Повний звіт SMART для NVMe:

sudo smartctl -a /dev/nvme0n1

Ключові атрибути, за якими потрібно стежити:

Атрибут Що показує Дія при проблемі
Percentage Used Відсоток спожитого ресурсу диска (0% — новий, 100% — вичерпаний) При значенні понад 80% — планувати заміну
Critical Warning Бітове поле попереджень (температура, доступний простір, надійність) Будь-яке ненульове значення — негайна діагностика
Temperature Поточна температура диска Постійно вище 70°C — перевірити охолодження
Media and Data Integrity Errors Кількість помилок цілісності даних Будь-яке значення більше нуля — заміна диска
Available Spare Відсоток запасних блоків Нижче 10% — критично, заміна

Автоматизоване опитування SMART можна налаштувати через smartd. У файлі /etc/smartd.conf додайте рядок:

/dev/nvme0n1 -a -m [email protected] -M test

Спочатку використовуйте прапорець -M test для перевірки доставки сповіщень, потім приберіть його для переходу в production-режим. Переконайтеся, що MTA налаштований коректно, інакше сповіщення не надійдуть.

Специфіка NVMe-SMART: на відміну від SATA SSD, де критерієм зносу часто слугує Wear Leveling Count, для NVMe орієнтуйтеся саме на Percentage Used. Цей атрибут розраховується виробником на основі фактичного спожитого TBW відносно заявленого ресурсу.

Попередження щодо руйнівних дій: не виконуйте smartctl --smart=off /dev/nvme0n1 на production-диску — це вимкне моніторинг SMART, і ви втратите можливість відстежувати деградацію. Якщо вам потрібно вимкнути SMART для діагностики, спочатку створіть повний snapshot леджера та переконайтеся, що маєте робочий бекап.

Наступний крок: після вибору та налаштування накопичувача перейдіть до налаштування мережі — саме мережевий стек визначає, чи надходитимуть слоти та голоси вчасно. Дивіться розділ Мережеві вимоги валідатора: пропускна здатність, latency, порти.

Джерела