Валідатори та інфраструктура Solana: повний операційний довідник

Цей довідник містить операційні процедури для розгортання, обслуговування та відновлення валідаторів Solana. Матеріал орієнтований на інженерів, які керують інфраструктурою безпосередньо: від вибору заліза до реагування на інциденти. Кожен розділ містить конкретні кроки, перевірки та межі застосування.

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

Сервер, мережа та архітектура

Вимоги до сервера валідатора Solana

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

Базові параметри для mainnet-beta (перевірте актуальні вимоги у репозиторії Agave перед розгортанням):

• CPU: 12+ фізичних ядер, 16+ рекомендовано
• RAM: 128 ГБ мінімум, 256 ГБ для комфортного запасу під час пікових навантажень
• Накопичувач: від 2 ТБ NVMe для ledger та accounts
• ОС: Ubuntu 24.04 LTS або 24.04 LTS (amd64)

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

Bare metal чи орендований сервер для валідатора

Для продакшн-валідатора на mainnet-beta перевага віддається bare metal. Причина — детермінованість вводу-виводу: віртуальні машини додають шар гіпервізора, який непередбачувано впливає на latency дискових операцій. Навіть незначні затримки у зчитуванні accounts збільшують skip rate.

Орендований виділений сервер підходить, якщо провайдер гарантує доступ до NVMe без шару емуляції та фіксовану прив'язку ядер до вузла. Перевірте у провайдера, чи використовується pass-through диска до PCIe слота.

Оптимальний CPU для валідатора Solana

Agave валідатор написаний на Rust і активно використовує багатопотоковість. Ключові фактори вибору CPU:

• Частота на одне ядро: впливає на швидкість обробки окремих транзакцій
• Кількість фізичних ядер: дозволяє паралельно обробляти етапи пайплайну (receive, verify, process, bank)
• Розмір L3-кешу: великий кеш зменшує звернення до пам'яті при роботі з accounts

Гіперпоточність (SMT/HT) зазвичай вимикають у продакшні: фізичні ядра дають більш стабільну latency. Конкретні моделі залежать від доступності у вашому дата-центрі — орієнтуйтеся на високу базову частоту та мінімум 12 ядер.

NVMe-накопичувачі для валідатора: вибір та налаштування

NVMe — критичний компонент. Валідатор постійно читає та записує accounts, snapshots та ledger.

Критерії вибору:

• Інтерфейс: PCIe Gen4 або Gen5 — різниця у пропускній здатності суттєва при відновленні з snapshot
• Endurance: орієнтуйтеся на DWPD не нижче 1 для робочого навантаження
• Форм-фактор: U.2 або EDSFF (E3.S/E1.S) для серверних шасі

Налаштування:

1. Перевірте, що диск працює в режимі NVMe, а не SATA emulation
2. Вимкніть сторожовий таймер power management для стабільності: nvme set-feature -f 0x0a -v 0 /dev/nvme0
3. Форматуйте з аліасом для зменшення write amplification: mkfs.ext4 -O large_file -E stride=32,stripe-width=32 /dev/nvme0n1p1

Розділяти ledger та accounts на різні фізичні диски має сенс при інтенсивному навантаженні на RPC-вузли. Для валідатора достатньо одного високопродуктивного диска з розділами.

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

Solana використовує протокол Turbine для трансляції блоків та Gossip для обміну метаданими. Мережеві вимоги:

• Пропускна здатність: мінімум 1 Гбіт/с, рекомендовано 10 Гбіт/с — під час пікових сплесків транзакцій вузол отримує значний обсяг даних
• Latency: важлива не абсолютна величина, а стабільність (jitter). Коливання понад 5 мс між сусідніми вузлами помітно впливають на синхронізацію
• Порти (UDP та TCP): 8000–8020 для Gossip та Turbine, 8900 для RPC (якщо увімкнено)

Перевірте, що ваш провайдер не обмежує UDP-трафік на цих портах — це поширена причина проблем із Gossip.

Вибір дата-центру для розміщення валідатора

Географія впливає на latency до інших валідаторів. Solana не має фіксованої «столиці» мережі, але більшість вузлів зосереджена у певних регіонах. Орієнтуйтеся на дата-центри, де вже розміщено кілька активних валідаторів.

Критерії вибору:

• Наявність прямих peering-з'єднань з основними мережевими провайдерами
• Можливість отримати dedicated 10 Гбіт/с порт без oversubscription
• Відсутність обмежень на UDP-трафік
• Фізична безпека та доступ до колокації для заміни обладнання

Резервування інфраструктури: hot spare та автоматичний failover

Hot spare — це повністю налаштований вузол, який готовий прийняти навантаження, але не бере участі в консенсусі. Для Solana це означає:

• Ідентичне залізо в тому ж дата-центрі
• Синхронізовані ключі (identity та vote) на зашифрованому носії
• Актуальний snapshot та ledger

Автоматичний failover у Solana ускладнений тим, що два вузли з однаковим identity не можуть працювати одночасно. Практична схема: моніторинг виявляє відмову основного вузла, зупиняє його (через remote management типу IPMI), і лише після цього запускає hot spare. Ручне підтвердження перед переключенням зменшує ризик split-brain.

Архітектура RPC-вузла: призначення, навантаження, масштабування

RPC-вузол надає API для взаємодії з блокчейном. Він відрізняється від валідатора: не бере участі в консенсусі, але зберігає повний стан мережі.

Навантаження на RPC-вузол залежить від кількості клієнтів та типів запитів. Найважчі — запити, що читають багато акаунтів (наприклад, getProgramAccounts з фільтрами).

Масштабування:

• Вертикальне: більше RAM для кешування accounts, швидший NVMe
• Горизонтальне: кілька RPC-вузлів за load balancer з ротацією запитів

Розділяйте валідатор та RPC на різні фізичні машини — RPC-навантаження не повинно впливати на консенсус.

Мережева безпека валідатора: firewall, SSH, захист доступу

Базові правила:

• Firewall: дозволіть лише UDP/TCP 8000–8020 для Gossip/Turbine, TCP 22 для SSH (обмежений за IP), TCP 8900 для RPC (якщо потрібно)
• SSH: ключовий доступ лише, заборона паролів, нестандартний порт рекомендовано
• Ключі: identity та vote keypair зберігайте зашифрованими, розшифровуйте лише під час запуску або через keyring

Не відкривайте RPC-порт (8900) на валідаторі в інтернет — використовуйте окремий RPC-вузол або тунель.

Розподілена архітектура: кілька вузлів, балансування, географія

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

Балансування запитів між RPC-вузлами виконуйте на рівні L4 (TCP/UDP) — L7 не підходить через специфіку протоколу. Для публічних RPC-сервісів використовуйте rate limiting на рівні reverse proxy перед вузлами.

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

Як підготувати Linux для валідатора Solana

Середовище: Ubuntu 24.04 LTS (amd64), свіжовстановлена, без додаткових сервісів.

Кроки підготовки:

1. Оновіть систему: sudo apt update && sudo apt upgrade -y
2. Встановіть залежності: sudo apt install -y build-essential pkg-config libssl-dev libudev-dev
3. Налаштуйте sysctl для мережі:
   • net.core.rmem_max = 134217728
   • net.core.rmem_default = 16777216
   • net.ipv4.udp_rmem_min = 8192
4. Збільште ліміти файлових дескрипторів: у /etc/security/limits.conf додайте * soft nofile 1000000 та * hard nofile 1000000
5. Вимкніть swap: sudo swapoff -a та закоментуйте рядки swap у /etc/fstab

Перевірка: ulimit -n має показувати 1000000 після повторного входу.

Як безпечно створити identity та vote account

Ключі валідатора — це точка відмови. Втрата identity keypair означає втрату валідатора.

Безпечна процедура:

1. Генеруйте ключі на локальній машині, не на сервері: solana-keygen new -o ~/validator-identity.json
2. Генеруйте vote account: solana-keygen new -o ~/validator-vote.json
3. Створіть authorized voter (може збігатися з identity або бути окремим): solana-keygen new -o ~/validator-authority.json
4. Зробіть зашифровані резервні копії всіх трьох keypair-файлів на окремі носії
5. Перенесіть ключі на сервер через зашифрований канал (scp з ключовою автентифікацією)
6. Встановіть права доступу: chmod 600 *.json

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

Як перевірити identity, vote account та authorized voter перед запуском

Перед створенням vote account у блокчейні перевірте відповідність ключів:

1. Отримайте публічний ключ identity: solana-keygen pubkey ~/validator-identity.json
2. Отримайте публічний ключ vote account: solana-keygen pubkey ~/validator-vote.json
3. Отримайте публічний ключ authorized voter: solana-keygen pubkey ~/validator-authority.json
4. Запишіть ці три адреси та перевірте, що вони відповідають вашим резервним копіям

Створення vote account (виконується один раз):

1. solana create-vote-account ~/validator-vote.json ~/validator-identity.json ~/validator-authority.json --commission 100
2. Перевірте створення: solana vote-account ~/validator-vote.json

Очікуваний результат: команда показує vote account з вашим identity як validator та correct authorized voter.

Як встановити Agave validator крок за кроком

Клієнт: Agave (форк Solana Labs validator). Перевірте актуальну стабільну версію у репозиторії Agave перед встановленням.

1. Встановіть binaries через agave-install:
   • sh -c "$(curl -sSfL https://release.anza.xyz/stable/install)"
2. Додайте до PATH: export PATH="$HOME/.local/share/solana/install/active_release/bin:$PATH"
3. Перевірте версію: agave-validator --version
4. Створіть робочий каталог: mkdir -p ~/validator/ledger ~/validator/snapshots
5. Змонтуйте NVMe до ~/validator/ledger (або налаштуйте відповідний розділ)

Очікуваний результат: agave-validator --version показує встановлену версію Agave.

Як працюють ledger та snapshots у Solana

Ledger — це послідовний лог усіх слотів від генезису. Повний ledger mainnet-beta займає терабайти, тому валідатори використовують snapshots.

Snapshot — це стиснений зріз повного стану мережі (всі accounts та їхні дані) на певний слот. При старті валідатор:

1. Завантажує останній доступний snapshot
2. Відтворює ledger починаючи з слота snapshot до поточного
3. Після синхронізації починає брати участь у консенсусі

Snapshots генеруються періодично (кожні кілька слотів). Розмір snapshot на mainnet-beta — десятки гігабайтів, тому швидкість NVMe критична для завантаження.

Як налаштувати systemd service для валідатора

Створіть файл /etc/systemd/system/agave-validator.service:

[Unit]
Description=Solana Validator
After=network.target
[Service]
Type=simple
User=solana
LimitNOFILE=1000000
Environment="PATH=/home/solana/.local/share/solana/install/active_release/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin"
ExecStart=/home/solana/.local/share/solana/install/active_release/bin/agave-validator \
--identity /home/solana/validator-identity.json \
--vote-account /home/solana/validator-vote.json \
--ledger /home/solana/validator/ledger \
--accounts /home/solana/validator/accounts \
--rpc-port 8899 \
--no-voting \
--full-rpc-api
Restart=on-failure
RestartSec=10
[Install]
WantedBy=multi-user.target

Параметр --no-voting додається для первинної синхронізації. Після повного завантаження його треба прибрати.

Активація: sudo systemctl daemon-reload && sudo systemctl enable agave-validator

Конфігураційний файл валідатора: ключові параметри

Замість довгих аргументів командного рядка використовуйте конфігураційний файл (формат TOML). Створіть ~/validator/config.toml:

• identity-path: шлях до identity keypair
• vote-account-path: шлях до vote account keypair
• ledger-path: каталог ledger
• accounts-path: каталог accounts (окремо від ledger для кращої продуктивності)
• rpc-port: порт RPC (якщо потрібен локально)
• snapshot-interval-slots: частота генерації snapshot (за замовчуванням підходить для більшості випадків)
• limit-ledger-size: максимальний розмір ledger у GiB (залежить від вашого диска)
• known-validators: список pubkey надійних валідаторів для початкового з'єднання

Запуск з конфігом: agave-validator --config ~/validator/config.toml

Як запустити валідатор на mainnet-beta

Передумови: підготовлений сервер, встановлений Agave, створені ключі, vote account існує в блокчейні.

1. Вкажіть кластер: solana config set --url https://api.mainnet-beta.solana.com
2. Перевірте з'єднання: solana slot — має показати поточний слот
3. Запустіть з --no-voting для первинної синхронізації: sudo systemctl start agave-validator
4. Моніторьте прогрес: journalctl -u agave-validator -f
5. Після досягнення поточного слота зупиніть, приберіть --no-voting з конфігурації та перезапустіть

Очікуваний результат: у логах з'являється «voting», skip rate стабілізується.

Як налаштувати snapshot-джерело та генератор

За замовчуванням валідатор завантажує snapshots з інших вузлів через Gossip. Для прискорення синхронізації можна вказати явне джерело:

• --snapshots /path/to/local/snapshots: використовувати локальні snapshot-файли
• --genesis /path/to/genesis.bin: для повної синхронізації з генезису (не рекомендовано на mainnet)

Генерація snapshot на працюючому вузлі відбувається автоматично. Щоб створити snapshot вручну (наприклад, для міграції): solana-ledger tool create-snapshot --ledger /path/to/ledger <slot> /path/to/output

Перевірте актуальний синтаксис команди у документації Agave — інтерфейс може змінюватися.

Як перенести валідатор на новий сервер без втрати даних

Передумови: новий сервер підготовлений, Agave встановлено, ключі перенесено.

1. Зупиніть валідатор на старому сервері: sudo systemctl stop agave-validator
2. Створіть snapshot на старому сервері
3. Перенесіть snapshot та останній ledger на новий сервер (rsync через SSH або фізичний носій для великих обсягів)
4. Перевірте цілісність: розмір файлів та логи завантаження
5. Запустіть валідатор на новому сервері
6. Перевірте, що vote account показує новий identity у блокчейні

Ризик: якщо обидва сервери запущені з однаковим identity одночасно, мережа може їх покарати. Обов'язково зупиняйте старий вузол перед стартом нового.

Оновлення, міграція та відкат

Як оновити валідатор без зайвого простою

Solana оновлюється через feature activations — нові функції активуються у певному слоті. Валідатор повинен мати версію, яка підтримує ці функції до моменту активації.

Процедура оновлення:

1. Перевірте, які feature activations заплановані: solana feature status
2. Перевірте, чи підтримує нова версія Agave ці функції
3. Оновіть binaries: agave-install update
4. Перевірте версію: agave-validator --version
5. Перезапустіть сервіс: sudo systemctl restart agave-validator

Час простою — кілька секунд (час перезапуску процесу). Snapshot та ledger залишаються сумісними.

Як підготувати план відкату валідатора

План відкату потрібен перед кожним оновленням. Елементи:

• Збереження поточних binaries: скопіюйте каталог ~/.local/share/solana/install/active_release до резервної копії
• Фіксація версії: запишіть поточну версію та git commit hash
• Перевірка snapshot: переконайтеся, що snapshot створено перед оновленням
• Тест відкату: на testnet перевірте, що старі binaries можуть завантажити поточний snapshot
• Часове вікно: якщо оновлення неспішне, плануйте відкат протягом перших 10–15 хвилин після перезапуску

Як перевірити нову версію Agave перед оновленням

Середовище: testnet або devnet, не mainnet-beta.

1. Розгорніть тестовий вузол на testnet з тією ж конфігурацією
2. Оновіть binaries до цільової версії
3. Запустіть і спостерігайте за логами: відсутність panic, нормальний skip rate, стабільне голосування
4. Перевірте, що вузол успішно обробляє транзакції
5. Залиште тестовий вузол працювати щонайменше кілька годин перед оновленням mainnet

Як виконати відкат валідатора до попередньої версії

Попередження: відкат під час активної feature activation може призвести до delinquent статусу. Виконуйте відкат лише якщо нова версія несправна і оновлення ще не стало обов'язковим.

Кроки:

1. Зупиніть валідатор: sudo systemctl stop agave-validator
2. Відновіть старі binaries з резервної копії
3. Перевірте версію: agave-validator --version
4. Запустіть валідатор
5. Моніторьте логи на предмет помилок несумісності snapshot

Якщо snapshot несумісний зі старою версією, доведеться чекати створення нового snapshot або синхронізуватися з більш раннього слота.

Як мігрувати з Solana Labs на Agave клієнт

Agave — це форк Solana Labs validator, який став основним клієнтом. Міграція зазвичай зводиться до заміни binaries:

1. Зупиніть валідатор
2. Встановіть Agave через офіційний інсталятор
3. Перевірте, що конфігураційний файл сумісний (більшість параметрів не змінилися)
4. Запустіть валідатор

Перевірте у реліз-нотах Agave, чи є breaking changes у конфігурації для вашої версії. Якщо є — внесіть зміни перед запуском.

Як налаштувати автоматичне оновлення валідатора

Автоматичне оновлення валідатора на mainnet-beta — ризикована практика. Рекомендований підхід:

• Автоматичне оновлення binaries без автоматичного перезапуску
• Сигнал (alert) при наявності нової версії
• Ручне підтвердження перезапуску після перевірки на testnet

Якщо ви все ж налаштовуєте повну автоматизацію, використовуйте agave-install update у cron з перевіркою версії та перезапуском лише за умови, що testnet-вузол вже працює на цій версії без проблем.

Як тестувати оновлення на testnet та devnet

testnet наближені до mainnet за навантаженням, devnet — для розробників. Для тестування оновлень використовуйте testnet:

1. Запустіть валідатор на testnet з тією ж конфігурацією, що й mainnet
2. Оновіть до цільової версії
3. Спостерігайте мінімум 2–4 години: skip rate, memory usage, відсутність panic у логах
4. Перевірте, що вузол не відстає за слотами

devnet підходить для швидкої перевірки запуску, але не відображає реальне навантаження.

Як працювати з резервним вузлом під час оновлення

Схема з hot spare дозволяє мінімізувати ризик:

1. Оновіть резервний вузол першим
2. Перевірте його стабільність на testnet або як non-voting вузол на mainnet
3. Після підтвердження стабільності оновіть основний вузол
4. Якщо основний вузол не піднімається після оновлення — переключте на резервний

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

Як обробити невдале оновлення: діагностика та виправлення

Симптоми невдалого оновлення:

• Валідатор не стартує — перевірте логи systemd: journalctl -u agave-validator -n 100
• Panic при завантаженні snapshot — ймовірно, несумісність формату
• Високий skip rate після оновлення — перевірте метрики та конфігурацію

Порядок дій:

1. Зупиніть валідатор
2. Збережіть логи для аналізу
3. Спробуйте відкат (якщо дозволяє стан мережі)
4. Якщо відкат неможливий — перевірте, чи є patch-реліз, що виправляє проблему
5. Зверніться до каналу валідаторів з описом проблеми та логами

Як мігрувати ledger та accounts між клієнтами

Якщо ви переходите між клієнтами (наприклад, до альтернативної реалізації), формат ledger та accounts може відрізнятися. Загальний підхід:

1. Перевірте документацію цільового клієнта щодо сумісності форматів
2. Якщо формати несумісні, використовуйте інструменти міграції (якщо надаються)
3. Альтернатива: синхронізуйте з нуля з snapshot цільового клієнта, якщо такі є доступні

Не намагайтеся конвертувати файли вручну — це майже гарантовано призведе до пошкодження стану.

Моніторинг та аварійне відновлення

Чому валідатор став delinquent: причини та рішення

Delinquent статус означає, що валідатор не голосував достатньо слотів протягом епохи. Причини:

• Відставання за слотами: повільний диск, недостатньо CPU, мережеві проблеми
• Зупинка процесу: OOM killer, panic, помилка конфігурації
• Несумісна версія: валідатор не підтримує активовану feature
• Проблеми з Gossip: ізоляція від мережі, блокування UDP

Рішення: діагностуйте конкретну причину за логами та метриками, усуньте її, перезапустіть валідатор. Delinquent статус знімається автоматично після відновлення стабільного голосування.

Як аналізувати skip rate валідатора

Skip rate — відсоток слотів, де валідатор не проголосував. Перевірте:

1. solana validator-info <identity-pubkey> — базова статистика
2. Логи: шукайте «skip» для конкретних слотів
3. Кореляція з навантаженням: чи збігається високий skip rate з піками CPU або дискового вводу-виводу

Нормальний skip rate на mainnet-beta — зазвичай нижче 5%. Значення вище 10% свідчить про проблеми з інфраструктурою.

Моніторинг валідатора Solana: метрики, інструменти, дашборди

Ключові метрики для моніторингу:

• skip_rate: відсоток пропущених слотів
• slot_height: поточний слот валідатора порівняно з мережею
• root_slot: останній фіналізований слот
• cpu_usage, memory_usage: споживання ресурсів
• disk_iops, disk_latency: навантаження на NVMe
• gossip_peers: кількість з'єднань через Gossip

Інструменти:

• Agave експортує метрики у форматі Prometheus (--metrics-config)
• Grafana для візуалізації (існують готові дашборди від спільноти)
• Alertmanager для сповіщень

Налаштуйте збір метрик з інтервалом 10–15 секунд — частіше створює зайве навантаження.

Аварійне відновлення валідатора: стратегії та кроки

Стратегії відновлення залежать від типу відмови:

• Програмна відмова: перезапуск сервісу, відкат версії
• Відмова диска: заміна диска, відновлення з snapshot
• Відмова сервера: переключення на hot spare
• Повна втрата даних: завантаження snapshot з зовнішнього джерела, повна ресинхронізація

Базовий порядок для повної відмови:

1. Оцініть масштаб проблеми за логами та моніторингом
2. Якщо сервер недоступний — переключте на hot spare
3. Якщо дані пошкоджено — завантажте останній валідний snapshot
4. Перевірте цілісність після відновлення
5. Проведіть post-mortem аналіз

Як налаштувати alerts та сповіщення для валідатора

Критичні alertи, які потребують негайного реагування:

• Валідатор зупинився (process down)
• Skip rate перевищує 10% протягом 5 хвилин
• Відставання за слотами більше ніж на 100
• Memory usage перевищує 90%
• Disk latency перевищує 10 мс
• Gossip peers впав нижче 20

Канали сповіщень: налаштуйте принаймні два незалежні канали (наприклад, Telegram та email). Перевірте, що alertи не дублюються через хибні налаштування порогів.

Як діагностувати snapshot failures

Симптоми: валідатор не створює snapshot або не може завантажити існуючий.

Діагностика:

1. Перевірте вільний простір на диску: df -h ~/validator/
2. Перевірте логи на предмет «snapshot» помилок
3. Перевірте права доступу до каталогу snapshots
4. Якщо завантаження з мережі не працює — перевірте Gossip з'єднання

Типова причина — нестача місця на диску. Snapshot потребує місця для тимчасових файлів під час створення. Залишайте мінімум 20% вільного простору.

Як аналізувати логи валідатора Solana

Логи валідатора інформативні, але об'ємні. Ключові патерни для пошуку:

• «panic»: критична помилка, потребує негайного втручання
• «error»: помилки, які не призводять до зупинки, але вказують на проблеми
• «skip»: пропущені слоти для голосування
• «snapshot»: статус створення та завантаження snapshot
• «gossip»: проблеми з мережевим з'єднанням

Команди для аналізу:

• journalctl -u agave-validator --since "1 hour ago" | grep -i "panic\|error"
• journalctl -u agave-validator -f для реального часу

Налаштуйте ротацию логів, щоб вони не заповнили диск: journalctl --vacuum-size=10G

Як відновити валідатор після повної втрати даних

Попередження: ця процедура призводить до тривалої ресинхронізації (від кількох годин до доби залежно від швидкості мережі та диска).

Кроки:

1. Підготуйте чистий диск з достатнім місцем
2. Перевірте наявність ключів (identity та vote) — без них відновлення неможливе
3. Отримайте snapshot з надійного джерела (інший ваш вузол або довірений оператор)
4. Розпакуйте snapshot у каталог ledger
5. Запустіть валідатор з --no-voting для синхронізації
6. Після досягнення поточного слота приберіть --no-voting та перезапустіть

Перевірка: після відновлення переконайтеся, що vote account показує правильний identity та нормальний skip rate.

Як працює система credits та root slot у Solana

Credits — це внутрішня одиниця обліку участі валідатора. Валідатор отримує credits за кожен успішний голос (vote). Кількість credits залежить від епохи та налаштувань мережі.

Root slot — це найвищий слот, який валідатор вважає фіналізованим. Root просувається вперед, коли достатня кількість валідаторів досягли консенсусу щодо цього слота.

Для моніторингу:

• Перевірте root slot: solana slot та порівняйте з solana block-height
• Відставання root slot від поточного слота мережі вказує на проблеми з синхронізацією

Incident runbook: типовий план реагування на інцидент валідатора

Цей runbook — шаблон для реагування. Адаптуйте його під вашу інфраструктуру.

Крок 1: Виявлення (0–2 хвилини)

• Отримайте alert з моніторингу
• Підтвердіть інцидент: перевірте статус сервісу та поточний слот

Крок 2: Оцінка (2–5 хвилин)

• Перевірте логи: journalctl -u agave-validator -n 200 --no-pager
• Визначте тип відмови: програмна, мережева, дискова, версійна
• Оцініть масштаб: чи впливає на голосування

Крок 3: Мітигація (5–15 хвилин)

• Програмна відмова: перезапуск сервісу
• Версійна проблема: відкат до останньої робочої версії
• Мережева проблема: перевірте firewall, Gossip peers, зв'язок з дата-центром
• Дискова проблема: перевірте місце, SMART-статус диска

Крок 4: Відновлення (15–60 хвилин)

• Якщо мітигація не допомогла — переключте на hot spare
• Якщо hot spare недоступний — завантажте snapshot та ресинхронізуйте
• Перевірте відновлення: skip rate, root slot, голосування

Крок 5: Post-mortem (протягом 24 годин)

• Зафіксуйте хронологію подій
• Визначте кореневу причину
• Сформулюйте дії для запобігання повторенню
• Оновіть runbook, якщо процедура була недосконалою

Джерела

• Anza: Agave Validator Requirements
• Anza: Setup an Agave Validator
• Anza: Validator Security Best Practices
• Anza Agave: Releases
• Anza: Install the Solana CLI
• Solana Documentation: Staking
• Solana Documentation: Stake Accounts