总结分享一下最近关于多控制器开发与研究的入门时的疑惑。
实验环境是FLoodlight 0.9和Open vSwitch 1.9,由于两者都仅支持OpenFlow 1.0协议,而多控制器的支持是在OpenFlow 1.2以后才加入的特性, 那是否可以在目前的实验环境下进行一些简单的多控制器开发实验呢? 经过查询,发现ovs支持如下命令:
#ovs-vsctl set-controller br0 tcp:192.168.0.1 tcp:192.168.0.2
即直接在单个网桥上连接多个控制器。
我猜想这个命令可能是把写在前面的ip地址作为主控制器,后面的作为备份控制器,主控制器失去链接后交换机会主动连接备份交换机。 那通过这条简单的命令是否就可以实现多控制器的主备切换呢?
做了简单的验证实验,答案是否定的。得出的结论是交换机不仅同时连接了两个控制器,而且同时向这两个交换机发送同样的消息,控制器也同时向交换机下发消息或者安装流表。 即这两个控制器在逻辑上是没有任何差别的。
随之而来的疑问就是这样做的话,将会带来巨大的流量开销和状态信息的不一致, 单单支持同时连接是没有意义的,那目前的实验环境是否支持控制器之间简单的协调机制比如角色的分配与协调呢?
通过查看Floodlight的源代码,发现核心代码中已经实现了一些对多控制器的支持,比如控制器可以向交换机发出角色变更的请求等,可以说这是对OpenFlow1.2以后的预实现。 但另一端的Open vSwitch是否支持多控制器的角色请求的应答呢?
继续做验证实验,在控制器端添加发送角色请求的相关代码,发现确实可以实现控制器的角色分配。抓包查看发现,控制器角色变更的请求与回复都是在OF协议的Vendor消息中包含,查看OpenlowF 1.0 spec中关于Vendor消息的说明,Vendor消息提供额外的附加信息功能,为未来版本预留。
因此猜测Open vSwitch在Openlow1.0的基础上实现了对多控制器的扩展。
查看FLoodlight源代码,在org/openflow/vendor/nicira/OFRoleReplyVendorData.java
的注释说明中写道
Class that represents the vendor data in the role request extension implemented by Open vSwitch to support high availability.
猜测得到验证。在Open vSwitch的mail list中得到里进一步确认。
Add support for multiple OpenFlow controllers on a single bridge.
With this commit, Open vSwitch permits a bridge to have any number of OpenFlow controllers. When multiple controllers are configured, Open vSwitch connects to all of them simultaneously. Details of configuration are in the vswitch schema documentation.
OpenFlow 1.0 does not specify how multiple controllers coordinate in interacting with a single switch, so more than one controller should be specified only if the controllers are themselves designed to coordinate with each other.
An upcoming commit will provide a simple means for coordination between multiple controllers.
Add support for master/slave controller coordination.
Now that Open vSwitch has support for multiple simultaneous controllers, there is some need for a degree of coordination among them. For now, the plan is for the controllers themselves to take the lead on this.
This commit adds a small bit of OVS infrastructure: the ability for a controller to designate itself as a "master" or a "slave". There may be at most one master at a time; when a controller designates itself as the master, then any existing master is demoted to slave status. Slave controllers are not allowed to modify the flow table or global configuration; any attempt to do so is rejected with a "bad request" error.
HP ProCurve switch的mail list中也提到了Open vSwitch中关于多控制器的说明
Like Open vSwitch, our implementation will NOT fall back to a second controller, it will only fall back to "secure" or "normal".
Like Open vSwitch, if you specify multiple controllers, it will connect to all of them simultaneously. Like Open vSwitch, we do implement the Nicira extension to set each controller connection to master or slave. With this scheme, the controllers themselves manage the fall back and decide which of the controllers is elected master, the switch does nothing.
得到的结论就是,在OpenFlow 1.2以上版本没有大范围普及的情况下,可以继续在当前配置环境下进行多控制器的入门研究。