网络通信 频道

SDN颠覆之路:步子太大恐怕容易扯着..

    【IT168 技术】整个网络业界正痴迷于软件定义网络概念作出的种种美好承诺,但人们却忘记了OpenFlow以及VXLAN这类需要权衡的技术元素。

  作为思科公司CEO,John Chambers曾在上一次思科Live大会的主题演讲当中放出明确的信号:“颠覆或者被颠覆,”这意味着如果我们的企业无法顺应这股发展潮流,则必然被其无情吞没。而在网络行业当中,这股以颠覆为核心的发展态势则紧紧围绕着软件定义网络(简称SDN)拓展开来。

  然而由于通过软件定义网络实现颠覆的意愿太过强烈,人们往往忘记提出正确的问题。如果大家已经对这一议题进行过较长时间的关注,就会发现推进的重心一直在中央集权与权力下放两种倾向之间游移不定。以Russ White以及Ivan Pepelnjak为代表的众多网络技术大师也在向软件定义网络提出质疑,而非一股脑接受其宣扬的理论。

  作为一名网络架构师,我将在接下来的内容中为大家提供一些规则或者指南,帮助各位掌握来自《最优路由设计》以及《网络架构的艺术》等网络设计论著当中的经验及结论。我还将提到其中部分重要准则,希望大家能在着手进行软件定义网络应用以及相关新技术的部署之前作为参考:

  · 将复杂性从复杂性当中剥离出来

  · 不要重新发明轮子

  · 状态是要花钱的

  · 在网络边缘位置保持智能元素

  · 始终保有权衡空间

  · 管理故障域的大小

  让我们先从OpenFlow着眼。这是一套协议,旨在将控制层与数据层加以分离,并利用一套控制器以程序化方式引导交换机推动或者卸下流量。OpenFlow在一年之前曾经风靡一时,但如今其发展脚步似乎开始放慢。为什么会这样?就我个人来看,这是因为过去流交换领域所犯下的诸多错误如今仍在不断重演。

  状态是要花钱的。状态化方案在扩展能力方面仍然无法与非状态方案相比肩。出于这项原因,只有在转发行为不能遵循普通转发规则的情况下,我们才应该安装状态。Segment Routing(简称SR)在这方面作出了颇具吸引力的承诺。OpenFlow也能够在非MPLS网络当中实现同样的功能,但我仍然不太信任这种以纯控制器形式实现的转发机制。

  根据同样的思路,人们是否会寻求与软件定义网络相关的权衡性技术方案?如果大家还没有找到任何可以作为权衡空间的元素,那一定是搜寻的目光还不够犀利。人们希望拥有智能化水平、出色的速度表现以及低廉的使用成本——但我们往往只能从中选择两者。没错,网络硬件的价格确实越来越低,而且白盒交换机的出现也让我们多了一种廉价方案选择,但有取必有舍——这始终是一条颠扑不破的真理。

  在我看来,网络行业对于隧道技术也抱有一种不切实际的自信。VXLAN曾经被誉为自切片面包以来最出色的发明,但它只是一项隧道技术——或者说封闭手段。除了能让我们比VLAN——其规模化能力极差,特别是在多租户网络环境之下——获得更多识别机制之外,它并没有带来更多令人兴奋的亮点。事实上,我们完全可以利用隧道技术拿出更多振奋人心的成果。大家如何管理自己的隧道并实现隧道当中的信息可视化目标?您的底层设计方案是否恰当?其核心实质仅仅是IP,对吧?这就像是平地起楼,如果大家在地基层面偷工减料,那么最终成果再漂亮也只能成为遇风即倒的豆腐渣。

  我发现业界对于fabric同样给予了高度关注。没错,fabric确实非常出色,但一旦出了问题、其结果却往往令人难以承受。如果大家把一切都塞进fabric,建立起一套庞大的故障域,那么相当于在本质上将所有鸡蛋都放进同一个篮子里。需要再次强调的是,您是否从权衡角度考量过这样的方案?我并不是在否认fabric的实用性,只是想提醒大家,它并不是我们能够选择的惟一解决方案。

  那么我的观点到底是什么?

  我的观点在于,目前网络行业实在是把太多精力放在了颠覆身上、甚至将其作为首要诉求,但人们却往往没能提出正确的问题并对权衡空间作出考量。我发现人们仍在不断犯下过去早已出现过的错误,甚至为了颠覆而重新发明轮子。

  我个人认为,利用BGP、EVPN、SR以及MPLS等协议以更为渐进的方式向软件定义网络过渡才是最理想的方式。我们的主要注意力应该集中在利用现有而且经过时间考验的协议方面,而后再尝试发明用于支撑技术颠覆的新型协议。目前很多创新项目正在不断推进,最终我们也必将从中获得堪称伟大的实际产品——不过在此之前,眼前的道路仍然漫长而且坎坷。

0
相关文章