Выделенный сервер для Bitcoin и Ethereum full node: сначала диск, потом ядра

MAATRIX · Выделенные серверы · Статья 13 из 48

У криптоноды есть особый талант: терпеливо занимать свободное место. В день установки диск кажется просторным, через несколько месяцев — предусмотрительным, а затем в мониторинге появляется сообщение, которое почему-то всегда приходит вечером. Блокчейн продолжает расти независимо от того, когда вы в последний раз открывали панель сервера.

Выделенный сервер для Bitcoin или Ethereum выбирают через режим узла, программный клиент и запас хранения. Слово full node ещё не означает, что всем проектам нужна одинаковая конфигурация. В линейке MAATRIX много процессорных ресурсов, но большинство тарифов предлагают около одного терабайта диска. Для некоторых сценариев именно это ограничение определит выбор.

Полная проверка и полное хранение — разные требования

Bitcoin full node самостоятельно проверяет правила сети. При этом узел может хранить всю доступную ему историю блоков либо удалять старые блоковые файлы после проверки в режиме pruning. Сокращённое хранение не превращает его в лёгкий клиент, который просто доверяет чужому ответу.

Но pruning ограничивает доступ к старым данным и некоторые сценарии повторного сканирования. Если вашему приложению нужна историческая информация, определённые индексы или обслуживание других клиентов, заранее проверьте совместимость требований. Нельзя выбрать экономный режим хранения, а потом удивиться, что сервер не предоставляет произвольные данные за всю историю.

В Ethereum тоже важно различать обычный полный узел и архивный. Архивные сценарии позволяют работать с историческим состоянием и могут требовать значительно больше пространства в зависимости от реализации. Режим синхронизации, очистки и поддерживаемые запросы выбираются вместе с клиентом. Назвать тариф «для Ethereum» без этих уточнений почти так же полезно, как назвать автомобиль «для поездок».

Наконец, узел сети, RPC-служба для приложения и валидатор — разные роли. Публичная RPC-нагрузка добавляет требования к CPU, памяти и защите доступа. Валидатор связан с отдельными ключами и процедурами эксплуатации. Запуск обычной ноды сам по себе не является обещанием дохода и не требует превращать технический сервер в торговый проект.

Что рекомендует документация Ethereum на дату проверки

По состоянию проверки 7 октября 2026 года руководство ethereum.org указывает для обычного узла минимально 16 ГБ RAM и 2 ТБ NVMe, а в рекомендуемой конфигурации — 32 ГБ RAM и 4 ТБ NVMe. Это общие ориентиры: требования меняются с клиентом, настройками и развитием сети. На той же странице подчёркнута необходимость запаса после синхронизации. Источник — руководство по запуску узла Ethereum.

Для работы нужны клиент слоя исполнения и клиент консенсуса. Их данные складываются, а не заменяют друг друга. Если проверять размер только одного каталога, можно получить очень точный расчёт неполной системы. Современные рекомендации по аппаратуре дополнительно сформулированы в EIP-7870.

Поэтому стандартный тариф с одним диском на 1 ТБ нельзя безоговорочно рекомендовать как спокойную долгосрочную основу Ethereum-ноды. Некоторые сочетания клиента и режима могут помещаться в меньший объём, но это требует отдельного расчёта и регулярного обслуживания. Для публикации готового предложения честнее ориентироваться на поддерживаемую конфигурацию с запасом.

У NECROPOLIS два NVMe по 1 ТБ. Если использовать их суммарную ёмкость, это всё равно не эквивалент рекомендуемых 4 ТБ. Если собрать зеркало, полезный объём приблизится к одному терабайту. Покупка этого тарифа ради фразы «два диска для Ethereum» без уточнения схемы хранения проблему не решает.

Практический вывод: для Ethereum сначала согласуйте подходящую дисковую конфигурацию и точный клиент, затем выбирайте процессор. В предоставленном стандартном наборе тарифов нет готового универсального ответа для всех современных вариантов узла. Это нормальный результат подбора, а не повод спрятать ограничение под большим числом ядер.

Bitcoin: что проверить до заказа терабайта

Для Bitcoin сначала решите, нужна ли вся история локально. Если достаточно самостоятельной проверки текущего состояния без длительного хранения старых блоков, pruning заметно уменьшает дисковую потребность. Он не отменяет первоначальную проверку и передачу необходимых данных. Особенности режима и эксплуатации описаны в руководстве Bitcoin по полной ноде.

Если история должна сохраняться полностью, получите актуальную оценку блоковых файлов, состояния цепочки, выбранных индексов и служебного запаса. Размер сети меняется, поэтому число из старой статьи легко устаревает. Особенно осторожно добавляйте индексы: их польза для приложения должна оправдывать дополнительный диск и время построения.

Один NVMe на 1 ТБ может выглядеть достаточным по размеру текущих блоков, но из этого ещё не следует безопасный горизонт эксплуатации. Нужно оставить место для роста, обслуживания и временных операций. Определите, за сколько месяцев до исчерпания ёмкости команда должна начать изменение конфигурации.

SCARAB с четырьмя ядрами EPYC 4124P, 32 ГБ DDR5 и 1 ТБ NVMe за $309 в США можно рассматривать для измеряемого сценария Bitcoin, особенно с сокращённым хранением. ANKH за $329 даёт шесть ядер Ryzen 7600X и 64 ГБ, но не увеличивает диск. Если проблема в ёмкости, доплата за память её не исправит.

Не обязательно начинать с выделенного сервера. Для спокойного частного узла подходящий VPS или собственная машина могут быть экономнее. Физический сервер оправдан, когда важны конкретные ресурсы, изоляция нагрузки, самостоятельное администрирование или дополнительные службы. Общие принципы подбора разобраны в статье о ресурсах сервера для криптовалютной ноды.

Первичная синхронизация и обычная жизнь нагружают сервер по-разному

Первый запуск включает загрузку, проверку и построение нужного состояния. Это может активно использовать процессор, диск и сеть. После достижения актуального состояния профиль меняется: узел обрабатывает новые данные и запросы приложений. Измерять только спокойный режим недостаточно, если после сбоя придётся снова синхронизироваться.

Время синхронизации зависит от выбранного клиента, версии, режима, соседей по сети и накопителя. Поэтому обещание точного числа часов по одной модели CPU ненадёжно. Даже одна машина может получить разные результаты в разных условиях подключения.

SSD важен не только объёмом. Синхронизация создаёт множество операций чтения и записи, а обслуживание базы клиента требует свободного пространства. Уточните модель, ресурс записи и состояние накопителя. Надпись NVMe не раскрывает всего поведения под длительной нагрузкой.

Настройки памяти меняют баланс между кэшем и остальной системой. У Bitcoin Core есть собственные рекомендации по снижению потребления и параметрам кэширования в документации проекта. Не переносите значение из чужого сервера механически: объём RAM и сопутствующая нагрузка могут отличаться.

Канал 1 Гбит/с с обозначением UNLIMITED выглядит подходящим исходным условием для проверки, но не гарантирует такую скорость от каждого пира. Кроме того, условия использования и длительного исходящего трафика нужно сверить у провайдера. Узел не обязан превращаться в самый загруженный источник данных сети только потому, что в тарифе нет привычной месячной квоты.

RPC — отдельная дверь, а не часть публичного двора

Сетевое общение с другими узлами и административный либо прикладной RPC-доступ имеют разные назначения. Возможность принимать p2p-соединения не означает, что интерфейс управления нужно открывать всему интернету. Разделяйте адреса, правила фильтрации и полномочия.

Если нодой пользуется только ваше приложение, ограничьте доступ нужной сетью или защищённым каналом. Если создаёте RPC-сервис для многих клиентов, добавьте аутентификацию, ограничения запросов, наблюдение и оценку дорогих методов. Один тяжёлый запрос к истории может потреблять существенно больше ресурсов, чем обычное чтение свежего блока.

Не храните на сервере лишние секреты. Для узла, который только проверяет данные и обслуживает чтение, обычно нет причины добавлять ключи от значительных активов. Когда ключи всё же нужны для отдельной роли, их жизненный цикл и резервирование проектируют отдельно от каталога блокчейна.

Защитите административный доступ и обновляйте поддерживаемое ПО. Проверяйте происхождение дистрибутивов и контрольные данные способом, рекомендованным проектом. Случайный установочный скрипт с обещанием «нода за пять минут» сокращает путь не только администратору, но иногда и постороннему человеку.

Логи также требуют разумного хранения. Они помогают диагностировать синхронизацию и ошибки, но при бесконтрольном росте способны занять диск, который вы так тщательно рассчитывали под цепочку. Для RPC-сервиса отдельно подумайте, какие сведения о запросах действительно необходимо сохранять.

Когда два диска полезнее ещё одного процессора

Отказ накопителя может потребовать повторной загрузки большого объёма данных. Для некоторых частных узлов это допустимо, для прикладного сервиса — уже долгий перерыв. Время возвращения в работу должно участвовать в выборе хранения наряду со скоростью.

Зеркало помогает пережить отказ одного устройства, но не заменяет сохранение конфигурации и важных секретов. Реплика на независимом сервере может поддержать доступность RPC, однако её тоже нужно обновлять и проверять. Два клиента на одном физическом хосте имеют общую точку отказа.

Полный резервный образ блокчейн-данных не всегда является лучшим использованием хранилища: публичные данные можно заново получить и проверить. Но если восстановление должно быть быстрым, пригодная копия состояния может сэкономить время. Её согласованность и способ создания зависят от клиента; копирование активно изменяемого каталога наугад не гарантирует успешный старт.

В любом случае сохраните настройки, версии, параметры запуска и инструкции. Должно быть понятно, какие данные можно восстановить из сети, какие — только из собственных копий, а какие вообще нельзя потерять. Общий порядок подготовки среды есть в статье о развёртывании криптовалютной ноды.

План приёмки, который переживёт устаревание цифр

До заказа выберите сеть, клиенты, режим хранения и нужные методы приложения. Рассчитайте диск с запасом на рост и обслуживание. Уточните допустимость сценария, параметры сети и возможность будущего изменения накопителей, не предполагая, что любой апгрейд выполняется без переезда.

После запуска дождитесь корректного актуального состояния всех компонентов, необходимых выбранному типу узла, проверьте методы приложения и нагрузку. Наблюдайте за отставанием, ошибками, свободным местом и временем ответа. Наличие запущенного процесса не доказывает, что данные свежие и сервис отвечает правильно.

Проведите контролируемый перезапуск, проверьте доступ после обновления и подготовьте процедуру восстановления. Назначьте порог свободного места и срок реакции на него. Предупреждение должно появляться тогда, когда ещё есть время заказать новую конфигурацию, а не когда осталось место только для самого предупреждения.

Для Bitcoin выбор может начинаться со SCARAB или ANKH, если выбранный режим и рост укладываются в накопитель. Для Ethereum стандартную дисковую конфигурацию из приведённой линейки необходимо пересматривать под актуальные рекомендации. В обоих случаях правильная нода определяется способностью долго и корректно выполнять свою роль. Процессор здесь важен, но последнее слово часто остаётся за свободным местом.

Все материалы о выделенных серверах