Представьте: ваш DeFi-сервис теряет связь с Ethereum на 10 минут из-за сбоя — потери на ликвидности достигают $50 000 в час. А если это платёжный шлюз для крипто-мерчанта, каждый час простоя приносит убыток до $10 000. Одиночная нода — это single point of failure. downtime ноды равен downtime продукта. Мы настраиваем отказоустойчивые конфигурации блокчейн-нод для production-сервисов. Наши инженеры имеют опыт с Ethereum, Solana, Polygon, Arbitrum и другими сетями, более 5 лет на рынке и 10+ проектов по настройке нод. В документации Ethereum сказано: health check must verify not only connectivity but also synchronization status.
Проблемы одиночной ноды
Downtime возникает не только из-за аппаратных сбоев. Чаще всего проблемы связаны с отставанием ноды от chain tip — после краша Ethereum требует пересинхронизации, Solana — догоняет слоты. Перегрузку RPC — один инстанс не справляется с нагрузкой запросов от нескольких сервисов. Плановые обновления клиента во время rolling update делают ноду временно недоступной. Аппаратные отказы диска, RAM или сетевой карты выводят её из строя. Повреждение snapshot при неожиданном отключении питания также приводит к длительному восстановлению.
Почему стоит выбрать Active-Active архитектуру?
Active-Active архитектура решает эти проблемы в корне. Она обеспечивает в 2 раза более быстрый failover по сравнению с Active-Passive, так как обе ноды постоянно обслуживают трафик. При Active-Passive вторая нода простаивает, а при сбое требуется время на промоцию. Active-Active же мгновенно перераспределяет нагрузку, а health check каждые 5 секунд гарантирует, что несинхронизированная нода не получит трафик.
Client requests │ ┌───▼───┐ │ HAProxy / Nginx │ ← health check каждые 5s └───┬───┘ │ ┌────┴────┐ ▼ ▼ Node-1 Node-2 ← разные AZ / датацентры │ │ └────┬────┘ │ Shared или independent storage Пример конфигурации HAProxy для Ethereum RPC:
global maxconn 50000 log stdout format raw daemon defaults mode http timeout connect 5s timeout client 60s timeout server 60s option http-server-close option forwardfor frontend ethereum_rpc bind *:8545 bind *:8546 # WebSocket default_backend ethereum_nodes backend ethereum_nodes balance leastconn option httpchk POST / HTTP/1.1\r\nHost:\ localhost\r\nContent-Type:\ application/json\r\nContent-Length:\ 68\r\n\r\n{\"jsonrpc\":\"2.0\",\"method\":\"eth_syncing\",\"params\":[],\"id\":1} http-check expect string '"result":false' # нода в sync если eth_syncing = false server node1 10.0.1.10:8545 check inter 5s fall 2 rise 3 server node2 10.0.1.11:8545 check inter 5s fall 2 rise 3 # Sticky sessions для WebSocket (нельзя переключать mid-subscription) stick-table type ip size 100k expire 30m stick on src frontend ethereum_ws bind *:8546 default_backend ethereum_ws_nodes backend ethereum_ws_nodes balance source # WebSocket — по source IP для sticky server node1 10.0.1.10:8546 check inter 10s fall 2 rise 3 server node2 10.0.1.11:8546 check inter 10s fall 2 rise 3 Критичный момент для WebSocket: подписки (eth_subscribe, Solana slotSubscribe) — stateful, при failover клиент должен пересоздать подписки. Используем sticky sessions по IP.
Какой health check нужен для Ethereum RPC?
HTTP health check (status 200) недостаточен — нода может отвечать, но отставать на 1000 блоков. Правильная проверка:
#!/bin/bash # /etc/haproxy/scripts/check_eth_node.sh NODE_URL="http://localhost:8545" # 1. Проверяем что нода не в процессе синхронизации SYNCING=$(curl -sf -X POST "$NODE_URL" \ -H "Content-Type: application/json" \ -d '{"jsonrpc":"2.0","method":"eth_syncing","params":[],"id":1}' | \ jq -r '.result') if [ "$SYNCING" != "false" ]; then exit 1 fi # 2. Проверяем что блок не старше 3 минут (180 секунд) BLOCK_HEX=$(curl -sf -X POST "$NODE_URL" \ -H "Content-Type: application/json" \ -d '{"jsonrpc":"2.0","method":"eth_getBlockByNumber","params":["latest",false],"id":1}' | \ jq -r '.result.timestamp') BLOCK_TIME=$((16#${BLOCK_HEX#0x})) NOW=$(date +%s) AGE=$((NOW - BLOCK_TIME)) if [ $AGE -gt 180 ]; then exit 1 fi exit 0 Аналогично для Solana — проверяем getSlot и getEpochInfo, допуск 50–100 слотов.
| Метод health check | Что проверяет | Недостаток |
|---|---|---|
| HTTP 200 | Доступность порта | Не видит отставание |
| eth_syncing | Синхронизация | Не даёт возраст блока |
| eth_getBlockByNumber | Время последнего блока | Требует скрипт |
Как обновлять ноды без downtime?
Rolling update — обновляем по одной ноде, выводя из ротации:
#!/bin/bash # rolling_update.sh # Шаг 1: выводим node1 из rotation haproxy -sf $(cat /var/run/haproxy.pid) -f /etc/haproxy/haproxy_node2_only.cfg # Шаг 2: ждём drain существующих соединений sleep 30 # Шаг 3: обновляем node1 ssh node1 "systemctl stop geth && apt upgrade -y ethereum && systemctl start geth" # Шаг 4: ждём sync node1 while ! /etc/haproxy/scripts/check_eth_node.sh node1; do echo "Waiting for node1 to sync..." sleep 30 done # Шаг 5: возвращаем node1, обновляем node2 haproxy -sf $(cat /var/run/haproxy.pid) -f /etc/haproxy/haproxy.cfg sleep 30 ssh node2 "systemctl stop geth && apt upgrade -y ethereum && systemctl start geth" Как мониторить состояние HA-кластера?
Используем Prometheus + Grafana с метриками:
| Метрика | Порог алерта | Критичность |
|---|---|---|
| eth_block_age_seconds | > 120s | Critical |
| haproxy_backend_active_servers | < 1 | Critical |
| haproxy_backend_response_time_ms | > 2000ms | Warning |
| node_disk_io_time_percent | > 80% | Warning |
| node_memory_available_bytes | < 10% | Warning |
Алерты настраиваем в PagerDuty или Telegram. Для backend_active_servers < 1 — немедленное оповещение дежурного.
Типичные ошибки при настройке HA
При настройке HA часто встречаются ошибки: одинаковые health checks для всех нод, отсутствие мониторинга age блока, игнорирование WebSocket sticky sessions, ручное обновление и недостаточная ёмкость для resync. Разберём каждый кейс. Если проверять только порт, балансировщик будет считать обе ноды здоровыми, даже если одна отстаёт — запросы попадают на устаревшие данные. Нода может висеть на 50-м блоке часами, а health check не срабатывает — используйте eth_getBlockByNumber с таймстампом. Клиент, подписавшийся на события через ноду, при failover теряет подписку без переподключения. Без скрипта rolling update легко допустить простой — автоматизируйте с помощью HAProxy и API. После сбоя нода может пересинхронизироваться несколько часов — учитывайте это при выборе дисков и канала.
Процесс работы: от анализа до деплоя
- Анализ — изучаем текущую инфраструктуру, требования к uptime, бюджет.
- Проектирование — выбираем схему (Active-Active или Active-Passive), провайдеров, инструменты мониторинга.
- Реализация — развёртываем ноды в разных зонах доступности, настраиваем балансировщик и health checks.
- Тестирование — симулируем отказы, проверяем failover и время восстановления.
- Деплой и документация — сдаём конфигурацию, инструкции по обслуживанию и планы действий при сбоях.
Что входит в услугу
- Развёртывание второй ноды в отдельной AZ/датацентре.
- Настройка HAProxy или Nginx с умными health checks.
- Скрипты rolling update для обновлений без downtime.
- Prometheus метрики, Grafana дашборд, алерты.
- Документация процедур failover и восстановления.
Если ваша система требует uptime 99.9% — свяжитесь с нами для аудита текущей архитектуры. Закажите настройку отказоустойчивости вашей блокчейн-ноды — мы подберём оптимальное решение за 5 рабочих дней. Получите консультацию: оценим ваш проект и предложим тариф.