企业官网建设流程全解析

华为云Stack 8.X 系列我开始写流量模型分析，说实话这个题目有点大。8.X版本的网络架构延续了华为云Stack一贯的Overlay思想，但和早期的FusionSphere OpenStack版本相比，在网关部署、分布式路由、服务链挂载这些细节上变化不小。我写这篇的主要目的，是帮那些拿到架构图却依然搞不清“虚拟机里的一个包到底走到哪、经过谁、在哪封装、在哪解封装”的运维和交付兄弟们，把整条链路撸顺。第一篇先聚焦最基础的转发面和控制面逻辑，把几个关键流量的走向讲透。

1. 先搞清楚平面划分：流量模型的前提是分清那几个“口子”

很多人一上来就盯着VPC、VXLAN、vRouter这些逻辑概念，结果越看越晕。我的习惯是反着来，先看物理网络和计算节点上到底铺了几根网线、几个网口、打了哪些VLAN。物理拓扑才是流量模型的骨架，逻辑网络全部是附着在物理链路上的肉。

华为云Stack的典型物理规划里，计算节点和管理节点上至少会区分这几个平面：

• 管理平面（Management Plane）：承载云平台管理组件之间的通信，比如CPS、IAM、各类控制器和计算节点的管理通道。这个平面通常要求稳定、低延迟，但不承载租户业务大流量。
• 内部通信平面（Internal Base Plane）：以前的一些版本也叫内网平面，用来承载虚拟机之间的东西向流量、DHCP/元数据服务流量等。在部分部署里，它和业务平面共用，但8.X推荐的分法里还是建议单独规划，避免内部服务流量干扰租户大流量。
• 业务平面（Tenant/Data Plane）：承载租户虚拟机实际业务流量的平面，VXLAN隧道物理上就跑在这个平面。这也是我们分析流量模型时最关注的一条路。
• 存储平面（Storage Plane）：用于计算节点和后端存储（分布式存储或商业存储阵列）之间的数据通信，比如云硬盘的IO流量、备份流量、镜像下载流量。这个平面上流量特征是“大块连续、长期占用带宽”，如果跟业务平面混跑，很容易出现拥塞。

还有一个带外管理平面（BMC），用于硬件级别的远程管理，和云平台流量模型基本无关，这里不展开。

8.X版本的部署工具里，网络平面规划通常在“AZ配置”环节完成，每个平面都会绑定到具体的物理网卡或网卡bond上。我所见到比较稳妥的做法是：业务平面至少使用2张10GE/25GE网卡做bond，存储平面单独使用2张网卡，管理平面使用2张GE/10GE网卡。如果服务器网口有限，至少也要把存储和管理分开，业务和管理可以视规模合并，但我不建议在超过20台计算节点的环境里合并——云平台管理组件的抖动会直接影响业务转发。

每个平面在网络设备上对应独立的VLAN或VLAN段，计算节点上看到的通常是类似这样的配置（不同版本稍有差异，以实际为准）：

# 查看计算节点的网络配置（示意） ip -d link show bond0 # 业务平面bond，成员网卡为eth0/eth1，主备或负载均衡模式

这里插一句非常重要的经验：平面划分不清晰是后续流量排查最大的坑。我接手过好几个现场问题，虚拟机之间延迟高、云硬盘IO不稳定，最后查下来全是存储流量把业务平面带宽打满了，原因就是部署时存储平面和业务平面共用了一组物理网卡。所以做流量模型分析的第一步，永远不是看vRouter，而是打开网络规划表，确认这几个平面在每一台节点上走的哪个物理口、哪个VLAN。

2. 逻辑网络再梳理一遍：VPC、子网、VXLAN、网关之间的关系

物理平面搞清楚之后，再看逻辑网络就会轻松很多。华为云Stack的逻辑网络模型和开源Neutron一脉相承，但做了不少产品化封装。我们先理清几个最基本的概念。

2.1 VPC和子网

VPC（虚拟私有云）是一个租户级的隔离网络空间，里面可以创建多个子网。子网本质上是一个三层网段，比如192.168.1.0/24。同一个VPC内的子网默认可以通过vRouter互通，不同VPC之间默认隔离，需要通过对等连接、云连接等方式打通。

这个模型和传统物理网络的区别在于：传统网络里两个VLAN间的路由靠交换机的三层接口或防火墙，而云平台里这个“路由”被抽象成了虚拟路由器（vRouter）。vRouter不是一个独立硬件设备，它要么跑在专门的网络节点上，要么分布跑在每个计算节点上。这一点是理解华为云Stack流量模型的核心。

2.2 VLAN和VXLAN

VLAN大家都很熟，12比特的VLAN ID，最多4094个可用，在一个大二三层网络里给每个租户分一个VLAN显然不够用。VXLAN把二层扩展到了24比特的VNI（VXLAN Network Identifier），支持1600万个租户网络，并且通过UDP封装让二层报文可以跨三层IP网络传输，这正好解决了云平台大二层和租户隔离的需求。

所以华为云Stack里租户网络默认走VXLAN overlay模式。计算节点上的分布式虚拟交换机（DVS）负责完成VLAN到VXLAN的映射和封装解封装。外部网络、管理网络等特定场景才会继续使用传统的VLAN模式。

2.3 集中式网关与分布式网关的本质区别

这是流量模型里最需要拎清楚的一点。网关负责子网跨网段路由、南北向NAT、安全策略下发等动作。

• 集中式网关：网关实例只部署在少数几个网络节点或网关节点上。所有跨子网流量、出VPC流量都要绕行到这些节点。优点是网关状态集中、策略管控方便；缺点是东西向跨子网流量会绕路，延迟增加，且集中节点容易成为瓶颈。
• 分布式网关：每个计算节点上都运行网关实例（DVS内置的分布式路由能力）。同一VPC内跨子网的流量，可以做到从源计算节点直接转发到目的计算节点，不用再绕到集中网关节点。这极大优化了东西向流量的转发路径。

华为云Stack 8.X在新建VPC网络时，默认会启用分布式网关能力，这是和早期版本一个明显差异。但也别以为有了分布式网关就万事大吉——南北向流量（虚拟机访问外部网络或外部访问虚拟机）以及EIP、SNAT、DNAT这些NAT功能，仍然依赖集中式网关节点。具体见后面第4章。

为了后面描述方便，我先给出一张逻辑上需要注意的拓扑要素清单：

• 租户虚拟机：业务流量的源和目的
• 分布式虚拟交换机（DVS）：计算节点上的虚拟交换层，负责VXLAN封装、流表匹配、安全组执行
• vRouter（分布式网关/集中式网关）：三层路由和NAT执行点
• SDN控制器集群：负责下发流表、路由表，不直接参与数据面转发
• 外部网络：物理网络侧的三层网关或专线出口

提示：在分析流量模型时，建议始终带着一个问题——“当前这条路径，参与数据转发的组件有哪些？控制面有没有参与？”如果控制面参与每个包的转发，那性能必然大打折扣。华为云Stack数据面默认是纯转发，控制面只在连接建立、路由变化时下发表项。

3. 东西向流量路径拆解：同子网和跨子网根本不是一回事

东西向流量指VPC内部虚拟机之间的通信。这是云环境里占比最大的流量类型，尤其是大数据、微服务这类应用。我们分两种场景仔细拆。

3.1 同一子网内两台虚拟机的通信路径

同一子网内的通信属于二层通信，不需要经过网关。两台虚拟机如果落在同一个计算节点上，流量路径最简洁：

VM_A (eth0) → DVS本地转发 → VM_B (eth0)

这种流量甚至不出物理网卡，直接在节点内部的虚拟交换机上就完成了，延迟极低。这也是云平台虚拟机密度提升后性能依然能保持的重要保障。

如果两台虚拟机落在不同计算节点上，路径就变成了：

VM_A → DVS_A（查询流表，判断目的MAC在远端节点）→ VXLAN封装（增加UDP头+外部IP头）→ 通过业务平面物理网卡发出 → 物理网络（TOR/汇聚交换机）→ 计算节点B的物理网卡 → DVS_B解封装 → VM_B

注意几个技术细节：

• VXLAN封装后的外部IP头，源地址是计算节点A的业务平面IP，目的地址是计算节点B的业务平面IP。这部分IP地址规划在部署阶段就确定了，和租户虚拟机自身的IP无关。
• 外层UDP目的端口默认是4789（VXLAN标准端口），但也有版本或配置使用其他端口，排查时要注意。
• DVS的流表里保存了“虚拟机MAC ↔ VNI ↔ 远端VTEP IP”的对应关系。SDN控制器通过BGP EVPN或其他方式把远端MAC/VNI信息同步给每个计算节点上的DVS。

在华为云Stack的实际实现里，如果你登录计算节点，可能会看到类似下面的流表条目（示意，不要照搬命令）：

# 在计算节点上查看DVS中的流表（示意） ovs-appctl dpctl/dump-flows | grep -i "nsi=xxxx" # 关注in_port、dl_dst、tun_id、actions字段，就能还原出转发路径

排查建议：如果你怀疑同子网东西向流量有问题（比如丢包、延迟高），第一件事是确认两端虚拟机在哪个计算节点上，然后直接在计算节点上看物理网卡上的流量。要么抓包看VXLAN封装后的包，要么看DVS流表有没有对应条目。这里有一个重要经验：在虚拟机内部tcpdump只能看到原始报文，看不到VXLAN封装；必须在计算节点的物理网卡上抓包，才能看到完整的VXLAN报文。别搞混了。

3.2 同VPC跨子网的通信路径：分布式网关的关键场景

跨子网通信属于三层路由，必须经过网关。在分布式网关模式下，这个网关就运行在源端计算节点上，转发路径如下：

VM_A (10.0.1.2/24) → 发现目的IP (10.0.2.3) 不在本子网 → 发往默认网关（vRouter分布式网关，即本节点DVS内置路由）→ vRouter查路由表，命中10.0.2.0/24子网 → 下一跳为VM_B所在的计算节点B的VTEP IP → VXLAN封装后从业务平面发出 → 计算节点B解封装 → VM_B

关键点在于：源计算节点上的vRouter直接完成了路由决策，而不再把流量先发到某个中心网关节点。这意味着即使VM_A在节点A、VM_B在节点B，流量也只需要经过“A到B”这一跳物理链路，绕行路径被压缩到最短。

但这里有个容易被忽略的细节：分布式网关虽然处理了转发，但ARP学习、路由表下发仍然依赖控制面。跨子网通信时，源VM要发送到网关MAC，这个网关MAC在分布式网关模式下是所有计算节点共享的（同一个VPC的同一个子网在所有计算节点上看到的网关MAC一致）。这个一致性由SDN控制器保证。

如果你在实际环境中发现跨子网通信时流量都跑到了集中式网关节点（怎么判断？看网关节点的网卡流量和CPU），那大概率是分布式网关配置没有生效，或者VPC网络被强制关掉了分布式路由能力。这种情况在混合部署了老版本网络的场景下尤其常见——同一个租户VPC里既有8.X新建的子网，也有历史版本迁移过来的子网，后者的网关行为可能还是集中式的。

3.3 不同VPC之间的互通：为什么要绕一次“外部”

不同VPC之间默认隔离，如果想互通，通常用VPC对等连接。在华为云Stack上，VPC对等连接实现后，流量会通过vRouter转发到对端VPC，但这里要注意：对等连接是支持跨节点直接转发的，还是必须经过集中网关？我的经验是在8.X版本中，对等连接如果配了路由，流量路径会走源端分布式网关直连目标VPC所在节点，效果相当于扩大的子网路由；但如果对等连接关联了中心化服务（比如通过云防火墙或安全服务进行流量审计），流量就必须被引流到服务链上，路径就会变长。

所以每次做流量分析前，先看看VPC的路由表里有哪些路由条目，特别是是否有指向服务链或外部网络的默认路由，这直接决定了流量会不会绕路。

4. 南北向流量路径拆解：从VM到外部网络的完整链路

南北向流量是第二个大头，也是容易出问题的地方。这里说的外部网络，包括物理网络里的其他服务器、专线对端、Internet出口等所有不在VPC内的网络。

4.1 虚拟机主动访问外部网络

虚拟机访问外部网络的默认路径：VM发出的包目的IP不在VPC子网内，vRouter收到后查路由表，如果VPC有到外部网络的默认路由（通常指向集中式网关节点），流量就会被引到集中式网关节点，再由网关节点交给物理网络设备（一般是防火墙或核心交换机），最终到达目的地。

在这个过程里，通常还会伴随着NAT转换：

• 如果虚拟机绑定了弹性公网IP（EIP），网关节点会把虚拟机私有IP转换成EIP（1:1 NAT），外部网络看到的是EIP地址。
• 如果多个虚拟机共享一个EIP实现上网（SNAT场景），网关节点会把源IP转换成EIP并记录会话表，回程流量根据会话表还原。

具体路径示意：

VM_A (10.0.1.2) → 分布式网关（查路由，发现目的在公网）→ 引流到集中式网关节点 → NAT（源IP转为EIP） → 物理防火墙 → 外部网络

4.2 外部网络主动访问虚拟机（入方向）

外部访问绑定EIP的虚拟机，流量进入路径：外部网络 → 物理防火墙/核心交换机 → 集中式网关节点（目的IP为EIP，网关节点做DNAT，转换为虚拟机私有IP）→ 根据路由和VXLAN隧道转发到虚拟机所在计算节点 → DVS解封装 → VM。

这个过程有一个关键点：集中式网关上必须存在对应的DNAT规则和会话表。如果DNAT表项没有正确下发或老化，外部访问就会不通。我在排障时经常遇到的情况是：EIP绑定正常、安全组放通正常、VPC路由正确，但外部就是访问不了，最后发现是集中式网关节点上的NAT会话被异常清理了，重启相关网络服务后恢复。

4.3 EIP/SNAT/DNAT到底在哪儿执行

这是很多人含糊的地方。明确一下：EIP的1:1 NAT、SNAT、DNAT这些功能，在华为云Stack 8.X中默认由**集中式网关节点（或专门的网关节点集群）**执行，而不是在每个计算节点上执行。分布式网关解决的是东西向跨子网路由问题，NAT功能目前仍集中处理。

这一个结论引出三个实际后果：

• 南北向流量即使东西向走分布式网关省了路，到集中式网关这一段仍然可能成为瓶颈。如果业务以南北向大流量为主，要对网关节点做充分的资源和带宽规划。
• 网关节点主备切换时，南北向流量会短暂中断（几秒到几十秒），NAT会话表能否热迁移直接决定了中断时长。
• 排查EIP问题时，登录集中式网关节点查看NAT转换状态，是最高效的手段。

4.4 安全组和ACL在路径上作用于哪个位置

安全组（Security Group）和网络ACL（Network ACL）是控制虚拟机进出流量的两道关卡。

• 安全组：绑定在虚拟机的虚拟网卡上，在每个计算节点的DVS上生效。无论东西向还是南北向，只要流量进出虚拟网卡，安全组规则就会匹配执行。
• 网络ACL：绑定在子网上，作用于子网边界，在vRouter转发的路径上生效。

所以一个包从外部进入虚拟机，实际会经过两道过滤：网关节点或物理防火墙（如有）→ 到达计算节点DVS → 安全组检查放行后才交给虚拟机。如果发现外部访问不通，但VPC路由和EIP解析都正常，优先检查安全组是否放行了对应端口；如果安全组放行了还不通，再查网络ACL。

注意：安全组规则在DVS上以类似流表的形式存在，新建规则到生效有一个下发过程。在控制器和计算节点之间的网络有抖动时，可能出现规则下发不同步的窗口期，表现为“规则加进去了，瞬间又能通，过一会儿又不行”。这种问题排查起来很耗心力，确认控制器与计算节点通信链路稳定是第一优先级。

5. 存储与管理流量的“另一条路”：流量模型里不可忽略的部分

很多人写流量模型只盯租户业务流量，但我做交付这些年，切身感受是存储流量和管理流量往往更能左右一个云平台的稳定性。这一章把它们单拎出来说。

5.1 云硬盘IO流量：走向后端存储的专用通道

虚拟机使用云硬盘时，每一次IO读写都会转化为存储网络上的数据流量。华为云Stack的存储方案分为分布式存储（如OceanStor Pacific系列）和商业存储（SAN/NAS）两种。

分布式存储场景下，计算节点和后端存储节点之间走独立的存储平面。存储平面设计上有几个特点：

• 推荐使用独立物理网卡和独立VLAN，避免与业务流量争抢带宽。
• 带宽需求往往比业务面还高。例如业务面25GE，存储面至少也是25GE，如果是全闪分布式存储，还会上100GE。
• 存储流量对丢包极其敏感，一个微小的丢包会造成严重的时延尖刺。这也是为什么存储面不建议跨多跳网络的原因，最好就是计算节点和存储节点直连TOR，TOR之间再通过大带宽互联。

如果你观察到虚拟机云硬盘性能不稳定、IO时延波动大，第一步不要去看虚拟机内部分区或文件系统，而是先看存储平面的带宽占用和丢包统计。常见问题是存储平面被某些突发任务（如批量创建虚拟机时的镜像克隆、快照删除）打满，导致所有VM的IO都受影响。

5.2 管理组件通信流量：控制面和数据面必须区分对待

管理流量包括：SDN控制器与计算节点DVS之间的表项下发、CPS心跳、OpenStack各服务的API调用、运维通道等。这类流量整体不大，但突发性较强（比如批量创建删除虚拟机、全场网络表项更新时）。

管理流量走管理平面，管理平面在性能上通常不是瓶颈，但在事件风暴时可能出现瞬时拥塞，表现为控制器和计算节点之间的心跳超时、表项下发延迟。所以管理平面虽然是“弱流量”，也不能掉以轻心。建议在交换机侧为管理平面的VLAN配置独立的QoS队列，至少让它和存储流量、业务流量完全隔离。

实操心得：我记得有一次一个批量创建200台VM的任务，导致管理平面拥塞，SDN控制器下发流表延迟，结果创建出来的VM网络不通，恢复后才正常。后来排查抓包发现管理平面和内部通信平面混用了物理网卡。把平面物理隔离后，同样的批量任务再也没出过问题。所以物理隔离永远是网络稳定性的最佳保障，虚拟隔离（VLAN）是退而求其次的方案。

5.3 什么样的场景需要多个VXLAN隧道或叠加网络

在沿用传统物理网络的部署里（比如混合云场景、物理机纳管场景），一个VPC子网可能同时承载虚拟机和物理机，虚拟机走VXLAN，物理机走VLAN，二者之间的通信就需要网关节点做VLAN到VXLAN的映射转换。这种场景下流量路径会多一跳，而且是必须经过集中网关的一跳：

VM（VXLAN）→ 计算节点DVS → VXLAN转发 → 集中网关节点 → VLAN转换 → 物理交换机 → 物理机

这类混合转发的流量模型在政务云、金融云中很常见。排障时如果不能识别到中间的转换节点，很容易产生“为什么同一个子网内VM通、物理机不通”的疑惑。

6. 高可用和故障场景下流量会怎么“漂移”

流量模型不仅要懂正常路径，更要理解故障切换后的路径变化。下面三种典型场景值得每个运维人员提前心里有数。

6.1 集中式网关节点主备切换

集中式网关节点通常以主备或集群方式部署。主节点维护NAT会话、外部路由等信息。当主节点故障或主动升级时，备节点接管，虚拟IP（VIP）漂移到备节点。切换期间：

• 现有NAT会话会中断或重新建立，取决于是否配置了会话同步。
• VXLAN隧道、外部网络路由会重新收敛。
• 虚拟机内部表现为数据面丢包或时延增大，持续几秒到几十秒不等。

对业务影响最大的是长连接业务（如数据库连接池、视频流传输）。建议在关键业务接入侧配置连接重试机制，避免因为TCP长连接因会话中断而长时间阻塞。

6.2 计算节点宕机后的流量重分布

某台计算节点宕机，其上承载的虚拟机通过HA机制在其他健康节点重建。这个过程中：

• 该节点上原本承载的VXLAN隧道流量全部中断。
• 分布式网关在该节点上失效，其他节点对目标虚拟机的转发流表会标记为不可达。
• VM在其他节点启动后，SDN控制器会重新下发ARP和路由信息，整个恢复周期通常在1~3分钟（取决于HA切换策略和物理机启动速度）。

这时候流量模型会短暂出现“黑洞”现象——包发出去了，但流表里没有对应条目。不属于配置错误，属于故障迁移过程中的正常窗口。

6.3 链路故障与ECMP的重新选路

业务平面如果配置了等价多路径（ECMP），比如计算节点通过双上联连接到两台TOR，物理链路中断时，流量会自动从另一条路径转发，切换时间完全取决于物理网络设备的能力，秒级到毫秒级都有。这里想提示大家：不要只在云平台侧看冗余，物理网络的冗余设计（双上联、堆叠/MLAG、ECMP）同样影响云平台的流量稳定性。我见过因为TOR堆叠分裂导致整个业务面震荡的案例，那个排查过程一言难尽。

7. 流量问题排查我自己的一线顺序

最后分享一套我实际用了很多年的排查顺序，适用于大多数华为云Stack网络问题。它不是教科书流程，而是实战中最高效的先后次序。

1. 先看监控：登录ManageOne或云平台监控界面，看虚机网卡出入方向流量、丢包率、时延。这个步骤能快速圈定问题是出在云平台内部还是外部。
2. 再看路由：进入VPC详情，检查子网路由表、VPC路由表，确认默认路由和关键路由条目是否缺失或错误。路由配错是头号低级但高频原因。
3. 查安全策略：查看安全组和网络ACL是否放通了对应IP和端口。有时规则空白比错误更隐蔽。尤其注意安全组规则里隐含的拒绝逻辑。
4. 看ARP和MAC表：登录计算节点或网关节点，查看虚拟机对应的MAC地址表是否学习正常，ARP是否解析到了正确的网关MAC。ARP表混乱往往是VXLAN网络内部表项异常的信号。
5. 抓包定位：在虚拟机内tcpdump抓原始包，在计算节点物理网卡上抓VXLAN封装包，两相对比，就能判断包是在封装前还是封装后丢的。
6. 对照物理链路：最后如果前面全部正常，那问题大概率出在物理网络。联系网络团队检查TOR端口配置、VLAN放通、聚合成员状态。

这个顺序背后的原则是：先排除配置类问题，再查逻辑转发，最后才碰物理链路。因为配置类问题占比最高、定位最快，而物理链路排查需要跨团队协作，放到最后做最有效率。

用表格总结一下高频问题的定位方向：

华为云Stack 8.X的流量模型整体思路是“射程之内皆转发”——能本地完成的二层转发绝不出卡，能分布式完成的三层路由绝不绕集中网关，但涉及南北向NAT、混合网络转换这类必须中心化处理的场景，仍然保留集中节点。这个设计取舍在绝大多数业务场景下是合理的，只是需要我们在规划和排障时心里始终挂着这两条线。

下一篇我打算针对具体场景拆更细，像VPC终端节点、负载均衡器下的流量模型、跨AZ部署时东西向流量的绕行路径，这几个主题单独拿出来研究价值都比泛泛而谈大得多。到时候继续聊。

这篇文章来自我的实际交付和排障经验整理，文中涉及的组件名称和命令在不同版本里可能存在差异，但流量模型的分析思路应该是通用的。如果你在实践中有不一样的理解，欢迎一起探讨。