除了 monitor、OSD、RGW 和 manager 服务在使用 Ceph 提供对象和块存储时，需要 Ceph 元数据服务(MDS)和 NFS-Ganesha 服务作为使用 NFS 协议的原生 CephFS 的网关时。对于面向用户的对象存储，也会部署 RGW 服务。网关运行 CephFS 客户端来访问 Ceph 公共网络，并由管理员而不是最终用户进行控制。

NFS-Ganesha 在自己的容器中运行，它们同时连接到 Ceph 公共网络和新的隔离网络 StorageNFS。Red Hat OpenStack Platform(RHOSP)director 的可组合网络功能会部署这个网络，并将其连接到 Controller 节点。作为云管理员，您可以将网络配置为 Networking(neutron)提供商网络。

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

要访问 NFS 共享，请置备用户 VM、Compute(nova)实例，以及一个连接到存储 NFS 网络的额外 NIC。CephFS 共享的导出位置显示为标准 NFS IP:<path> 元组，它们使用 StorageNFS 网络上的 NFS-Ganesha 服务器 VIP。网络使用用户虚拟机的 IP 地址对 NFS 共享执行访问控制。

网络(neutron)安全组阻止属于项目 1 的用户虚拟机访问通过 StorageNFS 属于项目 2 的用户虚拟机。项目共享相同的 CephFS 文件系统，但实施项目数据路径分离，因为用户虚拟机只能访问导出树下的文件：/path/to/share1/…., /path/to/share2/….

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

为避免通过 NFS 共享进行 CephFS 数据路径中的单点故障，NFS-Ganesha 在由 Pacemaker-Corosync 集群管理的主动被动配置中运行在 RHOSP Controller 节点上运行。NFS-Ganesha 使用虚拟服务 IP 地址来跨 Controller 节点充当虚拟服务。

如果一个 Controller 节点失败或者特定 Controller 节点上的服务失败，且无法在那个节点上恢复，Pacemaker-Corosync 会使用同一虚拟 IP 地址在不同的 Controller 节点上启动新的 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 roles generate 命令的更多信息，请参阅高级 Overcloud 自定义指南中的角色。

openstack overcloud roles generate 命令创建一个自定义 roles_data.yaml 文件，包括 -o 指定的服务。在以下示例中，创建的 roles_data.yaml 文件具有 ControllerStorageNfs、Compute 和 CephStorage 的服务。

使用可组合网络定义自定义网络并将其分配到任何角色。您可以使用 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
name_lower: storage_nfs
vlan: 70
ip_subnet: '172.17.0.0/20'
allocation_pools: [{'start': '172.17.0.4', 'end': '172.17.0.250'}]
ipv6_subnet: 'fd00:fd00:fd00:7000::/64'
ipv6_allocation_pools: [{'start': 'fd00:fd00:fd00:7000::4', 'end': 'fd00:fd00:fd00:7000::fffe'}]

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

用于定义 CephFS 后端 manila-cephfsganesha-config.yaml 的集成式环境文件位于 /usr/share/openstack-tripleo-heat-templates/environments/ 中。

manila-cephfsganesha-config.yaml 环境文件包含与部署共享文件系统服务(manila)相关的设置。后端默认设置可用于大多数环境。以下示例显示了 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: ../deployment/manila/manila-api-container-puppet.yaml
  OS::TripleO::Services::ManilaScheduler: ../deployment/manila/manila-scheduler-container-puppet.yaml
  # Only manila-share is pacemaker managed:
  OS::TripleO::Services::ManilaShare: ../deployment/manila/manila-share-pacemaker-puppet.yaml
  OS::TripleO::Services::ManilaBackendCephFs: ../deployment/manila/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: ../deployment/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::Services::ManilaBackendCephFs 设置的值，它为 CephFS 后端设置默认值。

有关环境文件的更多信息，请参阅 Director 安装和使用指南中的环境文件。

将新隔离存储NFS 网络映射到网络(neutron)提供商网络。Compute 虚拟机附加到网络，以访问由 NFS-Ganesha 网关提供的共享导出位置。

有关使用共享文件系统服务的网络安全性 ，请参阅安全和强化指南中的强化共享文件系统服务。

在 neutron-shared 提供商网络上创建对应的 StorageNFSSubnet。确保子网与 network_data.yml 文件中的 storage_nfs 网络定义相同，并确保 StorageNFS 子网的分配范围不会重叠。不需要网关，因为 StorageNFS 子网专用于提供 NFS 共享。

[stack@undercloud-0 ~]$ openstack subnet create --allocation-pool start=172.17.0.4,end=172.17.0.250 --dhcp --network StorageNFS --subnet-range 172.17.0.0/20 --gateway none StorageNFSSubnet

[stack@undercloud-0 ~]$ openstack subnet create --ip-version 6 --dhcp --network StorageNFS --subnet-range fd00:fd00:fd00:7000::/64 --gateway none --ipv6-ra-mode dhcpv6-stateful --ipv6-address-mode dhcpv6-stateful StorageNFSSubnet -f yaml

您可以使用共享文件系统服务定义可用于使用特定设置创建共享的共享类型。共享类型的工作方式，如块存储卷类型。每种类型都有相关的设置，例如额外的规格。当您在创建共享期间调用类型时，设置会应用到共享文件系统。

使用 Red Hat OpenStack Platform(RHOSP)director，您必须在打开云前创建一个默认共享类型，供用户访问。对于带有 NFS 的 CephFS，请使用 manila type-create 命令：

$ manila type-create default false

有关共享类型的更多信息 ，请参阅存储指南中的创建共享类型。