SDN控制器三大用处

小伙伴们在生活的过程中会遇到很多问题，比如有些小伙伴对SDN控制器三大用处不是很懂，不过没有关系，小编今天就给大家详细讲解一下这个问题，具体内容如下。

SDN控制器是网络的操作系统，是软件定义网络中的应用程序。它负责流量控制以确保网络的智能，允许服务器告诉交换机向哪里发送数据包。基于软件的网络控制使得服务应用和网络的集成更加容易。

1.南行接口

这方面描述的很好。开关来自不同的制造商，控制器来自不同的制造商。如何让它们互联互通？本质上，这不是技术问题，而是不同厂商的利益问题。ONF的OpenFlow和OF-Config，思科的OpFlex，甚至一些厂商都使用XML/Json+REST API。按照目前的情况，南向接口标准很难建立。

OpenFlow+OF-Config是目前最好的选择，标准相对完善，开源实现完整，部分厂商已经开始支持OpenFlow1.3和1.4。基于OpenFlow的系统已经在谷歌部署。

对于OpFlex和ACI，博主们还是持观望态度。如果没有思科之外的其他交换机厂商的支持，用户仍然会陷入厂商锁定的困境，可能很难通过SDN节约成本。

博客作者对于采用XML/Json+REST API作为南向接口没有强烈的偏好。许多云服务提供商使用REST API将配置从控制器推送到交换机。唯一的问题是，这种集中的配置管理实际上只是传统网络中包装的一个功能，交换机仍然通过传统的二层和三层协议互连。这种方案不会节省网络部署和运维的成本。相反，由于这一新特性，企业可能不得不购买额外的软件并雇用额外的工程师来开发和维护这一新特性。这也从一个侧面解释了为什么有些企业在部署了所谓的SDN之后，成本反而增加了:他们的SDN不彻底。

2.分布式状态管理

也许你会问:SDN是集中控制的，哪里需要分布式的状态管理？但其实这是一个很难的问题。博主们会在后面的文章中详细讨论这个问题。这里给大家举一个例子:假设SDN网络中的一条链路突然断了，交换机通知SDN控制器这个事件。SDN控制器决定将通过这条链路的所有流量移动到另一条路径，换句话说，只有一条链路断开，新旧路径上的每个交换机都需要相应更新。更复杂的问题是:SDN控制器应该以什么顺序更新许多交换机？由于SDN控制器与交换机之间的通信延迟、控制平面的拥塞和交换机CPU的负载，SDN控制器发送给交换机的Flow_Mod会乱序生效。然后，在更新流表的期间，网络处于完全不可描述的状态。在此期间，可能会出现拥塞、数据包丢失和路由黑洞。如果这段时间足够短，整个网络会立刻从上一个稳定状态进入下一个稳定状态，需要大家都能接受。但是如果这种状态改变因为某种原因失败了，我们允许网络处于未知的中间状态吗？我们需要像数据库一样支持网络状态回滚吗？通过这个简单的例子，我们发现很难让SDN控制器和网络中的所有交换机保持同步。如何解决这个问题，博主们会在后面的博文中分享一些经验教训。

3.从用户模型到转发模型的映射

正如马丁所说，这个问题是SDN中最难也最容易被忽视的问题。让我们头脑风暴一个场景，看看这是什么样的问题:Blogger我刚刚用最高的SDN技术构建了一个多租户数据中心。我很高兴欢迎第一个租户(tenant)，他的要求是建立一个网站，有2个web服务器和1个数据库服务器。Web服务器和数据库属于不同的子网，所以需要在web服务器之前部署防火墙。web和数据库之间的通信只允许在TCP端口1234上进行。可惜这位租客希望自己能一站式完成以上所有配置。让我们想想这个要求意味着什么。首先，SDN控制器要允许不同的租户登录，每个租户只能看到和配置自己的网络和服务。其次，SDN控制器需要定义一套配置语言，而这种语言只需要描述业务逻辑，与底层网络无关。第三，在租户定义完成后，SDN控制器需要将租户的配置转换成网络中的真实流表，而不管实际网络的拓扑结构如何。在上面的例子中，SDN控制器甚至需要部署防火墙等网络服务。一些数据中心使用特殊的硬件来执行这些网络服务，因此SDN控制器必须准确计算和更新流表，以确认网络流量将沿着正确的路径通过这些硬件服务节点。

在设计SDN系统时，还存在一些更为棘手的问题，如高可用性、零接触供应、无命中升级等。它将在随后的博客文章中涉及。在这里，博主只想强调一点，要设计一个最基础的SDN系统，这里所说的三个方面都必须经过仔细的考虑、设计和构建。

以上是我们及时介绍的SDN控制器的三种用法，想了解更多精彩教程请继续关注我们的网站！