本发明涉及云计算与软件定义网络领域，特别涉及一种用于云计算网络虚拟化中的sdn控制器架构。
背景技术：
现代的云计算平台往往借助于sdn技术来实现网络虚拟化，例如openstack平台的neutron插件或者dragonflow插件。因为sdn比传统的架构提供更高的灵活性，更适应云计算平台中动态为虚拟机创建和分配各种网络服务的需求。neutron插件只使用了部分的sdn技术，而dragonflow插件则比较完整地采用了sdn技术。
最早的openstack的dragonflow插件，采用了单控制节点与多个agent的架构。单个控制节点在性能上可能成为瓶颈，在可用性上存在单点失效的问题。dragonflow后来推出了新的分布式dragonflow。分布式dragonflow需要在所有的计算节点上安装sdn控制器，控制节点的数量与云计算平台的计算节点数量一致，各个sdn控制器之间通过分布式数据库同步数据。分布式dragonflow解决了单点问题，但是这样的缺点是，控制节点需要与计算节点竞争资源，在计算节点负荷较大时，控制节点可能缺少足够的资源处理sdn请求。云计算平台具有弹性伸缩的特点，计算节点的增加和减少是根据计算节点的负荷决定的。系统不能根据sdn控制节点的负荷增加减少控制节点数量。
传统的sdn控制器大多使用关系数据库作为数据存储层。关系数据库的优点是提供较强的数据一致性和可用性，也就是从cap原理（任何分布式系统只可同时满足一致性、可用性、分区容错性三者中的二点。）的角度来说，关系数据库属于ca数据库。也就是说关系数据库强调数据的一致性，但是很难做到弹性伸缩。但是在云环境下，sdn控制器的数据存储吞吐量往往会有较大的涨落，而基于key/value的数据库，例如redis，更适合云环境下的数据存储。
关系数据库的另一个缺点是，因为关系数据库的查询使用sql语句，常用的编写sdn控制器的语言例如python、java，是面向对象的。导致阻抗不匹配。使用key/value数据库也有助于解决这个问题。
技术实现要素：
本发明所要解决的技术问题是应用于云计算网络虚拟化中的sdn控制器架构。它通过将sdn控制器的控制逻辑处理和状态存储分离，实现了一种可以根据各种不同的网络虚拟化应用，灵活地弹性伸缩控制节点和存储节点数量的sdn控制器架构。它同时也是一种相比于传统的高可用实现方法，更节约资源的实现sdn控制器高可用性的方法。
与传统的sdn控制器不同的是，为了使控制节点的数量能够弹性伸缩，本发明中的控制节点应该只提供无状态服务。这里的无状态指的是控制节点上不保存应用状态，处理一次请求所需的全部信息，要么都包含在这个请求里，要么可以从存储节点获取到。无状态服务的好处是，一次请求在任何一个控制节点上处理的结果都是一样的，计算节点上的代理可以将一次请求发送到一个控制节点，下一次请求发送到另一个控制节点。系统可以只根据控制节点的负载情况分配请求，对处理的结果没有任何影响。增加新的控制节点时，系统只需要将新的请求发送到新增的控制节点，因为处理请求的上下文都在请求中，或者存储在存储节点上，新增的控制节点处理请求的结果与已有的控制节点完全一样。当系统需要删除某一控制节点数量时，系统可以等待当前节点正在处理的请求处理完成后关闭并删除这个节点，其余的控制节点可以继续处理后续的请求，程序的正确性不受任何影响。
控制节点通过插件api的方式访问存储集群。存储集群可以是任意的key/value分布式数据库集群，例如，redis。系统可以根据不同的场景和需求更换存储集群。存储集群负责应用状态的持久化，具体的细节根据具体的存储集群配置。
系统可以根据应用和负载的需要弹性伸缩存储节点数量，并且通过能够重新平衡存储节点的哈希算法，例如一致性哈希算法，平衡存储集群上的负载。
为了保证存储集群能够弹性伸缩，所用的哈希算法应该具有以下特点：
（1）将应用状态的key和存储节点集群中的存储节点建立映射关系，从而将key分布到不同的存储节点上；
（2）保证平衡性，即key尽可能的分布到所有存储节点上，使所有存储节点都得到利用；
（3）保证单调性，即有新的存储节点加入到存储节点集群中时，已分配到原有存储节点上的key可以被映射到新的存储节点上；
（4）保证一个特定的存储节点，在不同的控制节点上映射为相同的内容。
存储集群弹性伸缩的方法如下：
(1)在进行实际的伸缩之前，根据伸缩后的存储节点集群计算重新计算已存储的应用状态id的哈希值;
(2)如果有需要添加的存储节点，将其加入集群，并将映射到新存储节点上的应用状态key/value从旧的存储节点移动到新的存储节点上;
(3)如果有需要移除的节点，先将其上存储的应用状态key/value移动到重新计算哈希值后映射的存储节点上，然后将其移除出存储集群。
每个控制节点在加入集群时都会被分配一个唯一的id。
控制节点为收到的每个事件分配一个唯一的序列号id，后接受的事件id应该大于先接受的事件id。
控制节点的应用状态以key/value的形式存储在存储节点上。key应该是根据请求中全局唯一的信息生成的，例如，对于为虚拟机分配ip地址的应用，虚拟机的openstackuuid是唯一的，可以用虚拟机的uuid作为key，虚拟机的网络信息，比如mac地址，ip等作为value。
控制节点失效应该被及时的检测到，失效检测机制可以由zookeeper或者某种gossip协议实现。
控制节点失效时。要保证事件处理的交易完整性。控制节点改变存储在存储节点上的状态的操作分为四种：1、增加，增加一个键值对；2、删除，删除一个键值对；3、更新，更新一个键值对，将某个键的值更新为另一个值；4、查询，查询一个键值对，即查询一个给定的键对应的值。其他更复杂的操作都可以分解成这四种操作的组合。
在处理事件之前先对事件进行保存，保存的方法是，步骤一：根据收到事件的控制节点id和事件id生成一个唯一的key，这个key是使用哈希算法根据控制节点id和事件id生成的哈希值；步骤二，控制节点依据收到事件生成value，这个value的属性包括：一）事件的二进制表示，或者事件的某种序列化，控制节点应该能够通过解析或者反序列化value重新生成事件，二）收到时间的控制节点id，三）事件id四）事件交易完成标记，如果设为true，代表事件交易已经处理成功；步骤三，控制节点将key,value保存在存储节点上。
系统应该根据事件的控制节点id和事件id生成和维护二级索引，方便控制节点根据控制节点id和事件id查询事件。
处理事件中，如果被处理的事件需要交易完整性，则控制节点要保存操作信息和回滚信息。保存的方法是：步骤一：每次执行更改控制器状态的操作之前，首先生成一个唯一序列号。后执行操作的序列号必须大于先执行操作的序列号，例如，先执行一个增加操作，后执行一个更新操作，增加操作和更新操作的序列号可以分别是1和2。步骤二：根据控制节点id，事件id和序列号生成的哈希值；步骤三，为每个需要保存的操作生成value，这个value中应该包含以下属性，一）操作类型。操作类型应该是增加、删除、更新三种操作之一。二）操作信息，对于增加操作，操作信息的内容是新增加的key/value；对于删除操作，操作信息的内容是删除的key/value；对于跟新操作操作信息的内容是key、更新前的旧value和更新后的新value；步骤三，控制节点将key,value保存在存储节点上；三）控制节点id；四）事件id；五）操作序列号；六）操作完成标记，如果设为true，代表操作已经完成。
每个操作完成之后要标记该操作已经完成，例如，在操作信息中增加一个标志操作是否已经完成的标记。处理事件的操作和标记操作是否已经完成应该是原子化的。如果系统使用的分布式key/value数据库不支持原子化操作，可以使用支持原子化操作的关系数据库存储操作信息，因为只需要保存当前正在处理的需要交易完整性的事件的操作，所以并发的读写量不大，不会影响系统性能。或者通过zookeeper实现两阶段提交协议。
系统应该生成和维护操作信息的二级索引，以方便根据控制节点id，事件id和操作序列号查询操作信息。
处理事件之后，要通过修改事件的完成标记保存交易是否已经完成。
一个控制节点失效时，另一个控制节点可以继续处理。另一个控制节点首先检查是否有未完成的事件处理，可以根据存储节点上存储的操作信息决定继续处理事件还是回滚。继续处理的方法是：步骤一,查询失效控制节点的未完成事件；步骤二，查询未完成事件的操作信息；步骤三，根据操作信息和系统状态决定是继续完成交易，放弃交易还是回滚交易。
回滚交易的方法是：步骤一，查找未完成事件的操作信息中序列号最大的已完成并且未被回滚的操作；步骤二，回滚这一步操作，回滚一个操作的方法是执行一个反操作，反操作分为三种1）新增操作的反操作是删除操作，删除新增的key/value；2）删除操作的反操作是新增操作，新增被删除的key/value；3）更新操作的反操作是更新操作，将key的value更新为保存在操作信息中的旧value；步骤三，标记此操作为已经回滚；步骤四，重复步骤一到步骤三直到所有已完成操作都已经被回滚。