干货 | 携程光网络抵御光缆中断实践

这篇具有很好参考价值的文章主要介绍了干货 | 携程光网络抵御光缆中断实践。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

作者简介

Lightworker,携程网络技术专家,关注光纤通信、DCI传输技术领域。

一、背景

光传输网络(简称OTN)是一种基于光纤技术的通信网络。它利用光纤作为传输介质,将信息以光的形式进行传输。其凭借DWDM(密集型波分复用)技术以及保护倒换技术,可以实现大带宽、低延迟、高可靠的数据传输,因此广泛应用于多个数据中心互联场景。国内外大型互联网公司通过租用运营商光纤自建传输网络,能够大大降低IDC之间数据传输的成本。同样,携程也拥有自建的光传输网络(简称TOTN),主要用于承载骨干网跨数据中心流量以及IT办公上网流量。

作为底层物理网络,TOTN直接面对运营商光缆,需应对频繁出现的光缆故障。众所周知,国内基建仍处于发展阶段,运营商光缆经常被施工挖断。据美国运营商Level3的统计,其光纤网络大概每年每千公里就会中断1次;中国电信大概每年会发生50次以上干线光缆中断;而在印度,几乎每天都会中断几次甚至十几次。可见,光缆中断的次数与当地社会经济的发展程度密切相关。

携程TOTN自建成以来,平均每年监测到20余次光缆中断。因此在提供大容量传输的同时,如果能够在发生光缆故障的时候,光网络可以自动切换,使业务带宽不受影响,甚至不感知故障,将极大的提升网络可靠性。

干货 | 携程光网络抵御光缆中断实践,网络

图1 光缆挖断现场

二、整体架构

携程传输网络为双平面带保护设计,每个IDC部署完全独立的2套传输设备,分别连接2条不同路由的光纤,组成完全独立的2个传输平面。

干货 | 携程光网络抵御光缆中断实践,网络

图2 TOTN拓扑图

正常状态下,业务走在直达链路上,当主用光缆中断时,传输系统会将业务切换至备用通道绕行。主备通道切换时间遵循ITU-TG.783和ITU-TG.841标准,小于50ms。

干货 | 携程光网络抵御光缆中断实践,网络

图3 光网络保护

干货 | 携程光网络抵御光缆中断实践,网络

图4 光缆故障时业务流向

通过上述保护机制,能够解决光缆中断时业务自动切换,带宽不损失,并且抵御同时发生2处光缆中断的极端情况。

但与此同时,有一个问题一直困扰我们,就是传输切换的时候两端网络设备端口存在flapping的情况,导致业务有相应的报错产生。

三、问题分析

网络设备接口从down到up的时间因为不同设备不同光模块有差异,且网络层的二层及三层收敛时间因网络架构的不同存在不确定因素(通常认为是秒级中断),因此每次传输切换都会造成一定时间的业务不可用。通常表现在敏感业务的报错,如Redis。Redis作为内存数据库,对网络抖动非常敏感,几乎每次光缆中断切换都有感知。

比如3月17日12:00 传输A平面,光纤发生闪断,骨干网CSR in方向错包。

干货 | 携程光网络抵御光缆中断实践,网络

图5 骨干网报错

比如9月11日19:44 B平面光缆中断,传输切换时Redis大量报错,如下图:

干货 | 携程光网络抵御光缆中断实践,网络

图6 Redis报错

要解决传输切换导致网络设备端口flapping问题,业界一直没有成熟的标准方案。通过对其它互联网公司的调研,比较常用的方案是在交换机接口上配置link-delay,即路由器收到链路中断的信号后,延时一段时间将链路状态置为down,在这段时间里,如果链路恢复,即保持链路up状态,不产生down状态,避免了链路的频繁抖动。

我们也尝试了这种方式,但发现有诸如设备不支持、配置不生效等问题,一直无法达到预期的效果。原因是link delay不是IEEE标准,不同厂商的网络设备对该功能的支持不尽相同。为此,传输业务的分配只能分摊在不同的光缆路由,确保光缆中断时至少有一半业务不受影响,但这始终无法解决业务有感知的问题。例如A端至Z端需开通200G业务,必须分摊到两个不同平面,每个100G业务参与各自平面的倒换。

干货 | 携程光网络抵御光缆中断实践,网络

图7 业务分摊示意图

另外我们在调研中发现,有些公司为了使link-delay生效,将延时设置成2s。这样的设置虽然使传输保护倒换生效,但一旦保护机制出现故障,路由层面的切换将因此损失2s的宝贵时间。

四、技术研究

2023年,TOTN引入了支持5ms倒换的DCI产品,该产品通过二个方面的改进将传输50ms的倒换时间提升至5ms。一是应用了磁光开关,磁光开关原理是利用法拉第旋光效应, 通过外加磁场的变化来改变磁光晶体对入射偏振光偏振面的作用, 从而达到切换光路的作用。由于无机械移动部件, 可靠性高, 并且开关速度快;二是通过预先将备用通道的光缆参数录入DSP芯片,在倒换时节省了重新计算参数的时间。

干货 | 携程光网络抵御光缆中断实践,网络

图8 光开关原理

我们希望通过缩短光开关切换的时间,解决网络设备端口flapping的问题。但在实际应用中,即使传输倒换时间已经压缩到5ms,网络设备的端口仍然会flapping。通过对产品参数的研究和调试后,我们发现,当光缆中断时,传输光层会向两端电层板卡发送AIS信号,电层板卡收到AIS信号后会向网络设备发送Local_Fault告警,当网络设备收到该告警后,端口即变为down(IEEE 802.3ae)。通过设置传输系统延时发送该信号(默认4*50ms),只要传输切换在该时间段内完成,即不会向网络设备发送该信号,因此端口就不会flapping。

干货 | 携程光网络抵御光缆中断实践,网络

图9 故障信号传递示意图

在DCI产品成功实现了切换无感知后,我们希望在现网传统产品中也找到类似的参数进行调整。因为告警延时传递与5ms倒换时间无关,即使是50ms的倒换时间,如果能让网络设备端口不感知光缆抖动,也会对业务稳定性带来极大的提升。

五、 优化方案

为了实现网络传统产品支持无感切换,通过与厂商技术沟通,得出的结论是需要将100GE业务映射方式由BIT透明映射调整为MAC透明映射(会中断业务),然后再设置告警参数延时200ms传递。

由于TOTN从来没有使用过MAC透明映射方式,对此,我们协调设备厂商在实验室专门做了MAC映射和BIT映射的测试验证。结论是两种方式吞吐量没有区别,延时有差异,BIT映射时对64-9600Byte的帧都是24us,MAC映射时随帧长增大而增大,但最大9600时,也就25us,可以忽略不计。

干货 | 携程光网络抵御光缆中断实践,网络

图10 实验环境拓扑

干货 | 携程光网络抵御光缆中断实践,网络

干货 | 携程光网络抵御光缆中断实践,网络

图11 RFC2544测试结果

因此我们制定了优化方案,先调整传输A平面,灰度运行一段时间后再调整B平面。

六、 验证效果

8月18日对传输A平面进行优化:100GE业务映射方式采用MAC透明映射,告警参数延时传递200ms。经测试验证,可实现传输光缆主备切换对网络设备端口无感知,Redis无感知。

在真实的故障场景下也同样得到了验证。如9月7日15:13传输A平面发生光缆中断故障,Redis报错无异常尖峰。

干货 | 携程光网络抵御光缆中断实践,网络

图12 优化后Redis报错

经过经一个月的灰度验证后,我们于9月15日对传输B平面进行优化,并且将告警参数延时传递时间在200ms的基础进一步缩短至100ms,同样经测试验证Redis无感知。

七、 未来规划

为保持架构的统一性,我们将重新定义携程光网络设备技术标准,要求新入网的OTN设备必须支持BIT映射的告警延迟下插。同时,推动各供应商全面支持该功能,使之成为光缆故障场景下的一种最佳实践。

抵御光缆故障是个业界公认的难题,头部互联网公司都在此栽过跟头。通过上述一系列实践,我们在抵御光缆故障方面已经做到了领先水平。光网络运维是个长期过程,无感知切换只是其中一小部分,更多的是告警发现、性能监测以及光缆路由识别,避免同路由情况的发生。

【推荐阅读】

  • 携程分布式图数据库Nebula Graph运维治理实践

  • JuiceFS 在携程海量冷数据场景下的实践

  • 携程公共技术支持运营实践

  • 携程基于DPDK的高性能四层负载均衡实践


干货 | 携程光网络抵御光缆中断实践,网络

 “携程技术”公众号

  分享,交流,成长文章来源地址https://www.toymoban.com/news/detail-773884.html

到了这里,关于干货 | 携程光网络抵御光缆中断实践的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • 干货 | 瘦身50%-70%,携程 Taro 小程序样式 Size 缩减方案

    作者简介 Can,携程前端开发,目前从事小程序开发工作,对编译打包技术、小程序跨平台解决方案有浓厚兴趣。 一、概述 目前我们团队小程序是使用 Taro 跨端方案 React 框架进行开发,基于现有样式方案,在编译打包后会产生大量的样式代码冗余,在项目编译后的产物中占有

    2024年02月11日
    浏览(34)
  • 干货 | 提前在开发阶段暴露代码问题,携程Alchemy代码质量平台

    作者简介 Lyan,携程资深后端开发工程师,负责自动化测试框架及平台类工具开发,关注Devops、研发效能领域。 一、背景 随着敏捷开发,DevOps开发模式的流行,代码质量分析作为研发质量保证体系的重要组成部分,不仅能有效的降低因频繁迭代带来的故障风险,而且对整个工

    2023年04月11日
    浏览(37)
  • 抵御时代风险:高级安全策略与实践

    目录 网页篡改攻击 流量攻击 数据库攻击 恶意扫描攻击 域名攻击 在今天的数字时代,网站已经成为企业、机构和个人展示信息、交流互动的重要平台。然而,随着网络攻击技术的不断进步,网站也面临着各种安全威胁。本文将探讨五种常见的网络攻击类型,并提供保护网站

    2024年02月12日
    浏览(33)
  • 开源 | 携程 Redis On Rocks 实践,节省 2/3 Redis成本

    作者简介 patpatbear,携程软件技术专家,负责携程缓存内核的维护,热爱开源,专注于高性能、分布式NoSQL系统的建设和应用。 一、背景 redis使用内存作为存储介质,具有良好的性能和低延迟,但其内存容量通常成为瓶颈,且内存价格较高,导致redis使用成本较高。 随着SSD磁

    2024年02月04日
    浏览(40)
  • Python网络爬虫(三):Selenium--以携程酒店为例

            Selenium是一个用于网站应用程序自动化的工具,它可以直接运行在浏览器中,就像真正的用户在操作一样。它相当于一个机器人,可以模拟人类在浏览器上的一些行为,比如输入文本、点击、回车等。Selenium支持多种浏览器,本文以Chrome浏览器为例。chromedriver是一个驱

    2024年04月23日
    浏览(46)
  • 技术实践|Hive数据迁移干货分享

    导语 Hive是基于Hadoop构建的一套数据仓库分析系统,可以将结构化的数据文件映射为一张数据库表,并提供完整的SQL查询功能。它的优点是可以通过类SQL语句快速实现简单的MapReduce统计,不用再开发专门的MapReduce应用程序,从而降低学习成本,十分适合对数据仓库进行统计分

    2024年02月11日
    浏览(52)
  • 干货|EasyMR 基于 Kubernetes 应用的监控实践

    在之前的内容中,我们深入探讨了 EasyMR 如何利用 Kubernetes 进行部署。大家已经了解到,在 EasyMR 的整体架构中,我们使用 Prometheus 进行节点和服务监控数据的采集、查询和存储。同时,Grafana 作为强大的可视化工具,将 Prometheus 中的监控数据以多样化的方式展示出来。 在本文

    2024年02月03日
    浏览(34)
  • 干货|三个维度详解 Taier 本地调试原理和实践

    在平时和开发者们交流的过程中,发现许多开发朋友尤其是新入门 Taier 的开发者,对于本地调试都有着诸多的不理解和问题。本文就大家平时问的最多的三个问题,服务编译,配置本地运行,如何在 Taier 运行 Flink-standalone,进行简单的介绍,希望和大家共同交流学习。 在本

    2024年02月11日
    浏览(32)
  • [干货] 如何解决慢SQL?详细分析和优化实践!

    本篇博客将分享如何通过慢SQL分析工具和常用优化手段,来解决慢SQL的问题。首先让我们看一下慢SQL的定义。 简单来说,慢SQL指的是执行时间较长的SQL语句。在数据库中,一个查询的运行时间往往会受到多种因素的影响,例如表结构、数据量和索引等。如果一条SQL语句的执行

    2024年02月08日
    浏览(25)
  • JDK11 升级 JDK17 最全实践干货来了

    上篇文章给大家带来了JDK8升级JDK11的最全实践,相信大家阅读后已经对JDK11有了比较深入的了解。2021年9月14日,Oracle发布了可以长期支持的JDK17版本,那么从JDK11到JDK17,到底带来了哪些特性呢?亚毫秒级的ZGC效果到底怎么样呢?值得我们升级吗?而且升级过程会遇到哪些问题

    2024年02月05日
    浏览(57)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包