VL2 — 让一万台服务器像在同一台交换机上

是什么

VL2（Virtual Layer 2）是 Microsoft 2009 年提出的一套数据中心网络架构，让一整个机房上万台服务器看起来像挂在同一台巨型交换机上。

日常类比：以前的机房像多层办公楼——同一层的人聊天很快，跨楼层要排队等电梯（带宽收敛），而且座位号绑死部门（IP 绑位置），换部门就得改名片。VL2 把它改成开放式大厅：任意两个工位之间都有等长的多条小路（多路径等带宽），名片（应用地址）和座位号（物理地址）解耦，搬工位不用改名片。

VL2 是后来 Azure 网络底座的原型，也直接启发了 Google Jupiter、AWS Andromeda 这一代云数据中心网络。

为什么重要

不理解 VL2，下面这些事都说不清：

为什么云厂商敢承诺「VM 随便迁移、IP 不变」——那是 VL2 双地址思想的延续
为什么现代数据中心机房从「树形」变成了「Clos」拓扑——VL2 是把这个搬上工业舞台的关键论文
为什么 VXLAN / NVGRE 这些 overlay 协议会火——VL2 先证明了「L2 语义跑在 L3 上」是可行的
为什么云厂商不再追求买一台「核武器级超级交换机」——VL2 证明便宜的商用交换机堆出来更划算

核心要点

VL2 解决三件事，对应三招：

任意两台服务器之间带宽相等 → Clos 拓扑（折叠胖树）+ Valiant 负载均衡
应用地址不绑物理位置 → 双地址：LA（位置地址）+ AA（应用地址）
替代 ARP 广播风暴 → 集中式 Directory System 查 AA→LA 映射

招式 1：Clos + Valiant 负载均衡

Clos 拓扑长这样（简化）：

      [Intermediate 交换机]  ← 中间层，多台并列
       /  |  \
   [Aggregation 交换机]    ← 汇聚层
       /  |  \
   [ToR 交换机]            ← 接服务器
       /  |  \
    服务器  服务器  服务器

任意两台服务器之间有多条等长的路径。问题来了：怎么在多条路径间分配流量，才不会让某条链路堵车？

Valiant 负载均衡（VLB）的招法：每条流随机挑一台中间交换机「绕一下」再去目的地。这样无论真实流量矩阵长什么样，平均下来每条链路负载都接近均匀。

类比：不管早高峰大家想去哪，先随机分配你去哪个十字路口换乘，整个路网就不会偏堵某一条主干道。

招式 2：双地址（LA / AA）

LA（Locator Address）：基础设施地址，跟物理位置绑定，跑标准路由协议（OSPF）
AA（Application Address）：应用看到的地址，扁平、不绑位置，VM 搬家也不变

服务器之间通信走 IP-in-IP 封装：外层包 LA（路由用），内层包 AA（应用看到的）。物理网络只认 LA，应用只认 AA，互不打扰。

招式 3：Directory System

应用想给某个 AA 发包时，先问 Directory：这个 AA 现在在哪台 LA 上？ Directory 用复制状态机（RSM）保证一致性，替代了原本的 ARP 泛洪。

实践案例

案例 1：Microsoft 真实流量观测

VL2 论文最有价值的部分之一是实测了 Microsoft 生产数据中心的流量画像：

75% 流量是机房内部（server ↔ server），只有 25% 出机房——所以机房内部带宽必须管够
流量矩阵每几分钟就变一次——没法靠静态优化（如手工配 VLAN）
elephant flows 数量少但占大部分流量体积，mice flows 数量多但占连接数大头——意味着随机 hash 大部分时候够用，偶尔撞车

这组数据后来成了所有数据中心网络论文的「标准基线」。

案例 2：ECMP 让 VLB 几乎免费实现

理论上 Valiant 要求随机选中间节点，听起来要写专门的负载均衡器。VL2 的工程巧思是：商用交换机本来就支持 ECMP（Equal-Cost Multi-Path）——多条等价路径自动 hash 选一条。

把 ECMP 配好 + 加一层 IP-in-IP 封装，VLB 就「免费」实现了，不用买特殊设备。这一招让 VL2 真正能落地，而不只是论文上的好主意。

案例 3：VM 迁移不改 IP

一台 VM 原本跑在机架 A 的服务器上，AA = 10.1.1.5，LA = 192.168.1.20
VM 迁移到机架 B 的另一台服务器，AA 保持 10.1.1.5，LA 变成 192.168.5.7
Directory System 更新映射，所有访问 10.1.1.5 的请求自动走新 LA
应用层完全不感知，TCP 连接也能保持

这就是「云上 VM 随便搬」的底层魔法。

踩过的坑

ECMP hash collision：ECMP 用流的五元组 hash 选路径，偶尔两条 elephant flow 撞到同一链路上，那条链路就堵了。后续工作（Hedera、CONGA）专门治这个。
Directory System 首包延迟：第一次访问某个 AA 时要去查 Directory，给首包加几十微秒延迟。短连接占多数的场景敏感。
没考虑多租户隔离：VL2 假设一个机房一个租户。多租户云出现后，VXLAN / NVGRE 在 VL2 思想上加了租户标识，才补完这一块。
要求重投资 Clos 拓扑：VL2 不能在老树形拓扑上「软件升级」，必须重新布线。这是当年很多公司没立刻跟进的原因。

适用 vs 不适用场景

适用：

大型数据中心（万台服务器级别），机房内部流量占大头
流量矩阵动态变化、无法静态规划
需要 VM 迁移而不改 IP
多路径冗余 + 等价带宽是硬要求

不适用：

小机房（几十台机器），简单 L2 交换机就够了
跨机房 / 跨地域场景——VL2 是机房内方案，跨机房要 SD-WAN
严格的多租户隔离场景——需要 VXLAN / NVGRE 等 overlay 补充

历史小故事（可跳过）

2008 年前：数据中心普遍用三层树形拓扑，越往上越收敛，跨机架带宽极不对等。
2008 年同期：UCSD 的 Al-Fares 等人发表 A Scalable, Commodity Data Center Network Architecture（Fat-Tree），同样主张商用交换机 + Clos。
2009 年 SIGCOMM：Microsoft Research 发表 VL2，把 Fat-Tree 思想 + Valiant + 双地址 + Directory 凑齐，落到生产数据中心。
之后：Azure、Google Jupiter、AWS 都走上 Clos + overlay 这条路。VXLAN（2014 RFC）把 VL2 的双地址思想标准化成跨厂商协议。

学到什么

测量先于设计：VL2 有说服力，是因为它先公布了 Microsoft 生产流量画像。没有这组数据，所有架构主张都是空谈。
商用胜于专用：用便宜的商用交换机 + 软件智能（VLB / ECMP / Directory）代替昂贵的超级交换机。这是云厂商基础设施哲学的雏形。
解耦是万能解药：物理位置（LA）和应用语义（AA）解耦，VM 才能迁移；控制面（Directory）和数据面（封装转发）解耦，控制面坏了数据面还能跑。
Valiant 是个老想法：VLB 来自 1980 年代并行计算机互联网络的研究，VL2 把它搬到数据中心。老论文常常是新工程的金矿。

关联

clos-1953 —— Clos 拓扑的数学起源，VL2 是它在数据中心的工业落地
fat-tree-2008 —— 同期的 Fat-Tree 论文，主张相同但更偏学术
vxlan-2014 —— 把 VL2 的双地址思想标准化成跨厂商 overlay
ecmp-equal-cost —— VL2 用 ECMP 在商用交换机上实现 Valiant 负载均衡
google-jupiter —— Google 把 VL2 思想跑十年的工业续集

反向链接

andromeda-2018 —— Andromeda — Google Cloud 网络虚拟化的高速通道
b4-2013 —— B4 — Google 用 SDN 把跨数据中心 WAN 利用率拉到 95%+
fat-tree-2008 —— Fat-Tree 2008 — 用一堆便宜交换机搭出现代数据中心