cardano-node: 本地化运营进阶，进一步压榨 cnode 运行成本

随着版本迭代和 Conway 更新的上线，对运行节点的配置要求也水涨船高，目前为止 9.1.1 的配置要求是

Minimum System Requirements

• An Intel or AMD x86 processor with two or more cores, at 1.6GHz or faster (2GHz or faster for a stake pool or relay)
• Or, for MacOS, an Apple Silicon (M1, M2 or M3) processor
• 24GB of RAM
• 200GB of free storage (250GB recommended for future growth)

就内存和存储空间这两项，租用云服务器涨配置直接等同于加钱。
实施本地化部署部分节点后，变成一次性投入相对还好点。我这从最早期运营下来的节点，SSD从一开始 120G 升级到 256G，最近又因为空间不足又迫切需要升级到 512G 甚至 1T。

作为经典配置 1(block producer) + 2 (relay) + 1(test + cold wallet)
4个节点4台设备内存独立配置没有办法，但硬盘空间是否可以融合共享达到进一步节省成本的目的呢。

分析和试验了一下，还真可以！

方案简述

使用其中一台负载较轻或性能较高的设备，安装 2T SSD，并部署 NFS server服务，其余节点作为 nfs client 映射网络驱动器。
一个 2T的 SSD 可以满足 4个甚至到 6、7个 cnode的 db/immutable 的存储需求，而成本则远低于 512G x 4。而且将来的空间需求会更有弹性。万一未来存储需求进一步提高，只需要将部分client的映射撤下分流去其他 nfs 驱动盘，现有的硬盘不会马上因为容量不足被淘汰。

实施步骤

部分内容GPT帮忙整理，嘿.

要在Ubuntu系统中将同一局域网内另一台Ubuntu机器的磁盘映射为网络驱动器，可以使用NFS（Network File System）或Samba来实现。以下是使用NFS的方法，适合在两个Linux系统之间共享文件。

准备工作

假设：

• Server：你想要共享磁盘的机器，IP为192.168.1.100
• Client：你想要将共享的磁盘映射为网络驱动器的机器，IP为192.168.1.101

1. 在Server上安装和配置NFS

1.1 安装NFS服务器

sudo apt update
sudo apt install nfs-kernel-server

1.2 创建一个共享目录

假设你要共享/mnt/shared目录。

sudo mkdir -p /mnt/shared

1.3 修改NFS导出文件

编辑/etc/exports文件，添加共享目录配置：

sudo nano /etc/exports

在文件中添加以下内容：

/mnt/shared 192.168.1.101(rw,sync,no_subtree_check,no_root_squash)

这里的192.168.1.101是Client的IP地址。如果你想允许多个客户端访问，可以将其替换为整个子网地址，比如192.168.1.0/24。
no_root_squash 是为了让客户端也可以用 root身份读写目录内的文件

1.4 重新启动NFS服务

sudo exportfs -ra
sudo systemctl restart nfs-kernel-server

2. 在Client上安装并配置NFS客户端

2.1 安装NFS客户端

sudo apt update
sudo apt install nfs-common

2.2 把原本cnode的immutable挂载为nfs

sudo mv $CNODE_HOME/db/immutable $CNODE_HOME/db/immutable_bak
sudo mkdir -p $CNODE_HOME/db/immutable

由于只有immutable占据大量的存储空间，因此只挂载共享这个目录，在挂载之后先备份原来的

2.3 挂载远程共享目录

sudo mount 192.168.1.100:/mnt/shared $CNODE_HOME/db/immutable

现在，$CNODE_HOME/db/immutable目录下就可以访问Server的/mnt/shared目录了。

3. 设置开机自动挂载（可选）

为了在重启后自动挂载NFS共享，编辑/etc/fstab文件：

sudo vi/etc/fstab

在文件中添加以下行：

192.168.1.100:/mnt/shared $CNODE_HOME/db/immutable nfs defaults 0 0

4. 验证

可以使用以下命令来验证挂载是否成功：

df -h

优缺点分析 和 注意事项

优点

• 省钱：上文已经说了，买1个2T，远比买 4个 512G 有性价比。
• 容量更有弹性，假设挂载4个节点的区块数据未来不够用了，可以撤掉其中一个client转移到其他nfs或SSD。腾出的空间足够剩余3个节点继续使用一段时间。
• 维护和恢复更为快捷：假设需要新增一个节点或其中一个节点出现故障需要修复。只需要 nfs_server 上复制一份 immutable ，SSD内部复制可以大幅缩短所需时间，比网络同步快，比局域网内上传快，甚至比用usb移动硬盘U盘传输要快许多。这对于动辄 186G的数据很重要。

缺点

• 如果nfs_server 的SSD损坏，将会导致所有节点团灭。需要注意对关键配置文件和密钥进行备份（不过还好，只是immutable数据的话，这部分是静态的）
• 对LAN的网速有依赖，最好是万兆或 2.5G 网速。但实测在 1G Lan下，影响不大，实际上cnode的数据吞吐量每秒峰值只有2M左右4台一共不超过10M，对 SSD来说，再增加数十倍的吞吐压力也是轻轻松松。
• IO性能瓶颈，对 nfs_server 的性能有影响。实测下，还好，即便是client在进行高强度的区块验证和下载同步，服务端的负载只有 0.1的波动。参考上一条，cnode是重计算对读写性能要求反而不高。内存开销因为nfs_server可能会有一点点高，但也不明显。

以下是 nfs_server 和 nfs_client的运行状况截图

nfs server

nfs client

可见响应速度上没有问题，负载也都几乎可以忽略

注意事项

• 确保Server和Client之间的防火墙设置允许NFS通信。
• 确保NFS共享目录的权限设置正确，Client可以读写该目录。
• 多个cnode建议错开时间重启和启动，多个同时同步和验证可能对 nfs_server 并发IO压力
• 每个cnode 的client必须是单独的 nfs目录。不可以指向同一个路径，多个cnode同时写同一个 immutable 会出错会致整个区块文件夹重新同步——这将是灾难级的。