1. 先把HCS放在整个私有云版图里看如果你接触过传统虚拟化再去看华为HCSHuawei Cloud Stack私有云很容易产生一个困惑这不就是一批物理服务器加上虚拟化软件吗其实HCS解决的不是“虚拟化”这一层的问题而是从IaaS到PaaS再到运维运营体系的完整云平台建设。它更像是一套“可交付的云操作系统”而不是单纯的虚拟化工具。我最早接触HCS是在一个中型企业的数据中心改造项目里。客户原来用的是多套独立的虚拟化集群每个业务部门自己申请资源、自己管理几十台虚拟机零散分布在不同的物理机上资源利用率低扩容要靠手工迁移。HCS进入视野之后最关键的变化是把“资源池”真正做起来了计算、存储、网络三类资源统一编排业务部门通过自服务界面申请管理员只需要在后端做配额和策略管理。这套逻辑和公有云是一致的区别在于它部署在客户自己的机房数据和管控面都在本地。HCS适合谁来参考我的判断是三类人一是正准备从传统虚拟化向私有云演进的基础设施团队二是需要同时管理多套环境、希望统一运维入口的运维人员三是对业务连续性有较高要求、需要一套完整容灾或双活方案的技术决策者。如果你是刚接触私有云这篇文章可以帮你把HCS的架构骨架和部署逻辑串起来而不是一上来就陷进操作细节里。实际部署HCS时底层是一套标准化交付包物理服务器、存储设备、交换机、防火墙加上华为自研的FusionCompute、FusionStorage、ManageOne等组件统一由部署工具完成初始化。这个过程中最需要理解的是各组件之间的边界和依赖关系。先把这个搞明白后面每一步操作都不会跑偏。2. 架构拆解HCS各层组件到底在干什么2.1 控制面ManageOne和CPS不是一回事很多刚接触HCS的人容易把ManageOne当成整个平台的全部。实际上ManageOne只是统一运维与运营门户它承担的是“对外窗口”的角色云管平台的租户申请、资源审批、监控告警、账单展示都从这里进去。真正负责底层资源编排和部署的是另一个核心组件CPS——Cloud Provisioning Service中文叫云服务部署系统。CPS这个名字可能不如ManageOne响亮但它的作用是基础性的。整个HCS集群的初始化、组件的安装升级、节点的健康检查全部由CPS驱动。形象点说CPS是“施工队”ManageOne是“物业服务中心”。施工队先把机房里的资源搭好物业中心再对外提供窗口服务。没有CPS你连第一台裸金属服务器都纳管不进去。2.2 计算虚拟化FusionCompute的核心角色FusionCompute是HCS的计算底座在存储和网络组件还在单独部署时FusionCompute往往已经先把计算资源池撑起来了。它由两部分组成CNACompute Node Agent运行在每台物理服务器上负责虚拟机的生命周期管理VRMVirtual Resource Manager是管理节点负责集群调度、HA、DRS等高级功能。Support的虚拟化底层基于KVM所以在Linux运维里有经验的人会感觉比较顺手。但要注意FusionCompute不等同于开源的KVM栈它把资源调度、安全策略、热迁移、快照、模板等能力都做了产品化封装。在实际部署中VRM节点通常以虚拟机形式运行建议把VRM独立放在一台可靠宿主机上避免与承载业务的虚拟资源争抢CPU和内存。2.3 存储虚拟化FusionStorage把本地盘变成分布式存储池FusionStorage是HCS在存储侧的关键组件也是整个私有云里我最看重的部分。它做的事情可以这样理解把多台服务器自带的SATA盘、SAS盘或者NVMe盘聚合起来形成一个大容量的分布式存储池同时提供块存储、文件存储和对象存储能力。也就是说你不一定非得购置独立的集中式存储阵列本地盘也能组成企业级存储。这块设计在部署时有明显的成本优势。一个三节点的集群每台服务器插上几块机械盘和一至两块SSD缓存盘就能对外提供千核级别的虚拟机磁盘性能。但这里也有它的约束节点越多数据副本和一致性开销越大网络的带宽和时延要求也越高。规划时需要结合业务规模合理设置副本策略通常生产环境建议两副本或三副本不能贪图空间而降低数据可靠性。2.4 网络虚拟化VXLAN和SDN的实现思路HCS的网络虚拟化分两个层面。底层是物理交换网络负责服务器之间的互通上层是Overlay网络采用VXLAN技术将虚拟网络与物理拓扑解耦。这个设计和公有云里VPC的实现思路一样每个租户的网络、子网、安全组都是逻辑隔离的即使所有租户共用同一套物理网络彼此之间也互不感知。在网络部署实操中我最想提醒的是不要因为HCS自带网络自动化配置就不管underlay。Underlay如果设计不合理例如IP地址规划冲突、路由收敛慢、MTU不一致Overlay再先进也会出现间歇性通信故障。早期我在一个二层广播域过大的环境里排查过一次“云主机某些IP通、某些IP不通”的诡异问题最后定位到MTU不一致导致VXLAN封装后的分片异常。所以底层网络规划要“笨功夫做扎实”。3. 部署前的关键考量决定成败的不是安装命令3.1 版本选型和License规划HCS的版本迭代节奏比较快不同的版本对底层硬件平台、服务器固件、交换机型号和操作系统内核都有配套要求。部署前一定要先从华为官网或销售侧要到兼容性列表兼容性表把你准备采购的服务器型号、网卡型号、硬盘型号逐个核对一遍。踩过一次很典型的坑客户机房采购了一批比较新的NVMe固态硬盘但HCS当前版本的内核驱动还不支持装完FusionStorage后硬盘始终无法被识别只能等待华为发布适配补丁。所以选型阶段千万别嫌麻烦直接对着兼容性列表买硬件后续能省很多事。License方面HCS采用的是按CPU物理核数授权的模式。你需要规划好物理服务器的数量和单台服务器的核数再乘上一个冗余系数。如果预留了未来3年业务扩容的余地建议License按扩容后的规模一次性购买因为后续追加授权不仅要走合同流程还可能受版本限制无法平滑升级。3.2 网络规划管理、业务、存储的三网分离HCS部署中网络规划是最容易出问题的一个环节。官方推荐的做法是管理网络、业务网络、存储网络三网分离。管理网络承载ManageOne、CPS、FusionCompute VRM等管理组件的通信业务网络承载虚拟机之间、虚拟机与外部网络的南北流量存储网络专门承载分布式存储的内部数据复制和IO流量。三网分离的核心原因是性能隔离和故障隔离。存储网络如果和业务网络混在一起业务高峰期的大流量会直接影响分布式存储的同步时延而存储数据同步慢又会反过来拖累虚拟机的磁盘读写形成恶性循环。物理上建议存储网络使用独立网卡和独立交换机VLAN条件允许时存储网络还可以考虑使用无损网络配置以避免TCP丢包重传带来的性能损耗。3.3 硬件资源评估的“反直觉”之处做HCS的容量规划时很多人习惯只算虚拟机所需的CPU和内存总和然后等比例换算物理服务器数量。实际部署后你会发现存储的性能瓶颈往往比计算资源更先到来特别是IOPS密集型业务。举一个实际例子一个规模不大的开发测试环境虚拟机的CPU利用率长期在20%左右内存利用率也就50%但因为所有系统盘都放在同一个分布式存储池里在没有SSD缓存的场景下全量打镜像和批量编译构建时存储时延明显飙升。所以硬件规划不能只看总量的“平均数”务必要估算峰值的压力。存储层面优先引入SSD作为缓存层或者按业务类型拆分多个存储池——数据库类的虚拟机放在高性能池开发测试类虚拟机放在低成本的机械盘池。这个设计直接影响后续运行业务的体验也是架构师体现水平的地方。4. 部署实操从裸机到云资源开通的全流程4.1 底层系统与网络初始化HCS的部署工具会引导你完成大部分底层初始化工作但在运行部署工具之前有几件事必须要人工确认到位。物理服务器设置BIOS为Legacy或UEFI启动模式并确保RAID卡直通或配置好磁盘模式FusionStorage场景下通常建议磁盘直通不做RAID。所有服务器的时间必须同步NTP服务要提前配置好时区统一为UTC8。时间不同步会导致证书校验失败、组件心跳异常这是初期安装失败最常见的原因之一。交换机的端口模式要提前确认管理VLAN和业务VLAN的trunk放通要配置好。这些准备全部就绪后通过部署向导输入各个节点的IP、主机名、root密码再选择部署场景和组件工具会自动往节点上安装操作系统和基础软件。整个自动化过程通常需要几个小时期间不要手动去重启节点否则容易导致部署中断。4.2 FusionCompute资源池创建底层部署完成后第一步就是登录FusionCompute的管理界面创建集群。这个过程和VMware vSphere创建Cluster是类似的为集群设置DRS自动调度、HA高可用、EVC模式等参数。我建议创建集群时把所有宿主机的EVC模式设为一致避免不同代际CPU的服务器之间热迁移时出现“非法指令”的报错。然后是添加主机。每台物理服务器上运行着CNA代理FusionCompute通过这些代理纳管服务器。加主机时要注意正确选择存储接口和业务接口的物理网卡主机加入集群时会自动扫描可用的存储资源和网络资源如果底层VLAN配置不对这一步可能会发现不了存储池或网络需要回头检查交换机和网卡绑定配置。4.3 FusionStorage的初始化和存储池划分FusionStorage的初始化是在FusionCompute已经运行的基础上进行的。你先指定一批节点作为存储节点然后对每台服务器的物理磁盘进行声明哪些盘做数据盘哪些盘做缓存盘哪些盘做系统盘绝不能动。这个步骤一定要仔细核对因为一旦把系统盘声明成数据盘或者把缓存盘配置得过大都会影响存储集群的可靠性。存储池划分时要按业务场景分别建立高性能存储池和大容量存储池并分别挂载到对应的主机集群。给虚拟机发放存储卷时分配策略也有讲究厚置备延迟清零适合需要提前预留空间的核心数据库精简置备适合开发测试环境但因为按需分配也存在超分导致存储池写满的风险。生产环境请谨慎使用大面积精简置备。4.4 ManageOne的集成与云资源开通FusionCompute和FusionStorage都工作正常后部署管理面ManageOne就是打通云服务体验的最后一环。ManageOne会同步FusionCompute里已有的资源池、集群、存储和网络信息然后统一在平台上抽象为“区域Region”“可用分区AZ”“规格”“镜像”等云资源概念。云资源开通的实测路径大概是管理员先在ManageOne上创建“企业项目”和“用户组”给运维人员分配项目管理权限运维人员导入镜像、创建“虚拟私有云”和“子网”业务用户登录自服务门户选择CPU、内存规格选择磁盘类型和网络一键创建虚拟机。整个流程和公有云控制台非常相似这也是HCS被称为“可交付的公有云”而不是“虚拟化平台”的最大原因。5. 实际部署和运维中常见的坑整理成速查表5.1 时间同步问题如果集群内部分节点的时间漂移超过一定阈值轻则告警重则导致服务间通信鉴权失败。排查时的第一反应一定是检查所有节点的NTP服务是否指向同一个时间源并查看偏移量。尤其在刚部署完成的数周内建议每天看一次时间同步状态等稳定后再放宽。5.2 主机名与域名解析HCS内部组件之间大量依赖主机名通信。安装部署时如果主机名起得比较随意后续排查问题会非常痛苦——日志里全是无法辨识的节点标识。而且各节点之间的/etc/hosts解析必须一致一台节点解析别名有误就可能出现“某服务无法启动但相邻节点完全正常”的怪异现象。5.3 存储双活与仲裁配置如果业务对连续性要求比较高HCS支持双活数据中心方案。跨站点部署时网络时延和仲裁机制是关键。仲裁节点选择在哪边、站间链路带宽是否足够、脑裂场景下的自动切换策略这几点需要在部署前和业务方充分对齐。千万不要以为双活是“全自动”的很多切换场景都需要人工决策。5.4 补丁和升级操作的顺序HCS的版本升级有严格的路径依赖不能跨版本跳级。升级前最好先查看官方补丁说明按顺序依次升级FusionStorage、FusionCompute、ManageOne等组件。我见过有人为了省事一次性跳了三个小版本结果部分组件的功能数据模型对不上最后只能回滚重新升级白白浪费一个维护窗口。5.5 监控告警阈值拍脑袋设置HCS内置的监控模板给出的默认阈值比较保守例如磁盘利用率达到80%就告警。实际使用中建议根据业务的真实波动调整告警阈值告警太灵敏容易疲劳太迟钝又起不到预警作用。一个实用的做法是先按默认阈值运行两周期间记录所有告警并归类把完全不影响业务的告警阈值调宽把真正影响业务的指标更细致地切分层次。6. 我自己的几点部署体会HCS这套平台第一次接触时会觉得组件多、概念多、部署流程长。但把它拆开看底层就是计算虚拟化、分布式存储、网络虚拟化这三驾马车上层再叠一套统一的运维运营门户。只要把每一层之间的依赖关系搞清楚部署和排错都不会是无头苍蝇。如果要在所有经验里挑一条最想强调的那就是不要一上手就追求“高可用全功能”。第一次部署时尽量按官方推荐的简化配置来先跑通最小的资源池验证计算、存储、网络的端到端能力再逐步叠加双活、备份镜像、多AZ等进阶特性。很多高级特性配置不当反而给基础设施引入新的故障点。HCS看起来是华为的私有云产品但它的整体设计思路、分层架构、部署流程和运维方法论很多地方都带着公有云技术的影子。你如果对一个公有云厂商的架构有较深理解再回过头来看HCS会更容易融会贯通。反过来也一样把HCS部署运维搞明白了再去理解云平台的技术原理视角会完全不一样。