将仲裁引入 IDC 网络合理吗?
Posted dog250
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了将仲裁引入 IDC 网络合理吗?相关的知识,希望对你有一定的参考价值。
为什么互联网是分布式控制而不是中心控制的?请看原始论文:The design philosophy of the DARPA internet protocols
还有一个原因,广域网 RTT 太大,集中控制开销过大,影响传输时效。
但在小范围高定制的网络中,这些问题不存在,比如 IDC 网络,RTT 在 50us 级。简单算一笔账,IDC 网络微突发排队延时可达数 ms 到数十 ms,而集中控制的额外信令开销却只有若干甚至 1 个 RTT,即几十 us,划算。
相比 1000 个 sender 同时将 10KB 的消息扇入到同一个交换机造成拥塞,每个 sender 额外花几十 us 的时间预定一段彼此错开的时间是划算的。与数据阻塞在交换机 buffer 引入额外不可预知的响应时间不同,数据在 sender 的等待时间是可预知的,这段时间可以被 sender 精确调度。
当 sender 要发送数据时,先预定时隙,集中控制器统一安排,保证来自所有 sender 的所有报文无排队通过网络,这是高尚的。就像应用程序使用内存前先预留内存一样。
承诺 sender 一个明确的可无拥塞传输的时间点,到达这个时间点前,sender 可以做点别的,一旦该时间点到来,网络保证一定在固定的极短时延内传输完毕。无论对主机资源还是网络资源,均可达最大有效利用率。
大致算法如下:
- 所有端节点和转发节点构成有向图。
- 两两节点生成最短路径,路径由转发节点构成。
- 每个转发节点携带一个 bitmap,表示该节点时隙预定情况。
- 预定发送时间排在路径上所有节点最后一个置位 bit 之后。
- 不必同步时钟,准序即可解决 80% 的问题。
稍作解释。
早期的令牌网就是这样一类集中控制网络,有人觉得又把集中控制引回去,岂不是开历史倒车?这不是开倒车,这是螺旋上升,现如今的云基础设施和早期的多终端登录大型机在形式上又有多少区别呢?
前些天跟朋友闲聊了解到 IEEE 802.11 和令牌网颇有渊源。令牌作为仲裁机制,非常适合做集中控制,分配时隙。但由于设计上过于复杂,在与极简的 CSMA/CD 的竞争中失败。但时隙分配的思想却非常好,它在混乱中引入了秩序,有序的时隙可彻底避免冲突和网络拥塞。
考虑到复杂度,倒也不一定要严格有序,用 20% 的无序换取保持简单,解决掉 80% 的随机统计复用问题,即引入一种准有序机制,就能解决绝大部分问题。
分布式,端到端控制并非网络设计的不变自然律,它恰好迎合了互联网的设计目标,在不需达成这些目标的地方,规则是需要被打破的。IDC 便是这样一个地方。在 IDC 网络,不仅可以改造交换机而重构成胖网瘦端,也可简单引入一台控制器做时隙调度,而对于端上所需要做的,仅仅是在实际发送报文前预定一段空闲时间。
IDC 内部微服务对延时非常敏感,但继承自互联网的统计复用特征会带来与生俱来的微突发,微突发严重影响延时的稳定性。这是 IDC 网络的万年难题(另一个万年难题是 TCP over Wi-Fi)。
解决方案并非没有,而是该方案简单到什么程度才能被部署。TSN(Time Sensitive Networking) 足够解决延时抖动问题,但作为工业级方案却也足够复杂,延时抖动不是不可忍受,便倾向于继续忍受,这就是工程。
浙江温州皮鞋湿,下雨进水不会胖。
以上是关于将仲裁引入 IDC 网络合理吗?的主要内容,如果未能解决你的问题,请参考以下文章