1.3. Ceph 文件系统架构

除了监控器外，OSD、RGW (RGW)和管理器服务在 Ceph 提供对象和/或块存储时部署，还需要 Ceph 元数据服务(MDS)，并且使用 NFS 协议，一个 NFS-Ganesha 服务需要作为原生 CephFS 的网关。（面向用户的对象存储，还部署 RGW 服务）。网关运行 CephFS 客户端来访问 Ceph 公共网络，且受管理而非最终用户控制。

NFS-Ganesha 在其自身的 docker 容器中运行，它们与 Ceph 公共网络和新的隔离网络 StorageNFS 接口。OpenStack director 的可组合网络功能用于部署此网络并将其连接到控制器节点。然后，云管理员将网络配置为 neutron 提供商网络。

NFS-Ganesha 通过 Ceph 公共网络访问 CephFS，并使用 StorageNFS 网络上的地址绑定其 NFS 服务。

要访问 NFS 共享，用户 VM (nova 实例)会置备连接到存储 NFS 网络的额外 NIC。使用 NFS-Ganesha 服务器的 VIP，CephFS 共享导出位置显示为标准 NFS IP:<path > tuples。用户虚拟机的访问控制是使用该网络上的用户虚拟机的 IP 进行。

Neutron 安全组可防止属于租户 1 的用户虚拟机访问属于 StorageNFS 网络租户 2 的用户虚拟机。租户共享相同的 CephFS 文件系统，但强制实施租户数据路径，因为用户虚拟机只能访问导出树下的文件： /path/to/share1/….、/path/to/share2/…。

当 OpenStack director 启动 Ceph 服务守护进程时，它们管理自己的高可用性(HA)状态，一般情况下，这些守护进程的多个实例正在运行。相反，在这个发行版本中，一次只有一个 NFS-Ganesha 实例才能为文件共享提供服务。

为通过 NFS 共享避免 CephFS 的数据路径中的单点故障，NFS-Ganesha 在由 Pacemaker-Corosync 集群管理的主动 - 被动配置中运行 OpenStack 控制器节点。NFS-Ganesha 在作为虚拟服务 IP 地址的虚拟服务间充当控制器节点。

如果控制器出现故障（或者特定控制器节点上的服务失败且无法在该节点上恢复），Pacemaker-Corosync 会在使用相同虚拟 IP 的不同控制器上启动一个新的 NFS-Ganesha 实例。现有客户端挂载会被保留，因为它们使用虚拟 IP 作为共享的导出位置。

失败后，使用默认 NFS mount-option 设置和 NFS 4.1 或更高版本，TCP 连接会被重置，客户端重新连接。I/O 操作在故障切换过程中临时停止响应，但它们不会失败。应用程序 I/O 也停止响应，但在故障转移完成后恢复。

新的连接、新的锁定状态等会被拒绝，直到宽限期达到 90 秒后，服务器会等待客户端回收其锁定。NFS-Ganesha 保留客户端列表，如果它发现所有客户端回收了锁定，则会退出宽限期。