为什么Ceph比Glusterfs更适合接入k8s

如果团队不是实在搞不定ceph的话,个人建议,现阶段不建议k8s的后端存储使用glusterfs. 因为问题比较多.

首先说明一下,glusterfs这种无中心架构,节点之间采用全互联模式的,也就意味着通信带宽消耗要求会比master/slave这种高很多.

另外glusterfs更加适合做冷数据存储集群,也就是一些重要数据压缩打包以后放在那里.我们这边目前使用glusterfs集群发现,很多上层应用的支持非常不好,例如nexus官方已经明确说明不支持该存储了.还有很多虽然没有明确说明,但是其实对glusterfs这种架构的支持度是不太友好的.

还有很重要一点,glusterfs的生态远远没有ceph的好,虽然现在glusterfs官方版本也出到9.x了,但是像heketi这样的工具,用来k8s管理glusterfs集群增删改glusterfs的volume的,这玩意目前已经停止维护了.还有glusterfs-exporter,这个的监控工具,官方也停止维护了.这段时间使用就发现了一些问题,例如exporter这种居然不是每个节点收集的信息一样的,会查看glusterfs所有节点的uuid,然后找到默认最大的那个才是收集最全面的信息的,其他节点是会缺少一些信息.这个内容官方就没有很明确提出来,只是建议让你在所有节点都部署exporter,但是那样对集群来说其实负担比较大的,因为一个volume status命令是需要所有节点来通信的.如果两三百个volume,然后每个volume都来一下,想想这个通信量就很可观了.

接着,对于glusterfs来说,这玩意对linux文件系统的关联度实在很大,里面有超级多的参数,云里雾里的,甚至官方也不一定能完全给出可靠的解释,例如open-behind,这个参数官方说是对于打开文件句柄那块有优化的,但是我们使用的时候发现了很多bug,在7.7及之前的版本,会出现文件句柄异常这样的问题,导致挂载中断,这在k8s里面会导致pod不断重启的.但是到底这玩意是怎么生效的,作用如何,查过很多资料,目前还不明确,当然可能也是个人理解水平问题.

当然也想说一点,现在去各大app上买书的话,glusterfs目前没有一本书!这是重点,意味着你想深入理解这个工具,只能靠网上的资料或者源码了,而网上的内容,大部分还是3.x版本的,现在已经9.x了.同时国内懂这个的真的很少很少.所以你想找懂优化的人,那就更少了...还有就是虽然官方在github上给出了doc文档,但是我看了其中的一部分,很多内容讲的太生涩难懂了,有些内容如果你不是对fuse那些非常熟悉的话,估计都不知道那玩意在干嘛.

所以真的,大部分情况下,ceph都是目前k8s集群比较好的选择,至少会比glusterfs这边好很多,当然未来不敢说,至少目前现阶段,glusterfs的生态还是有很多很多问题的.

上一篇:Ceph集群与Ceph块存储


下一篇:。 (有些情况下通过 lsof(8) 或 fuser(1) 可以 找到有关使用该设备的进程的有用信息)