除了监控器外，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 保留客户端列表，如果它发现所有客户端回收了锁定，则会退出宽限期。

ControllerStorageNFS 自定义角色用于设置隔离的 StorageNFS 网络。此角色类似于默认的 Controller.yaml 角色文件，其添加 StorageNFS 网络和 CephNfs 服务（由 OS::TripleO::Services:CephNfs表示）。

[stack@undercloud ~]$ cd /usr/share/openstack-tripleo-heat-templates/roles
[stack@undercloud roles]$ diff Controller.yaml ControllerStorageNfs.yaml
16a17
> 	- StorageNFS
50a45
> 	- OS::TripleO::Services::CephNfs

如需有关 openstack overcloud 角色 generate 命令的信息，请参阅高级 Overcloud 自定义指南中的 Roles 部分。

可组合网络允许您定义自定义网络，并将它们分配给任何角色。StorageNFS 可组合网络使用 network_data_ganesha.yaml 文件来配置 StorageNFS 可组合网络，而不是使用标准 network_data.yaml 文件。这两个角色都位于 /usr/share/openstack-tripleo-heat-templates 目录中。

network_data_ganesha.yaml 文件包含定义隔离的 StorageNFS 网络的额外部分。虽然默认设置适用于大多数安装，但您仍需要编辑 YAML 文件来添加网络设置，包括 VLAN ID、子网等。

name: StorageNFS
enabled: true
vip: true
ame_lower: storage_nfs
vlan: 70
ip_subnet: '172.16.4.0/24'
allocation_pools: [{'start': '172.16.4.4', 'end': '172.16.4.250'}]
ipv6_subnet: 'fd00:fd00:fd00:7000::/64'
ipv6_allocation_pools: [{'start': 'fd00:fd00:fd00:7000::10', 'end': 'fd00:fd00:fd00:7000:ffff:ffff:ffff:fffe'}]

如需有关可组合网络的更多信息，请参阅高级 Overcloud 自定义指南中的 使用 可组合网络章节。

用于定义 CephFS 后端的集成式环境文件位于 undercloud 节点的以下路径中：

/usr/share/openstack-tripleo-heat-templates/environments/manila-cephfsganesha-config.yaml

manila-cephfsganesha-config.yaml 环境文件包含与共享文件系统服务部署相关的设置。后端默认设置可用于大多数环境。这个示例显示了部署共享文件系统服务时 director 使用的默认值：

[stack@undercloud ~]$ cat /usr/share/openstack-tripleo-heat-templates/environments/manila-cephfsganesha-config.yaml
# A Heat environment file which can be used to enable a
# a Manila CephFS-NFS driver backend.
resource_registry:
  OS::TripleO::Services::ManilaApi: ../docker/services/manila-api.yaml
  OS::TripleO::Services::ManilaScheduler: ../docker/services/manila-scheduler.yaml
  # Only manila-share is pacemaker managed:
  OS::TripleO::Services::ManilaShare: ../docker/services/pacemaker/manila-share.yaml
  OS::TripleO::Services::ManilaBackendCephFs: ../puppet/services/manila-backend-cephfs.yaml
  # ceph-nfs (ganesha) service is installed and configured by ceph-ansible
  # but it's still managed by pacemaker
  OS::TripleO::Services::CephNfs: ../docker/services/ceph-ansible/ceph-nfs.yaml

parameter_defaults:
  ManilaCephFSBackendName: cephfs 1
  ManilaCephFSDriverHandlesShareServers: false 2
  ManilaCephFSCephFSAuthId: 'manila' 3
  ManilaCephFSCephFSEnableSnapshots: false 4
  # manila cephfs driver supports either native cephfs backend - 'CEPHFS'
  # (users mount shares directly from ceph cluster), or nfs-ganesha backend -
  # 'NFS' (users mount shares through nfs-ganesha server)
  ManilaCephFSCephFSProtocolHelperType: 'NFS'

parameter_defaults 标头表示配置的开头。具体来说，此标题下的设置可让您覆盖 resource_registry 中设置的默认值。这包括 OS::Tripleo::Services::ManilaBackendCephFs 设置的值，后者为 CephFS 后端设置默认值。

有关环境文件的更多信息， 请参阅高级 Overcloud 自定义指南中的 环境文件。

新的 isolated StorageNFS 网络必须映射到 neutron-shared 提供商网络。Compute 虚拟机将附加到此 neutron 网络，以访问由 NFS-Ganesha 网关提供的共享导出位置。

有关使用共享文件系统服务网络安全的一般信息，请参阅《 安全和强化指南》中强化 共享文件系统服务 的章节。

要使用这个命令：

在 neutron 共享提供商网络上创建对应的 StorageNFSSubnet。确保子网与 undercloud 中的 storage_nfs_subnet 相同，但请确保此子网的分配范围和对应的 undercloud 子网没有重叠。不需要网关，因为此子网专用于提供 NFS 共享。

[stack@undercloud-0 ~]$ openstack subnet create --allocation-pool start=172.16.4.150,end=172.16.4.250 --dhcp --network StorageNFS --subnet-range 172.16.4.0/24 --gateway none StorageNFSSubnet
+-------------------+--------------------------------------+
| Field         	  | Value
+-------------------+--------------------------------------+
| allocation_pools  | 172.16.4.150-172.16.4.250
| cidr            	| 172.16.4.0/24
| created_at    	  | 2018-09-17T21:22:14Z
| description   	  |
| dns_nameservers   |
| enable_dhcp   	  | True
| gateway_ip    	  | None
| host_routes   	  |
| id            	  | 8c696d06-76b7-4d77-a375-fd2e71e3e480
| ip_version    	  | 4
| ipv6_address_mode | None
| ipv6_ra_mode  	  | None
| name          	  | StorageNFSSubnet
| network_id      	| cd272981-0a5e-4f3d-83eb-d25473f5176e
| project_id      	| 3ca3408d545143629cd0ec35d34aea9c
| revision_number   | 0
| segment_id    	  | None
| service_types 	  |
| subnetpool_id 	  | None
| tags          	  |
| updated_at    	  | 2018-09-17T21:22:14Z
+-------------------+--------------------------------------+

共享文件系统服务允许您定义可用于创建与特定设置的共享类型。共享类型（如 Block Storage 卷类型）：每种类型都有关联的设置（名称、额外规格），并在共享创建期间调用类型应用这些设置。

OpenStack director 需要一个 default 共享类型。在打开云才能访问之前，必须创建此默认共享类型。对于使用 NFS 的 CephFS，请使用 manila type-create 命令：

manila type-create default false

有关共享类型的信息，请参阅《 存储指南》的" 创建和管理 共享类型"部分。