专门做网站的公司有哪些,集团门户网站建设方案,网易企业邮箱小程序,自己做聊天背景网站作者 | 魏煌松来源 | 鲜枣课堂时至今日#xff0c;谷歌在2015年公布的成果#xff0c;“利用SDN将广域网带宽利用率提升至接近100%”#xff0c;仍然是SDN的一个标杆案列#xff0c;也是难以逾越的巅峰。但事实上#xff0c;当时使用的SDN控制器Onix#xff0c;早已退出了… 作者 | 魏煌松来源 | 鲜枣课堂时至今日谷歌在2015年公布的成果“利用SDN将广域网带宽利用率提升至接近100%”仍然是SDN的一个标杆案列也是难以逾越的巅峰。但事实上当时使用的SDN控制器Onix早已退出了历史舞台。在今年的NSDI会议上谷歌发表论文详细阐述了其第二代SDN控制器Orion的设计原则、整体架构和在生产网络中的应用情况。尽管是最近才发表的论文但Orion已经在现网中运行了四年可谓是“久经考验”。今天这篇文章会分为几个部分包括介绍谷歌网络的整体情况回顾第一代SDN控制器Onix简要阐述谷歌新一代SDN控制器Orion的情况和几个重要的设计考虑。█ 谷歌网络情况简介如图所示谷歌的网络主要分成三大部分B4、B2也叫Espresso以及Jupiter。其中B4是谷歌的数据中心互联网络连接了谷歌全球的数据中心。B2是谷歌面向互联网的网络负责将用户业务从全球各地的POP点引入到数据中心。而Jupiter则是谷歌数据中心的内部网络。这里再补充谈一下谷歌网络承载的业务流量属性。直到现在很多运营商专家都表示谷歌的流量基本是自有业务因此可控性好更适合SDN。而运营商网络的流量情况则过于复杂。事实上随着谷歌产品线的扩展尤其是云服务业务的增长谷歌网络内的流量不可预测性也在不断提升。很大一部分流量已经不再是自有业务。█ 谷歌的第一代SDN谷歌的第一代SDN控制器Onix总的来说有这么几点值得注意一是Onix本身是合作研发而非自研二是Onix的引入是一个循序渐进的过程三是Onix是一个单体molonithic程序。Onix的研发是Nicara、NEC和谷歌合作进行的甚至Nicara的专家还扮演了非常重要的角色。但到了Orion从论文上看作者已经是清一色的谷歌员工。可以说谷歌的网络团队在这几年中是在飞速成长的。Onix投产的过程也是循序渐进的大概花了三年完成切换。第一阶段是2010年开始引入openflow交换机但新交换机对外的表现和传统交换机一样只是网络协议运算在controller而不是设备本身完成。第二阶段是一个漫长的流量切换过程。直到2012年开始流量才完全切换到openflow网络。Onix作为一个单体程序其很多固有局限性基本无法解决这也是Orion出现的理由。单体程序在稳定性和开发速度上都存在很大的劣势。以谷歌的实力发布一个新版本都需要5个月这个节奏和业务发展是明显不相称的。微服务版本的Orion上线后两周就可以发布一个版本并且还有望提升到一周。分布式程序稳定性大增控制器完全崩溃的几率变得更小。█ Orion的整体情况Orion本身的工作模式一个词总结就是调和reconciliation。一方面Orion接收网络管理方人或者上层应用的意图并层层翻译。另一方面不断地感知当前网络的实际运行状态然后将网络的运行状态逐渐调整向管理方意图靠拢。从设计的根本原理上看和Kubernetes的原理几乎一致。而从架构上看Orion则是一个典型的微服务应用。最上层是各种具体的网络应用如负责域内算路的Routing Engine以及负责BGP广播的Raven等。中间的核心层主要实现了控制器的通用功能包括一个集中的NIB数据库兼具消息队列功能和负责处理配置、拓扑及流表生成的管理器以及用于和路由器通信的OFE。各个模块之间都是微服务主要通过NIB承载的消息进行交互这也很好的保障了故障隔离性及开发的可协调性。值得注意的是Orion控制的所有路由器均只有openflow协议栈没有传统协议栈包括BGP信息的广播和接收都是在控制器上完成可以说彻底实现了SDN化。当然出于安全性的考虑Orion并不是一点集中的控制器而是分域部署的。这在牺牲一些全局性带来的优势如算路更优流表更新更快等的同时也最大程度确保了网络的健壮性。█ Orion的设计考虑作为面向超大规模生产网络的控制器意图驱动intent-based是必然选择。谷歌表示宏观的意图远比细锁的过程更稳定更不容易出错。因此Orion本身就被设计为一个逐层翻译和细化意图的控制器最终会将管理人员的意图翻译为交换机可识别的openflow原语primitives。Orion处理故障的原则也非常值得学习对于小问题积极处理对于大问题则直接躺平不干涉数据面状态。如图所示一个数据流自顶向下的三层路由器网络中如果感知到2个路由器损坏则Orion会牵引流量绕开损坏的路由器这就是fail-closed。而如果感知到四个路由器都损坏了则Orion不会再做任何操作保持数据面当前状态也就是fail-static。这是因为一方面小问题Orion可以在不影响现网流量的情况下进行处理但大问题的处理则会严重影响现有业务另一方面数据面出现大问题的几率其实很小更大的可能是管理通道或者控制器本身出现问题因此感知到大面积故障误报的可能性很大。最后一点是关于管理通道的问题。一般认为带外管理因为具有单独的管理通道会是更可靠的方式。但管理通道本身也可能损坏且大量网元均通过带外管理也会产生巨大的成本。因此Orion采用了带内管理和带外管理相结合的方式一方面只对重要设备进行带外管理这样节省了大量成本另一方面带内管理和带外管理互为备份避免管理通道的损坏导致网元彻底脱管。 █ 结语网络运营追求的无非是安全和高效。SDN本身就是为了高效而生的经过业界多年的实践这一点已经没有太大的争议其效率的提升是实实在在的。而现在争议最大的主要聚焦在安全和实施成本上。考虑到网络的自然迭代成本其实不是问题逐步转型就好。谷歌也不是一夜之间把路由器都替换掉的。而安全方面我想谷歌的论文以及业界的其他实践已经解答了很多技术上的问题。剩下的问题更多是意识层面的是靠算法调度流量更安全还是深夜的双人割接更安全是靠经验反复分析、层层把关的割接报告更可靠还是软件自动计算的drain analysis更准确这些问题的答案并不是那么显然因为安全的定义其实是很复杂的。总的来说遇到的困难不少取得的成果也不算大。但我仍然坚信SDN就是未来。毕竟梦想还是要有的。往期推荐虚幻引擎5上的《黑客帝国》全新体验爱了爱了元宇宙真的是割韭菜吗Log4j 第三次发布漏洞补丁漏洞或将长存低代码发展专访系列之六低代码平台能解决业务重构的问题吗点分享点收藏点点赞点在看
