曾几何时，你可能被“集群FS”“共享FS”“SANFS”“并行FS”“分布式FS”这些名词弄得头晕眼花，冬瓜哥一度也是，而且也找很多人去求证，倒头来每个人的说法都不一样，于是冬瓜哥开始潜心自己研究总结。究其本质原因是集群系统里有好几个逻辑层次，而每个层次又有不同的架构，组合起来之后，花样繁多，而又没有人愿意用比较精准的名字来描述某个集群系统，取而代之只用了能够表征其某个层次所使用的架构来表征整个系统，这是产生理解混乱的原因。本文会对现存的集群文件系统框架进行一个清晰的梳理、划界。即便是大名鼎鼎的维基百科，恐怕也没有一篇文章彻底的梳理所有这些框架，都是零零散散的混乱定义，让人看了摸不着头脑。维基百科中文频道，冬瓜哥之前增加过一条“集群文件系统”的定义，还有百度百科，大家可以去看看，那个条目写的非常概要，而本文则展开讲述。
【主线1】从双机共享访问一个卷说开去
把一个卷/Lun/LogicalDisk/Virtual Disk，管它叫什么的，同时映射给多台主机，管它用什么协议，IP/FC/IB/SAS，这多台主机会不会同时认到这个卷?会。每台主机OS里的驱动触发libfc/libiscsi/libsas等库发出scsi report lun这个指令的时候，存储系统都会将这个卷的基本信息在scsiresponse里反馈回去，包括设备类型、厂商、版本号等，主机再发送scsi inquery lun来探寻更具体的信息，比如是否支持缓存以及是否有电池保护等。接着主机发出scsi read capacity来获取这个卷的容量，最后主机OS会加载一个通用块设备驱动，注册盘符。冬瓜哥说的有点多了，上面这些其实与主题无关，但是冬瓜哥的思路属于线性再叠加类比和发散思维，必须一步一步串起来，所以不得不多说点。
那么在主机1使用NTFS或者EXT等文件系统格式化这个卷，写文件，其他主机上是否可以直接看到这个文件?曾几何时，不少人问冬瓜哥这个问题，瓜哥也测试过不少人对这个问题的看法，喜忧参半。有人天然的认为，如果不能实现这种效果，还玩个屁?持有这种观点的人就是只浮于表面的那些人而且装逼过甚。听到这个问题考虑考虑犹豫地说出”应该可以吧“的那些人，还算能动动脑子不过其知识体系的完整度也真让人捉急。实际上，有一定几率其他主机可以看到新写入的数据，但是大部分时候，其他主机要么看不到，要么错乱(磁盘状态出了问题比如未格式化等等)。所以多主机天然可以共享卷，但是天然却共享不了卷中的文件。咋回事?因为每台主机上的文件系统从来不会知道有人越过它从后门私自更改了磁盘上的数据，你写了东西我不知道，我认为这块地方是未被占用的，我写了东西把你覆盖掉了，你也不知道，最后就错乱了，跑飞了。多主机共同处理同一个卷上的数据，看上去很不错，能够增加并发处理性能，前提是卷的IO性能未达到瓶颈，所以这种场景并不只是思维实验，是切切实实的需求，比如传统企业业务里最典型的一个应用场景就是电视台非线编系统，要求多主机共享访问同一个卷、同一个文件，而且要求高吞吐量。但是，上述问题成为了绊脚石。
咋解决?很显然两个办法，在这方面，人类的思想都是一样的，逃不开几种方案，只要你了解问题根源，稍微动点脑子，就不比那些个底层系统设计者想出的办法差到哪去。
图1
如图1下半部分所示，第一种办法，既然多个FS各干各的又不沟通，那么干脆大伙谁都别管理文件了，找个集中的地方管理文件，大伙想要读写创建删除截断追加任何文件/目录，把指令发给这个人，让它执行，返回结果，这不就可以了么?是啊，这特么不就是所谓NAS么我说。主机端的文件系统没了?非也。还在，只不过只负责访问本地非共享的文件数据，对于那些需要被/与其他主机共享的文件，放到另一个目录里，这个目录实体存在于NAS上，主机端采用NFS/CIFS客户端程序将这个实体目录挂载到本地VFS某个路径下面，凡是访问这个路径的IO请求都被VFS层重定向发送给NFS/CIFS客户端程序代为封装为标准NFS/CIFS包发送给NAS处理。这样，就可以实现多主机同时访问同一份数据了。
【支线】数据一致性问题的谬误
在这里冬瓜哥给各位开一个支线任务。很多人有所迷惑，多个主机共享访问同一个文件，那么就能避免我写的数据不会覆盖你写的么?不能。既然不能，那上面岂不是白说了?倒头来数据还不是要相互覆盖，不一致?估计我问出这个问题之后，一大堆人就干瞪眼了，迷糊了。如果不加任何处理，两个诸如记事本这样的程序打开同一个文件，同时编辑，最后的确是后保存的覆盖先保存的。但是此时的不一致，是应用层的不一致，并不是文件系统层的不一致，也就是说并不会因为主机A写入的数据覆盖掉了主机B写入的数据而导致NAS的文件系统不一致从而需要FSCK或者磁盘格式未知等诡异错误。那么NAS就放任这种应用层的相互乱覆盖么?是的，放任之。为何要放任?为何NAS不负责应用层数据一致?那我要问问你，NAS怎么能保证这一点?A写了个123进去，同时B写了个456进去，NAS是最终把文件保存成123456呢，还是142536呢?还是145236呢?NAS如何能管得了这个?所以NAS根本就不管应用层的一致。那咋整?锁啊。应用打开某个文件的时候，先向NAS申请一个锁，比如要锁住整个文件或者某段字节，允许他人只读，还是读写都不行，这些都可以申请。如果你用MS Office程序比如Word打开某个NAS上的文件，另一台主机再打开一次，就会收到提示只能打开只读副本，就是因为有其他主机对这个文件加了写锁。此时便可保证应用层一致了，而记事本这种程序是根本不加锁的，因为它就不是为了这种企业级协作而设计的，所以谁都能打开和编辑。所以，应用层不一致，与底层不一致根本就是两回事。
#p#
【主线2】标准店销模式和超市模式
NAS是成功解决了多主机共享访问存储的问题，但是自身却带来了新问题，第一，走TCPIP协议栈到以太网再到千兆万兆交换机，这条路的开销太大，每一个以太网帧都要经过主机CPU运行TCPIP协议栈进行错误检测丢包重传等，这期间除了CPU要接受大量中断和计算处理之外，还需要多次内存拷贝，而普通Intel CPU平台下是不带DMA Engine的，只有Jasper Forest这种平台才会有，但是即便有，对于一些小碎包的内存拷贝用DMAEngine也无法提升太多性能，主机CPU耗费巨大;第二，系统IO路径较长，主机先要把IO请求发给NAS，NAS翻译成块IO，再发送给磁盘，IO转了一手，增加了时延;第三，NAS本身是个集中式的存储设备，如果NAS设备出现IO或者CPU瓶颈，前端主机数量再多也没用。
这就是店销模式的尴尬之处。你想买什么东西，你不能碰，你得让店员给你拿，如果店员数量有限，顾客多，那就只能排队，或者乌泱泱一帮人你一句我一句与店员交流，这显然出现了瓶颈。后来，对于量大的店，改为了超市模式，顾客先看看货物的分布图，然后自己去对应货架拿货物结账，极大地提升了性能。存储也可以这么干。
图2
如图2所示，如果找一台独立的节点，专门来管理FS元数据，比如块映射信息、bitmap、权限等等，而让原来的两个节点直接认到卷。什么!?你不是说多个主机认到同一个卷，数据会被损毁么?这是没把东西串起来，没动脑子想。冬瓜哥是说过，但是前提是两主机上的FS各管各的。现在我不让它各管各的，还是把FS拿出来，但是拿到旁边去，平时别挡路，让原来的节点直接访问盘，但是节点访问盘之前，必须经过第三个节点也就是图中的FS节点的授权和同意，这样的话就不会不一致，而且还能获得更高的速度，因为此时可以使用比如FC/SAS/IB等对CPU耗费少(协议传输层直接在卡里硬件完成)的链路类型，另外IO直接从节点下来到卷，不用转手。此时的IO流程是：节点上使用一种特殊的客户端(并非传统NFS/CIFS客户端)，任何对文件的操作都通过Eth交换机向FS节点查询，比如一开始的ls，后续的open/read/write等，FS会将对应文件的信息(权限、属性、对应的卷块地址等)返回给节点，节点获取这些信息，便直接从卷上读写数据，所有的元数据请求包括锁等，全部经由Eth网与FS节点交互。这便是存储里的超市模式。
专业术语，店销模式称为带内模式或者共路模式，超市模式则为带外模式或者旁路控制模式或者随路模式。而图2中所示的方式，则就是所谓带外NAS系统。或者有人起了个更忽悠人的名字：“共享文件系统”/“共享式文件系统”，或者SanFS，也就是多主机通过SAN网络共享访问同一个卷，而又能保证文件底层数据一致性。上述的这种共享文件系统无非包含两个安装组件，元数据节点安装Master管理软件包，IO节点安装客户端软件包，经过一番设置，系统运行，所有IO节点均看到同样的目录，目录里有同样的同一份数据，因为它们都是从元数据节点请求文件目录列表以及数据的，看到的当然是一样的了。如图所示，NFS/CIFS客户端是不支持这种方式的，需要开发新的客户端，这个客户端在与FS节点通信时依然可以使用类似NFS的协议，但是需要增加一部分NFS协议中未包含的内容，就是将文件对应的块信息也传递给客户端，需要做一下开发，其他的都可以沿用NFS协议，此外，这个特殊客户端在IO路径后端还必须增加一个可直接调用块IO接口的模块，NFS客户端是没有实现这个的。
【主线3】对称式协作与非对称式协作
咱们再说回来，除了使用带内NAS或者带外NAS方式之外，还有另一种办法解决多节点共享处理同一份数据，而且相比NAS显得更加高大上和学院派。如图1上半部分所示，既然大伙各管各的又不沟通，那我让你们之间沟通一下不就可以一致了么?没错，在各自的FS之上，架设一个模块，这个模块专门负责沟通，每个人做的改变，均同步推送给所有人，当然，要改变某个数据之前，必须先加锁占坑，否则别人也有可能同时在试图改变这个数据。加锁的方式和模式有很多种，这个瓜哥会在后续文章中介绍。很早期，Win平台有个名为Sanergy的产品，其角色就是构架在NTFS之上的一个沟通同步、加锁、文件位置管理和映射模块，但是很难用，性能也很差，这个产品后来被IBM收购以后就没下文了，其原因是该产品与NTFS松耦合，对NTFS没有任何改动，只是在上面做了一些映射定向，开销非常大，是一个初期在广电领域非线编系统对于多机共享卷的强烈需求下出现的产品。再比如Ibrix(HP x9000 NAS的底层支撑集群文件系统)则是架构在EXT3 FS之上的集群管理模块，其对EXT3文件系统也没有修改。
这种模式的集群文件系统，称为“对称式集群文件系统”，意即集群内所有节点的角色都是均等对称的，对称式协作，大家共同维护同一份时刻一致的文件系统元数据，互锁频繁，通信量大，因为一个节点做了某种变更，一定要同时告诉集群内所有其他节点。相比之下，上文中所述的那种超市模式的带外NAS文件系统，则属于“非对称式集群文件系统”，有一个集中的独裁节点，非对称式协作，或者说没有“协作”了，只有“独裁”。
显而易见，对称式协作集群有个天生的劣势，就是看上去好看，人们都喜欢对称，但是用起来就不那么舒坦了，两个原因，第一个是其扩展性差，节点数量不能太多，否则通信量达到瓶颈，比如32个节点的话，每个节点可能同时在与其他31个节点通信，此时系统连接总数近似为32x32，如果一千个节点，则连接总数为999x999，节点性能奇差。其次，安全性方面，对称式协作，多个节点间耦合性非常紧，一旦某个节点出现问题，比如卡壳，那么向其加锁就会迟迟得不到应答，影响整个集群的性能，一人出事全家遭殃，再就是一旦某个节点发飙把文件系统元数据破坏了，也一样是全家遭殃，重则整个系统宕机FS再也挂不起来，轻则丢数据或不一致。所以，也只有少数几家技术功底深厚的追求完美的公司做出了类似产品，典型代表就是Veritas的CFS，类似的产品还有Ibrix。还有一些对称式协作集群产品，其内部并非是纯粹的对称式协作，而是按照某种规则划分了细粒度的owner，比如目录A的owner是节点A，目录B的owner是节点B，所有的IO均需要转发给owner然后由owner负责写盘，这样不需要加锁，降低通信量;或者将锁的管理分隔开，比如目录A的锁管理节点职责赋给节点A，这样大家访问目录A就都向A节点加锁，而不用所有人都发出锁请求，GPFS对称式协作FS就是这种做法。但是这些加了某种妥协的架构也就不那么纯粹了，但的确比较实际。这些不怎么纯粹的协作管理，可以被归为“Single Path Image”，也就是其协作方式是按照路径划分各个子管理节点的，甚至每个节点可能都掌管一个独立的文件系统，然后由协作层将其按照路径虚拟成一个总路径，Windows系统之前内置有个DFS就是这么干的;而纯粹的对称协作，可以被归为“Single Filesystem Image”，意即整个集群只有一个单一文件系统，所有人都可以管理任何元数据，完全纯对称。当然，SPI和SFI这两个估计逼格高甚，可能不少人已经难以理解了，所以冬瓜哥也就不再继续费手指头打字了。
即便如此，对称式协作集群的节点数量也不能增加到太多。而非对称式集群，由于耦合度很低，只是多对1耦合(每个IO节点对元数据节点之间耦合)，通信量大为降低，目前最大的非对称式协作集群FS可达单集群13K台，基于HDFS。
#p#
说到这里，冬瓜哥要做个总结了。
图3
如图3和图4所示，冬瓜哥把集群文件系统架构分割为三层，最底层为数据访问层或者说存储层，在这一层，上述的架构都使用了共享式架构，也就是多节点共享访问同一个或者同多个卷。再往上一层，冬瓜哥称之为协作管理层，这一层有对称式协作和非对称式协作两种方式，分别对应了多种产品，上文中也介绍了。最顶层，就是数据访问层，其实这一层可有可无，如果没有，那么需要把应用程序直接装在IO节点上，应程序直接对路径比如/clusterfs/cluster.txt进行代码级调用即可比如read()。
图4
而如果将某个节点上的这个路径，使用NFS/CIFS server端export出去，再找一台server用NFS/CIFS客户端mount上来读写的话，那么这个集群系统就成了一台集群NAS了，从任何一个节点上都可以mount，这样就增加了并发度，增加了性能，当然，前提是底层的卷提供者未达到瓶颈。把应用和IO节点装在同一台server上，有些低逼格的说法叫做“HCI”，所谓超融合系统。冬瓜哥之前是一名纯粹的产品经理，也善于包装忽悠，有兴趣者可以看本公众号(大话存储)之前文章：《可视化存储智能—思路、技术和展现》。
往事不可追如冷风吹。好了，大家可以看到一个集群文件系统的三层框架架构，其中在协作管理层，有两种架构，第一种是对称式协作，第二种是非对称式协作。好了，其实上面这句话就是前文啰嗦一大堆的精髓所在。而我们现有的多数教材，是反过来说，它先特么给你总结和抽象，把你搞晕，然后可有可无懒懒散散的举几个不明不白的例子。冬瓜哥对此深恶痛绝，去特么的!耽误了多少莘莘学子的宝贵人生!这也是冬瓜哥急切想进入教师体制的原因，因为看到别人说不清楚某个东西，瓜哥心里捉急啊。
【支线】RAC、SMP和AMP
咋样?做完刚才那个主线任务，是不是有种荡气回肠的感觉呢?休息一下，来做个支线吧。Oracle RAC属于对称式协作+共享存储型集群。而早期的CPU和RAM之间的关系，也是对称式协作+共享存储型集群，如果把CPU看做节点，RAM看做存储的话，多CPU通过FSB共享总线通过北桥上的DDR控制器访问下挂的集中的RAM。多个线程可以随意在多CPU上任意调度，哪个CPU/核心执行都可以，这不是对称是什么?而且针对缓存的更新会有一致性广播探寻发出，这不是协作是什么?多CPU看到同样的RAM地址空间，同样的数据，这不是共享存储是什么?这种CPU和RAM之间的关系又被称为SMP，对称对处理器。与对称式协作面临的尴尬相同，系统广播量太大，耦合太紧，所以后来有了一种新的体系结构成为AMP，非对称对处理器。典型的比如Cell B.E处理器，被用于PS3游戏机中，其中特定的内核运行OS，这个OS向其他协处理内核派发线程/任务，运行OS的内核与这些协处理核之间是松耦合关系，虽然也共享访问集中的内存，但是这块内存主要用于数据存储，而不是代码存储，这种处理器在逻辑架构上可以扩充到非常多的核心。具体冬瓜哥不再多描述，后续看机会可能会在其他文章中详细介绍Cell B.E处理器。
但是好景不长。十年前，共享存储型的SMP处理器体系结构，被全面替换为NUMA架构。起因是因为集中放布的内存产生了瓶颈，CPU速度越来越快，数量越来越多，而内存控制器数量太少，且随着CPU节点数量增加滞后，访问路径变得太长，所以，每个CPU自己带DDR控制器，直接挂几根内存条，多个CPU在互联到一起，形成一个分布式的RAM体系，平时尽量让每个CPU访问自己的RAM，当然必要时也可以直接访问别人的RAM。在这里冬瓜哥不想深入介绍NUMA体系结构，同样的事情其实也发生在存储系统架构里。
#p#
【主线4】分布式存储集群——不得已而为之
钱、性能 for 互联网企业;可靠性、钱、性能for传统企业。人们无非就是受这几个主要因素的驱动。互联网企业动辄几千个节点的集群，让这几千个节点共享卷，是不现实的，首先不可能用FC这种高成本方案，几千端口的FC交换机网络，互联网就算有钱也不会买些这个回来。就用以太网!那只能用iSCSI来共享卷，可以，但是性能奇差。其次，互联网不会花钱买个SAN回来给几千台机器用，一个是没钱(是假的)，第二个是没有哪个SAN产品可以承载互联网几千个节点的IO压力的，虽然这些厂商号称最大支持64K台主机，我估计它们自己都没有实测过，只是内存数据结构做成可容纳64K条而已。
那怎么解决几千个节点的集群性能问题?首先一定要用非对称式协作方式，是的，互联网里从来没有人用过对称式集群，因为扩展性太差。针对存储瓶颈问题，则不得不由共享式，转为分布式。所谓分布式，也就是每个节点各自挂各自的存储，每个节点只能直接访问自己挂的磁盘卷，而不能直接访问他人的磁盘，这与NUMA访问内存是有本质不同的，NUMA里任意CPU可以直接在不告诉其他人的前提下直接访问其他人的RAM。为什么分布式就可以提升IO性能?这其实是基于一个前提：每个节点尽量只访问自己所挂接硬盘里的数据，避免访问别人的，一旦发生跨节点数据访问，就意味着走前端以太网络，就意味着低性能。NUMA就是这么干的，OS在为进程分配物理地址时，尽量分配在该进程所运行在的那个CPU本地的RAM地址上。
互联网里的Hadoop集群使用的Mapreduce就可以保证每个节点上的任务尽量只访问自己硬盘里的数据，因为这种大数据处理场景非常特殊，所以能从应用层做到这种优化。而如果你把一个Oracle RAC部署在一个分布式集群里，RAC是基于共享存储模式设计的，它并不知道哪个数据在本地哪个在远端，所以难以避免跨节点流量，所以效率会很低。但是我们的Server SAN同志虽然使用了分布式存储架构，但是却成功的使用高性能前端网络比如万兆甚至IB以及高性能的后端存储介质比如PCIE闪存卡规避了超级低的相对效率，而把绝对性能提上去了，其实考察其对SSD性能的发挥比例，恐怕连50%都不到。
值得一提的是，在分布式集群中，虽然数据不是集中存放的，但是每个节点都可以看到并且可以访问所有数据内容，如果数据不存在自己这，那么就通过前端网络发送请求到数据所存储在的那个节点把数据读过来，写也是一样，写到对应的远端数据节点。入图5所示便是一个分布式+对称式集群。
图5
分布式存储架构得到广泛应用的原因一个是其扩展性，另一个是其成本，不需要SAN了，普通服务器挂十几个盘，就可以是一个节点，几千上万个节点就可以组成分布式集群。纵观市场上，大部分产品都使用非对称式+分布式架构，成本低，开发简单，扩展性强。具体产品就不一一列举了，大家自行都能说出几个来。
图6所示则是一个分布式+非对称式集群。
图6
分布式系统一个最重要的地方是一定要实现数据冗余，不但要防止盘损坏导致数据丢失，还要防止单个节点宕机导致的数据不可访问。Raid是空间最划算的冗余方式，单节点内可以用raid来防止盘损坏导致的数据不可用，但是节点整个损坏，单机Raid就搞不定了，就得用跨节点之间做Raid，这样会耗费大量网络流量，Erasure Code(EC)就是传统Raid的升级版，可以用N份校验来防止N个节点同时损坏导致的数据丢失，但是也需要耗费大量带宽。所以常规的实现方式是直接使用Raid1的方式将每份数据在其他节点上镜像一份或者两份存放，Raid1对网络带宽的耗费比Raid5或者EC要小得多。
哎呦，写到这，冬瓜哥都有点刹不住了，这篇幅太长了，现在的人都浮躁，看几段就不愿意看了，没关系，浮躁之人就让他浮躁吧，冬瓜哥一定要把想说的说完，而且说清楚，这才是冬瓜哥，冬瓜哥一直都是这样，这样的冬瓜哥才是冬瓜哥。看完冬瓜哥文章的，自然也会受益。看不完的，不进则退。
【支线】各种集群NAS
对于一个集群NAS来讲，其可以使用分布式+对称式(Isilon就是这么做的，GPFS有两个版本，其分布式版本也是这种架构)，也可以使用分布式+非对称式(互联网开源领域所有集群FS)，也可以使用共享式+对称式(VeritasCFS，Ibrix)，也可以采用共享式+非对称式(BWFS)。但是集群NAS一般都泛指一个独立的商用系统，而商用系统一般都是面向传统企业的，扩展性要求不是很高，而对“高雅”的架构却情有独钟，所以这些传统集群NAS厂商一般要么使用对称式要么使用共享式这些“高雅”的架构。
【支线】YeeFS架构简析
讲了这么多，冬瓜哥认为需要结合实际的产品来把这些概念和架构匹配起来，效果最佳。YeeFS由达沃时代(DaoWoo)公司出品，是一个典型的分布式非对称式集群文件系统+集群SAN(或者说Server SAN)。想到这里，你此时应该在脑海里想到“哦，非对称式，那在协作管理层一定要有元数据节点了。哦，分布式，那在存储层一定是每个节点各管各的磁盘或者卷了”，“那么前端访问层呢?”，哎呦，不错，你终于学会思考了，而且思路框架已经有点逼格了嘿。YeeFS在前端访问层支持NFS、CIFS以及Linux下的并行访问客户端，NFS和CIFS可以从任意节点Mount，对于ServerSAN访问方式，支持iSCSI连接方式。行了，我已经了解这款产品了!得了吧你，就这三板斧，逼格还早呢。
上面只是使用了我们所建立的框架思维来套用到一款产品上，从大架构方面来了解一款产品，类似大框架的产品还有很多，如果它们全都一个模子，那就不会有今天的ServerSAN产品大爆炸时期的存在了。考察一款ServerSAN产品，从用户角度看主要看这几样：性能、扩展性、可用性、可靠性、可维护性、功能、成本。从技术角度除了看大框架之外，还得关心这几个东西：是否支持POSIX以及其他接口，数据分块的分布策略、是否支持缓存以及分布式全局缓存，对小文件的优化，是否同时支持FS和块，数据副本机制，副本是否可写可读可缓存。
YeeFS支持标准POSIX及S3/VM对象接口。Posix接口很完善也很复杂，不适合新兴应用，比如你上传一张照片，你是绝对不会在线把这个照片中的某段字节更改掉的，POSIX支持seek到某个基地址，然后写入某段字节，而这种需求对于网盘这种新应用完全是累赘，所以催生了更加简单的对象接口，给我一个比如hash key，我给你一份完整数据，要么全拿走要么删除，要改没问题，下载到本地改完了上传一份新的，原来的删除。对分块的布局方面，YeeFS底层是基于分块(又被很多人称为object，对象)的，将一堆分块串起来形成一个块设备，便是集群SAN，将一对obj串起来形成文件，这就是集群NAS，这些对象块在全局磁盘上平均化分布，以提升IO并发度。在实际案例中YeeFS曾经支持到3亿的小文件存储同时还可以保证优良的性能，业界对小文件存储的优化基本都是大包然后做第二层搜索结构，相当于文件系统中的文件系统，以此来降低搜索时延。数据可用性方面，默认2个副本，可调。YeeFS支持读写缓存，但是不支持全局的分布式共享缓存，后者实现起来非常复杂，也只有由传统存储演变过来的高大上型ServerSAN比如VMax这种，通过IB来互联，高速度高成本，才敢这么玩，即便如此，其也只敢使用基于hash的避免查表搜索的缓存分配方式，而二三线厂商恐怕玩不起这个。YeeFS节点向元数据节点加锁某个obj之后便可以在本地维护读写缓存。YeeFS的副本也是可读写的，并且在保持并发度的前提下还保持完全同步的强一致性。整个集群可在线添加和删除节点而不影响业务。
在对闪存的利用方面，YeeFS采用三个维度来加速，第一个是采用传统的冷热分层，第二个维度，采用只读SSD Cache来满足那些更加实时的热点数据的性能提升，第三个维度采用非易失NVRAM来作为写缓存，并将随机的IO合并成连续的大块IO写入下层，极大的优化了性能。此外，YeeFS在元数据访问加速方面，采用了元数据切分并行无锁设计，多线程并行搜索，提升速度;元数据一致性方面，采用主备日志、分组提交方式，既保证性能又保证一致性。
其他功能方面，支持去重和压缩，支持在客户端缓存文件布局信息，避免频繁与元数据节点交互信息。节点宕机之后的数据重构采用的是Raid2.0的方式，将数据重构到所有磁盘的空闲空间，提升并发度，降低重构时间。元数据节点支持扩展为多元数据节点协作并行处理元数据请求，以保证数千节点的超大规模集群的性能。
YeeFS 客户端的一些主要配置:元数据缓存超时时间设置，每个客户端有缓存元数据的能力，超时时间从0开始往上不等; 数据缓存大小设置，包括写缓存和读缓存的大小设置; 并发连接数设置，可以控制一个客户端在IO上往其它存储节点上的最大连接数目控制; 其它的一些配置命令，例如导出目录设置(这个客户端只能导出文件系统中的某个目录)，客户端权限控制(这个客户端上是允许读写操作还是只读操作)，IP控制等。 YeeFS的IO节点上一些配置比如数据校验是否打开，日志大小，IO线程，IO线程与磁盘之间的关系等。元数据节点上主要配置是一些整体系统配置，文件或者目录的副本数配置，存储池的配置，负载均衡、数据重构等一些整体系统的配置。
YeeFS这个产品映入瓜哥眼帘的一个原因是其支持的比较完善，包括POSIX接口、既是集群SAN又是集群NAS。第二个原因，则是其提到的“应用感知”优化，这与瓜哥一直在提的“应用定义”不谋而合，详见之前文章《可视化存储智能解决方案》。其可以在系统底层针对不同应用不同场景进行IO层面的QoS调节。另外，现在的所谓“软件定义”存储系统，过于强调硬件无关性，忽视硬件特性。而YeeFS比较注重硬件的特性，如Flash、RDMA、NUMA、NVRAM等的优化和利用，针对不同硬件的不同特点，定义不同的场景。
YeeFS还有两个兄弟，YeeSAN和WooFS。YeeSAN是YeeFS的简化版，只提供分布式块存储服务，强调比YeeFS块服务更的高IOPS和低时延。而YeeFS可以同时提供文件和块服务。WooFS是专门针对跨数据中心实现的广域分布式的产品，通过统一的名字空间实现多个数据中心间的数据共享，任何一个数据中心的应用可以通过标准Posix接口直接访问存储在其他数据中心的数据，这里就不过多介绍了。
好，到此为止，你应该能更加深入的了解一款产品了，后续碰到任何产品，大家都可以用这种思路去切入、审视、分析和判断，这样可以防止被忽悠。
#p#
【主线5】串行访问/并行访问
对于一个分布式架构的集群NAS(不管是对称式还是非对称式)，某个应用主机从某个节点mount了某个路径，访问其中数据，如果访问的数据恰好不存储在本机而是远端节点，那么该节点先从源端节点把数据拿到本地，再发送给请求数据的主机。为何不能让应用主机预先就知道数据放在哪，然后自己找对应的节点拿数据?这样可以节省一次IO转发过程。是的，你能想到的，系统设计者也想到了。但是传统的NFS/CIFS客户端是无法做到这一点的，必须使用集群文件系统厂商开发的特殊客户端，其先从元数据节点要到文件布局信息，然后直接到集群中的IO节点读写数据，这样的话，应用主机就可以同时从多个IO节点读写数据，而不再像之前那样从哪个节点mount的就只能从这个节点读写数据，这就是所谓的并行访问模式，指的是应用主机访问这个集群时候，是串行从一个节点读写数据，还是可以并行从多个节点同时读写数据。几乎所有的互联网开源集群文件系统都支持并行访问。此外，也可以看到，超市模式再一次在应用主机和集群之间得到了使用。
【主线任务大结局】终极大总结
1. 集群文件系统在数据访问层或者说数据存储层可分为共享存储型和分布存储型，或者说共享式和分布式，分别称为共享FS和分布式FS。
2. 集群文件系统在协作管理层可分为对称式集群和非对称式集群;
3. 集群文件系统在协作管理层针对元数据的管理粒度还可以分为Single Filesystem Image和Single Path Image;
4. 分布式集群文件系统在前端访问层可以分为串行访问和并行访问，后者又称为并行FS。
5. 不管什么架构，这些FS统称为“集群文件系统”。多个层次上的多种架构两两组合之后，便产生了让人头晕眼花的各种集群文件系统。
不仅是集群文件系统，集群块系统也逃不出上面的框架，相比于“集群块系统”逼格稍微高那么一点点的名词，就是“Server SAN”，一个分布式块存储系统，再包装包装，把应用装它上面，就是所谓HCI了，说实话冬瓜哥一开始都不知道HCI是个啥，还是被人邀请加入了一个HCI的群才知道竟然还有人搞出了这个词，哎，世界之大，逼格混杂!
