简介面向华为 HCIE-Cloud Computing V3.0 认证备考者与云计算从业人员的培训教材围绕华为云Stack解决方案与政企上云知识体系组织内容适合需要系统理解认证考点和典型行业场景的学习者。压缩包内含 1 个 PDF 文件大小约 32.05MB便于集中阅读、离线查阅和按章节复习。目前已有 175 人学习。教材从云计算发展背景切入介绍华为云Stack的定位、整体架构与高阶云服务并围绕基础设施云化、应用使能、数据使能、统一管理四条主线展开结合数字经济、行业数字化转型与政企智能升级需求说明平台在合规部署、平滑上云和云上创新中的支撑作用。读者可据此建立解决方案的全局认识对照考纲梳理架构层次与关键能力并在备考和实际项目理解中查漏补缺。1. 一朵政企云的门槛不在虚拟化而在管理面和业务面能不能切开把服务器虚拟化、再发几台虚拟机出去这件事开源方案半小时就能跑通。真正卡住政企上云进度的从来不是 KVM 能不能起来而是另外三件事必须同时成立几十种异构硬件能被同一套调度吃掉多租户之间的网络该通的通、该断的断以及任意一个部件挂掉时业务还能在分钟级爬起来。HCIE-Cloud Computing V3.0 这份华为云Stack 培训教材反复在讲的其实就是这三件事的实现路径而不是产品清单。云计算在政企场景里最容易被低估的一点是它首先是一套隔离与边界的工程其次才是一套资源池的工程。教材里 12 类 80 云服务的背后真正的硬骨头是四层架构怎么切、管理面往哪放、网络在哪一层做策略、灾备在哪一层做切换。把这几个边界想清楚再看那些云服务名字就不再是一张背不完的表。2. 四层架构与分区部署ManageOne 为什么必须站在最外层华为云Stack 的系统整体架构被切成四层这个切法不是按功能归类来的而是按变化频率和信任边界来的。基础设施层收敛硬件差异资源池层把硬件翻译成可调度的资源云服务层把这些资源包装成有 SLA 的服务展现层则是唯一面向人的出口。层次越往下变更越慢、越重越往上迭代越快、越轻。2.1 四层各自负责什么边界划在哪里最底下是基础设施层适配多元算力支持 X86、鲲鹏、飞腾、海光四种 CPU 架构支持 GPU支持分布式存储与集中式存储、交换机、负载均衡器、防火墙。这一层的职责只有一个把物理世界的差异吸干让上面看到的永远是一类资源而不是某个型号的机器。第二层是资源池层教材的原话是通过云平台系统软件实现硬件资源池的使能和操作。注意使能和操作是两个动作——使能是把裸硬件变成受管资源操作是对受管资源做生命周期管理。这一层分别实现了 IaaS 的资源控制、容灾备份的资源控制、大数据与数仓的资源控制。也就是说容灾不是云服务层临时拼出来的功能它在资源池层就已经有独立的控制通路这也是后面 RPO0 能成立的前提。第三层是云服务层构筑 Service 能力实现云服务的使能和管控。ECS、EVS、VPC、CCE、OBS、CloudDNS、EIP、QoS 这些 IaaS 服务EI、PaaS、数据库、安全、ROMA 这些高阶服务都落在这一层。第四层是展现层ManageOne 是租户与运营运维的统一入口。提示判断一个云平台是否分层最简单的办法是看它换一款 CPU 或换一款存储时需要改动到第几层。如果改一层就够分层是真的如果要连服务层一起改那只是画了个分层图。2.2 ManageOne 为什么站在最外层而不是塞进服务层ManageOne 的职责有两块教材写得很清楚一是云服务的运营集成能力通过 Console Home 集成各云服务 Console给用户统一的云服务使用界面入口二是云平台的系统级运维能力实现对云服务端到端的监控监控对象包括云服务自身、租户资源和云服务所依赖的基础设施计算、存储、网络并基于这些监控与告警数据提供报表、大屏以及高级运维数据分析能力。把这一层独立出来、并且放在最外面解决的是一个很现实的问题云服务是不断新增的如果每个新服务都自带一套登录、鉴权、计费、告警界面运维人员的工作量会随服务数量线性增长。Console Home 集成各云服务 Console意味着新增一个服务只需要接入这套框架而不是重新造一套门户。这跟浏览器插件模型是一个思路——宿主提供容器和权限插件只提供内容。2.3 Global 与 Region 融合部署时的分区逻辑真正体现设计功力的是部署架构。在 HCS Global 与 Region 融合部署场景下Global 组件管理面与 Region 组件管理面部署在同一个 OpenStack 资源池内但按不同的业务特性部署在不同的网络区域内。这句话的含金量在于物理上共用一套资源池逻辑上必须按信任等级切开。DMZ 区部署 LVS、Nginx 等组件还有 HAproxy、DNS、NTP、API 网关、应用发布这些对外入口类组件External_OM 区部署运营运维服务、高阶服务、基础服务、跨云管理服务OM_Service 区部署远程接入组件包括堡垒机、前置服务器、升级代理、部署代理再往下是计算-管理下沉区部署高阶服务管理面计算-租户区部署计算 AZKVM/BMS网络区部署网络节点与网元BR/vRouter存储区部署块存储和对象存储。整体上还有可信区与半可信区的划分DGC、ISAP、ModelArts、DevCloud 这类数据与 AI 相关的服务落在更靠内的位置。这里有个容易被忽略的设计计算-管理下沉区单独存在。高阶服务比如数据库服务、大数据服务自身也需要算力如果把这些管理面算力放进租户 AZ就会带来两个问题——占用租户可售容量以及管理面与租户流量混在一张网里。管理下沉区的本质是把平台自己用的资源和卖给租户的资源在拓扑上分开这样租户看到的 AZ 容量是干净的平台扩容管理面也不会影响租户配额。用 OpenStack 原生命令可以直观看到 AZ 与主机聚合的对应关系这也是后续排查虚机为什么落在这台机器上的起点# 载入管理面凭据变量字段以现场实际为准 export OS_AUTH_URL管理面Endpoint export OS_USERNAME管理员账号 export OS_PASSWORD口令 export OS_PROJECT_NAMEservice export OS_USER_DOMAIN_NAMEDefault # 列出可用分区AZ 决定了一台虚机能落在哪一类硬件上 openstack availability zone list --long # 查看主机聚合aggregate 是把特性相同的主机聚成一组的手段 # metadata 里通常写着 cpu_arch、是否支持绑核、是否 GPU 节点等信息 openstack aggregate list --long openstack aggregate show 聚合组名availability zone list --long输出里的Hosts字段告诉你这个 AZ 由哪些计算节点组成openstack aggregate show的properties字段告诉你调度器靠什么把规格和主机匹配起来。后面所有关于一云多芯的讨论落地点都是这两条命令的输出。3. 一云多芯X86 与鲲鹏凭什么能在同一朵云里各干各的活教材里 HCS 8.1.1 把一云多芯列为云底座的第一条能力组合鲲鹏、X86、海光、飞腾多种 CPU 架构基础设施提供灵活的混合部署管理能力结合多种算力优势提供 KVM 虚拟化、BMS 等基础实例以及 GPU、NPU 等 AI 场景实例。这段话听起来像宣传语但它背后有一堆不解决就跑不起来的工程问题。3.1 能装上去和能被调度吃掉是两回事把一台鲲鹏服务器纳管进 OpenStack技术上只是加一个 nova-compute 节点。但真正的一云多芯要求是一个租户在同一个 VPC 里可以既有跑在 X86 上的虚机也有跑在 ARM 上的虚机两者之间二层互通安全组策略一致镜像和规格各自匹配计费口径统一。这就要求调度层能识别架构差异而不是让用户自己去猜。教材给出的落地形态是 AZ 划分AZ1-x86 资源池、AZ2-ARM 资源池、AZ3-裸金属资源池各自挂载对应的计算资源池KVM 主机组、裸金属。资源池的形态还不止虚机——虚拟化资源池、BMS 资源池、GPU 资源池、容器资源池、Hadoop 资源池并存用户无需关心真实物理硬件的类型和位置只按需向资源池提出诉求。这条用户无需关心是有代价的调度器必须能在发放阶段完成一次过滤。下面这段代码还原了这个过滤链的核心逻辑它解释了为什么规格里必须带架构信息# 调度过滤链的简化还原一台虚机最终落在哪个 AZ取决于规格与主机聚合的匹配 def filter_hosts(flavor, aggregates, hosts): candidates [] for host in hosts: agg aggregates.get(host[aggregate]) if agg is None: continue # 1) 架构必须匹配规格里声明 arm64就不能落到 x86 聚合组 if flavor[arch] ! agg[metadata].get(cpu_arch): continue # 2) 特性必须匹配需要 GPU / NPU / 绑核 / 大页的规格落到不支持的主机就是发放失败 required set(flavor.get(traits, [])) if not required.issubset(set(agg[metadata].get(traits, []))): continue # 3) 容量过滤预留水位避免把一台宿主机压到无法做 HA 切换 if host[free_vcpu] flavor[vcpus] * 1.2: continue if host[free_mem_mb] flavor[ram_mb] * 1.2: continue candidates.append(host[name]) return candidates aggregates { agg-arm: {metadata: {cpu_arch: arm64, traits: [npu]}}, agg-x86: {metadata: {cpu_arch: x86_64, traits: [gpu, hugepage]}}, } hosts [ {name: compute-arm-01, aggregate: agg-arm, free_vcpu: 64, free_mem_mb: 262144}, {name: compute-x86-01, aggregate: agg-x86, free_vcpu: 12, free_mem_mb: 32768}, ] # 一个 8 核 32G、需要 NPU 的规格只可能落在 ARM 聚合组里 print(filter_hosts({arch: arm64, vcpus: 8, ram_mb: 32768, traits: [npu]}, aggregates, hosts))这段逻辑里三个过滤条件对应三类真实故障架构不匹配会直接报镜像无法启动同一份 qcow2 镜像通常不能跨架构跑特性不匹配会在发放成功之后才暴露性能问题比如该绑核的没绑核、该用大页的走了普通页容量水位不留余量会导致单机故障时 HA 切不走虚机飘不起来。第三条最容易被忽略也最容易在大促或批量上线时炸。3.2 混合部署与保护投资的真实含义教材强调X86、ARM 资源池混合部署保护投资。这句话的实质是政企不会一次性把存量 X86 全部替换掉新采购的 ARM 机器要和旧的 X86 机器在同一朵云里共存若干年。所以多芯能力的关键指标不是支持几种架构而是不同架构的资源能不能被同一套配额、同一套 VPC、同一套运维视图管理。同理异构不只发生在 CPU 上。教材提到管理网络节点支持海光服务器管理网络节点与所有高阶服务支持飞腾 2500、海光 7280/7260 等多款异构服务器管理网络节点和所有高阶服务支持 icelake 服务器GPU 云主机新增支持 A40、A100(40G)。这些细节说明一件事连平台自身的组件也要能在国产化算力上跑否则全栈自主可控只覆盖了租户侧管理面还是个缺口。兼容性清单也是同一逻辑的延伸操作系统层面与 CentOS、中标麒麟、深度、Ubuntu 做过兼容性验证数据库层面有 MySQL、PostgreSQL、南大通用、达梦中间件有东方通/金蝶编译器与工具链有 GCC、JDK语言覆盖 C、C、Java、Python、Ruby、Go。往上教材提到对接行业合作伙伴超过 50 家、形成行业联合解决方案超过 60 个。这些数字的意义在于一朵云能不能落地取决于存量应用能不能不改代码跑上去而不是取决于架构图画得多漂亮。3.3 多核架构带来的性能增量从哪来教材给了两个性能口径云原生应用业务性能提升 80%基于昇腾的 AI 云服务性能提升 2 倍以上。这两个数字背后的机制不一样。前者主要来自容器化之后减少的虚拟化开销与更细的调度粒度——虚机里跑容器和直接在裸金属上跑容器网络转发路径和中断处理的开销差别很大后者主要来自 NPU 的专用算力与算子库适配通用 CPU 去做矩阵运算是纯粹的浪费。真正值得记住的是资源融合那一层的表述服务化内部把计算、网络、存储资源以虚机、容器、物理机、GPU 加速、AI 加速、高性能卸载转发、普通 IO 转发等形式提供给用户。这里的高性能卸载转发和普通 IO 转发并列出现说明转发路径是可选的——需要极致网络性能的业务比如高性能计算、高频交易类场景走卸载路径普通业务走通用路径。这种同一朵云里两种转发平面并存的设计是资源池层必须承担的复杂度。4. 虚拟网络的四道边界安全组、ACL、Peering、Endpoint 各管一段云网络最让人困惑的不是功能少而是功能太多、每种的生效范围和状态特性都不一样。教材把云内互通拆成七条、云外云间互通拆成四条这十一条能力如果按边界归类其实只有四道实例边界、子网边界、VPC 边界、数据中心边界。搞清哪道边界由谁负责排障时间能省一大半。4.1 实例边界与子网边界安全组和网络 ACL 的分工教材第一条子网内默认二层互通同时提供安全组能力可以基于实例端口边界做安全访问控制。第三条同 VPC 内跨子网默认三层互通同时提供网络 ACL 能力基于子网边界做安全访问控制。两句话点明了本质区别——安全组挂在端口上网络 ACL 挂在子网上。这带来的直接后果是安全组可以做到同一子网里 A 能访问 B、B 不能访问 A这种粒度而网络 ACL 只能做到整个子网进出的流量统一规则子网内部的互访它管不着。常见的实现思路是安全组有状态规则放通入方向之后回程自动放通网络 ACL 无状态进出方向要各自写规则。我一般会这么理解——安全组像每台机器自己的门卫网络 ACL 像楼层的大门楼层门禁不会记得你刚才是不是从这儿出去的。所以只放通一个方向跨子网访问就会变成单向通、回程被丢表现为能连上但没响应。4.2 VPC 边界Peering 配路由Endpoint 不配路由第四条和第五条是容易被混用的两个能力。VPC Peering 用于多部门数据快速共享、跨 VPC 的 VM 互通关键动作是按需配置路由——Peering 只建立了通道路由没配就是黑洞。VPC Endpoint 用于服务安全访问跨 VPC 访问 VM/容器/APIG 等特点是无需配置路由但需要额外配置安全访问控制。这个差异决定了选型如果是两个 VPC 之间大量主机互相访问用 Peering 加路由如果是多个 VPC 集中访问某一个服务典型的是把公共服务集中部署其他 VPC 来调用 Endpoint 更合适因为不需要在每个 VPC 的路由表里维护条目规模上去之后路由条目本身就是运维负担。第六条容易被忽略VPC 内支持精细化路由能力可把业务流量引流至特性云主机如安全软件实现云内流量调度满足第三方安全模块引流诉求。这条能力的存在说明一件事——云平台没有试图把所有安全能力都做进自己肚子里而是留了引流口子让第三方安全虚机能以下一跳的形式插进转发路径。这是很务实的设计取舍。4.3 数据中心边界EIP、NAT、专线、二层桥接、云连接云外与云间互通有四条路径各自解决的问题完全不同# 排查跨 VPC / 跨 Region 不通时的固定动作先看路由再看策略 # 1) 查 VPC 路由表Peering、专线、引流规则最终都体现在这里 openstack router show router-id -f json | jq .routes # 2) 查端口上的安全组绑定确认策略挂在了预期端口上 openstack port show port-id -f json | jq {sg: .security_groups, fixed_ips: .fixed_ips} # 3) 查子网关联的 ACL注意 ACL 无状态进出方向都要有规则 openstack network show network-id -f json | jq .tags第一段命令的输出是排障的分水岭如果有去程路由没回程路由表现是能发出请求、收不到响应和 ACL 只放通单向的现象一模一样但修法完全不同。这也是为什么网络排障必须按边界逐层收敛而不是一上来就抓包。EIP 解决的是内外同时主动访问双向SNAT 解决内网主动访问外网单向出DNAT 解决外网主动访问内网单向入。三者不是替代关系而是三种流量方向模型选错了不是不通而是通得不对——比如本该用 SNAT 的场景配了 EIP虚机直接暴露在公网安全组漏一条规则就是事故。专线解决 VPC 与本地网络互通二层桥接解决传统应用快速上云——本地网络内的应用迁移上云且 IP 保持不变靠的就是二层桥接云连接解决跨 Region 私网互通支持跨 Region 网络互通和跨云 VPC Peering。二层桥接这个能力看着不起眼实际是政企上云的关键一环大量存量系统的配置文件里写死了 IP改 IP 等于改应用二层桥接让这批系统能在不改代码的前提下先上云。4.4 ELB 的 7 层能力为什么单独列一条教材把ELB 服务支持跨云间的负载能力并支持 7 层高级路由单独列出来。7 层路由意味着可以按域名、路径做转发决策而不只是按四元组做四层负载。这在多云/混合云场景下价值很大——同一套域名一部分流量留在本地资源池一部分送到云上靠 7 层规则切分业务侧不用改任何配置。把上面这些能力串起来看会发现一个规律云内互通解决的是隔离前提下的连通云外云间互通解决的是连通前提下的合规。前者防止租户之间串流量后者保证数据该在哪就在哪。这两件事的方向是相反的所以必须用两套机制而不是一套。5. 网络排查从手工 tcpdump 到秒级定界的五条踩坑记录教材对传统排障方式的描述非常直白数据中心网络出现异常时运维人员需要手工登录各个节点上传 TCP DUMP 工具进行命令行抓包抓包完成后下载抓包文件到本地排查操作繁琐、耗时耗力、容易出错当需要在业务流的多个点同时抓包时需要同时操作多个命令行还需要一定的操作能力。这段话描述的是真实痛点不是客套话。5.1 定界的本质是缩小嫌疑范围不是找到根因CloudNetDebug 集了拨测和抓包两个功能用于处理数据中心内可能出现的各种网络问题。通过拨测工具可自动化检测业务网络是否出现断流、是否出现丢包通过抓包功能可实现自动化抓包支持基于业务流的多点协同抓包支持灵活的单点虚拟机网卡抓包和主机网卡抓包。它的四类典型用途教材写得很清楚检测网络断流、丢包问题网络故障时用于定界虚拟网络和物理网络的故障边界自动化定界是哪个网元节点的问题当无法确认是应用还是网络的问题时用于排除网络问题。注意第三条——排除网络问题本身就是一种结论。运维最怕的不是故障而是不知道锅在谁身上应用团队和网络团队互相等对方举证。这套工具在能力上的增量也很具体新增 vpcep、natgw、elb 拨测能力快速定界流量中断点新增 VIP 流量抓包支持 EIP/VPC/DC/VPC-PEERING 等网络流量类型运维场景加固主动链路探测新增 ELB 主动链路持续监测重要流量。拨测覆盖到 vpcep 和 natgw 这两个组件意味着 Endpoint 和 SNAT/DNAT 这两条最容易出问题的路径被纳入了自动检测。5.2 HawkEye Agent 的布点决定了能抓到什么采集侧靠的是 HawkEye Agent部署位置决定了观测视角。教材列出的布点包括CNA计算节点代理、BM裸金属、GW网关、vRouter/软 NAT、EGF/内核态 NAT 网关、UGW/EGF、BR、ELB、EulerOS Endpoint、UGW/EGF Backend。控制侧是拨测抓包 server包含 HkeController、hkeAnalyzer、Redis 主备、GaussDB。通道有四类REST API、RPC 信息查询通道、DB 数据通道、物理网络 ERSPAN。这张布点图解释了一个关键事实抓包不发生在虚机里而发生在虚机所在宿主的 vRouter 上、网关的软 NAT 上、ELB 的转发路径上。这既是能力也是限制——虚机内部协议栈的问题这套工具看不到但虚机之外的每一跳它都能看到。Redis 主备加 GaussDB 的组合说明拨测是有历史数据的不是一次性探测故障复盘时可以回看当时链路状态这一点比事后抓包有价值得多。5.3 五条踩坑记录注意下面五条都按现象 → 原因 → 解决记录前三条是策略类问题后两条是抓包姿势问题。现象跨子网访问能建立连接但收不到响应抓包看到去程报文正常、回程没有。原因网络 ACL 无状态只放通了入方向回程的临时端口被默认规则丢弃同时安全组有状态回程自动放通两套策略状态特性不一致导致误判。解决ACL 进出方向都显式放通排查时先看 ACL 再看安全组顺序反了会绕大弯。现象VPC Peering 建好之后两端虚机互 ping 不通Peering 状态显示正常。原因Peering 只建立通道不自动下发路由两端路由表都缺对方网段。解决两端路由表互指配完之后用openstack router show确认路由条目真的生效而不是只在控制台看到已创建。现象拨测结果显示链路可达业务侧仍然报接口超时。原因拨测验证的是四层可达ELB 后端健康检查失败但前端监听正常四层通、七层挂。解决启用教材里提到的 ELB 主动链路探测把后端健康状态纳入拨测范围同时检查 7 层路由规则是否把流量导到了错误的后端组。现象故障发生时想抓包抓包启动之后故障已经恢复抓到一堆正常报文。原因故障是瞬时抖动人工触发抓包永远慢一步。解决对重要流量常驻主动链路探测靠 GaussDB 里的历史拨测数据做复盘抓包只在复现阶段用多点协同抓包时用五元组对齐各采集点的报文避免拿不同流的包做对比。现象迁移上云后部分老系统连不上数据库网络层看起来全通。原因三层互通要求地址段规划不冲突存量网络与 VPC 网段重叠时会出现路由指向错误表现为时通时不通。解决上云前做网段冲突检查冲突且不能改 IP 的系统走二层桥接这也是教材把二层桥接列为独立能力的现实原因。6. 灾备分级的取舍RPO0 到底是拿什么换来的教材里灾备能力的表述是全地域、全场景、租户自助覆盖本地、同城、异地、两地三中心同城双活同时提供应用级与平台级业务连续性保障支持数据库服务、中间件服务、虚拟机容器等核心组件的双活做到实例级故障自动切换单部件切换后网络 IP 和接入访问方式不变业务完全无感知RPO 等于 0、RTO 分钟级。异地灾备则提供异地应用容灾、异地云主机容灾、异地数据备份。这张分级表把取舍摆得很清楚级别距离典型能力RPO改造代价本地高可用单数据中心虚拟机/容器 HA、云主机与存储备份、数据库与大数据备份取决于备份周期低基本无需改造同城高可用≤100km同城应用双活/容灾、同城大数据容灾、同城数据备份0中需应用支持双活异地灾备100km异地应用容灾、异地云主机容灾、异地数据备份大于 0中高需容灾编排两地三中心跨地域CSHA、CSDR一键式切换同城 0、异地大于 0高但业务无需改造RPO0 的来源是同步复制而同步复制受光传输时延约束所以同城的距离被限定在 100 公里这个量级超过这个距离只能走异步RPO 必然大于 0。这不是产品能力问题是物理问题。教材里支持 0-1、1-N 的容灾数据中心叠加单 AZ 到双 AZ 的 CSHA 演进这句话实际上是在承认大部分客户不会一步到位建两地三中心而是先单 AZ、再同城双活、最后异地平台必须支持这种渐进式演进。我认为这套设计里最值得琢磨的取舍是业务无改造上云即容灾。要做到业务不改代码就能容灾平台必须在资源池层就把容灾控制通路做进去而不是在应用层加 SDK——这正是第 2 章里资源池层分别实现 IaaS 的资源控制、容灾备份的资源控制那句话的真正含义。代价是平台复杂度大幅上升收益是存量系统不用重写就能获得分钟级 RTO。对于一堆跑了十几年的核心系统这个交换是划算的。另一个取舍是租户自助。统一的容灾管理平台方舟实现一键式容灾切换、降低运维复杂度租户甚至可以定期执行容灾演练。把演练权限交给租户意味着平台要承担租户误操作的风险但换来的是容灾方案真的会被验证——没演练过的容灾方案和没有容灾方案的区别只在于心理安慰。从那以后我每次评估一套云平台的灾备能力都会强制走一遍距离—RPO—改造代价这三个问题而不是先看它支持几种容灾模式。因为模式是无限的物理约束是有限的把约束想清楚方案自然就收敛了。希望帮到你。本文还有配套的精品资源点击获取 
长河君 · 2026/11/3 10:58:00 · 阅读 1.2k 华为云Stack四层架构、一云多芯与云网络灾备分级实践
简介面向华为 HCIE-Cloud Computing V3.0 认证备考者与云计算从业人员的培训教材围绕华为云Stack解决方案与政企上云知识体系组织内容适合需要系统理解认证考点和典型行业场景的学习者。压缩包内含 1 个 PDF 文件大小约 32.05MB便于集中阅读、离线查阅和按章节复习。目前已有 175 人学习。教材从云计算发展背景切入介绍华为云Stack的定位、整体架构与高阶云服务并围绕基础设施云化、应用使能、数据使能、统一管理四条主线展开结合数字经济、行业数字化转型与政企智能升级需求说明平台在合规部署、平滑上云和云上创新中的支撑作用。读者可据此建立解决方案的全局认识对照考纲梳理架构层次与关键能力并在备考和实际项目理解中查漏补缺。1. 一朵政企云的门槛不在虚拟化而在管理面和业务面能不能切开把服务器虚拟化、再发几台虚拟机出去这件事开源方案半小时就能跑通。真正卡住政企上云进度的从来不是 KVM 能不能起来而是另外三件事必须同时成立几十种异构硬件能被同一套调度吃掉多租户之间的网络该通的通、该断的断以及任意一个部件挂掉时业务还能在分钟级爬起来。HCIE-Cloud Computing V3.0 这份华为云Stack 培训教材反复在讲的其实就是这三件事的实现路径而不是产品清单。云计算在政企场景里最容易被低估的一点是它首先是一套隔离与边界的工程其次才是一套资源池的工程。教材里 12 类 80 云服务的背后真正的硬骨头是四层架构怎么切、管理面往哪放、网络在哪一层做策略、灾备在哪一层做切换。把这几个边界想清楚再看那些云服务名字就不再是一张背不完的表。2. 四层架构与分区部署ManageOne 为什么必须站在最外层华为云Stack 的系统整体架构被切成四层这个切法不是按功能归类来的而是按变化频率和信任边界来的。基础设施层收敛硬件差异资源池层把硬件翻译成可调度的资源云服务层把这些资源包装成有 SLA 的服务展现层则是唯一面向人的出口。层次越往下变更越慢、越重越往上迭代越快、越轻。2.1 四层各自负责什么边界划在哪里最底下是基础设施层适配多元算力支持 X86、鲲鹏、飞腾、海光四种 CPU 架构支持 GPU支持分布式存储与集中式存储、交换机、负载均衡器、防火墙。这一层的职责只有一个把物理世界的差异吸干让上面看到的永远是一类资源而不是某个型号的机器。第二层是资源池层教材的原话是通过云平台系统软件实现硬件资源池的使能和操作。注意使能和操作是两个动作——使能是把裸硬件变成受管资源操作是对受管资源做生命周期管理。这一层分别实现了 IaaS 的资源控制、容灾备份的资源控制、大数据与数仓的资源控制。也就是说容灾不是云服务层临时拼出来的功能它在资源池层就已经有独立的控制通路这也是后面 RPO0 能成立的前提。第三层是云服务层构筑 Service 能力实现云服务的使能和管控。ECS、EVS、VPC、CCE、OBS、CloudDNS、EIP、QoS 这些 IaaS 服务EI、PaaS、数据库、安全、ROMA 这些高阶服务都落在这一层。第四层是展现层ManageOne 是租户与运营运维的统一入口。提示判断一个云平台是否分层最简单的办法是看它换一款 CPU 或换一款存储时需要改动到第几层。如果改一层就够分层是真的如果要连服务层一起改那只是画了个分层图。2.2 ManageOne 为什么站在最外层而不是塞进服务层ManageOne 的职责有两块教材写得很清楚一是云服务的运营集成能力通过 Console Home 集成各云服务 Console给用户统一的云服务使用界面入口二是云平台的系统级运维能力实现对云服务端到端的监控监控对象包括云服务自身、租户资源和云服务所依赖的基础设施计算、存储、网络并基于这些监控与告警数据提供报表、大屏以及高级运维数据分析能力。把这一层独立出来、并且放在最外面解决的是一个很现实的问题云服务是不断新增的如果每个新服务都自带一套登录、鉴权、计费、告警界面运维人员的工作量会随服务数量线性增长。Console Home 集成各云服务 Console意味着新增一个服务只需要接入这套框架而不是重新造一套门户。这跟浏览器插件模型是一个思路——宿主提供容器和权限插件只提供内容。2.3 Global 与 Region 融合部署时的分区逻辑真正体现设计功力的是部署架构。在 HCS Global 与 Region 融合部署场景下Global 组件管理面与 Region 组件管理面部署在同一个 OpenStack 资源池内但按不同的业务特性部署在不同的网络区域内。这句话的含金量在于物理上共用一套资源池逻辑上必须按信任等级切开。DMZ 区部署 LVS、Nginx 等组件还有 HAproxy、DNS、NTP、API 网关、应用发布这些对外入口类组件External_OM 区部署运营运维服务、高阶服务、基础服务、跨云管理服务OM_Service 区部署远程接入组件包括堡垒机、前置服务器、升级代理、部署代理再往下是计算-管理下沉区部署高阶服务管理面计算-租户区部署计算 AZKVM/BMS网络区部署网络节点与网元BR/vRouter存储区部署块存储和对象存储。整体上还有可信区与半可信区的划分DGC、ISAP、ModelArts、DevCloud 这类数据与 AI 相关的服务落在更靠内的位置。这里有个容易被忽略的设计计算-管理下沉区单独存在。高阶服务比如数据库服务、大数据服务自身也需要算力如果把这些管理面算力放进租户 AZ就会带来两个问题——占用租户可售容量以及管理面与租户流量混在一张网里。管理下沉区的本质是把平台自己用的资源和卖给租户的资源在拓扑上分开这样租户看到的 AZ 容量是干净的平台扩容管理面也不会影响租户配额。用 OpenStack 原生命令可以直观看到 AZ 与主机聚合的对应关系这也是后续排查虚机为什么落在这台机器上的起点# 载入管理面凭据变量字段以现场实际为准 export OS_AUTH_URL管理面Endpoint export OS_USERNAME管理员账号 export OS_PASSWORD口令 export OS_PROJECT_NAMEservice export OS_USER_DOMAIN_NAMEDefault # 列出可用分区AZ 决定了一台虚机能落在哪一类硬件上 openstack availability zone list --long # 查看主机聚合aggregate 是把特性相同的主机聚成一组的手段 # metadata 里通常写着 cpu_arch、是否支持绑核、是否 GPU 节点等信息 openstack aggregate list --long openstack aggregate show 聚合组名availability zone list --long输出里的Hosts字段告诉你这个 AZ 由哪些计算节点组成openstack aggregate show的properties字段告诉你调度器靠什么把规格和主机匹配起来。后面所有关于一云多芯的讨论落地点都是这两条命令的输出。3. 一云多芯X86 与鲲鹏凭什么能在同一朵云里各干各的活教材里 HCS 8.1.1 把一云多芯列为云底座的第一条能力组合鲲鹏、X86、海光、飞腾多种 CPU 架构基础设施提供灵活的混合部署管理能力结合多种算力优势提供 KVM 虚拟化、BMS 等基础实例以及 GPU、NPU 等 AI 场景实例。这段话听起来像宣传语但它背后有一堆不解决就跑不起来的工程问题。3.1 能装上去和能被调度吃掉是两回事把一台鲲鹏服务器纳管进 OpenStack技术上只是加一个 nova-compute 节点。但真正的一云多芯要求是一个租户在同一个 VPC 里可以既有跑在 X86 上的虚机也有跑在 ARM 上的虚机两者之间二层互通安全组策略一致镜像和规格各自匹配计费口径统一。这就要求调度层能识别架构差异而不是让用户自己去猜。教材给出的落地形态是 AZ 划分AZ1-x86 资源池、AZ2-ARM 资源池、AZ3-裸金属资源池各自挂载对应的计算资源池KVM 主机组、裸金属。资源池的形态还不止虚机——虚拟化资源池、BMS 资源池、GPU 资源池、容器资源池、Hadoop 资源池并存用户无需关心真实物理硬件的类型和位置只按需向资源池提出诉求。这条用户无需关心是有代价的调度器必须能在发放阶段完成一次过滤。下面这段代码还原了这个过滤链的核心逻辑它解释了为什么规格里必须带架构信息# 调度过滤链的简化还原一台虚机最终落在哪个 AZ取决于规格与主机聚合的匹配 def filter_hosts(flavor, aggregates, hosts): candidates [] for host in hosts: agg aggregates.get(host[aggregate]) if agg is None: continue # 1) 架构必须匹配规格里声明 arm64就不能落到 x86 聚合组 if flavor[arch] ! agg[metadata].get(cpu_arch): continue # 2) 特性必须匹配需要 GPU / NPU / 绑核 / 大页的规格落到不支持的主机就是发放失败 required set(flavor.get(traits, [])) if not required.issubset(set(agg[metadata].get(traits, []))): continue # 3) 容量过滤预留水位避免把一台宿主机压到无法做 HA 切换 if host[free_vcpu] flavor[vcpus] * 1.2: continue if host[free_mem_mb] flavor[ram_mb] * 1.2: continue candidates.append(host[name]) return candidates aggregates { agg-arm: {metadata: {cpu_arch: arm64, traits: [npu]}}, agg-x86: {metadata: {cpu_arch: x86_64, traits: [gpu, hugepage]}}, } hosts [ {name: compute-arm-01, aggregate: agg-arm, free_vcpu: 64, free_mem_mb: 262144}, {name: compute-x86-01, aggregate: agg-x86, free_vcpu: 12, free_mem_mb: 32768}, ] # 一个 8 核 32G、需要 NPU 的规格只可能落在 ARM 聚合组里 print(filter_hosts({arch: arm64, vcpus: 8, ram_mb: 32768, traits: [npu]}, aggregates, hosts))这段逻辑里三个过滤条件对应三类真实故障架构不匹配会直接报镜像无法启动同一份 qcow2 镜像通常不能跨架构跑特性不匹配会在发放成功之后才暴露性能问题比如该绑核的没绑核、该用大页的走了普通页容量水位不留余量会导致单机故障时 HA 切不走虚机飘不起来。第三条最容易被忽略也最容易在大促或批量上线时炸。3.2 混合部署与保护投资的真实含义教材强调X86、ARM 资源池混合部署保护投资。这句话的实质是政企不会一次性把存量 X86 全部替换掉新采购的 ARM 机器要和旧的 X86 机器在同一朵云里共存若干年。所以多芯能力的关键指标不是支持几种架构而是不同架构的资源能不能被同一套配额、同一套 VPC、同一套运维视图管理。同理异构不只发生在 CPU 上。教材提到管理网络节点支持海光服务器管理网络节点与所有高阶服务支持飞腾 2500、海光 7280/7260 等多款异构服务器管理网络节点和所有高阶服务支持 icelake 服务器GPU 云主机新增支持 A40、A100(40G)。这些细节说明一件事连平台自身的组件也要能在国产化算力上跑否则全栈自主可控只覆盖了租户侧管理面还是个缺口。兼容性清单也是同一逻辑的延伸操作系统层面与 CentOS、中标麒麟、深度、Ubuntu 做过兼容性验证数据库层面有 MySQL、PostgreSQL、南大通用、达梦中间件有东方通/金蝶编译器与工具链有 GCC、JDK语言覆盖 C、C、Java、Python、Ruby、Go。往上教材提到对接行业合作伙伴超过 50 家、形成行业联合解决方案超过 60 个。这些数字的意义在于一朵云能不能落地取决于存量应用能不能不改代码跑上去而不是取决于架构图画得多漂亮。3.3 多核架构带来的性能增量从哪来教材给了两个性能口径云原生应用业务性能提升 80%基于昇腾的 AI 云服务性能提升 2 倍以上。这两个数字背后的机制不一样。前者主要来自容器化之后减少的虚拟化开销与更细的调度粒度——虚机里跑容器和直接在裸金属上跑容器网络转发路径和中断处理的开销差别很大后者主要来自 NPU 的专用算力与算子库适配通用 CPU 去做矩阵运算是纯粹的浪费。真正值得记住的是资源融合那一层的表述服务化内部把计算、网络、存储资源以虚机、容器、物理机、GPU 加速、AI 加速、高性能卸载转发、普通 IO 转发等形式提供给用户。这里的高性能卸载转发和普通 IO 转发并列出现说明转发路径是可选的——需要极致网络性能的业务比如高性能计算、高频交易类场景走卸载路径普通业务走通用路径。这种同一朵云里两种转发平面并存的设计是资源池层必须承担的复杂度。4. 虚拟网络的四道边界安全组、ACL、Peering、Endpoint 各管一段云网络最让人困惑的不是功能少而是功能太多、每种的生效范围和状态特性都不一样。教材把云内互通拆成七条、云外云间互通拆成四条这十一条能力如果按边界归类其实只有四道实例边界、子网边界、VPC 边界、数据中心边界。搞清哪道边界由谁负责排障时间能省一大半。4.1 实例边界与子网边界安全组和网络 ACL 的分工教材第一条子网内默认二层互通同时提供安全组能力可以基于实例端口边界做安全访问控制。第三条同 VPC 内跨子网默认三层互通同时提供网络 ACL 能力基于子网边界做安全访问控制。两句话点明了本质区别——安全组挂在端口上网络 ACL 挂在子网上。这带来的直接后果是安全组可以做到同一子网里 A 能访问 B、B 不能访问 A这种粒度而网络 ACL 只能做到整个子网进出的流量统一规则子网内部的互访它管不着。常见的实现思路是安全组有状态规则放通入方向之后回程自动放通网络 ACL 无状态进出方向要各自写规则。我一般会这么理解——安全组像每台机器自己的门卫网络 ACL 像楼层的大门楼层门禁不会记得你刚才是不是从这儿出去的。所以只放通一个方向跨子网访问就会变成单向通、回程被丢表现为能连上但没响应。4.2 VPC 边界Peering 配路由Endpoint 不配路由第四条和第五条是容易被混用的两个能力。VPC Peering 用于多部门数据快速共享、跨 VPC 的 VM 互通关键动作是按需配置路由——Peering 只建立了通道路由没配就是黑洞。VPC Endpoint 用于服务安全访问跨 VPC 访问 VM/容器/APIG 等特点是无需配置路由但需要额外配置安全访问控制。这个差异决定了选型如果是两个 VPC 之间大量主机互相访问用 Peering 加路由如果是多个 VPC 集中访问某一个服务典型的是把公共服务集中部署其他 VPC 来调用 Endpoint 更合适因为不需要在每个 VPC 的路由表里维护条目规模上去之后路由条目本身就是运维负担。第六条容易被忽略VPC 内支持精细化路由能力可把业务流量引流至特性云主机如安全软件实现云内流量调度满足第三方安全模块引流诉求。这条能力的存在说明一件事——云平台没有试图把所有安全能力都做进自己肚子里而是留了引流口子让第三方安全虚机能以下一跳的形式插进转发路径。这是很务实的设计取舍。4.3 数据中心边界EIP、NAT、专线、二层桥接、云连接云外与云间互通有四条路径各自解决的问题完全不同# 排查跨 VPC / 跨 Region 不通时的固定动作先看路由再看策略 # 1) 查 VPC 路由表Peering、专线、引流规则最终都体现在这里 openstack router show router-id -f json | jq .routes # 2) 查端口上的安全组绑定确认策略挂在了预期端口上 openstack port show port-id -f json | jq {sg: .security_groups, fixed_ips: .fixed_ips} # 3) 查子网关联的 ACL注意 ACL 无状态进出方向都要有规则 openstack network show network-id -f json | jq .tags第一段命令的输出是排障的分水岭如果有去程路由没回程路由表现是能发出请求、收不到响应和 ACL 只放通单向的现象一模一样但修法完全不同。这也是为什么网络排障必须按边界逐层收敛而不是一上来就抓包。EIP 解决的是内外同时主动访问双向SNAT 解决内网主动访问外网单向出DNAT 解决外网主动访问内网单向入。三者不是替代关系而是三种流量方向模型选错了不是不通而是通得不对——比如本该用 SNAT 的场景配了 EIP虚机直接暴露在公网安全组漏一条规则就是事故。专线解决 VPC 与本地网络互通二层桥接解决传统应用快速上云——本地网络内的应用迁移上云且 IP 保持不变靠的就是二层桥接云连接解决跨 Region 私网互通支持跨 Region 网络互通和跨云 VPC Peering。二层桥接这个能力看着不起眼实际是政企上云的关键一环大量存量系统的配置文件里写死了 IP改 IP 等于改应用二层桥接让这批系统能在不改代码的前提下先上云。4.4 ELB 的 7 层能力为什么单独列一条教材把ELB 服务支持跨云间的负载能力并支持 7 层高级路由单独列出来。7 层路由意味着可以按域名、路径做转发决策而不只是按四元组做四层负载。这在多云/混合云场景下价值很大——同一套域名一部分流量留在本地资源池一部分送到云上靠 7 层规则切分业务侧不用改任何配置。把上面这些能力串起来看会发现一个规律云内互通解决的是隔离前提下的连通云外云间互通解决的是连通前提下的合规。前者防止租户之间串流量后者保证数据该在哪就在哪。这两件事的方向是相反的所以必须用两套机制而不是一套。5. 网络排查从手工 tcpdump 到秒级定界的五条踩坑记录教材对传统排障方式的描述非常直白数据中心网络出现异常时运维人员需要手工登录各个节点上传 TCP DUMP 工具进行命令行抓包抓包完成后下载抓包文件到本地排查操作繁琐、耗时耗力、容易出错当需要在业务流的多个点同时抓包时需要同时操作多个命令行还需要一定的操作能力。这段话描述的是真实痛点不是客套话。5.1 定界的本质是缩小嫌疑范围不是找到根因CloudNetDebug 集了拨测和抓包两个功能用于处理数据中心内可能出现的各种网络问题。通过拨测工具可自动化检测业务网络是否出现断流、是否出现丢包通过抓包功能可实现自动化抓包支持基于业务流的多点协同抓包支持灵活的单点虚拟机网卡抓包和主机网卡抓包。它的四类典型用途教材写得很清楚检测网络断流、丢包问题网络故障时用于定界虚拟网络和物理网络的故障边界自动化定界是哪个网元节点的问题当无法确认是应用还是网络的问题时用于排除网络问题。注意第三条——排除网络问题本身就是一种结论。运维最怕的不是故障而是不知道锅在谁身上应用团队和网络团队互相等对方举证。这套工具在能力上的增量也很具体新增 vpcep、natgw、elb 拨测能力快速定界流量中断点新增 VIP 流量抓包支持 EIP/VPC/DC/VPC-PEERING 等网络流量类型运维场景加固主动链路探测新增 ELB 主动链路持续监测重要流量。拨测覆盖到 vpcep 和 natgw 这两个组件意味着 Endpoint 和 SNAT/DNAT 这两条最容易出问题的路径被纳入了自动检测。5.2 HawkEye Agent 的布点决定了能抓到什么采集侧靠的是 HawkEye Agent部署位置决定了观测视角。教材列出的布点包括CNA计算节点代理、BM裸金属、GW网关、vRouter/软 NAT、EGF/内核态 NAT 网关、UGW/EGF、BR、ELB、EulerOS Endpoint、UGW/EGF Backend。控制侧是拨测抓包 server包含 HkeController、hkeAnalyzer、Redis 主备、GaussDB。通道有四类REST API、RPC 信息查询通道、DB 数据通道、物理网络 ERSPAN。这张布点图解释了一个关键事实抓包不发生在虚机里而发生在虚机所在宿主的 vRouter 上、网关的软 NAT 上、ELB 的转发路径上。这既是能力也是限制——虚机内部协议栈的问题这套工具看不到但虚机之外的每一跳它都能看到。Redis 主备加 GaussDB 的组合说明拨测是有历史数据的不是一次性探测故障复盘时可以回看当时链路状态这一点比事后抓包有价值得多。5.3 五条踩坑记录注意下面五条都按现象 → 原因 → 解决记录前三条是策略类问题后两条是抓包姿势问题。现象跨子网访问能建立连接但收不到响应抓包看到去程报文正常、回程没有。原因网络 ACL 无状态只放通了入方向回程的临时端口被默认规则丢弃同时安全组有状态回程自动放通两套策略状态特性不一致导致误判。解决ACL 进出方向都显式放通排查时先看 ACL 再看安全组顺序反了会绕大弯。现象VPC Peering 建好之后两端虚机互 ping 不通Peering 状态显示正常。原因Peering 只建立通道不自动下发路由两端路由表都缺对方网段。解决两端路由表互指配完之后用openstack router show确认路由条目真的生效而不是只在控制台看到已创建。现象拨测结果显示链路可达业务侧仍然报接口超时。原因拨测验证的是四层可达ELB 后端健康检查失败但前端监听正常四层通、七层挂。解决启用教材里提到的 ELB 主动链路探测把后端健康状态纳入拨测范围同时检查 7 层路由规则是否把流量导到了错误的后端组。现象故障发生时想抓包抓包启动之后故障已经恢复抓到一堆正常报文。原因故障是瞬时抖动人工触发抓包永远慢一步。解决对重要流量常驻主动链路探测靠 GaussDB 里的历史拨测数据做复盘抓包只在复现阶段用多点协同抓包时用五元组对齐各采集点的报文避免拿不同流的包做对比。现象迁移上云后部分老系统连不上数据库网络层看起来全通。原因三层互通要求地址段规划不冲突存量网络与 VPC 网段重叠时会出现路由指向错误表现为时通时不通。解决上云前做网段冲突检查冲突且不能改 IP 的系统走二层桥接这也是教材把二层桥接列为独立能力的现实原因。6. 灾备分级的取舍RPO0 到底是拿什么换来的教材里灾备能力的表述是全地域、全场景、租户自助覆盖本地、同城、异地、两地三中心同城双活同时提供应用级与平台级业务连续性保障支持数据库服务、中间件服务、虚拟机容器等核心组件的双活做到实例级故障自动切换单部件切换后网络 IP 和接入访问方式不变业务完全无感知RPO 等于 0、RTO 分钟级。异地灾备则提供异地应用容灾、异地云主机容灾、异地数据备份。这张分级表把取舍摆得很清楚级别距离典型能力RPO改造代价本地高可用单数据中心虚拟机/容器 HA、云主机与存储备份、数据库与大数据备份取决于备份周期低基本无需改造同城高可用≤100km同城应用双活/容灾、同城大数据容灾、同城数据备份0中需应用支持双活异地灾备100km异地应用容灾、异地云主机容灾、异地数据备份大于 0中高需容灾编排两地三中心跨地域CSHA、CSDR一键式切换同城 0、异地大于 0高但业务无需改造RPO0 的来源是同步复制而同步复制受光传输时延约束所以同城的距离被限定在 100 公里这个量级超过这个距离只能走异步RPO 必然大于 0。这不是产品能力问题是物理问题。教材里支持 0-1、1-N 的容灾数据中心叠加单 AZ 到双 AZ 的 CSHA 演进这句话实际上是在承认大部分客户不会一步到位建两地三中心而是先单 AZ、再同城双活、最后异地平台必须支持这种渐进式演进。我认为这套设计里最值得琢磨的取舍是业务无改造上云即容灾。要做到业务不改代码就能容灾平台必须在资源池层就把容灾控制通路做进去而不是在应用层加 SDK——这正是第 2 章里资源池层分别实现 IaaS 的资源控制、容灾备份的资源控制那句话的真正含义。代价是平台复杂度大幅上升收益是存量系统不用重写就能获得分钟级 RTO。对于一堆跑了十几年的核心系统这个交换是划算的。另一个取舍是租户自助。统一的容灾管理平台方舟实现一键式容灾切换、降低运维复杂度租户甚至可以定期执行容灾演练。把演练权限交给租户意味着平台要承担租户误操作的风险但换来的是容灾方案真的会被验证——没演练过的容灾方案和没有容灾方案的区别只在于心理安慰。从那以后我每次评估一套云平台的灾备能力都会强制走一遍距离—RPO—改造代价这三个问题而不是先看它支持几种容灾模式。因为模式是无限的物理约束是有限的把约束想清楚方案自然就收敛了。希望帮到你。本文还有配套的精品资源点击获取