企业官网建设流程全解析

简介：《华为FusionStorage系统管理指南》是一本面向存储管理员与系统运维人员的华为分布式存储解决方案操作手册，重点解决FusionStorage中存储池与块客户端的日常管理问题。压缩包内仅含1个PDF文件，约1.32MB，便于离线查阅，内容基于V100R003C30版本整理。已有194人学习使用。手册从存储池扩容、减容到删除，再到块客户端的创建与删除均给出详细步骤，同时覆盖卷管理、映射管理等关键模块，并强调数据备份与谨慎操作原则。读者可据此掌握资源管理核心流程，提升数据中心存储资源的运维效率，也可作为华为存储认证或项目交付的参考材料。

1. 华为FusionStorage系统管理指南为什么绕不开

把《华为FusionStorage系统管理指南.pdf》下载下来是一回事，真正把它读透是另一回事。FusionStorage 是华为基于通用服务器构建的分布式块存储，最小三节点就能跑，往上可以扩展到几十上百个节点。它和传统磁盘阵列的运维习惯差别很大：磁盘分散在多个服务器里，管理平面自己也跑在这个集群上，所以「登进管理页面看一下状态」这个动作背后，还压着网络、角色、仲裁机制三层上下文。这份系统管理指南解决的就是这类问题——业务侧报 IO 超时、某块盘亮了红灯、存储池容量逼近水位线时，运维人员应该去哪里看、按什么顺序排查、哪些操作能点哪些不能点。如果你负责 FusionStorage 集群日常运维，或者正在为私有云底座做存储交付，这份文档基本就是操作底线。

2. 先理解管理模型：集群谁在管，数据怎么走

2.1 MDC、VBS、OSD 三种角色的边界

FusionStorage 是典型的分层分布式架构，系统管理指南里所有页面和命令，本质上都在跟三个角色打交道。

MDC 更像整个集群的「大脑」，客户端创建卷、删除卷、扩容量，最终都要由 MDC 更新元数据并下发到相关 OSD。VBS 是数据通路上的关键，它跑在计算节点侧，把上层下发的块级 IO 转换成对象级操作；OSD 则是物理硬盘的逻辑抽象，一个 OSD 对应一块盘，磁盘组又把这些 OSD 组织成一个个故障域。

这三者的关系可以用一条 IO 链路串起来：业务服务器上的客户端 -> VBS -> OSD -> 物理磁盘。管理操作则走另一条路：管理页面/命令行 -> MDC -> 各节点 Agent -> 更新配置。理解这条链路后，排障时你才知道「页面看到的告警」和「业务实际感受到的抖动」之间隔了几层。很多时候业务 IO 正常，管理页面却提示节点离线，那是因为管理面和数据面各自走不同的网络，谁先断、谁后断，表现完全不一样。

2.2 管理网、存储网、业务网各自该放什么流量

FusionStorage 的组网在指南里通常是三张网分离：

• 管理网：承载 MDC、Agent、仲裁通信，端口少、流量小，但要求稳定，一般用千兆独立 VLAN。
• 存储网：承载 VBS 与 OSD 之间的数据同步，流量最大，要求低延迟，通常用双口 10GE 绑定。
• 业务网：承载客户端到 VBS 的访问，取决于上层业务模型。

实际交付中，我一般建议管理网单独走一台华为三层交换机上的独立 VLAN，ACL 只放行运维网段；存储网做双 10GE bond，MTU 统一调大，比如 9000。这里有一个经常被忽略的坑：所有交换机端口和服务器网卡的 MTU 必须一致，只要有一跳链路还是默认 1500，IPSAN 这类大包就会走分片，性能直接腰斩。系统管理指南里对组网有一段要求，核心意思也是「管理、存储、业务三层流量不要混跑」，因为存储网络上的突发流量会挤掉管理心跳，触发误报。

2.3 管理组件通常住在哪，虚拟 IP 是什么

MDC 不是一台独立服务器，而是部署在某几个存储节点上的管理进程。为了让运维入口固定，FusionStorage 会为管理组件分配一个虚拟 IP（VIP）。日常你知道一个固定地址能打开管理页面，就是因为有这层 VIP 机制：主管理节点宕机后，VIP 会漂移到备节点，页面访问不中断。

登录管理页面后，看到的第一个页面一般是集群概览，包含集群健康状态、节点列表、存储池容量、告警事件。这里我建议大家养成一个习惯：第一次拿到集群就把「节点名、管理 IP、角色、所在机架」整理成一张资产表，后续所有告警排查都基于这张表来定位。系统管理指南里能查到查看节点详情的路径，但它不会替你做资产梳理，这张表是你自己的运维底座。

3. 服务配置：把存储池和卷按指南建起来

3.1 建集群前的硬件准备：从 SmartKit 到 RAID 两模式

创建存储池之前，硬件层面的准备决定了后面会不会返工。常见做法是用华为 SmartKit 做一轮硬件检查和固件升级，重点看硬盘固件、网卡固件、RAID 卡驱动是否在 FusionStorage 兼容列表里。特别是 RAID 卡，如果还在 RAID 模式，需要先把控制器改成直通（Pass-Through）模式，让操作系统直接看到物理盘。做这一步时，AVAGO 等品牌的阵列卡驱动版本很关键，驱动和 FusionStorage 内核模块不匹配，后面磁盘识别会异常。

直通模式设置完，建议把每台服务器的磁盘槽位顺序记录到资产表里，因为 FusionStorage 磁盘组是按物理盘粒度管理的，换盘时你必须知道「sdb 对应第几个槽位」。这一步看似琐碎，但它决定了以后换盘的人敢不敢下手。指导手册通常默认运维人员已经完成这个层级的准备，实际你会发现很多集群交付后不稳定，根子就出在 RAID 卡模式没改干净，或者直通后仍有部分盘被 RAID 卡占用。

3.2 存储池与故障域参数

创建存储池是 FusionStorage 管理里最核心的一次配置，因为存储池一旦建成，冗余策略和故障域级别在大多数场景下无法原地修改。界面上的几个关键参数：

故障域选「节点」时，三副本的三个分片会放在三台不同服务器上，任意一台宕机数据不丢；选「机架」时，分片会跨机架放置，能扛住整个机架掉电，但对集群规模有要求，机架数少于副本数时无法创建。纠删码策略一般用在容量敏感的大数据场景，常见的 4+2、6+3 配比，实际可用容量大约是 N/(N+M)。

容量规划时，副本模式最简单：物理可用容量 = 总裸容量 ÷ 副本数，再打一个 0.85 左右的余量系数。比如 12 块 10TB 盘，RAID 直通，三副本，那这个存储池的实际可用容量约等于 12 × 10 × 0.85 ÷ 3 = 34TB。这个估算方法和系统管理指南里的容量计算公式是对得上的，只是生产上还要把快照预留、扩容余量算进去，建议初始建池只规划到总物理容量的 70% 左右，留出重建和快照的buffer。

3.3 创建卷与映射建组：四个直接影响业务的参数

存储池建好后，创建卷反而是相对简单的一步，但简单不等于可以随意填。首先，卷容量单位要统一，界面上一般以 GB 为单位，规划时用 TB 做除法容易出错，尤其是给数据库这类固定容量业务分配时，多给 10% 或少给 10% 后期都要扩容处理。推荐使用精简配置（Thin Provisioning）应对未来容量不确定的虚拟机场景，但创建时务必设置容量上限，否则会出现单卷无限占用存储池空间。

其次是映射，FusionStorage 支持将卷映射给计算节点，映射关系由「卷 + 客户端 + 启动器」三元组定义。管理指南里这一节讲的命名组（Group）概念很关键——把同类型客户端的启动器放在一个组里，统一赋予卷访问权限。实际运维中我最常遇到的问题是：业务新增一台服务器后，管理员只添加了启动器，忘了加入组，导致卷能看到但 IO 起不来。

创建卷时还有两个容易被忽略的业务参数：LUN 类型和快照策略。LUN 类型影响客户端对卷的识别方式，选错可能导致操作系统里盘符正常但分区工具报错；快照策略如果直接套用默认策略，可能每小时打一个快照，瞬间把存储池空间吃出一大块。我的经验是，生产卷先创建无策略副本卷，稳定跑一周后再根据备份需求单独加快照策略，不要一上来就全家桶。

4. 日常读系统状态：页面、命令行、告警三条腿走路

4.1 Web 管理页面重点看哪几个字段

FusionStorage 管理页面的信息密度很高，但日常工作不需要全看。我一般打开页面后按三个区域扫一眼：顶部集群健康状态、中间存储池容量条、左侧告警事件列表。健康状态出现黄色或红色时，优先看事件详情而不是猜测；存储池容量条看的是已用比例和剩余天数趋势，不是瞬时值。

容量趋势这里有一个指南里容易被忽略的概念：可用容量和已用容量之间还隔着一个「预留容量」。快照、远程复制、临时扩容都会消耗预留容量，页面主容量条往往不显示这部分。所以当容量条还剩 20%，系统却提示存储池空间不足时，不要惊讶，先去查快照空间占用。

4.2 用业务侧命令验证卷是否真的可用

管理页面看到的一切始终是间接反馈，最直接的验证是从业务服务器上发起一次 IO。给刚映射的卷做冒烟测试，我的做法是这样的：

# 查看卷是否已经被操作系统识别 lsblk /dev/sdX # 带直通方式做一次 30 秒的只读压力测试，避免写坏测试卷 fio --filename=/dev/sdX --rw=read --bs=64k --size=2G --numjobs=1 \ --name=smoke_test --time_based --runtime=30 --direct=1

lsblk 看的是磁盘是否存在，这一步能发现映射层面的问题；fio 只读跑 30 秒，能验证数据通路是否通畅。参数里direct=1表示绕过文件系统缓存，直接走块设备层，确保压测流量真实经过 VBS 到 OSD 的完整链路。如果 fio 报错或延迟异常，再看管理页面上该卷对应的性能监控曲线，能快速区分是存储侧问题还是业务侧问题。

4.3 告警阈值建议：别等到硬盘快响才知道

系统管理指南里对告警配置有推荐阈值，但出厂默认值偏保守，适合初始上线，不适合长期运行。我习惯按三层来设：

邮件和 SNMP 陷阱同步配置，告警发送目标写运维值班邮箱。这里有个细节：管理页面的告警邮件依赖管理网的 SMTP 可达性，很多集群收不到告警是因为防火墙只放行了业务流量，管理网到邮件服务器不通。这类问题排查起来并不难，但确实属于「不踩一次想不到」的类型。

5. 系统管理避坑指南：这五类操作翻车记录

5.1 管理页面打不开，但业务一切正常

现象：浏览器访问管理页面超时，业务服务器上的 IO 却完全正常。

原因：管理平面的 VIP 与业务数据面走不同网络路径，业务 IO 正常说明存储集群本身健康，问题大概率出在管理网链路、VIP 所在节点故障、或者管理进程异常退出。常见诱因是上层交换机变更时，运维只调整了业务网段路由，管理网 VLAN 的互联地址被误删。

解决：先 SSH 登录管理节点，查看管理进程是否存活；再 ping VIP 确认二层可达；最后检查交换机上管理 VLAN 的配置。如果 VIP 所在节点宕机，等待 VIP 漂移或手动触发主备切换。这个现象本身不可怕，可怕的是运维误以为集群故障，直接重启存储节点，把一个小问题放大成大故障。

5.2 换盘后容量不回升

现象：物理上替换了故障盘，管理页面存储池容量仍旧少一块盘，新盘一直处于未加入状态。

原因：换盘前没有在管理界面上把那块盘对应的 OSD 标记为故障并移除，新盘插入后系统无法自动识别它属于哪个磁盘组。

解决：正确顺序是先在管理界面找到故障 OSD -> 执行移除操作 -> 等数据在其他副本上重建完成 -> 再物理拔盘 -> 插入新盘并扫描，新 OSD 会自动加入原磁盘组。如果已经插了新盘还没做移除，就需要先人工把旧 OSD 从磁盘组解绑，再对新盘执行加入磁盘组的操作。这块操作路径各版本菜单位置略有不同，但核心动作一致：先软件移除，再硬件更换。

5.3 把「停止服务」当「下电」用

现象：维护窗口期为了更换内存条，直接在存储节点上执行了系统关机，结果集群出现大面积告警，多个卷短暂中断。

原因：FusionStorage 的分布式机制允许单节点故障，但「正常停止服务」和「异常宕机」在集群看来是两回事。如果通过管理界面执行停止节点服务，集群会提前把该节点上的主副本角色切换走；而直接下电，某些卷的主副本来不及切换，客户端 IO 会等待仲裁超时。

解决：所有涉及节点下电的操作，统一走管理界面的节点维护入口，而不是在操作系统层直接 shutdown。如果必须直接关机，提前把该节点上的 VBS 和主 OSD 角色全部手动迁移到其他节点，再执行关机。这个差别在指南里放在「节点维护」一节，属于白纸黑字写了但很容易被忽略的内容。

5.4 快照和 LUN 复制悄悄把存储池写满

现象：存储池容量没有大文件写入，但已用空间每周增长几个百分点，持续一个月后告警。

原因：快照策略配置不当，系统按小时打快照，而每个快照块写入都需要额外空间；LUN 复制也一样，如果复制目标放在同一存储池，源卷数据量越大，预留空间被吃光的速度越快。

解决：打开快照空间统计页面，按快照名称排序，找占用最大的几个策略。生产环境建议快照数量控制在每卷 8 个以内，保留周期不超过 7 天；LUN 复制目标卷尽量放到另一个存储池。更重要的是，把「快照预留空间」纳入容量监控，单独设一个 90% 告警阈值，不要等存储池总容量告警才发现问题。

5.5 加节点时心跳网络误报

现象：向已有集群添加新节点后，集群健康状态出现黄色，提示管理节点心跳超时。

原因：新节点加入集群时，会一次性上报大量磁盘和心跳信息，如果管理网带宽有限或者交换机端口处于半双工状态，管理节点处理不过来，就会产生误报。

解决：新节点加入前，先在交换机上确认管理网端口速率为自适应且工作在全双工；加入操作尽量安排在业务低峰期；加入完成后观察 15 分钟，确认集群状态稳定再继续加下一台。另一个实用习惯是：加节点前先看当前集群的管理节点 CPU 和内存占用，如果已经接近 70%，优先扩容管理节点资源，再加存储节点。

6. 验证一套集群的管理基线：三份记录单

长期运维 FusionStorage，最值得养成的习惯是维护三份记录单。第一份是集群基线表，记录每个节点的角色、磁盘数量、固件版本、管理 IP，每次变更后更新一次；第二份是容量趋势表，每周记录存储池已用容量、快照空间、节点 IO 延迟，连续记录一个月后，你就能看到容量的真实消耗速度，而不是等 85% 告警来了才慌张；第三份是变更操作单，记录每次维护操作的步骤、耗时、结果，包括「通过什么菜单做的、有没有先切换主副本」。

验证集群配置是否健康，我每个季度会做一次演练：挑业务低峰期，在管理界面手动下线一个存储节点，观察卷是否在 30 秒内完成主副本切换；重新上线后确认数据重建进度。这个动作不需要真的拔盘，但能提前暴露仲裁配置、副本放置策略里的隐藏问题。演练前先比对系统管理指南里关于节点维护的条款，确认当前版本支持在线维护，再执行操作。三次演练累计下来，你会比我更清楚这套集群在极端情况下的真实表现。

我第一次接手 FusionStorage 集群时，吃过不读文档的亏——直接关了一台节点换内存，结果业务侧出现分钟级 IO 中断。后来把系统管理指南里「节点维护」和「磁盘更换」两章翻熟，才养成了先操作软件再碰硬件的习惯。这份管理指南不是用来收藏的 PDF，它是每次变更前应该翻一遍的检查清单。希望这套方法能帮你少踩几个坑；但也记住，任何指南都覆盖不了现场所有意外，带着基线数据去排查，总比空手猜测强。希望帮到你。

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