自己建的数据中心，含着泪也要联完~

没想到吧，因为数据中心“胡乱选址”，诞生了一门独立的网络功课。

这就是DCI，Data Center Interconnect，数据中心互联，你可以认为这是大厂自建的城域/广域网，谷歌的B4网络是这领域的祖师爷。

先为数据中心胡乱选址背锅，实在背不动了才会进行数据中心园区规划、再进行DCI网络优化。

这种规律在老生代、中生代、新生代的大厂里循环，无一幸免。

01 /猥琐发育，别浪

最开始，每个厂都还很小，谁也不知道能不能活到明天，更没有专业的网工，本着少花钱的原则开始↓

①从租一个机位开始
②分散在不同机柜的多个机位
③需要租1整个机柜了
④分散在多列的机柜
⑤重复以上的循环，依次到1整列机柜、1整个模块包间、1整层、1整楼、1整个园区
⑥通常不到1整层的时候，园区就没空地儿了，业务再增长得去别的园区租机柜了，而且交付周期非常短，不然关键业务促销没支持好，全公司都得歇菜
⑦这时候通常会有背景不一的网工不到10人，就会采取最简单粗暴的方式（专线、裸纤都有可能，取决于交付时效）把2个园区连起来
⑧再接下来是3个园区、4个园区…

最终就会可能变成下面这个样子，所谓的规律就没什么规律，也可能只是符合这个城市数据中心产业的分布规律。

02 /拓扑规范化

再往后发展，就会变成拓扑学中著名的N²问题。

从成本角度考虑又不可能完全是N²，所以为了避免园区太多了之后，互联太多、太乱，网工们首先想到的是找2个POP点作为所有园区的中转互联。

所有园区都需要和2个POP点机房互联，同时可以保留园区之间的直联，园区直联通常在这种架构中叫“直通车”。

如上图，所需的连接有14条，可以如果熟悉拓扑规律，会很清楚这种Mesh组网的复杂度是O(N²)。

N表示园区和POP点的总数，所以如果缩小N，就可以大幅缩减需要租用的互联链路。

最直接的方案是，挑2个长期合作的核心园区承担POP功能，例如下图中的C和E↓

这个方案只需要9条连接，比原方案减少了5条。

POP功能和园区合并也是降成本的趋势产物。

在此基础上就可以做出跨Region互联的方案，如国内典型的华南-华东-华北三地域格局——

这基本上就是大厂覆盖全国的“红-绿”双平面环网全国性质骨干网的雏形了。

在这个基础上，每个Region内园区除了和POP互联外，还可以按需组建直通车链路：

1、减少POP园区的负担
2、降低业务耦合园区之间的时延，保障业务性能

直通车链路的起源主要来自于业务部署，而非网络规划：

1、刚开始一个新业务在犄角旮旯猥琐发育，哪里有资源就部署在哪里，典型的朱元璋一只碗开局
2、这个业务猥琐成功了，日活爆了，但原来那个园区资源不够扩了，扩到其它园区，通过POP园区中转
3、业务跨这2个园区的redis等时延和抖动敏感的流量太大了，跨POP时延又高、又经常被别的园区流量占用带宽，老要扩容
4、那就给这2个园区建个直通车链路，带宽专用、时延降低

03 /数通组网

❶园区内与DCN的衔接

如下图，通常DCI在园区内与DCN有2种衔接方式：垂直模式和平行模式。

垂直模式比较好理解，DCI设备在拓扑上位于园区核心的上一层，要求DCI设备与园区核心Full-Mesh连接。

平行模式中，DCI设备和园区核心属于同一层级，也可以认为是一部分特殊的园区核心。

DCI设备与园区核心不互联，DCI设备专门用于跨园区互联，园区核心专用于集群间的高带宽互联。

这两种种模式有各自的优缺点，适合不同的运营模式，如果没有什么特别的诉求。

一般的网络团队都会选择垂直模式，比较好理解，运营也容易适应。

如果有如下精细化运营的需求，那么水平模式就会被考虑：

1、控制初建成本，不想一次性把园区核心和DCI矩阵全建满，而是根据实际水位扩容矩阵中的平面
2、精准容量运营，平行方式可以精确区分南北向流量和东西向流量的水位，以实现精准流量扩容，而避免大水漫灌
3、减少层级，缩小几us的转发时延，不过和DCI传输距离（每10公里增加100us RTT时延）而言，这点减少微不足道

通常只有到了极致追求成本的情况（具备把成本优势转化为市场优势的能力）下，才会考虑这么极端的操作。

同样的，也必须具备这种极致的网络运营能力。

❷跨园区的协议选择

Region内，由于连接是由业务需求转化，相对DCN没什么规律。

因此都收敛为互联网最初的样子，那就把每个园区当作一个组织↓

1、园区和园区之间通过EBGP方式互相交换路由
2、经过POP园区或别的园区的路径就相当于通过别的组织中转路由

这样的好处，可以天然利用EBGP简洁的路由策略控制互访的主用路径和确定性备用路径。

在跨Region场景，这时就会学习运营商的骨干网设计：SIS+带RR的IBGP再叠加各种SDN混合的流量工程。

这么干的目的是↓

1、骨干网作为一个整体提供的是统一的跨域数据带宽服务，所以可以视为1个IBGP域
2、由于拓扑的复杂性，ISIS相比OSPF具有更简化的LSDB数据结构、天然的双栈能力可以具备更好的复杂拓扑适应性，简单来说OSPF在ISIS面前更像是个玩具，根本上不了严肃运营场景的台面
3、通过流量工程可以对不同DSCP值的流量进行灵活的水位控制。

a类通常不给业务使用，所以水位控制主要在b类型流量上，阈值会控制在线路带宽的40%，突破40%就需要考虑扩容了。

剩下的60%带宽其中大部分会给c类流量作为quota，闲置带宽就可以被d类流量随意使用。

不同类型流量的收费策略可以用天差地别来形容，不然所有业务就都会说自己非常重要得用b类，这种收费服务模型会倒逼业务区分流量，避免预算浪费。

a.协议流量最高优先级，占比极低
b.业务流量高优，确保SPF+承诺带宽转发（拥塞场景中，也优先保障转发)通常给实时同步类业务
c. 业务流量次高优，承诺带宽转发（不确保SPF，拥塞场景中会被绕行），通常给非实时在线同步业务
d.业务流量默认，不承诺带宽转发（在拥塞场景中，会被优先丢弃），通常给离线类型业务

这种策略可以让网络团队充分提升昂贵的骨干带宽利用率，在上级领导那里获得源源不断的点赞。

具体流量工程的方式就不多介绍了，就是老一辈的MPLS TE、中生代SR-TE、新生代SRv6，并且加上SDN作辅助全局调度。

评价方式还是看能不能在保障关键业务b类流量的前提下充分让c、d类流量提高链路带宽利用率。

这都是被Google B4 90%以上利用率卷起来的游戏。

❸一个常被忽视的关键点：稳定性

前面说的这好那好都是一切都正常的情况下，DCI不管是城域还是骨干都依赖光传输OTN网络。

光传输的SLA是50ms保护，50ms对许多敏感的内存数据库应用来说是一定会有感知的。

同时DCI设备数通协议互联会经过许多2层和1层设备，无法在协议层快速感知到中间链路的异常。

这就需要在每条物理链路上叠加BFD，以实现快速探测端到端异常，而传统的BFD工作在3层，无法遍历每一条物理链路，这就需要进行相应的协议改造。

由于探测的灵敏性取决于探测频率，高频BFD会严重占用主控CPU资源，端口一多就更让CPU吃不消，所以硬件级BFD都是DCI的低开销特性。

很多时候，我看到以太网上层垒这么多复杂的特性，就忍不住要发点感慨↓

为啥以太网的链路层协议在HPN里啥都能改，可到了DCI场景，不能加个像SDH网络那样具备物理层连接可靠性的探测协议呢？

那就不需要什么BFD了，芯片厂商直接把这部分钱给赚了。

好了，关于DCI就聊这么多吧，祝大家拉纤愉快，搬砖丝滑。