存储在线GlusterFS及其工作机制简介
GlusterFS是著名的非结构化数据集群文件系统，因为其优异的性能、灵活的扩展性、久经考验的稳定性，在文件存储领域，一直是NAS集群的首选方案之一。正因如此，一些公司基于GlusterFS推出了分布式文件存储产品和相关解决方案，比如，Red Hat收购了GlusterFS的开发团队，发布了Red Hat Gluster Storage，这款产品也是其企业产品线的核心套件之一。上海储迅技术有限公司作为领先的分布式存储产品和高性能计算/AI计算基础架构供应商，也积极参与到GlusterFS项目的开发，基于它打造了数据中心级的分布式存储产品，也为社区贡献了许多模块的关键代码（比如本文提到的Windows客户端和高性能计算经常用到的RDMA模块）。
GlusterFS以高性能而著称。简约原则（所谓奥卡姆剃刀原理）是其设计的灵魂。在GlusterFS中，每个文件系统的API都定义了一个stack frame结构，其API处理时被拆解为stack wind/unwind两个高效过程。这种方式其实是模拟了C函数过程调用的微观过程。不同的是，C函数中stack结构由编译器建立，当它的过程调用返回（return）后，结果也就得到了。在GlusterFS中，这种stack结构由GlusterFS宏代码创建。stack wind调用完成了整个过程调用的前半部分，而stack unwind调用完成了后半部分。GlusterFS就是以这种stack wind/unwind机制建立了异步操作模型，这种模型帮助GlusterFS实现了跨机器接口调用（RPC）的过程。当操作请求/回应发送给网络远端机器的过程中，GlusterFS并不会阻塞，它以一种暂停当前操作，继续处理其他请求的方式代替。当结果回应收到以后，相应的“暂停”会自然恢复。
比如一个文件的写操作，GlusterFS在文件写的这条执行路径上（stack wind）完成了包括文件寻址、创建文件描述符、数据编码到数据的网络分发的所有操作，而在收到网络响应时（stack unwind），则完成了从数据解码、文件装配到写操作结果回复的所有操作。整个过程干净利落，没有多余的线程。值得一提的是，GlusterFS这种工作方式类似于Lisp语言和GNU Hurd微内核操作系统，其设计者是站在计算机语言和操作系统构建的高度设计出这么一种高效的集群文件系统。
GlusterFS Windows客户端
GlusterFS分为服务器和客户端组件，一直以来服务器和客户端组件都被设计为运行在Linux，OpenBSD这类UNIX平台之上。而在Windows平台上，过去的最佳方式是通过Samba文件共享间接使用GlusterFS集群，因此，Windows平台用户无法体验到GlusterFS优异的性能，不得不说是深深的遗憾。
在Windows平台上，以Samba文件共享方式使用GlusterFS集群存储虽说是一种可用的方式，但远远称不上“好”。如图1所示，Windows平台的应用程序如果要使用GlusterFS集群的存储空间，必须经过Samba服务器和客户端来代理请求，其中的性能损失是必然的。
虽然通过Samba文件共享能给Windows平台带来容量的无限扩展，但Samba协议复杂的会话和协议转换会严重拖慢文件访问速度。可以说，Samba协议是一把双刃剑，既是扩充Windows文件系统容量的万能钥匙，又是性能瓶颈所在。在实际生产环境中，文件性能损耗可能非常严重，尤其是小文件存储环境，因为每个文件都会经过层层的协议转换和调用切换，导致文件系统API的响应时间变长，吞吐能力急剧下降。原本的GlusterFS所具有的奔腾的数据处理能力，在Windows环境中就变成了涓涓细流。
上海储迅信息技术有限公司一直以来积极参与GlusterFS开源项目，从多年的行业实施中早已清醒意识到，应用GlusterFS设计模型，研发出一种能在Windows系统中运行的GlusterFS原生客户端势在必行。
图1 传统GlusterFS在Windows平台中的应用架构
GlusterFS Windows客户端由上海储迅信息技术有限公司开发。在这之前，虽然业界对于GlusterFS的Windows原生客户端需求早已求之若渴，并且方案设计也在技术社区中屡屡提出。但是由于Linux和Windows在操作系统、文件系统等方面的巨大差异，其相关设计一直以来仅停留在概念阶段。
图2是上海储迅信息技术有限公司的GlusterFS Windows客户端架构。如图所示，GlusterFS Windows客户端相对于原有的Samba客户端有重大改进：在安装GlusterFS Windows客户端的主机中去掉了Samba连接，再者Windows客户端能同时连接GlusterFS集群中的多个Server（图中仅画出了两个）。改进之后的客户端相对于Samba连接在文件读写性能上有巨大的优势：
一是接口直连优势。GlusterFS协议原本只能应用于Linux平台，而Windows客户端是将GlusterFS协议以及GlusterFS的stack wind/unwind过程调用模型移植到Windows平台。在Windows平台上，我们设计的GlusterFS客户端在平台内使用FUSE和操作系统的文件系统对接（与GlusterFS在Linux中使用FUSE情形类似），对外使用GlusterFS协议及其过程调用模型与GlusterFS集群通信，这中间省去了Samba协议转换的中间环节，提高了系统的性能并节省了计算资源，大大缩短了文件访问的响应时间。
二是可并发优势。在使用GlusterFS Windows客户端的场景中，一个Windows客户端可以直接与GlusterFS集群中的每个单机通信。也就意味着GlusterFS Windows客户端能利用并发物理连接成倍提高自己的带宽。
以上两点，直连和并发正是当今云存储优化的精髓，而之前使用Samba客户端的Windows平台则显得廉颇老矣。
图2 GlusterFS Windows客户端原理图
性能对比测试
为了验证GlusterFS Windows客户端的性能，我们分别通过Samba和GlusterFS Windows客户端连接同一套GlusterFS集群，以下图3是Samba和GlusterFS客户端在Windows环境中的性能对比测试。
实验Windows客户端是Windows Server 2008 R2，GlusterFS存储集群是两台各配备6块企业级SATA盘的GlusterFS存储节点，节点之间使用万兆以太网连接，测试程序使用单进程读写方式。
图3 GlusterFS Windows客户端与Samba的性能对比测试
从上图可以看出，GlusterFS Windows客户端相比Samba连接有了巨大的性能提升。在大文件测试中，GlusterFS客户端的表现与Samba连接旗鼓相当，但在小文件测试中，GlusterFS客户端性能大幅领先Samba。比如在4kB文件测试中，Samba连接仅能提供数百kB/s的读写带宽，而通过GlusterFS客户端访问时，4kB文件的读写速度平均测出高达2.1MB/s的性能。测试文件改为8kB时，GlusterFS客户端达到4MB/s的性能，而Samba仍然只有数百kB/s的速度。
以上是单进程读写测试，在多进程并发读写的场景中，GlusterFS的Windows客户端还表现出一定程度性能叠加，Samba就更望尘莫及了。
总结
GlusterFS的Windows客户端无疑是有其存在的巨大价值。当然除了性能需求，Windows操作系统的使用者会要求一些Windows平台才有的特性。当前，公司开发者正在全力以赴增强产品的功能。展望未来，上海储迅信息技术有限公司会继续积极投入到分布式存储的开源项目之中，也会深耕行业应用，推出更多的高性能、高可靠性、能解决行业痛点的优秀产品。