1. 在CAS管理平台，选择顶部 计算 页签，进入 主机池 下的 KP2集群 的“存储”页面。
2. 单击 <增加> 按钮，弹出增加存储池对话框。
3. 在存储池类型中选择“共享文件系统”，并在列表中选择之前已在主机池下添加好的对应共享文件系统。
4. 单击 <选择主机> 按钮，勾选KP2集群中需要挂载该共享文件系统的主机（确保KP2集群的所有CVK主机都已通过主机池配置了对应的存储资源）。
5. 确认并完成挂载后，启动存储池
6. 不确定有没有影响就在没业务的时候操作

在H3C CAS 5.0平台上，将KP1集群的共享文件系统挂载到KP2集群，核心难点在于CAS系统的设计限制。根据官方文档，一个共享文件系统被限制在单个集群内使用。

这意味着，你无法通过常规操作将KP1集群正在使用的共享文件系统，直接“挂载”给KP2集群使用。

 可行的操作方案

根据你的实际需求，有以下两种方案：

• 方案一：如果KP2集群需要全新的独立存储
  这是最直接的方法。在KP2集群上，创建一个全新的共享文件系统。此操作仅涉及新增存储，不会对KP1集群的在运行业务产生任何影响。

• 方案二：如果KP2集群必须使用KP1的现有数据（高风险）
  此方案流程复杂且风险较高，操作不当可能导致KP1集群业务中断甚至数据损坏。

  1. 数据迁移：将KP1集群中所有使用该共享文件系统的虚拟机迁移到其他存储位置。

  2. 解除挂载：在KP1集群中，将该共享文件系统从所有主机上卸载（Umount）。

  3. 删除定义：从CAS管理平台中删除该共享文件系统的定义。

  4. 重新添加与挂载：在KP2集群中，重新添加该存储设备，并将其挂载给KP2集群使用。

 对业务的影响与关键风险

• 方案一（新建存储）：完全无影响。这是在线的、安全的操作。

• 方案二（迁移数据）：存在明显影响。

  • 业务中断：虚拟机迁移和存储重新挂载过程会造成业务中断。

  • 数据风险：操作复杂，任何失误都可能导致数据丢失或损坏。

  • 架构违背：这种做法违背了CAS“共享文件系统以集群为边界”的设计原则，可能引入未知的稳定性风险。

CAS5.0 KP1、KP2 集群共享文件系统挂载问题

环境：同一鲲鹏主机池下两套独立集群 KP1、KP2；KP1 已有 OCFS2 类型 iSCSI/FC 共享文件系统，想给 KP2 集群使用。

⚠️核心硬性约束（CAS5.0 OCFS2 共享文件系统）

OCFS2 共享文件系统（iSCSI‑共享文件系统 / FC‑共享文件系统），一个 LUN / 共享文件系统只能归属于【同一个 CAS 集群】，不支持直接同时挂载给 KP1、KP2 两个不同 HA 集群。

OCFS2 磁盘内部保存cluster.conf，记录本集群全部 CVK 节点 UUID；如果两套集群同时接管同一个 LUN，cluster.conf 冲突，会直接报cluster.conf do not match挂载失败，严重会损坏虚拟机磁盘数据。 官方文档明确：一个共享文件系统仅能在一个集群中使用。

区分：如果是NFS 网络文件系统（NAS），不受该限制，多个集群可以同时挂载 NFS。你这里是 SAN 的 OCFS2 共享文件系统，受上面约束。

可选的 3 种实现方案

方案 1：将共享文件系统从 KP1 迁移到 KP2（业务会中断）

适用：业务以后全部跑在 KP2，KP1 不再使用该存储。

1. 将 KP1 集群该存储池上所有虚拟机关机 / 迁移到其他存储，无虚拟机占用共享文件系统；
2. 在 KP1 集群删除该共享文件系统（不要格式化 LUN，仅在 CVM 平台删除存储池）；
3. 存储阵列侧，把 LUN 映射给 KP2 集群全部 CVK 主机；
4. 登录 KP2 集群，添加 iSCSI/FC 共享文件系统，扫描 LUN，选择保留原有文件系统（不要格式化！）；
5. 导入原有虚拟机，业务恢复。

业务影响：虚拟机需要关机，业务中断；迁移完成后 KP1 不再能访问这个存储。

方案 2：复制数据（两套集群各自独立存储，业务零中断，推荐生产）

1. KP2 集群分配新的 SAN LUN，在 KP2 新建一套独立共享文件系统；
2. 通过 CAS 的虚拟机克隆 / 备份恢复、或者存储阵列层面 LUN 克隆，把 KP1 共享里面的数据完整复制到 KP2 新存储；
3. KP1 继续使用旧存储，KP2 使用复制后的新存储；两套集群完全隔离，互不干扰。

✔KP1 在线业务完全不受任何影响；两套集群各自独立存储，没有 OCFS2 集群 conf 冲突风险。

方案 3：把 KP1、KP2 合并为一个 HA 集群（不推荐，改动大）

将 KP1、KP2 所有 CVK 合并成同一个 CAS 集群，集群内部所有主机可以正常访问该共享文件系统。 缺点：

• 合并集群改动风险高，涉及集群仲裁、HA 策略、虚拟机资源调度；
• 合并后不再是两套独立集群，故障域合并，一个节点故障会影响整个集群。

❌绝对禁止操作

不要直接把同一个 SAN‑LUN 同时映射给 KP1 和 KP2 两套 CAS 集群，然后两边同时添加共享文件系统；会触发 OCFS2 集群配置冲突，有虚拟机磁盘损坏、数据丢失风险。

容易混淆点说明

1. 同一个主机池下的多个集群，依然是独立 HA 集群，OCFS2 不支持跨集群共享 SAN LUN，不是主机池级别，是集群级别约束H3C。
2. NFS（NAS）不受此限制，NFS 可以同时给 KP1、KP2 挂载；只有 iSCSI/FC 的 OCFS2 共享文件系统有该限制。

业务影响总结

1. ❌不能直接原地把 KP1 在用的 OCFS2 共享同时挂载 KP2；
2. 迁移方案（方案 1）：业务需要停机中断；
3. 复制数据方案（方案 2）：KP1 原有业务零中断，两套集群各自独立存储，生产环境优先选该方案；
4. 若你的存储是 NFS 类型 NAS，直接在 KP2 添加 NFS 存储池即可，KP1 业务完全不受影响。

检查命令（SSH 登录 CVM）

一人一套说辞，又可以又不可以的。。。

对业务无影响，但是注意一个共享存储池最好不要给超过32台主机使用