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控制器的三个用处,想了解更多精彩教程请继续关注脚本之家网站!
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)