超融合存储,如何辨别真伪

2016/05/26

如今,以超融合为代表的分布式存储发展迅速,国内外提供超融合产品解决方案的厂商众多,如VMware VSAN、EVO:RAIL、EMC ScaleIO、Nutanix、Maxta、SimpliVity、Scale Computing、Pivot3、Stratoscale、Gridstore、Atlantis Computing、华三、达沃时代、华为FusionStorage 、SMARTX、深信服、华云网际、凯翔科技等都提供了各种不同的分布式存储产品和方案。

在对外宣传上,各家厂商称谓也不相同,从超融合、分布式存储、融合存储、到ServerSAN、云存储、软件定义存储,总之五花八门,让人眼花缭乱,总之一句话:都是将存储管理软件安装在多台x86存储服务器上,管理存储资源,并让服务器协调合作,对外呈现出统一的存储接口。如果根据存储接口不同,又可以细分为对象存储(Key-Value Store)、Server SAN(分布式块设备),NoSQL数据库存储等。

在我看来,其实不必纠结称谓和定义。从应用的角度出发,它提供了有别于传统存储的新的选择,用户可以根据自己的业务需要进行判断和选择。

对于新的存储系统而言,由于技术较新,用户了解有限,因此市场产品鱼目混珠、滥竽充数是在所难免的。在这种情况下,用户应该如何选择适合的产品呢?本文中,我将从技术的角度谈谈个人的看法,以飨读者。

在我看来,评价一个分布式存储系统的优劣可以从性能(Performance)、可扩展性(Scalability)、系统可用性(Availability)和数据安全性(Data Reliability即数据不丢失)4个方面加以看量。

一个总的结论是完美的产品是不存在的,即没有一个产品能同时确保四个方面都很突出。因为这四个方面在一定程度上是互相矛盾的,例如数据安全性越高,需要的数据备份数量就越多,但与此同时,系统性能就会降低。比如两副本系统的数据安全性,通常会低于3副本系统,但是系统的读写性能,2副本通常高于3副本。因此优秀的分布式存储系统是需要根据产品本身的对外特性,在上述4个方面进行合理的取舍。

通常说来, ServerSAN产品对系统性能(IOPS)要求比较高,势必会牺牲一定的数据安全性;而对象存储产品不得不牺牲一定的IOPS或读写的延迟,来换取对象存储所需要的数据高可靠性。

在本文所推荐的几个原则,是透过ServerSAN产品体系架构的分析,来判断和比较产品的优劣。除了技术分析之外,尽可能为大家提供一些简单的判断方法,希望能够有所帮助。

首先是通过块数据存取方法来判断系统的性能和效率。

众所周知,ServerSAN主要处理块数据,以计算虚拟化、数据库等应用为主,更多涉及企业的OLTP业务应用,大多属于关键业务应用。对于这类业务应用而言,系统的可靠性、安全性至关重要。在满足了这些条件的前提下,性能将是最终决定因素,这也是产品之间来开差距的指标。

如果仅仅从现有应用着眼,会有用户对于性能的效率和能力不以为意,但从长远的发展眼光,块数据存取方法的不同,技术设计架构的差异,所表现出的能力会有较大的区分。

目前ServerSAN系统存取块数据,对于存储介质的访问存在直接和间接的访问方式的区分。所谓间接的访问方式,就是借助ext2、ext3、ext4或者ZFS等Linux的文件系统,来存储和管理块数据,或者利用对象存储系统将块数据以对象的方式存取。

这种数据访问方式实现起来相对简单,但它们无法针对块数据的特点,以及设备的特性进行性能优化,访问过程中需要对用户的块数据进行多次转换,比如将块数据传递给文件系统,由文件系统再将数据写入存储介质。这种多层次的传递会造成系统性能损耗。

用对象存储来实现块设备存储存在更多问题,因为对象存储中的对象通常是Immutable(不可改变的),而且对象存储系统更加强调吞吐率,而块设备中的数据是在不停的被修改的,并且块设备更强调IOPS。因此,间接的访问存储介质的方式其性能很难达到最优。

与之相比,直接存储方式会自己实现一个适合块设备特性的精简文件系统,直接对磁盘裸设备(Raw Device)直接操作和控制,可以在最大程度上充分利用磁盘设备的IOPS,从而达到系统硬件的极限。

既然存在这样的区分,因此对于用户来说,很重要的一个任务就是能够识别出哪些才是专业的九段产品,避免业余九段浑水摸鱼。但在工作实践的过程中,有什么样的方法能够帮助我们进行鉴别呢?

在此,个人给大家推荐的办法是:就看ServerSAN系统管理的存储介质上,是否安装了文件系统。如果存储介质上有文件系统,那么便是间接访问方式。这种鉴别方法未必100%准确,但绝大多数情况下是有效的。

接下来,需要考虑的问题就是IO请求所经过的网络路径。

所谓IO请求路径,通常包括几个部分:接收外部(如虚拟机的)IO请求、寻址即将外部IO请求转换为(ServerSAN)系统内部请求、将内部IO请求发至相应的存储节点以实现数据访问。

在一个ServerSAN系统中,通常会由客户端块设备驱动来负责接收外部IO请求,其处理方式亦寻址方式有多种:有些需要查询元数据库(Metadata Store,用于存放内部数据块的元数据,包括数据块在哪个存储节点上的信息);有的则利用Consistent Hashing的方法,直接计算出IO请求对应的内部存储地址,从而达到省略查询元数据库的目的。

此外,将内部请求发送到存储节点也有多种方式:以副本为3份的写请求为例,有的是将数据依次写入3个存储节点,如此就涉及3个网络跳转;也有的是将数据先写入主节点(Primary),再由主节点发给另外两个从节点,如此需要两个网络跳转。另外一种方式是同时广播给3个存储节点,如此只涉及一个网络跳转。

图 1 拥有最长网络路径的系统

以Sheepdog Storage系统为例,一个IO请求需要通过QEMU block driver,Gateway,存储节点3个网络跳转,即网络路径为3。以Ceph为例,一个IO请求需要通过RBD(客户端驱动),主OSD(存储节点),从OSD共3个网络跳转,即网络路径为3。

图 2 拥有最短网络路径的系统

目前为止,我们见到的分布式存储系统里最优的I/O路径为2:客户端驱动和存储节点;其中寻址功能被合并到客户端驱动,并且寻址不需要查询元数据库。客户端驱动直接广播到所有的存储节点上。

同样的,有没有一个判断ServerSAN系统I/O路径的简单方法呢?

不幸地是,我们很难通过一个系统的外部表象来判断这个系统的I/O路径是多少,是否最优?我也没有想出一个简单的方法。但就像判断直接和间接访问裸设备一样,判断系统的I/O路径对于判断系统的水平也是非常重要的。

尽管没有一个简单的方法,但在实际的选型过程中,I/O路径应该成为一个考察的重点,用户应该要求供应商介绍其系统架构,以及外部I/O、内部I/O请求的方法,一旦我们得知系统不是内直接寻址或不是将数据一次性广播给所有的副本节点,我们就可以得出如此的判断:该系统的I/O路径极有可能不是极有可能最优的。

除了影响系统性能的因素之外,我认为系统可扩展性(High Scalability)和容错能力以及安全性都是需要认真考虑的因素。

对于系统的可扩展性首先要考察系统是否存在瓶颈。需要考察系统是否存在这样一个组件(component):系统大部分请求(request)需要经过这个组件或由这个组件来处理,其特征是如果这个组件通常由一台或几台服务器构成,往往就存在着瓶颈的问题,比如SleepDog Storage系统中存在一个Cluster Manager,的组件,它的功能是用于监控数据节点上线/下线的变化,通常通过ZooKeeper来实现。对于ZooKeeper来说,其监控能力存在着上限,如1000个数据节点,如果这1000个数据节点里面,还有更小的单元的状态需要监控,如逻辑卷状态等,如此就会演变成为上万个连接数需要被管理,这就大大超过了ZooKeeper的可承受范围。在这种情况下, Cluster Manager就会成为了ServerSAN系统的瓶颈,导致系统扩展性不好。

ServerSAN系统的容错能力是指:在网络错误、服务器硬件失败的情况下,系统工作不受影响。因为当存储系统的节点数扩展一定的规模后(如1000个节点),同时系统承受了一定量的用户请求,节点上线下线、网络断线连线、磁盘出错(企业硬盘的错误率在3%左右)的情况就会很频繁。在这种情况下,如果系统的容错能力弱,整个系统就将忙于数据迁移和恢复,正常的客户数据请求的处理会受到影响。

一般而言,在客户的IO请求路径上(比如寻址方式)使用Consistent Hashing、DHT(Distributed Hash Table)或者类似的算法,如Ceph的CRUSH算法,都会导致系统的容错能力弱。这是因为此类算法会在系统的节点或硬盘上线下线时,动态迁移大量数据。

优秀的ServerSAN系统可以通过日志的方式,将节点或硬盘在下线期间的数据记录下来,等它们上线后,只复制缺失的数据而避免拷贝所有的数据。

在这里,我们同样需要一个简单的判断的方法。我个人的推荐是,可以通过观察系统是否存在一个中央控制单元,或中央监控单元或中央元数据库;I/O寻址算法是否使用了DHT或类似的算法。来简单判断系统容错能力好坏。

最后,需要说说数据安全性。

我们知道:数据安全性、数据一致性(Data Consistency)和系统性能三者互斥的,即一个系统很难同时达到高数据安全性、强数据一致性和高IOPS的系统。以异地容灾为例,在ServerSAN系统中其方法是将一份数据复制到两个或多个副本到异地数据中心,如此大大提高了系统的安全性。但如此一来,该系统数据一致性和系统性能就有可能会受到影响。

不论是同步复制还是异步复制,这样的影响都是存在的。

首先是同步数据复制,是在系统成功响应客户的写请求之前,数据被复制到至少两个数据中心,如果是异地数据中心则对于网络带宽、延时都有很高的要求,否则将导致系统的性能及其低下。但保持异地数据中心的高网络带宽和低延迟,成本会是非常高的。不得已,就会采用异步方式,即在一个数据中心的写请求一旦成功写入本地的数据中心即可返回,系统可以在后台将这部分写复制到另外的一个数据中心去。非常显然,异步方式会导致两个中心的数据存在不一致性。

也正是因为如此,好的解决方案应该采用两地三中心的方式。这也是我个人推荐的方式。

总之,分布式存储技术还处于快速的发展之中,技术并不断突破和创新。但总体来说,优秀的分布式系统已经比较成熟,已经能够满足用户业务应用的需要,与传统磁盘阵列相比,分布式存储的优势毋庸置疑。用户可以结合实际应用的需要大胆尝试和选用分布式存储系统。

无论在全球还是国内市场,互联网企业的成功实践其实已经印证了这一点,分布式存储已经到了成熟应用的阶段。但是与此同时,分布式存储市场毕竟年轻,特别是市场鱼龙混杂,这无疑增加了用户的风险。

笔者希望通过自己多年经验的分享,能够帮助用户能够使用和应用好分布式系统。个人的经验有限,难免存在纰漏,不足之处敬请批评指正。

如果您感兴趣,可申请试用。当您购买商用版时,仅升级license即可正式使用我们的产品