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

Цей матеріал містить технічно перевірені специфікації для розгортання вузла валідатора Solana на базі клієнта Agave (колишній solana-labs/solana). Усі наведені нижче параметри стосуються кластера mainnet-beta. Якщо ви обслуговуєте testnet або devnet — вимоги до накопичувача будуть нижчими, проте архітектурні обмеження залишається тими самими. Перевірено станом на червень 2025 року; перед закупівлею обовʼязково звіртеся з офіційним репозиторієм Agave, оскільки вимоги зростають разом із розміром леджера.

Мінімальні та рекомендовані специфікації

Різниця між мінімальними та рекомендованими специфікаціями — не формальна. Мінімум дозволяє вузлу синхронізуватися та функціонувати, але за навантаження на мережу такий валідатор з високою ймовірністю пропускатиме слоти, отримуватиме менше винагород і створюватиме ризик відставання (delinquency). Рекомендовані специфікації забезпечують стабільну роботу з запасом на зростання леджера.

CPU: ядра, частота, архітектура

  • Архітектура: виключно x86_64 (AMD64). ARM-платформи наразі не підтримуються клієнтом Agave.
  • Мінімум: 12 фізичних ядер.
  • Рекомендовано: 16 фізичних ядер і більше.
  • Частота: базова частота від 2.8 GHz. Solana — це переважно однопотокове навантаження на етапі обробки транзакцій у слоті, тому вища тактова частота окремого ядра дає помітний ефект.
  • Платформи: серверні лінійки AMD EPYC (Milan, Genoa) або Intel Xeon (Ice Lake, Sapphire Rapids). Споживчі процесори (Ryzen, Core iX) працюють, але не мають ECC-памʼяті та серверних можливостей відновлення.

RAM: обсяг, тип, канали

  • Мінімум: 128 GB.
  • Рекомендовано: 256 GB.
  • Тип: ECC DDR4 або DDR5. ECC не є жорсткою вимогою клієнта, але для сервера, що безперервно обробляє фінансові транзакції, використання памʼяті з корекцією помилок — стандарт операційної гігієни.
  • Канальність: максимально можлива для вашої платформи (8-канальна конфігурація на EPYC дає суттєву перевагу в пропускній здатності памʼяті порівняно з 2- або 4-канальною).

Обсяг леджера mainnet постійно зростає. Якщо сьогодні 128 GB вистачає із запасом, через 6–12 місяців ситуація може змінитися. 256 GB дає горизонт планування.

Накопичувач: NVMe, обсяг, IOPS, TBW

  • Тип: виключно NVMe SSD. Будь-які SATA-накопичувачі, HDD або гібридні рішення непридатні — вузол не встигатиме читати акаунти під час обробки слота.
  • Мінімальний обсяг: 1 TB.
  • Рекомендований обсяг: 2 TB і більше, залежно від горизонту планування та кількості знімків (snapshots), які ви зберігаєте.
  • IOPS: випадкове читання — від 100 000 IOPS і вище (4K random read). Це ключова метрика: під час обробки транзакцій валідатор виконує тисячі випадкових читань акаунтів.
  • TBW (Total Bytes Written): для mainnet-валідатора накопичувач зазнає значного запису. Орієнтуйтеся на enterprise- або datacenter-клас із TBW від 1200 TB для 1 TB диска (наприклад, Samsung PM9A3, Intel/Solidigm D7-P5510, Micron 7450 PRO). Споживчі NVMe (Samsung 990 Pro, WD Black SN850X) працюватимуть, але їхній ресурс TBW може вичерпатися за 8–18 місяців інтенсивної роботи.
  • Форм-фактор: U.2 або M.2 (з адекватним відведенням тепла). Для серверних платформ U.2 є стандартом.

Операційна система та залежності

Рекомендована ОС: Ubuntu 24.04 LTS (Jammy Jellyfish). Це найширше протестоване середовище для клієнта Agave. Ubuntu 20.04 LTS також підтримується, але наближається до кінця стандартної підтримки.

Інші дистрибутиви (Debian 12, Rocky Linux 9) можуть працювати, але ви зіткнетеся з відсутністю готових інструкцій та необхідністю самостійно вирішувати конфлікти залежностей.

Основні залежності:

  • build-essential — компілятори та інструменти збірки (gcc, make).
  • pkg-config — для пошуку бібліотек під час компіляції.
  • libssl-dev — криптографічна бібліотека.
  • libudev-dev — для взаємодії з апаратним забезпеченням (зокрема з апаратними ключами).
  • Rust toolchain — клієнт Agave написаний на Rust, тому для збірки з вихідного коду потрібен stable Rust (встановлюється через rustup).
  • systemd — стандартний менеджер сервісів; всі офіційні інструкції з управління валідатором орієнтовані на systemd-юніти.
  • lz4 — використовується для стиснення та розпакування знімків леджера.

Якщо ви встановлюєте валідатор із готових бінарних файлів (release binaries), Rust не потрібен — але для оновлень та патчів збірка з вихідного коду є стандартом у спільноті.

Мережеві вимоги: пропускна здатність та latency

Мережа — це не другорядний фактор, а критична складова. Solana генерує блоки кожні ~400 мілісекунд, і валідатор повинен встигати обмінюватися повідомленнями з іншими вузлами в межах цього вікна.

  • Мінімальна пропускна здатність: 1 Gbps.
  • Рекомендована пропускна здатність: 10 Gbps. Під час пікових навантажень (високодіяльні епохи, спами транзакціями) трафік між вузлами може суттєво зростати.
  • Symmetric bandwidth:Вихідна та вхідна пропускна здатність мають бути симетричними. Домашні зʼєднання з асиметричним каналом (наприклад, 1 Gbps down / 50 Mbps up) непридатні.
  • Latency: чим нижча — тим краще. Ідеально — розміщення в дата-центрі, де фізично присутні інші валідатори Solana. Типові значення: до 5 ms до більшості peer-вузлів у межах одного регіону, до 50 ms — між континентами.
  • Статична IP-адреса: обовʼязкова. Валідатори ідентифікуються за IP, і динамічна адреса ускладнить звʼязок з іншими вузлами.
  • Порти: за замовчуванням клієнт використовує порт 8000–8009 для gossip, 8899 для RPC (якщо увімкнено), 8900 для службового RPC. Переконайтеся, що ці порти відкриті для вхідного та вихідного трафіку.

Використання VPN, Tor або проксі для трафіку валідатора неприпустиме — це прямо порушує роботу протоколу gossip і призведе до ізоляції вузла.

Орієнтовна вартість інфраструктури

Конкретні цифри залежать від провайдера, регіону, поточного ринку та обраної конфігурації, тому наводити фіксовані суми без привʼязки до дати та джерела було б некоректно. Натомість наведемо структуру витрат, за якою ви зможете самостійно розрахувати бюджет:

  • Сервер (CAPEX або щомісячна оренда): основний драйвер вартості — це CPU (серверний клас із 16+ ядрами) та накопичувач (enterprise NVMe з високим TBW). RAM у серверних конфігураціях зазвичай йде у комплекті або додає помірну суму.
  • Мережа: 10 Gbps порт у дата-центрі коштує значно дорожче за 1 Gbps. Оцініть, чи потрібен вам 10 Gbps відразу чи можна почати з 1 Gbps з можливістю апгрейду.
  • Колокація або хмарний провайдер: bare-metal у колокації зазвичай дешевший за еквівалентний хмарний інстанс, але вимагає управління апаратним забезпеченням. Хмарні рішення (наприклад, Dedicated Instances) дають гнучкість, але з націнкою.
  • Резервний сервер: якщо ваш основний вузол виходить з ладу, вам потрібен запасний сервер для швидкого відновлення. Це фактично подвоює апаратні витрати.
  • Моніторинг та інфраструктурні сервіси: системи моніторингу (Prometheus, Grafana), логування, алерти — можуть бути безкоштовними (self-hosted), але вимагають ресурсів або окремого сервера.

Для поточного розрахунку зверніться до провайдерів bare-metal (Hetzner, OVH, Leaseweb та інші) або хмарних платформ і порівняйте конфігурації, що відповідають наведеним вище специфікаціям.

Перевірка відповідності сервера вимогам

Перед розгортанням валідатора виконайте наступні перевірки на сервері з Ubuntu 24.04 LTS. Усі команди безпечні та лише читають інформацію.

CPU:

lscpu | grep -E "Architecture|CPU\(s\)|Thread|Core|Model name|MHz"

Очікуваний результат: Architecture — x86_64, CPU(s) — 16 або більше (фізичних ядер, без гіперпотоків), MHz — від 2800.

RAM:

free -h

Очікуваний результат: total — 128G або більше. Якщо ви бачите менше, перевірте, чи всі модулі розпізнані BIOS.

Накопичувач:

lsblk -d -o NAME,SIZE,ROTA,TYPE,MODEL

Очікуваний результат: ROTA = 0 (вказує на SSD, не HDD), TYPE = disk, SIZE — 1T або більше. Перевірте, що це саме NVMe, а не SATA SSD:

ls /dev/nvme*

Якщо каталог не порожній — накопичувач NVMe.

IOPS накопичувача (тільки для читання, безпечна команда):

sudo apt install -y fio && fio --name=read-test --filename=/mnt/nvme_test --size=4G --rw=randread --bs=4k --ioengine=libaio --iodepth=64 --numjobs=4 --time_based --runtime=30 --group_reporting

Увага: ця команда створює 4 GB тестовий файл. Замініть /mnt/nvme_test на шлях до вашого NVMe-розділу. Після тесту файл можна безпечно видалити: rm /mnt/nvme_test.

Очікуваний результат: read IOPS — від 100 000 і вище. Якщо значення суттєво нижче, накопичувач може не витримати навантаження mainnet.

Мережа:

ip link show | grep -E "state UP|mtu"

Очікуваний результат: інтерфейс у стані UP, MTU — 9000 (jumbo frames рекомендовано для зменшення накладних витрат на пакети між валідаторами). Якщо MTU 1500 — налаштуйте jumbo frames у співпраці з вашим провайдером.

Пропускна здатність (потребує iperf3 на обох кінцях):

iperf3 -c <IP_віддаленого_сервера> -p 5201 -t 30 -P 4

Очікуваний результат: від 1 Gbps і вище. Якщо значення стабільно нижче 800 Mbps — перевірте налаштування мережевого інтерфейсу та узгодьте це з провайдером.

Системний час:

timedatectl status

Очікуваний результат: NTP synchronized — yes. Розсинхронізація часу на валідаторі призводить до відхилення блоків та ізоляції. Якщо NTP не активний — увімкніть:

sudo timedatectl set-ntp true

Після всіх перевірок ви матимете обʼєктивну картину відповідності сервера вимогам. Якщо хоча б один критичний параметр (архітектура CPU, тип накопичувача, обсяг RAM, синхронізація часу) не відповідає мінімуму — розгортання валідатора на цьому сервері не рекомендоване.

Джерела