企业官网建设流程全解析

开头

刚接手一套华为云Stack 8.X环境的时候，我最头疼的其实不是OpenStack API调不通，也不是租户配额分不匀，而是业务侧报障时我脑子里没有一张清晰的“流量地图”。比如某天业务方跟我说“我们有两台虚拟机之间数据同步特别慢”，你从上到下查了一圈，防火墙没丢包、负载均衡没异常、交换机端口也不拥塞，最后才发现问题出在跨主机虚拟网络的某条封装链路上。这种问题没有三年的排障经验，基本只能瞎猜。

所以这篇文章我就想系统聊聊华为云Stack 8.X的流量模型分析。名字里带了“（一）”，这确实会是一个系列——第一篇先把基础框架讲透：流量模型是什么、为什么要分析、华为云Stack里的网络架构长什么样、几类典型流量路径分别怎么走，以及我在真实环境里怎么用抓包和诊断手段去验证这套模型。适合刚接触华为云Stack的运维/网络工程师，也适合那些已经跑了一段时间、但始终没把网络转发链路彻底理清的同学。

注意：本文基于华为云Stack 8.X的通用网络架构原理和常见运维实践整理，具体命令、界面名称可能因版本和部署形态有差异，思路是通用的。

1. 流量模型分析要解决的核心问题与整体思路

1.1 流量模型到底是个什么东西

流量模型，说白了就是数据包从源到目的地，经过哪条路径、做了几次封装和解封装、在哪些节点经历了什么变换（比如源地址转换、目标地址转换、VXLAN封装），最终到达目标网卡。在传统网络里，路径很直观：交换机、路由器一画，链路一标，ping一下traceroute一下就清楚了。但在云平台这种虚拟化环境里，问题要复杂得多——每个虚拟机的流量先到虚拟交换机，虚拟交换机又要做隧道封装，然后才交给物理网卡发出；对端收到后还要拆封装、查流表、过安全组策略，才最终送到虚拟机。

所以理解流量模型，本质上是在做一件事：把“逻辑上通”和“物理上通”这两件事统一起来。很多时候业务反馈网络不通，不是真的物理链路断了，而是逻辑网络里的路由/安全组/NAT规则出了问题；反过来也有物理链路拥塞、MTU不一致导致大包丢弃，但逻辑网络一切正常的情况。脑子里没有这张完整的“流量地图”，你排障就只是一个一个节点手动敲，浪费时间还容易漏。

1.2 分析流量模型的三个实际用途

第一个用途是排障。这是最直接的。当业务侧反馈“跨可用区互访不通”“虚拟机访问外部应用特别慢”时，如果你能第一时间定位到问题出在哪个转发环节，比在界面上点半天“网络诊断”要高效得多。第二个用途是容量规划。流量模型能告诉你哪个链路是瓶颈，比如某套业务大量走东西向流量，可你监控重点一直放在南北向出口上，那容量规划就做偏了。第三个用途是变更评估。做任何网络变更（比如新加一台计算节点、调整某个VLAN、升级安全组策略）之前，先模拟一下流量路径会不会受影响，能规避掉很多低级故障。

也就是说，流量模型不是一个静止的拓扑图，而是一套判断框架，帮你把故障定位、容量规划、变更风险这三件事都纳入一个统一的视角里。

1.3 这套分析方法的整体框架

我在实际工作中习惯把流量模型拆成三个层面来建立认知：第一层是整体网络拓扑，包括物理网络的接入/汇聚/核心分层，以及业务平面、存储平面、管理平面的划分；第二层是逻辑网络，包括VPC、子网、安全组、NAT网关、负载均衡这些服务在转发链路中的具体位置和作用；第三层才是具体的流量路径，把一、二层串起来，看每一个具体业务场景下的完整数据链路。

后面几节我会沿着这个框架逐步展开。先从网络架构分层说起，这是所有流量路径分析的基础。

2. 华为云Stack 8.X网络架构分层速览

2.1 物理网络：接入、汇聚与核心三层的基本定位

华为云Stack 8.X物理网络规划通常沿用经典的三层结构——接入层、汇聚层、核心层。接入层一般就是TOR（Top of Rack）交换机，直接连接服务器网卡，承担着接入和VLAN透传的工作；汇聚层负责接入层的流量收敛，同时往往是VXLAN隧道的网关所在位置（也可能下移到接入层，取决于组网设计）；核心层则连接各个汇聚设备，承担数据中心内部高速互联的角色。

这里有一个很重要的经验：在分析流量模型之前，一定先把这台环境的物理网络架构图找出来。因为云平台排障经常出现“逻辑路径对，物理路径绕远”的情况。举个例子，如果两台虚拟机分布在两个不同机柜的物理机上，即使它们在同一个VPC、同一个子网，数据包也要从主机A的物理网卡出去，经TOR_A、汇聚、再到TOR_B，最后才到主机B。这个路径和物理拓扑强相关，不存在“虚拟网络可以完全无视物理位置”这种说法。

另外，华为云Stack 8.X为了保证不同业务之间的隔离，通常会规划多个物理网络平面：业务平面承载虚拟机业务流量，存储平面承载云硬盘/对象存储的存储流量，管理平面承载OpenStack各组件之间的管理通信。这三个平面在物理上可以通过VLAN隔离，也可以通过独立网卡/独立交换机物理隔离。理解这一点非常关键，因为排障时你首先要确认问题属于哪个平面。

2.2 逻辑网络：VPC、子网、安全组与网络服务的位置

逻辑网络层是云平台最核心的实现部分。华为云Stack的逻辑网络基于OpenStack Neutron框架做了大量自研改造，但基本概念是相通的。VPC（虚拟私有云）是租户间的隔离域，一个VPC内部可以创建多个子网，子网之间默认三层互通；不同VPC之间默认隔离，需要通过VPC Peering或者路由服务才能互通。

子网是理解流量路径的一个关键边界。在传统网络里，同子网通信走二层，跨子网通信走三层；在云平台里这个逻辑同样成立，但实现方式变成了虚拟交换机上的流表转发。云平台会在虚拟交换机上根据流表直接判断目标IP是否在同一个子网，如果是就直接转发（可能走VXLAN隧道），如果不是就送给分布式虚拟路由器去做三层转发。

安全组是另一个容易把流量模型搞复杂的点。它本质是一个分布式防火墙规则，会在虚拟交换机层面生效。也就是说，即使两台虚拟机在同一个宿主机上、同一个网桥上，流量也会按顺序经过安全组检查。我见过很多新手以为“同物理机通信更安全，不需要检查”，实际完全不是。

此外NAT网关、EIP（弹性公网IP）、负载均衡这些服务也各自在转发链路上占据位置。它们本质上是分布式的组件，会在计算节点内部以特定网络功能的方式承载，而不是像传统网络那样挂在物理链路边上。

2.3 管理面、业务面、存储面三类流量必须分开看

这一点我觉得是华为云Stack流量分析里最容易忽略、也最容易翻车的地方。很多刚开始做云平台运维的同事，一遇到网络问题就盯着业务流量查，却忽视了管理和存储流量对网络的占用。

管理面流量包括OpenStack各组件（比如Nova、Neutron、Cinder）之间的API调用、消息队列通信、数据库同步等。这类流量通常不大，但延迟敏感；一旦延迟过高，可能出现节点心跳超时、服务状态抖动等连锁故障。存储面流量则是云硬盘数据的读写流量，这类流量往往是持续的、大带宽的。在超融合部署形态下，存储流量和业务流量共享物理网络，一到业务高峰期存储流量起来之后，就可能把网络打满，进而拖慢业务流量。

所以分析流量模型时候，我一般先确认“这三类流量中哪一类才是当前问题的焦点”。如果是云硬盘性能差，优先看存储平面；如果是管理面告警频发，优先看管理网络；如果是业务卡顿，才去看业务流量路径。用这种分类方式做初步筛选，能帮我快速缩小排查范围。

3. 四类典型业务流量路径拆解与原理分析

3.1 同宿主机内虚拟机间通信：最短路也有几个暗坑

先看最简单的一种模型：同一个物理机上的两台虚拟机互相通信。这个场景在业务上经常出现，比如数据库和缓存部署在同一个计算节点上，它们之间高频交互。

在这种场景下，数据包从VM1的虚拟网卡（virtio）发出后，进入宿主机上的虚拟交换机（华为云Stack底层常基于Open vSwitch或自研虚拟交换机实现）。虚拟交换机先查流表，发现目标MAC/IP对应的是本宿主机上的另一个虚拟网卡，于是直接通过内部端口转发给VM2，整个过程中数据包不会出物理网卡，也不会做VXLAN封装。

这套流程在逻辑上很简单，但有两个暗坑。第一，安全组检查依然存在——虽然数据没出宿主机，但分布式防火墙仍然会基于安全组策略对流量进行过滤，所以配置了安全组拒绝规则的话，即便物理机上两台虚拟机相邻也无法通信。第二，虚拟交换机本身是消耗CPU资源的，虽然OVS有内核态数据路径（比如Open vSwitch的datapath），但高频的小包通信仍然会占用不少主机CPU。很多人在物理机上做性能测试时发现同主机互访居然有比较明显的时延，原因就在这。

3.2 跨宿主机虚拟机通信：VXLAN封装与MTU问题

跨宿主机的虚拟机通信是最常见的业务流量模型，也是最容易出现疑难杂症的地方。

假设VM1在计算节点A，VM2在计算节点B，两者位于同一个VPC的子网内（VNI一致）。VM1发出的原始数据包到达宿主机A的虚拟交换机后，流表显示目的端口在远端——于是虚拟交换机就把这个以太网帧封装成VXLAN报文，即在外层加一个UDP头（目的端口通常4789）以及VXLAN头，再套上外层IP头和MAC头，然后从宿主机A的物理网卡发出。这个被封装后的报文在物理网络里就是一个普通的UDP报文，经过TOR、汇聚、核心到达宿主机B。宿主机B的虚拟交换机收到后拆掉VXLAN封装还原出原始以太网帧，再通过流表/安全组检查后交给VM2。

因为存在两层报文（内层是虚拟机看到的完整以太网帧，外层是物理网络传输的封装报文），所以整个链路的MTU问题就特别突出。举个例子，物理网络MTU为1500字节，VXLAN封装本身需要额外50字节（外层IP头20 + UDP头8 + VXLAN头8 + 内层以太网头可能有差异），如果虚拟机内部设置网卡MTU也按1500算，那么最大报文长度3000多字节的数据帧经过封装后，外层报文就是1550字节，超过了物理网络1500的MTU限制，就会被分片或者丢弃。分片会导致性能下降，直接丢弃则表现为业务丢包、连接中断。

所以我在做基线检查时，一定会对比虚拟机内网卡的MTU和物理网络的MTU。常见的做法是让虚拟机内部的MTU设置为1450或更小，或者在物理网络上启用不小于1550的巨型帧（jumbo frame）。很多“跨节点通信时通时不通”的问题，最终查下来都是MTU不一致导致的。

3.3 虚拟机访问外部网络：SNAT与EIP的协作过程

南北向流量是另一种常见的流量模型，其中最常见的是虚拟机主动访问外部网络（比如访问外部API服务、下载数据等）。

虚拟机的原始源IP是VPC内部的私有IP，比如192.168.1.10。这个地址在外面不可路由，所以数据包在虚拟交换机里被识别为“需要走NAT网关”。华为云Stack里的NAT网关是基于分布式虚拟路由器（DVR）实现的——注意“分布式”这个关键词，意味着SNAT能力不止在一个集中式网关上，而是在每个计算节点本地就能完成。

数据包到达DVR后，DVR根据NAT网关规则做一次源地址转换（SNAT），把源IP改成NAT网关的公网IP地址，再发给物理网络。返程流量到达NAT网关后，再根据连接跟踪表把目标地址改回私有IP，然后通过VXLAN隧道转发给对应的虚拟机。整个过程对虚拟机来说完全无感——它只知道自己通过“网关”出去了。

这里要特别强调一个排障经验：EIP和SNAT网关并不完全是一回事。EIP是直接把公网IP绑定到虚拟机的虚拟网卡上，流量不用经过NAT网关的SNAT规则；SNAT网关则是多个虚拟机共享一个公网IP去访问外部。如果业务方汇报“外部访问不了我们的服务”，你要先分清是出方向的问题还是入方向的问题，再决定去查EIP绑定状态还是NAT网关规则。

3.4 外部流量进入虚拟机：DNAT、负载均衡与前置安全设备

从外部访问虚拟机（入方向流量）是另一种关键的南北向模型。

最直接的入方向访问方式是给虚拟机绑定EIP。数据包从外部进入，到达华为云Stack的网络边界，在入方向做一次目标地址转换（DNAT），把公网IP转换成虚拟机私有IP，然后封装成VXLAN隧道报文转发到计算节点，最终到达VM。在这种场景下，连接跟踪表非常关键——返程流量必须按照原路径逆向往回走，如果连接跟踪表被刷掉或老化异常，就会表现为“外部能建连，但很快断掉”。

如果业务前面挂了负载均衡（ELB），那么外部流量的目的地其实就是ELB的监听地址，ELB根据后端服务器组把请求分发到具体虚拟机上。这种情况下，流量路径多了一个ELB节点，排查时就要先确认请求是否到达ELB、ELB是否把流量正确分发了，以及后端健康检查是否正常。

华为云Stack还支持在业务流量前部署云防火墙等安全服务，这种情况下流量会先经过防火墙的清洗再进入VPC。虽然多了一层保护，但也意味着一半以上的网络问题都可能在防火墙这一层被引入——比如安全策略放通不全、性能瓶颈在大流量下触发限流。我遇到过一个现场，业务整体很慢，绕了一圈才发现防火墙虚机CPU打满，而不是云平台网络本身有任何问题。

4. 实操经验：抓包与诊断手段怎么用

4.1 抓包位置的选择思路

一个完整的流量分析离不开抓包验证，但抓包位置比抓包工具本身更重要。如果抓包位置选错，抓出来的包没有任何解释力。

拿跨宿主机通信举例，我通常会同时做三处抓包：第一处在VM1内部（源虚拟机），确认数据包确实发出来了；第二处在VM1所在宿主机A的物理网卡（看是否有VXLAN封装后的报文发出）；第三处在VM2所在宿主机B的物理网卡（看是否收到了VXLAN报文）。三个位置一对比，就能很快判断问题在转发链路的前半段还是后半段，或者在中间物理网络。

在华为云Stack的计算节点上，常用的抓包命令是tcpdump。抓物理网卡的时候需要留意，因为物理网卡上同时承载着管理流量、存储流量和业务流量，抓包量可能很大，建议加上过滤条件：

# 在宿主机上看是否收到特定VXLAN封装报文，如果有可以只显示目的端口4789 tcpdump -i eth0 udp port 4789 -nn -vv -s 0

如果要在OVS内部看具体路径，可以使用ovs-appctl和ovs-ofctl系列命令：

# 查看某个虚拟机网卡的ofport编号 ovs-vsctl get Interface vnet0 ofport # 查看对应流表项是否命中 ovs-ofctl dump-flows br-int | grep "in_port=<ofport编号>" | head -20

虚拟机内部抓包相对简单，直接tcpdump在对应网卡上：

tcpdump -i eth0 icmp -nn

4.2 虚拟网络层的流表诊断方法

传统排障习惯是ping一下，通就是通，不通就是不通。但在云平台里，ping不通之后还必须继续细分：是哪一层没通？是ARP解析失败、还是VXLAN隧道没建立、还是安全组拒绝了、还是流表没下发成功？

我经常用的一个招数：先把云平台网络相关的日志节点梳理清楚。Neutron（或华为自研的AC服务）的日志会记录流表下发过程，当你创建一个网络或安全组规则时，实际下发到每个计算节点的流表项是有日志的。如果流表下发失败或者不一致，就会出现“网络配置明明改了，但实际转发不生效”的诡异问题。

如果发现某个虚拟机的流量完全断掉，我会优先检查所在宿主机的虚拟交换机上这个VM对应的端口状态。一个常见故障是VM漂移（热迁移）之后，虚拟交换机上的流表没有同步更新，导致目的VM虽然在新宿主机上，但流表还指向旧宿主机。这种情况从逻辑层面看完全正常，VM状态正常、网络安全组正常，但流量就是不通，只有到虚拟交换机层面检查才能发现。

4.3 一个模拟排查案例：跨主机通信“时通时不通”

最后用一个真实感极强的典型案例把前面的方法串起来。

场景：业务反馈，VPC内两台虚拟机A和B跨宿主机通信，ping偶尔通，偶尔超时。从配置看，安全组已放通所有ICMP流量，VPC、子网配置正常，没有特殊NAT规则。我拿到问题后，按流量模型三步走：

第一步，确认问题确实发生在A到B方向。在VM_A内部连续ping VM_B，同时开启tcpdump：

# VM_A内：持续ping，并同时抓包 ping -c 100 10.0.1.20 tcpdump -i eth0 icmp -nn -c 50

发现ping的丢包率和抓包结果吻合，说明问题不在VM_A自身处理，报文确实发出去了。

第二步，在宿主机A的物理网卡上抓包（外层网卡）看VXLAN封装报文是否出去。如果能抓到封装报文，说明VM_A侧虚拟交换机处理正常——流表命中、封装没有问题。然后去宿主机B的物理网卡抓包，看外层VXLAN报文是否到达。如果B侧物理网卡没有抓到任何封装报文，问题大概率在中间物理网络。

第三步，到宿主机B的虚拟交换机内部查流表和使用ovs-appctl。我实际操作中遇到过一种经典情况：物理网络一切正常，VXLAN报文也到了宿主机B的物理网卡，但宿主机B的虚拟交换机关联的隧道端口异常，导致报文无法正确送到VM_B。为什么是“时通时不通”？因为隧道端口异常前，还有一部分老连接/老ARP缓存有效，所以偶尔能通；缓存老化后，新连接就建不起来了。

最终排查发现，是宿主机B的OVS隧道端口所在的物理链路出现了拥塞——虽然同一块物理网卡上承载了存储流量和业务流量，平时压力不大，但存储备份任务一启动，业务链路的时延就会变高，在VXLAN隧道这种对时延敏感的路径上就容易出现偶发丢包。把存储流量调整到独立网卡后，问题彻底解决。

这个案例说明了两个问题：一是流量模型分析必须涉及物理层和虚拟层两层视角；二是永远不要忽略“同一物理资源承载了多种类型流量”这个前提，这往往是隐蔽瓶颈的来源。

5. 常见问题与排查技巧速查

5.1 流量模型相关问题排查速查表

我把日常工作中遇到的高频问题整理成一个速查表，供参考：

5.2 三个亲测有效的避坑经验

第一个经验：抓包一定要统一时间基准。排障时我在多台宿主机上同时抓包，如果时间不同步，对比起来会非常痛苦。建议提前在所有计算节点和管理节点上配置好NTP时间同步，并且在抓包时用-ttt等参数记录相对时间戳，这样定位“报文是否在同一个时间窗口内”会容易很多。

第二个经验：变更前先做基线记录。流量模型不是等到故障发生才去分析的，系统正常运行时就要记录一套基准数据——比如关键路径的时延、某条VXLAN隧道的丢包率、控制节点与计算节点之间的API响应时间。出问题后再和基线对比，能快速看出是哪段链路发生了劣化。我在每次网络变更（升级补丁、调整MTU、扩容计算节点）前后都会做一次基线测量，这也是避免变更引入隐性问题的有效手段。

第三个经验：多用“最小化复现”的方法验证流量模型。当环境里跑着几十个租户、几百台虚拟机时，直接分析问题流量很困难。我会先缩小区间——创建一个临时的测试VPC、起两台测试虚拟机，手动复现业务方描述的流量特征，然后在只有这两台VM的“干净环境”里做抓包和流表分析，这样大概率能快速定位问题。等模型验证通了，再回头分析生产环境，思路会清晰得多。

写在最后的一点体会

流量模型分析这个事，说难也难，说简单也简单。难在它要求你脑子里同时装着物理拓扑、逻辑拓扑和转发实现三套体系；简单在只要你把前几节讲的基础框架吃透，后续所有排障都只是在往这个框架里套场景。我自己刚接触华为云Stack那段时间，遇到问题第一反应就是查告警、看监控面板，但后来发现，很多“疑难杂症”如果你能提前画出流量路径图，就能在10分钟内锁定大致方向，再结合抓包验证，基本都能定位。

这一篇先到这里。后续我会继续写第二篇和第三篇，重点拆解更细的场景：比如VPC Peering、专线接入、IPv6双栈、负载均衡前挂防火墙等复杂组网下的流量模型，以及更深入的OVS流表分析和性能调优实操。如果你在华为云Stack排障中也遇到过典型的流量问题，欢迎带着场景来交流，我们一起把流量模型这张图拼完整。