上回说到,许仙和白娘子通过光传输实现了两个数据中心之间互联互通,帮助新保和堂的生意大大扩张。
话分两头。法海好不容易治好了PTSD,痛定思痛,也期望通过在金山寺推行数字化转型,通过“互联网+跳大神”的商业模式,开拓线上做法事的蓝海市场,提升寺庙的经济效益的同时承担更多的社会责任。
法海在网络直播的大会上,看到直播间里边台上菊花公司的专家高谈阔论“建立美好的全连接世界”,一番搔首弄姿以后,拿出一台设备,告诉大家:这是内置AI芯片的交换机,CE***,整机只要一千六百八十万就可以运回家!
法海立即联系了菊花公司的销售,一番肮脏的PY交易之后,法海在金山寺的数据中心部署了两台CE***。
法海有点儿不放心,问菊花公司销售:你们这个交换机没问题吧?
菊花公司销售经理拍着胸脯说:没问题,这交换机业务如果中断,除非雷峰塔倒,西湖水干!
法海一听,放心地开始往数据中心里面迁移业务了。
很快,“线上金山寺”APP开始运行,由于法海自己就是大IP,还入住了某手、某音、某鱼等网黄,以及学某某国等网红传播平台,线上金山寺的日活很快超过百万。
为了扩展业务,法海从隔壁阿某某巴又挖来一位技术总监,自研了基于开源社区的容器云平台,引入了CI/CD流程,实现线上金山寺的业务快速迭代。
这天,新迭代的线上金山寺APP 2.50版本要上线了。程序员和工程师们沐浴焚香祈祷服务器不要出问题。
可是,在金丝雀测试通过以后,数据中心网络管理报告,整网大量丢包!
做了一半的版本迭代只好立即回退。
祸不单行。好事成双。刚好,有关部门为了庆祝网络安全法颁布纪念,对所有APP进行了安全大审计,没有来得及修复漏洞的线上金山寺APP被发现存在大量网络安全问题,金山寺被吊销ICP执照十年。
远处的雷峰塔传来了崩塌声……
原来,这是因为CE***整机的VoQ规格太少造成的。
让我们回顾《交换机篇 10 倚天屠龙(上)》的内容。
通过Broadcom的StrataDNX平台实现的框式交换机,两颗转发芯片Jericho之间,通过多片FE3600网片互联互通。Jericho每芯片支持4GB的包缓存,并支持96K的VoQ虚拟队列。
VoQ是Virtual Output Queue的缩写。简单地说,在没有应用VoQ技术的设备中,每个接口只有自身分配的物理队列,在交换机ASIC中一般每接口4个或8个;而引入VoQ技术的设备中,每个入方向端口,都可以为交换机内,任意的出方向端口分配一个或若干个虚拟的队列,如下图所示:
VoQ可以起到什么作用呢?
以上图为例。图中,LPU0上的两个10G接口向LPU3的一个10G接口发送流量,当然,这会导致LPU3的10G接口发生拥塞,LPU3的缓存很快会占满,并通过交换网的令牌机制反压到LPU0的TM(Traffic Manager)部件。由于VoQ的作用,LPU0上,接口XGE0/1还能够向LPU3上,没有发生拥塞的XGE3/0发送数据。
在云原生数据中心中,由于CI/CD的普及,大规模拉起容器时,会发生容器云中的Node集中去容器仓库拉取容器镜像的情况,这种数据中心核心交换机上,线卡上部分接口拥塞是不可避免的。
许仙和白素贞的新保和堂由于使用了H3C S12500X-AF作为核心交换机,每芯片支持96K VoQ队列,可以为芯片上的每个100G接口提供16000个VoQ队列。这样,在整机最多768个100G接口的情况下,每两个100G接口之间,至少可以分配20个VoQ队列,可以实现4级甚至5级H-QoS。
而法海由于受到不良商家的欺骗,采购的CE***交换机,每芯片只支持2K个VoQ队列,每个100G接口只能分配到300多个VoQ队列,连基本的QoS都难以满足,在CI/CD情况下,大规模应用发布的时候大量丢包是可想而知的,本质上,是因为在数据中心核心位置,使用了偷工减料的交换机导致业务不可用。
鲁迅先生虽然没有亲见雷峰塔的倒掉,但在《论雷峰塔的倒掉》中指出,莫非设备商造偷工减料的交换机的时候,竟没有想到关键规格的偷工减料是会被测出来的么?
活该。
本期问题:
盒式交换机为什么不需要支持VoQ?
上期问题解答:
S12500X-AF每槽位高度为1.2U,物理上可以放置3排QSFP+/QSFP28接口,也增加了散热面积,所以整机可以支持更多的交换芯片。