跳转到内容
Jason's Study

B4 — Google 用 SDN 把跨数据中心 WAN 利用率拉到 95%+

是什么

B4 是 Google 把全球各数据中心连起来的那张专用网（WAN）。这篇论文讲的是：他们怎么用 SDN（软件定义网络） 把这张网的控制面从交换机里抠出来，搬到一台中心服务器上统一调度，最后把链路利用率从行业惯例的 30-40% 拉到了长期 70%+，热门链路直接打满到 95-100%。

日常类比：传统 WAN 像每个红绿灯各自决策（每个路口自己看车流），B4 像一个中央调度大脑——它能看到全城所有路口的实时车流，然后给每辆车分配一条全局最优的路线。

几个名词先讲清楚：

  • WAN（Wide Area Network）：跨城市、跨大洲的网络。Google 的 WAN 连的是欧美亚十几个数据中心。
  • SDN（Software-Defined Networking）：把”决定怎么转发”的逻辑从交换机硬件里抽出来，搬到普通服务器上跑软件。
  • 流量工程（TE）：根据全局视图给每条流量分配路径和带宽——这是 B4 的灵魂。

为什么重要

这是 SDN 第一次在生产关键路径上的大规模落地。在它之前，SDN 大多是学术 demo 或小规模试点。B4 证明了三件事：

  • 集中控制能在 跨大洲、毫秒级延迟 的环境里跑稳
  • 私有 WAN 的利用率可以从 30% 拉到 95%——意味着同样带宽能多跑 2-3 倍流量，省掉海量光纤投资
  • 自研白盒交换机 + 开源控制器（Onix）的组合，能替代思科、瞻博的封闭设备

这篇之后，微软的 SWAN（同年同会议）、AWS 内部 WAN、阿里 / Meituan / ByteDance 的骨干网设计都受它影响。

核心要点

B4 的架构是三层金字塔：

  1. switch 硬件层（最底）：Google 自研白盒交换机，只负责按表转发，不跑复杂协议。类比：纯执行的工人，不思考。

  2. site 控制器层（中间）：每个数据中心站点跑一组 OpenFlow controller（基于 Onix 平台），管本地交换机；同时跑一个修过的路由协议栈处理 BGP/IS-IS。类比：每座城市的交通局，处理本地事务+和外面交接。

  3. global 层（最顶）：一个中心 TE（Traffic Engineering）服务，看到全网拓扑+所有应用的带宽需求，用 max-min 公平分配 算出每条流量该走哪条路、占多少带宽，然后下发到 site 控制器。类比：交通部总调度室，全国一张图。

关键设计：

  • 应用分级：把流量分成几个优先级（用户面交互 > 远程调用 > 大数据复制），TE 优先满足高优先级
  • Google 两端都控：发流量的应用和收流量的应用都是 Google 自己的，能配合”现在网络忙，你慢点发”
  • 故障兜底：TE 挂了，site 控制器自动 fallback 回分布式路由协议——保证不黑屏

为什么要分这三层？因为集中决策慢、分布式决策视野小——把”算路径”放在 global 层（视野最大），把”维护链路状态”放在 site 层（反应最快），把”按规则转发”放在硬件（成本最低）。每一层只做自己擅长的事。

实践案例

案例 1：为什么传统 WAN 利用率只有 30%

电信级 WAN 设计原则是 “N+1 冗余”——任意一条链路坏了，剩下的要能扛住全部流量。一条链路平时跑到 50% 就要预警，因为对端坏了它得瞬间扛 100%。再加上突发流量缓冲、维护窗口预留……最后实际利用率压到 30-40%。这是安全裕度的代价。

更深层的问题：传统 WAN 用的 OSPF/BGP 这些协议是分布式自治的——每个路由器只看邻居、不看全局。它们各自算最短路，不会主动绕路填满闲置链路。结果就是几条主路被打满，旁边的备用路常年闲着。

案例 2：B4 怎么把利用率拉满

B4 用了三招组合拳：

  1. 应用配合：Google 内部备份、索引复制这种”晚一小时也行”的弹性流量占大头。TE 告诉它们”现在带宽紧，等会再发”，它们就乖乖排队。
  2. 全局视角：TE 看到所有链路，能把 A→B 的流量分成 3 条不同路径并行走（多路径），任一条断了立刻重算。
  3. 集中决策：不依赖 OSPF/BGP 那种慢吞吞的分布式收敛，TE 几秒就能算出新方案下发。

结果：很多链路长期跑在 95%+，只在故障切换的几秒内才需要降级。

案例 3：单点故障是怎么避免的

集中控制听起来”TE 挂了全网瘫痪”，B4 的答案是 fail-safe 降级：

  • TE 和 site 控制器之间正常时下发集中算的流表
  • 一旦失联，site 控制器立刻切回普通分布式路由（OSPF/IS-IS），按最短路转发
  • 用户感知到的只是”利用率掉回 40%“，不会断网

这种”集中态优秀，分布式态保命”的混合模式，后来成了 SDN 工程化的标配。

案例 4：max-min 公平怎么分带宽

假设三条流共享一条 10Gbps 链路，需求分别是 8、4、2 Gbps，总需求 14 超出容量。max-min 算法的做法：

  1. 先看最小需求的：流 3 只要 2，给满 → 剩 8Gbps
  2. 剩下两条流平分：每条 4Gbps → 流 2 想要 4 刚好满足
  3. 流 1 想要 8，但只剩 4 → 给 4

最终分配：流 1 = 4，流 2 = 4，流 3 = 2，链路恰好打满。这种”先满足小的、剩下的让大的分”的逻辑保证：没人能多拿而不挤压别人。B4 的 TE 在全网做这件事，不是单链路。

踩过的坑

  1. OpenFlow 1.0 表项数量有限：交换机只能存几千条流表，全网组合爆炸。B4 用 hash 分流 + ECMP（Equal-Cost Multi-Path，等价多路径——多条路径同等优先时按 hash 分流量） 把规模压下来，没每条流写一条规则。

  2. 集中控制 = 单点风险：TE 算错或下发错会瞬间影响全网。Google 加了双副本+灰度下发+回滚，每次只改一小块流量先观察。

  3. 应用必须配合：如果业务方都是”要带宽就硬抢”的传统 RPC，TE 调度不动。Google 强推内部 SLA 分级，让所有团队按优先级标记流量——这是组织能力问题，不是技术问题。

  4. 跑到 95% 没缓冲：瞬时突发会丢包。B4 让边缘应用做速率反馈——网络紧张时主动 backoff，延迟敏感的流量优先发。

  5. TE 收敛速度跟不上：链路抖动时如果每秒都重算一次，全网在抖动中震荡。B4 用滞后窗口：变化幅度小于阈值不重算，故障级变化才触发全量。

适用 vs 不适用场景

适用：

  • 自有数据中心 + 自有应用的私有 WAN（Google / Microsoft / Amazon / 阿里）
  • 流量结构里有大量弹性、可延迟的批处理（备份、复制、训练数据传输）
  • 组织有能力推应用配合（标优先级、做速率反馈）

不适用：

  • 公开互联网 ISP（流量不可控，应用不在自己手里）
  • 小规模数据中心（控制器+TE 的运维成本压不下来）
  • 实时性要求毫秒级抖动的金融交易网（集中控制的下发延迟够呛）

历史小故事（可跳过）

  • 2008 年：Stanford 的 Nick McKeown 等人发表 OpenFlow 论文，SDN 概念诞生。
  • 2010 年前后：Google WAN 流量爆炸式增长，传统设备每年涨 2-3 倍带宽，账单痛到管理层。
  • 2010 年：Onix 论文发表（Google + Nicira + Stanford 合作），提出”分布式状态 + 集中编程”的控制器平台。
  • 2010-2011 年：Urs Hölzle（论文末作，Google SVP）拍板自研——白盒交换机 + 内部分支版 Quagga + Onix 控制器。
  • 2012 年：B4 全量上线，逐步替换原有思科 / 瞻博骨干。
  • 2013 年 SIGCOMM：首次公开，论文一发圈内炸锅——SDN 从 PPT 变现实。微软同会议发 SWAN，思路撞车。
  • 2018 年 SIGCOMM：Google 又发 B4 演进版论文，讲怎么从”集中 TE 服务”扩展到多区域协同，处理跨区域故障域。

学到什么

  1. 集中视角 + 分布式兜底 是大型系统的通用范式——平时享受集中决策的最优，故障时退到分布式保命
  2. 利用率不是技术指标，是商业杠杆——从 30% 到 95% = 同样投入跑 3 倍业务，是能拿出来汇报董事会的数字
  3. SDN 真正的门槛是组织而非技术——白盒交换机和 OpenFlow 都开源了，但让所有应用团队按优先级标流量需要 CTO 拍板
  4. Google 论文的特点：不藏私（架构图都画出来），但关键参数永远不给（max-min 怎么算的、收敛多快），让你抄不了完整作业
  5. 垂直整合是壁垒：B4 能跑出 95% 因为 Google 同时控制了应用、操作系统、交换机、控制器五层。任何一层不在自己手里，调度就有死角
  6. 理论 → 工程的代价：Onix 论文 2010 年发，B4 2013 年才公开——中间三年是把”原型能跑”做到”全球关键基础设施能跑”的隐性工程

延伸阅读

关联

  • openflow-2008 —— SDN 协议层基础，B4 是它的工业终极用户
  • jupiter-2015 —— 数据中心内 SDN 网络，和 B4 互补（一个对内一个对外）
  • vl2-2009 —— 微软早年数据中心网络设计，思想上的前辈
  • tcp —— B4 跑满 95% 还能稳定，依赖 TCP 拥塞控制兜底
  • paxos-1998 —— TE 控制器的状态一致性靠类似 Paxos 的协议保
  • google-1998 —— 同一家公司的早期工程哲学，可以看出基础设施自研的传统从搜索时代就开始
  • wang-2014-spdy —— 同样来自 Google 的协议层创新，思路接近：自己控制两端就能改协议

反向链接

  • ix-2014 —— IX 数据面操作系统 — 用虚拟化把高吞吐和低延迟同时塞进内核
  • jupiter-2015 —— Jupiter Rising — Google 数据中心网络十年怎么做到带宽涨百倍
  • openflow-2008 —— OpenFlow 2008 — 把交换机的『分拣规则』搬到一台中央电脑上
  • paxos-1998 —— Paxos 1998 — 古希腊议会寓言里藏的共识协议
  • tcp —— TCP — 在不可靠的 IP 上凿出一条 reliable 字节流
  • vl2-2009 —— VL2 — 让一万台服务器像在同一台交换机上
  • wang-2014-spdy —— How Speedy is SPDY — 换协议没让网页变快多少