提升存储系统可用性

分布式文件存储概述及对比

“分布式存储系统是大量普通PC服务器通过Internet互联，对外作为一个整体提供存储服务。”实质是基于软件实现的存储服务，属软件定义存储范畴。根据VMware定义“软件定义的存储是将工业标准服务器的存储提供出来并通过软件控制层面实现存储的自动化和池化”。

不同的分布式存储系统适合处理不同类型的数据，可分为四类：分布式文件系统、分布式键值（Key-Value）系统、分布式表格系统和分布式数据库。当前主流的分布式文件存储产品以Hadoop、GlusterFS、Moosefs为代表。横向对比分析情况见表1所示。

综合考量，本文选用MFS作为实例的技术实现，并通过实践中的优化弥补其弱项。

安装部署MFS实例

1.集群规划及拓扑

在独立二层网络内，部署六台普通配置的X86机架式服务器，服务器本地硬盘在100到400GB之间。所有服务器通过一台低端二层以太网交换机单链路互联，组合成一个总容量1.7TB的逻辑存储。提供网络文件系统服务。示意图如图1所示。

图1 实例网络拓扑图

集群所有节点服务器位于同一网段，便于管理及部署。Metalogger日志服务器同时作为时间同步服务器及数据存储服务器。运行情况如图2所示（不包含元数据节点）。

图2 实例运行图

2.MFS集群安装

有两种安装方式可供选择：官方软件库安装、源码编译安装。本文采用软件库安装方式。集群软硬件配置如表2所示。具体安装步骤为：

表1 分布式文件存储对比

3.集群配置使用

集群安装成功后仅需修改少数必要配置文件即可运行，其它配置基本不用修改。

（1) 修 改 Chunkserver节点的mfshdd.cfg文件

在文件末尾加入本地文件系统目录作为集群的一个独立的存储空间，如：/data_volumn1、/data_volumn2、...。MFS会 把 所有Chunkserver的本地文件目录整合起来，提供统一的存储空间对外服务，容量是所有目录的总和。

(2) 在Master添加对外服务的存储路径

即设置共享目录。修改mfsexports.cfg，在文件头部添加

* /a c c e s s p a t h rw,alldirs,admin,maproot=0:0，/accesspath 为 MFS系统中实际存在的数据目录，这一目录需要从客户端连接到集群根目录后进行创建和维护，使集群形成自根“/”开始的树形目录结构。

(3) 客户端

MFS提供原生Linux客户端。由于MFS需要工作在用户级的文件系统上，所以需要安装FUSE模块。通过Linux的系统软件库安装即可，yum-y install fuse fuselibs。再加载fuse模块，modprobe fuse。至此，可以挂载MFS存储了，mfsmount/mnt/clientmountpoint/-H 10.10.2.201 -S /accesspath。

图3 Windows环境访问MFS数据

表2 集群实例软硬件配置

MFS不提供Windows客户端，不支持Windows环境，以成为其扩大影响力的一大短板。通过深入探索测试，通过Total Commander及mfs4tcdbg两个第三方软件组合的形式，成功实现在Windows里通 过T o t a l Commander管理界面直接访问MFS存储。使用方式对于用过FTP软件的人不会陌生，如图3所示。

实例验证

1.目标验证

(1) 读写性能好。

数据多副本使读性能比单台服务器提升显著，且随数据节点增加基本实现线性提升。如图4所示。

在相同环境下测试，传统集中式存储读速度一般在100MB/S左右。可见，MFS分布式存储只需要低端千兆以太网络就可以达到比集中式光纤网络存储更高的速度，且写速度基本与之持平，方案的性价比明显。

且本例数据存储服务器配置低、数量少。利用集群弹性伸缩特性，通过在线增加数据存储服务器数量、加装闪存加速介质等优化措施后，集群的读性能还会大大增加，给业务大规模并发I/O提供更好支持。

(2) 扩容成本低。

图4 MFS实例读速度

MFS各组件的大部分版本可组合使用。原理上可以用较低版本的集群组件匹配较老旧的服务器。因此，可以使用任何品牌、任何年代的标准X86机架服务器加上标准以太网二层交换机就可以方便地进行集群在线横向扩展。

比集中存储扩容简单、高效，对应用几乎透明。可按需动态地利旧下线服务器及集中式存储（把其转为X86服务器本地硬盘）组合成为性能更高，容量更大的存储系统，提供全新的存储服务能力。

(3) 维护成本大幅减低。

当前主流集中存储运维价格不低于500/T/年，组网至少需要两台FC-SAN交换机，还需专门的存储运维人员。本文实例所用6台服务器都均已使用超过6年，硬件成本忽略不计。低端二层交换机1台，价值约1000元。软件均为开源版本，无费用。系统配置确定后，运行基本无需人工干预，后续运维费用的产生仅来源于在网硬件的损耗。

(4)多节点冗余容错架构。

进行多种暴力破坏测试，通过Metalogger的元数据副本及集群配置信息副本恢复集群后，数据始终不丢失，架构始终保持完整，预期RTO为15分钟。同时，通过回收站、快照功能还可以保存数据最近的多个版本，避免人为误操作导致的数据丢失。都充分验证了系统整体可靠性、安全性及易用性。

2.创新实践及后续工作

经过测试验证，如图1所示，在MFS标准部署模式基础上提出如下探索性的部署方式：

(1) 一个MFS集群中部署多个Metalogger元数据日志服务器，通过Linux bash脚本实现元数据的自动备份及自动向集群内其它多个服务器的拷贝。确保了集群最重要信息的安全。当元数据服务器无法运行时，只需重新部署新的元数据服务器，解压任意一份元数据备份到指定目录，即可恢复集群运行，整个过程在15分钟之内。

(2)Metalogger备份服务与数据服务Chunkserver、客户端Client、时间同步服务NTP等混合部署于一台服务器，提升了服务器资源利用率及集群总存储容量。通过验证，混合部署模式不会影响各服务之间的通信及运行，也不会影响集群正常运行。

图5 硬盘负载图

(3)合理配置服务器本地硬盘。由于集群能管理到各服务器本地单个硬盘，建议添加到集群存储池的硬盘无需做本地RAID，把每块物理硬盘作成单独的存储卷直接加入到集群。

一来可避免RAID后硬盘可用容量的损失及RAID卡性能（如：更换硬盘后重做raid效率等）、故障问题；二来能够更直观高效地进行所有硬盘的负载管理及维护。同时更好发挥所有硬盘同时独立读写的高性能，如图5所示。

但集群包含大量硬盘，手工逐个硬盘去维护维护工作量很大且效率低。需要编写Linux bash脚本实现各主机所有硬盘的自动格式化，自动挂载文件目录。大大简化了运维工作，避免手工误操作，提升集群管理效率和可用性。因此，建议所有数据存储服务器配置容量大、数量多的硬盘，至少3TB×10块SATA硬盘。再辅以SSD加速设备,实现较高性价比。

同时我们也看到一些有待改进的问题:

比如，集群自带管理门户使用方便，但无鉴权，后续将通过Tomcat、IIS等中间件部署管理程序，增加鉴权页面，用户输入正确的验证信息才能跳转到管理系统页面，实现鉴权功能；集群自身的QoS功能较弱，需探索软件层面的解决方案，在与集群有效结合后来保证服务水平。

结语

通过横向对比及实例验证，选择一个具有比较优势的分布式文件存储系统；现有MFS、GFS等有中心节点设计的分布式文件存储的问题在于，尽管管理节点主备部署实现了元数据保护，但集群配置文件无保护，容错机制不够完善，导致故障恢复窗口时间长，成功率无法保证。

本文通过实例验证了“1个管理服务器+N个元数据日志服务器”的部署模式，使元数据更安全。同时借助脚本技术实现集群配置数据的自动备份和在多个节点服务器上的保存。

增强了集群故障恢复能力和效率，克服了此类有中心分布式存储的单点问题；实现Windows环境里对MFS存储数据的直接访问，解决了主流分布式文件存储都不支持Windows客户端的问题。

通过分布式文件存储系统的部署，实现了笔者单位当前云环境下文件存储系统可用性的提升及拥有成本的大幅降低，将逐步在重文件存储的应用上推广使用。