在此前的文章中，我们说到了裸设备访问方式，以及系统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系统中其方法是将一份数据复制到两个或多个副本到异地数据中心，如此大大提高了系统的安全性。但如此一来，该系统数据一致性和系统性能就有可能会受到影响。

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

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

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

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

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

系列阅读：

判断超融合存储优劣的几个原则初探（一）

判断超融合存储优劣的几个原则初探（二）