☰
H3C存储一体机CX5000G G3:SAN/NAS融合配置与排障实践
2026/9/29 15:10:34 网站建设 项目流程

简介:伴随企业关键业务对存储可靠性、容量与运维效率要求的持续提升,H3C UniStor CX5000G G3 系列存储一体机成为数据中心及边缘场景中常见的存储平台。本份用户指南由新华三技术有限公司发布,面向网络规划人员、现场技术支持与维护工程师、负责集群配置和维护的管理员,内容覆盖安全规范、产品介绍、安装与拆卸、上电和下电、部件更换、布线等全流程操作。资源包共1个文件,文件类型为pdf,整体大小16.26MB,便于离线查阅与团队内部培训。指南中不仅提供了命令行格式约定、图形界面操作说明和各类安全标识,还针对设备运行、电气、电池及激光安全给出明确注意事项,有助于读者在部署和维护过程中规避风险。目前已有234人学习下载,对正在规划或使用该系列存储一体机的工程师而言,这份官方手册可作为硬件安装、日常运维与故障排查时的重要参考。

1. H3C UniStor CX5000G G3 存储一体机:一台把 SAN 和 NAS 塞进同一机箱的设备

存储一体机这个概念喊了好多年,真正拆过机器的人都知道,一体机和“把服务器装个磁盘阵列软件”是两码事。H3C UniStor CX5000G G3 属于后者:控制器、盘柜、SAN 和 NAS 网关都在同一套硬件里,你不需要再单独买 NAS 头、单独配 FC 交换机,一台设备同时出块存储和文件存储。适合的场景很明确:虚拟化平台、数据库、还有那种机房空间和电力都不宽裕的中型环境。这份指南我拆过一遍,硬件布局、RAID 策略、多路径、启动失败排查都在里面,本文把能直接参考的配置步骤和踩坑记录整理出来,给准备上手的人省点弯路。

2. 硬件架构与组网选型:从控制器、盘位到前端协议的落地顺序

2.1 控制器与盘位布局:先搞清这台机器能挂多少盘

CX5000G G3 的硬件结构不复杂,但规划顺序很重要。先看控制器。设备标配双控制器,每个控制器上有独立的 CPU、缓存和板载闪存,缓存掉电有电池保护,这决定了你在划分 RAID 时不需要像老阵列那样特别担心缓存数据丢失。控制器上有 4 个 10GE 端口和 4 个 16G FC 端口,意味着同一台设备既能走 FC 给数据库用,也能走 iSCSI 给虚拟化平台用。

盘位布局是另一个关键点。G3 系列按盘位数分成不同型号,常见的是 12LFF 和 25SFF 两种盘笼。12LFF 适合大容量冷数据,25SFF 适合用 SSD 跑热数据。混插要谨慎:同一 RAID 组里不要混插 SSD 和 HDD,控制器会按最慢的盘来限速。扩容硬盘时,建议至少一次插满一个盘笼的背板通道,通道带宽共享,插单盘跑出来的性能和你规划的不一样。

部署规划习惯上先画一张拓扑再动手:两台控制器做主备,每台控制器分别连两台 FC 交换机,后端盘笼通过 SAS 线缆连到控制器,形成冗余路径。这样画完之后,再进初始化配置,思路会顺很多。

2.2 前端协议与交换机选型:FC 和 iSCSI 怎么选

协议选型取决于上层的业务类型。数据库业务对延迟敏感,走 FC 更稳,CX5000G G3 的 16G FC 端口现在依然够用,单端口跑满吞吐没压力。虚拟化平台虚机数量多,单虚机吞吐不高的场景,用 10GE iSCSI 成本更低,线缆和交换机都用普通的,不用额外买 FC 光模块。混合场景就把 FC 端口分给数据库、iSCSI 端口分给虚拟化,一台设备两侧同时工作,这是存储一体机相对独立阵列的优势。

如果选 iSCSI 路线,交换机注意看背板缓冲。国产中低端交换机里,H3C S1850 系列做接入层够用,但别拿它做存储核心交换机。存储流量是长连接大包突发,交换机 buffer 不足时,即便端口没跑满也会出现延迟抖动。我一般会选带大缓存或专用存储级的交换机,端口上按 10GE 的速率配满。

2.3 初始化部署:从串口到 Web 管理台的第一次登入

新设备开箱后,先用串口线连控制器上的管理口。默认管理 IP 通常印在机器标签上,找不到就直接看串口启动信息。串口登录后,进入命令行初始化界面,按提示设置管理 IP、掩码、网关。这一步的关键是两台控制器的管理 IP 要规划在同一网段,后续 Web 管理台通过浮动 IP 访问任意一台都能接管。

# 串口进入 CLI 后,典型初始化命令序列 system interface mgmt0 ip address 192.168.10.10 255.255.255.0 ip gateway 192.168.10.1 save

管理口配完后,浏览器打开https://192.168.10.10,首次登录会让你创建管理员密码。之后按向导提示做三件事:发现盘笼、确认控制器角色、分配热备盘。发现盘笼时如果某块盘显示 Unexpanded,别慌,那是还没有加入 RAID 组的正常状态。

3. 存储池与卷管理:RAID 策略、Thin Provision 与热备盘规划

3.1 RAID 策略选择:RAID 5、RAID 6 还是 RAID 10

存储一体机的 RAID 策略直接影响可用容量和重建效率。常用有三种:

RAID 级别最少盘数可用容量用途建议
RAID 53(N-1)×单盘成本敏感、允许长重建窗口
RAID 64(N-2)×单盘大容量盘必须用,双盘故障安全
RAID 104N/2×单盘数据库、核心虚机

大容量盘建议加 RAID 6 的核心理由是重建时间。一块 16T 的 NL-SAS 盘重建可能要跑十多个小时,这段时间里如果再来一块盘故障,RAID 5 直接丢数据,RAID 6 还能扛住。RAID 10 则优先保证性能,适合放在数据库场景,但容量成本高了一倍。CX5000G G3 的控制器默认支持 RAID 0/1/5/6/10,创建 RAID 组时界面会直接显示可用容量和最小盘数要求。

3.2 创建存储池与卷:界面操作与参数说明

先在 Web 管理台把物理盘划分到存储池:

  1. 进入“存储池 → 创建”,选择要纳管的盘,建议同一批同型号同转速,避免不同盘混在一个池里。
  2. 选择 RAID 策略,设置热备盘。热备盘的坑在于:有的现场把热备盘勾选成“全局热备”,有的选“专用热备”。全局热备适合盘笼多、故障不确定的场景;专用热备绑定到特定 RAID 组,能更快开始重建,但灵活性差。没有特别原因,用全局热备。
  3. 存储池创建完成后,在池下创建卷。卷类型选“精简”还是“厚”,看业务是否在你控制之内。

3.3 Thin Provision 的边界:超分配不是玄学,是有数学的

Thin Provision 是这个系列默认推荐使用的卷类型,它按需分配物理空间,创建 2T 卷实际可能只占 100G。问题出在超分配比例上。100T 的存储池,你可以创建 150T 的精简卷,但一旦实际写入量超过池的物理容量,所有卷全部只读,数据库直接报错。

我一般控制超分配比例在 1.5 倍以内,并且给池设置一个 80% 的告警阈值。CX5000G G3 的告警配置里,可以设置池容量使用率达到 80% 时发送邮件事务通知。别依赖这个阈值自动扩容——扩容需要现场插盘,冷备盘不在现场的情况下,80% 阈值到 90% 的缓冲窗口很短。

4. 主机接入与多路径配置:FC、iSCSI 与多路径软件的配合

4.1 FC 主机接入:zoning 与 LUN 映射

FC 接入的路径是:存储控制器 FC 端口 → FC 交换机 → 主机 HBA 卡。交换机上必须做 zoning,不做的后果是存储侧能看到所有主机,主机侧能看到存储的所有端口,一旦某台主机发起错误指令,影响范围可能波及其他服务器。

zoning 尽量做单 initiator/单 target,也就是一台主机只映射到它要访问的存储端口。H3C FC 交换机上用zoning字面命令创建 zone:

// 交换机 CLI 创建 zone 示例,两个口:主机 HBA 口和存储 FC 口 zone create name db_zone member 1,0 db_hba zone create name db_zone member 1,8 cx5000g_port cfgadd "DB_Cfg", db_zone cfgenable "DB_Cfg"

LUN 映射先看存储侧。把卷做成 LUN,再映射到主机 HBA 的 WWN。映射时存储侧通常会提示选择启动器类型,Linux 选 Linux,Windows 选 Windows,影响的是返回值格式。映射完成后主机侧用cat /proc/scsi/scsi能看到新磁盘。

4.2 iSCSI 主机接入:CHAP 认证与链路聚合

iSCSI 接入在 CX5000G G3 上配置不复杂,但建议开 CHAP 认证。存储侧开 CHAP 后,主机侧 initiator 必须配置相同的用户名和密码,密码要求不少于 12 位且包含大小写字母和数字。生产环境里见过现场为了省事关掉 CHAP,结果交换机上任意一台机器都能发现存储 target,这是真实事故,血肉教训。

链路方面,主机两个 10GE 口分别接两台交换机,存储侧两个 iSCSI 端口分别接两台交换机,然后在主机侧配置 multipath,而不是试图做链路聚合。存储一体机的 iSCSI 不适合做 LACP 聚合,多路径软件的效果远比聚合好,故障切换粒度也更细。

4.3 多路径软件:让故障切换不再靠运气

Linux 主机下推荐用 device-mapper-multipath。安装后配置/etc/multipath.conf,核心参数如下:

# /etc/multipath.conf 关键片段 defaults { user_friendly_names yes path_grouping_policy multibus path_checker tur failback immediate }

路径分组策略选multibus,意思是所有活动路径均参与 IO 分发。path_checker tur是测试单元就绪命令,比默认的 readsector0 更轻量,IO 压力大的情况下不容易误判。配置完后可以跑multipath -ll查看是否生成多路径设备链路,如果只看到一条路径,回到交换机上查 zoning 是不是漏配了一个端口。

5. 避坑与常见问题排查:启动失败、堆叠、聚合口满、时间同步

5.1 启动失败:日志在哪看,先查什么

存储一体机上电后控制器起不来,这是现场最紧张的时刻之一。现象是前面板指示灯常亮但无闪烁,串口输出停在 bootrom 阶段。常见原因是控制器电池电量过低。这台设备在电池电量不足时会暂停启动流程,并不是故障,只是保护机制。

解决:等电池充电完成,一般 30 分钟到 1 小时,重新上电即可。如果等待后仍无法启动,串口登录 bootrom 菜单,检查启动镜像是否被意外覆盖,用boot命令指定备用镜像分区启动。CX5000G G3 的控制器有两个镜像分区,主分区坏了从备用分区启动是整机可用性的兜底。

5.2 堆叠配置踩坑:split brain 与优先级

有些现场把两台 CX5000G G3 做成堆叠来扩展卷容量,这本身没问题,但堆叠配置里最容易翻车的是脑裂。现象:两台控制器各自认为自己是主控,管理台上出现两个独立系统,部分卷只能从其中一台访问。

原因往往是堆叠链路不稳定。堆叠口通常是 10GE 端口,如果用的是普通网线而不是直连 DAC 线,物理抖动概率会放大。解决:优先用专用堆叠线缆或 DAC 线,减少中间环节。配置优先级时,确保一台控制器优先级明显高于另一台,高优先级作为主控,低优先级做备。优先级相同意味着主控选举变成随机行为,升级维护时非常容易翻车。

5.3 聚合口满:链路负载不均的表象与根因

“聚合口满”这个报错经常出现在交换机侧,现象是存储的一对聚合端口里,一个口流量接近 100%,另一个口只有 20%。看起来像是“满”了,其实链路远没到瓶颈。根因是流量哈希算法把大量流量打到了同一端口。

检查思路分两步。第一步看交换机聚合组是不是已经把所有端口都加入,如果聚合组只有两条物理链路,那就只有两个哈希桶。第二步看流量的源目 MAC 或 IP 特征,虚拟化平台里大量虚机共享少数几个 MAC 地址,哈希容易碰撞。解决方式是调整交换机负载均衡模式,按 IP 和端口做五元组哈希,或者在主机侧启用多路径让流量平均分散到不同物理口。

5.4 时间同步:NTP 不生效的常见原因

存储一体机的日志时间不对会直接影响故障排查。CX5000G G3 管理台上配置 NTP 服务器地址很简单,但经常配完不生效,现象:管理台显示时间与 NTP 服务器偏差越来越大,或者是完全不更新。原因多半是管理网段和 NTP 服务器不通。

S1850 交换机接入层常出这个问题:存储管理口在 VLAN 10,NTP 服务器在 VLAN 100,三层路由没有配通。解决:先在交换机上执行ping测试管理口到 NTP 服务器的连通性,再确认存储控制器的管理网口 gateway 配置正确。时间偏差超过阈值时,手动先把时间改到接近真实值,再开启 NTP 同步。跨度很大的情况下,NTP 的步进调整逻辑可能导致同步失败,手动拉近距离后重启 NTP 服务即可。

6. 上线前的性能验证:用 fio 和存储自带工具确认状态

新存储上线不能不测就交付。我习惯用 fio 做基准,先把存储的真实能力摸清,再按业务模型决定要不要加缓存或调整 RAID 策略。

# fio 随机读测试,模拟数据库日志场景,队列深度 32,块大小 8K fio --name=randread --ioengine=libaio --iodepth=32 --rw=randread \ --bs=8k --size=20G --numjobs=4 --group_reporting \ --filename=/dev/mapper/mpatha --direct=1

跑测试前确认--filename指向的是多路径设备而不是裸盘。裸盘路径跑出来的结果只经过单条链路,无法反映真实承载能力。--direct=1绕过操作系统缓存,这对存储评估是必要的——不做这个绕过,测出来的数字写的是内存缓存速度,不是存储速度,等于白测。

跑完性能测试,再进存储管理台看控制器 CPU 和缓存命中率。CX5000G G3 的监控页面能直接看两个控制器的资源占用。如果某个控制器 CPU 长期超过 70%,检查有没有把耗时操作都打在同一台控制器的卷上,LUN 映射到两台控制器的卷应该尽量均衡。存储控制器 CPU 和 vCPU 不是一个概念,控制器 CPU 超了就是纯硬件瓶颈,别用虚拟化平台的 CPU 超分配思路去解。

最后一步是验证告警通道。改一个池容量阈值到 1%,让它触发告警,确认邮件或 SNMP 能收到。这套流程跑完之后,存储的交付才算真正落地。从那以后,我每次给新的 CX5000G G3 做上线,都强制把 fio、控制器监控、告警通道走完一遍才签字。希望帮到你。

本文还有配套的精品资源,点击获取

需要专业的网站建设服务?

联系我们获取免费的网站建设咨询和方案报价,让我们帮助您实现业务目标

立即咨询