过去十年是互联网高速发展的十年,随着产业不断发展,应用种类极大丰富,用户规模空前庞大,往往一个应用就拥有千万级别用户,上P数据量。在这样的环境下,早期的单机或集群的计算模式已经无法满足应用的发展要求,更大规模的云计算模式是互联网持续发展的必经之路。受制于目前数据中心规模问题以及异地容灾需求,往往一个应用会分布在多个数据中心之内,而用户的交互行为,让应用之间的交互流量凸显,导致不同的云数据中心之间往往会产生几十甚至上百G的带宽需求。在这样的背景下,光网络开始逐渐走入了互联网企业的视野。
云数据中心对于光网络的需求
一直以来光网络都是运营商的专利,其他行业鲜有涉足,近几年才开始逐渐在互联网行业开始应用。国外的谷歌、Facebook、微软,国内的腾讯、百度、阿里巴巴都已经计划或开始建设自己的传输网络,用于搭建数据中心之间的高速通道。互联网对于光网络有着自己的独特需求,以下为大家进行简单的列举:
超大带宽
对于云数据中心来讲,对于光网络的第一需求就是提供超大容量带宽管道。随着云化的不断深入和云规模的不断扩张,物理边界已经逐渐被抹平,一个应用可能分布在多个数据中心,但是从逻辑的角度又需要让应用感觉不到物理的地域差异,这个时候就需要在不同数据中心之间提供足够大的带宽,来打平异地布局所带来的不利因素。
简单
这里提到的简单包含了两层含义。第一层含义是架构简单:门槛低,可复制。互联网企业内的网络技术人员大多是IP网络领域技术人员,对光网络技术了解较少。复杂的架构、高门槛将会阻碍光网络在互联网企业中的建设落地和运营。第二层含义是运营简单。互联网企业的网络运营团队人数较少,且需要同时管理IP网络和光网络,这就要求光网络的运营足够简单,能够像IP网络一样快速定位故障和恢复业务。
敏捷能力
互联网业务瞬息万变,竞争激烈。一个业务晚上线一天就可能形成完全不一样的市场格局。因此要求光网络具备足够的灵活性和弹性,能够快速开通业务,灵活实现业务的迁移和调度。
极致化用户体验
互联网追求极致化用户体验,这也是互联网业务吸引用户的核心竞争力之一,极致化的用户体验需要网络提供高带宽、低延迟,以及故障的快速收敛性能,这需要网络的各个层面一起努力。
新的形势下光网络需要做出哪些转变?
互联网巨头谷歌早在2005年就开始筹备组建其在美国境内的核心骨干光网络,并在2010年底开始合作投资海缆,因而在互联网企业的光网络应用中走在了领先位置。
国内互联网企业的传输网络应用大致起步于2008~2009年,大型互联网公司都在其核心节点城市建设了数据中心间的城域传输网络,并且随着核心数据中心节点的不断扩张,开始尝试组建城际传输干线。互联网元素的注入对于光网络提出了更高的要求。
腾讯的光传输网络始建于2009年,并于2012年底开始进行100G传输的试点建设,2013年开始进行批量化100G传输建设,2014年实现了100G端到端业务开通。目前已经在全国多个城市部署了光网络,提供数据中心间互联带宽超过15个T。同时,为了满足区域一体化需求,腾讯在京津、广深进行了城际光网络建设尝试。结合网络发展步伐和上层业务实际需求,我们认为光网络需要做以下优化:
更强的环境适应能力
以往的传输设备都是落地在运营商专用的传输机房,21英寸标准ETSI传输机柜,-48V直流供电,机房整体散热。而互联网使用的数据中心机房是PC 服务器的世界,19英寸标准机柜,220V交流或者240V高压直流供电,机房冷热通道隔离。在数据中心机房进行环境改造部署传输设备,涉及到供电、制冷、更换机柜等等环节,除去大的成本开销外,至少需要3个月的时间。这对于以效率为生存准则的互联网企业来讲是难以接受的。更强的环境适应能力是光传输设备在非运营商环境下规模应用的重要前提。
更高速率的光网络
互联网产生的流量每天都在发生变化,年增率达到100%。IP网络已经开始向40G/100G切换,大数据时代的到来不可逆转。
光网络已经开始进入了100G时代,但是对于更高速率的光网络诉求依然是强烈的。目前200G/400G传输网络技术已经逐渐成熟,并开始进行试商用。虽然进展喜人,但是前景依然不容乐观。原因在于:
·技术路线尚未统一且存在一定缺陷:16QAM目前看是主流方向,但是传输性能比100G低7dB;奈奎斯特、4x100GQPSK方案虽然在传输性能上面有所提升,但是波特效率比100G系统并没有显著提升。
·与10G/40G/100G传输系统频率间隔为固定的50GHz不同,200G/400G 16QAM系统的频率间隔为37.5GHz,新系统如何从老系统平滑升级并与老系统并存,是一个重要的课题。
去电信化思维
在现有模式下,IP网络和光网络的规划、建设、管理、运维都是分开的,我们在IP层进行了大量冗余设计的同时,在光层也进行了诸如光复用段、光通道层、环路保护等等诸多保护。牺牲了系统效率、浪费了大量资源。因此非常有必要把IP网络和光网络整合在一起考虑架构冗余问题。
我们知道IP网络冗余除了要防备使用链路出现异常,还要考虑设备故障引发的问题。因此,虽然可以通过架构设计来提升IP网络的利用率,但是IP网络层面的冗余是不能减免的。而光网络做为IP网络的下一层网络,可以利用IP网络的冗余设计,取消光层的保护。
当然,这里的取消保护并不意味着光网络就不需要考虑冗余设计,而是要将整个网络捏合在一起进行考虑。一方面需要光网络向IP网络提供具有足够多路径的底层链路,使得当故障出现时只会出现部分链路异常;另一方面要充分考虑IP网络的诉求,配合IP网络实现快速的故障发现、收敛和恢复。
光层SDN[注]
前面提到,互联网是追求效率的行业,竞争异常激烈,机会稍纵即逝,这就要求网络层面具备足够敏捷和灵活的能力。对光网络来讲,快速的开通,灵活的调整,敏捷的调度功能是必不可少的。需求很骨感,但是现实很残酷。我们发现现有环境下光网络的建设供给模式很难满足互联网的敏捷要求。目前运营商的传输扩容项目都是以半年为周期计算的(+本站微信networkworldweixin),即使在互联网公司这一周期被大大缩减,也依然需要至少2个月周期。
看起来很难改变,那么如何满足这里的需求呢?比较原始的办法就是结合历史发展趋势,在建设过程中储备一些备用资源,来满足突发需求。但是由于预估资源可能不够准确,且备用资源难以调整、灵活性不足,依然无法满足全部需求。如何把备用资源灵活利用起来,做到可调度、可调整?这就需要通过SDN的思路来解决。
SDN的概念诞生于2006年,在短短的不到10年时间内不断发展壮大,被越来越多的运营商和互联网公司所接受。2012年,谷歌宣布其主干网络已经全面运行在OpenFlow上,从而实现其广域网链路利用率从30%提升到接近饱和。这也证明了OpenFlow已经具备了现网商用所需的技术成熟度。
虽然SDN的大部分成功案例都是在IP网络上面实现的,但是我们认为,SDN实际上是一种思想,在光网络也同样适用。主流传输设备厂商都已经加入到了SDN光网络的研发狂潮中,大多采用PCE技术来实现初期的SDN光网络模型(如图所示)。
PCE controller负责路径计算,通过南向接口使用PCEP协议+私有协议来实现和底层传输设备的通信,实现拓扑感知,故障快速发现,下发指令等功能;通过东西向接口使用标准PCEP和其他PCE controller对接,实现跨域系统间的协商;通过北向接口和上层应用协商。通过这样一个架构模型,可以实现路径自动计算、通道快速建立、故障快速恢复等基本功能,很大程度上可以满足对于光网络敏捷度和灵活性的要求。
但是我们也看到,Openflow 1.4的标准中尚未对于光层场景进行定义,这也使得SDN光网络目前依然处于前期实验阶段。线路侧可调速率、可调中心频率、可调频宽、可调编码方式,复用/解复用器可调栅格等技术都需要去研究和实现。光层SDN的道路依然长远。
精细化运营需求
互联网企业的运营团队需要全面负责IP网络和光网络,技术人员大多是IP网络技术人员,对光网络知识了解较少。如果光网络的可运维性还是停留在原来的水平,将大大阻碍光网络在互联网企业的落地和运营。因此光网络可精细化运营能力的提升是不可或缺的。
最先需要优化的就是告警。现在大部分传输厂商的告警采用的是将各个板卡出现的告警全部上报的方式,但是光层设备的逻辑关联关系是非常强的,往往一个板卡/模块的故障,会连带在下游的多个板卡和模块上产生告警,现网核心间站点干路光纤的故障能够产生上千条告警,大量告警为故障的定位和排查带来极大困难。优化的思路就在于对告警进行关联性分析,通过数据库中业务的配置关系,用上层告警收敛下层的衍生告警,从而最终定位出根因告警。进而可以快速根据根因告警定位故障原因,使得整体排障效率大大提升。
其次就是监控能力的提升。光层设备虽然能够实时了解所使用光纤的衰耗情况,但是依然较难对具体的光纤故障进行定位。当确认光路中断后,还是需要到各个光纤跳接点挂表测试,使得光纤故障处理的效率难以得到提升。通过整合OTDR,可以使光层设备具备光纤在线实时监测能力。通过将1625nm的检测光整合到复用段一起传输,利用检测光的折射和反射可以实时定位每个跳接点间光纤的实时衰耗变化,这使得提前预判光纤的故障成为可能,这也是精细化运营能力的重要体现。
结语
互联网产业高速发展的今天,数据中心之间的通信需求使得光网络在互联网企业得到大量的应用,而互联网的特性也给光网络提出了更高的要求。更高速率的带宽、更大的容量,更强的环境适应能力,更强的可精细化运营能力,灵活敏捷的布局和可调度能力,都是光网络需要去攻克的难关。而通过光层SDN的演进,通过IP网络和光网络更深层次的融合,相信光网络的应用将会给未来互联网的发展带来更大的收益。