共享文件系统使用之变革——从GPFS到NAS

字数 4651阅读 5150评论 5赞 11

# 1 概述

## 1.1 背景
我行ODS数据平台作为为全省农商行供数的重要数据系统，其中的ETL集群起着每日进行数据加工处理的功能。目前ODS ETL由10台PC服务器组成集群，每台服务器通过SAN网络连接集中存储，每台服务器操作系统上安装IBM GPFS软件实现10台服务器并行访问同一个容量为14TB的共享文件系统。

随着业务的飞速发展，存储数据量快速增长，IOPS不断提高，原有存储架构的容量和性能逐渐面临瓶颈。另外，由于底层的主要集中存储使用年限已超8年，面临故障率高和性能不足的风险。在这样的背景下，我们计划对ODS ETL整体架构重新进行设计和建设，

搭建一套全新架构，支撑未来业务的持续发展。

## 1.2 目标
随着业务的飞速发展，存储数据量快速增长，IOPS不断提高。为了支撑未来业务的高速发展，我们计划对搭建一套全新的ODS ETL架构，实现功能和性能的提升。这套新的架构首先要满足ODS ETL批量处理的性能增长需求，同时实现底层存储的双活架构，提升整体架构的高可用。

# 2 GPFS使用现状

## 2.1 GPFS架构

** ODS ETL的GPFS架构图如下：**
![](/home/attachment/202210/10/1215117_166536654610849.png)

目前ODS ETL集群由10台PC服务器组成集群，每台服务器通过SAN网络连接IBM 存储网关SVC，SVC下挂两台DS8000存储实现高可用。同时，每台服务器上安装IBM GPFS软件实现10台服务器并行访问同一个来自底层存储的共享文件系统，容量为14TB。在ETL集群批量数据加工处理过程中，整个集群对该GPFS共享文件进行并行读写。

GPFS的共享存储功能是构建在SAN存储之上，集群中的每台服务器需要接入SAN网络并分配SAN存储，再由上层GPFS软件进行并行访问功能的设计和控制。GPFS集群的运行维护涉及PC服务器、SAN存储和GPFS软件三方面。

## 2.2 GPFS处理能力
针对我们在业务高峰期间某日收集的24小时GDFS性能数据进行分析。数据采集每10秒一次，共采集8687个时间点，每个时间点的数据包括ODS ETL集群中十台服务器每台的读写吞吐量和IOPS等内容。

下面从读写吞吐量和IOPS两个指标分析。读写吞吐量指标体现服务器到存储的带宽使用情况，IOPS指标体现存储端的读写处理性能。

**（1）、GPFS集群24小时吞吐量**
![](/home/attachment/202210/10/1215117_166536658720826.png)

整个GPFS集群的吞吐量带宽平均值为1400 MB/s，峰值为3989 MB/s。吞吐量在1000 MB/s以上的比例为1.6%，即98.4%的时间里GPFS集群的吞吐量在1000 MB/s以下。峰值时间点数据负载集中在etl7-etl12这6台服务器上，每台服务器的读写吞吐量均在1000 MB/s以下，最高值为etl7的914.4 MB/s。对应时间点的IOPS为15243。

**（2）、GPFS集群24小时IOPS**
![](/home/attachment/202210/10/1215117_166536660675548.png)

整个GPFS集群的IOPS平均值为1673，峰值为33382。吞吐量在10000以上的比例为2%，即98%的时间里GPFS集群的吞吐量均在10000以下。峰值时间点数据负载集中在etl0、etl11这2台服务器上，主要行为是写操作，分别达到10804次和21351次。对应消耗的带宽为338.8 MB/s。

# 3 变革背景

## 3.1GPFS软件版本过期
GPFS当前版本4.2,操作系统版本suse11 sp4，版本已过期，缺少IBM技术支持。GPFS软件和操作系统版本都需要升级，且需要停机升级，对生产系统运行影响较大。

## 3.2配合底层SAN存储更新换代
GPFS构建在SAN存储之上，我们GPFS集群底层使用的存储为IBM SVC虚拟化架构下的两台DS8000存储。其中一台DS8870使用年限已近十年，目前存在故障率较高、性能低下等风险。我们经过考虑，计划在2022年将这台DS8870存储下线，同时计划在三年内逐步迁移SVC虚拟化架构下的数据至华为高端存储。在这样的背景下，我们ODS数据平台底层使用的存储面临着更新换代的局面，需要抉择是继续购买新的集中存储替换使用还是选择新的共享存储技术路线整体替换原有的GPFS架构。

## 3.3整体架构维护复杂
GPFS整体架构维护管理成本较高。GPFS的维护涉及IP网络和SAN网络两套网络。其中SAN网络包括所有服务器的HBA卡、SAN交换机、服务器和交换机之间的光纤线路、存储网关、集中存储等物理设备，链路环境较多，维护较复杂。

# 4 技术路线选择
我们ODS ETL集群对共享存储的需求主要为共享文件存储，多个节点同时对共享存储中的数万个小文件进行读写操作，对同一个文件的写操作需要有一致性控制。

我们先对目前的技术路线进行分析。文件存储技术按照底层硬件架构可以分为集中式NAS存储和分布式文件系统。

集中式NAS存储生态完善，在各大企业数据中心文件共享服务中占据很大比例。集中式NAS存储设备由机头和扩展柜组成，集成度高，部署和运维相对简单。从应用使用角度，当前主流集中式NAS的特性比较适合大量小文件存储的场景。

分布式文件系统与集中式NAS相比，区别在于提供了并行化和横向扩展的能力。分布式文件系统按照架构有无中心分为两类，一种是有中心架构的分布式文件系统架构，包括GFS、HDFS等。另外一种是完全无中心的分布式存储架构，包括CephFS、GlusterFS等。

GFS和HDFS的默认最小存储单元为64M、128M甚至更高，是适合大文件尤其是GB级别的大文件存储场景的分布式存储系统。     GlusterFS是采用无中心对称式架构，没有专用的元数据服务器，元数据存在于文件的属性和扩展属性中。数据分片分布，也更适合大文件存储。

CephFS是分布式存储系统Ceph面向文件存储的接口，CephFS 构建在RADOS（Ceph的核心技术-分布式对象存储）之上,继承RADOS的容错性和扩展性，支持冗余副本。

# 5 NAS使用方案

经过充分分析和考虑，我们决定在新的ODS ETL集群中采用集中式NAS解决方案。采用NAS解决方案具有以下优点：
（1）目前主流国产高性能集中式NAS的IOPS可达10-11万（以一般小文件，8k或16k文件，70%读，随机读写为模型），远超原有GPFS架构IOPS峰值33382。

（2）NAS存储配置双控制器，每个控制器配置2张四端口的万兆网卡，即每个控制器8个万兆网口做绑定，配置负载均衡。该配置下NAS设备单控制器带宽可达到8GB/s，双控制器带宽一共可以达到16GB/s。NAS端带宽完全满足原有GPFS 峰值3.9GB/s的带宽需求。

（3）ETL客户端每台服务器增加配置2张万兆网卡做绑定，用于NAS访问专用。ETL单台服务器NAS访问带宽可以达到2GB/s。ETL单独客户端带宽完全满足原有GPFS架构下单台最大0.9GB/s的带宽需求。

## 5.1 整体架构设计
计划采购2台新型高性能集中式全闪NAS设备为ODS ETL集群提供共享存储服务。新的架构图如下：
  ![](/home/attachment/202210/10/1215117_166536663355335.png)

（1）采购两台新型NAS设备组建数据双活架构。当一台NAS存储故障后，可切换到另一台NAS存储上，实现共享数据的高可用。

（2）NAS存储配置双控制器，每个控制器配置2张四端口的万兆网卡，即每个控制器8个万兆网口做绑定，配置负载均衡。该配置下NAS设备单控制器带宽可达到8GB/s，双控制器带宽一共可以达到16GB/s。NAS端带宽完全满足当前GPFS 峰值3.9GB/s(3989 MB/s)的带宽需求。

（3）ETL客户端每台服务器增加配置2张万兆网卡做绑定，用于NAS访问专用，与原有业务网卡物理隔离。ETL单台服务器NAS访问带宽可以达到2GB/s。ETL单独客户端带宽完全满足当前GPFS架构下单独最大0.9GB/s(914.4 MB/s)的带宽需求。

## 5.2 改造带来的提升

（1）新的架构中无需搭建SAN网络，极大节省了原GPFS架构中SAN存储维护成本。同时释放了存储网关SVC下两台存储的容量，符合SVC架构逐渐迁移下线的整体优化策略。

（2）新架构去除了对IBM GPFS软件的依赖，同时新NAS设备可选择国产主流NAS型号，产品技术支持和响应速度得到极大提高。另一方面，也符合目前IT基础设施国产化的趋势。

（3）新架构整体性能得到提升。
目前主流国产高性能NAS的IOPS可达10-11万（以一般小文件，8k或16k文件，70%读，随机读写为模型），远超原有GPFS架构IOPS峰值33382。

新架构下ETL单台服务器NAS访问带宽可以达到2GB/s，远超原有GPFS架构下ETL服务器单台最大0.9GB/s(914.4 MB/s)的带宽需求。

新架构下ETL集群带宽最大可达16GB/s，远超原有GPFS架构下ETL集群带宽峰值3.9GB/s(3989 MB/s)的带宽需求。

（4）管理维护更简单。针对服务器集群的扩容和下线、针对共享文件系统容量的扩容和缩容等维护均变得更简单，风险更可控。

# 6 GPFS迁移规划
在整体架构规划完毕后，我们下一步需要考虑的如何将如此大容量的数据从GPFS迁移到新NAS架构上。我们计划分几个步骤进行实施：

（1）数据分析。提前对原有的14TB数据进行全面梳理分析，根据梳理结果分为可删除的数据、业务切换前必须迁移的数据、业务切换后分批迁移的存量数据三大类。

（2）数据清理。针对梳理结果分为可删除的数据，提前分批进行备份后删除清理，从而尽可能缩小原有GPFS共享文件系统的容量。

（3）切换前数据迁移。针对必须在业务切换之前完成迁移的存量数据，进行分析后分批提前完成迁移，尽可能减少在停机切换窗口中迁移的数据量。

（4）停机迁移。业务切换的停机窗口迁移必要的当前数据，需要提前计算好数据量、迁移带宽以及迁移耗时。最好能够提前进行迁移速度的测试，从而控制在停机窗口内完成。

（5）切换后数据迁移。针对可以在业务切换之后进行分批迁移的存量数据，进行分批次迁移，控制好每次迁移的数据量和网络带宽，避免对业务系统的正常使用。

# 7 总结
GPFS作为IBM公司开发的高性能共享文件系统，在过去的20多年里面在共享文件存储领域具有举足轻重的地位，其价值也得到用户认可。如今，随着高性能NAS以及分布式存储的兴起和成熟，更多的共享文件存储方案摆在用户面前。我们经过考虑，决定选择采用当前高性能的双活NAS作为ODS ETL数据处理系统将来的共享文件存储解决方案。当然，每个业务系统特点不同，每个用户的使用方式也不同，对于共享文件存储的解决方案的选择，适合用户自己的才最好的。

nas GPFS 共享文件系统

著作权归作者所有

如果觉得我的文章对您有用，请点赞。您的支持将鼓励我继续创作！