作者lzg21st·2022-03-14 11:01

存储工程师·brcb

基于华为高端NAS存储双活的POC测试

字数 11318阅读 5803评论 7赞 11

【摘要】近年来，银行业积累了越来越多的非结构化数据，在业务场景和存储系统建设上都在不断进行优化。本文以作者所在企业的业务需求以及存储系统优化实际出发，在高端NAS存储双活系统上线前进行了深度POC测试。从双活系统组网、架构健壮性以及业务系统适配上进行了多维度的测试，并形成了本POC测试报告，最终作为行里高端NAS双活系统规划和建设的依据。

# 1. 项目背景

我行自2018年开始建设NAS存储资源池，从而正式开启了业务数据的存储架构优化之路，对于文件类的数据由先前的GPFS向NAS存储逐步迁移转型。此外，结合存储系统分级体系建设以及业务系统的分级标准，在NAS存储资源池建设上同样也进行了分级存储建设。

为此，近两年来随着新核心系统的建设我行开始调研并构建高端NAS存储资源池。同时，在同城双中心构建高端NAS存储的双活架构以满足我行新核心、重要及重要支撑系统的文件共享需求及其文件的高可用需求。然而，高端NAS双活在我行首次实施，无论是该技术本身在我行网络架构中的适配性，还是在业务场景中的匹配上，甚至是存储运维人员对于这一新技术的全面掌握上都存在不确定性，甚至是盲点。因此，运维部门作为该项目建设的牵头部门，开展了深度的高端NAS双活POC测试。

# 2. 测试目的和测试思路

本项目计划通过深度的POC测试对高端NAS双活系统在应用场景、安全性以及功能性上进行充分验证，然后形成详尽的POC测试报告，最终作为高端NAS双活系统的规划和建设依据。测试目的主要包括以下方面：

第一，验证高端NAS双活架构在我行分区域建设的网络架构中的组网可行性。第二，验证高端NAS双活架构在各种单点和双点故障场景中的自身架构健壮性。第三，验证基于细粒度的单个业务系统的计划性站点切换演练的易用性和安全性。

对于POC测试原则最重要的是真实模拟或尽量贴近生产实际，因为在客户真实环境中的POC测试是最有说服力的，尤其是网络环境的真实性。同时，形成的POC报告也为后续方案规划和项目建设提供最强有力的数据支撑。为此，在充分考虑并评估生产业务影响的情况下，我们选择在生产网络区域进行了测试。为了规避测试对生产环境的影响，本次POC测试重点进行功能性测试，不做性能压力测试。

# 3. 测试准备和测试用例设计

## 3.1 高端NAS双活系统搭建

为了构建华为高端NAS双活系统，首先，需要完成两台华为OceanStor 18000系列高端全闪存在两个数据中心的安装配置。然后，按照双活系统的网络架构规划，完成四张独立的网络平面接入。具体如下：

- 两台OceanStor 18000系列高端全闪存完成硬件调试和配置。

- 完成高端NAS双活系统所需四张网络平面的准备和接入：

管理网络：用于存储的日常管理。

仲裁网络：提供NAS双活系统的仲裁功能，配置HA冗余架构的物理仲裁服务器，接入两个独立的VLAN，以便提升仲裁网络的健壮性。

业务网络：每台存储配置四个控制器，每两控为一组，分别接入核心网络区域和业务三区，形成两个故障漂移组。同城双中心的业务网络不打通大二层，即两个数据中心采用独立的IP地址。

复制网络：每个中心的两台专用复制交换机以FULL-MESH方式和存储进行连接，再通过平行连接方式和本中心的DWDM设备进行连接。
![](/home/attachment/202203/14/377499_164722933398288.png)
图一 华为高端NAS双活系统网络拓扑图

- 在业务三区和核心区分别准备至少一台业务测试主机，主机安装Vdbench IO仿真软件，用于后续高可用测试场景中的业务连续性测试。

## 3.2 测试用例设计

在测试用例的设计上，以高端NAS双活系统POC测试的目的为出发点，主要从高端NAS双活系统搭建、高可用性测试以及功能性测试三个维度进行本次POC测试用例的设计。具体如下表：

![](/home/attachment/202203/14/377499_164722729994934.png)
表一 华为高端NAS双活系统POC测试用例

# 4. 测试过程记录

## 4.1 双活平台搭建

4.1.1 快速部署NAS双活平台
![](/home/attachment/202203/14/377499_164722736012113.png)

1.添加远端设备
![](/home/attachment/202203/14/377499_164722529030330.png)
 ![](/home/attachment/202203/14/377499_164722530164260.png) 
2.创建双活域
![](/home/attachment/202203/14/377499_164722531816939.png)
![](/home/attachment/202203/14/377499_164722532232425.png)
![](/home/attachment/202203/14/377499_164722532680445.png)
![](/home/attachment/202203/14/377499_164722533115198.png)

## 4.2 高可用性测试

4.2.1 仲裁到主存储链路故障
![](/home/attachment/202203/14/377499_164722740568142.png)

1.在主端测试主机上运行vdbench工具
![](/home/attachment/202203/14/377499_164722542667377.png)

2.断开主端存储的仲裁链路，在存储界面上出现仲裁故障告警，看到仲裁服务器断开，链路为未连接状态以及端口断开状态。
![](/home/attachment/202203/14/377499_164722543210321.png)
![](/home/attachment/202203/14/377499_164722543546595.png)

3.租户双活pair状态不会受到影响
![](/home/attachment/202203/14/377499_164722544151482.png)

4.主机上的IO不受影响。
![](/home/attachment/202203/14/377499_164722544834301.png)

5.恢复主存储侧的仲裁链路，存储告警消失，同时仲裁服务器处于在线状态。
![](/home/attachment/202203/14/377499_164722545210176.png)
![](/home/attachment/202203/14/377499_164722545758644.png)

4.2.2 仲裁到备存储链路故障
![](/home/attachment/202203/14/377499_164722745176379.png)

1.在主端测试主机上运行vdbench工具
![](/home/attachment/202203/14/377499_164722549529621.png)

2.断开仲裁服务器到备存储的链路，在存储界面上出现仲裁故障告警，看到仲裁服务器断开，链路为未连接状态
![](/home/attachment/202203/14/377499_164722550234770.png)

3.租户双活pair状态不会受到影响
![](/home/attachment/202203/14/377499_164722550865917.png)

4.主机上的IO不受影响。
![](/home/attachment/202203/14/377499_164722551218246.png)

4.2.3 单条ISL链路故障
![](/home/attachment/202203/14/377499_164722748848852.png)

1.在主端测试主机上运行vdbench工具
![](/home/attachment/202203/14/377499_164722557349721.png)

2.在主存储上人为断开一条存储复制物理链路后，存储自动识别告警。
![](/home/attachment/202203/14/377499_164722557937776.png)
![](/home/attachment/202203/14/377499_164722558633631.png)

3.在双活域中也能正常显示链路断开
![](/home/attachment/202203/14/377499_164722559157881.png)

4.查看存储双活pair状态不受影响
![](/home/attachment/202203/14/377499_164722559728742.png)

5.查看测试主机侧IO不受影响，无IO中断现象。
![](/home/attachment/202203/14/377499_164722560418164.png)

6.恢复主存储上存储复制物理链路，告警消失。
![](/home/attachment/202203/14/377499_164722560882061.png)

4.2.4 全部ISL链路故障
![](/home/attachment/202203/14/377499_164722752687977.png)

1.断开主存储所有复制链路，存储上可以看见链路告警，双活域里链路全部故障
![](/home/attachment/202203/14/377499_164722565020298.png)
![](/home/attachment/202203/14/377499_164722565494200.png)

2.查看双活租户Pair运行状态处于未同步状态，文件系统pair健康状态处于故障，运行状态处于未同步。
![](/home/attachment/202203/14/377499_164722566163797.png)

3.查看主机侧IO无中断
![](/home/attachment/202203/14/377499_164722566656098.png)

4.恢复4条物理复制链路后告警消失，并且双活租户和文件系统pair自动恢复并同步，同步完成后双活租户和文件系统pair状态处于正常。
![](/home/attachment/202203/14/377499_164722567114561.png)
![](/home/attachment/202203/14/377499_164722567534809.png)

4.2.5 单台仲裁服务器故障
![](/home/attachment/202203/14/377499_164722758936125.png)

1.在主机上运行vdbench工具
![](/home/attachment/202203/14/377499_164722571761689.png)

2.关闭1台仲裁服务器，看到仲裁离线，告警上报，仲裁切换到另外一台仲裁服务器上。
![](/home/attachment/202203/14/377499_164722572255245.png)
![](/home/attachment/202203/14/377499_164722572527379.png)
![](/home/attachment/202203/14/377499_164722573113329.png)

3.存储双活租户pair状态不受任何影响
![](/home/attachment/202203/14/377499_164722573614195.png)

4.测试主机IO不受影响，无中断。
![](/home/attachment/202203/14/377499_164722575939019.png)

5.上电恢复仲裁服务器后，仲裁服务器恢复在线状态且仲裁链路恢复正常。
![](/home/attachment/202203/14/377499_164722576614861.png)

4.2.6 两台仲裁服务器故障
![](/home/attachment/202203/14/377499_164722764084187.png)

1.在主机上运行vdbench工具
![](/home/attachment/202203/14/377499_164722604968898.png)

2.关闭两台仲裁服务器，看到仲裁离线，告警上报。
![](/home/attachment/202203/14/377499_164722605415812.png)

3.存储双活租户Pair以及文件系统Pair状态不受影响。
![](/home/attachment/202203/14/377499_164722606185544.png)

4.测试主机IO不受影响，无IO中断。
![](/home/attachment/202203/14/377499_164722606752611.png)

5.两台仲裁服务器恢复后，存储界面中显示其为在线状态。
![](/home/attachment/202203/14/377499_164722607367206.png)

4.2.7 主存储故障
![](/home/attachment/202203/14/377499_164722770193624.png)

1.在主机上运行vdbench工具后，拔掉主存储的电源后存储无法登录管理界面。备存储上出现链路断开告警并且备存储自动切换为优先站点，状态为激活并且文件系统自动切换为读写状态。
![](/home/attachment/202203/14/377499_164722614180432.png)

2.主存储下电后已无法正常登录图形化界面，备存储识别到链路断开告警。
![](/home/attachment/202203/14/377499_164722614660956.png)

3.备存储变成了优先站点并对外提供服务
![](/home/attachment/202203/14/377499_164722615173406.png)

4.主机侧出现持续IO归零。
![](/home/attachment/202203/14/377499_164722616199905.png)

5.需要人工干预处理，强制卸载文件系统，卸载成功后再重新以备存储侧的业务地址mount文件系统即可。

6.上电主存储，存储之间复制链路自动恢复正常，双活租户pair以及文件系统Pair也会自动恢复正常。
![](/home/attachment/202203/14/377499_164722616934242.png)

7.原主存储由优先站点切换为非优先站点。
![](/home/attachment/202203/14/377499_164722617473969.png)

4.2.8 备存储故障
![](/home/attachment/202203/14/377499_164722773561554.png)

1.在主机上运行vdbench，重启备存储来模拟备存储故障
![](/home/attachment/202203/14/377499_164722621867989.png)

2.重启备存储后，主存储上已经识别到复制链路故障且处于未连接状态
![](/home/attachment/202203/14/377499_164722622248423.png)

3.主机IO短暂归零丢一个包
![](/home/attachment/202203/14/377499_164722622790518.png)

4.备存储恢复后，复制链路恢复正常，双活租户Pair以及文件系统Pair自动恢复正常。
![](/home/attachment/202203/14/377499_164722623316771.png)

4.2.9 ISL链路故障且仲裁到主存储链路故障
![](/home/attachment/202203/14/377499_164722777144528.png)

1.在主机上运行vdbench，然后断开主存储上所有复制物理链路
![](/home/attachment/202203/14/377499_164722628227868.png)

2.存储复制链路断开，图形化界面已经自动识别告警
![](/home/attachment/202203/14/377499_164722628712830.png)

3.断开主端存储的仲裁链路后，主存储上仲裁服务器状态已经处于离线状态
![](/home/attachment/202203/14/377499_164722629461901.png)

4.存储双活发生切换，备存储切换成优先站点继续对外提供业务，测试主机IO持续归零
![](/home/attachment/202203/14/377499_164722629954708.png)

5.需要强制卸载文件系统，然后通过备存储侧的地址挂载文件系统才能正常访问共享目录。

6.恢复复制物理链路，双活租户pair和文件系统Pair自动恢复。
![](/home/attachment/202203/14/377499_164722630525748.png)

4.2.10 双活场景下主存储单个控制器故障测试
![](/home/attachment/202203/14/377499_164722780195861.png)

1.在主机上运行vdbench，拔出主存储B控制器
![](/home/attachment/202203/14/377499_164722634413275.png)

2.在存储上已监控到B控制器拔出
![](/home/attachment/202203/14/377499_164722634881908.png)

3.存储双活租户Pair以及文件系统Pair运行正常无影响
![](/home/attachment/202203/14/377499_164722635394090.png)

4.逻辑IP发生漂移，主用端口发生改变，主机侧丢两个IO
![](/home/attachment/202203/14/377499_164722636063391.png)

5.插回控制器，逻辑IP漂移回原来的主用端口，主机IO再次短暂归零
![](/home/attachment/202203/14/377499_164722636424813.png)

4.2.11 主存储故障+仲裁服务器故障
![](/home/attachment/202203/14/377499_164722786432899.png)

1.在主机上运行vdbench
![](/home/attachment/202203/14/377499_164722655395318.png)

2.下电主存储，备存储已经识别到链路断开告警
![](/home/attachment/202203/14/377499_164722655837563.png)

3.备存储切换成优先站点并处于激活状态，对外提供业务
![](/home/attachment/202203/14/377499_164722656441246.png)

4.主机IO持续归零需要人工干预。
![](/home/attachment/202203/14/377499_164722656926532.png)

5.在主机侧测试主存储逻辑IP地址连通性，大约丢5个数据包后，备存储上的逻辑IP地址可以连通。

6.重启两台仲裁服务器（模拟仲裁服务器故障）

7.主机侧需要强制umount文件系统，然后用备存储的业务地址重新挂载文件系统。

8.上电主存储后双活pair自动恢复，然后恢复仲裁服务器
![](/home/attachment/202203/14/377499_164722657520171.png)

4.2.12 仲裁服务器故障+主存储故障
![](/home/attachment/202203/14/377499_164722790545528.png)

1.主机上运行vdbench，然后关闭两台仲裁服务器（模拟仲裁服务器故障）

2.仲裁服务器关闭后，存储自动识别到仲裁服务器断开告警![](/home/attachment/202203/14/377499_164722661824150.png)

3.双活系统仲裁模式自动切换为静态优先级模式
![](/home/attachment/202203/14/377499_164722662871148.png)

4.主机侧无IO无中断现象。
![](/home/attachment/202203/14/377499_164722663452726.png)

5.下电主存储后，测试主机IO持续归零
![](/home/attachment/202203/14/377499_164722663842893.png)

6.备存储已经自动识别到复制链路断开告警
![](/home/attachment/202203/14/377499_164722664381771.png)

7.主存储故障后并没有自动切换，备存储处于非优先站点并且处于未激活状态。
![](/home/attachment/202203/14/377499_164722664836036.png)

8.强制启动备存储，使其切换成优先站点并处于激活状态，并进行业务恢复。
![](/home/attachment/202203/14/377499_164722665876117.png)

9.备存储已经切换成优先站点并处于激活状态
![](/home/attachment/202203/14/377499_164722666547626.png)

10.主机侧需要强制卸载文件系统，然后以备存储侧的地址重新挂载文件系统。主机继续用vdbench进行文件系统测试验证。

11.上电主存储后，需要手动同步pair，原主存储站点自动变为非优先站点
![](/home/attachment/202203/14/377499_164722667441713.png)
![](/home/attachment/202203/14/377499_164722667918011.png)

12.同步完成后租户双活Pair和文件系统Pair都恢复为正常状态
![](/home/attachment/202203/14/377499_164722668381229.png)

13.恢复仲裁服务器，双活系统的仲裁模式自动恢复成仲裁模式
![](/home/attachment/202203/14/377499_164722668955637.png)

14.恢复过程中，主机IO不受影响
![](/home/attachment/202203/14/377499_164722669596608.png)

## 4.3 功能性测试

4.3.1 文件系统定时快照
![](/home/attachment/202203/14/377499_164722794837475.png)

1.对FS04文件系统创建定时快照策略
![](/home/attachment/202203/14/377499_164722675434026.png)

2.往FS04文件系统里写入文件，过一段时间后可以看到快照会产生，快照的数量和名称同存储管理界面中的是一致的。
![](/home/attachment/202203/14/377499_164722678138922.png)
![](/home/attachment/202203/14/377499_164722678525056.png)

## 4.4 单业务系统主从切换测试

4.4.1 基于单个业务系统的主从切换
![](/home/attachment/202203/14/377499_164722798124188.png)

1.切换前，主机运行vdbench测试工具
![](/home/attachment/202203/14/377499_164722682646439.png)

2.主从切换，在主存储上进行租户主从切换操作
![](/home/attachment/202203/14/377499_164722683130227.png)

3.切换完成后，备存储租户下的逻辑地址处于激活状态。
![](/home/attachment/202203/14/377499_164722683783004.png)

4.整个切换过成中，测试主机IO持续归零
![](/home/attachment/202203/14/377499_164722684343637.png)

5.主机侧需要手工强制卸载文件系统，然后以备存储侧的业务地址重新挂载共享文件系统。

# 5. 测试结论

在对华为高端NAS双活POC测试中，按照业务网络是否打通大二层进行了两轮测试，本文是按照不打通同城大二层进行的测试。

通过对比测试，业务网络平面既可以支持两中心大二层打通的网络架构，也支持不打通大二层，使用各中心独立IP地址的方案。两种网络架构在存储端的RTO指标是一致的，而最主要的区别主要在于大二层打通的架构可以获得更好的主机端全局的RTO指标。在大二层打通的情况下，当发生站点切换时，主机侧可以无感知的恢复NAS连接。而对于独立IP的方案，正如文中高可用性测试章节特定场景下所描述的那样，需要主机侧重新执行NAS存储的挂载。

总之，通过详细的POC测试，不但验证了华为高端NAS双活产品可以满足我行的业务需求，也验证了在各种故障场景下，华为高端NAS双活系统的架构健壮性。在我行存储资源池分类分级建设中，每种类型的存储分别适用于特定的业务场景。如FC SAN存储以其高并发和低延迟特性，主要用于数据库场景。而NAS存储主要用于业务系统文件共享或者是不同业务系统间的文件交互。华为高端NAS双活系统很好的满足了我行重要业务系统的文件共享需求、系统间文件交互平台建设需求以及跨数据中心的文件高可用需求。

华为OceanStor 18000系列是全新一代高端全闪存存储系统，为企业关键业务提供最高水平的数据服务。具备创新的高可靠SmartMatrix架构、更高的扩展性、全闪存设计的高性能以及面向混合云的演进方案，与我行的应用需求与发展要求相符合。由于技术产品及方案的复杂性和测试方案的完备性，本POC测试结果仅代表我行实际测试情况。撰写本文仅希望能抛砖引玉，为同业存储架构选型提供有益的参考。

nas存储 poc测试存储双活高端存储

著作权归作者所有

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

添加新评论7 条评论

xiangxiang1999系统架构师北京某技术公司
2023-08-02 20:41

内容详尽，感谢分享！

joyyoung售前工程师新华三技术有限公司
2023-04-23 16:24

rootA存储工程师ASP
2022-10-14 10:58

感谢分享很详细的测试结果、也为同行业架构和设备的选型提供了很好的参考价值；华为高端NAS已满足现有的架构需求和业务承载能力；

flashbang系统运维工程师INC
2022-06-23 10:37

老师，有两个问题。（1）咱们的 NAS 应用场景是什么；（2）为什么在NAS上使用高端的全闪阵列。

bb652826616： @lzg21st 不错的分享经验

2022-07-07 08:59

lzg21st： @flashbang 兄弟你好！ 1.nas在我们这边应用场景主要是两类，一类是单个业务系统应用服务器集群文件共享场景，另一类是用于不同业务系统进行文件交互使用，也就是不同业务系统采用共享文件系统里边的子目录实现。 2.在我们这边，存储进行了分级分类建设，不同级别的存储资源用于承载不同级别的业务系统，像高端nas存储主要用于承载重要的业务系统，同时通过部署nas双活架构，满足重要系统跨站点的高可用需求。

2022-06-23 12:41

添加新回复

ltzxlwj700m

系统工程师中*银行
2022-04-11 15:54

【文章价值点】本文基于构建高端NAS存储资源池的契机，使用华为高端NAS存储进行双活POC测试，测试重点为功能性测试，不涉及性能压测。作者详细描述了POC测试目的和测试思路。【文章建议】文章内容详实，作者的测试案例设计详细，覆盖场景较全，对其他有NAS替换需求的金融行业来说很有参考价值。

sharkjam运维人员深圳市某公司
2022-04-08 16:38

高端设备加上高可用方案，想想我公司用的nas服务器在家用的多盘方案，望尘莫及，感谢分享

feidang技术经理方正国际软件有限公司
2022-03-15 12:26

测试场景全面，测试记录详实，感谢作者。请教几个问题： 1.从测试过程来看，只在一个中心部署了测试主机，将来也是这样吗？同一个业务，不会在两个中心都部署吗？ 2.两中心大二层打通后，两台存储只有一个逻辑IP？ 3.按照业务网络是否打通大二层进行了两轮测试，最后选择了哪种呢？谢谢！

feidang： @lzg21st 谢谢！

2022-03-30 15:06

lzg21st： @feidang 你好！ 1.应用集群在两个中心都有服务器部署的，应用层是双活的。 2.业务大二层打通后，同一个租户里可以配置相同的lif逻辑地址，存储切换后，ip也会飘到从端存储上。然后不同的租户都可以配置相应的逻辑lif端口和地址。 3.选择了本文测试场景中的未打通大二层的架构。

2022-03-16 12:40

添加新回复

Ctrl+Enter 发表

匿名评论

基于华为高端NAS存储双活的POC测试

添加新评论7 条评论

本文隶属于专栏

作者其他文章

相关文章

相关问题

相关资料