基于NVMe Over TCP的分层存储架构设计

背景 

互联网,物联网,人工智能等现代科技的发展和大规模应用,使得产生的数据规模呈现难以预测的爆炸性增长。在这种背景下,数据的存储和使用也遇到了新的挑战。为了应对新的挑战,在具体的存储技术,以及应用架构这两个方面都产生了巨大的进步。在存储技术方面,发展的主要方向是提供更高性能,更高密度的存储介质和访问方式,Flash以及专为其设计的NVMe协议无疑是这个领域中最重要的一个。而在应用架构方面,通常是存储,计算,网络三个方面的协调,如何提高资源的利用率,充分发挥出这三个要素的性能,容量以及提供充分的灵活性以满足各种应用场景是设计的关键,在这一方面,今年来超大规模数据中心以及云技术的发展充分展现了其在这方面的优势。本文主要探讨如何利用最先进的存储技术以及最先进的应用架构这两方面的发展来提升存储系统的设计.

我们先看一下超大规模数据中心是怎么做的,首先是解耦合(disaggregation)和资源池化(Resource pooling), 这样不仅大大提高了计算和存储资源的利用率,而且也解决了应用的灵活扩展,存储需求动态变化的需要。同时在资源管理方面也大大简化,各种应用需要多少资源就从各个资源池申请相应数量,不够了再去拿一点,用完了就释放到池中,而管理者也只要监控整个资源池的使用使用率。超大型数据中心另一个做法就是功能分层实现,把一些共同的基础功能放在底层,而上层专注于业务相关的功能实现。那我们是不是可用借鉴一下把这套理念应用到存储系统中呢?我们接下来深入探讨一下(事实上很多数据中心已经在这么做了).
分层存储架构设计

图表 1:双层存储架构设计

 

在一般使用场景下,是存储盘直接连到服务器主机上提供并不可靠,并不具备扩展性的块存储(block storage),然后在其上根据不同的业务需求再构建各种不同的更高级的存储解决方案,这些方案有些是提供可靠块存储的,文件存储,对象存储的,各类数据库等。而这些上层应用存储解决方案一般都需要解决几个共同的问题:高可靠,高可用,可扩展,数据加密压缩等。为了解决这些共同问题,借鉴当今大型数据中心的思路,提出了分层的存储架构设计,在底层构建一层高可靠,高可用,可扩展,并且充分理解物理存储设备特性并为之优化的块存储层。在此基础上再根据不用的应用需要构建与之适应的应用存储方案,这些上层应用存储主要考虑为各种不同的应用而优化,而不用关注存储硬件本身可靠性,扩展性等。

 

分层存储架构优点分析

具体来说,这种分层的架构有如下几个优点:

1. 简化应用/业务相关的存储层设计,优化性能

比如文件系统,对象数据库等,不需要操心数据可靠性,可用性,存储资源的扩展性等问题。在相同的成本下提高性能,性能提高来源于两个方面,一是因为在架构设计中,通常越是上层和应用相关的存储设计逻辑越复杂,从而导致成为整个架构的性能瓶颈。而底层的block storage本身并不是瓶颈,所以在很多存储系统中,即使换上了最先进,最快的NVMe盘对系统的整体性能提升页不大。而基于分层的架构设计,可以把副本(Replica),纠删码(EC)保护,弹性扩容等功能都放到下层去做,可以使得整个系统设计的任务更平衡,去除掉单点瓶颈,从而提高系统的整体性能。

另一方面,由于采用双层架构,所以即使在存储系统内部,上层应用存储和下层通用块存储也是解耦合的,从而在存储系统内部也可以做到更灵活的计算存储比。比如需要更高的性能,就增加上层业务存储模块的节点数,每节点管理的存储资源减少。而如果需要更多的存储,性能过剩,那可以增加硬盘数量,或者下层存储节点的数量。通过存储计算比的平衡可以在已有的硬件条件下提高性能。

 

2. 故障处理方面的优势

我们从硬盘,底层块存储服务,上层应用存储服务三个不同的故障场景来分析一下。对于硬盘故障,一般情况下对于此类故障,底层块存储服务都会有类似于Erasure code的保护机制,在硬盘故障的时候能做到自动数据保护,并不影响上层应用的服务,故障被很好的隔离。关于底层块存储服务器节点故障,块存储服务器也是一个高可用的集群,故而一般都可以直接由副本节点继续向上层应用存储提供服务,基本对整个系统也没有什么影响。最后再看下上层应用存储服务节点故障,首先由于高可靠相关的副本offload到底层块存储完成,所以应用存储节点的数量可以大大减少,比如原来做三副本需要300个服务器,那么现在没有副本了,只需要100个节点就可以提供相同的服务,由此故障产生的概率也大大减少。另外由于物理存储和应用存储服务节点是解耦合的,所以在故障的时候,可以直接把原属于他的volume给其他的存储服务节点接管,没有数据copy等费事费资源的过程,大大提高了故障恢复速度和业务的连续性。

 

3. 优化存储硬件资源使用,降低系统的成本

资源池化的一个好处就是可以集中管理资源,一方面可以提高资源的使用效率,比如原来把硬盘直接放在上层应用存储服务器节点,那么不管应用层真实需要用到多少存储空间,他对这些硬盘都是独占的,在很多情况下会导致浪费,尤其是在业务启动的初期,数据量比较少。根据经验显示,即使是部署了6-8年的存储系统,往往硬盘的利用率都在40%左右。那么通过池化动态分配,至少可以把硬盘的利用率提高到80%。另外一方面,池化的资源更容易做针对硬件的一些优化,举例来说,现在很多NVMe SSD的持久性并不高,尤其是在随机读写的场景下,以Intel P4510 8T为例,随机IO下DWPD是0.9,而顺序IO下是3.0,在块存储服务器完全可以针对硬件的这些特性而做相应的优化,尽量避免伤害硬件的操作,另外其他一些高级数据服务的实现也更容易,效率更高,比如压缩等,可以进一步提高硬盘的使用率。一般情况下,这些硬盘在整个存储系统中的成本是最大的一块,尤其是NVMe SSD集群,那么优化他们的利用率,优化管理以延长使用寿命无疑会带来巨大的成本优势。

 

分层存储架构设计实现方案分析

对于技术实力比较强的超大规模数据中心,他们大部分都是自己实现整套解决方案,那么对于研发力量有限的用户来说,如果要通过这种分层的设计方式来优化整个存储系统,有哪些选择呢,一是可以选择使用一些公有云提供的块存储服务,另外也可以直接购买一些企业级的存储产品,不过这些高性能存储产品的价格非常昂贵。相对直接选择现有成品来说,另一个选择就是用当今最为市场接受的SDS(软件定义存储)方案,自己在标准的服务器上搭建符合自己需要的高性能块存储服务层。目前市场上针对NVMe SSD的全闪存SDS方案中,lightbits labs提出的基于NVMe over TCP的SDS方案无疑是最值得考虑的一个。为什么要用基于NVMe over TCP的存储呢,众所周知,NVMe是协议本身是专为Flash这种存储介质而设计,其队列数和队列深度的支持使得IO的并发性得到空前的提升,而这正是充分发挥出Flash性能的关键。该协议经过多年的发展,从最早的只能支持PCIe接口到对各种网络的广泛支持,NVMeoF家族现在有FC, IB, RDMA, TCP协议,而NVMe over TCP 作为最新的一个标准也是被市场寄予厚望,一方面由于其无所不在的生态,能适用于各种场景,另一方面由于现在以太网设备本身的快速发展,使得带宽不再是问题,在此情况下,NVMe over TCP从性能上来讲并不比其他网络差,而所增加的些许延迟在大部分应用场景中也影响不大。另外,目前众多分布式存储系统也是一般基于普通的以网网络,所以升级较为简单。Lightbits labs作为NVMe over TCP的先行者,首先其引导了协议的制定,并且也是当前Linux kernel里相关驱动的主要贡献者,所以在这个领域有相当的技术认知深度。另外Lightbits labs的产品LightOS也是业内第一个基于NVMe over TCP的商用SDS解决方案,2019年就发布的第一代产品不但在性能上面表现非常突出,而且还提供丰富的数据服务,硬件管理等实用的功能,比如纠删码保护,压缩,硬盘持久性优化,thin-provisioning 等等功能。2020年初Lightbits Labs又发布了其第二代产品,在第一代的基础上增加了集群的功能,成为一个完整的分布式的SDS的块存储解决方案。该方案无疑为本文讨论的分层存储架构提供了坚实的基础,用该方案作为底层块存储层,可以非常方便的和当前的应用分布式存储系统融合,都是基于标准服务器和标准的以太网络。并且该方案所有的驱动,包括高可用机制(ANA)都是标准化并且在Linux kernel里面都是直接支持,没有任何私有的东西,在安全性方面没有任何顾虑。

 Ceph双层存储架构案例分析

最后我们以优化Ceph为例来分析一下使用Lightbits的NVMe/TCP的SDS解决方案带来的优势。虽然一般情况下Ceph是为一些不需要高性能的应用而设计的,但是原理都是一样的。而且Ceph被市场广泛的使用,而在某些场景下,其性能已经成为应用的痛点,我们也希望通过讨论给Ceph使用者一点启发,看看是不是有解决痛点的可能。并且我们也希望看到随着NVMe SSD时代的到来,Ceph等协议也会与时俱进,能适用于更多的场景。

 我们先看下目前Ceph性能低由哪些原因:

  1. Ceph设计本身对数据的可靠性,一致性等做了非常多的考虑,一般情况下也是至少使用3副本,副本数的增加也就导致了为提供相同的服务其节点数成倍数增加,其系统内部数据的同步等功能的复杂度是成几何倍数增加,所以会导致性能的极具降低。
  2. Cehp的故障处理会对整个集群的性能产生极大影响。首先,在某个硬盘故障的情况下,OSD需要进行数据的rebuild,而在这rebuild的过程中,性能会急剧下降。另外,在OSD服务器故障,或者新的OSD加入的情况会导致更大的性能影响,因为新的OSD重新加入也就是相当于加入了多个PG,而在每个PG内需要进行leader election,等第一个PG leader election完成后开始数据rebuild,问题是这个数据rebuild又会影响其他PG的leader eletion,导致恶性循环,故而整个故障回复时间会非常长
  3. 另外一个问题是Ceph有个Peering的机制,在Peering阶段,所有的写操作都不能进行,因为这个阶段是place group里所有的Active OSD同步哪些object 是valid,哪些不valid的过程。而这个过程的长短就取决于集群的规模和PG里面object的数量,甚至需要几分钟才能完成。

通过上述分析我们可以看到,随着集群规模的变大,无论是正常运行中,还是故障处理中,系统内部的处理会大大复杂,从而导致性能大大下降。

那么分析一下采用相同的物理设备资源,而改成使用双层的存储架构设计,即使是最保守的估算,使用原有的硬件设备,在性能上也可以提升3倍以上,这是由于不需要在上层做replicaion带来的提升,而在故障处理方面,由于OSD节点数大大减少,故而故障的可能性也大大下降,不过对于OSD节点本身的故障,需要做一些优化,在OSD节点故障时能让其他OSD接管他的volume。

同时,因为Ceph本身同时提供文件,对象和块存储三种存储,对于文件和对象,我们可以使用上述架构大大提升性能,而对于块存储本身的业务需要,可以不经过Ceph这一层,这样块存储服务的性能提升是数量级的变化。另一方面,由于剔除掉了块存储服务,那么ceph的OSD节点数量可以进一步减少,从而进一步提高文件和对象存储的性能。

图表 2 Ceph集群优化

 

我们举例来说明一下,假设原有的Ceph集群有300台服务器,每台服务器8 X 4TB的存储,对外提供的文件,对象,和块存储各占1/3,内部采用3副本方式,对外共提供3200TB的容量。改成双层存储架构之后,下层块存储集群采用Lightbits的方案,每服务器至少可以12 X4T(甚至更高密度),用200台服务器提供相同的对外容量3200TB,内部也是3副本。其中1060TB直接通过块存储被应用服务器使用,而剩余2140TB通过Ceph节点对外提供文件和对象存储,采用单副本,假设每OSD管理和原来相同的容量,那么需要67台OSD服务器(2140TB/32TB)。我们可以看到,在相同的环境下,仅仅通过优化存储架构,我们不但可以节约33台服务器,而且可以数量级的提升块存储性能,数倍提升文件和对象存储性能。并且还有更多的资源池化带来的利用率,硬盘管理寿命优化等优点。

 

 

About the Writer: