SDN控制器是网络的一种操作系统，是软件定义网络中的应用程序，负责流量控制以确保智能网络,允许服务器告诉交换机向哪里发送数据包，基于软件的网络控制使得集成业务申请和网络更容易。
1. 南向接口
这个方面很好描述，交换机来自不同的厂家，控制器来自不同的厂家，如何让它们互联互通?本质上，这不是一个技术问题，而是不同厂商的利益问题。ONF的OpenFlow和OF-Config，Cisco的OpFlex，甚至有些厂家使用XML/Json + REST API。根据目前的情况，要建立南向接口标准困难重重。
OpenFlow + OF-Config是目前最好的选择，标准相对而言最完善，开源的实现最完整并且已经有厂家开始开始支持OpenFlow1.3和1.4了。基于OpenFlow的系统已经在Google得到了部署[link]。
对于OpFlex和ACI，博主还呈观望态度。如果没有Cisco之外的其他交换机厂商支持，用户仍然会陷入vendor lock-in的窘境，希望通过SDN节省成本可能会比较困难。
对于采用XML/Json + REST API作为南向接口，博主并没有特别强烈的偏好。不少云服务提供商的网络就是用REST API从控制器向交换机推送配置的。唯一的问题是：这种集中的配置管理其实只是包装在传统网络上面的一个feature，交换机之间仍然通过传统的二层三层协议互联互通。这种方案不会节省网络部署和运维的成本，相反，由于这个新的feature，企业可能还要购买额外的软件，聘请额外的工程师围绕这个新feature进行开发和维护。这也从一个侧面解释了为什么有些企业部署所谓的SDN之后，成本反而增加：它们SDN的不彻底。
2. 分布式的状态管理
也许大家会问：SDN都集中控制了，哪里需要分布式的状态管理呢?但事实上，这是一个非常棘手的问题。博主会在之后的文章里详细讨论这个问题，这里给大家举个例子先：试想在SDN网络中的一条link突然断了，交换机将这个事件通知了SDN控制器。SDN控制器决定将所有经过这条link的流转移到另外一条路径上，换言之，仅仅断掉一条link，新旧路径上的每一个交换机都需要做出相应的更新。更复杂的问题是：SDN控制器应该以怎样的顺序来更新众多的交换机呢?由于SDN控制器和各个交换机的通信延时，控制平面的拥塞状况，交换机CPU的负载不同，SDN控制器发给各个交换机的Flow_Mod会无序的生效。那么，在流表被更新的这段时间，网络便处于一个完全无法描述的状态。拥塞丢包，路由黑洞都可能在这段时间发生。如果这段时间足够的短，整个网络马上从上一个稳定的状态进入到下一个稳定的状态，大家也需可以接受。但是如果由于某些原因，这次状态变化失败，我们是否允许网络处于一个未知的中间状态?我们是否需要像数据库那样支持网络状态的回滚?通过这个简单的例子，我们已经发现，要维持SDN控制器和网络中所有交换机的状态保持同步是一件非常困难的事情。如何解决这个问题，博主会在稍后的博文中分享一些教训。
3. 用户模型到转发模型的映射
正如Martin所说，这个问题是SDN中最难也是最容易被忽略的一个问题。我们不妨集体脑补一个场景，看看这究竟是一个什么样的问题：博主我刚刚用最高大上的SDN技术搭建了一个支持多租户的数据中心(multi-tenancy datacenter)。我很开心的迎来了第一个租户(tenant)，这个租户的要求是建立一个拥有2 台web服务器和1台数据库服务器的网站。web 服务器和数据库属于不同的子网，在web服务器之前需要部署一个防火墙。web和数据库之间只允许在TCP端口1234上进行通讯。要命的是，这个租户希望自己能够一站式的完成所有以上的配置。我们仔细想想这个要求意味着什么。首先，SDN控制器要允许不同的租户登录，并且每个租户仅仅能够看到和配置自己的网络及服务。其次，SDN控制器需要定义一套配置语言，并且这套语言仅仅需要描述业务逻辑，和底层网络没有丝毫的关系。再次，在租户定义完成之后，不论实际网络的拓扑是什么样子，SDN控制器都需要把租户的配置转变为网络中实实在在的流表。在上面的这个例子中，SDN控制器甚至需要部署防火墙等网络服务。有些数据中心是使用专门的硬件来履行这些网络服务的，那么SDN控制器就一定要准确的计算和更新流表，确认网络流量会沿着正确的路径经过这些硬件服务节点。
在设计SDN系统时，还存在一些更难的问题，比如高可靠性(high availability)，自动化部署(zero-touch provisioning)，无丢包升级(hit-less upgrade)等等。之后的博文中会陆续涉及。在这里博主只想强调：要设计一个最最基本的SDN系统，这里所提到的三个方面是一定要仔细斟酌，设计和施工的。
以上及时脚本之家小编为大家介绍的关于SDN控制器的三个用处，想了解更多精彩教程请继续关注脚本之家网站！
