要成功部署 NFS Ganesha，需要将 role-ganesha 添加到 /srv/pillar/ceph/proposals/policy.cfg。有关详细信息，请参见第 5.5.1 节 “policy.cfg 文件”。要使用 NFS Ganesha，还需要在 policy.cfg 中指定 role-rgw 或 role-mds。

尽管可以在现有的 Ceph 节点上安装并运行 NFS Ganesha 服务器，但建议在能够访问 Ceph 集群的专用主机上运行该服务器。客户端主机通常不是集群的一部分，但需要能够通过网络访问 NFS Ganesha 服务器。

要在完成初始安装后随时启用 NFS Ganesha 服务器，请将 role-ganesha 添加到 policy.cfg，并至少重新运行 DeepSea 阶段 2 和 4。有关详细信息，请参见第 5.3 节 “集群部署”。

NFS Ganesha 是通过 NFS Ganesha 节点上的 /etc/ganesha/ganesha.conf 文件配置的。但是，每次执行 DeepSea 阶段 4，都会重写此文件。因此，建议编辑 Salt 使用的模板，即 Salt Master 上的 /srv/salt/ceph/ganesha/files/ganesha.conf.j2 文件。有关配置文件的详细信息，请参见第 21.2 节 “配置”。

在执行 DeepSea 阶段 2 和 4 来安装 NFS Ganesha 之前，必须满足以下要求：

在此设置中，earth 的 IP 地址为 192.168.1.1，mars 的地址为 192.168.1.2。

此外，使用了两个浮动虚拟 IP 地址，这样无论服务在哪个物理节点上运行，客户端都可连接到服务。192.168.1.10 用于通过 Hawk2 进行集群管理，192.168.2.1 专门用于 NFS 导出项。这样，以后便可更轻松地应用安全限制。

以下过程介绍示例安装。https://www.suse.com/documentation/sle-ha-15/book_sleha_quickstarts/data/art_sleha_install_quick.html 上提供了更多详细信息。

如果其中一个节点（例如 earth）上发生 NFS Ganesha 故障，请解决问题并清理资源。如果 NFS Ganesha 在 mars 上发生故障，则只有在清理资源之后，该资源才能故障回复到 earth。

要清理资源，请执行以下命令：

root@earth # crm resource cleanup nfs-ganesha-clone earth
root@earth # crm resource cleanup ganesha-ip earth

有时，服务器可能由于网络问题而无法访问客户端。Ping 资源可以检测并缓解此问题。配置此资源的操作是可选的。

DeepSea 不支持配置 NFS Ganesha HA。为了防止在配置 NFS Ganesha HA 之后 DeepSea 失败，请从 DeepSea 阶段 4 中排除 NFS Ganesha 服务的启动和停止：

对于该示例配置，您需要拥有以下资源：

部署 NFS Ganesha 节点之后，请确认集群是否可运作，并且存在默认的 CephFS 存储池：

cephadm@adm > rados lspools
cephfs_data
cephfs_metadata

检查两个 NFS Ganesha 节点是否安装了文件 /etc/ganesha/ganesha.conf。将以下段落（如果尚未存在）添加到配置文件中，以便将 RADOS 作为 NFS Ganesha 的恢复后端。

NFS_CORE_PARAM
{
    Enable_NLM = false;
    Enable_RQUOTA = false;
    Protocols = 4;
}
NFSv4
{
    RecoveryBackend = rados_cluster;
    Minor_Versions = 1,2;
}
CACHEINODE {
    Dir_Chunk = 0;
    NParts = 1;
    Cache_Size = 1;
}
RADOS_KV
{
    pool = "rados_pool";
    namespace = "pool_namespace";
    nodeid = "fqdn"
    UserId = "cephx_user_id";
    Ceph_Conf = "path_to_ceph.conf"
}

您可以检查配置格式如下的现有行，以确定 rados_pool 和 pool_namespace 的值：

%url rados://rados_pool/pool_namespace/...

nodeid 选项的值与计算机的 FQDN 相对应，并且 UserId 和 Ceph_Conf 选项值可在已存在的 RADOS_URLS 段落中找到。

由于旧版 NFS 不允许我们通过将宽限期提前来延长服务器重启动过程，我们在早于 4.2 的版本中禁用了 NFS 选项。此外，我们还禁用了大多数 NFS Ganesha 缓存，因为 Ceph 库已经在使用激进缓存模式。

“rados_cluster”恢复后端将其信息存储在 RADOS 对象中。尽管数据量不大，我们仍希望其具有高可用性。出于此目的，我们使用 CephFS 元数据存储池，并在其中声明一个新的“ganesha”名称空间，使其不同于 CephFS 对象。

注意：集群节点 ID

两个主机的大多数配置都是相同的，不过，各节点“RADOS_KV”段落中的 nodeid 选项需要设置为不同的字符串。NFS Ganesha 默认会将 nodeid 设置为节点的主机名。

如果您需要使用主机名以外的其他固定值，可以在一个节点上设置 nodeid = 'a'（示例设置），在另一个节点上设置 nodeid = 'b'。

我们需要确认集群中的所有节点都知道彼此的存在。此目的通过在主机之间共享的 RADOS 对象来实现。NFS Ganesha 使用此对象传达与宽限期有关的当前状态。

此 nfs-ganesha-rados-grace 包包含一个用于查询和操作此数据库的命令行工具。如果至少有一个节点上未安装该包，请运行以下命令加以安装：

root # zypper install nfs-ganesha-rados-grace

我们将使用该命令来创建数据库并添加两个 nodeid。在本示例中，两个 NFS Ganesha 节点分别命名为 ses6min1.example.com 和 ses6min2.example.com。在其中一个 NFS Ganesha 主机上运行以下命令：

cephadm@adm > ganesha-rados-grace -p cephfs_metadata -n ganesha add ses6min1.example.com
cephadm@adm > ganesha-rados-grace -p cephfs_metadata -n ganesha add ses6min2.example.com
cephadm@adm > ganesha-rados-grace -p cephfs_metadata -n ganesha
cur=1 rec=0
======================================================
ses6min1.example.com     E
ses6min2.example.com     E

此命令会创建宽限数据库，并向其添加“ses6min1.example.com”和“ses6min2.example.com”。最后一个命令可转储当前状态。新添加的主机始终被视为将强制执行宽限期，因此会为它们设置“E”标志。“cur”和“rec”值显示当前和恢复版本号，我们通过这种方法来跟踪允许主机恢复的内容以及时间。

在两个 NFS Ganesha 节点上，重启动相关服务：

root # systemctl restart nfs-ganesha.service

服务重启动后，检查宽限数据库：

cephadm@adm > ganesha-rados-grace -p cephfs_metadata -n ganesha
cur=3 rec=0
======================================================
ses6min1.example.com
ses6min2.example.com

注意：清除了“E”标志

请注意，两个节点均已清除其“E”标志，表示它们不再强制实施宽限期，并且现在处于正常操作模式。

完成上述所有步骤之后，您可以装入从这两个 NFS Ganesha 服务器中的任意一个导出的 NFS，并对它们执行常规 NFS 操作。

我们的示例配置假设，如果这两个 NFS Ganesha 服务器中的其中一个变为停用状态，您将在 5 分钟内手动将其重启动。5 分钟后，元数据服务器可能会取消 NFS Ganesha 客户端拥有的会话以及与其关联的所有状态。如果在集群的其余节点进入宽限期之前取消该会话的功能，服务器的客户端可能无法恢复其所有状态。