在上一篇文章中，强调了区分系统存储介质访问方式的重要性，接下来，需要考虑的问题就是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路径极有可能不是极有可能***的。
(未完待续)
作者简介：陈靓，1999年北京航空航天大学硕士毕业，2002年考入美国俄亥俄州立大学学习计算机科学，2006年获得该校博士学位。此后入职美国Amazon，于AWS Storage Team(云计算核心存储团队)工作，长达7年之久，曾经担任系统架构师和研发团队带头人，负责设计和实现了著名的AWS Glacier系统结构;2011年加入AWS S3团队，负责对AWS S3 的Volume子系统新版本的研发。2013年，接受南京市政府321计划的感召，选择归国创业，创办了南京鹏云网络科技有限公司，致力于私有云存储产品的研发。2015年入选中组部“国家千人计划”专家人才。
