所有的计算都提供服务,而提供服务之后一定要有数据放在一个地方,这个地方就是Ceph。

 

看看存储发展的过程——基本上是从本地存储到分布式存储的过程。为什么我们需要软件定义存储?首先可以看到最开始我们的数据只需要存在几块或者十几块硬盘里面就可以了,这种场景下可以采用直联式存储。但是数据越来越多我们发现需要集中式存储,到后来又不够用了就产生虚拟化,包括SAN、FC、iSCSI。现在出现了PB级海量存储,数据中心也显得有点力不从心,所以我们采用了软件定义存储。

 

时代发展需要分布式存储,分布式存储现在有很多方案。这里展示了现在比较流行的开源分布式存储方案的对比。

 

现在的开源分布式存储一般包括三种存储:块存储、对象存储、文件存储。前面都是适用场景——块存储就是虚拟机存储;对象存储是云网盘、媒体数据存储,Ceph提到以后所有的存储都会在对象存储里面;文件存储是NAS、大数据、家庭存储。

 

我们看一下特点——块存储的特点是IOPS要求高,可靠性要求高,配合云计算方案;对象存储特点是吞吐量要求较高,因为对象存储数据量非常多;文件存储特点是应用比较广泛。

 

主要看一下开源存储方案的发展情况,对比一下各个模型解决方案的情况。

 

Ceph是最好的块存储开源软件,随着OpenStack的流行慢慢活起来的。现在,Ceph已经基本是块存储领域的事实标准;对象存储方面Swift和Ceph最出色;文件存储现在Gluster最成熟,Ceph有发展潜力。

 

从我们对比的情况来看,Ceph是唯一一个提供统一的三种存储接口的开源解决方案,所以我们在应用场景里面首选Ceph。

 

既然我们选择了Ceph,那就看一下Ceph在数据安全、功能、性能这三个比较重要的方面的表现情况。

 

第一个是数据安全。Ceph本身是一个高可用的工作存储解决方案。它是分布式存储,有很多存储节点,而存储节点我们一般使用多副本的方式进行存储。

 

在使用三不管的情况下,两个硬盘在不同的节点,两块硬盘同时工作,这种情况出错的可能性非常小。而且当一个硬盘坏掉之后,Ceph会自动把这个硬盘下线。

 

另一种情况是硬盘没有坏,但整个节点是坏的。这种情况也不用担心,Ceph会尽量按副本默认的规则直接把副本分布在不同的节点上面,所以有一两个节点不行了并不会影响到数据。现在有三个机位,每个机位两台机柜,我们通过Ceph平均分布在三个节点不同的时段上面,可以达到同样的结果。

 

Ceph能够保证在磁盘损坏的过程中数据不会丢失,而且保证业务是高可用的。

 

还有一种情况是整个数据中心down掉了,就是数据中心发生灾难的情况下还要保证数据有用的话,就涉及到容灾的问题。

 

ACTIVE和PASSIVE是一种快速的容灾方案,ACTIVE和PASSIVE之间还有一个SYNC的状态。这是现在社区里面一个很重要的发展方向,所以我会讲得比较详细一点。

 

可以看一下rbd mirroring配置,在这个地方可以从rbd的pool把模式打开。第一步就是把模式打开,另外要加一个Peers。做完这两步之后你就可以看到第三条命令,即察看它的信息。

 

看一下这些命令到底做了什么事情。User执行这条命令,直接把这件事情交给rbd command命令,到librbd,再到cls-client然后到cls。osd而里面有一个模块是cls,类似于rdc的调用关系。这边会给它发一个命令叫POOL,然后执行set,最后执行cls,其实就是设置了一个原数据。然后再返回,返回到notify,返回到notify后整个流程基本就结束了。这是第一个比较简单的操作流程。

 

下面我们来看一下rdb-mirror。它相当于另外一个服务,整个架构是这样的形式。所有数据同步都由rdb-mirror来做的。可以看一下它分为五个模块。第一个是Mirror模块。这个模块主要就是local,里面有两个变量比较重要。其中一个是cluster watcher,它监控到rdb-mirror的东西;另一个是deleter。整体架构其实很简单,replayers指向一个POOL,这个POOL带动然后形成一个新的Mirror。

 

从这里面可以发现最明显的问题是只有一个Watcher,说明它们的同步不是基于通知的机制,而是通过轮询的机制来发现问题的。这样做的话,即使很长时间没有改动也会一直轮询,造成资源的巨大消耗。


除了rdb-mirror之外还有一个比较重要的问题就是rdb-mirror刚刚引进的时候是没有高可用的。两个技术中间可以做镜像,但是镜像只有一个服务,会造成很大的问题。这对安全性要求很高,如果只有一个服务,那整个数据就跑掉了。rdb-mirror在监管发布之后,整个团队一直在做rdb-mirrorHA。目前还有一个问题没有办法解决,因此rdb-mirror对于一个Cluster来说就是一个客户。

 

第二个是功能。

 

先说一下iscsi。iscsi有三种,第一个是Tgt+librbd,第二个是Scst+kernel rbd,第三个是Lio-tcmu+librbd。iscsi特性支持,第一个是Normal,第二个也是Normal,第三个是Good;Rbd特性支持一是Good,二是Bad,三是Good;稳定性一是Good,二是Normal,三是Normal;性能方面一是Normal,二是Good,三是Good。

 

第二个问题是namespace,它主要解决的问题是当一个用户使用一个Pool的时候,另外一个用户也要使用Pool,如果没有办法隔开他们两个是比较危险的,所以我们使用namespace,不同的用户使用不同的Pool。


第三个是性能。

 

首先是参数优化方面,分网络方面和磁盘方面。

 

网络方面我们做了两方面的工作,MTU设置为9000。使用iperf测试宽带可以看到优化效果,宽带提升约8.88%。磁盘方面优化很大,最后达到的效果是1.4W+2.1W。

 

第二部分就是cache方案,因为现在SSD越来越普及了,我们把一个SSD做好几个盘的划分,得到的结果非常不错,几乎翻了一倍。

 


还有引擎优化。

 

这是我们测试的结果,这个结果很不理想,但是我们测试的结果是Jewel的FileStore和Kraken版的FileStore,有40%的提升。

 

以上就是我今天分享的内容,谢谢大家!

 

投稿邮箱:openstackcn@sina.cn