CN107872404A - 业务分片处理方法、装置及软件定义网络控制器 - Google Patents

业务分片处理方法、装置及软件定义网络控制器 Download PDF

Info

Publication number
CN107872404A
CN107872404A CN201610846887.5A CN201610846887A CN107872404A CN 107872404 A CN107872404 A CN 107872404A CN 201610846887 A CN201610846887 A CN 201610846887A CN 107872404 A CN107872404 A CN 107872404A
Authority
CN
China
Prior art keywords
burst
resource
area
node
identification information
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN201610846887.5A
Other languages
English (en)
Inventor
蒋英铭
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
ZTE Corp
Original Assignee
ZTE Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by ZTE Corp filed Critical ZTE Corp
Priority to CN201610846887.5A priority Critical patent/CN107872404A/zh
Publication of CN107872404A publication Critical patent/CN107872404A/zh
Pending legal-status Critical Current

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08Configuration management of networks or network elements
    • H04L41/0893Assignment of logical groups to network elements
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • H04L47/12Avoiding congestion; Recovering from congestion
    • H04L47/125Avoiding congestion; Recovering from congestion by balancing the load, e.g. traffic engineering
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/70Admission control; Resource allocation
    • H04L47/78Architectures of resource allocation

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

本发明实施例提供一种业务分片处理方法、装置及软件定义网络控制器,利用预设的分片算法和计算粒子实例化算法,计算业务消息中资源信息对应的分片识别信息和计算粒子识别信息,并根据计算结果将业务消息分配到集群节点上的分片区,通过该分片区中对应的计算粒子对业务消息进行处理。由于一个集群中包括两个及两个以上的节点设备,将业务消息分派到集群节点的分片区,并由分片区中的计算粒子进行处理,可使业务消息不再由一个网络设备集中处理,避免了对单个网络设备高度依赖的问题,提升了网络容灾性能,保证了用户体验。同时由于集群中各节点都有独立的业务处理能力,因此提升了资源利用率和业务并发处理能力,提高了网络吞吐量。

Description

业务分片处理方法、装置及软件定义网络控制器
技术领域
本发明涉及网管领域,尤其涉及业务分片处理方法、装置及软件定义网络控制器。
背景技术
现有网络中,对流量的控制和转发都依赖于网络设备实现,且设备中集成了与业务特性紧耦合的操作***和专用硬件,这些操作***和专用硬件都是各个厂家自己开发和设计的,这直接导致业务部署、业务升级、业务适应等都非常麻烦,网络管理工作举步维艰,在这种情况下,SDN(Software Defined Network,软件定义网络)应运而生。
SDN是一种新型的网络架构,它的设计理念是将网络的控制平面与数据转发平面进行分离,从而通过集中的控制器中的软件平台去实现可编程化控制底层硬件,实现对网络资源灵活的按需调配。在SDN网络中,网络设备只负责单纯的数据转发,可以采用通用的硬件;而原来负责控制的操作***将提炼为独立的网络操作***,负责对不同业务特性进行适配,而且网络操作***和业务特性以及硬件设备之间的通信都可以通过编程实现。SDN的典型架构共分三层,最上层为应用层,包括各种不同的业务和应用;中间的控制层主要负责处理数据平面资源的编排,维护网络拓扑、状态信息等;最底层的基础设施层负责基于流表的数据处理、转发和状态收集。
尽管SDN架构具有“控制和转发分离”、“设备资源虚拟化”和“通用硬件及软件可编程”等明显优势,但同时也正是由于SDN构架下能够对网络设备的转发进行统一控制,因此,整个网管***能否正常运转就依赖于部署SDN控制器的设备是否能够正常运转,以SDN控制器部署在服务器为例:如果该服务器掉电或者故障,则SDN控制器无法工作,这就必然使得用户业务大面积受到影响,为了避免服务器无法正常工作使影响用户业务的问题,现有技术只能采用“主备双机”的方式来容灾,如图1所示,主用服务器11和备用服务器12之间定时进行数据备份,当主用服务器11发生硬件故障或者网络断链,监控软件(MC/ServiceGuard)监控到异常的时候,将会控制关闭主用服务器11,自动启动备用服务器12,由备用服务器12继续给客户端提供服务。
“主备双机”的方式在一定程度上能够保证网管***正常提供服务,但仅依靠备用服务器来容灾,当备用服务器同样出现问题的时候,网管***对业务的处理还是会中断,也就是说,现有技术中将业务进行集中处理导致网管***容灾性差。
发明内容
本发明实施例提供的业务分片处理方法、装置及软件定义网络控制器,主要解决的技术问题是:提出一种新的业务处理方案,用于解决现有技术中由一台服务器集中处理业务所导致的网管***容灾性差的问题。
为解决上述技术问题,本发明实施例提供一种业务分片处理方法,包括:
接收业务消息,所述业务消息包含资源信息;
根据所述资源信息,分别通过预设的分片算法及计算粒子实例化算法得到该资源信息对应的分片识别信息和计算粒子识别信息;
将所述业务消息分配至根据所述分片识别信息在集群的节点上确定的分片区,并通过所述计算粒子识别信息在所述分片区内对应的计算粒子进行处理。
本发明实施例还提供一种业务分片处理装置,包括:
业务接收模块,用于接收包含资源信息的业务消息;
映射模块,用于根据所述资源信息,分别通过预设的分片算法及计算粒子算法得到该资源信息对应的分片识别信息和计算粒子识别信息;
分配模块,用于将所述业务消息分配至根据所述分片识别信息在集群的节点上确定的分片区,以供在所述分片区内通过所述计算粒子识别信息对应的计算粒子对所述业务消息进行处理。
本发明实施例还提供一种软件定义网络控制器,包括如上所述的业务分片处理装置。
本发明实施例还提供一种计算机存储介质,所述计算机存储介质中存储有计算机可执行指令,所述计算机可执行指令用于执行前述的任一项的业务分片处理方法。
本发明的有益效果是:
根据本发明实施例提供的业务分片处理方法、装置、软件定义网络控制器以及计算机存储介质,利用预设的分片算法和计算粒子实例化算法,计算接收到的业务消息所包含的资源信息对应的分片识别信息和计算粒子识别信息,并根据得到的分片识别信息将业务消息分配到集群节点上的分片区,然后通过该分片区中与计算粒子识别信息相对应的计算粒子对业务消息进行处理。在这种业务处理方案中,由于一个集群中肯定包括两个及两个以上的节点设备,因此依据业务消息的资源信息将业务消息分派到集群节点的分片区,并由分片区中的计算粒子进行处理,就可以使业务消息不再集中由某一个网络设备进行处理,这就避免了集中业务处理方案中对单个网络设备高度依赖的问题,提升了网络容灾性能,保证了用户体验。同时由于集群中各节点都有独立的业务处理能力,相对于现有技术中两台主、备服务器仅具备一台服务器的处理能力,本发明实施例提供的业务分片处理方案不仅能提升资源利用率,实现资源优化配置,还能提升业务的并发处理能力,提高网络吞吐量。
附图说明
图1为现有技术中“主备双机”业务管理***的一种示意图;
图2为本发明实施例一提供的业务分片处理方法的一种流程图;
图3为本发明各实施例中节点分片的示意;
图4为本发明实施例二提供的业务分片处理装置的一种结构示意图;
图5为图4中分配模块的一种结构示意图;
图6为本发明实施例二提供的业务分片处理装置的另一种结构示意图;
图7为本发明实施例二提供的SDN控制器的一种结构示意图;
图8为本发明实施例二提供的服务器的一种硬件结构示意图。
具体实施方式
下面通过具体实施方式结合附图对本发明实施例作进一步详细说明。
实施例一:
为了解决现有SDN架构下对业务的处理集中在一台网络设备中,导致***容灾性能差以及资源利用率低的技术问题,本实施例提供一种业务分片处理方法,该方法由业务分片处理装置来实施,其主要适用于控制集群。
控制集群由一组相互独立的、通过高速网络互联的节点组成,它们构成了一个组,并以单一***的模式加以管理。一个客户与集群相互作用时,集群像是一个独立的服务器。在控制集群中,每一个控制集群节点都是一个独立的全功能节点,不需要依赖于控制器其他集群节点而工作。集群节点可以是计算机、服务器等设备。
下面请结合图2对本实施例中提供的业务分片处理方法进行介绍:
S202、业务分片处理装置接收业务消息。
可以理解的是业务消息的传输路径必然依赖于网络拓扑结构,而网元(NE)、链路(LINK)、隧道(LSP)等都具有一定的传输能力,因此在业务消息传输过程中,少不了利用这些资源。
在本实施例中业务分片处理装置接收的业务消息中包括资源信息,资源信息可以包含在业务消息的发送地址中。资源信息中包括资源识别名DN(Distinguished Name,识别名),DN是存在与消息发送地址中的一个基础数据结构,可以理解的是,资源识别名应该可以唯一识别一个资源,因此,在DN中可以包含资源类型以及资源值,且DN中的资源值最好可以唯一表征各资源。唯一表征各资源的意思是指不同的资源具有不同的资源值,即使是不同类型的资源也不应当拥有相同的资源值。
这样设置能够方便后续计算过程,虽然通过资源类型与资源值可以一起识别一个资源,例如,网元和链路各有100个资源,各网元资源的资源值分别为1~100,而链路资源的资源值也为1~100,通过资源类型与资源值可以唯一识别出一个资源,如资源值为23的网元资源,因此即使当前有两个资源值为23的资源,但是并不会将资源值为23链路资源识别为资源值为23的网元资源。但是采用这种方式设置资源值的问题在于后续计算过程的目的是为了为具有不同资源信息的业务消息决定不同的去向,而计算的时候仅会使用资源值,所以还是应当要为不同的资源设置不同的资源值,例如,网元有100个资源,这100个资源的资源值分别是1~100,而链路也有100个资源,这100资源的资源值就不能再为1~100,为了能够通过资源值唯一识别出一个资源,可以将链路资源的资源值分别设置为101~200。
除了资源类型与资源值以外,DN中还可以包括资源的功能,以下是消息发送地址中一种可供参考的DN格式:
DN{
public String type="";
public String value;
public String function="";
}
其中,“public String type”表征资源类型,如网元,链路,隧道等,在发送地址中,可以采用字符短小的大写缩写,如NE,LINK,LSP等来表示。“public String value”表示资源值,即资源的具体值,SDN中可采用UUID(Universally Unique Identifier,通用唯一识别码)的字符串来表示,也可以是U31中的资源value值。“public String function”表征资源具体功能,如创建CRT(create)、删除DEL(delete)等。
S204、业务分片处理装置根据资源信息,分别通过预设的分片算法及计算粒子实例化算法得到该资源信息对应的分片识别信息和计算粒子识别信息。
在一个集群节点上,可以承载多个分片区,即“片”(shard),Sharding(分片)是水平扩展(Scale Out,亦或横向扩展、向外扩展)的解决方案,其主要目的是为突破单节点I/O能力的限制,解决扩展性问题。在集群中,一个分区片用于对某类型资源中某些资源值的资源所发送的业务消息进行处理。每个分区片都有自己的分片区标识(Shard ID),分片区标识是一个片的唯一标识信息,在一个控制集群的多个节点中,不会存在两个分片区标识相同的分区片。
如图3所示,在集群当中包括第一节点31和第二节点32,在第一节点31当中包括第一分片区311和第二分区片312,在第二节点32当中包括第三分区片321,三个分片区的分片区标识分别为311、312和321。
获取到业务消息中的资源信息之后,可以根据资源信息确定出将该业务消息分配到哪一个片上去,通过预设的分片算法和资源信息可以计算出业务消息中资源信息对应的分片识别信息,分片识别信息用于与集群中各个片的分片区标识Shard ID进行匹配,假定计算出的分片识别信息为“312”,则该分片识别信息可以与图3中第二分片的分片区标识“312”匹配成功,匹配成功后表示应当将该业务消息分派到第二分片312上去。分片算法可以是哈希码(hash code)分片算法,根据资源识别名和哈希码分片算法得到资源信息对应的分片识别信息的具体过程可以参照如下:首先通过哈希码分片算法对资源值进行处理得到哈希数值m,然后将计算获得的哈希数值m与资源类型对应的分片总数n进行求模,并将求模得到的计算结果与资源类型进行组合得到资源信息对应的分片识别信息。
每一个分区片中可以设置至少一个CP(Compute Particle,计算粒子),CP是资源操作的基本单元,其相当处理算法的调用接口,也就是说,不同的计算粒子会采用不同的算法对业务消息进行不同的处理。有了CP,资源才能进行业务逻辑的处理,才能进行发消息等各种操作。每一个分区片中可以设置至少一个CP(Compute Particle,计算粒子),在图3所示出的集群中,第一分片区311中包括第一计算粒子311a、第二计算粒子311b以及第三计算粒子311c。为了确定出应当对一个业务消息进行怎样的处理,则应当确定出对业务消息进行处理的计算粒子是哪一个。根据资源信息利用计算粒子实例化算法可以计算出计算粒子识别信息。计算粒子实例化算法是指上就是将资源识别名中的资源类型和资源值进行组合后,根据预先存储的资源类型、资源值同计算粒子识别信息的映射关系表中匹配出对应的计算粒子识别信息。
S206、业务分片处理装置将业务消息分配至根据分片识别信息在集群的节点上确定的分片区,并通过分片区内与计算粒子识别信息对应的计算粒子进行处理。
业务分片处理装置计算出资源信息的分片区识别信息和计算粒子识别信息之后,将分片区识别信息与集群内各个分片区的分片区标识进行匹配以确定应当将对应的业务消息分配到哪一个分片区上去。具体的,业务分片处理装置可以在集群的各个节点上查询节点内是否存在与计算出的分片区识别信息相匹配的分片标识,如果存在,则表明匹配成功的分片标识所对应的分片区就是分派业务消息的目标分片区,业务分片处理装置可以将该业务消息分配至该目标分片区。进一步,业务分片处理装置还可以通过计算粒子识别信息在该分片区内进行匹配,以确定应当由该分片区内哪一个计算粒子对业务消息进行处理,如果匹配成功,则业务分片处理装置通过匹配到的计算粒子从预设算法库中调用业务处理算法对业务信息进行处理。
本领域技术人员应当明白的是,除了上述顺利匹配到目标分片区与计算粒子的情形外,还有可能存在这样几种情况:
第一种,业务分片处理装置可以在集群内通过分片识别信息匹配到对应的分片区,但是计算出来的计算粒子识别信息却无法在对应分片区中匹配到计算粒子,例如,计算出来的分片识别信息为“311”,计算粒子识别信息为“311d”,则根据计算结果在图3示出的集群当中可以匹配出分片区标识为“311”的第一分片区311,但是,在第一分片区311内却并不存在“311d”的计算粒子识别信息,在这种情况下,应当根据资源信息通过计算粒子实例化算法在匹配出的分片区中实例化出对应的计算粒子,即通过粒子实例化算法和业务消息中携带的资源信息,实例化一个可以对该业务消息进行处理的计算粒子,然后根据实例化出的计算粒子从预设的业务处理算法库中调用业务处理算法对业务消息进行处理。
第二种,业务分片处理装置计算出的分片区识别信息无法匹配到对应的分片区,即在集群内不存在分片区标识与计算出的分片区识别信息相匹配的分片区。当然,如果连相匹配的分片区都不存在,自然也就不存在与计算粒子识别信息相匹配的计算粒子。在这种情况下可以根据分片识别信息在集群的某一节点上新建分片区作为目标分片区,并将业务消息分配至该新建的目标分片区。
在分片区中除了包含计算粒子以外,还包含片区存储数据库,片区数据库用于对分派到该分片区的资源进行存储。因此,在新建分片区的过程中还应当为该分片区分配一个片区存储数据库,该片区存储数据库的名称可以包含该分片区的分片区标识和缓存名,例如,一个片区存储数据库的名称为“NE-107#Inlabel”,其中,“NE-107”是根据网元DN生成的分片标识信息,“Inlabel”是应用入库的时候填的一个cache名称。
在本实施例的一些示例当中,新建分片区的时候,可以将分片区创建在集群的任意一个节点上,在另外一些示例当中,可以根据负载均衡算法结合集群中各个节点当前的负载情况来确定应当将新的分片区创建在哪一个节点上,负载通常包括应用程序处理负载和网络流量负载。依照负载均衡原则工作的集群称为负载均衡集群,负载均衡集群提供了更实用的***。负载均衡集群使负载可以在计算机集群中尽可能平均地分摊处理。这样的***非常适合向使用同一组应用程序的大量用户提供服务。每个节点都可以承担一定的处理负载,并且可以实现处理负载在节点之间的动态分配,以实现负载均衡。同时,还可以根据每个节点上不同的可用资源或网络的特殊环境来进行优化。负载均衡集群在多节点之间分发计算处理负载。大多数情况下,负载均衡集群中的每个节点都是运行单独软件的独立***。
在创建新的分片区之后,还应当根据粒子实例化算法和业务消息中携带的资源信息在分片区上实例化出对应的计算粒子,该过程在第一种情况中已经做了详细介绍,这里不再赘述。
值得注意的是,在本实施例中,分片区与分片区中的计算粒子都是根据需要才创建的,也即是在根据业务消息携带的资源信息进行计算之后发现不存在对应的分片区或者计算粒子,是为了处理该业务消息需要对应的分片区或者计算粒子时才会新建,但是本领域技术人员应当明白的是,在本实施例中,在并没出现对分片区或者计算例子的需求时,也可以根据工程经验进行一些“预部署”,例如,根据工程经验,在一个分片区中,存储/写入、读取和删除都是非常常见的处理方式,因此可以预先为这几种常见处理的算法在分片区中实例化对应的计算粒子。
从上述新建过程中可以看出,本实施例提供的集群中,分片区并不是一成不变的,其可以新建,也就是说,集群具有良好的扩展性,并且在进行扩展的时候并不会影响到集群中其他分片区的工作。另外,分片区上的计算粒子是可以关闭的,当一个分片区上的计算粒子全部都处于关闭状态的时候,该分片区也就不能提供服务了,此时可以将该分片区从该节点上删除。所以本实施例中的集群除了可扩展以外,还能进行“收缩”,总体而言,集群具有良好的可缩放性,相较于现有“主备双机”的管理方式,本实施例提供的业务分片处理方案具有明显的优势:在“主备双机”的管理方式中,由于主用服务器与备用服务器在提供业务服务的时候,只能视作一台服务器,因此在业务量较大的情况下,使用单台服务器进行所有的计算及存储,经常会出现CPU、磁盘或者内存不足的问题。如果要提升性能,就必须关闭SDN控制器,升级服务器,更换更高配置的机器,这时候依然会造成业务中断,可见现有业务处理方案的扩展性(或可缩放性)不强。
在本实施例中,针对集群的更新操作除了分片区的新建与删除以外,还包括分片区的迁移与节点迁移。分片区迁移的情况比较多,例如,某一个节点上承载的分片区太多,负载过大;或者是集群中新增了一些空闲的节点,例如某一个节点上上多个分片区被删除,或者是集群中新增了新的节点,在这些情况下,为了均衡集群内各个节点的负载压力,业务分片处理装置可能会将一些负载相对较大的节点上的部分分片区迁移到压力相对较小的节点上。在业务分片处理装置监测到集群某一节点上的某一分片区需要迁移时,可以通过负载均衡算法从集群的其他节点中为该待迁移的分片区确定出目的节点,然后将待迁移的分片区迁移至目的节点。值得注意的是,当分片区迁移到新的节点之后,业务分片处理装置应当要重新启动该分片区的片区存储数据库。
针对节点的迁移是指上也是一种分片区迁移,只不过,在节点迁移的情况中,待迁移节点上所有的分片区都会被迁移,而且待迁移节点中各个分片区迁移的目的节点可能不相同,因为,当一个待迁移节点上承载了多个分片区的时候,如果将该节点上的所有分片区都迁移到同一个目的节点上,则目的节点可能会负载过大。所以在节点迁移的过程中,还是以分片区为单位进行的,通过负载均衡算法从集群的其他节点中为各待迁移的分片区确定出各自对应的目的节点,将各待迁移的分片区迁移至各自对应的目的节点上。节点迁移的情况一般发生在节点设备故障或者节点退出集群的情况下。
在上面介绍的计算粒子CP都是在分片区内,按照资源DN实例化的,这些CP主要用于接收并处理针对该资源的消息。在本实施例的而另外一些示例当中,计算粒子CP还可以按照分片区实例化,这一类CP负责对该分片区内所有资源进行管理。还有一些CP可以根据节点实例化,这种CP在一个集群节点中只有一个。
本发明实施例提供的业务分片处理方法,通过接收到的业务消息携带的资源信息计算出分片识别信息和计算粒子识别信息,然后根据分片识别信息和计算粒子识别信息将业务消息分派到对应的分片区中有分片区内对应的计算粒子进行处理,避免了集中业务处理方案中对单个网络设备高度依赖的问题,提升了网络容灾性能,保证了用户体验。同时由于集群中各节点都有独立的业务处理能力,相对于现有技术,不仅能提升资源利用率,实现资源优化配置,还能提升业务的并发处理能力,提高网络吞吐量。
更进一步地,由于集群中的节点、分片区、计算粒子可以随时新建、删除,因此业务消息处理***的扩展性好,便于业务部署、业务升级等工作的顺利开展,在为用户提供更新、更好的服务的同时,还能保证用户业务不会受到***升级或扩容的影响,保证了用户体验。
实施例二:
本实施例还提供一种业务分片处理装置,如图4所示,业务分片处理装置40包括业务接收模块402、映射模块404和分配模块406。
其中业务接收模块402用于接收包含资源信息的业务消息;映射模块404用于根据资源信息,分别通过预设的分片算法及计算粒子算法得到该资源信息对应的分片识别信息和计算粒子识别信息;分配模块406则用于将业务消息分配至根据分片识别信息在集群的节点上确定的分片区,以供在分片区内通过计算粒子识别信息对应的计算粒子对业务消息进行处理。
控制集群由一组相互独立的、通过高速网络互联的节点组成,它们构成了一个组,并以单一***的模式加以管理。一个客户与集群相互作用时,集群像是一个独立的服务器。在控制集群中,每一个控制集群节点都是一个独立的全功能节点,不需要依赖于控制器其他集群节点而工作。集群节点可以是计算机、服务器等设备。
可以理解的是业务接收模块402能够接收到业务消息必然依赖于网络拓扑结构,而网元(NE)、链路(LINK)、隧道(LSP)等都具有一定的传输能力,因此在业务消息传输过程中,少不了利用这些资源。
在本实施例中业务接收模块402接收的业务消息中包括资源信息,资源信息可以包含在业务消息的发送地址中。资源信息中包括资源识别名DN,DN是存在与消息发送地址中的一个基础数据结构,可以理解的是,资源识别名应该可以唯一识别一个资源,因此,在DN中可以包含资源类型以及资源值,且DN中的资源值最好可以唯一表征各资源。唯一表征各资源的意思是指不同的资源具有不同的资源值,即使是不同类型的资源也不应当拥有相同的资源值。
这样设置能够方便后续计算过程,虽然通过资源类型与资源值可以一起识别一个资源,例如,网元和链路各有100个资源,各网元资源的资源值分别为1~100,而链路资源的资源值也为1~100,通过资源类型与资源值可以唯一识别出一个资源,如资源值为23的网元资源,因此即使当前有两个资源值为23的资源,但是并不会将资源值为23链路资源识别为资源值为23的网元资源。但是采用这种方式设置资源值的问题在于后续计算过程的目的是为了为具有不同资源信息的业务消息决定不同的去向,而计算的时候仅会使用资源值,所以还是应当要为不同的资源设置不同的资源值,例如,网元有100个资源,这100个资源的资源值分别是1~100,而链路也有100个资源,这100资源的资源值就不能再为1~100,为了能够通过资源值唯一识别出一个资源,可以将链路资源的资源值分别设置为101~200。
除了资源类型与资源值以外,DN中还可以包括资源的功能,以下是消息发送地址中一种可供参考的DN格式:
DN{
public String type="";
public String value;
public String function="";
}
其中,“public String type”表征资源类型,如网元,链路,隧道等,在发送地址中,可以采用字符短小的大写缩写,如NE,LINK,LSP等来表示。“public String value”表示资源值,即资源的具体值,SDN中可采用UUID(Universally Unique Identifier,通用唯一识别码)的字符串来表示,也可以是U31中的资源value值。“public String function”表征资源具体功能,如创建CRT(create)、删除DEL(delete)等。
在一个集群节点上,可以承载多个分片区,即“片”,Sharding是水平扩展(ScaleOut,亦或横向扩展、向外扩展)的解决方案,其主要目的是为突破单节点I/O能力的限制,解决扩展性问题。在集群中,一个分区片用于对某类型资源中某些资源值的资源所发送的业务消息进行处理。每个分区片都有自己的分片区标识,分片区标识是一个片的唯一标识信息,在一个控制集群的多个节点中,不会存在两个分片区标识相同的分区片。
如图3所示,在集群当中包括第一节点31和第二节点32,在第一节点31当中包括第一分片区311和第二分区片312,在第二节点32当中包括第三分区片321,三个分片区的分片区标识分别为311、312和313。
获取到业务消息中的资源信息之后,可以根据资源信息确定出将该业务消息分配到哪一个片上去,映射模块404通过预设的分片算法和资源信息可以计算出业务消息中资源信息对应的分片识别信息,分片识别信息用于与集群中各个片的分片区标识Shard ID进行匹配,假定计算出的分片识别信息为“312”,则该分片识别信息可以与图3中第二分片的分片区标识“312”匹配成功,匹配成功后表示应当将该业务消息分派到第二分片312上去。分片算法可以是哈希码分片算法,映射模块404根据资源识别名和哈希码分片算法得到资源信息对应的分片识别信息的具体过程可以参照如下:映射模块404首先通过哈希码分片算法对资源值进行处理得到哈希数值m,然后将计算获得的哈希数值m与资源类型对应的分片总数n进行求模,并将求模得到的计算结果与资源类型进行组合得到资源信息对应的分片识别信息。
每一个分区片中可以设置至少一个CP,CP是资源操作的基本单元,其相当处理算法的调用接口,也就是说,不同的计算粒子会采用不同的算法对业务消息进行不同的处理。有了CP,资源才能进行业务逻辑的处理,才能进行发消息等各种操作。每一个分区片中可以设置至少一个CP,在图3所示出的集群中,第一分片区311中包括第一计算粒子311a、第二计算粒子311b以及第三计算粒子311c。为了确定出应当对一个业务消息进行怎样的处理,则映射模块404应当确定出对业务消息进行处理的计算粒子是哪一个。映射模块404根据资源信息利用计算粒子实例化算法可以计算出计算粒子识别信息。具体的,映射模块404将资源识别名中的资源类型和资源值进行组合后,根据预先存储的资源类型、资源值同计算粒子识别信息的映射关系表中匹配出对应的计算粒子识别信息。
分配模块406根据映射模块404的计算结果对业务接收模块接收到的业务消息进行处理。分配模块406可以将业务消息分配至根据分片识别信息在集群的节点上确定的分片区,并通过计算粒子识别信息在分片区内对应的计算粒子进行处理。如图5所示,分配模块406包括匹配单元4061、分片生成单元4062以及分派单元4063。
映射模块404计算出资源信息的分片区识别信息和计算粒子识别信息之后,匹配单元4061将分片区识别信息与集群内各个分片区的分片区标识进行匹配以确定应当将对应的业务消息分配到哪一个分片区上去。具体的,匹配单元4061可以在集群的各个节点上查询节点内是否存在与计算出的分片区识别信息相匹配的分片标识,如果存在,则表明匹配成功的分片标识所对应的分片区就是分派业务消息的目标分片区,分派单元4063可以将该业务消息分配至该目标分片区。进一步,分派单元4063还可以通过计算粒子识别信息在该分片区内进行匹配,以确定应当由该分片区内哪一个计算粒子对业务消息进行处理,如果匹配成功,则分派单元4063通过匹配到的计算粒子从预设算法库中调用业务处理算法对业务信息进行处理。
本领域技术人员应当明白的是,除了上述顺利匹配到目标分片区与计算粒子的情形外,还有可能存在这样几种情况:
第一种,匹配单元4061可以在集群内通过分片识别信息匹配到对应的分片区,但是计算出来的计算粒子识别信息却无法在对应分片区中匹配到计算粒子,例如,映射模块404计算出来的分片识别信息为“311”,计算粒子识别信息为“311d”,则匹配单元4061根据计算结果在图3示出的集群当中可以匹配出分片区标识为“311”的第一分片区311,但是,在第一分片区311内却并不存在“311d”的计算粒子识别信息,在这种情况下,分片生成单元4062应当根据资源信息通过计算粒子实例化算法在匹配出的分片区中实例化出对应的计算粒子,即通过粒子实例化算法和业务消息中携带的资源信息,实例化一个可以对该业务消息进行处理的计算粒子,然后分派单元4063根据实例化出的计算粒子从预设的业务处理算法库中调用业务处理算法对业务消息进行处理。
第二种,匹配单元4061根据映射模块404计算出的分片区识别信息无法匹配到对应的分片区,即在集群内不存在分片区标识与计算出的分片区识别信息相匹配的分片区。当然,如果连相匹配的分片区都不存在,自然也就不存在与计算粒子识别信息相匹配的计算粒子。在这种情况下分片生成单元4062可以根据分片识别信息在集群的某一节点上新建分片区作为目标分片区,并由分派单元4063将业务消息分配至该新建的目标分片区。
在分片区中除了包含计算粒子以外,还包含片区存储数据库,片区数据库用于对分派到该分片区的资源进行存储。因此,在分片生成单元4062新建分片区的过程中还应当为该分片区分配一个片区存储数据库,该片区存储数据库的名称可以包含该分片区的分片区标识和缓存名,例如,一个片区存储数据库的名称为“NE-107#Inlabel”,其中,“NE-107”是根据网元DN生成的分片标识信息,“Inlabel”是应用入库的时候填的一个cache名称。
在本实施例的一些示例当中,分片生成单元4062新建分片区的时候,可以将分片区创建在集群的任意一个节点上,在另外一些示例当中,分片生成单元4062可以根据负载均衡算法结合集群中各个节点当前的负载情况来确定应当将新的分片区创建在哪一个节点上,负载通常包括应用程序处理负载和网络流量负载。依照负载均衡原则工作的集群称为负载均衡集群,负载均衡集群提供了更实用的***。负载均衡集群使负载可以在计算机集群中尽可能平均地分摊处理。这样的***非常适合向使用同一组应用程序的大量用户提供服务。每个节点都可以承担一定的处理负载,并且可以实现处理负载在节点之间的动态分配,以实现负载均衡。同时,还可以根据每个节点上不同的可用资源或网络的特殊环境来进行优化。负载均衡集群在多节点之间分发计算处理负载。大多数情况下,负载均衡集群中的每个节点都是运行单独软件的独立***。
在分片生成单元4062创建新的分片区之后,还应当根据粒子实例化算法和业务消息中携带的资源信息在分片区上实例化出对应的计算粒子,该过程在第一种情况中已经做了详细介绍,这里不再赘述。
值得注意的是,在本实施例中,分片区与分片区中的计算粒子都是分片生成单元4062根据需要才创建的,也即是在根据业务消息携带的资源信息进行计算之后发现不存在对应的分片区或者计算粒子,是为了处理该业务消息需要对应的分片区或者计算粒子时才会新建,但是本领域技术人员应当明白的是,在本实施例中,在并没出现对分片区或者计算例子的需求时,分片生成单元4062也可以根据工程经验进行一些“预部署”,例如,根据工程经验,在一个分片区中,存储/写入、读取和删除都是非常常见的处理方式,因此分片生成单元4062可以预先为这几种常见处理的算法在分片区中实例化对应的计算粒子。
从上述新建过程中可以看出,本实施例提供的集群中,分片区并不是一成不变的,其可以新建,也就是说,集群具有良好的扩展性,并且在进行扩展的时候并不会影响到集群中其他分片区的工作。除了新建以外,对分片区还可以进行一些其他的管理维护,如图6所示,在本实施例提供的另一种业务分片处理装置40中,除了包括业务接收模块402、映射模块404和分配模块406以外,还包括片区维护模块408。
分片区上的计算粒子是可以关闭的,当一个分片区上的计算粒子全部都处于关闭状态的时候,该分片区也就不能提供服务了,此时片区维护模块408可以将该分片区从该节点上删除。所以本实施例中的集群除了可扩展以外,还能进行“收缩”,总体而言,集群具有良好的可缩放性,相较于现有“主备双机”的管理方式,本实施例提供的业务分片处理方案具有明显的优势:在“主备双机”的管理方式中,由于主用服务器与备用服务器在提供业务服务的时候,只能视作一台服务器,因此在业务量较大的情况下,使用单台服务器进行所有的计算及存储,经常会出现CPU、磁盘或者内存不足的问题。如果要提升性能,就必须关闭SDN控制器,升级服务器,更换更高配置的机器,这时候依然会造成业务中断,可见现有业务处理方案的扩展性(或可缩放性)不强。
在本实施例中,针对集群的更新操作除了分片区的新建与删除以外,还包括分片区的迁移与节点迁移。分片区迁移的情况比较多,例如,某一个节点上承载的分片区太多,负载过大;或者是集群中新增了一些空闲的节点,例如某一个节点上上多个分片区被删除,或者是集群中新增了新的节点,在这些情况下,为了均衡集群内各个节点的负载压力,片区维护模块408可能会将一些负载相对较大的节点上的部分分片区迁移到压力相对较小的节点上。在片区维护模块408监测到集群某一节点上的某一分片区需要迁移时,可以通过负载均衡算法从集群的其他节点中为该待迁移的分片区确定出目的节点,然后将待迁移的分片区迁移至目的节点。值得注意的是,当分片区迁移到新的节点之后,片区维护模块408应当要重新启动该分片区的片区存储数据库。
针对节点的迁移是指上也是一种分片区迁移,只不过,在节点迁移的情况中,待迁移节点上所有的分片区都会被迁移,而且待迁移节点中各个分片区迁移的目的节点可能不相同,因为,当一个待迁移节点上承载了多个分片区的时候,如果将该节点上的所有分片区都迁移到同一个目的节点上,则目的节点可能会负载过大。所以在片区维护模块408进行节点迁移的过程中,还是以分片区为单位进行的,片区维护模块408通过负载均衡算法从集群的其他节点中为各待迁移的分片区确定出各自对应的目的节点,然后将各待迁移的分片区迁移至各自对应的目的节点上。节点迁移的情况一般发生在节点设备故障或者节点退出集群的情况下。
在上面介绍的计算粒子CP都是在分片区内,按照资源DN实例化的,这些CP主要用于接收并处理针对该资源的消息。在本实施例的而另外一些示例当中,计算粒子CP还可以按照分片区实例化,这一类CP负责对该分片区内所有资源进行管理。还有一些CP可以根据节点实例化,这种CP在一个集群节点中只有一个。
本实施例提供一种SDN控制器,请参考图7,SDN控制器7包括上述任意一种业务分片处理装置40,SDN控制器7可以以计算机程序的形式运行在服务器上,也可以使硬件实体。
本实施例中提供的业务分片处理装置可以部署在服务器上,下面结合图8对实现本实施例中业务分片处理装置的硬件结构进行介绍:
该服务器8至少包括:输入输出(IO)总线81、处理器82、存储器83、内存84和通信装置85。其中,
输入输出(IO)总线81分别与自身所属的服务器的其它部件(处理器82、存储器83、内存84和通信装置85)连接,并且为其它部件提供传送线路。
处理器82通常控制自身所属的服务器的总体操作。例如,处理器82执行计算和确认等操作。其中,处理器82可以是中央处理器(CPU)。
通信装置85,通常包括一个或多个组件,其允许自身所属的服务器与无线通信***或网络之间的无线电通信。
存储器83存储处理器可读、处理器可执行的软件代码,其包含用于控制处理器82执行本文描述的功能的指令(即软件执行功能)。
其中,本发明提供的业务分片处理装置中,业务接收模块的功能可以通过服务器8的通信装置85来实现,而映射模块的计算功能则可以由处理器82来实现,分配模块的功能可以由处理器82和通信装置85共同来实现,最后片区维护模块的维护流程也同样可以通过处理器802和和通信装置85共同执行。
当通信装置85接收到业务消息后,通过输入输出总线81将业务消息传输给处理器82,处理器82从业务消息中的消息发送地址中提取出资源信息,资源信息中包括资源识别名DN,然后预设的根据分片算法和计算粒子实例化算法计算得到分片识别信息和计算粒子识别信息。可以理解的是,在服务器8的存储器83当中,可以预先存储集群中当前各节点上各分片区的信息和各分片区中已经存在的各计算粒子的信息,处理器82可以根据预先存储的信息确定出应当将该业务消息分派到哪一个节点的哪一个分片区上去,确定出来后,可以控制通信装置85将业务消息发送到对应的节点上去,以便对应分片区中对应计算粒子对业务消息进行处理。
如果处理器82无法在预先存储的信息中匹配到计算出的分片识别信息和计算粒子识别信息,则可以先根据负载均衡算法确定应当在哪一个节点上新建分片区,然后通过通信装置85向对应节点发送控制消息,使对应节点新建分片区,并实例化计算粒子之后,再通过通信装置85将办业务消息传给节点。
本发明实施例提供的业务分片处理装置,通过接收到的业务消息携带的资源信息计算出分片识别信息和计算粒子识别信息,然后根据分片识别信息和计算粒子识别信息将业务消息分派到对应的分片区中有分片区内对应的计算粒子进行处理,避免了集中业务处理方案中对单个网络设备高度依赖的问题,提升了网络容灾性能,保证了用户体验。同时由于集群中各节点都有独立的业务处理能力,相对于现有技术,不仅能提升资源利用率,实现资源优化配置,还能提升业务的并发处理能力,提高网络吞吐量。
更进一步地,由于集群中的节点、分片区、计算粒子可以随时新建、删除,因此业务消息处理***的扩展性好,便于业务部署、业务升级等工作的顺利开展,在为用户提供更新、更好的服务的同时,还能保证用户业务不会受到***升级或扩容的影响,保证了用户体验。
显然,本领域的技术人员应该明白,上述本发明实施例的各模块或各步骤可以用通用的计算装置来实现,它们可以集中在单个的计算装置上,或者分布在多个计算装置所组成的网络上,可选地,它们可以用计算装置可执行的程序代码来实现,从而,可以将它们存储在计算机存储介质(ROM/RAM、磁碟、光盘)中由计算装置来执行,并且在某些情况下,可以以不同于此处的顺序执行所示出或描述的步骤,或者将它们分别制作成各个集成电路模块,或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。所以,本发明不限制于任何特定的硬件和软件结合。
以上内容是结合具体的实施方式对本发明实施例所作的进一步详细说明,不能认定本发明的具体实施只局限于这些说明。对于本发明所属技术领域的普通技术人员来说,在不脱离本发明构思的前提下,还可以做出若干简单推演或替换,都应当视为属于本发明的保护范围。

Claims (12)

1.一种业务分片处理方法,包括:
接收业务消息,所述业务消息包含资源信息;
根据所述资源信息,分别通过预设的分片算法及计算粒子实例化算法得到该资源信息对应的分片识别信息和计算粒子识别信息;
将所述业务消息分配至根据所述分片识别信息在集群的节点上确定的分片区,并通过所述分片区内与所述计算粒子识别信息对应的计算粒子进行处理。
2.如权利要求1所述的业务分片处理方法,其特征在于,将所述业务消息分配至根据所述分片识别信息在所述节点上确定的分片区包括:
在所述集群的各节点上查询到与所述分片识别信息匹配的目标分片区时,将所述业务消息分配至该目标分片区,在所述集群的各节点上未查询到与所述分片识别信息匹配的目标分片区时,根据所述分片识别信息在所述集群的某一节点上新建分片区作为目标分片区,将所述业务消息分配至该新建的目标分片区。
3.如权利要求2所述的业务分片处理方法,其特征在于,所述业务消息还包括缓存名;根据所述分片识别信息在所述集群的某一节点上新建目标分片区包括:
根据负载均衡原则从所述集群的各节点中选择一个作为目标节点;
以所述分片识别信息作为分片区标识在所述目标节点上新建目标分片区,并为该新建的目标分片区分配片区存储数据库,设置数据库名包含所述分片区标识和所述缓存名。
4.如权利要求3所述的业务分片处理方法,其特征在于,通过所述计算粒子识别信息对应的计算粒子对所述业务消息进行处理包括:
根据所述计算粒子识别信息在所述目标分片区中匹配对应的计算粒子,如匹配成功,通过匹配到的计算粒子从预设业务处理算法库中调用业务处理算法对所述业务消息进行处理;
在匹配失败的情况下,根据所述资源信息通过所述计算粒子实例化算法在所述分片区中实例化出对应的计算粒子,通过实例化的计算粒子从预设的业务处理算法库中调用业务处理算法对所述业务消息进行处理。
5.如权利要求1-4任一项所述的业务分片处理方法,其特征在于,还包括对分片区进行以下至少一种更新处理:
监测到所述集群某一节点上的某一分片区中的计算粒子都处于关闭状态时,将该分片区从该节点上删除;
监测到所述集群某一节点上的某一分片区需要迁移时,通过负载均衡算法从所述集群的其他节点中为该待迁移的分片区确定出目的节点,将所述待迁移的分片区迁移至所述目的节点;
监测到所述集群某一节点上的所有分片区都需要迁移时,通过负载均衡算法从所述集群的其他节点中为各待迁移的分片区确定出各自对应的目的节点,将所述各待迁移的分片区迁移至各自对应的目的节点上。
6.如权利要求1-4任一项所述的业务分片处理方法,其特征在于,所述资源信息包含资源识别名,所述资源识别名包含资源类型及唯一表征各资源的资源值;所述预设的分片算法为预设的哈希码分片算法;
根据所述述资源识别名和所述哈希码分片算法得到所述资源信息对应的分片识别信息包括:
通过所述哈希码分片算法对所述资源值进行处理得到哈希数值m;
将所述哈希数值m与所述资源类型对应的分片总数n进行求模得到的值与所述资源类型进行组合得到所述资源信息对应的分片识别信息。
7.一种业务分片处理装置,包括:
业务接收模块,用于接收包含资源信息的业务消息;
映射模块,用于根据所述资源信息,分别通过预设的分片算法及计算粒子算法得到该资源信息对应的分片识别信息和计算粒子识别信息;
分配模块,用于将所述业务消息分配至根据所述分片识别信息在集群的节点上确定的分片区,以供在所述分片区内与所述计算粒子识别信息对应的计算粒子进行处理。
8.如权利要求7所述的业务分片处理装置,其特征在于,所述分配模块包括匹配单元、分片生成单元以及分派单元;
所述匹配单元用于在所述集群的各节点上查询是否存在有与所述分片识别信息匹配的分片区,将与所述分片识别信息匹配的分片区作为目标分片区;
所述分片生成处理单元用于在所述匹配单元未查询到与所述分片识别信息匹配的分片区时,在所述集群的某一目标节点上新建所述分片识别信息对应的分片区作为目标分片区;
所述分派单元用于将所述业务消息分配至所述目标分片区。
9.如权利要求8所述的业务分片处理装置,其特征在于,所述业务消息还包括缓存名;所述分片生成单元用于根据负载均衡原则从所述集群的各节点中选择一个作为目标节点,以所述分片识别信息作为分片区标识在所述目标节点上新建分片区作为目标分片区,并为该新建的目标分片区分配片区存储数据库,设置数据库名包含所述分片区标识和所述缓存名。
10.如权利要求7-9任一项所述的业务分片处理装置,其特征在于,还包括片区维护模块,用于对分片区进行以下至少一种更新处理:
监测到所述集群的节点上的某一分片区中的计算粒子都被关闭时,将该分片区从该节点上删除;
通过负载均衡算法确定所述集群的节点上的某一分片区需要迁移时,通过所述负载均衡算法从所述集群的其他节点中为该待迁移的分片区确定出目的节点,将所述待迁移的分片区迁移至所述目的节点;
监测到所述集群某一节点上的所有分片区都需要迁移时,通过负载均衡算法从所述集群的其他节点中为各待迁移的分片区确定出各自对应的目的节点,将所述各待迁移的分片区迁移至各自对应的目的节点上。
11.如权利要求7-9任一项所述的业务分片处理装置,其特征在于,所述资源信息包含资源识别名,所述资源识别名包含资源类型及唯一表征各资源的资源值;所述预设的分片算法为预设的哈希分片算法;
所述映射模块根据所述述资源识别名和所述哈希码分片算法得到所述资源信息对应的分片识别信息包括:
通过所述哈希码分片算法对所述资源值进行处理得到哈希数值m;
将所述哈希数值m与所述资源类型对应的分片总数n进行求模得到的值与所述资源类型进行组合得到所述资源信息对应的分片识别信息。
12.一种软件定义网络控制器,其特征在于,包括如权利要求7-11任一项所述的业务分片处理装置。
CN201610846887.5A 2016-09-23 2016-09-23 业务分片处理方法、装置及软件定义网络控制器 Pending CN107872404A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201610846887.5A CN107872404A (zh) 2016-09-23 2016-09-23 业务分片处理方法、装置及软件定义网络控制器

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201610846887.5A CN107872404A (zh) 2016-09-23 2016-09-23 业务分片处理方法、装置及软件定义网络控制器

Publications (1)

Publication Number Publication Date
CN107872404A true CN107872404A (zh) 2018-04-03

Family

ID=61750761

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201610846887.5A Pending CN107872404A (zh) 2016-09-23 2016-09-23 业务分片处理方法、装置及软件定义网络控制器

Country Status (1)

Country Link
CN (1) CN107872404A (zh)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109144540A (zh) * 2018-07-27 2019-01-04 同济大学 一种分布式的软件定义网络更新方法
CN112583864A (zh) * 2019-09-27 2021-03-30 ***通信集团广东有限公司 一种数据迁移方法及装置
CN113225362A (zh) * 2020-02-06 2021-08-06 北京京东振世信息技术有限公司 服务器集群***和服务器集群***的实现方法

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109144540A (zh) * 2018-07-27 2019-01-04 同济大学 一种分布式的软件定义网络更新方法
CN112583864A (zh) * 2019-09-27 2021-03-30 ***通信集团广东有限公司 一种数据迁移方法及装置
CN113225362A (zh) * 2020-02-06 2021-08-06 北京京东振世信息技术有限公司 服务器集群***和服务器集群***的实现方法
CN113225362B (zh) * 2020-02-06 2024-04-05 北京京东振世信息技术有限公司 服务器集群***和服务器集群***的实现方法

Similar Documents

Publication Publication Date Title
CN101958805B (zh) 一种云计算中终端接入和管理的方法及***
CN111736872A (zh) 灰度发布升级方法、装置、计算机***及可读存储介质
CN107872404A (zh) 业务分片处理方法、装置及软件定义网络控制器
US10652100B2 (en) Computer system and method for dynamically adapting a software-defined network
CN106874142B (zh) 一种实时数据容错处理方法及***
CN104486394B (zh) 不中断业务软件升级方法及装置
CN110633085B (zh) 基于微服务架构的继电保护整定计算方法及装置
CN104038376A (zh) 一种管理真实服务器的方法、装置及lvs集群***
CN112910937B (zh) 容器集群中的对象调度方法、装置、服务器和容器集群
CN101026496A (zh) 一种容灾***、方法和网络设备
CN111752140A (zh) 控制器应用程序模块协调器
CN113296882A (zh) 容器编排方法、设备、***及存储介质
Muthanna et al. SDN multi-controller networks with load balanced
Pasieka et al. Models, methods and algorithms of web system architecture optimization
CN111796563A (zh) 工业自动化***的控制蜂巢架构工程效率
CN105207856A (zh) 一种基于sdn虚拟交换机的负载均衡的***及方法
CN107197002A (zh) 云计算***及云数据处理方法
CN106933654B (zh) 一种基于缓存的虚拟机启动方法
WO2022166715A1 (zh) 一种智能流水线处理方法、装置、存储介质及电子装置
Melnik et al. A recovery technique for the fog-computing-based information and control systems
CN110022220B (zh) 名片识别中的路由激活方法及***
il Kim et al. A VNF placement method considering load and hop count in NFV environment
CN113890850B (zh) 路由容灾***及方法
Alomari et al. On ensuring full yet cost-efficient survivability of service function chains in nfv environments
US20050182763A1 (en) Apparatus and method for on-line upgrade using proxy objects in server nodes

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
WD01 Invention patent application deemed withdrawn after publication
WD01 Invention patent application deemed withdrawn after publication

Application publication date: 20180403