企业官网建设流程全解析

简介：面向负责分布式存储部署与运维的工程师，这份PDF指南系统讲解了华为FusionStorage软件从安装准备到组件上线的完整流程。资源为单份PDF文档，大小仅2.98MB，适合作为现场操作手册随时查阅；目前已有380人浏览学习。文档由华为技术有限公司发布，对应FusionStorage V100R003C30版本，发布日期为2016年1月；内容按FusionSphere服务器虚拟化场景组织，先给出安装流程总览，再分章节介绍安装准备、系统要求、FSM组件安装配置、FSA组件部署（包括存储节点安装、元数据分区挂载、IB网络配置、FusionStorage参数配置）以及将存储资源接入虚拟化环境等操作。指南覆盖了FusionStorage两大核心组件从安装到配置的完整细节，也列出了可选的存储节点与网络配置步骤，便于用户根据实际环境灵活选用。通过学习可掌握分布式存储集群的部署逻辑、组件依赖关系与关键配置要点，为项目交付、扩容实施或故障排查提供切实参考。

1. 别把FusionStorage软件安装指南当成“点下一步”的文档：先弄懂三件事

拿了一份《FusionStorage软件安装指南.pdf》，不等于安装就有底了。真正做交付时，它更像一张城市地图，标注了路名和地标，哪条路正在修要靠现场判断。FusionStorage是华为的分布式存储软件，典型用途是把一堆X86服务器的本地盘通过网络聚合成统一存储池，替代传统集中式SAN。扩容时买服务器就行，坏处是安装链路长、前置条件多。这份软件安装指南适合三类人：私有云交付工程师、存储运维、虚拟化集成商。动手前先弄懂三件事：组网平面怎么分、许可证容量怎么规划、存储池和故障域什么关系。这三件事里任何一件出错，排错时间都会超过安装本身。

2. 安装前的组网与版本规划：软件安装指南里最容易跳过的部分，决定后面能否上线

FusionStorage集群的安装失败，一半以上发生在上架之前。这不是耸人听闻——软件安装指南里最靠前的部分往往是组网规划和版本配套，字少、没有截图，很多工程师瞄一眼就翻过去了。等到创建存储池时连不上节点，再回头补课，代价翻倍。这一章把安装前最容易被跳过的三件事讲透。

2.1 控制流与数据流分离：两种网络平面怎么划分更安全

FusionStorage把流量分成管理面、控制面和数据面三类。管理面负责GUI和CLI操作，控制面负责存储策略下发，数据面承载实际的副本复制和业务IO。数据面一旦抖动，影响的是所有副本同步，不是单个命令慢不慢的问题。软件安装指南会要求控制面和数据面在物理或逻辑上隔离，常见的做法有两种：用两套交换机完全隔离，或者在同一套交换机上划不同VLAN并做端口隔离。

实际项目中我一般建议客户优先做物理隔离，至少数据面要独享万兆或25GE端口。如果预算有限必须共用一套交换机，就在交换机上为数据面单独划VLAN并开启端口隔离，不要把管理VLAN和数据VLAN混在同一个非聚合口下。另一个常被忽略的细节是端口协商：数据面端口强制自适应可能自动降速到千兆，FusionStorage节点间带宽不足时，表面看状态都正常，实际写入性能只有预期的一半。安装前逐台检查交换机端口速率和双工模式，能省掉后面的大量排查时间。

MTU不一致是隐藏得最深的坑。管理面走1500字节没问题，数据面却要求9000字节大包。操作时先在交换机端口上统一MTU 9000，再到服务器网卡配置里也设置成9000。这里要提醒一句：指南会写“建议MTU 9000”，但往往不会强调两端必须一致；不少交付项目就漏了这个一致性检查，导致节点一上线就闪断。第4章会给出具体验证命令。

2.2 版本与许可证规划：先核对安装包配套，再谈容量

拿到软件安装指南PDF之后，第一件事不是往下翻操作步骤，而是看安装包文件名和版本号。FusionStorage的安装包通常与FusionCompute或ManageOne配套发布，版本号包含大版本和补丁编号，混用组件版本是最常见的安装失败原因。安装前的核对顺序推荐这样：先校验安装包的SHA256或数字签名，再登记当前环境里所有已有组件的版本号，最后对比配套关系表，确认没有需要升级的中间组件。跳过任何一步，安装向导都有可能到最后一刻才报组件不兼容，白白浪费几个小时。

许可证要分清裸容量和可用容量。3副本策略下，可用容量只有裸容量的三分之一；如果许可证按裸容量审批，容量规划就得先做完副本系数换算再提交申请。填写ESN时一个字母都不能错，ESN与服务器硬件信息绑定，错了校验必定失败。评估版通常有使用期限，生产环境不要依赖评估版，到期后存储服务会停止创建新卷，影响比想象中更大。

许可证校验还依赖节点系统时间。分布式存储的证书认证通常内嵌时间戳，节点间时区不统一或偏差超过阈值，证书校验会静默失败。建议在安装系统时就配置好chrony或NTP，让每个节点指向同一个时间源。装完系统第一件事用date -R检查时区，别等到存储服务起不来再回头看。

2.3 硬件资源清单：把节点角色映射到实际服务器

FusionStorage集群从功能上一般分三类角色：MDC节点负责管理和控制面，OSD/存储节点提供数据盘容量，客户端节点可选、只发起IO不参与存储复制。小规模集群可以把MDC角色部署在存储节点上，规模上来后建议独立部署。软件安装指南的硬件要求表会写CPU、内存和磁盘推荐值，动手前把它整理成一张检查表逐项核对。

BIOS设置同样关键。系统盘可以组RAID1保证启动稳定，但数据盘必须设为HBA直通或JBOD模式，让操作系统看到每块独立盘。不少项目翻车就翻在这里：运维默认把数据盘也做了RAID5，FusionStorage装完只能识别到一块虚拟盘，真实容量少了一大半。装系统前用lsblk核对一遍盘符，再清理数据盘上可能残留的分区表。

# 检查所有磁盘当前状态（以CentOS系为例） lsblk -o NAME,SIZE,TYPE,MODEL # 清理数据盘上可能残留的分区表（谨慎执行，先核对盘符） for disk in /dev/sdb /dev/sdc; do sgdisk --zap-all "$disk" done

逻辑说明：lsblk -o指定输出列，便于把每块盘和规划表逐块对照；sgdisk --zap-all只清理分区表标记，不会擦除盘上已有文件系统数据，但能避免FusionStorage创建数据盘时因为识别到旧分区而跳过该盘。参数说明：/dev/sdb、/dev/sdc换成现场实际盘符，不要照抄；数据盘如果之前做过LVM，还需要执行pvremove或至少确认VG元数据已被清掉，否则安装工具依然可能报“磁盘忙”。

3. 从软件安装指南到实际部署：FusionStorage的安装执行路径与关键参数

软件安装指南的主体内容通常按三个阶段展开：部署管理面、添加存储节点、创建存储池。每一阶段都有前置条件和校验动作，不能跳步。这里按最常见的交付路径拆开讲，并把每个阶段里影响后续运行的参数单独拎出来。

3.1 安装入口：先部署管理面，再接存储节点

FusionStorage安装一般分三步：部署管理平台、添加存储节点、创建存储池。管理平台可以独立部署，也可以和MDC角色合设。安装工具会引导你输入节点IP、子网掩码、网关、VLAN ID和SSH登录凭据，然后自动执行预检查。预检查报告有红叉时不要硬过，挨个看失败项，多半是SSH互信或网络连通问题。

以集群引导阶段为例，安装包会先把管理面变成可用状态，再通过CLI或GUI添加节点。下面这段脚本模拟预检查里最常见的两个动作：网络可达和SSH端口探活，便于你理解这个过程。

#!/bin/bash # 节点互信与连通性预检：逐个检查管理IP的ping和SSH端口 NODE_LIST="192.168.10.11 192.168.10.12 192.168.10.13" for ip in $NODE_LIST; do ping -c 3 -W 2 "$ip" >/dev/null 2>&1 \ && echo "节点 $ip 网络可达" || echo "节点 $ip 不可达" timeout 3 bash -c "echo >/dev/tcp/$ip/22" 2>/dev/null \ && echo "节点 $ip SSH端口正常" || echo "节点 $ip SSH端口不通" done

逻辑说明：这个脚本对应安装向导预检查的第一阶段，验证所有节点能被管理面访问。SSH端口不通时，添加节点必定失败，需要先解决防火墙、sshd服务和网络策略的问题，不要反复重试安装任务。参数说明：NODE_LIST替换成实际规划的管理IP；-c 3指定三次探测；/dev/tcp/22是Linux自带的TCP探活写法，等价于扫描端口22。

管理面部署完成并添加节点后，验证不能只看GUI上的“正常”图标。我习惯再ssh到每个存储节点，用uptime看负载、用df -h看系统盘使用率，确认没有异常进程把系统资源占满。软件安装指南在这个阶段也会给一条“检查集群健康状态”的命令，各版本有差异，以你手头PDF的附录为准。

3.2 存储池与故障域：参数填错比装错更难受

创建存储池是整个安装过程的分水岭，界面里要填池名、硬盘类型、冗余策略和故障域。硬盘类型按物理盘选择：SSD池放热数据，HDD池放温冷数据，混插会让慢盘拖累整个池的性能。冗余策略在分布式存储里叫副本数，常见的是2副本和3副本。2副本节省容量，但坏一块盘后要尽快完成数据重建；3副本能扛单节点断电，适合数据库和核心业务。

故障域是FusionStorage里最值得花时间理解的概念。副本不只散落在不同磁盘上，还要落在不同“域”里。一个故障域通常映射到一台物理服务器或一个机柜。如果在存储池里把故障域设成无，两个副本可能落到同一台服务器的两块盘上，那台服务器断电时，所有数据一起丢。实际项目里最稳妥的起点是：以服务器为最小故障域，生产池从3副本开始，等容量吃紧再评估能否降到2副本。

写缓存策略也要提前想好。节点上有SSD作为缓存盘时，安装界面通常会让你选写缓存模式。写缓存开太大，掉电时可能丢数据；开太小，写性能起不来。常见做法是缓存容量约占数据容量的5%到10%，并且核心业务卷关闭延迟写缓存。卷级别如果还能再调，优先保证数据库卷的持久化语义。

3.3 卷与主机映射：让计算节点真正用上存储

存储池建好后，上层业务要看到存储，得先建卷，再把卷映射给主机。通常流程是：在存储管理面创建卷，设置卷大小和所属存储池，再创建主机或主机组，最后把卷映射到主机。映射方式常见为iSCSI，计算节点上需要装open-iscsi和multipath-tools。给一个Linux计算节点上做iSCSI发现和登录的常规操作：

# 配置iSCSI发起端（以Linux为例） iscsiadm -m discovery -t sendtargets -p 192.168.20.1:3260 iscsiadm -m node -T iqn.2024-08.example:fspool -p 192.168.20.1:3260 --login # 检查多路径聚合结果 multipath -ll

逻辑说明：发现存储目标并登录后，系统会产生多个/dev/sdX路径，multipath -ll用来确认这些路径被聚合成一个dm设备。看到active/active表示路径正常；看到一条active一条failed，优先查交换机和网卡聚合配置。参数说明：-p后面是存储侧配置的iSCSI门户地址和端口；iqn名字来自存储侧创建主机时生成的initiator名称，不能写错；CHAP认证的用户名密码必须两边一致，否则登录时直接报auth failed。

映射完成后不要急着交业务。先在上层计算节点跑一遍mount和fstrim验证，确认卷能正常读写，再格式化文件系统。虚拟化场景下，磁盘类型建议选thin provisioning的稀疏卷，便于回收闲置容量；数据库场景反而建议用普通卷，避免空间超卖后文件系统写满导致故障。

4. 避坑指南：FusionStorage集群装不起来时的五个排查方向

安装FusionStorage时，很多问题看起来是软件故障，根子却在网络、时间、磁盘模式这些基础环境上。这里整理五条高频踩坑记录，一条对应一类现象，按“现象、原因、解决”展开。

4.1 现象：存储节点安装后反复闪断，状态在“在线”和“离线”间来回跳

原因：数据面网络不通或丢包导致节点心跳超时。很多情况不是网线问题，而是MTU和VLAN配置不一致，导致大包在链路上被丢弃。

解决：先看交换机端口统计，CRC错包多说明物理层有问题；再ping大包验证数据面MTU：

# 在管理节点对存储数据面IP执行带DF标志的MTU测试 ping -M do -s 8972 192.168.30.1

逻辑说明：-M do禁止路径分片，-s 8972是ICMP payload大小，加上28字节IP/ICMP头正好9000字节。提示fragmentation needed时，说明路径上有接口MTU小于9000，去交换机上把对应端口改为MTU 9000并在服务器网卡侧同步修改。参数说明：192.168.30.1替换成对端存储节点的数据面IP；如果集群用双交换机，两台交换机上都要检查。

4.2 现象：创建存储池时容量总比预期少，逻辑容量差了一大截

原因：数据盘被识别成“系统盘”，或RAID控制器以虚拟磁盘方式占用了一块物理盘。安装工具只能看到直通盘，看不到RAID卡组出来的VD，所以实际容量对不上。

解决：进BIOS确认磁盘控制器是HBA直通或JBOD模式，然后在RAID控制器配置里删除已有VD，把磁盘设置为non-RAID。操作完成后回系统重新执行lsblk，确认每块物理盘都出现了独立盘符。清残留分区表时用第2章的sgdisk命令，顺序是“先改BIOS模式，再清分区，最后重复刷新节点”。

4.3 现象：存储进程起不来，服务一直显示启动失败

原因：许可证校验失败，或节点间系统时间偏差超过阈值。安装工具有时不会在前台明确报“时间不对”，只在后台日志里留下时间戳异常记录。

解决：先在所有节点执行date -R看时间和时区，不一致就配置chrony或NTP同步。时间正常后看许可证状态，确认授权容量、节点数与实际环境匹配。以下命令适合在服务启动前强制校准时间：

# 查看当前时间与时区 date -R # 立即校准系统时间到NTP源 chronyc makestep

逻辑说明：date -R输出带时区，时区乱套会导致其它节点认为证书内嵌时间无效；chronyc makestep用于时间偏差小于阈值的条件下强制步进，适合服务启动前快速对齐。参数说明：如果chronyc报错，检查/etc/chrony.conf里的server配置是否指向可达的时间源。时间对齐后仍起不来，去管理面查证书序列号和容量匹配关系，不要盲目重启整个服务。

4.4 现象：iSCSI挂载后，计算节点上IO报错或路径全部变成failed

原因：存储侧配置了多个门户地址，但计算节点只登录了其中一个；或交换机做了端口聚合但计算节点侧没配bond；也可能CHAP认证信息不一致导致部分路径被拒绝。

解决：把存储侧所有iSCSI目标地址重新discovery一次，确认每条路径都登录成功。计算节点上把multipath.conf里的path_checker设为tur，然后执行multipath -ll确认所有路径状态。检查CHAP时，注意复制存储侧生成的用户名密码时别带入多余空格，这在Web界面复制场景里特别常见。

4.5 现象：升级包导不进去，安装向导执行到一半回滚

原因：升级包版本比当前环境旧，或环境里残留了上一次安装的部分组件元数据，导致版本序号被误判。

解决：不要直接重装升级包。先停止存储服务，再清理旧的安装目录，但千万别格式化有数据的MDC节点。先从管理面导出配置备份，再解压升级包做版本兼容性检查，确认版本号前缀一致后重新导入。这里的关键动作是“先备份、再清理、后导入”，顺序不能反，否则要重新走一遍许可证申请。

5. 安装文档没有交代的边界：性能验证与磁盘运维的先后顺序

软件安装指南能帮你把集群装起来，但装起来之后怎么证明它合格、坏盘了怎么处理、升级失败怎么收场，这些边界条件往往分散在其它文档甚至只在现场经验里。这一章补上这三块。

5.1 性能验证：从fio到真实业务的完整步骤

FusionStorage装完只是开始，要让业务部门接受这个存储，得在割接前给出一份可复现的性能报告。用fio打底层是常见做法，但参数设不对时测试结果会被缓存掩盖。先跑一个4K随机写：

# 4K随机写测试，direct模式绕过操作系统缓存，跑60秒取稳态 fio --name=randwrite4k \ --ioengine=libaio --direct=1 --bs=4k --rw=randwrite \ --size=20G --directory=/mnt/fspool --numjobs=16 \ --iodepth=64 --group_reporting --time_based --runtime=60s

逻辑说明：--direct=1让写操作绕过操作系统页缓存，直接落到底层块设备，避免FusionStorage卷的性能被本地缓存美化；--time_based配合--runtime=60s保证跑满60秒而不是写到20G就结束。参数说明：--numjobs=16和--iodepth=64组合产生的并发队列是1024，这个深度适合验证分布式存储在处理大量并发IO时的表现；业务侧如果是数据库，建议把bs改成8k或16k再看一组数据。测试报告里重点记录IOPS和时延P99两个值，P99超过5毫秒时先看客户端网卡和交换机有没有成为瓶颈，再看存储节点CPU软中断占比。注意：fio测出的底层性能不代表数据库性能，割接前最好再用业务备机做一次全量数据拷贝验证。

5.2 磁盘运维红线：扩容、缩容、坏盘处理的先后顺序

集群上线后，坏盘处理顺序是高压线。正确操作是先登录管理面把故障盘置为离线或维护状态，等集群触发的副本重建至少完成一个副本，再物理拔出旧盘。顺序反了，可能看到的是副本重建全部卡住，存储池长时间处于降级状态。扩容同理：先把新节点的网络接好并加进管理面，让向导做预检，不要在预检还没结束前就把数据盘插满。有些现场图省事，先插盘再上架，结果控制器模式不对，还得重新抽盘。

缩容比扩容更敏感。生产集群里直接关掉一个节点来省电是非常危险的操作，缩容前要把该节点上的数据全部迁移出去，确认剩余副本数和故障域都满足要求后，再从管理面执行减少节点流程。整个缩容期间不要同时进行坏盘更换，两个运维动作叠加会让故障域内的副本数瞬间不足，极端情况下会触发数据丢失风险。

5.3 版本升级与回退：安装指南里的风险说明别只看前半页

升级前先到管理面做一次完整配置备份，记录当前版本的工作目录和数据库文件位置。升级顺序通常是先MDC节点、再存储节点、最后客户端。跨大版本升级通常不支持直接回退，所以升级前要留好旧版本安装介质和配置备份。如果升级后某个节点的存储服务反复重启，不要急着回退整个集群，先确认是不是只有该节点缺少新版本要求的固件或内核模块。回退操作只在故障面超过一个存储池时考虑，且回退前必须停止业务IO。软件安装指南里“升级过程不可中断”的意思是网络和电源不能断，不是让你在业务高峰硬扛，时间窗口要提前和业务方对齐。

6. 装完FusionStorage后，我养成的三个验证习惯

第一次独立交付FusionStorage时，我按软件安装指南一步步操作，界面全绿，以为大功告成。结果第二天早上业务方反馈卷映射全部丢失，排了半天发现是某个内核模块每次重启后不会自动加载。从那以后，我给自己定了三条规矩。

第一条，装完不看GUI的绿勾，只信命令行自检。界面状态是管理面上报的心跳，不代表数据面真的可用。我会逐台ssh到存储节点，查负载、查socket连接数、查数据面网卡有没有丢包统计，把结果留档。

# 集群安装完成后的快速自检：远程逐台检查负载与内存 for ip in 192.168.10.11 192.168.10.12 192.168.10.13; do ssh "$ip" "hostname; uptime; free -m | awk '/Mem/{print \$3\"/\"\$2\"MB\"}'" done

逻辑说明：这条命令把三个节点的主机名、负载、内存占用一次性拉出来，重点看uptime输出里的load average是否持续走高。参数说明：ssh双引号里的$3和$2必须转义，否则会在本地被shell先展开，传到远端时就变成空值；IP列表换成实际管理的地址。

第二条，凡是指南里画了三角符号的注意项，全部转成脚本里的显式检查。比如MTU一致性、时间偏差、CHAP密码里的空格，这些看一遍就忘的细节，写成脚本每次装完跑一遍，比人眼可靠。第三条，报错时先查日志，再改配置。FusionStorage的管理面日志会记录每个任务的执行链路，很多问题在日志里已经有明确提示，只是没显示在弹窗里。养成“先看日志再动手”的习惯后，我几乎没有再因为误操作把集群搞到不可恢复。

这些习惯未必能让你一次装成功，但能让你在出问题时少熬夜。希望帮到你。

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