判断超融合存储优劣的几个原则初探(3)

2016/02/28

在此前的文章中,我们说到了裸设备访问方式,以及系统I/O路径的问题,应该说这是ServerSAN系统性能影响比较大的两个因素,用户在选型中,需要进行仔细地了解和考察。除了影响系统性能的因素之外,我认为系统可扩展性(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即可正式使用我们的产品