Розгортання ноди Solana: налаштування та оптимізація RPC-доступу

Чому запуск ноди Solana — нетривіальне завдання

У нашій практиці ми стикалися з ситуаціями, коли клієнт закуповував сервер за офіційними мінімальними вимогами, але нода відставала від tip вже через тиждень. Solana — один з найвимогливіших блокчейнів до ресурсів: мінімальні системні вимоги — це не приблизні рекомендації, а жорсткий поріг, за яким нода просто не встигає за мережею та деградує. Неправильний вибір диска, нестача RAM або економія на мережевому каналі призводять до постійних форків та втрати RPC-стабільності. Ми налаштовували ноди для DeFi-проектів, що обробляють тисячі запитів на секунду, і виробили конфігурацію, яка дозволяє тримати slot lag нижче 10 слотів.

Вимоги до обладнання: що реально потрібно

Офіційні вимоги Solana Foundation та реальний production-minimum розходяться. Практичні цифри на поточний момент:

Чому так багато RAM: Solana зберігає account state в пам'яті (accounts DB). При 1.8+ млрд accounts в мережі це сотні гігабайт. Нода з 128 GB RAM не запуститься стабільно.

Чому NVMe обов'язковий: швидкість I/O критична. Нода обробляє тисячі транзакцій на секунду, записує ledger, відповідає на RPC — все одночасно. Rotational HDD для accounts/ledger неприйнятні: вони програють NVMe в 50 разів за пропускною здатністю випадкового доступу.

Як обрати оптимальну конфігурацію для RPC-ноди?

Якщо вам потрібен RPC-вузол без голосування, можна заощадити на CPU (12 ядер достатньо), але не на RAM та дисках. Для комерційного RPC, що обслуговує десятки тисяч запитів, беріть 512 ГБ RAM та 4 ТБ NVMe з PCIe 4.0. Мережа — обов'язково 10 Гбіт/с, інакше клієнти скаржитимуться на таймаути. Правильна конфігурація окупається за рахунок відсутності простоїв — одна хвилина даунтайму може коштувати $1000 для DeFi-проекту. Зв'яжіться з нами, щоб підібрати оптимальне обладнання під ваше навантаження.

Встановлення та конфігурація

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

# Ubuntu 22.04 LTS — рекомендуемая OS # Настройка sysctl для высокой нагрузки cat >> /etc/sysctl.conf << EOF net.core.rmem_max = 134217728 net.core.wmem_max = 134217728 net.core.rmem_default = 134217728 net.core.wmem_default = 134217728 net.core.optmem_max = 134217728 net.core.netdev_max_backlog = 65536 EOF sysctl -p # Лимиты для процесса solana-validator cat >> /etc/security/limits.conf << EOF solana soft nofile 1000000 solana hard nofile 1000000 solana soft memlock unlimited solana hard memlock unlimited EOF # Hugepages для улучшения производительности памяти echo 'vm.nr_hugepages = 131072' >> /etc/sysctl.conf 

Встановлення Solana CLI

# Устанавливаем конкретную версию — не latest в production SOLANA_VERSION="v1.18.26" sh -c "$(curl -sSfL https://release.solana.com/${SOLANA_VERSION}/install)" export PATH="/home/solana/.local/share/solana/install/active_release/bin:$PATH" solana --version 

Конфігурація RPC-ноди

# /home/solana/start-validator.sh #!/bin/bash exec solana-validator \ --identity /home/solana/validator-keypair.json \ --known-validator 7Np41oeYqpe1GAUzqNoFdJ5SAAQhphFp8s6XAXFCLRiE \ --known-validator GdnSyH3YtwcxFvQrVVJMm1JhTS4QVX7MFsX56uJLUfiZ \ --known-validator DE1bawNcRJB9rVm3buyMVDbezCfKkKa3aTEnDqeS89UB \ --only-known-rpc \ --rpc-port 8899 \ --private-rpc \ --dynamic-port-range 8000-8020 \ --entrypoint mainnet-beta.solana.com:8001 \ --entrypoint entrypoint2.mainnet.solana.com:8001 \ --entrypoint entrypoint3.mainnet.solana.com:8001 \ --expected-genesis-hash 5eykt4UsFv8P8NJdTREpY1vzqKqZKvdpKuc147dw2N9d \ --wal-recovery-mode skip_any_corrupted_record \ --ledger /mnt/ledger \ --accounts /mnt/accounts \ --snapshots /mnt/snapshots \ --log /home/solana/solana-validator.log \ --limit-ledger-size 50000000 \ --no-voting \ --enable-rpc-transaction-history \ --enable-extended-tx-metadata-storage \ --rpc-bind-address 0.0.0.0 

Ключові флаги:

• --no-voting — RPC-нода, не валідатор (не потрібен stake)
• --limit-ledger-size 50000000 — обмеження розміру ledger (~200 GB). Без цього ledger росте необмежено
• --enable-rpc-transaction-history — зберігати історію транзакцій (необхідно для getTransaction)
• --known-validator — довірені валідатори для initial sync. Обов'язково для безпеки, інакше нода може синхронізуватися з fork

Перший запуск: snapshot синхронізація

Синхронізація з genesis займає тижні. Використовуємо snapshot — це в 10 разів швидше:

# Скачиваем последний snapshot с официальных источников # Список available snapshots: https://api.mainnet-beta.solana.com/ solana-validator \ --ledger /mnt/ledger \ download-latest-snapshot \ --snapshot-dir /mnt/snapshots \ --trusted-validators 7Np41oeYqpe1GAUzqNoFdJ5SAAQhphFp8s6XAXFCLRiE 

Після завантаження snapshot (~100+ GB) нода запускається та наздоганяє tip за кілька годин.

Моніторинг ноди

# Статус ноды solana-validator --ledger /mnt/ledger monitor # Информация о здоровье curl -s http://localhost:8899 -X POST -H "Content-Type: application/json" \ -d '{"jsonrpc":"2.0","id":1,"method":"getHealth"}' | jq . # Отставание от tip (должно быть < 100 слотов в норме) solana catchup --our-localhost 8899 

Критичні метрики: slot lag, skipped slots, memory usage (має бути < 90% RAM), I/O wait.

Prometheus + Grafana: експортер solana-exporter публікує метрики у форматі Prometheus. Dashboard доступний на Grafana Marketplace.

Які метрики вказують на проблеми?

Якщо slot lag перевищує 1000 слотів, а skipped slots зростають — це сигнал, що нода не справляється з навантаженням. Дивіться на I/O wait: якщо він > 30%, диск стає вузьким місцем. RAM при повному завантаженні accounts бази — слідкуйте за наближенням до 90%. Налаштуйте алерти в Grafana на ці пороги.

Типові проблеми

Нода відстає і не може наздогнати tip: зазвичай проблема в I/O — accounts база не встигає. Перевіряємо iostat -x 1, якщо await > 50ms — потрібен швидший NVMe.

OOM killer вбиває процес: 256 GB RAM на межі. Рішення: додати swap на NVMe (не HDD), налаштувати vm.swappiness=10.

Нода форкається: перевіряємо --known-validator та --expected-genesis-hash. Нода без trusted validators вразлива до eclipse атак.

Як ми налаштовуємо Solana-ноду: етапи роботи

Ми пропонуємо розгортання ноди Solana під ключ, від аналізу вимог до передачі в експлуатацію.

Терміни орієнтовні від 4 до 8 робочих днів. Вартість розраховується індивідуально — залежить від складності та обраного заліза. Зв'яжіться з нами для оцінки проекту.

Що входить в роботу

• Підготовка сервера: sysctl, limits, hugepages, розмітка дисків
• Встановлення та конфігурація solana-validator
• Початкова синхронізація через snapshot
• Налаштування systemd сервісу та автоперезапуску
• Моніторинг: Prometheus метрики, Grafana дашборд, алерти на slot lag
• Консультація щодо вибору хостингу та заліза

Замовте налаштування ноди Solana — ми забезпечимо стабільний RPC-доступ з мінімальним часом простою. Отримайте консультацію інженера.