51学通信论坛2017新版

标题: SDN多控制器是如何实现的 [打印本页]

作者: admin 时间: 2017-9-17 14:08
标题: SDN多控制器是如何实现的
最近在ONS 2016（Open Networking Summit开放网络峰会）中华为T-SDN Super控制器凭借着持续的创新能力，从众多厂商DEMO中脱颖而出，获得了SDN IDOL 2016冠军。华为基于ONOS的T-SDN Super控制器解决了运营商网络多厂商多域网络业务快速发展、跨域协调保护等一系列难点痛点问题。

[attach]1118[/attach]

拓扑很简单，上层是super控制器。下面是多个子控制器。那么就引出这篇文章的内容：SDN多控制器是如何实现的呢？
交换机可与一个控制器建立连接，也可与多个控制器建立连接。当与多个控制器建立连接后可以增强可靠性，因为当与一个控制器连接失败后，交换机仍可继续工作在OpenFlow 模式下。控制器对交换机管理权的移交完全是由控制器自己管理的，这样做的好处是允许“快速失败恢复”，并且有利于控制器的负载均衡。控制器（controllers）之间通过什么机制，如何协调管理交换机不在此讨论范围内。多控制器的优点，只有在控制器之间切换时状态保持同步才起作用。多控制器旨在处理控制器的“失败恢复”和控制器的“负载均衡”。
这里只讨论控制器的“失败恢复”。
当OpenFlow操作被初始化，交换机必须与所有配置的控制器相连，并且尽力地同时地维持所有连接。多个控制器可能会发送controller-to-switch 命令到交换机，那么交换机就需要向相应的控制器回复。异步消息也可能需要发送到多个控制器，将消息复制多份，发给每一个合法的并愿意接收此消息的OpenFlow 通道。
控制器缺省的角色是OFPCR_ROLE_EQUAL，控制器对交换机有完全的访问权，并且每一个交换机在角色上都是平等的。缺省的条件下，交换机接收所有的Asynchronous messages（例如packet-in，flow-removed）。控制器可以发送controller-to-switch 命令去修改交换机的状态。交换机并不会给两个控制器之间做任何仲裁或资源共享。
控制器可以请求使自己的角色改为 OFPCR_ROLE_SLAVE。在这种角色下，控制器对交换机只有 read-only 访问权限。缺省条件下，控制器不接收除Port-status 消息以外的交换机 Asynchronous messages。交换机此时也禁止了执行controller-to-switch 命令的能力，不能再修改交换机的状态；也禁止了OFPT_PACKET_OUT、OFPT_FLOW_MOD、OFPT_GROUP_MOD、OFPT_PORT_MOD和OFPT_TABLE_MOD。如果控制器发送了那些命令，交换机必须回复以 OFPT_ERROR消息，消息的类型字段为OFPET_BAD_REQUEST，代码字段为OFPBRC_IS_SLAVE。其余的 controller-to-switch 消息，如OFPT_MULTIPART_REQUEST 和OFPT_ROLE_REQUEST，应该正常处理。
控制器可以请求使自己的角色变为OFPCR_ROLE_MASTER。这个角色与 OFPCR_ROLE_EQUAL相似，对交换机有完全的访问权，其不同之处是，交换机确保它是唯一的控制器。当一个控制器把自己的角色改为OFPCR_ROLE_MASTER，交换机就把其它的具有 OFPCR_ROLE_MASTER 角色的控制器改为OFPCR_ROLE_SLAVE。当交换机执行这种角色改变操作时，交换机将不再为角色被改变的控制器发送消息（多数情况下，控制器将不再可访问）。
一个交换机可能同时与多个处于同等地位的控制器相连。多个控制器处于Slave状态，至多一个控制器处于 Master 状态。每一个控制器都会通过一个OFPT_ROLE_REQUEST消息与交换机交流它的角色，并且交换机必须记住每一个连接的控制器的角色。控制器可能在任何时刻改变自己角色。
一个控制器也可以控制让哪些交换机的asynchronous messages通过自己的OpenFlow 通道，改变以上描述的缺省配置。以上那些改变都是通过一个 Asynchronous Configuration message实现的，不同控制器可以收到不同的通知，一个“主控制器”可以选择性地禁止它不关心的消息，而一个“从控制器”可以选择想要监控的消息。
从openflow1.3的官方文档上截取多控制器相关的字段：
A switch may be simultaneously connected to multiple controllers in Equal state, multiple controllers in Slave state, and at most one controller in Master state. Each controller may communicate its role to the switch via a OFPT_ROLE_REQUEST message, and the switch must remember the role of each controller connection. A controller may change role at any time.
意思就是说控制器需要跟交换机通信，告诉交换机自己是master还是slave，交换机必须记住各个控制器分别是什么角色。
这个代码就是交换机在给所有的控制器发送ROLE_REQUEST，然后控制器下发REPLY
Shell
g_controller_role = role;
role_req_info.generation_id = g_election_generation_id;
role_req_info.role = role;
for(; idx_sw < g_server.max_switch; idx_sw++)
{
if (g_server.switches[idx_sw].state)
{
sw = &g_server.switches[idx_sw];
if(sw && (sw->state))
{
ret = sw->msg_driver.msg_handler[OFPT13_ROLE_REQUEST](sw, (UINT1 *)&role_req_info);
}
可以使用Zookeeper管理交换机和控制器之间的关系，包括监测和反馈控制器是否失败；同时，如果一个控制器与Zookeeper失去连接，另一个控制器将负责控制此交换机。Zookeeper使用一个匹配的协议维持与控制器很大的一致性，且只要大多数控制器可用，Zookeeper就有很强的容错能力。

[attach]1119[/attach]

控制器可以维持一个全网拓扑视图，从而允许一个控制器集群内相互之间能分享和管理网络信息。其全网拓扑信息包括switch、port、link和host等信息。我们的DCFabric控制器使用Hbase进行存储（当然也可以采用其他方式），保障分布式和可持续性。由于Hbase具有一致性存储的特性，所以保障了网络拓扑图的最终一致性。
DCFabric使用Zookeeper来存储交换机和控制器之间的关系数据。每一个DCFabric都需要连接Zookeeper。Zookeeper曾经是Hadoop的一个子项目。现在已经好似一个顶级项目。它主要是用来解决分布式应用中经常遇到的一些数据管理问题，如：统一命名服务、状态同步服务、集群管理、分布式应用配置项的管理等。
下面的代码就是Zookeep如何对DCFabric进行信息交互的，以及将信息写入Hbase
Shell

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

if(OFPCR_ROLE_MASTER == role)
{
INT4 len = TABLE_STRING_LEN;
INT1 election_generation[TABLE_STRING_LEN] = {0};
INT1 master_id[TABLE_STRING_LEN] = {0};
g_master_id = g_cluster_id;
if(ZOK != zoo_get(g_zkhandler, SDN_ELEC_PATH, 0, election_generation, &len, NULL))
{
g_election_generation_id = strtoull(election_generation, 0, 10);
}
#ifdef HBASE_CLIENT
else
{
query_value(ELECTION_GENERATION_ID, election_generation);
g_election_generation_id = strtoull(election_generation, 0, 10);
}
zoo_set(g_zkhandler,SDN_ELEC_PATH, election_generation, strlen(election_generation), -1);
zoo_set(g_zkhandler, SDN_MASTER_PATH, master_id, strlen(master_id), -1);
#ifdef HBASE_CLIENT
persist_value(ELECTION_GENERATION_ID, election_generation);
persist_value(MASTER_ID, master_id);
return ret;
}

参考资料
OpenFlow Switch Specification 1.3.0
作者简介：
蒋暕青@上海宽带技术及应用工程研究中心：SDN技术实践者，大四北上思博伦实习半年，现工作地点上海
--------------华丽的分割线------------------
本文系《SDNLAB原创文章奖励计划》投稿文章，该计划旨在鼓励广大从业人员在SDN/NFV/Cloud网络领域创新技术、开源项目、产业动态等方面进行经验和成果的文字传播、分享、交流。有意向投稿的同学请通过官方唯一指定投稿通道进行文章投递，投稿细则请参考《SDNLAB原创文章奖励计划》
声明:本文转载自网络。版权归原作者所有,如有侵权请联系删除。

欢迎光临 51学通信论坛2017新版 (http://bbs.51xuetongxin.com/)