SeigRobotics在开始聊HuaweiCloudStack之前，我想先还原一个场景：企业里原有的虚拟化平台跑了两三年，部门越来越多，资源池被切得七零八落，运维天天在处理“这台机器装不了这个系统”“那个网络通不了”之类的需求。你会发现自己其实需要一个带自助服务、计费配额、多租户隔离的私有云平台，而不是一台台物理机或一套套虚拟化集群。这时候HuaweiCloudStack就会被拉进选型名单。这篇文章，我想以一个做过多个政企云项目交付的视角，把HuaweiCloudStack到底是什么、架构怎么搭、哪些点最容易踩坑，一次讲清楚。
这篇属于系列第一篇，定位在“介绍与架构”。内容主要面向三类读者：一是刚接手公司云平台规划的技术负责人，二是准备考云架构相关认证的工程师，三是正在做技术选型对比的解决方案人员。看完这篇文章，你会对HuaweiCloudStack的整体定位、分层逻辑、核心组件、网络模型和部署形态有一个完整的认知，并且能理解为什么它在架构上要做某些看起来很“重”的设计。
1. 为什么企业最终会选HuaweiCloudStack：一个被频繁问到的选择题
1.1 私有云选型的三条路
我参与过不少私有云项目的前期调研，企业通常有三条路摆在那里。
第一条路是纯手工基于OpenStack自建。这条路听起来很“极客”，团队也确实能学到最多东西。但真正跑起来，你会发现光是把OpenStack的各个组件升级和打补丁就足够消耗一个小组的全部精力。Neutron网络模块出个莫名其妙的问题、Cinder存储后端某个驱动不兼容、Keystone的token过期时间调整引发连锁反应，每一件事都要自己扛。更别提OpenStack每个发行版之间的差异很大，社区版本迭代又非常快，没有足够的研发资源根本兜不住底。
第二条路是采购商业版OpenStack发行版，比如Red Hat OpenStack Platform、Mirantis等。这类方案的好处是供应商帮你把兼容性和稳定性做了大量工作，坏处是企业还是需要一个团队去维护这套平台，而且这些商业发行版在国内的生态支持、硬件适配、本地化交付方面，往往没有国内厂商那么贴身。
第三条路，就是买华为HuaweiCloudStack这一类由云厂商直接交付的私有云方案。它本质上仍然基于OpenStack生态，但华为在OpenStack之上做了三层东西：第一是大量自研组件补齐了OpenStack在企业级场景下的短板，比如更细粒度的资源调度、更完善的运营运维能力；第二是硬件层面的优调适配，服务器、存储、交换机选型都有官方兼容性列表，避免了自己拼凑硬件的兼容性风险；第三是商业交付的完整性，包括安装部署工具、升级方案、健康巡检、原厂支持服务体系。
很多企业最后选第三条路，并不是因为华为的架构比开源方案更“酷”，而是因为私有云本质上是个运营工程，不是技术demo。你需要的是一套有售后、有迭代节奏、有人负责的平台，而不是一个技术框架。
1.2 CloudStack两个“失散兄弟”的辨认
这里必须先澄清一个特别容易让人混乱的点：HuaweiCloudStack和Apache CloudStack是两个完全不同的项目。Apache CloudStack是另一款云管理平台，早期由Cloud.com公司开源，后来捐给了Apache基金会，底层虚拟化支持KVM、VMware、Xen等，整体架构思路也是管理多种虚拟化资源。而HuaweiCloudStack虽然名字里也有CloudStack，但它底子其实是OpenStack体系，走的路线完全不一样。
所以如果你在搜索引擎里查“CloudStack”，会看到很多Apache CloudStack的资料，但那些文档跟华为这套平台的关联度非常有限。在做技术选型对标的时候，建议把华为这套平台理解成“华为版的OpenStack企业发行版 + 云运营管理平台”，不要被名字带偏。
另外还有一个容易混淆的概念：华为云Stack（HCS）和HuaweiCloudStack。在实际项目里，华为云Stack更多指华为公有云的私有化部署版本，它在商业形态和软件菜单上和纯私有云有差异，包含了从基础设施到PaaS的完整云服务栈。HuaweiCloudStack这个称呼在一些历史文档、认证教材、交付资料里出现，更偏向笼统地指华为的私有云技术体系。为了避免纠结，这篇文章统一用HuaweiCloudStack来指代这套私有云技术体系，后续提到“云Stack”的时候，指的是商业交付的产品形态。
1.3 它到底能解决企业的哪些痛点
先说资源层面的痛点。传统虚拟化平台虽然有虚拟机，但缺少租户概念，A部门创建的VM和B部门创建的VM在运维视角上几乎是平级的。HuaweiCloudStack引入了完整的项目/租户模型，每个部门可以划分到独立的租户空间，配额、镜像、网络、存储策略都按租户隔离。管理员可以给某个部门分配“20核CPU、64GB内存、2TB存储”，到了配额上限就自动拒绝新资源申请，这个能力在虚拟化平台里做起来极其痛苦。
再说服务交付层面的痛点。原来开一台虚拟机要走工单：业务部门提申请、运维审核、再手动创建、再分配IP。HuaweiCloudStack把服务目录做成了自助化的，业务人员通过Web界面自己选择规格、网络、系统镜像，几分钟就拿到一台机器。管理员只需要在初始阶段把镜像和规格提前配好。
然后是运维和排障层面的痛点。私有云涉及虚拟化、分布式存储、SDN网络、云管平台多套子系统，出了问题要跨层排查。HuaweiCloudStack提供了统一告警中心，管理面上可以看到物理层、虚拟化层、云服务层的所有事件。虽然这个“统一”做得不是十全十美，但比自己在多个控制台之间切换要高效很多。
这套平台真正厉害的地方，是把“基础设施能力”变成“服务化能力”的整套工程化落地。它未必在每个技术指标上都是业界最强，但它完整度非常高，从底层驱动到上层API，从资源调度到计量计费，都是打通了的。对使用者来说，这比一堆零零散散的开源组件拼起来要省心很多。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 全局架构拆解：从硬件到用户之间的四层协作
2.1 四层架构的核心分层逻辑
HuaweiCloudStack的整体架构，大量借鉴并兼容了OpenStack的通用分层，但又相比社区版本做了很多工程化裁剪。如果从交付视角看，我会把它的逻辑架构拆成四层：硬件层、数据面、控制面与管理面。
硬件层很好理解，就是物理服务器、存储设备和网络交换机。在华为这套体系里，硬件选型特别重要，因为平台会针对特定硬件做驱动和固件的优化。比如服务器推荐使用华为自家的FusionServer系列，存储可以用OceanStor系列，网络交换机推荐CloudEngine系列。这并不是纯绑定策略，而是因为华为完成了大量兼容性测试和性能调优。你在实际项目里用第三方硬件也能跑起来，但性能和稳定性就需要自己验证。
数据面是真正承载业务流量的部分，包括计算节点上的虚拟化平台，也就是QEMU/KVM那一层，以及分布式存储的数据读写路径、虚拟网络的VXLAN数据转发路径。从流量角度看，业务数据每次读写都经过这一层，所以数据面的性能决定了用户真正的体验。华为在这个层面做了不少优化，比如裸金属服务器的统一纳管，比如DPDK和智能网卡在虚拟网络转发中的使用。
控制面负责管理数据面的资源和状态，对应的是OpenStack里的Nova、Cinder、Neutron这些控制服务。比如你发起创建一台虚拟机，Nova-scheduler要决定这台机器跑在哪台物理节点上；Neutron-server要分配网络和IP地址；Cinder要对接存储后端创建一块云硬盘。控制面一般不承载业务数据流量，但它一旦宕机，新的资源请求就无法处理，已经运行的虚拟机则不受影响。这也是为什么控制节点和管理节点要做高可用，而计算和存储节点可以承受单点故障的架构基础。
管理面是用户和administrator打交道的入口，对应的就是ManageOne这个统一管理平台。它负责两件事：运营管理和运维管理。运营管理包括多租户管理、配额控制、服务目录审批流和计量计费；运维管理包括监控告警、日志分析、容量管理和健康巡检。控制面解决“资源能不能创建”，管理面解决“谁能创建、创建了多少、平台有没有问题”。
2.2 控制面与管理面为什么非要分开
很多人第一次接触这套架构会疑惑：管理和控制不是一回事吗？为什么要拆成两个平面？
我做项目的时候也遇到过这种困惑。其实这两个面的服务对象完全不同。控制面是面向系统内部所有组件的，它要保证的是集群状态一致性和资源调度正确性，好比一台机器的发动机管理系统。管理面是面向人和流程的，它要处理的是多租户、配额、审批、审计和运营报表，更像是车辆的仪表盘和辅助驾驶系统。
两者分开最直接的好处是故障隔离。如果管理面出了故障，最多是用户无法登录控制台创建新资源，已经在跑的虚拟机、存储I/O、网络转发都不受影响。反过来，如果某个计算节点的虚拟化服务异常，导致上报给控制面的心跳丢失，管理面仍然可以让你看到是哪台节点出了问题，方便快速定位。
另外从设计理念上讲，OpenStack社区版本里的Horizon界面组件非常弱，仅能完成最基本的资源操作，根本不具备多租户审批流、计量计费、跨Region运营等能力。华为把管理面独立出来并且做成ManageOne，就是在补齐这个层面的企业级短板。所以你在学习这套架构的时候，如果把OpenStack的控制组件和ManageOne混在一起看，会觉得很乱。分开看就清晰了：控制面和数据面解决“技术上能不能做”，管理面解决“业务上怎么管”。
2.3 创建一台虚拟机的完整路径
把四层架构讲清楚后，我建议顺着一条真实的使用链路走一遍，这样你对每个组件落在哪个位置会有更直观的感觉。假设你是某个租户的管理员，刚登录ManageOne要创建一台CentOS虚拟机。
第一步，ManageOne管理面先认证你的身份。身份信息验证通过后，判断你在哪个项目空间、配额够不够、规格模板是否存在。这些审核逻辑在管理面完成。
第二步，ManageOne调用控制面的API，把创建请求转给Nova组件。此时实际动作发生在控制面，Nova-scheduler综合计算每台计算节点的CPU、内存、存储余量，选择一台合适的计算节点。
第三步，这台被选中的计算节点上的Nova-compute进程收到指令，开始调虚拟化层准备虚拟机。先把镜像从Glance服务拉到本地，再调用存储服务为虚拟机创建系统卷，同时Neutron组件会分配好虚拟网卡和IP地址。
第四步，虚拟机成功启动后，Nova反馈状态给控制面，控制面再把状态同步回管理面。你在ManageOne界面里就可以看到这台虚拟机已经处于“运行中”状态。
这条链路里，最耗时的一般是镜像下载和存储卷创建，而最容易出错的是网络资源配置。所以我们在项目交付时，网络部分总是要求最严格，这一点我放到后面的网络章节单独展开。
3. 核心组件地图：名字背后的实际职责
3.1 计算侧：Nova和它底下的虚拟化底座
计算资源池的核心组件是OpenStack的Nova。在HuaweiCloudStack架构里，Nova负责管理计算节点的虚拟机生命周期，包括创建、删除、迁移、冷热迁移、快照等。每个计算节点上的虚拟化底座，通常是把KVM通过FusionCompute这个虚拟化平台组件做了一层封装。
这里我多说一句FusionCompute。它本身可以单独作为一款服务器虚拟化产品交付，相当于华为版的vSphere。在HuaweiCloudStack体系里，FusionCompute承担了计算节点的底层虚拟化职责，Nova-compute则负责和FusionCompute交互。这个关系很多初学者会混淆，以为云平台直接和KVM对话，实际上中间还隔了一层面向物理机的虚拟化资源管理。
从实际运维角度看，这种设计带来的好处是：即使你的计算节点需要做底层固件升级、内核参数调整、虚拟化驱动更新，也有一套相对独立的操作路径，不会直接影响上层云平台的整体逻辑。坏处是，排障的时候要多看一层日志，如果虚拟机起不来，既要去Nova的日志里找调度和创建记录，也要去FusionCompute的日志里找底层虚拟化报错。
冷迁移和热迁移在实际项目中也是高频操作。冷迁移一般是计算节点要做硬件维护，停掉虚拟机后再迁移到其他节点，风险低但业务中断。热迁移则要求在共享存储环境下，把运行中的虚拟机从一台物理机迁到另一台，内存状态持续同步，业务基本不感知。HuaweiCloudStack对热迁移的支持还算成熟，但很依赖网络带宽和存储性能的稳定性；如果分布式存储的时延抖动特别大，热迁移过程中的内存同步可能会拖垮整个集群的网络，这一点务必在生产环境迁移前做足压力验证。
3.2 存储侧：三个存储菜单怎么选
存储是私有云项目里最容易出预算分歧的部分。HuaweiCloudStack的存储方案通常可以划分为三个菜单。
第一个是分布式块存储，对应OpenStack里的Cinder和Ceph/自研分布式存储。它的特点是数据分散在多个服务器的本地硬盘上，通过副本或纠删码算法保证可靠性。这种方案不需要单独买存储阵列，成本低，扩展性好，非常契合虚拟机的系统盘和数据盘。我在一个中型政企项目里看到他们用了三副本策略的分布式存储，三个存储节点各放一份副本，单节点故障数据不丢，在线扩容也很方便。
第二个是集中式存储阵列，对应华为OceanStor系列，通过Cinder驱动对接。这类存储的典型特征是使用FC或iSCSI协议提供块设备，性能稳定，功能丰富，可以做基于存储层的快照和远程复制。对于数据库这类对I/O时延极其敏感的业务，集中式存储阵列通常比分布式存储表现更好。缺点是成本高，而且存储阵列有单台架构的上限，扩容到多台之后管理复杂度也会上升。
第三个是在同一个云平台上同时使用这两种存储，也就是混合存储模式。比如普通虚拟机放在分布式存储上，而核心数据库的云硬盘放在集中式存储上。这种模式看起来最完美，但实际维护要额外小心，因为你在配置存储策略和故障排查时要区分不同的后端路径。
从具体选择建议来说：如果业务以Web应用、办公系统、开发测试为主，分布式存储完全够用；如果有Oracle、核心业务数据库这类重I/O应用，老老实实给它们规划集中式存储；如果预算充足，云平台可以同时纳管两种类型，按需挂载。
3.3 网络侧：从Neutron到SDN控制器
网络侧是HuaweiCloudStack架构中复杂程度最高的部分。总体来看，它基于OpenStack Neutron的模型，但华为在实际产品中会搭配自己的SDN控制器来实现更灵活的网络能力。这也是很多运维老手觉得“用OpenStack社区的纯软件网络方案跑大规模私有云不太稳”的解决思路之一。
从功能角度拆解，计算节点上的虚拟交换机负责把虚拟机发出的数据包封装成VXLAN，然后转发到目标节点。SDN控制器统一维护了整个虚拟网络的拓扑、IP地址分配、路由规则和策略配置。当管理员在ManageOne上创建一个新的VPC网络时，SDN控制器负责把对应的网络规则下发到所有相关的计算节点上。
这种集中控制、分布转发的架构模型和软件定义网络的经典思路是一致的。好处是规则变更收敛快，管理员在控制面改一条路由策略，SDN控制器能迅速推送到所有数据面节点，不用一台台手工登录改配置。坏处是SDN控制器本身成了一个新的高可用焦点，如果控制器集群出问题，网络策略的变更会受阻，已经下发到计算节点上的转发规则不受影响，但新建网络的流程会卡住。
网络这部分细节我后面专门用一个章节展开，因为这是私有云和传统虚拟化差异最大的地方。
3.4 管理侧：ManageOne包揽了多少活
前面已经提到，ManageOne是HuaweiCloudStack的管理面核心，它本身也是一个分布式应用，有自己独立的管理平面网络。从模块上分，ManageOne里包含运营管理与运维管理两大块。
运营管理主要面向云平台的使用方，比如业务部门的IT管理员。它提供了服务目录、资源申请、审批流、配额管理、计量计费等功能。实际项目中用得比较多的是：
- 租户管理员在ManageOne上自助创建虚拟机、订购云硬盘、申请公网IP。
- 部门负责人通过审批流控制资源申请，避免出现浪费。
- 财务或运营人员按月度查看各项目的资源消耗量和费用账单。
运维管理主要面向平台的运维团队。常用功能包括：
- 全局拓扑视图，把物理设备、虚拟资源、虚拟机之间的关系画出来。
- 告警管理，汇总来自服务器硬件、存储、网络设备、虚拟化平台、云平台各组件的告警。
- 日志中心，统一收集各组件的日志，方便故障复盘。
- 健康巡检和容量规划，定期检查集群健康状态，并提示资源水位。
在项目交付中，ManageOne的部署位置、网络连通性、账号体系和认证方式都是必须提前规划的项。如果企业已经有统一认证系统，ManageOne要对接LDAP或AD域；如果没有，则要在平台内部先建立账号体系，后续再谈单点登录。不要小看这个细节，我见过不少项目因为前期没有规划好认证对接，导致上线后所有用户都拿默认管理员账号在操作，完全失去了多租户隔离的意义。
4. 网络架构是目前最容易被低估的模块
4.1 为什么网络是私有云交付的最大难点
作为一个交付过不少云平台的人，我的真实感受是：计算和存储只要硬件没问题、配置别太离谱，基本上不会出大乱子。但网络不一样，它的问题往往是一层层嵌套的，牵一发而动全身。
从大的背景说起，传统数据中心网络是二层加三层混合的架构，服务器之间通过交换机二层互联，跨楼层或跨机房通信依赖三层路由。而私有云里，租户要求的是一个独立的、可以自定义IP地址段的虚拟网络空间。不同租户的虚拟机IP可以完全相同，比如A租户用了192.168.1.0/24，B租户也可以用192.168.1.0/24，两个网络必须在隔离的前提下正常运行。这种多租户叠加网络的需求，用传统的VLAN隔离来做的难度非常大，因为VLAN数量最多4096个，规模一大就不够用。
所以现在私有云普遍采用VXLAN叠加网络技术来解决这个问题。VXLAN使用24 bit的网络标识符，理论支持1600万个隔离网络，并且能够把二层网络跨越三层网络进行扩展。这带来的效果是：租户A和租户B都用192.168.1.0/24网段，但因为VXLAN网络标识符不同，互不干扰。
4.2 VXLAN大二层中的流量转发路径
深入了解HuaweiCloudStack的网络模型之前，需要先理解组件角色、数据路径和路由决策三者之间的关系。这里说的组件包括计算节点上的虚拟交换机、SDN控制器、网关节点等。
先看虚拟机发出一个数据包的场景。如果两台虚拟机在同一个VPC网络、且调度在同一台计算节点上，虚拟交换机直接在本机查询转发表，把数据包从源虚拟机网卡转发到目标虚拟机网卡。这是最快的一条路径，根本没有离开物理机，也不会产生东西向流量在网络上绕行的问题。
如果目标虚拟机在另一台计算节点上，源计算节点的虚拟交换机就会把数据包封装进VXLAN报文，外层加上VTEP地址和VXLAN网络标识符，然后通过物理网络送到目标计算节点解封装，再把原始数据包交给目标虚拟机。这条路径就是常见的VXLAN隧道转发。
如果两台虚拟机在同一个VPC网络，但处在两个不同的物理机房的二层域内，仍然可以通过VXLAN跨三层实现互通，前提是两台物理机的VTEP地址可以三层互通。华为这套平台的SDN架构支持这种跨三层的大二层组网，这也是私有云能够跨机架甚至跨楼宇收敛成一个逻辑资源池的关键。
4.3 东西向与南北向：两种流量的不同命运
在云平台里，东西向流量指的是虚拟机之间的通信流量，南北向流量指的是虚拟机与外部网络互访的流量。两种流量的处理路径在传统网络里是完全不同的。
东西向流量前面已经说了，尽量在计算节点本地或VXLAN隧道内完成转发。这里有一个关键设计点：华为这套平台支持分布式路由，也就是说每个计算节点上可以运行一个虚拟路由器实例，专门处理本物理机上虚拟机的路由决策。这样，同一计算节点内的跨网段互通、跨计算节点的同网段互通，都不需要把流量汇聚到某个集中的网络节点再转发出去。这个设计显著降低了物理网络的流量压力。
南北向流量则必须经过出口网关。虚拟机要访问外部网络，数据包会先到达所在计算节点上的虚拟路由器，然后查路由表，确定下一跳指向外网网关，再通过物理网络送到网关节点。网关节点上会做NAT或专用网络网关处理，最后把流量送进物理交换机，走正常的Internet出口或专线出口。
在传统网络设备上，我们经常看到的就是“先路由后NAT”，在云平台里也差不多，只不过路由和NAT都软件化了。你在交付时最需要关注的，是南北向流量的带宽瓶颈。如果所有租户的南北向流量都汇聚到一对硬件网关节点，出口带宽会被一下子压满。所以规划时要算清楚业务模型的流量比，是内网互访多还是上公网多，由此来决定计算节点数量、网关节点规格以及物理网络出口带宽。
4.4 网络规划中几个血与泪的经验
我在多个项目里踩过网络配置的坑，简单列几条最有价值的经验。
第一，VXLAN网络标识符规划和VLAN ID映射一定要提前做好表格。云平台内部的VLAN和VXLAN数量会在上线后迅速膨胀，如果不提前规划好命名规则和映射关系，后期排查网络问题会让你恨不得把所有交换机重启一遍。
第二，物理交换机的MTU一定要记得调大。VXLAN封装后包体会变大，默认1500 MTU在VXLAN场景里会出现大量分片甚至丢包。标准做法是把物理网络MTU调到9000，也就是开启巨型帧，让虚拟机的数据包在封装后仍能在一个物理帧里承载。但这个修改要全链路统一，交换机、服务器网卡、存储网络全都要一起调整，不然又会出现“有些地方通，有些地方不通”的诡异问题。
第三，管理网络、存储网络、业务网络必须物理隔离或严格逻辑隔离。计算节点的iBMC管理口、存储复制流量、虚拟机业务流量放在同一张物理网络上，一旦某个平面出现环路或广播风暴，会牵连所有业务。经验上至少要做到存储网络和业务网络分离，管理网络的带宽冲突可以通过独立网卡规划来规避。
第四，SDN控制器集群的部署位置一定要在管理网络里，保证它和所有计算节点控制通道的连通性。SDN控制器只管下发热规则和收集状态，不参与业务数据包的转发，所以对它的网络质量要求反而没那么高，但控制通道一旦断了，新建网络和修改网络策略都会卡壳。
5. 部署形态与高可用设计：小规模和大规模的区别
5.1 最小部署集长什么样
如果你想搭一套测试环境或小规模生产环境，HuaweiCloudStack的最小规模可以压到3台物理服务器。这3台节点同时承担控制面和管理面的角色，也承担计算节点的职责，属于典型的小型融合部署。
具体分配上，3台服务器组成一个集群，每台上同时运行控制节点服务、管理节点服务、计算节点服务和分布式存储服务。虽然各服务互相争抢资源，但在测试环境里完全能接受。从资源规划角度看，每台服务器建议至少双路CPU、256GB内存，本地盘要预留充足空间存放分布式存储的副本数据。网络上需要至少配置业务网和管理网两张VLAN，服务器之间用万兆互联。
这种形态的主要用途是功能验证、POC测试和培训。你可以在上面完整跑一遍租户隔离、虚拟机生命周期、VPC创建、云硬盘挂载等所有核心流程，验证平台是否满足需求。但千万别把重要的生产业务直接压上去，因为控制面、管理面、计算面耦合在一台机器上，任何一个服务异常，都会造成同台机器上所有服务一起受影响。
5.2 生产级部署的典型高可用设计
到了真正的生产环境，架构就要拉开层次了。控制节点、管理节点、计算节点和存储节点通常分开部署。
以一套中型规模的私有云为例，控制节点至少3台，组成集群，通过负载均衡对外提供服务。这里面Nova、Neutron、Cinder、Keystone等组件都以多实例方式运行，任何一个控制节点宕机，请求会自动切换到其他节点。管理节点同样至少3台，ManageOne的各个服务分布在上面，前端通过VIP对外提供控制台入口。
计算节点按业务需求线性扩展，从几十台到几百台都可以，通过Nova的调度能力统一纳管。每个计算节点上跑着FusionCompute的Agent和云平台相关组件，采用无状态设计，坏了可以直接隔离，不影响全局。如果有虚拟机的HA策略，平台会检测计算节点故障，并把该节点上的虚拟机在其他节点快速拉起。
存储节点独立规划，组成分布式存储集群。通常至少3个存储节点起步，每个节点配置多块大容量盘，数据以三副本方式保存。存储网络单独使用万兆或更高的带宽，与业务网络分离，避免数据复制流量挤占业务流量。如果对可靠性有更高要求，可以提升到两副本加仲裁节点的模式，甚至把存储节点分到两个机房做灾难容错。
网络设备层面的高可用也很关键。每台计算节点至少两条物理链路分别接到两台TOR交换机，TOR交换机各自上行到两台核心交换机，形成无单点故障的物理网络。VXLAN的VTEP可以在服务器网卡上，也可能在TOR交换机上，具体取决于部署模式。业务允许的前提下，我强烈建议做链路聚合的冗余冗余方式，避免单链路故障导致业务中断。
5.3 多机房与多可用区的演进
规模再往上走，企业会面对多机房资源统一管理的问题。HuaweiCloudStack通过Region和AZ两个层级来组织资源。
Region对应一个地理区域或一个大型数据中心，每个Region有自己独立的控制节点和管理面。不同Region之间的资源基本物理隔离，Failover不透明，适合做容灾场景下的独立管理。AZ更细一层，对应同一个Region内的不同可用区，比如同一个机房的不同楼栋或不同电力域。同一个Region下的多个AZ共享控制面和管理面，但计算、存储资源物理分散。这样租户可以在不同AZ里各建一套应用，实现同城双活或者主备切换。
在架构选型时，Region的划分通常依据行政归属或管理边界，AZ的划分则依据故障域边界。这个设计听起来不复杂，但它决定了整个平台的容灾能力和运维模式，前期规划如果拍脑袋，后期再改几乎等于重构。建议你的Region和AZ划分尽量按照“故障半径”来定义，凡是可能一起挂掉的范围尽量缩到一个AZ内，跨AZ就得具备独立的恢复能力。
6. 上手前必须想清楚的几个问题：我的实操体会
6.1 容量规划最容易犯的错
做容量规划时，管理员经常只算CPU和内存，这是最容易翻车的。真实项目里还需要精确评估四类资源：CPU、内存、存储I/O能力和网络带宽。
CPU和内存好理解，虚拟机规格乘数量加余量，差不多就是物理资源的基数。存储容量则要看副本策略。比如你规划了10TB有效数据，使用三副本技术，实际占用的物理空间是30TB，再加上系统预留、快照空间、存储集群自身的冗余空间，实际采购量可能要到40TB以上。网络带宽同样容易被低估，虚拟机之间互拷贝大文件、存储做数据重建、系统做热迁移，这些操作在同一时刻发生，如果万兆网络被撑爆，全部业务都会跟着卡。
我建议你在规划阶段做一次“最坏场景演练”：假设50台虚拟机同时开机、30台虚拟机同时做快照、存储集群同时在做数据均衡，物理网络能不能承受？如果不想算得太复杂，就统一预留至少30%的冗余量，别让容量处于临界状态。
6.2 别把私有云当成“虚拟化加个界面”
传统虚拟化平台和私有云在运维心智上有一个巨大的差异：虚拟化平台运维的习惯是“这台物理机上跑着哪些虚拟机，我直接登录宿主去排查”；私有云的运维习惯必须切换到“资源属于哪个租户、VPC属于哪个网络、配额够不够、策略允不允许”这些更高维度的问题。
你可以在物理计算节点上看到所有虚拟机的进程，但不要在宿主层面直接去操作某个虚拟机的配置文件，因为云平台有自己管理虚拟机的API和数据库，直接改底层文件会造成状态不一致。如果你习惯了vSphere直接SSH到ESXi主机操作，用HuaweiCloudStack时一定要改掉这个习惯。规范的做法是通过ManageOne或命令行客户端下发请求，让平台自己完成操作，才能保证状态的一致性。
6.3 学习这套平台的最佳路径
如果你想系统掌握HuaweiCloudStack，我建议按这个顺序来学习。
先搭一个最小环境，用了解架构中每个组件的作用，哪怕只是三台物理机的小集群，也要亲手做一遍租户创建、网络创建、虚拟机发放、云硬盘挂载的完整流程。这个环节最能让你理解“管理面-控制面-数据面”三者之间的配合。
再专门学习网络部分。把VXLAN、分布式路由、安全组、NAT网关这些网络概念全部理解透，最好能在测试环境里故意配置一些错误，看看告警和日志里会有什么提示。
然后把存储部分的三种形态挨个用一遍。感受一下分布式存储和集中式存储各自的性能差异，再实际操作一次存储扩容和故障演练。
最后再学习ManageOne的运营功能，把配额、审批流、计费、项目空间这些企业级特性跑一遍。到这个阶段，你对这套平台的认知已经能覆盖大多数项目交付中需要面对的日常问题了。
作为系列第一篇，这篇文章先把HuaweiCloudStack的定位、分层架构、核心组件和网络模型梳理清楚。后面我会继续写第二篇，重点放在部署实操上，包括从零开始搭建一套测试环境、网络配置的具体步骤、以及安装过程中常见的报错处理和排查思路。如果你正在选型或者正在准备实施，可以先收藏这篇，等下一篇实操文出来一起对照着看。