甲骨文把共享存储藏了3年，47%用户才发现这功能

2024年Q3，OCI（Oracle Cloud Infrastructure，甲骨文云基础设施）块存储的共享挂载量环比增长47%。这个数字背后是个被低估的技术细节——多数工程师仍在用NFS（Network File System，网络文件系统）或手动同步绕开真正的并发写入需求。

OCFS2（Oracle Cluster File System Version 2，甲骨文集群文件系统第二版）在OCI上跑通全配置，其实只需要两台Ubuntu虚拟机、一个块卷、四条防火墙规则。但文档分散在三处，没有一条完整路径。本文按实际部署时间线还原，从网络验证到集群启停，全程约25分钟。

第一步：网络层预检，拒绝"配置完才发现连不通"

两台VM（server1: 10.0.1.85，server2: 10.0.1.235）必须在同一子网（10.0.1.0/24）。OCI的安全列表需要两条入站规则：

TCP 7777（o2cb心跳）和TCP 3260（iSCSI通信）必须同时开放，缺一不可。

验证命令从server2执行：

nc -vz 10.0.1.85 3260
nc -vz 10.0.1.85 7777

返回"Connection refused"才是正确状态——说明端口可达，只是服务未启动。如果显示"Timeout"或"No route to host"，检查VCN路由表和子网关联。这个细节坑过至少三份社区文档，它们把"refused"当成错误提示。

第二步：安装与集群定义，双机必须完全一致

两台机器同步执行：

sudo apt update && sudo apt upgrade -y
sudo apt install ocfs2-tools-dev ocfs2-tools -y

创建集群定义：

sudo o2cb add-cluster ociocfs2

节点注册需要精确IP，主机名解析不保险：

sudo o2cb add-node ociocfs2 server1 --ip 10.0.1.85
sudo o2cb add-node ociocfs2 server2 --ip 10.0.1.235

验证配置文件：

sudo cat /etc/ocfs2/cluster.conf

输出必须包含cluster段落（heartbeat_mode = local）和两个node段落（number从0递增）。任何一台机器的cluster.conf不一致，都会导致脑裂或挂载失败。

第三步：内核模块与集群服务，启动顺序有讲究

加载OCFS2内核模块：

sudo modprobe ocfs2

配置o2cb服务自启：

sudo o2cb configure

交互式选项建议：默认心跳为local，集群名ociocfs2，其余按提示确认。双机都配置完成后，启动集群：

sudo o2cb online ociocfs2
sudo o2cb status

状态显示"Heartbeat: Active"且节点数为2，才算就绪。此时可以格式化块设备（仅在一台执行）：

sudo mkfs.ocfs2 /dev/sdb

mount命令同样需要cluster_name参数：

sudo mount -t ocfs2 /dev/sdb /shared

双机同时挂载后，用`df -h`和`touch /shared/test-$(hostname)`验证写入可见性。文件应该实时同步，延迟通常在毫秒级。

生产环境的三条隐藏规则

第一，块卷的访问类型必须在创建时设为"Read/write - shareable"，后期修改需要卸载并重挂，会中断业务。第二，OCFS2的集群心跳走7777端口，但数据路径走iSCSI的3260，安全组漏掉任一都会导致间歇性失联。第三，Ubuntu的ocfs2-tools包默认不装o2cb服务，必须手动enable，否则重启后集群不会自恢复。

OCI官方文档把OCFS2归类在"第三方工具"章节，而非块存储的核心功能。这种分类方式导致多数用户先入为主地选择NFS或GlusterFS，即便它们在这个场景下延迟更高、配置更复杂。47%的增长数据来自甲骨文2024财年技术白皮书，但白皮书本身没解释"为什么现在才增长"——也许只是更多人终于发现了这个被藏起来的开关。

你的集群文件系统选型卡在哪个环节？是网络策略的"refused"误导，还是服务启动顺序的隐形依赖？