一种软件定义网络中分布式控制器的自适应选择方法与流程
本发明涉及软件定义网络领域，特别是指一种软件定义网络中分布式控制器的自适应选择方法。
背景技术：
软件定义网络正在吸引着学术界和工业界越来越多的关注，它解耦了网络的数据平面和控制平面，使得重构网络的控制平面变得更加自由。在软件定义网络中，数据流按照下列步骤被处理。首先，在一个交换机接收到一个新的流以后，这个交换机产生一个流请求，然后将它发送给一台控制器。其次，控制器根据全局的网络视图计算一条路径为这条流。然后，控制器产生相应的流规则，并将它们安装到路径上的所有交换机。最后，路径上的每个交换机查询它的流表和基于匹配的规则执行相应的动作。上述在一个交换机和控制器之间的交互过程产生了流请求的响应时延。实际上，许多因素能够导致更长的时延分布的尾部。单个控制器的能力不是足够的来快速处理接收到的流请求，这些流请求仍然经历着响应的长尾时延。随着网络规模的增长，由于有大量的流请求需要处理，单个控制器不可避免的成为了性能的瓶颈。同时，控制器上部署了许多的应用，这进一步加剧了控制器的负载。
为了实现可扩展的控制平面，研究者们提出了基于多控制器的分布式控制器。其中，onos和opendaylight是两个代表性的分布式控制器。为了减少响应的尾部时延，它们寻求控制器到交换机的分配机制。也就是说，主动地给每一个交换机分配一个控制器，从而使得每一个控制器管理相同数量的交换机。然而，单位时间内交换机所产生的流请求的数量是动态变化的，每个交换机所产生的流请求的数量也是有差别的。因此，在这种设置下，传递低的响应时延以及使得时延分布的尾部更短仍然是有挑战的。实际上，控制器每单位时间内接收到的流请求的数目是不同的。控制器之间的负载不均衡导致了长尾的响应时延。而且，这种控制器到交换机的分配需要控制器之间的协同，则进一步加剧了控制器的负载。
技术实现要素：
有鉴于此，本发明的目的在于提出一种减轻控制器响应时延的方法。
基于上述目的本发明提供的一种软件定义网络中分布式控制器的自适应选择方法，包括：当交换机接收到新的流请求时，所述交换机随机向至少两个控制器发送探测指令，所述控制器接收到所述探测指令后评估各自的响应时延，并将评估结果返回给所述交换机，所述交换机接收到评估结果后，选择最小响应时延的控制器，并将所述流请求发送到该控制器。
进一步的，当接收到的流请求的数目低于预设值时，所述交换机单独的为每一条流选择一个控制器，当接收到的流请求的数目等于或者高于所述预设值时，将所述流请求分批，并为每一批流选择一个控制器。
进一步的，当为每一条流选择一个控制器时，所述交换机随机向至少两个控制器发送探测指令，所述控制器接收到所述探测指令后评估各自的响应时延，并将评估结果返回给所述交换机，所述交换机接收到评估结果后，选择最小响应时延的控制器，并将所述流请求发送到该控制器。
进一步的，当为每一批流选择一个控制器时，预先设定批尺寸δ，当交换接收到第一条流请求时，所述交换机随机向至少两个控制器发送探测指令，所述控制器接收到所述探测指令后评估各自的响应时延，并将评估结果返回给所述交换机，所述交换机接收到评估结果后，选择最小响应时延的控制器，并将所述流请求发送到该控制器，同时将之后接收到的δ-1条流请求也发送到该控制器，其中δ为大于等于2的正整数。
进一步的，所述控制器采用以下函数评估自身的响应时延：
其中ψi表示响应时延，γi来表示控制器能够同时处理的流请求的数目，ri表示正在被处理的流请求的数目，
进一步的，还包括预先设定最大响应时延，当所述交换机接收到所述评估结果后，将所述评估结果与所述预先设定的最大响应时延比较，当所述评估结果小于或等于所述预先设定的最大响应时延时，将流请求发送至该控制器上排队等待处理。
进一步的，当所述评估结果大于所述预先设定的最大响应时延时，重新选择控制器。
从上面所述可以看出，本发明提供的控制器的选择方法包括：当交换机接收到新的流请求时，所述交换机随机向至少两个控制器发送探测指令，所述控制器接收到所述探测指令后评估各自的响应时延，并将评估结果返回给所述交换机，所述交换机接收到评估结果后，选择最小响应时延的控制器，并将所述流请求发送到该控制器。本发明实施例的控制器的选择方法，能够动态地平衡控制器之间的负载，克服了异构控制器条件下的性能波动的问题，有效地降低了控制器响应的尾部时延。
附图说明
图1为本发明实施例的控制器的自适应选择方法流程图；
图2为本发明实施例的控制器的自适应选择方法中控制器选择机制的框架图。
具体实施方式
为使本发明的目的、技术方案和优点更加清楚明白，以下结合具体实施例，并参照附图，对本发明进一步详细说明。
需要说明的是，本发明实施例中所有使用“第一”和“第二”的表述均是为了区分两个相同名称非相同的实体或者非相同的参量，可见“第一”“第二”仅为了表述的方便，不应理解为对本发明实施例的限定，后续实施例对此不再一一说明。
本发明实施例的方法在控制器同构的条件下，提出一个有效的负载意识的控制器选择策略，这个负载意识的选择策略通过随机地探测几个控制器的负载，然后发送流请求到负载较轻的控制器，从而能够动态地平衡控制器之间的负载，具体方案如下：
当交换机接收到新的流请求时，所述交换机随机向至少两个控制器发送探测指令，所述控制器接收到所述探测指令后评估各自的响应时延，并将评估结果返回给所述交换机，所述交换机接收到评估结果后，选择最小响应时延的控制器，并将所述流请求发送到该控制器。
进一步的，当接收到的流请求的数目低于预设值时，所述交换机单独的为每一条流选择一个控制器，当接收到的流请求的数目等于或者高于所述预设值时，将所述流请求分批，并为每一批流选择一个控制器。
进一步的，当为每一条流选择一个控制器时，所述交换机随机向至少两个控制器发送探测指令，所述控制器接收到所述探测指令后评估各自的响应时延，并将评估结果返回给所述交换机，所述交换机接收到评估结果后，选择最小响应时延的控制器，并将所述流请求发送到该控制器。
进一步的，当为每一批流选择一个控制器时，预先设定批尺寸δ，当交换接收到第一条流请求时，所述交换机随机向至少两个控制器发送探测指令，所述控制器接收到所述探测指令后评估各自的响应时延，并将评估结果返回给所述交换机，所述交换机接收到评估结果后，选择最小响应时延的控制器，并将所述流请求发送到该控制器，同时将之后接收到的δ-1条流请求也发送到该控制器，其中δ为大于等于2的正整数。
进一步的，所述控制器采用以下函数评估自身的响应时延：
其中ψi表示响应时延，γi来表示控制器能够同时处理的流请求的数目，ri表示正在被处理的流请求的数目，
进一步的，还包括预先设定最大响应时延，当所述交换机接收到所述评估结果后，将所述评估结果与所述预先设定的最大响应时延比较，当所述评估结果小于或等于所述预先设定的最大响应时延时，将流请求发送至该控制器上排队等待处理。
进一步的，当所述评估结果大于所述预先设定的最大响应时延时，重新选择控制器。
本发明实施例的控制器的选择方法，能够动态地平衡控制器之间的负载，克服了异构控制器条件下的性能波动的问题，有效地降低响应的尾部时延，减轻了控制器的负载。
如图1所示，为本发明实施例的控制器的选择方法流程图。从图中可以看出，本实施例的方法包括以下步骤：
步骤101：当交换机接收到新的流请求时，所述交换机随机选择至少一个控制器。
步骤102：所述交换机向选择的控制器发送探测指令。
步骤103：所述控制器接收到所述探测指令后评估各自的响应时延。
步骤104：所述控制器将评估结果返回给所述交换机。
步骤105：所述交换机接收到评估结果后，选择最小响应时延的控制器，并将所述流请求发送到该控制器。
在上述实施例的基础上，具体的，当接收到的流请求低于预设值时，所述交换机单独的为每一条流选择一个控制器，当接收到的流请求等于或者高于所述预设值时，将所述流请求分批，并为每一批流选择一个控制器。
进一步的，当为每一条流选择一个控制器时，所述交换机随机向至少两个控制器发送探测指令，所述控制器接收到所述探测指令后评估各自的响应时延，并将评估结果返回给所述交换机，所述交换机接收到评估结果后，选择最小响应时延的控制器，并将所述流请求发送到该控制器。
进一步的，当为每一批流选择一个控制器时，预先设定批尺寸δ，当交换接收到第一条流请求时，所述交换机随机向至少一个控制器发送探测指令，所述控制器接收到所述探测指令后评估各自的响应时延，并将评估结果返回给所述交换机，所述交换机接收到评估结果后，选择最小响应时延的控制器，并将所述流请求发送到该控制器，同时将之后接收到的δ-1条流请求也发送到该控制器。
进一步的，所述控制器采用以下函数评估自身的响应时延：
其中ψi表示响应时延，γi来表示控制器能够同时处理的流请求的数目，ri表示正在被处理的流请求的数目，
进一步的，还包括预先设定最大响应时延，当所述交换机接收到所述评估结果后，将所述评估结果与所述预先设定的最大响应时延比较，当所述评估结果小于或等于所述预先设定的最大响应时延时，将流请求发送至该控制器上排队等待处理。
进一步的，当所述评估结果大于所述预先设定的最大响应时延时，重新选择控制器。
更具体的，当一个新的流到达一个交换机，交换机将按照算法1的流程进行工作。首先，交换机随机地探测d个控制器，d≥1。然后，这d个控制器按照算法2的流程来评估它们各自的响应时延，并将评估的响应时延ψ返回给交换机。如果控制器i的响应时延ψi超过了最大响应时延rdmax的限制，控制器i将返回响应时延ψi＝-1。当交换机接收到d个控制器返回的响应时延，它将选择拥有最小的正的响应时延的控制器。如果所有控制器返回的响应时延都为负，这个交换机将重新选择一个响应时延没有超过最大限制的控制器。最后，交换机将发送流请求到所选的控制器。
算法1
算法2
如图2所示，为本发明实施例的控制器的自适应选择方法中控制器选择机制的框架图。控制器的自适应选择包含两个主要的构件：控制器选择(cs)和队列管理(qm)。cs构件能够实现控制器选择机制中所设定的轻量级、可扩展和爆发免疫的目标，qm构件能够实现自适应的目标。
当网络中只有少数的几个控制器，探测所有的控制器时可行的。考虑到探测将引发通信的过载以及加剧控制器的负载，有必要设计一种针对每个流的轻量级的探测方法。
主动的针对单条流的控制器选择方法：为了处理非均匀分布的流请求以及减少响应的尾部时延，交换机需要为每一条流选择一个控制器，代替以前的控制器到交换机的分配机制，主动的针对单条流的控制器的选择能够使来自相同交换机的流请求能够被不同的控制器处理，这样的选择策略能够充分利用网络中所有控制器的能力，从而减少响应的尾部时延。
为了减少探测控制器所带来的通信过载，一种方法是来减少探测的控制器的数量。在探测的控制器的数量和响应的尾部时延之间存在一种权衡。探测更多的控制器能够实现更短的响应的尾部时延，然而这也意味着更多的通信过载和计算过载。在此种情形下，探测所有的控制器花费是巨大的，因此，代替探测所有的控制器本发明实施例采用探测d个控制器的方法，d≥1。理论证明，与仅仅探测一个控制器相比，随机的选择两个控制器(也就是d＝2)，控制器端的最大负载将会有很大的缩减。基于这样的事实，本发明实施例主动的针对单条流的选择策略，每次只需要探测两个控制器，因此这种策略是可扩展的。同时，这也使得该选择策略能够有效地减少通信过载以及缓解控制器的负载。
代替探测控制器的负载，探测控制器的响应时延能够更好地减少响应的尾部时延。对于响应时延的探测需要控制器评估自身对于流请求的响应时延。因为本发明实施例的选择策略只需要获取控制器对于流请求的响应时延的数值表示，因此该策略是轻量级的。此外，控制器的异构的以及时间变化的处理能力也增加了对于响应时延的评估的复杂性。
主动的针对一批流的控制器的选择。当交换机接收到爆发的数据流或者是流请求的到达十分频繁，在这种情况下，即使每次仅仅探测两个控制器，若是为每一条流都执行一次探测，探测的代价也是十分巨大的。因此，可以为一批到达的流执行一次控制器的选择，这将有效地增加控制器选择机制的可扩展性，这样的选择机制也能够容纳交换机所遭遇的爆发的数据流。
主动的针对一批流的控制器的选择是指交换机在接收到这一批流中的第一个流请求时就执行一次控制器的选择，设定批尺寸的大小为δ，这就意味着后续到达的δ-1个流请求将于第一个流请求被发送到相同的控制器，它们共享第一个流请求到达时，所执行的控制器选择的结果。假设每个交换机产生的流请求服从一个参数为λ的泊松过程，此时，流请求的达到间隔将是一个服从参数为1/λ的指数分布，一批大小为δ的流请求的达到周期是服从参数为δ/λ的指数分布，这也意味着执行一次控制器选择的时间间隔是服从参数为δ/λ的指数分布。
此处，在执行控制器选择的次数以及控制器选择的最终效果之间存在着一种权衡。如果δ被设置的太小，显然将频繁地执行控制器的选择。但是，如果δ被设置的太大，那又将降低控制器选择的效果。但是，无论怎么选择δ值的大小，都应当落入本申请的保护范围内。
为了有效地减少流请求的响应时延，交换机需要能够为流请求选择拥有较低响应时延的控制器。
请求的响应时延由排队时延和处理时延构成。而且，排队时延与队列长度相关，队列长度是指控制器上排队的流请求的数目。同时，为了评估排队时延，它是必要的来评估每个请求的处理时间。规定控制器记录vj，也就是最近响应的第j个请求的处理时间，给定最近完成的流请求的数目s，计算
考虑到控制器能够同时处理多个流请求，本文采用γi来表示控制器controlleri能够同时处理的请求的数目。qi和ri分别表示控制器controlleri上排队的和正在被处理的请求的数目。为了提高整个系统的利用率，拥有空闲运行分片的控制器应该有一个更低的预估的响应时延。因此，当ri<γi时，控制器controlleri的响应时延
总结，控制器controlleri采用以下评估函数来评估响应时延：
当交换机发送一个时延评估请求到控制器controlleri，该控制器采用上述公式来为该请求评估响应时延。考虑一种特殊的情况，当γi＝1时，
由于每个交换机分别执行控制器的选择，于是可能存在“从众行为”，也就是多个交换机同时将请求发送到同一个控制器，这将使该控制器的性能迅速下降，并且将会导致较长的响应时延。此外，当探测的几个控制器都拥有较低的性能时，从这探测的几个控制器中选择一个控制器并不是一个最好的方法。
为了降低尾部时延以及减少“从众行为”的影响，控制器需要限制在其上排队的请求的数目。确定控制器端的最大队列长度的值是关键的，该值设置的太小，在两次分配之间将会导致资源的空闲，从而产生较低的控制器的利用率。该值设置的太大，队列很长，将会引发较长的响应时延。
当更少的请求被发送到一个控制器，这可能导致控制器上资源较低的利用。当请求需要更长的处理时间时，更长的时延将会产生。因此，在评估了请求的响应时延以后，本发明实施例进一步的设计了一种时延意识的限制机制来限制控制端的队列长度，这种机制能够容纳异构的以及随时间变化的控制器的处理能力。同时，限制控制器的队列长度能够有效地弱化“从众行为”的影响。在某一时刻，控制器接收到由于“从众行为”导致的爆发的流请求，使得队列的长度超过了限制。在接下来的一段时间内，新到达的流请求不会在该控制器上排队等候处理，直到该控制器上的队列长度低于最大长度的限制。本发明实施例所设计的基于时延意识的限制机制依赖于控制器为了流请求而进行的自身对于请求响应时延的评估。
特别地，本文设定一个请求允许等待的最大响应时延为rdmax，也就是说，当交换机决定是否要将请求发送到某个控制器controlleri上时，需要首先检测该控制器反馈的响应时延ψi。只有当ψi<rdmax时，该请求才有可能会在该控制器上排队等待处理。在执行一次控制器选择时，将探测d个控制器。如果这d个被探测的控制器都不满足响应时延的限制，该交换机需要重新选择一个新的控制器。采用这种方法，每个控制器上的队列长度将会根据控制器的处理能力得到动态的调整。
本发明实施例设定rdmax来使得请求能够偏向具有较强处理能力的控制器。此外，rdmax的值能够根据控制器的处理能力的变化得到动态的调整。对于有较低处理能力的控制器，rdmax能够限制在该控制器上排队的请求的数目。从而使得更多的请求能够被发送到拥有较强处理能力的控制器。然而，如果rdmax被设置的太小，由于评估的响应时延超过了rdmax的限制，这将导致大多数的控制器拒绝接收新的请求，也就是说很多时候探测的d个控制器都不能满足需求，从而需要多次重新选择控制器。此时，有必要来扩大rdmax的值。但是，在本申请的原理作为背景下，rdmax的任何取值都应当落入本申请的保护范围内。
所属领域的普通技术人员应当理解：以上任何实施例的讨论仅为示例性的，并非旨在暗示本公开的范围(包括权利要求)被限于这些例子；在本发明的思路下，以上实施例或者不同实施例中的技术特征之间也可以进行组合，步骤可以以任意顺序实现，并存在如上所述的本发明的不同方面的许多其它变化，为了简明它们没有在细节中提供。
另外，为简化说明和讨论，并且为了不会使本发明难以理解，在所提供的附图中可以示出或可以不示出与集成电路(ic)芯片和其它部件的公知的电源/接地连接。此外，可以以框图的形式示出装置，以便避免使本发明难以理解，并且这也考虑了以下事实，即关于这些框图装置的实施方式的细节是高度取决于将要实施本发明的平台的(即，这些细节应当完全处于本领域技术人员的理解范围内)。在阐述了具体细节(例如，电路)以描述本发明的示例性实施例的情况下，对本领域技术人员来说显而易见的是，可以在没有这些具体细节的情况下或者这些具体细节有变化的情况下实施本发明。因此，这些描述应被认为是说明性的而不是限制性的。
尽管已经结合了本发明的具体实施例对本发明进行了描述，但是根据前面的描述，这些实施例的很多替换、修改和变型对本领域普通技术人员来说将是显而易见的。例如，其它存储器架构(例如，动态ram(dram))可以使用所讨论的实施例。
本发明的实施例旨在涵盖落入所附权利要求的宽泛范围之内的所有这样的替换、修改和变型。因此，凡在本发明的精神和原则之内，所做的任何省略、修改、等同替换、改进等，均应包含在本发明的保护范围之内。
- 还没有人留言评论。精彩留言会获得点赞！