SDN前瞻 传统网络的缺陷

引言

---

在网络发展速度如此之快的今天，传统网络的架构充满了危机，主要有这四个问题：

• 传统网络部署管理困难。
• 分布式架构瓶颈出现。
• 流量控制难真正实现。
• 设备不可编程。

现在的网络厂商

---

• 种类繁多的网络厂商。

如何对网络设备进行操作？

---

• 从图中可以看到，不同厂商的网络设备混杂在一起使用。
• 但是不同厂商的网络设备要通过不同的方式进行部署（一般是通过Web和命令行），这就使得，对目前这种鱼龙混杂的网络进行统一配置，是一件很困难的事情。
• 但是它们的底层协议相同，互操作没有问题。

如何管理这么多网络设备？

---

• 目前我们通过搭建在服务器上的网管软件来管理。
• 比如比如学校利用的就是网管软件，架设在服务器中；网管软件生成网络的拓扑图，知道哪一台PC在哪里，出现故障能够进行报警。
• 主流的SNMP（网络管理协议），更多侧重于监控，而不是分配和部署。也就是说，如果网络出出现故障，通过网管报警，还是需要人为修理。

问题一：传统网络布署和管理非常麻烦

---

网络设备间如何协同工作？

---

• 网络设备之间，大部分都是采用 路由交换协议等 网络协议 来进行信息的交互。
• 协议的逻辑基础：
  1. 邻居建立
  2. 信息共享
  3. 选择路径
• 大部分网络采用的是典型的分布式网络架构：设备和设备之间相互交流路由信息，然后根据这些信息建立拓扑信息库，按照一些选路的算法计算路径。
• 说白了就是接力棒式的流程，你交给我，我交给他。
• 每个设备都有独立的CPU，独立运算。
• 协议是 网络设备的语言，相当于人类沟通的语言。

如果网络发生动荡，设备如何交互？

---

• 网络设备以接力棒的形式不断告诉下一跳邻居设备，然后将故障的链路删除。
• 但是可能会有多余的重复的信息。

当流量暴增或拓扑暴增时...

---

• 现在的云计算，大数据等互联技术的发展，导致网络中的流量越来越多，几乎以指数增长的形式上升，这使得底层网络设备的数量不断增加，压力越来越大，路由收敛的时间越来越长，效率越来越低。
• 数据中心网（互联网公司）、电信网（运营商），需要变革的意愿最强。

问题二：分布式架构瓶颈

---

网络带宽分配如何解决？

---

• 目前的负载均衡，并不是真正的负载均衡！下面的案例很大可能出现！

前往同一个目的地的带宽相同的路径A和B，有可能 A 95%的带宽都用于承担数据了，压力非常大，而 路径B 的带宽则只有20%利用率。

• 这张拓扑时数据中心里是非常容易发生的一件事情，当非常多的数据进来的时候，并没有完全的实现路径的负载均衡，这就很可能出现这种很危险的情况：某一个设备，在某一个瞬间压力过大崩溃了。
• 因此，当今网络最大的一个问题之一，就是流量的可视化。现在的流量控制设备，并不能做到对全网，全链路进行流量控制，进行合理的负载均衡。

有人可能会问，为什么不使得所有的 交换机和流量控制网络设备，实时监控和共享链路状态信息：是否拥塞，这样的话就能构建成一幅实时的流量图，根据这个流量图来进行流量控制？

虽然这个想法很不错，但是很遗憾，目前并没有一项技术能够支持构造实时的流量图：大部分流量控制设备都是独立进行控制的。

流量可视化难！

---

• 常规的网管软件，只能对故障进行监视，无法实现全网全局的链路状态检测。
• 常规的流量控制软件，只能实现区域化的流量控制，以及区域化的流量可视化。
• 理想化模型如下

问题三：流量控制是棘手难题！

---

能否自定义设备的转发策略？

---

• 传统的网络设备，工作方式是固定的：不修改目的IP地址和源IP地址，交换机根据MAC地址表进行转发，路由器根据路由表转发(不修改目的IP地址，不修改源IP地址，只修改MAC地址)。
• 根据业务需求，也就是客户需求，对转发设备的策略进行自定义，这和传统固定的转发策略大为不同：传统是厂商决定，用户很难对固定的策略做出改变；而SDN允许用户通过编程的方式，来实现自定义转发策略，达到一些特定的目的。

能否将软件运行在设备上？

---

• 我们买来设备的时候，里面的协议已经被订好。我们不能通过安装软件的方式来增加设备的功能。就算能的话我们也要通过重装OS等复杂的手段来实现。

问题四：无法按需，不可编程

---

总结：这些需求催生了SDN。