深信服超融合HCI部署实战：从裸机到业务上线的完整指南

简介：深信服超融合HCI用户及部署手册面向技术服务工程师与运维人员，聚焦超融合基础设施的架构认知与落地实施。内容涵盖产品说明、安装部署、网络配置、系统部署及应用等模块，可帮助读者理解HCI标准集群组网、aSV、aSAN、aNET等关键特性，并掌握从规划到上线的完整流程。资源包为1个PDF文件，大小约35.42MB，文档结构清晰，包含产品架构、关键特性、安装组网介绍、配置要求与常见问题排查等章节，便于按需检索与系统学习。目前已有1245人学习下载，适合正在接触或计划部署深信服超融合的工程师作为案头参考，也可用于日常运维与故障排查时快速定位知识点。

1. 深信服超融合HCI 用户及部署手册：从裸机到业务上线的完整路径

很多团队第一次接触深信服超融合HCI，卡住的地方往往不是功能本身，而是「三节点裸机摆在那里，先点哪里」。深信服超融合HCI 用户及部署手册这类资料的核心价值，是把计算、存储、网络三条线在同一个平台上的初始化顺序讲清楚。它解决的是中小规模数据中心里「服务器加本地盘能不能顶替传统存储阵列」这个具体问题，适合手里有 3 到 8 台同构服务器、准备做资源池化又不想引入独立存储的运维和集成人员。这篇笔记按我实际交付过的顺序拆：先讲清超融合在深信服这套体系里到底怎么组织资源，再落到部署前的硬件与网络核对、集群初始化、存储策略配置，最后把踩过的坑和验证手法摊开。读完你应该能独立走完一遍从裸机到虚拟机可用的流程，而不是只记住几个菜单名。

2. 部署前必须想清楚的资源模型与硬件核对

深信服超融合HCI 的部署不是「装个系统」那么简单，它把每台物理机的本地磁盘聚合成一个分布式存储池，再在其上跑计算虚拟化。理解这个模型，才能明白为什么部署前的核对比安装本身更耗时间。

2.1 计算、存储、网络三张网为什么必须物理隔离

超融合节点之间要同时跑管理流量、虚拟机业务流量和存储副本同步流量。存储同步对延迟极其敏感，一旦和业务流量挤在同一张网卡上，副本写入延迟会从毫秒级跳到几十毫秒，表现为虚拟机间歇性卡顿。常见做法是至少三张物理网口：管理网、业务网、存储网各一张，存储网建议万兆起步。如果服务器只有两个网口，那就把管理和存储用 VLAN 逻辑隔离，但存储流量必须走独立 VLAN 且不能被其他广播域干扰。

我一般会在部署前画一张表，把每台节点的网口、IP 段、VLAN ID、用途列清楚，避免装到一半发现存储网和业务网同段。

2.2 硬件核对清单与磁盘选型边界

深信服超融合HCI 对硬件有兼容性要求，不是随便一台服务器都能进集群。核对时重点看四项：CPU 是否支持虚拟化指令集并在 BIOS 中开启、内存是否满足「每节点不低于 64GB 且预留 8GB 给平台自身」、磁盘是否全部为同一类型（SSD 和 HDD 混插会拉低整池性能）、RAID 卡是否处于直通模式而非 RAID 模式。直通模式这一点最容易翻车，很多服务器出厂默认做了 RAID 0，进集群后平台识别不到单盘，存储池建不起来。

磁盘选型上，全闪适合对 IOPS 敏感的业务，混闪适合容量优先但能接受冷数据延迟的场景。注意：一旦集群初始化完成，再想换磁盘类型基本等于重建集群，没有后悔药。

2.3 部署前的固件与 BIOS 基线检查

这一步经常被跳过，但它是后面所有玄学问题的根源。我习惯在装平台前统一做三件事：把 BIOS 升到厂商推荐版本、把 RAID 卡固件对齐、关闭节能模式（C-State 和 P-State）。节能模式会导致 CPU 频率抖动，进而影响存储副本同步的稳定性，表现为集群偶尔报「节点通信超时」。

# 在每台节点上通过带外管理或本地终端检查关键项 # 1. 确认 CPU 虚拟化已开启（输出应为 vmx 或 svm） grep -E "vmx|svm" /proc/cpuinfo | head -1 # 2. 确认内存总量，单位 MB，需大于 65536 free -m | awk '/Mem/{print $2}' # 3. 确认磁盘是否直通（无 RAID 卷信息，直接看到物理盘） lsblk -d -o NAME,SIZE,TYPE | grep disk

这段检查的逻辑是：虚拟化指令集决定能不能跑虚拟机，内存决定平台自身预留后还剩多少给业务，磁盘直通决定存储池能否识别单盘。参数上，内存那条如果低于 64GB，建议先加内存再部署，否则平台装完可用资源会非常紧张。

3. 集群初始化：从单节点配置到三节点组网

单节点装完只是开始，真正决定集群能不能稳定跑的是组网和初始化顺序。深信服超融合HCI 的集群初始化对顺序有要求，先配管理网再配存储网，最后加节点，顺序错了会导致节点间信任关系建立失败。

3.1 首节点安装与平台初始化

首节点安装通常通过 ISO 引导，过程是自动化的，但有几个交互点需要手动确认：管理网 IP、网关、DNS、集群名称。集群名称一旦设定不建议修改，后续节点加入时靠它识别。安装完成后通过管理网 IP 登录平台，先别急着加节点，先把存储网和业务网的网口在平台里绑定好。

# 首节点安装后，通过 SSH 登录平台底层确认服务状态 # 查看集群管理服务是否正常 systemctl status cluster-manager # 查看存储服务是否已启动并处于单节点模式 systemctl status storage-service # 确认管理网 IP 配置生效 ip addr show | grep -A2 "mgmt"

逻辑说明：cluster-manager 负责节点间通信，storage-service 负责分布式存储。首节点安装后 storage-service 处于单节点模式，此时还没有副本，加节点后才会自动构建副本。参数上，如果 storage-service 起不来，八成是磁盘直通没做对，回去查 RAID 模式。

3.2 存储网与业务网的绑定与 VLAN 配置

在平台网络配置里，把物理网口绑定为虚拟交换机，再在虚拟交换机上划分 VLAN。存储网建议用独立虚拟交换机，不承载任何虚拟机流量。业务网可以和管理网共用一个虚拟交换机但用不同 VLAN。绑定模式上，存储网用主备或 LACP 都行，但 LACP 需要交换机侧配合做链路聚合，如果交换机没配，用主备更稳妥。

配置完成后，用 ping 大包测试存储网连通性，这是验证 MTU 和链路质量最快的方法。

# 在节点 A 上向节点 B 的存储网 IP 发大包，测试链路 # -M do 禁止分片，-s 指定包大小，存储网建议 MTU 9000 时用 8972 ping -M do -s 8972 -c 100 <节点B存储网IP> # 如果丢包或报 "Message too long"，说明 MTU 不一致 # 检查两端网口 MTU ip link show | grep mtu

参数说明：-s 8972 是配合 MTU 9000 的常用值（9000 减去 28 字节包头）。如果存储网用默认 MTU 1500，就把 -s 改成 1472。丢包率超过 0.1% 就要查线缆和交换机端口，别带着问题加节点。

3.3 节点加入集群与副本策略设定

首节点就绪后，后续节点通过管理网 IP 加入。加入过程中平台会自动同步配置并构建存储副本。三节点集群默认副本数为 2，意味着每份数据存两份，允许坏一台节点而不丢数据。如果节点数大于等于 5，可以考虑副本数 3，但会牺牲可用容量。

加入节点时注意：一次只加一台，等前一台完全同步完成再加下一台。同步期间集群 IO 会升高，别在这个时候跑重业务。

# 在首节点上查看集群节点状态和副本同步进度 # 查看节点列表及健康状态 cluster-cli node list # 查看存储池副本同步进度，关注 "rebuild progress" storage-cli pool status # 查看集群整体健康评分 cluster-cli health check

逻辑说明：node list 确认所有节点在线且版本一致，pool status 确认副本同步完成，health check 给出整体评分。参数上，如果 rebuild progress 长时间停在某个百分比，通常是存储网带宽不够或磁盘有坏道，先查存储网大包丢包率再查磁盘 SMART 信息。

4. 存储策略与虚拟机模板的落地配置

集群建好只是有了资源池，真正让业务跑起来还需要配存储策略和虚拟机模板。深信服超融合HCI 的存储策略决定了虚拟机的数据放在哪一层、副本几份、是否压缩，这些直接影响性能和容量。

4.1 存储策略的参数含义与选型

存储策略里几个关键参数：副本数、数据压缩、数据重删、缓存策略。副本数前面说过，三节点用 2。数据压缩对文本类数据效果好，对已压缩数据（如视频）反而浪费 CPU。数据重删适合桌面虚拟化场景，对数据库场景收益低。缓存策略决定热数据是否放 SSD，全闪集群可以关掉。

我一般会建两条策略：一条「高性能」给数据库和核心业务，副本 2、不压缩、缓存优先；一条「大容量」给文件共享和备份，副本 2、压缩开启、缓存关闭。策略建好后在创建虚拟机时选择，后期可以改但会触发数据重分布，尽量一次选对。

4.2 虚拟机模板制作与批量部署

模板制作的核心是「干净」：装完系统后打全补丁、装好虚拟化工具、清空临时文件、关机前做一次磁盘清理。然后用平台的自定义规范（类似 sysprep）做泛化，避免批量部署后 SID 冲突。

# 在模板虚拟机内执行泛化前的清理（以常见 Linux 为例） # 清空日志和临时文件 rm -rf /tmp/* /var/tmp/* journalctl --vacuum-time=1d # 清空机器 ID，避免克隆后冲突 truncate -s 0 /etc/machine-id # 关机，然后在平台中转换为模板 shutdown -h now

逻辑说明：清临时文件减小模板体积，清 machine-id 避免克隆后网络配置冲突。参数上，Windows 模板用平台自带泛化工具，Linux 模板手动清 machine-id 即可。转换模板后，批量部署时选择前面建的存储策略，一次可以部署几十台，但注意并发部署数量别超过集群剩余 IO 能力，否则部署过程会非常慢。

4.3 业务上线前的连通性与性能验证

虚拟机起来后别急着交付，先做三项验证：虚拟机之间互通、虚拟机到外网互通、存储性能达标。存储性能用平台自带的性能监控看 IOPS 和延迟，三节点全闪集群单虚拟机随机读 IOPS 应该在几千以上，延迟在毫秒级。如果延迟超过 10 毫秒，回去查存储网和磁盘健康。

# 在虚拟机内做磁盘性能快速验证（Linux） # 顺序写测试，1M 块，4G 数据 dd if=/dev/zero of=/tmp/testfile bs=1M count=4096 oflag=direct # 随机读测试，用 fio 更准确 fio --name=randread --ioengine=libaio --rw=randread --bs=4k \ --numjobs=4 --size=1G --runtime=60 --time_based --group_reporting

参数说明：dd 的 oflag=direct 绕过缓存，测的是真实磁盘写入。fio 的 bs=4k 模拟数据库随机读，numjobs=4 模拟并发。如果 fio 结果 IOPS 远低于预期，先确认虚拟机是否落在高性能存储策略上，再查集群整体负载。

5. 部署与运维中的避坑记录

这一章是我在多个项目里攒下的血泪经验，每条都按「现象 → 原因 → 解决」写，遇到类似情况可以直接对照。

5.1 节点加入集群卡在「正在同步配置」

现象：新节点加入时进度条长时间停在 30% 左右，最终报超时。原因：管理网和存储网走了同一张物理网卡，同步流量把管理通信挤掉了。解决：把存储网拆到独立网口，或者在虚拟交换机上给管理流量做 QoS 保障。如果硬件限制无法拆分，至少把存储网 VLAN 优先级调高。

5.2 集群健康报「存储副本降级」但磁盘没坏

现象：平台告警副本降级，但检查磁盘 SMART 全部正常。原因：存储网大包丢包导致副本同步失败，平台误判为副本不一致。解决：用 ping 大包测存储网，发现丢包后查交换机端口错误计数和线缆。我遇到过一例是光模块老化，换模块后恢复。

5.3 虚拟机批量部署后网络不通

现象：模板部署出来的虚拟机 IP 冲突或网卡不识别。原因：模板泛化不彻底，machine-id 或网络配置残留。解决：Linux 模板清 machine-id 和网络规则文件，Windows 模板用平台泛化工具重新封装。部署后如果还不通，检查虚拟交换机的 VLAN 配置是否和模板里的网卡配置匹配。

5.4 性能远低于预期，但资源监控显示不忙

现象：虚拟机卡顿，但集群 CPU 和内存利用率都不高。原因：虚拟机落在了「大容量」存储策略上，数据走了压缩和重删，CPU 开销大且延迟高。解决：把虚拟机迁移到「高性能」策略，迁移过程会触发数据重分布，建议在业务低峰做。迁移完成后用 fio 复测。

5.5 平台升级后部分节点服务起不来

现象：集群升级后个别节点 storage-service 无法启动。原因：升级前没做固件基线对齐，新版本对磁盘直通模式要求更严。解决：回退升级或把节点磁盘重新确认为直通模式。预防手段是升级前统一固件版本，并确认所有节点硬件配置一致。

6. 进阶：用性能基线把「玄学卡顿」变成可排查项

部署完成只是起点，真正让集群长期稳定的是建立性能基线。我的习惯是集群上线后第一周，每天固定时间采集一次关键指标，形成基线数据。之后任何「感觉卡」的反馈，先和基线对比，而不是凭感觉调参数。

采集项包括：集群整体 IOPS 和延迟、每节点 CPU 和内存利用率、存储网大包丢包率、副本同步队列深度。这些数据平台自带监控都有，但默认保留时间短，建议导出到外部时序库。下面是一个简单的采集脚本思路，用平台 API 拉数据后写入本地文件，方便后续对比。

# 伪代码示意：通过平台 API 采集性能指标并落盘 import requests import json import time # 平台 API 地址和认证信息（实际使用时替换为环境变量） API_BASE = "https://<管理网IP>/api/v1" TOKEN = "<登录后获取的token>" def collect_metrics(): headers = {"Authorization": f"Bearer {TOKEN}"} # 采集集群整体性能 cluster_perf = requests.get(f"{API_BASE}/cluster/performance", headers=headers).json() # 采集存储池状态 pool_status = requests.get(f"{API_BASE}/storage/pool", headers=headers).json() # 采集节点健康 node_health = requests.get(f"{API_BASE}/cluster/nodes/health", headers=headers).json() record = { "timestamp": int(time.time()), "cluster_iops": cluster_perf.get("iops"), "cluster_latency_ms": cluster_perf.get("latency"), "pool_rebuild": pool_status.get("rebuild_progress"), "node_status": [n.get("status") for n in node_health.get("nodes", [])] } with open("/var/log/hci_metrics.jsonl", "a") as f: f.write(json.dumps(record) + "\n") if __name__ == "__main__": collect_metrics()

逻辑说明：这段脚本做的是定时拉取平台性能接口并追加写入 JSONL 文件，方便后续用脚本做趋势对比。参数上，采集频率建议 5 分钟一次，太频繁会增加平台负担，太稀疏则抓不到瞬时抖动。落盘后可以用简单的 awk 或 Python 做基线对比，比如对比当前延迟和过去 7 天同一时段的均值，偏差超过 50% 就触发排查。

验证方法上，我一般会做一次「受控压测」：在业务低峰用 fio 在测试虚拟机上打满存储，观察集群延迟曲线和副本同步队列。如果延迟曲线平稳且队列不堆积，说明集群有余量；如果延迟飙升，说明存储网或磁盘是瓶颈，需要扩容或调整策略。这个压测结果就是后续扩容决策的依据。

最后说个我自己的教训：早期做项目时总想一次把集群配到「最优」，结果参数改来改去反而把基线搞乱了。后来固定一个习惯——部署完成后先跑一周默认配置，采集基线，再根据基线做一次针对性调整，之后除非业务变化否则不动。集群这东西，稳定比激进重要。希望帮到你。

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