Уявіть: ваш 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 архітектура вирішує ці проблеми в корені. Вона забезпечує вдвічі швидший 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 робочих днів. Отримайте консультацію: оцінимо ваш проєкт і запропонуємо тариф.