华为云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和VXLANVLAN大家都很熟12比特的VLAN ID最多4094个可用在一个大二三层网络里给每个租户分一个VLAN显然不够用。VXLAN把二层扩展到了24比特的VNIVXLAN 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目的端口默认是4789VXLAN标准端口但也有版本或配置使用其他端口排查时要注意。DVS的流表里保存了“虚拟机MAC ↔ VNI ↔ 远端VTEP IP”的对应关系。SDN控制器通过BGP EVPN或其他方式把远端MAC/VNI信息同步给每个计算节点上的DVS。在华为云Stack的实际实现里如果你登录计算节点可能会看到类似下面的流表条目示意不要照搬命令# 在计算节点上查看DVS中的流表示意 ovs-appctl dpctl/dump-flows | grep -i nsixxxx # 关注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转换如果虚拟机绑定了弹性公网IPEIP网关节点会把虚拟机私有IP转换成EIP1: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和网络ACLNetwork ACL是控制虚拟机进出流量的两道关卡。安全组绑定在虚拟机的虚拟网卡上在每个计算节点的DVS上生效。无论东西向还是南北向只要流量进出虚拟网卡安全组规则就会匹配执行。网络ACL绑定在子网上作用于子网边界在vRouter转发的路径上生效。所以一个包从外部进入虚拟机实际会经过两道过滤网关节点或物理防火墙如有→ 到达计算节点DVS → 安全组检查放行后才交给虚拟机。如果发现外部访问不通但VPC路由和EIP解析都正常优先检查安全组是否放行了对应端口如果安全组放行了还不通再查网络ACL。注意安全组规则在DVS上以类似流表的形式存在新建规则到生效有一个下发过程。在控制器和计算节点之间的网络有抖动时可能出现规则下发不同步的窗口期表现为“规则加进去了瞬间又能通过一会儿又不行”。这种问题排查起来很耗心力确认控制器与计算节点通信链路稳定是第一优先级。5. 存储与管理流量的“另一条路”流量模型里不可忽略的部分很多人写流量模型只盯租户业务流量但我做交付这些年切身感受是存储流量和管理流量往往更能左右一个云平台的稳定性。这一章把它们单拎出来说。5.1 云硬盘IO流量走向后端存储的专用通道虚拟机使用云硬盘时每一次IO读写都会转化为存储网络上的数据流量。华为云Stack的存储方案分为分布式存储如OceanStor Pacific系列和商业存储SAN/NAS两种。分布式存储场景下计算节点和后端存储节点之间走独立的存储平面。存储平面设计上有几个特点推荐使用独立物理网卡和独立VLAN避免与业务流量争抢带宽。带宽需求往往比业务面还高。例如业务面25GE存储面至少也是25GE如果是全闪分布式存储还会上100GE。存储流量对丢包极其敏感一个微小的丢包会造成严重的时延尖刺。这也是为什么存储面不建议跨多跳网络的原因最好就是计算节点和存储节点直连TORTOR之间再通过大带宽互联。如果你观察到虚拟机云硬盘性能不稳定、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的映射转换。这种场景下流量路径会多一跳而且是必须经过集中网关的一跳VMVXLAN→ 计算节点DVS → VXLAN转发 → 集中网关节点 → VLAN转换 → 物理交换机 → 物理机这类混合转发的流量模型在政务云、金融云中很常见。排障时如果不能识别到中间的转换节点很容易产生“为什么同一个子网内VM通、物理机不通”的疑惑。6. 高可用和故障场景下流量会怎么“漂移”流量模型不仅要懂正常路径更要理解故障切换后的路径变化。下面三种典型场景值得每个运维人员提前心里有数。6.1 集中式网关节点主备切换集中式网关节点通常以主备或集群方式部署。主节点维护NAT会话、外部路由等信息。当主节点故障或主动升级时备节点接管虚拟IPVIP漂移到备节点。切换期间现有NAT会话会中断或重新建立取决于是否配置了会话同步。VXLAN隧道、外部网络路由会重新收敛。虚拟机内部表现为数据面丢包或时延增大持续几秒到几十秒不等。对业务影响最大的是长连接业务如数据库连接池、视频流传输。建议在关键业务接入侧配置连接重试机制避免因为TCP长连接因会话中断而长时间阻塞。6.2 计算节点宕机后的流量重分布某台计算节点宕机其上承载的虚拟机通过HA机制在其他健康节点重建。这个过程中该节点上原本承载的VXLAN隧道流量全部中断。分布式网关在该节点上失效其他节点对目标虚拟机的转发流表会标记为不可达。VM在其他节点启动后SDN控制器会重新下发ARP和路由信息整个恢复周期通常在1~3分钟取决于HA切换策略和物理机启动速度。这时候流量模型会短暂出现“黑洞”现象——包发出去了但流表里没有对应条目。不属于配置错误属于故障迁移过程中的正常窗口。6.3 链路故障与ECMP的重新选路业务平面如果配置了等价多路径ECMP比如计算节点通过双上联连接到两台TOR物理链路中断时流量会自动从另一条路径转发切换时间完全取决于物理网络设备的能力秒级到毫秒级都有。这里想提示大家不要只在云平台侧看冗余物理网络的冗余设计双上联、堆叠/MLAG、ECMP同样影响云平台的流量稳定性。我见过因为TOR堆叠分裂导致整个业务面震荡的案例那个排查过程一言难尽。7. 流量问题排查我自己的一线顺序最后分享一套我实际用了很多年的排查顺序适用于大多数华为云Stack网络问题。它不是教科书流程而是实战中最高效的先后次序。先看监控登录ManageOne或云平台监控界面看虚机网卡出入方向流量、丢包率、时延。这个步骤能快速圈定问题是出在云平台内部还是外部。再看路由进入VPC详情检查子网路由表、VPC路由表确认默认路由和关键路由条目是否缺失或错误。路由配错是头号低级但高频原因。查安全策略查看安全组和网络ACL是否放通了对应IP和端口。有时规则空白比错误更隐蔽。尤其注意安全组规则里隐含的拒绝逻辑。看ARP和MAC表登录计算节点或网关节点查看虚拟机对应的MAC地址表是否学习正常ARP是否解析到了正确的网关MAC。ARP表混乱往往是VXLAN网络内部表项异常的信号。抓包定位在虚拟机内tcpdump抓原始包在计算节点物理网卡上抓VXLAN封装包两相对比就能判断包是在封装前还是封装后丢的。对照物理链路最后如果前面全部正常那问题大概率出在物理网络。联系网络团队检查TOR端口配置、VLAN放通、聚合成员状态。这个顺序背后的原则是先排除配置类问题再查逻辑转发最后才碰物理链路。因为配置类问题占比最高、定位最快而物理链路排查需要跨团队协作放到最后做最有效率。用表格总结一下高频问题的定位方向现象可能原因优先排查方向同子网虚拟机互通时好时坏DVS流表老化/物理链路丢包流表条目、TOR链路误码跨子网不通分布式网关失效/路由缺失VPC路由表、网关节点状态EIP绑定后外部不通NAT表项问题、安全组未放通集中网关NAT会话、安全组云硬盘IOPS抖动存储平面拥塞或丢包存储网络监控、物理链路质量批量创建VM后部分网络不可用管理平面拥塞导致流表下发延迟管理平面负载、控制器状态华为云Stack 8.X的流量模型整体思路是“射程之内皆转发”——能本地完成的二层转发绝不出卡能分布式完成的三层路由绝不绕集中网关但涉及南北向NAT、混合网络转换这类必须中心化处理的场景仍然保留集中节点。这个设计取舍在绝大多数业务场景下是合理的只是需要我们在规划和排障时心里始终挂着这两条线。下一篇我打算针对具体场景拆更细像VPC终端节点、负载均衡器下的流量模型、跨AZ部署时东西向流量的绕行路径这几个主题单独拿出来研究价值都比泛泛而谈大得多。到时候继续聊。这篇文章来自我的实际交付和排障经验整理文中涉及的组件名称和命令在不同版本里可能存在差异但流量模型的分析思路应该是通用的。如果你在实践中有不一样的理解欢迎一起探讨。