没想到吧,因为数据中心“胡乱选址”,诞生了一门独立的网络功课。
这就是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就聊这么多吧,祝大家拉纤愉快,搬砖丝滑。
热门跟贴