判断超融合存储优劣的几个原则初探(下篇) 作者： 日期：判断方法在本文所推荐的几个原则，是透过ServerSAN产品体系架构的分析，来判断和比较产品的优劣。除了技术分析之外，尽可能为大家提供一些简单的判断方法，希望能够有所帮助。（1）首先是通过块数据存取方法来判断系统的性能和效率。众所周知，ServerSAN主要处理块数据，以计算虚拟化、数据库等应用为主，更多涉及企业的OLTP业务应用，大多属于关键业务应用。对于这类业务应用而言，系统的可靠性、安全性至关重要。在满足了这些条件的前提下，性能将是最终决定因素，这也是产品之间来开差距的指标。如果仅仅从现有应用着眼，会有用户对于性能的效率和能力不以为意，但从长远的发展眼光，块数据存取方法的不同，技术设计架构的差异，所表现出的能力会有较大的区分。目前ServerSAN系统存取块数据，对于存储介质的访问存在直接和间接的访问方式的区分。所谓间接的访问方式，就是借助ext2、ext3、ext4或者ZFS等Linux的文件系统，来存储和管理块数据，或者利用对象存储系统将块数据以对象的方式存取。这种数据访问方式实现起来相对简单，但它们无法针对块数据的特点，以及设备的特性进行性能优化，访问过程中需要对用户的块数据进行多次转换，比如将块数据传递给文件系统，由文件系统再将数据写入存储介质。这种多层次的传递会造成系统性能损耗。用对象存储来实现块设备存储存在更多问题，因为对象存储中的对象通常是Immutable(不可改变的)，而且对象存储系统更加强调吞吐率，而块设备中的数据是在不停的被修改的，并且块设备更强调IOPS。因此，间接的访问存储介质的方式其性能很难达到最优。与之相比，直接存储方式会自己实现一个适合块设备特性的精简文件系统，直接对磁盘裸设备(Raw Device)直接操作和控制，可以在最大程度上充分利用磁盘设备的IOPS，从而达到系统硬件的极限。既然存在这样的区分，因此对于用户来说，很重要的一个任务就是能够识别出哪些才是专业的九段产品，避免业余九段浑水摸鱼。但在工作实践的过程中，有什么样的方法能够帮助我们进行鉴别呢?在此，个人给大家推荐的办法是：就看ServerSAN系统管理的存储介质上，是否安装了文件系统。如果存储介质上有文件系统，那么便是间接访问方式。这种鉴别方法未必100%准确，但绝大多数情况下是有效的。总之，用户对于系统存储介质的访问方式需要保持高度的重视。（2）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路径极有可能不是极有可能最优的。（3）系统可扩展性(High Scalability)和容错能力以及安全性我们说到了裸设备访问方式，以及系统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系统中其方法是将一份数据复制到两个或多个副本到异地数据中心，如此大大提高了系统的安全性。但如此一来，该系统数据一致性和系统性能就有可能会受到影响。不论是同步复制还是异步复制，这样的影响都是存在的。首先是同步数据复制，是在系统成功响应客户的写请求之前，数据被复制到至少两个数据中心，如果是异地数据中心则对于网络带宽、延时都有很高的要求，否则将导致系统的性能及其低下。但保持异地数据中心的高网络带宽和低延迟，成本会是非常高的。不得已，就会采用异步方式，即在一个数据中心的写请求一旦成功写入本地的数据中心即可返回，系统可以在后台将这部分写复制到另外的一个数据中心去。非常显然，异步方式会导致两个中心的数据存在不一致性。也正是因为如此，好的解决方案应该采用两地三中心的方式。这也是我个人推荐的方式。总之，分布式存储技术还处于快速的发展之中，技术并不断突破和创新。但总体来说，优秀的分布式系统已经比较成熟，已经能够满足用户业务应用的需要，与传统磁盘阵列相比，分布式存储的优势毋庸置疑。用户可以结合实际应用的需要大胆尝试和选用分布式存储系统。无论在全球还是国内市场，互联网企业的成功实践其实已经印证了这一点，分布式存储已经到了成熟应用的阶段。但是与此同时，分布式存储市场毕竟年轻，特别是市场鱼龙混杂，这无疑增加了用户的风险。