Операційні вимоги для «Як перенести валідатор на новий сервер без втрати даних» перевірено 2 серпня 2026 року. Для production використовуйте тільки реліз Agave, рекомендований для конкретного кластера, і звіряйте параметри з agave-validator --help . Офіційні вимоги Anza на цю дату орієнтують операторів на Ubuntu 24.04, щонайменше 12 ядер/24 потоки, 256 ГБ RAM, окремі швидкі NVMe та симетричний канал від 2 Гбіт/с; це рекомендації, а не гарантія достатньої продуктивності.
Перенесення валідатора Solana на нове залізо — це стандартна інфраструктурна процедура, яка за правильного підходу не призводить до пропущених слотів, втрати identity або виключення з набору валідаторів. Нижче — повний операційний runbook із чіткими передумовами, командами, точками перевірки та шляхами відкату.
Середовище: Ubuntu 24.04 LTS, клієнт — Agave (офіційний валідатор Solana), кластер — mainnet-beta. Конкретну версію Agave перевірте в офіційному репозиторії безпосередньо перед початком роботи. Дата останньої перевірки процедури: верифікуйте актуальність команд у вихідному коді клієнта на момент виконання.
Коли потрібне перенесення
Міграція на новий сервер має сенс у таких випадках:
- Апгрейд заліза. Збільшення обсягу RAM, перехід на швидші NVMe, зміна процесора — все, що впливає на пропускну здатність snapshot-завантаження та час обробки слотів.
- Зміна дата-центру або хмарного провайдера. Покращення латентності до сусідніх валідаторів або зміна юридичної юрисдикції.
- Компрометація ОС. Підозра на несанкціонований доступ — у такому разі міграція поєднується з повним перевстановленням і аудитом.
- Знос накопичувачів. Зростання кількості помилок читання/запису в SMART або деградація IOPS.
- Перехід на іншу версію ОС. Наприклад, з 20.04 на 22.04, коли in-place upgrade неприпустимий для продакшен-вузла.
Екстрена міграція через відмову старого сервера виконується за тією ж процедурою, але без можливості попереднього синхронізування ledger — у такому разі ви покладаєтесь на завантаження snapshot.
Підготовка нового сервера
Передумови: новий сервер має відповідати або перевищувати мінімальні вимоги до валідатора Solana для обраного кластера. Перевірте актуальні вимоги в офіційній документації — вони змінюються з ростом ledger.
Крок 1. Базове налаштування ОС
- Оновіть систему:
sudo apt update && sudo apt upgrade -y
- Встановіть необхідні залежності:
sudo apt install -y build-essential pkg-config libssl-dev libudev-dev curl jq
- Налаштуйте параметри ядра для роботи з великою кількістю відкритих файлів та мережевих з'єднань. Додайте до
/etc/sysctl.conf:
net.core.rmem_max=134217728
net.core.wmem_max=134217728
net.ipv4.tcp_rmem=4096 87380 134217728
net.ipv4.tcp_wmem=4096 65536 134217728
Застосуйте: sudo sysctl -p
Крок 2. Встановлення клієнта Agave
Завантажте бінарний файл актуальної стабільної версії з офіційного репозиторію Solana. Не використовуйте незатверджені релізи або гілки master для продакшен-валідатора.
Крок 3. Налаштування фаєрвола
Валідатору потрібен вхідний трафік на порту 8000–10000 (TCP та UDP — точний діапазон залежить від конфігурації, перевірте прапорці --dynamic-port-range). Також відкрийте SSH-порт. Усе інше — закрити.
Очікуваний результат: новий сервер готовий до запуску клієнта, але ще не запущений і не прив'язаний до identity.
Перенесення identity та vote ключів
Ризик: втрата або витік keypair-файлів призводить до незворотної втрати контролю над валідатором або голосуючим акаунтом.
Крок 1. Створіть тимчасову директорію на новому сервері з обмеженими правами:
mkdir -m 700 ~/validator-keys
Крок 2. Скопіюйте keypair-файли зі старого сервера через SSH із прямою передачею в пам'ять (без проміжного запису на диск старого сервера в відкритому вигляді, якщо використовуєте шифрування):
scp old-server:~/validator/identity.json ~/validator-keys/identity.json
scp old-server:~/validator/vote-account-keypair.json ~/validator-keys/vote-account-keypair.json
Якщо ви використовуєте апаратний HSM або ключі зберігаються поза файловою системою — дотримуйтесь процедури вашого HSM-провайдера. Цей runbook охоплює лише файлові keypair.
Крок 3. Перевірте, що скопійовані ключі збігаються з оригіналами:
На старому сервері:
solana-keygen pubkey ~/validator/identity.json
На новому сервері:
solana-keygen pubkey ~/validator-keys/identity.json
Публічні ключі мають збігатися повністю. Те саме повторіть для vote-account-keypair.
Крок 4. Встановіть права доступу:
chmod 600 ~/validator-keys/*.json
Шлях відкату: якщо ключі не збігаються, негайно видаліть скопійовані файли на новому сервері (shred -u ~/validator-keys/*.json) і повторіть копіювання. Не продовжуйте міграцію з невідповідними ключами.
Перенесення ledger або завантаження snapshot
Є два підходи. Вибір залежить від розміру ledger, ширини каналу між серверами та допустимого часу простою.
Варіант A: Копіювання ledger зі старого сервера
Підходить, коли між серверами є швидкий канал (10 Gbps+), а розмір ledger дозволяє завершити передачу за прийнятний час.
Крок 1. Зупиніть валідатор на старому сервері:
sudo systemctl stop agave-validator
Це необхідно, щоб ledger перебував у консистентному стані. Не копіюйте ledger працюючого валідатора — ви отримаєте пошкоджену копію.
Крок 2. Використайте rsync з контрольною сумою:
rsync -avz --checksum old-server:~/validator/ledger/ ~/validator/ledger/
Прапорець --checksum гарантує перевірку кожного файлу, а не лише розміру та часової мітки. Це повільніше, але надійніше для NVMe-ledger з великою кількістю дрібних файлів.
Очікуваний результат: повна копія ledger на новому сервері в ідентичній структурі директорій.
Варіант B: Завантаження snapshot з публічного джерела
Підходить, коли канал між серверами повільний, або старий сервер недоступний. Новий валідатор завантажить останній snapshot і відновить стан з нього.
Крок 1. Дізнайтеся адресу snapshot-джерела:
solana gossip --rpc-url https://api.mainnet-beta.solana.com | grep snapshot
Або використайте відоме snapshot-джерело з вашої інфраструктури. Якщо ви налаштовували власне snapshot-джерело, використовуйте його адресу.
Крок 2. Запустіть валідатор із вказанням snapshot:
agave-validator --identity ~/validator-keys/identity.json --vote-account ~/validator-keys/vote-account-keypair.json --ledger ~/validator/ledger --known-validator ADDRESS --only-known-rpc --snapshot-url SNAPSHOT_URL
Замініть ADDRESS на pubkey відомого валідатора, а SNAPSHOT_URL — на адресу snapshot-джерела.
Ризик: завантаження snapshot займає від кількох хвилин до години залежно від розміру та ширини каналу. Під цього часу валідатор не голосує.
Перевірка: у журналах має з'явитися рядок типу Snapshot load complete з вказанням слота.
Переключення трафіку на новий вузол
Важливо: не запускайте два валідатори з однаковим identity одночасно. Це призведе до дублювання голосів, конфліктів у консенсусі та потенційного виключення.
Крок 1. Переконайтеся, що старий валідатор зупинений:
sudo systemctl stop agave-validator
sudo systemctl disable agave-validator
Вимкнення сервісу запобігає випадковому перезапуску після перезавантаження старого сервера.
Крок 2. Запустіть валідатор на новому сервері:
Якщо ви використовуєте systemd (рекомендовано), створіть юніт-файл /etc/systemd/system/agave-validator.service з правильним шляхом до бінарника, ключів та ledger. Потім:
sudo systemctl daemon-reload
sudo systemctl enable agave-validator
sudo systemctl start agave-validator
Крок 3. Оновіть DNS, якщо валідатор доступний за доменним ім'ям:
Змініть A-запис на IP нового сервера. Врахуйте TTL — якщо він великий (наприклад, 3600 секунд), заздалегідь зменште його до 60 секунд за кілька годин до міграції.
Крок 4. Якщо ви використовуєте статичний IP-переназначення:
У деяких хмарних провайдерів можна відв'язати плаваючий IP від старого сервера і прив'язати до нового. Це дає миттєве переключення без очікування DNS-пропагації.
Очікуваний результат: новий валідатор підключається до кластера, починає отримувати слоти та голосувати.
Перевірка працездатності після перенесення
Виконайте всі перевірки послідовно. Не вважайте міграцію успішною, поки не пройдено кожну точку.
1. Перевірка статусу голосування:
solana vote-account ~/validator-keys/vote-account-keypair.json
Зверніть увагу на:
— root slot має зростати.
— skip rate має бути близьким до нуля (допустимі поодинокі пропуски під перші хвилини після запуску).
— Валідатор не має бути в статусі delinquent.
2. Перевірка журналів:
sudo journalctl -u agave-validator -f
Шукайте:
— Рядки voted for slot — підтвердження голосування.
— Відсутність Error або PANIC.
— Наявність bank-frozen — підтвердження успішного оброблення епохи.
3. Перевірка підключення до сусідів:
solana gossip
Валідатор має показувати активні з'єднання з іншими вузлами кластера. Якщо сусідів мало або немає — перевірте фаєрвол та мережеву маршрутизацію.
4. Моніторинг skip rate протягом першої години:
Протягом першої години після запуску skip rate може бути трохи підвищеним через ініціалізацію. Якщо через 30–60 хвилин skip rate не знижується нижче 1–2% — це привід для діагностики: перевірте завантаження CPU, IOPS накопичувача та мережеву латентність.
Шлях відкату: якщо новий сервер показує критичні проблеми (постійні PANIC, skip rate вище 10%, неможливість завантажити snapshot), зупиніть його і поверніть сервіс на старий сервер. Для цього переведіть IP назад, запустіть sudo systemctl enable agave-validator && sudo systemctl start agave-validator на старому сервері. Якщо ledger на старому сервері не змінювався після зупинки — відновлення буде миттєвим.
Декомісія старого сервера
Не поспішайте видаляти дані зі старого сервера. Залиште його як резервну інстанцію щонайменше на 24–48 годин після стабільної роботи нового вузла.
Крок 1. Переконайтеся, що новий валідатор стабільний:
- Skip rate нижче 2% протягом останніх 6 годин.
- Жодних PANIC або перезапусків сервісу.
- Root slot зростає відповідно до очікуваного темпу кластера.
Крок 2. Видаляйте ключі зі старого сервера:
Попередження: ця дія незворотна. Після видалення keypair-файлів відновлення можливе лише з резервної копії.
shred -u ~/validator/identity.json
shred -u ~/validator/vote-account-keypair.json
Використовуйте shred, а не rm — це перезаписує дані перед видаленням, що ускладнює відновлення з накопичувача.
Крок 3. Видаліть ledger:
rm -rf ~/validator/ledger
Якщо накопичувач буде переданий іншому користувачу або утилізований — виконайте повне стирання всього диска (shred на рівні блочного пристрою або криптографічне стирання, якщо підтримується).
Крок 4. Відключіть моніторинг та алерти для старого сервера в вашій системі (Prometheus, Grafana, Datadog тощо).
Крок 5. Звільніть ресурси: скасуйте аренду сервера, звільніть плаваючий IP (якщо не використовується на новому сервері), видаліть DNS-записи, що вказували на старий сервер.
Очікуваний результат: старий сервер повністю декомісійований, ключі безпечно знищені, новий валідатор стабільно працює під тим самим identity.