Призначення чек-листа

Чек-лист призначений для системних адміністраторів та операторів, які готують фізичний або хмарний сервер до розгортання вузла Solana у ролі валідатора. Він фіксує послідовність кроків від вибору заліза до першого запуску, допомагає не пропустити критичні налаштування та уникнути типових помилок, які призводять до пропущених слотів або втрати стейку.

Чек-лист не замінює повну інструкцію з розгортання, а працює як контрольний інструмент перед тим, як переходити до створення стейк-акаунта та делегування SOL.

Етапи підготовки

Вимоги до заліза та операційної системи

  • Процесор: щонайменше 12 ядер / 24 потоки, базова частота від 2,8 ГГц, підтримка AVX2 і SHA extensions; висока частота ядра важливіша за формальну кількість ядер.
  • Оперативна памʼять: 256 ГБ або більше для голосувального валідатора; бажана ECC-памʼять і плата з можливістю розширення до 512 ГБ.
  • Накопичувачі: окремі NVMe PCIe Gen3 x4 або швидші — від 1 ТБ для accounts, від 1 ТБ для ledger і від 500 ГБ для snapshots; accounts і ledger краще не розміщувати на одному диску.
  • Мережа: для стейкованого валідатора щонайменше 2 Гбіт/с симетрично; 10 Гбіт/с доступної пропускної здатності рекомендовано для стабільної роботи. Потрібна публічна IPv4-адреса.
  • Операційна система: актуальна Ubuntu; Anza станом на 2 серпня 2026 року збирає та запускає Agave на Ubuntu 24.04. Перед встановленням перевірте вимоги конкретного релізу.
  • Ядро: оновлене до останньої стабільної версії в межах мажорного релізу дистрибутива.
  • Файлова система: ext4 або XFS для диска з леджером (уникайте Btrfs для цього завдання).
  • SSH-доступ: лише за ключами, парольний вхід вимкнено.
  • Час: синхронізовано через chrony або systemd-timesyncd, NTP-сервери налаштовано.

Мережеве налаштування та фаєрвол

  • Статична IP-адреса або резервована через DHCP.
  • Відкритий узгоджений динамічний діапазон TCP/UDP, типовий приклад у документації Anza — 8000–8030. Конкретний діапазон задайте через --dynamic-port-range.
  • RPC не відкривайте в інтернет на голосувальному mainnet-beta валідаторі без окремої обґрунтованої архітектури. За замовчуванням HTTP RPC використовує 8899, WebSocket — 8900.
  • SSH-порт змінено зі стандартного 22 або обмежено за IP-адресами.
  • Увімкнено та налаштовано ufw або nftables: дозволено лише необхідні порти, решта — drop.
  • Перевірено відсутність конфліктів із іншими сервісами на тих самих портах.
  • Не плануйте production-валідатор за NAT: Anza прямо не рекомендує таку схему. Якщо вона неминуча, оператор сам відповідає за діагностику traversal і стабільність мережі.

Встановлення Solana CLI та генерування ключів

  • Встановлено актуальний Agave CLI за офіційною інструкцією Anza.
  • Перевірено версію CLI командою solana --version — вона має відповідати поточній рекомендованій для мережі.
  • Створено окремого системного користувача для запуску валідатора (не root).
  • Згенеровано пару ключів валідатора: solana-keygen new -o /path/to/validator-keypair.json.
  • Згенеровано окрему пару ключів для авторизованого знімача (withdrawer), якщо планується стейкінг.
  • Файли ключів збережено з обмеженими правами доступу (600), резервну копію створено на окремому зашифрованому носії.
  • Перевірено, що приватні ключі ніколи не потрапляли в логи, історію bash чи систему контролю версій.
  • Запущено тестову синхронізацію снепшоту для перевірки дискового вводу-виводу та мережевого зʼєднання.

Налаштування моніторингу та алертів

  • Встановлено агент моніторингу (Prometheus node_exporter, Netdata або аналогічний).
  • Налаштовано збір метрик: CPU, RAM, дисковий I/O, мережевий трафік, розмір леджера.
  • Створено алерти: завантаження CPU понад 90% триваліше 5 хвилин, вільне місце на диску леджера менше 20%, втрата пінгу до сервера.
  • Налаштовано перевірку доступності порту валідатора ззовні (TCP-check).
  • Підключено канал сповіщень: email, Telegram або інший — з підтвердженням доставки.
  • Налаштовано логротейт для журналів Solana, щоб уникнути переповнення диска.

Критерії готовності сервера

Сервер вважається готовим до розгортання валідатора, лише якщо виконані всі умови нижче:

  • Синхронізація снепшоту завершена успішно, леджер не містить помилок цілісності.
  • Команда agave-validator --help виконується без помилок під окремим системним користувачем валідатора.
  • Публічна IPv4-адреса стабільна, а gossip показує очікувану identity та зовнішню адресу вузла.
  • Моніторинг фіксує метрики, алерти підтверджено тестовим спрацюванням.
  • Резервні копії ключів валідатора та withdrawer збережені щонайменше у двох фізично розділених місцях.
  • Фаєрвол не блокує вхідний трафік на портах валідатора, перевірено з зовнішнього вузла.
  • Достатньо вільного місця на диску леджера для щонайменше 48 годин роботи без ручного втручання.

Обмеження чек-листа

  • Чек-лист охоплює лише етап підготовки інфраструктури. Створення стейк-акаунта, делегування SOL та реєстрація валідатора в мережі не входять до його меж.
  • Чек-лист не містить кроків із оновлення — для цього призначений окремий Чек-лист оновлення валідатора.
  • Аварійне відновлення, відкат та реагування на пропущені слоти розглядаються в Аварійному runbook валідатора.
  • Специфічні вимоги хмарних провайдерів (AWS, GCP, Hetzner тощо) не деталізовані — адаптуйте мережевий блок до вашого середовища.
  • Чек-лист не замінює перевірку безпеки: аудит конфігурації, налаштування fail2ban, HIDS та інші заходи варто планувати окремо.

Версія ресурсу

Ресурс «Чек-лист підготовки сервера валідатора»: статична версія 1.0. Сторінка містить готовий текстовий чек-лист і готова до практичного використання без очікування окремого інтерактивного інструмента. Остання редакційна перевірка: 2 серпня 2026 року.

Джерела