在獨立伺服器上運行 Chainstack 節點

在不與他人共用的裸機上自架你自己的 full node 或 archive node。把節點帶到 Chainstack(BYOC),從第一天起就擁有 root 與 IPMI,並擺脫託管 endpoint 的速率限制。

在獨立伺服器上用 Chainstack 能做什麼

Chainstack 是支援 70 多條鏈的託管區塊鏈基礎設施。若運行專用伺服器,您需自行處理節點,而 Chainstack 的工具則負責管理該節點。

沒有速率限制的 full node 或 archive node

你自己運行的節點沒有 RPS 上限,也沒有每月的 request unit 額度。運行一個 full node,或是保存完整歷史狀態的 archive node;唯一的上限就是硬體。

Bring Your Own Cloud(BYOC)

Chainstack 的 BYOC 會把節點軟體和管理層部署到屬於你的基礎設施上。編排與監控由 Chainstack 提供,底層硬體由 is*hosting 提供。

dApp 或 RPC 的正式環境後端

自架節點能以固定成本承載每天數百萬次 RPC 呼叫。把它放在你自己的負載平衡器後面,再增加伺服器來擴展讀取—延遲會保持穩定,因為沒有任何東西在限制你。

大規模索引 — 每一筆交易,不抽樣

你自己擁有的節點能讓索引器讀取每一筆待處理交易。mempool 索引器、subgraph 後端和分析管線都能在這裡以全速運行,這是有速率限制的 endpoint 無法支撐的。

Validator 或質押節點

獨立伺服器為 validator 提供不會在 epoch 中途被重新調度的核心,以及不會變動的 IP。對於簽名速度會影響獎勵的鏈,選擇高頻率的 CPU。

在一台機器上整合多條鏈的節點

一台配備大量 RAM 的高核心 EPYC 伺服器能同時並行運行多條鏈的節點。用 bandwidth pool 功能把同一地點的多台伺服器整合到單一流量方案下,當作一整組機隊來管理。
如何為 Chainstack 選擇獨立伺服器
在 Chainstack 伺服器的各項需求中,磁碟比 CPU 更重要。full node 和 archive node 的主要差別在於所需的磁碟容量,所以先依磁碟來選擇配置。

如何在獨立伺服器上部署 Chainstack 節點

以太坊的 full node 同步需要數小時到數天,archive node 則需要好幾 TB。以下步驟會帶你從一台空機器,走到一個正在同步、且 RPC endpoint 已可運作的節點。加固、監控和 reverse-proxy 設定列在最後的後續步驟中。

步驟 01 — 下訂伺服器並取得存取權

從上方區塊選一個配置(單一條鏈的 full node 用較小的 NVMe 等級即可)。開通完成後,你會透過電子郵件收到 IP、root 密碼和 IPMI 資訊。用 SSH 連線:

ssh root@YOUR_SERVER_IP

如果作業系統無法開機,IPMI 讓你不必開支援工單,就能重新安裝系統或進入 console。

步驟 02 — 為鏈上資料準備 NVMe

確認磁碟已存在,並掛載要用來存放鏈上狀態的那一顆:

lsblkmkfs.ext4 /dev/nvme1n1mkdir -p /data/ethereummount /dev/nvme1n1 /data/ethereumecho '/dev/nvme1n1 /data/ethereum ext4 defaults 0 0' >> /etc/fstab

把鏈上資料放在專用的 NVMe 上,而不是系統磁碟。

步驟 03 — 安裝執行客戶端

從官方 PPA 安裝 Geth:

add-apt-repository -y ppa:ethereum/ethereumapt update && apt install -y ethereumgeth version

步驟 04 — 安裝共識客戶端

The Merge 之後,以太坊需要在 Geth 旁邊搭配一個共識客戶端。安裝 Lighthouse,並產生兩個客戶端用來互相驗證的共用 JWT secret:

openssl rand -hex 32 | tr -d '\n' > /data/ethereum/jwt.hex

把 Lighthouse 指向 Geth 在 8551 埠的 engine API。

步驟 05 — 啟動 Geth 並開放 RPC endpoint

讓 Geth 指向 NVMe 上的路徑,並啟用 HTTP-RPC API:

geth --datadir /data/ethereum \  --authrpc.jwtsecret /data/ethereum/jwt.hex \  --http --http.api eth,net,web3 \  --http.addr 0.0.0.0 --http.port 8545

綁定到 0.0.0.0 會把 endpoint 開放在所有網路介面上—在你驗證階段沒問題,但上正式環境前要限制存取。

步驟 06 — 以服務方式運行並確認同步

把 Geth 包成一個 systemd unit,讓它在重開機後仍能運行、並在故障時重新啟動,然後觀察同步開始:

systemctl enable --now gethgeth attach --exec 'eth.syncing'

同步過程中,你會看到區塊編號逐漸上升:

{  currentBlock: 2148740,  highestBlock: 21463991,  ...}

eth.syncing 回傳 false 時,節點已完全同步,RPC endpoint 也已上線。

步驟 07 — 驗證 endpoint 是否回應

從你的應用程式伺服器,確認節點會回應 JSON-RPC 呼叫:

curl -s -X POST http://YOUR_SERVER_IP:8545 \  -H "Content-Type: application/json" \  -d '{"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id":1}'

回應中出現十六進位的區塊編號,代表你的自架節點正在處理請求。

後續步驟(上正式環境前請完成): 用 UFW 和 reverse-proxy 限制 RPC 埠、加上 TLS、為 peer 數量和磁碟使用量設定監控,並且—如果你使用 Chainstack BYOC—把節點連到你的 Chainstack 專案,讓它顯示在 console 裡。

常見問題

同步看起來卡在某個很低的區塊好幾個小時。 這通常是狀態下載階段的正常現象,而不是故障。在 geth attach 中用 admin.peers.length 檢查 peer 數量—如果是零,代表你的防火牆擋住了 P2P 埠(30303)。把它打開,peer 就會出現。

磁碟填滿的速度比預期快。 你不小心部署了 archive node。full(「snap」)同步只保留近期狀態;archive 會保留全部,需要好幾 TB。確認節點是用哪種模式啟動的,並依模式來決定 NVMe 容量,而不是反過來。

RPC endpoint 拒絕來自你應用程式的連線。 Geth 預設只監聽 localhost。要嘛是啟動時沒有加 --http.addr 0.0.0.0,要嘛是防火牆規則擋掉了 8545 埠。在判定節點故障之前,先檢查這兩點。

準備好運行你自己的節點了嗎?

設定一台獨立伺服器,在交機時取得 root 和 IPMI,開始同步。full node 與 archive node 的配置遍及五個地點。

設定 獨立伺服器

is*hosting 的基礎設施是 Chainstack 的穩固基礎

是裸機,而不是它的一小塊

你會完整取得一顆多核心的 AMD EPYC 和數百 GB 的 RAM,你和磁碟之間沒有任何 hypervisor。節點同步受限於 I/O,而在獨立伺服器上,沒有其他東西會來搶磁碟。從第一次開機起就提供 root 和 IPMI。

為鏈上狀態打造的 NVMe

archive node 會對磁碟產生持續的隨機讀取,這類負載會很快耗損消費級 SSD。我們採用多顆磁碟配置的企業級 NVMe,並在部署時設定 soft-RAID—正是為這種情境而準備。

內含 DDoS 防護與免費遷移

在荷蘭,我們提供防護效果達 95% 的免費 DDoS 防護;若你從其他供應商搬過來,我們免費為你遷移專案。這一切都運行在我們自有的硬體上,位於五個地點的 Tier-3+ 資料中心,全天候 24/7 監控。

Chainstack 獨立伺服器主機的常見問題

什麼是 Chainstack 獨立伺服器主機?

就是你自己在獨立硬體上運行區塊鏈節點,而不是使用 Chainstack 的託管 endpoint。Chainstack 的節點軟體和管理工具(透過 BYOC)運行在一台由你掌控的 is*hosting 裸機伺服器上。

我需要獨立伺服器,還是 VPS 就夠了?

要看你是運行節點,還是只是跟節點溝通。如果你只是使用 Chainstack 的託管 endpoint—一個監控程式、一個機器人、一支開發腳本—VPS 就綽綽有餘,而且更便宜(每月 10.19 美元起,40 多個地點)。如果你要自架 full node 或 archive node,就需要 VPS 無法提供的專用 NVMe 和 RAM。

我可以在獨立伺服器上運行哪些鏈?

任何 Chainstack 支援的鏈(70 多條),只受硬體限制。以太坊和其他 EVM 鏈可在標準的 EPYC 配置上運行;我們有部分伺服器標註為適用 Solana,因為它在 I/O 和 RAM 上的負擔較重。archive node 和高吞吐量的鏈則需要多顆 NVMe、搭配最大 RAM 的配置。

Chainstack 節點需要 GPU 嗎?

不需要。區塊鏈節點靠的是 CPU、RAM、磁碟和網路;GPU 對同步或 RPC 毫無幫助,只會增加費用。請選擇不含 GPU 的配置。附 GPU 的獨立伺服器是為 AI、ML 和算圖等工作負載準備的。

full node 同步需要多久?

以太坊 full node 用 snap sync 大約需要數小時到幾天,取決於鏈和客戶端。archive node 需要更久,也需要好幾 TB。同步時間取決於鏈和客戶端,而不是主機—這裡的 NVMe 和頻寬能消除磁碟和網路的瓶頸,但鏈本身還是得下載。

這跟 Chainstack RPC node providers 比起來如何?

Chainstack 是提供託管 endpoint 的眾多 Chainstack RPC node providers 之一—你把請求送到他們的基礎設施,並按 request unit 付費。自己運行節點則反過來:Chainstack RPC endpoint 屬於你、沒有速率限制、資料留在你的硬體上。託管方式起步更簡單;而當你的呼叫量、對 archive 資料的需求或合規規定超出共用 endpoint 的範圍時,自架就更划算。

你們提供代管的獨立伺服器嗎?

有的。選擇 unmanaged 可對節點擁有完整的 root 層級控制;選擇 managed 則可讓 is*hosting 團隊負責作業系統更新、監控和備份,讓你專注在應用程式上。代管的獨立伺服器在芬蘭、德國、荷蘭、烏克蘭和美國皆有提供。

更多 is*hosting 服務

VPS

在 40 多個地點部署 VPS 執行個體,用於較輕量的 Chainstack 工作負載—使用託管 endpoint 的監控程式、機器人和開發腳本。
瀏覽
$5.94 /個月

Data Storage

為你節點的金鑰和快照提供伺服器外備份。還原一個特定備份,比從頭重新同步一個 full node 快得多。
瀏覽
$1.00 /個月