在此前的文章中，我们说到了裸设备访问方式，以及系统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系统中其方法是将一份数据复制到两个或多个副本到异地数据中心，如此大大提高了系统的安全性。但如此一来，该系统数据一致性和系统性能就有可能会受到影响。
不论是同步复制还是异步复制，这样的影响都是存在的。
首先是同步数据复制，是在系统成功响应客户的写请求之前，数据被复制到至少两个数据中心，如果是异地数据中心则对于网络带宽、延时都有很高的要求，否则将导致系统的性能及其低下。但保持异地数据中心的高网络带宽和低延迟，成本会是非常高的。不得已，就会采用异步方式，即在一个数据中心的写请求一旦成功写入本地的数据中心即可返回，系统可以在后台将这部分写复制到另外的一个数据中心去。非常显然，异步方式会导致两个中心的数据存在不一致性。
也正是因为如此，好的解决方案应该采用两地三中心的方式。这也是我个人推荐的方式。
总之，分布式存储技术还处于快速的发展之中，技术并不断突破和创新。但总体来说，优秀的分布式系统已经比较成熟，已经能够满足用户业务应用的需要，与传统磁盘阵列相比，分布式存储的优势毋庸置疑。用户可以结合实际应用的需要大胆尝试和选用分布式存储系统。
无论在全球还是国内市场，互联网企业的成功实践其实已经印证了这一点，分布式存储已经到了成熟应用的阶段。但是与此同时，分布式存储市场毕竟年轻，特别是市场鱼龙混杂，这无疑增加了用户的风险。
笔者希望通过自己多年经验的分享，能够帮助用户能够使用和应用好分布式系统。个人的经验有限，难免存在纰漏，不足之处敬请批评指正。
作者简介：陈靓，1999年北京航空航天大学硕士毕业，2002年考入美国俄亥俄州立大学学习计算机科学，2006年获得该校博士学位。此后入职美国Amazon，于AWS Storage Team（云计算核心存储团队）工作，长达7年之久，曾经担任系统架构师和研发团队带头人，负责设计和实现了着名的AWS Glacier系统结构；2011年加入AWS S3团队，负责对AWS S3 的Volume子系统新版本的研发。2013年，接受南京市政府321计划的感召，选择归国创业，创办了南京鹏云网络科技有限公司，致力于私有云存储产品的研发。2015年入选中组部“国家千人计划”专家人才。
