TL;DR
- Сначала выберите роль (full / light‑pruned / validator / RPC / archive) и рассчитайте CPU, RAM и NVMe под неё.
- Стабильность и задержка важнее «толстой» полосы; держите двух провайдеров и OOB‑канал.
- Харднинг ОС, firewall по умолчанию deny, для валидатора — HSM и sentry‑архитектура.
- Мониторьте лаг синхронизации, пиров, p95/p99, CPU/RAM/IOPS; алерты на оффлайн/консенсус/производительность.
- Масштабируйтесь вертикально для одиночных узлов и горизонтально для RPC/HA; держите runbook’и и тренируйте восстановление.
- Облако быстро стартует, но для IO‑интенсивных RPC/архива на горизонте 6–24 мес выгоднее «железо»/колокация.
Роли узлов — кратко
Понимание роли определяет требования к инфраструктуре:
- Полный узел — полная валидация и независимая проверка; опора децентрализации.
- Лёгкий/прудованный — сниженные требования к хранению; для кошельков и ограниченных сред.
- Валидатор (PoS) — участие в консенсусе; строгие требования к доступности, безопасности и ключам.
- RPC/инфраструктурный — API для dApp/кошельков; оптимизирован под пропускную способность и низкую задержку.
- Архивный — историческое состояние и сложные запросы; максимальные требования к хранилищу.
Вычисления и ОС
- CPU: x86‑64 с высокой производительностью на ядро; RPC выигрывает от большого числа ядер.
- RAM: ~8-16 ГБ для многих full; 32–128+ ГБ для активных RPC/архива (зависит от сети/клиента).
- Память: ECC для продакшна и особенно валидаторов.
- ОС и упаковка: Ubuntu LTS/Debian/RHEL; Docker; для кластеров — Kubernetes.
- Тюнинг системы: ulimit/fs.file‑max, vm.swappiness≈1–10, net.core буферы, TCP BBR по ситуации.
- Файловые системы: ext4 или XFS; отдельные тома под данные узла и логи.
Хранилище
- Носители: NVMe SSD для активных записей/индексов; SATA SSD — в тестах/лёгких ролях.
- Ёмкость: от сотен ГБ (некоторые full) до нескольких ТБ (архив/RPC). Сверяйтесь с актуальной документацией клиента.
- Выносливость: ориентируйтесь на высокие TBW/DWPD; отслеживайте износ.
- Отказоустойчивость и восстановление: RAID1/10 или зеркалирование; регулярные бэкапы и проверка восстановления.
Сеть
- Uplink и задержка: важнее стабильности и низкой латентности, чем «толстая» полоса; RPC может требовать 1–10 Гбит/с.
- Устойчивость: два провайдера с автофейловером; статический публичный IP для пиринга.
- Порты и NAT: открывайте входящие по требованиям клиента; корректная настройка NAT/проброса.
- OOB: независимый канал аварийного управления (LTE/второй линк).
Безопасность
- Харднинг ОС: минимальные образы, своевременные патчи, минимальные привилегии, auditd.
- Сетевая политика: firewall default‑deny, только необходимые пиры/API, rate‑limit, анти‑DDoS.
- Ключи и секреты: валидаторы — HSM/аппаратные ключи, оффлайн‑бэкапы, ротация, разделение ролей.
- Sentry‑паттерн: валидатор за sentry‑узлами; никаких публичных входящих к валидатору.
- Логи и SIEM: централизация логов и алерты на аномалии аутентификации/сети/консенсуса.
Мониторинг и эксплуатация
- Синхронизация и консенсус: лаг по высоте/слоту, число пиров, orphan/stale, отклонённые блоки.
- Производительность: CPU/RAM/IOPS, износ/заполнение NVMe, RPC p95/p99 и ошибки.
- Алерты: оффлайн, деградация, ошибки консенсуса, почти заполненный диск.
- Runbook’и: процедуры обновлений, пост‑рестарт проверки, откат; окна обслуживания.
- Бэкапы и DR: снапшоты БД/ключей; периодические тесты восстановления (RTO/RPO).
Масштабирование
- Вертикально: больше CPU/RAM/NVMe; быстрые NIC; тюнинг ядра/ФС под IO.
- Горизонтально: кластеры для RPC; балансировщики (L4/L7), кеширование, геораспределение.
- Специализация: разделяйте роли (валидатор, sentry, RPC, архив) по узлам для снижения blast‑radius.
Экономика и модели размещения
- CAPEX: серверы, NVMe повышенной выносливости, HSM, сетевое оборудование.
- OPEX: энергия, полоса/трафик, IP‑адреса, мониторинг/SaaS, анти‑DDoS, дежурства.
- Облако vs «железо»/колокация: облако быстрое, но при длительных IO‑нагрузках дороже; «железо»/колокация окупаются за 6–24 мес.
Референс‑архитектуры
| Роль | CPU | RAM | Хранилище | Сеть | Особенности | Назначение |
| Полный | 4 vCPU | 16 ГБ | NVMe 1 ТБ | 1 Гбит/с | Ubuntu LTS, ext4 | Личная валидация, dev |
| Валидатор | 8 vCPU | 32 ГБ | NVMe 1–2 ТБ | 1 Гбит/с + OOB | HSM‑ключи, sentry‑узлы | Участие в консенсусе |
| RPC (prod) | 16–32 vCPU | 64–128 ГБ | NVMe RAID, 2–8 ТБ | 10 Гбит/с | LB, кеш, анти‑DDoS | API для dApp/кошельков |
| Архивный | 32 vCPU | 128 ГБ | NVMe 8–24 ТБ | 10 Гбит/с | SSD повышенной выносливости | Исторические запросы/аналитика |
Чек‑лист перед запуском
- Выбрана роль (full/light/validator/RPC/archive) и определены SLO.
- CPU/RAM с запасом; ECC где нужно.
- NVMe по ёмкости/выносливости; RAID/зеркало; план бэкапов.
- Два провайдера, статика, порты/NAT настроены; есть OOB.
- Firewall default‑deny; анти‑DDoS/rate‑limit; защищённый SSH/VPN.
- Валидатор: HSM/аппаратные ключи, sentry‑паттерн, без публичных входящих.
- Мониторинг: лаг, пиры, p95/p99, ошибки; алерты на дежурство.
- Runbook’и: апдейты, откаты, пост‑рестарт проверки.
- DR: тест восстановления; RTO/RPO задокументированы.
- Экономика: модель CAPEX/OPEX; выбор облако/железо; контракты/SLA.
Что дальше?
Нужны окружения full/validator/RPC/archive? Unihost спроектирует, развернёт и возьмёт в эксплуатацию: выделенные серверы, NVMe, анти‑DDoS, сеть с OOB и 24/7 мониторинг. Отправьте сеть, роль, целевые SLO и бюджет — пришлём конфигурацию, сроки и цену.