修复SDN路由故障?没那么简单!

两年前,我曾经写到过:修复软件定义网络故障需要使用数据包穿梭机才能在快速变化的动态网络中理清复杂且快速变化的拓扑。此外,企业正在加速迁移到混合云 网络,这使得我们更加依赖目前无法轻松控制的服务提供商网络内部路由。

两年前,我曾经写到过:修复软件定义网络故障需要使用数据包穿梭机才能在快速变化的动态网络中理清复杂且快速变化的拓扑。此外,企业正在加速迁移到混合云 网络,这使得我们更加依赖目前无法轻松控制的服务提供商网络内部路由。

网络结构会在防火墙两端自动定期重新配置,那么网络工程师又该如何修复快速变化、路由波动或最新变化等问题呢?SDN路由新工具可以解决这些问题,但是它 们与我们以前使用的工具大相径庭。

远程分析网络行为

科学的一个重要原则就是可再现性,其他研究人员按照相同的流程就能够在类似的条件下获得相同的结果。如果说网络中有属于科学范畴的东西,那它一定是命令 行。它的功能限制有严格的用法规定,虽然不同完全不变,但是重复执行相同命令会产生相同的操作。此外,它相对较为昂贵,因此在我们尝试理解为什么在一个特 定时间会出现网络异常时,它能够保证结果的稳定性。在半夜反向工程Mike所作的修改时,搞清楚“为什么Mike要修改防火墙规则?”这个问题是合理且有 意义的。

Mike、Kirstin和我自己的成本在于同为高水平管理员却要在凌晨3点的维护期间做一些效率低下的事情。通过命令行配置网络是一件耗时、容易出错且 最容易让网络速度产生巨大变化的方法。

其中还有一个副作用是,低基数(人数少)可以让我们在大脑中构思出有用的拓扑模型。我们能记住重要路由中的链路和节点,因为它们是我们自己建的。当服务出 现问题时,我们能回忆起最可能导致问题的错误特性,还有更重要的是修改过的节点。我们就会用命令行接口(CLI)连接该主机,修复问题,然后关掉问题单。

修复复杂路由中的故障

SDN是一把双刃剑:实际上可任意修改。在SDN路由中,在任何1台路由器上添加首选的下一跳路由,跟在100台路由器上操作是完全相同的,而且管理员在 图形化界面上可以快速地创建多个目标的连接,修改过程中完全没有任何障碍。

我们不要忘记了,IT喜欢在遇到棘手问题时修改网络。在出现VMware之前,你还记得自己有多频繁地重新配置物理服务器吗?现在,你又多频繁地修改虚拟 机(VM)呢?SDN将同样的功能带到了网络中。

就像是客户机几个小时发生一次变化,然后要在4个小时之后才去修复虚拟机操作系统的问题。只是分析网络的当前状态还不够——我们的网络故障修复工具需要支 持及时回滚路由变化,同时要能修复可能只存在几分钟的路由问题。这种问题早就存在于运营商网络中;只是现在我们也开始遇到同类的问题了。

可视化SDN路由工具

新型网络工具注重发现和监控网络路径。路径并不像传统意义的路由,因为它们有4个维度。一条路径有一对流量终端,以及所有可能用于传输数据包的路由,但是 它只能按照特定时间进行捕捉和监控。由于路径具有相当的复杂性,特别是在互联网路由中,这些网络故障修复工具并不是那种我们能轻松驾驭的汇总和点击查看明 细的典型仪表板工具。

这些新型SDN路由工具是交互式的,带有浏览和与上下文相关的浏览前端和中心。通过前后滚动连接可视化控件,我们就能对比不同时间捕捉的快照,从而发现网 络配置变化之后出现的复杂SDN路由性能问题。它们能够在大量链路中分辨出导致某一条配置错误链路出现的丢包原因。它们能够区分正常路径总延迟与路径中间 节点正常行为之间的差别。这一点很重要,因为它能够发现复杂网络中的问题,这些网络的长传输时间延迟可能会扩大总延迟时间。

两年前,我还不知道供应商是如何监控SDN的真实性能和拓扑,因为它总在通过编程来修改自身配置,甚至可能一天修改几百次。而且,我担心我们可能无法越过 SDN控制器的vRoutes和vLinks而全面了解应用程序状态。但是,最终我们看到一些新工具从实验室诞生,可能这也是一种革命性的进步(至少在网 络领域是的)。

或许我们已经遇到了一种实际的运营临界点,这时如果不使用监控工具去可视化展示SDN所制造的复杂状态,我们就不可能实现更多的自动化。今年可能会成为对 路由人员而言意义重大的一年——无论是软件驱动或是通过CLI手动配置的环境,无论是在数据中心或是云环境,都是这样。

来源:TechTarget中国

0赞

好文章,需要你的鼓励

2016

07/20

10:44

分享

点赞

邮件订阅
白皮书