web3-infra
AWS 上 archive/RPC 节点的容量和隔离边界
一次公开化的 archive/RPC 节点运维记录：Terraform 变更收窄、磁盘容量、实例规格、RPC/metrics 边界和启动后的验证口径。
目标很明确：增加 archive/RPC 能力，同时不碰无关的在线主机。 所以大部分工作不是“怎么把机器起起来”，而是“怎么把影响范围压住”。 更安全的模式是只启用目标节点定义、给每个节点独立 security group、明确数据盘容量，并且不要把某个已经调过规格的高配节点当成所有新节点的默认模板。
用语说明
| 用语 | 含义 |
|---|---|
| archive node | 保留历史状态的节点，可以查旧区块、receipt、trace 或历史余额。 |
| RPC | 应用或脚本访问节点的 HTTP API。EVM 链通常是 JSON-RPC。 |
| P2P | 节点和其他节点互联、同步数据用的网络端口。 |
| security group | AWS 上挂在实例或网卡上的防火墙规则。 |
| EBS | AWS 的块存储。节点的数据盘一般放链数据库。 |
| gp3 | 一种 EBS 类型，容量、IOPS、throughput 可以分开配置。 |
| Terraform plan | Terraform apply 前的预览，用来看会创建、修改或替换哪些资源。 |
实际改了什么
节点规格按几类 profile 来看：
| Profile | 客户端方向 | 实例规格 | 数据盘 |
|---|---|---|---|
| 大型 EVM archive node | Erigon archive node | r7i.2xlarge | 4096 GiB |
| 中型 EVM archive node | Erigon，必要时配 consensus client | r7i.2xlarge | 2048 GiB |
| Substrate-style RPC node | 链客户端承担 archive/RPC 工作负载 | r7i.2xlarge | 4096 GiB |
| 追加的 Substrate-style RPC node | 同客户端家族、独立网络 profile | r7i.2xlarge | 4096 GiB |
这些 profile 继续使用 gp3 数据盘，并配置较高的 I/O。 磁盘容量没有贴着官方参考值走，而是留了比较大的余量。 区块链数据库快满时，性能和稳定性都会变差；对 archive/RPC 节点来说，余量本身就是运行成本的一部分。
某个已经调过规格的节点没有作为默认基线。
它之前遇到过 hardfork、客户端同步和磁盘吞吐相关的问题，所以保留更高规格是它自己的历史背景。
其他新节点先用 r7i.2xlarge 起步，后续根据 CPU、内存、IO wait、同步速度再单独调整。
网络边界
这里不应该沿用一个“大开口”的 security group。 每个新节点都有自己的 security group。 P2P 按链的要求对公网开放，RPC 和 metrics 只给受信任的内网或监控来源。
实际边界是：
| 流量 | 边界 |
|---|---|
| P2P | 链需要的 P2P 端口对公网开放。 |
| RPC | 只允许可信内网或显式批准的来源访问。 |
| metrics | 由 monitor 主机抓取，不对公网开放。 |
| SSH | 和应用端口分开管理。 |
某些 EVM 节点的 RPC/metrics 进程仍然可以绑定在 127.0.0.1。
如果要从另一台 EC2 访问，需要通过受控的本地代理、tunnel 或 host 侧转发路径。
security group 放开不等于服务能被访问到；服务只监听 loopback 时，网络层规则不是唯一条件。
客户端版本
Erigon 系节点使用 upstream Erigon v3.4.4。
archive 模式继续显式保留 --prune.mode=archive。
Substrate-style 节点使用固定客户端版本，不再用 floating latest。
对节点基础设施来说，重启时悄悄拉到新版本很危险。
版本升级应该是一次可审查的变更，而不是 Docker tag 自动漂移。
有些 EVM 网络还需要 consensus client。 post-merge 网络里，execution client 单独跑起来不够。 execution 和 consensus 之间需要本地 JWT 鉴权。 JWT 放在文件里比写进容器启动参数更合适，因为启动参数容易被进程列表或容器 inspect 暴露。
Plan 的收口
apply 前看的不是“Terraform 会不会成功”，而是“plan 形状是不是对”。 预期里应该只有目标节点相关资源：
| 应该出现 | 不应该出现 |
|---|---|
| 目标 EC2 节点 | 替换范围外的既有节点 |
| 目标节点的数据盘 | 修改无关数据库或应用资源 |
| 节点独立 security group | 复用过宽的开放规则 |
| 必要的监控规则 | 全局网络策略变化 |
如果 plan 里出现了不在范围内的替换，应该先停下来缩小 plan。 基础设施变更里，apply 成功不等于变更正确。
启动后的验证口径
启动后先看最基础的状态：
docker ps
df -h /data
curl -s http://127.0.0.1:8545
EVM 节点看这些 RPC：
{"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id":1}
{"jsonrpc":"2.0","method":"eth_syncing","params":[],"id":1}
{"jsonrpc":"2.0","method":"trace_block","params":["0xf4240"],"id":1}
Substrate-style 节点先看区块高度是否推进、peer 是否稳定、parachain 和 relaychain 日志是否都在动。
这里要分清两个状态： 节点已经按 archive 模式配置并开始同步，不等于已经同步到最新高度。 archive 节点从启动到可稳定查询所有历史数据，可能还需要很多小时甚至几天。
这里的取舍
最关键的选择是收窄影响范围。 新节点用新实例、新数据盘、新 security group。 已有主机不被这次变更牵连。 等节点运行起来以后，再根据各自的 CPU、内存、磁盘 I/O 和同步速度单独调规格，这比一开始套用最贵配置更可控。