1. 课程导入与云网络性能全景

在云数据中心里，网络早已不是“把服务器连起来”的配角，而是决定业务上限的关键资源。Arista 云网络以 EOS（Extensible Operating System）为统一软件底座，配合 7000/7500 系列模块化机箱、7050X/7060X/7280R 等固定式交换机，以及 CloudVision 管理平台，构建出从 Leaf-Spine 到多级 CLOS 的弹性架构。理解这套架构的性能特征，是后续做优化与容量规划的前提。

本课程的核心目标可以概括为三件事：看清瓶颈、算准容量、调优路径。看清瓶颈，意味着能从吞吐、时延、丢包、抖动、利用率五个关键指标中定位问题；算准容量，意味着能根据业务流量模型推算 Spine 上行带宽、Leaf 下行端口数与收敛比；调优路径，意味着能通过 ECMP、QoS、缓冲区、PFC/ECN 等手段让流量走得更快更稳。三者环环相扣，缺一不可。

五个关键指标：性能的“体检表”

云网络的性能不能只看“通不通”，而要看“好不好”。以下五个指标构成了最基础的观测维度：

• 吞吐（Throughput）：单位时间内成功传输的有效数据量，通常以 Gbps 或 pps 衡量。它反映链路与设备的实际承载能力，受端口速率、转发芯片性能、流表规模影响。
• 时延（Latency）：报文从源到目的所经历的时间，包含串行化时延、传播时延、排队时延和转发时延。在 Leaf-Spine 架构中，同 Leaf 内东西向流量通常 2 跳，跨 Leaf 需 4 跳，每跳引入的时延需纳入预算。
• 丢包（Packet Loss）：因缓冲区溢出、链路误码或 ACL 丢弃导致的报文丢失比例。微突发场景下，即使平均利用率不高，瞬时拥塞也可能造成丢包。
• 抖动（Jitter）：时延的变化幅度，对实时音视频、RDMA 等业务尤为敏感。抖动过大往往意味着队列调度或路径选择不稳定。
• 利用率（Utilization）：链路或设备实际承载流量与理论容量的比值。持续高于 70% 即需警惕，高于 85% 则进入高风险区。

这五个指标并非孤立存在。例如，当某条 Spine 上行链路利用率逼近 90% 时，排队时延会非线性上升，进而推高抖动，最终在微突发下触发丢包。因此，容量规划不能只盯单一指标，而要建立联动视角。

从架构到指标：为什么 Leaf-Spine 决定了性能基线

Arista 云网络普遍采用 Leaf-Spine 两级 CLOS 架构。每台 Leaf 下行连接服务器，上行连接所有 Spine；Spine 之间不互联，只负责高速转发。这种设计带来两个直接好处：任意两台服务器之间最多经过 4 跳（Leaf→Spine→Spine→Leaf 在两级架构中实际为 Leaf→Spine→Leaf 共 3 跳，跨 Pod 才需更多跳），且任意一条上行链路故障时，ECMP 可自动将流量切换到剩余链路。

但架构优势不等于性能达标。假设一个 Pod 内有 32 台 Leaf，每台 Leaf 有 32 个 100G 下行端口和 8 个 400G 上行端口。下行总带宽为 32×32×100G = 102.4T，上行总带宽为 32×8×400G = 102.4T，收敛比 1:1。若实际业务流量中东西向占比 70%，则 Spine 层需要承载约 71.7T 的跨 Leaf 流量，此时若只部署 4 台 Spine，每台需承载约 17.9T，接近单台 400G×36 端口的理论上限，风险极高。这就是容量规划要解决的核心问题：用业务流量模型反推架构规模。

本课程学习路径

后续章节将沿着“观测→分析→优化→规划”的路径展开。首先建立性能基线，掌握如何在 EOS 上通过 show interfaces counters、show queue、show platform fap 等命令采集吞吐、丢包、队列深度数据；然后深入时延与抖动分析，理解缓冲区、调度算法、ECN/PFC 对实时业务的影响；接着进入容量规划实战，学习如何根据服务器数量、端口速率、收敛比、超售比计算 Spine 与 Leaf 的选型；最后覆盖 CloudVision 与 Telemetry 的自动化监控，让性能优化从“救火”变为“预防”。