Nautilus新特性: CephFS改进

在Ceph Nautilus版本中对CephFS文件系统做了改善。与CEPH的其他部分一样，我们一直在投入大量的开发人员时间来改进可用性和稳定性。以下各节将详细介绍这些工作

 

1. MDS稳定性

在过去的两个版本中，MDS稳定性一直是开发人员的主要关注点。我们最近发现的一个问题是，具有非常大缓存（64+GB）的MDS将在某些恢复事件期间挂起。例如，当MDS试图减小其缓存大小以遵守“mds_cache_memory_limit”时，会要求客户端释放一些capabilities，MDS计算要删除的capabilities的所需比率，并要求每个客户端这样做。但是，大型MDS可能具有数千万个capabilities outstanding，单个长时间运行的客户机可能拥有数百万个。一次查看所有发布消息的时间可能会导致MDS无法进行实际工作，甚至导致监视器将使用Standby MDS替换该MDS。

从两个方向解决了这个问题：

1. MDS现在限制了从客户客端调用capabilities的速度，以便缓存大小的突然减少（由于配置更改）或大型客户端缓存不会使MDS不稳定。这种行为是通过这些新的配置变量来控制的：mds_recall_max_caps, mds_recall_max_decay_rate, mds_recall_max_decay_threshold, mds_recall_global_max_decay_threshold, mds_recall_warning_threshold, mds_recall_warning_decay_rate。已经仔细选择了默认值；我们不希望管理员需要更改它们。每个选项的描述都记录了其作用。

2. MDS现在限制了单个客户端可以拥有的capabilities数量。这是通过新的mds_max_caps_per_client配置变量控制的。MDS将从超过此限制客户端的capabilities，恢复到限制之下。客户端的版本无关紧要。

还有一些正在进行的工作，通过让客户自己自愿释放不再使用的功能来解决这个问题。

CephFS的用户在使用非常大的缓存操作时，应该希望看到MDS以更可预测的方式运行。此外，MDS将不再容忍拥有数百万个上限的客户端，这些上限在恢复事件期间或MDS缓存大小发生较大变化时会导致自身问题。

2. NFS Ganesha网关群集

Ganesha是一个用户空间NFS服务器，用于导出本地文件系统和其他存储系统的解决方案。其中CephFS文件系统是Ganesha支持导出的文件系统类型之一。势必导致想NFS客户端公开Ceph文件系统，这可能是出于许多原因（包括存储群集隔离、安全性和遗留应用程序）所需要的。

CEPH的Nautilus版本使NFS Ganesha成为集群中的重要组件，从头到尾都由Ceph管理生命周期。就像与Rook operator和kubernetes一起，Ceph创建Nfs-Ganesha守护进程集群，以导出Ceph文件系统。

Ganesha集群中的每个守护进程都被配置为以active-active方式导出相同的文件系统。这意味着多个NFS服务器可以将客户端的请求负载平衡到同一个CEHFS文件系统。在Nautilus之前，这是一个不安全的配置（手动完成），因为故障转移可能会丢失NFS客户端状态。

使设置这些集群成为尽可能多的万能钥匙的工作还在进行中。我们预计在未来几个月内，许多用户界面更改将被重新移植到Nautilus。与此同时，Jeff Layton的博客文章中也提供了一个实践演示。

3 Changes to Standby Replay

在CephFS中配置“standby replay”守护进程的机制已被改写。standby replay守护进程实时跟踪活动MDS的日志，从而在Active MDS停机时实现非常快速的故障转移。在Nautilus之前，需要使用mds_standby_replay选项配置守护进程，以便mds可以作为备用replay运行。监视器将接收来自这些MDS守护进程的消息，指示它们能够在standby-replay中运行，然后将它们的ranks分配给后续的MDS（如果可用）。

这与其他文件系统配置是有区别的，这些配置通常通过CephFS命令套件进行更改；配置MDS会影响Monitor导致颠倒决策。相反，让操作人员指示哪些文件系统应该具有备用standby-replay程序更简单。另外，只为某些Rank使用standby-replay守护进程是没有意义的。

新文件系统设置allow_standby_replay会使文件系统启用standby-replay。只要有备用守护进程可用，Monitor就会将它们分配给文件系统上的可用Rank。

standby-replay守护进程计数会趋向于文件系统所需的Standby计数，后者由“standby_count_wanted”配置。确保配置此参数以跟踪对“max_mds”的更改，以便有足够的standby。对于standby-replay守护进程，建议将其设置为至少“max_mds+1”。因此，可以使用一个普通的standby-replay进程来替换备用的standby-replay进程。

最后，还有一些配置选项，允许操作人员指定要遵循的文件系统、ranks或命名的MDS。这些配置选项是“mds_standby_for_*。这些选项已在Nautilus中废弃，因此所有MDS都得到统一和平等的处理。

4. cephfs-shell工具

Cephfs有两个主要的访问工具：ceph-fuse客户端和Linux内核驱动程序。现在，Pavani Rajula在2018年夏天用python编写了一个新的cephfs-shell工具。该工具允许用户通过自定义shell在文件系统上执行简单的操作。例如

CephFS:~/>>> mkdir foo
CephFS:~/>>> put /etc/hosts foo/hosts
CephFS:~/>>> cat foo/hosts
127.0.0.1       localhost

# The following lines are desirable for IPv6 capable hosts
::1     localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouter
CephFS:~/>>>

请记住，cephfs-sheel是alpha-quality软件，可能有缺陷。我们定期向Nautilus移植修复程序，最受欢迎的是社区关于改进的想法（在CEPH用户邮件列表中）。

 

5. Blacklisting Older Clients

如在版本Mimic v13.2.2+中，CephFS现在允许集群管理员阻止旧客户端装载文件系统。这对黑名单版本很有帮助，因为它们在某些方面行为不当（例如，not releasing capabilities）。

这是使用新的文件系统设置完成的：

ceph fs set tank min_compat_client mimic

一旦完成，MDS将黑名单和驱逐旧客户端，并阻止他们在未来连接。