Дата-центр — це фізична основа роботи валідатора Solana. Навіть ідеально налаштований вузол не виконуватиме свої обовʼязки, якщо інфраструктура навколо нього не відповідає вимогам кластера. Цей матеріал систематизує критерії вибору, перелік перевірок перед підписанням контракту та типові помилки, які призводять до простоїв і втрати стейку.

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

Ключові критерії вибору дата-центру

Географічне розташування відносно кластера

Solana працює з цільовим часом слоту близько 400 мс, і затримка між валідаторами безпосередньо впливає на консенсус. Дата-центр має забезпечувати мінімальну мережеву відстань до основної маси валідаторів кластера. Для mainnet-beta це переважно Північна Америка та Західна Європа.

Практична перевірка: перед укладанням контракту запустіть трасування від тестової машини в обраному дата-центрі до кількох відомих валідаторів кластера. Орієнтовний показник — медіанна RTT до більшості топ-валідаторів не гірша за 80–120 мс. Точне значення залежить від поточного розподілу кластера, тому його треба перевірити самостійно на момент вибору.

Надійність живлення та резервування

Валідатор, який втрачає живлення, перестає голосувати та пропускає слоти. Мінімальні вимоги до інфраструктури живлення дата-центру:

  • Подвійне живлення (2N або N+1) — наявність двох незалежних вводів електроживлення від різних підстанцій.
  • Дизель-генератори з автономністю — паливний запас має забезпечувати роботу не менше 24–48 годин без дозаправки.
  • UPS на кожній стійці — безперебійники мають перекривати час запуску генераторів (зазвичай 10–30 секунд).
  • Історія інцидентів — запросіть у провайдера звіти про відключення живлення за останні 2–3 роки. Якщо таких звітів немає або їх відмовляються надавати — це сигнал.

Захист від DDoS на рівні мережі

Валідатори Solana є публічними вузлами з відкритими TCP-портами (за замовчуванням 8000–8020 для Gossip, 8899 для RPC). Це робить їх ціллю для volumetric та application-layer атак. Дата-центр має надавати:

  • Scrubbing-центр на периметрі — фільтрацію трафіку до того, як він досягне вашого сервера. Перевірте, чи scrubbing активний за замовчуванням, чи вимагається окрема активація.
  • Чорнову пропускну здатність (oversubscription) — зʼясуйте співвідношення заявленої до реальної пропускної здатності на вашому порту. Ідеально — 1:1, допустимо — не гірше за 1:4.
  • Можливість швидкого null-routing — ви або провайдер маєте мати змогу миттєво відключити атакований IP без перезавантаження сервера.

Підтримка IPv4 та IPv6

Solana-кластер активно використовує обидва протоколи. Відсутність IPv6 обмежує можливість зʼєднання з частиною валідаторів і може погіршити маршрутизацію. Переконайтеся, що провайдер видає IPv4-адресу без додаткових платежів і надає IPv6-підмережу (мінімум /64). Перевірте, чи не заблоковано вихідний трафік на нестандартних портах — деякі провайдери фільтрують їх за замовчуванням.

Провайдери: що перевірити перед контрактом

Перед підписанням угоди виконайте цілеспрямовану перевірку. Це не загальні питання з чек-листа, а конкретні кроки, які економлять години діагностики в майбутньому.

  • SLA на доступність електроживлення та мережі — шукайте не менше ніж 99,99% (приблизно 52 хвилини простою на рік). Читайте штрафні санкції: часто вони обмежені кредитами на послуги, а не реальними виплатами.
  • Процедура remote hands — хто фізично натискає кнопку перезавантаження, замінює диск або підключає KVM? Чи включена ця послуга в контракт? Який час реакції (зазвичай 15–30 хвилин для premium-підтримки)?
  • Політика щодо власного обладнання (colocation) — чи допускається розміщення ваших серверів? Які обмеження на вагу, глибину стійки, споживання на одиницю?
  • Мережева нейтральність — чи провайдер не обмежує трафік до певних ASN або не пріоритезує власні сервіси за ваш рахунок?
  • Умови розірвання та міграції — який термін повідомлення про вихід? Чи є штраф за дострокове розірвання? Чи допомагають з фізичним вивезенням обладнання?
  • Аудиторські звіти (SOC 2 Type II, ISO 27001) — наявність звіту не гарантує безпеку, але його відсутність у великого провайдера — червоний прапор.

Обовʼязково замовте тестовий стенд на 1–2 тижні перед основним розгортанням. Розгорніть на ньому повноцінний вузол і спостерігайте за стабільністю зʼєднання, температурою та відсутністю несподіваних перезавантажень.

Фізичний доступ та апаратна заміна

Апаратні відмови — не питання «чи станеться», а «коли». Диск виходить з ладу, памʼять дає помилки, материнська плата згорає. Ваша готовність до цих сценаріїв визначає час простою.

Стратегія remote hands. У більшості випадків ви не матимете фізичного доступу до сервера 24/7. Remote hands-спеціаліст дата-центру — це ваша єдина фізична точка контакту. Переконайтеся, що:

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

Процедура заміни диска. Для валідатора Solana зазвичай використовуються дві конфігурації: монолітний NVMe-диск під леджер та RAID-масив. У першому випадку заміна диска означає повне відновлення з моментального знімка (snapshot) або синхронізацію з кластера з нуля — це години або доба. У другому — заміна одного диска в масиві з подальшою реконструкцією. Вибір конфігурації визначає ваш план відновлення, і його треба продумати до розгортання.

KVM-доступ. Переконайтеся, що у вас є IPMI, iLO або аналогічний out-of-band-доступ до сервера, незалежний від основної ОС. Якщо ОС зависне або мережевий інтерфейс буде скинутий, без KVM ви втратите контроль над машиною до приїзду інженера.

Типові помилки при виборі дата-центру

  • Вибір виключно за ціною. Дешевий колокаційний майданчик зазвичай економить на резервуванні живлення, охолодженні або мережевій звитязі. Один годинний простій через відключення електрики коштує більше, ніж річна різниця в тарифі.
  • Ігнорування реального oversubscription мережі. Заявлені «1 Gbps» або «10 Gbps» не означають гарантованої пропускної здатності. Якщо порт розділений на 10 клієнтів, під час пікового навантаження ви отримаєте лише частину.
  • Розміщення в дата-центрі без scrubbing-захисту. DDoS-атака на сусідній вузол у тій самій підмережі може паралізувати ваш валідатор навіть без прямої атаки на вас.
  • Відсутність запасних компонентів на майданчику. Замовлення диска з доставкою займає від кількох годин до кількох днів. За цей час валідатор не голосує і втрачає стейк.
  • Довіра до маркетингових характеристик без перевірки. «Tier III» на сайті провайдера не є сертифікатом. Запитайте копію сертифіката Uptime Institute або іншого незалежного аудитора.
  • Розміщення в юрисдикції з нестабільною інфраструктурою. Регулярні відключення світла, обмеження на імпорт обладнання або ризик відключення країни від міжнародних магістралей — фактори, які не компенсуються жодним SLA.

Після обрання дата-центру та розгортання валідатора наступний логічний крок — планування резервування інфраструктури: hot spare та автоматичний failover, щоб одиночна апаратна відмова не перетворювалася на тривалий простої.

Джерела