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将黑名单和驱逐旧客户端,并阻止他们在未来连接。

发布了276 篇原创文章 · 获赞 134 · 访问量 105万+

猜你喜欢

转载自blog.csdn.net/iamonlyme/article/details/99227656