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

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

Чому резервування необхідне

Валідатор Solana — це не Stateless-сервіс. Його стан складається з повного леджера, набору рахунків та поточного слота. Втрата доступу до цього стану означає не просто перезапуск процесу, а тривалу відновлювальну синхронізацію, яка на mainnet-beta може тривати від кількох годин до кількох днів залежно від швидкості дискової підсистеми та стану мережі.

Основні загрози, що виправдовують резервування:

  • Апаратна відмова. Виходи з ладу NVMe-накопичувачів, оперативної пам'яті, материнської плати або блоку живлення. Навіть RAID-масив не захищає від відмови контролера або помилок прошивки.
  • Програмні збої. Kernel panic, OOM-вбивства, помилки файлової системи, корупція леджера внаслідок апаратних проблем із пам'яттю (bit flips).
  • Інфраструктурні інциденти. Відключення електроживлення в дата-центрі, відмова комутатора, витік охолоджувальної рідини в ряду стійок.
  • Планові перерви. Оновлення мікрокоду BIOS, замена компонентів за гарантією, міграція між стійками.

У контексті Solana тривалий простій валідатора означає пропущені слоти, перехід у статус delinquent та втрату частки винагород. Точні параметри делінквентності та вплив на винагороди варто перевірити в актуальній документації кластера, оскільки вони можуть змінюватися з оновленнями протоколу.

Стратегія hot spare: готовий резервний вузол

Hot spare — це повністю розгорнутий і синхронізований валідатор, який не бере участі в консенсусі (не голосує), але готовий увійти в кластер миттєво після перемикання. Це не холодний бекап і не віртуальна машина, яку треба піднімати з образу.

Вимоги до hot spare вузла

  • Ідентична або перевищуюча апаратна конфігурація відносно основного вузла: кількість ядер, обсяг RAM, тип і кількість NVMe-дисків. Слабший вузол не зможе утримувати темп кластера після перемикання.
  • Попередньо згенеровані ключові пари. На резервному вузлі мають бути розміщені identity-keypair та vote-account-keypair. Ключі мають бути ідентичними основному вузлу — це один і той самий валідатор, а не окремий екземпляр.
  • Синхронізований леджер. Вузол має бути спійманий до поточного слота кластера або відставати на мінімально допустиму величину (зазвичай не більше кількох слотів).
  • Фізична роздільність. Резервний вузол має перебувати в іншій стійці, бажано — в іншій зоні доступності того самого дата-центру або в сусідньому. Розміщення в одному ряду під одним комутатором не дає справжнього резервування.

Розгортання hot spare

Клієнт: agave-validator (Agave). Кластер: mainnet-beta або testnet. ОС: Ubuntu 24.04 LTS. Дата перевірки: верифікуйте актуальність прапорців у репозиторії Agave перед застосуванням.

Резервний вузол запускається з тією самою конфігурацією, що й основний, але із додатковим прапорцем:

agave-validator --no-voting --identity /path/to/identity-keypair.json --vote-account <vote-account-pubkey> --known-validator <pubkey> ... [решта параметрів]</pubkey></vote-account-pubkey>

Прапорець --no-voting гарантує, що вузол синхронізується, підтримує зв'язок із мережею через gossip, але не відправляє голоси. Це критично важливо: два вузли з одним identity-keypair не можуть голосувати одночасно, оскільки це розцінюється мережею як аномалія.

Перевірка стану:

solana slots --url http://127.0.0.1:8899

Очікуваний результат: значення «slot» має бути близьким до поточного слота кластера (перевірити через solana slot на будь-якому синхронізованому вузлі).

Ризик: Якщо випадково запустити резервний вузол без --no-voting поки основний ще активний, виникне дублювання голосів. Це може спричинити некоректну поведінку з боку кластера.

Автоматичний failover: як це працює

Solana-валідатор не має вбудованого механізму автоматичного failover. Перемикання між вузлами — це завдання інфраструктурного рівня, яке оператор реалізовує самостійно. Логіка полягає у трьох кроках: виявлення відмови, зупинка голосування на основному вузлі, активація голосування на резервному.

Виявлення відмови (health check)

Моніторинг має фіксувати такі стани:

  • Процес agave-validator не відповідає на healthz-запити.
  • Відставання за слотами перевищує поріг (наприклад, 150 слотів для mainnet-beta — точне значення перевірте в актуальній документації).
  • Диск заповнений понад 90%.
  • Температура NVMe перевищує критичний поріг (за наявності датчиків SMART).

Типове рішення — зовнішній скрипт або система моніторингу (Prometheus + Alertmanager, або кастомний daemon), що періодично опитує метрики валідатора через REST API (http://127.0.0.1:8899/health) та експортовані Prometheus-метрики (зазвичай порт 8898 або 8899 залежно від конфігурації).

Процедура перемикання

  1. Фіксація відмови. Health check підтверджує, що основний вузол недоступний або некоректно функціонує протягом заданого таймауту (рекомендовано не менше 30–60 секунд, щоб уникнути хибного спрацьовування).
  2. Примусова зупинка основного вузла. Якщо процес ще живий — примусово зупинити: systemctl stop agave-validator або kill -9. Це гарантує, що жоден голос не буде відправлено з основного вузла після активації резервного.
  3. Активація резервного вузла. Перезапустити agave-validator на hot spare без прапорця --no-voting. Це можна зробити через зміну конфігурації systemd unit та виконання systemctl restart agave-validator, або через сигнал, що змінює поведінку процесу.
  4. Підтвердження. Перевірити, що резервний вузол голосує: solana vote-account <vote-account-pubkey></vote-account-pubkey> — поле «last vote» має оновлюватися.

Попередження: Автоматичний failover — це руйнівна операція в тому сенсі, що вона змінює активний вузол. Неправильно налаштований health check може спричинити постійне перемикання туди-сюди (flapping), що є гіршим за одиночну відмову. Обов'язково реалізуйте cooldown-період після перемикання (наприклад, 10 хвилин, протягом яких новий health check не може ініціювати зворотне перемикання).

Шлях відкату: Якщо failover спрацював хибно, зупиніть голосування на резервному вузлі (додати --no-voting і перезапустити), переконайтеся, що основний вузол функціонує коректно, і перезапустіть його без --no-voting.

Синхронізація стану між основним та резервним

Головний виклик hot spare — тримати леджер актуальним без участі в голосуванні. Є два основні підходи.

Незалежна синхронізація через gossip

Резервний вузол підключається до мережі через gossip-протокол і завантажує слоти від інших учасників кластера, як звичайний неголосуючий вузол. За умови достатньої пропускної здатності мережі та швидкого диска, такий вузол здатен триматися близько до вершини леджера.

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

Локальне реплікування леджера

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

Типовий підхід — використання ZFS з відправкою snapshot-ів або rsync з відповідними обмеженнями. Критична умова: не можна копіювати леджер, поки основний валідатор активно його записує, без механізму узгодження (snapshot, LVM snapshot, або зупинка копіювання на рівні файлової системи).

Попередження: Копіювання леджера «на живу» без snapshot-механізму може призвести до неконсистентного стану на резервному вузлі. Валідатор із пошкодженим леджером може не стартувати або перейти в режим повної ресинхронізації, що звідки нівелює переваги hot spare.

Практична рекомендація: Для більшості операторів незалежна синхронізація через gossip є простішою та надійнішою за локальне реплікування, за умови що резервний вузол має достатню мережеву пропускну здатність (1 Гбіт/с — мінімум, 10 Гбіт/с — рекомендовано для mainnet-beta).

Тестування резервного сценарію

Нересурсований failover — це не резервування, а ілюзія. Тестування має бути регулярним і документованим.

Базовий тест (рекомендовано проводити щомісяця)

  1. Зафіксуйте поточний стан: запишіть поточний слот, статус vote-account, час останнього голосу.
  2. Імітація відмови: зупиніть основний валідатор: systemctl stop agave-validator
  3. Запустіть failover-процедуру: або вручну, або через автоматизований скрипт.
  4. Зафіксуйте результат: час від зупинки основного до першого голосу резервного, відставання за слотами у момент активації, кількість пропущених слотів.
  5. Повернення до норми: після підтвердження стабільності резервного вузла, зупиніть його голосування, переконайтеся, що основний вузол може синхронізуватися та відновити голосування.

Критерії успіху: резервний вузол почав голосувати не пізніше ніж за 2–3 хвилини після зупинки основного (за умови, що відставання за слотами було мінімальним). Точний допустимий поріг залежить від вашої толерантності до пропущених слотів.

Тест з відставанням леджера

Додатково перевірте сценарій, коли hot spare відставав на значну кількість слотів (наприклад, штучно зупиніть синхронізацію на кілька годин, потім імітуйте failover). Це покаже реальний час відновлення за неідеальних умов.

Типова помилка: тестувати failover лише коли hot spare ідеально синхронізований. У реальній відмові (наприклад, вихід з ладу комутатора) резервний вузол може мати відставання, і саме цей сценарій треба перевірити.

Вартість резервування vs ризик простою

Розрахунок економічної доцільності резервування вимагає кількох змінних, які відрізняються для кожного оператора:

  • Вартість апаратного забезпечення резервного вузла (сервер, NVMe-диски, RAM).
  • Вартість колокації — місце в стійці, електроживлення, трафік.
  • Вартість операційної праці — початкове налаштування, підтримка синхронізації, регулярне тестування.
  • Очікувана втрата від простою — залежить від розміру стейку, поточного рівня винагород та тривалості відновлення без резервного вузла.

Конкретні цифри винагород за слот, делінквентності та штрафів змінюються з оновленнями протоколу. Оператор має самостійно розрахувати очікувану втрату за формулою: кількість пропущених слотів × винагорода за слот × тривалість відновлення — і порівняти з місячною вартістю утримання hot spare.

Орієнтовні принципи прийняття рішення:

  • Малі стейки (до кількох тисяч SOL). Вартість резервного сервера може перевищувати очікувану втрату від рідкісних простоїв. У цьому випадку достатньо надійного сервера, регулярних бекапів ключів та відпрацьованої ручної процедури відновлення.
  • Середні та великі стейки. Навіть один інцидент з тривалим відновленням може перекрити річні витрати на hot spare. Резервування економічно виправдане.
  • Інституційні оператори. Резервування є обов'язковим не лише з економічних міркувань, а й з огляду на внутрішні політики доступності та відповідальності перед делегаторами.

Резервування через hot spare не є єдиним допустимим підходом. Деякі оператори обирають стратегію «швидкого відновлення» — надійний сервер без гарячого резерву, але з оптимізованою процедурою ресинхронізації (швидкі NVMe, попередньо завантажені snapshot-и, відпрацьований runbook). Цей підхід дешевший, але приймає на себе ризик тривалого простою. Вибір залежить від апетиту до ризику та розміру інфраструктури.

Джерела