CN103765837B - 多cpu的报文处理方法及系统、交换单元、单板 - Google Patents
多cpu的报文处理方法及系统、交换单元、单板 Download PDFInfo
- Publication number
- CN103765837B CN103765837B CN201280001081.6A CN201280001081A CN103765837B CN 103765837 B CN103765837 B CN 103765837B CN 201280001081 A CN201280001081 A CN 201280001081A CN 103765837 B CN103765837 B CN 103765837B
- Authority
- CN
- China
- Prior art keywords
- message
- cpu
- management
- business
- business cpu
- 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.)
- Expired - Fee Related
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
本发明实施例提供多CPU的报文处理方法及系统、交换单元、单板，所述方法包括：交换单元接收报文，确定所述报文为业务报文；通过业务聚合Trunk端口，广播负载检测请求消息，以使接收所述负载检测请求消息的各业务CPU分别通过各自的第一端口返回负载检测响应消息，所述负载检测响应消息中包括对应业务CPU的当前负载比率及管理IP地址；根据所述各负载检测响应消息中包含的对应业务CPU的当前负载比率及管理IP地址，将所述业务报文发送给当前负载比率最小的业务CPU；能够提高系统资源的利用率。
Description
技术领域
本发明涉及通信、电子设备技术领域，尤其一种多CPU的报文处理方法及系统、交换单元、单板。
背景技术
在电信设备中，为了增强单板的处理能力，常常在同一单板中设置多个处理器CPU，做成一块多CPU的单板，例如，无内部互锁流水级的微处理器(Microprocessorwithout interlocked piped stages，MIPS)架构的先进的电信计算平台(AdvancedTelecom Computing Architecture，ATCA)单板，一般集成两个以上CPU，由于每个CPU具有独立的内存和总线，不能采用现有的对称多处理技术，因为对称多处理技术中，要求各CPU之间共享内存子系统以及总线结构。
现有的MIPS架构的ATCA单板采用非对称多处理技术，然而，在非对称多处理技术中，外界通信数据通过接口器件送往各CPU，各CPU独自进行相关业务处理等工作，因此，基于任务和资源由不同处理器进行处理的非对称多处理技术，不能实现多CPU之间的负载均衡，降低系统资源的利用率。
发明内容
本发明实施例提供一种多CPU的报文处理方法及系统、交换单元、单板，以使基于非对称多处理技术的多个CPU也能实现多CPU之间的负载均衡，提高系统资源的利用率。
第一方面，本发明实施例提供了一种多CPU的报文处理方法，包括：
接收报文，确定所述报文为业务报文；
通过业务聚合Trunk端口，广播负载检测请求消息，以使接收所述负载检测请求消息的各业务CPU分别通过各自的第一端口返回负载检测响应消息，所述负载检测响应消息中包括对应业务CPU的当前负载比率及管理IP地址；
根据所述各负载检测响应消息中包含的对应业务CPU的当前负载比率及管理IP地址，将所述业务报文发送给当前负载比率最小的业务CPU。
在第一种可能的实现方式中，根据所述各负载检测响应消息中包含的对应业务CPU的当前负载比率及管理IP地址，将所述业务报文发送给当前负载比率最小的业务CPU，具体实现还可以为：
根据所述各负载检测响应消息中包含的对应业务CPU的当前负载比率及管理IP地址，获取当前负载比率最小的业务CPU对应的管理IP地址；
根据所述获取的管理IP地址，通过与所述当前负载比率最小的业务CPU的第一端口将所述业务报文发送给与所述获取的管理IP地址对应的业务CPU。
在第二种可能的实现方式中，所述方法具体实现还可以为：
接收报文，确定所述报文为管理控制报文；
通过第一管理控制端口，将所述管理控制报文发送给与所述管理端口对应的管理CPU，以使所述管理CPU对所述各业务CPU进行管理和控制。
在第三种可能的实现方式中，所述方法具体实现还可以为：
接收报文，确定所述报文为鉴权报文；
通过与主业务CPU的第二端口对应的第二管理控制端口，将所述鉴权报文发送给与所述主业务CPU，所述主业务CPU为所述各业务CPU的其中一个CPU。
第二方面，本发明实施例提供了一种交换单元，包括：
确定模块，用于接收报文，确定所述报文为业务报文；
广播模块，用于在所述确定模块确定所述报文为业务报文的基础上，通过业务聚合Trunk端口，广播负载检测请求消息，以使接收所述负载检测请求消息的各业务CPU分别通过各自的第一端口返回负载检测响应消息，所述负载检测响应消息中包括对应业务CPU的当前负载比率及管理IP地址；
发送模块，用于根据所述广播模块接收的各业务CPU返回的负载检测响应消息中包含的对应业务CPU的当前负载比率及管理IP地址，将所述业务报文发送给当前负载比率最小的业务CPU。
第三方面，本发明实施例提供一种交换单元，包括：处理器，所述处理器具体用于：接收报文，确定所述报文为业务报文；
通过业务聚合Trunk端口，广播负载检测请求消息，以使接收所述负载检测请求消息的各业务CPU分别通过各自的第一端口返回负载检测响应消息，所述负载检测响应消息中包括对应业务CPU的当前负载比率及管理IP地址；
根据所述各负载检测响应消息中包含的对应业务CPU的当前负载比率及管理IP地址，将所述业务报文发送给当前负载比率最小的业务CPU。
第四方面，本发明实施例提供一种多CPU的报文处理系统，用于与所述系统外部进行通信，包括：各业务CPU和交换单元，所述各业务CPU至少包括两个业务CPU，所述各业务CPU的其中一个业务CPU为主业务CPU；
所述交换单元分别与所述各业务CPU连接，具体为：所述交换单元的业务聚合Trunk端口分别与所述各业务CPU的第一端口连接，所述交换单元的各第二管理控制端口分别与所述各业务CPU的第二端口连接；
所述交换单元，用于接收报文，确定所述报文为业务报文；通过业务聚合Trunk端口，广播负载检测请求消息，以使接收所述负载检测请求消息的各业务CPU分别通过各自的第一端口返回负载检测响应消息，所述负载检测响应消息中包括对应业务CPU的当前负载比率及管理IP地址；根据所述各负载检测响应消息中包含的对应业务CPU的当前负载比率及管理IP地址，将所述业务报文发送给当前负载比率最小的业务CPU；
所述各业务CPU，分别用于根据接收到的所述业务报文进行相应的业务操作。
所述交换单元，具体用于根据所述各负载检测响应消息中包含的对应业务CPU的当前负载比率及管理IP地址，获取当前负载比率最小的业务CPU对应的管理IP地址；
根据所述获取的管理IP地址，通过与所述当前负载比率最小的业务CPU的第一端口将所述业务报文发送给与所述获取的管理IP地址对应的业务CPU。
第一种可能的实现方式中，所述系统还包括：管理CPU，通过第一管理控制端口与所述交换单元连接；
所述交换单元，还用于接收报文，确定所述报文为管理控制报文；通过第一管理端口，将所述管理控制报文发送给所述管理CPU；
所述管理CPU，用于若确定所述管理控制报文中包括配置命令，则将所述配置命令通过所述第一管理控制端口发送给所述交换单元，以使所述交换单元将所述配置命令通过与所述主业务CPU的第二端口对应的第二管理控制端口发送给所述主业务CPU，以使所述主业务CPU通过所述交换单元将所述配置命令同步发送给其他业务CPU，所述配置命令中包含逻辑网口和业务配置参数；
所述各业务CPU，分别用于根据所述配置命令中包含的逻辑网口和业务配置参数，进行相应的配置操作；
所述各业务CPU配置的逻辑网口和业务配置参数是相同的；
所述管理CPU，还用于若确定所述管理控制报文为汇总类型的管理控制报文，则将所述汇总类型的管理控制报文通过所述第一管理控制端口发送给所述交换单元，以使所述交换单元将所述汇总类型的管理控制报文通过第二管理控制端口分别发送给各业务CPU，所述汇总类型的管理控制报文包括心跳检测报文或查询报文或统计报文中至少一项，以使各业务CPU通过所述交换单元分别向所述管理CPU返回管理控制响应消息；
所述管理CPU，还用于若确定所述管理控制报文为非汇总类型的管理控制报文，则将所述非汇总类型的管理控制报文通过所述第一管理控制端口发送给所述交换单元，以使所述交换单元将所述非汇总类型的管理控制报文通过与所述主业务CPU的第二端口对应的第二管理控制端口发送给所述主业务CPU，以使所述主业务CPU通过所述交换单元向所述管理CPU返回管理控制响应消息。
在第二种可能的实现方式中，所述交换单元，还用于接收报文，确定所述报文为认证请求鉴权报文；通过与所述主业务CPU的第二端口对应的第二管理控制端口，将所述鉴权报文发送给与所述主业务CPU。
第五方面，本发明实施例提供一种单板，所述单板包括：上述的多CPU的报文处理系统。
由上述技术方案可知，本发明实施例当接收到业务报文时，通过预设的业务聚合Trunk端口向各业务CPU发送负载检测请求消息，用以获取各业务CPU的当前负载比率及对应的管理IP地址，将业务报文通过业务聚合Trunk端口发送给当前负载比率最小的业务CPU，从而可以实现将业务报文均衡的发送给各业务CPU，使得各业务CPU不用争抢系统资源，可以提高系统资源的利用率，因此，本实施例的技术方案可以使得基于非对称多处理技术的多个CPU也能实现多CPU之间的负载均衡。
进一步地，本发明实施例根据接收到的报文的不同类型，分别通过预设的端口将报文发送给对应的CPU，例如，将管理控制报文通过第一管理控制端口发送给管理CPU，可以实现通过管理CPU对各业务CPU进行统一管理和控制，从而可以提高系统的可靠性、可扩充性和抗灾难性。例如，当其中的一个业务CPU发生故障时，管理CPU可以重启该业务CPU。
附图说明
为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作一简单地介绍，显而易见地，下面描述中的附图是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。
图1为本发明一实施例提供的多CPU的报文处理方法的流程示意图；
图2为图1所示实施例应用的多CPU的报文处理系统的结构示意图；
图3为本发明另一实施例提供的交换单元的结构示意图；
图4为本发明另一实施例提供的交换单元的结构示意图；
图5为本发明另一实施例提供的多CPU的报文处理系统的结构示意图；
图6为图5所示系统实施例中管理CPU与各业务CPU之间的信令图。
具体实施方式
为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
图1为本发明一实施例提供的多CPU的报文处理方法的流程示意图，如图1所示，当交换单元接收到系统外部任一网络实体发送的报文时，所述方法具体包括：
101、交换单元接收报文，确定所述报文为业务报文。
在本发明的一个可选实施方式中，可以对交换单元的网口进行虚拟局域网(Virtual Local Area Network，VLAN)配置，具体配置如下：
配置交换单元的管理端口的VLAN为3000；鉴权Radius报文的外部端口VLAN为103，鉴权报文的内部端口VLAN为4003；上行业务报文的外部端口VLAN为101，上行业务报文的内部端口VLAN为4001；下行业务报文的外部端口VLAN为102，下行业务报文的内部端口VLAN为4002；即
鉴权报文的外部端口Radius_ext_vlan为103；
鉴权报文的内部端口Radius_inner_vlan为4003；
上行业务报文的外部端口Uplink_ext_vlan为101；
上行业务报文的内部端口Uplink_inner_vlan为4001；
下行业务报文的外部端口downlink_ext_vlan为102；
下行业务报文的内部端口downlink_inner_vlan为4002；
管理端口manager_vlan为3000。
需要说明的是，上述交换单元提供给每个业务CPU两个10GE网卡，为了数据层面和控制层面的分离，将其中一个10G口专门收发业务报文(即数据报文)，另外一个10G口收发管理控制报文或鉴权报文。具体实现可以为：
图2为图1所示实施例应用的多CPU的报文处理系统的结构示意图；如图2所示，将交换单元的xe1和xe8接口作为业务聚合Trunk端口(sa1接口)，与各业务CPU的第一端口(逻辑接口标识为spi1)连接，只允许业务报文通过。将交换单元的xe2接口和xe7接口设为第二管理控制端口，分别与各业务CPU的第二端口(逻辑接口标识为spi0)连接，只允许管理控制报文或鉴权报文通过。
进一步地，配置交换单元中的接口ge1、ge2、ge4、xe2、xe7的VLAN为3000；xe3、xe4、xe2接口的VLAN为103、4003；xe3、xe4、sa1接口的VLAN为101、4001、102、4002，即
Vlan3000ge1，ge2；ge4；xe2，xe7；
Vlan103 xe3，xe4；xe2；
Vlan4003 xe3，xe4；xe2；
Vlan101 xe3，xe4；sa1；
Vlan4001 xe3，xe4；sa1；
Vlan102 xe3，xe4；sa1；
Vlan4002 xe3，xe4；sa1；
Trunk sa1 xe1，xe8；
也就是说，ge1、ge2、ge4、xe2、xe7接口可以允许管理控制报文通过；xe3、xe4接口可以允许鉴权报文或者上行业务或下行业务报文通过；xe2接口可以允许鉴权报文通过，sa1接口可以允许上行业务报文或者下行业务报文通过。
例如，报文的进来物理接口为ge1，VLAN为3000，则确定接收的报文为管理控制报文；
又例如，报文的进来物理接口为xe3，VLAN为103或4003，则确定接收的报文为鉴权报文；
又例如，报文的进来物理接口为xe3，VLAN为101或102或4001或4002，则确定接收的报文为业务报文。
102、通过业务聚合Trunk端口，广播负载检测请求消息，以使接收所述负载检测请求消息的各业务CPU分别通过各自的第一端口返回负载检测响应消息，所述负载检测响应消息中包括对应业务CPU的当前负载比率及管理IP地址。
在本发明的一个可选实施方式中，各业务CPU分别通过各自的第一端口和第二端口，与外部进行通信，其中，各业务CPU的第一端口的逻辑接口标识为spi1，分别与交换单元的业务聚合Trunk端口连接，如图2所示，第一业务CPU的第一端口与交换单元的Xe1接口连接，第二业务CPU的第一端口与交换单元的Xe8接口连接，只允许业务报文通过；各业务CPU的第二端口的逻辑接口标识为spi0，第一业务CPU的第二端口与交换单元的Xe2接口连接，第二业务CPU的第二端口与交换单元的Xe7接口连接，只允许管理控制报文或鉴权报文通过。
为了方便各业务CPU的处理，在本发明的一个可选实施方式中，可以对各业务CPU的网口进行虚拟局域网配置，表1为各业务CPU的虚拟局域网配置，具体配置如表1所示：
表1：
在本发明的一个可选实施方式中，对各业务CPU的网口进行虚拟局域网配置，具体实现时可以为：
需要说明的是，逻辑接口标识phy_if_id表示哪个物理端口收发该逻辑接口标识对应的报文。其中，Phy_if_id的取值例如可以为：0-spi0，1-spi1。
在本发明的一个可选实施方式中，phy_if_id的配置规则如下：
处理鉴权报文的逻辑接口标识phy_if_id配置为spi0；
配置管理控制报文(例如配置、查询、检测报文)的逻辑接口标识phy_if_id配置为spi0；
配置上行业务报文的浮动接口的逻辑接口标识phy_if_id配置为spi1；
配置下行业务报文的浮动接口的逻辑接口标识phy_if_id配置为spi1；
配置上行业务报文的单机接口的逻辑接口标识phy_if_id配置为spi0；
配置下行业务报文的单机接口的逻辑接口标识phy_if_id配置为spi0。
需要说明的是，本实施例中，各业务CPU配置的逻辑网口和业务配置参数是相同的，具体实现时，如图2所示，例如，在管理CPU上创建一个管理程序，管理CPU通过管理程序配置和维护各业务CPU的管理IP(表1中的IP地址)，管理CPU通过交换单元与各业务CPU通信。管理CPU可以将配置命令通过所述交换单元中与第一业务CPU(主业务CPU)的第二端口对应的第二控制端口发送给第一业务CPU，以使第一业务CPU将所述配置命令同步发送给第二业务CPU(其他业务CPU)，所述配置命令中包含逻辑网口和业务配置参数。第二业务CPU分别根据配置命令中包含的逻辑网口和业务配置参数，进行相应的配置操作。
在本发明的一个可选实施方式中，为了实现各业务CPU之间的负载均衡，交换单元可以通过预设的Trunk端口向各业务CPU广播负载检测请求消息，用以获取各业务CPU的当前负载比率；
各业务CPU根据接收到的负载检测请求消息，分别获取各自对应的当前负载比率，并分别通过各自对应的第一端口(逻辑接口标识spi1)向交换单元返回负载检测响应消息，各负载检测响应消息中包括对应业务CPU的当前负载比率及管理IP地址。
103、根据所述各负载检测响应消息中包含的对应业务CPU的当前负载比率及管理IP地址，将所述业务报文发送给当前负载比率最小的业务CPU。
在本发明的一个可选实施方式中，交换单元根据各业务CPU返回的负载检测响应消息中包含的对应业务CPU的当前负载比率及管理IP地址，获取当前负载比率最小的业务CPU对应的管理IP地址；根据所述获取的管理IP地址，通过与所述当前负载比率最小的业务CPU的第一端口将所述业务报文发送给与所述获取的管理IP地址对应的业务。具体实现时，如图2所示，假设第二业务CPU的当前负载比率比第一业务CPU的当前负载比率小时，交换单元可以将业务报文通过交换单元的Xe8接口和第二业务CPU的第一端口(逻辑接口标识spi1)，向第二业务CPU发送业务报文。
在本发明的一个可选实施方式中，交换单元接收报文，若确定所述报文为管理控制报文；则通过预设的第一管理控制端口，如图2所示的ge4接口，将所述管理控制报文发送给对应的管理CPU，以便管理CPU根据接收的管理控制报文对各业务CPU进行管理和控制。
管理CPU根据接收的管理控制报文对各业务CPU进行管理和控制，具体实现时可以为：
若管理CPU确定管理控制报文为汇总类型的管理控制报文，则管理CPU将汇总类型的管理控制报文通过第一管理控制接口(ge4接口)发送给交换单元，交换单元通过预设的第二管理控制端口，如图2所示的xe2和xe7接口，将汇总类型的管理控制报文分别发送给各业务CPU，其中，各业务CPU分别通过各自对应第二端口(逻辑接口标识为spi0)向交换单元发送管理控制响应消息，以使交换单元将各业务CPU发送的管理控制响应消息通过第一管理控制接口(ge4接口)发送给管理CPU。
其中，汇总类型的管理控制报文包括但不限于心跳检测报文或查询报文或统计报文等，例如，管理CPU通过心跳检测报文检测各业务CPU的状态，当其中一个业务CPU异常时，管理CPU可以重启该业务CPU。
若管理CPU确定所述管理控制报文为非汇总类型的管理控制报文，则管理CPU将非汇总类型的管理控制报文通过第一管理控制接口(ge4接口)发送给交换单元，交换单元通过与主业务CPU(图2所示的第一业务CPU)连接第二管理控制端口(xe2)将该非汇总类型的管理控制报文发送给主业务CPU；主业务CPU通过自身的第二端口(逻辑接口标识为spi0)向交换单元发送管理控制响应消息，以使交换单元将主业务CPU发送的管理控制响应消息通过第一管理控制接口(ge4接口)发送给管理CPU。
在本发明的一个可选实施方式中，交换单元接收报文，若确定所述报文为认证请求鉴权报文；则通过交换单元中与主业务CPU(图2所示的第一业务CPU)连接第二管理控制端口(xe2)，将该鉴权报文发送给主业务CPU。
本发明实施例当接收到业务报文时，通过预设的业务聚合Trunk端口向各业务CPU发送负载检测请求消息，用以获取各业务CPU的当前负载比率及对应的管理IP地址，将业务报文通过业务聚合Trunk端口发送给当前负载比率最小的业务CPU，从而可以实现将业务报文均衡的发送给各业务CPU，使得各业务CPU不用争抢系统资源，可以提高系统资源的利用率，因此，本实施例的技术方案可以使得基于非对称多处理技术的多个CPU也能实现多CPU之间的负载均衡。
进一步地，本发明实施例根据接收到的报文的不同类型，分别通过预设的端口将报文发送给对应的CPU，例如，将管理控制报文通过第一管理控制端口发送给管理CPU，可以实现通过管理CPU对各业务CPU进行统一管理和控制，从而可以提高系统的可靠性、可扩充性和抗灾难性。例如，当其中的一个业务CPU发生故障时，管理CPU可以重启该业务CPU。
图3为本发明另一实施例提供的交换单元的结构示意图，如图3所示，包括：
确定模块31，用于接收报文，确定所述报文为业务报文；
广播模块32，用于在所述确定模块确定所述报文为业务报文的基础上，通过业务聚合Trunk端口，广播负载检测请求消息，以使接收所述负载检测请求消息的各业务CPU分别通过各自的第一端口返回负载检测响应消息，所述负载检测响应消息中包括对应业务CPU的当前负载比率及管理IP地址；
发送模块33，用于根据所述广播模块接收的各业务CPU返回的负载检测响应消息中包含的对应业务CPU的当前负载比率及管理IP地址，将所述业务报文发送给当前负载比率最小的业务CPU。
在本发明的一个可选实施方式中，发送模块33，具体用于根据述广播模块接收的各业务CPU返回的负载检测响应消息中包含的对应业务CPU的当前负载比率及管理IP地址，获取当前负载比率最小的业务CPU对应的管理IP地址；根据所述获取的管理IP地址，通过与所述当前负载比率最小的业务CPU的第一端口将所述业务报文发送给与所述获取的管理IP地址对应的业务CPU。
在本发明的一个可选实施方式中，确定模块31，还用于确定所述报文为管理控制报文；
对应地，发送模块33，还用于在所述确定模块确定所述报文为管理控制报文的基础上，通过第一管理控制端口，将所述管理控制报文发送给对应的管理CPU，以使所述管理CPU对所述各业务CPU进行管理和控制。
在本发明的一个可选实施方式中，确定模块31，还用于确定所述报文为认证请求鉴权报文；
对应地，发送模块33，还用于在所述确定模块确定所述报文为鉴权报文的基础上，通过与主业务CPU的第二端口对应的第二管理控制端口，将所述鉴权报文发送给与所述主业务CPU，所述主业务CPU为所述各业务CPU的其中一个CPU。
需要说明的是，为了实现本实施例交换单元的功能，需要对交换单元的各物理端口和各业务CPU的各物理端口进行虚拟局域网(Virtual Local Area Network，VLAN)配置，具体配置详见图1所示实施例中的相关描述，不再赘述。
本发明实施例的交换单元接收到业务报文时，可以通过预设的业务聚合Trunk端口向各业务CPU发送负载检测请求消息，用以获取各业务CPU的当前负载比率及对应的管理IP地址，将业务报文通过业务聚合Trunk端口发送给当前负载比率最小的业务CPU，从而可以实现将业务报文均衡的发送给各业务CPU，使得各业务CPU不用争抢系统资源，因此，可以提高系统资源的利用率，因此，本实施例的技术方案可以使得基于非对称多处理技术的多个CPU也能实现多CPU之间的负载均衡。
进一步地，本发明实施例的交换单元可以根据接收的报文的不同类型，分别通过预设的端口将报文发送给对应的CPU，例如，将管理控制报文通过第一管理控制端口发送给管理CPU，可以实现通过管理CPU对各业务CPU进行统一管理和控制，从而可以提高系统的可靠性、可扩充性和抗灾难性。例如，当其中的一个业务CPU发生故障时，管理CPU可以重启该业务CPU。
图4为本发明另一实施例提供的交换单元的结构示意图，如图4所示，包括：处理器，当处理器运行时，可以执行如下步骤：
接收报文，确定所述报文为业务报文；
通过业务聚合Trunk端口，广播负载检测请求消息，以使接收所述负载检测请求消息的各业务CPU分别通过各自的第一端口返回负载检测响应消息，所述负载检测响应消息中包括对应业务CPU的当前负载比率及管理IP地址；
根据所述各负载检测响应消息中包含的对应业务CPU的当前负载比率及管理IP地址，将所述业务报文发送给当前负载比率最小的业务CPU。
在第一种可能的实现方式中，当处理器运行时，还可以执行：
根据所述各负载检测响应消息中包含的对应业务CPU的当前负载比率及管理IP地址，获取当前负载比率最小的业务CPU对应的管理IP地址；
根据所述获取的管理IP地址，通过与所述当前负载比率最小的业务CPU的第一端口将所述业务报文发送给与所述获取的管理IP地址对应的业务CPU。
在第二种可能的实现方式中，当处理器运行时，还可以执行：
接收报文，确定所述报文为管理控制报文；
通过第一管理控制端口，将所述管理控制报文发送给对应的管理CPU，以使所述管理CPU对所述各业务CPU进行管理和控制。
在第三种可能的实现方式中，当处理器运行时，还可以执行：
接收报文，确定所述报文为认证请求鉴权报文；
通过与主业务CPU的第二端口对应的第二管理控制端口，将所述鉴权报文发送给与所述主业务CPU，所述主业务CPU为所述各业务CPU的其中一个CPU。
本发明实施例的交换单元接收到业务报文时，可以通过预设的业务聚合Trunk端口向各业务CPU发送负载检测请求消息，用以获取各业务CPU的当前负载比率及对应的管理IP地址，将业务报文通过业务聚合Trunk端口发送给当前负载比率最小的业务CPU，从而可以实现将业务报文均衡的发送给各业务CPU，使得各业务CPU不用争抢系统资源，因此，可以提高系统资源的利用率，因此，本实施例的技术方案可以使得基于非对称多处理技术的多个CPU也能实现多CPU之间的负载均衡。
进一步地，本发明实施例的交换单元可以根据接收的报文的不同类型，分别通过预设的端口将报文发送给对应的CPU，例如，将管理控制报文通过第一管理控制端口发送给管理CPU，可以实现通过管理CPU对各业务CPU进行统一管理和控制，从而可以提高系统的可靠性、可扩充性和抗灾难性。例如，当其中的一个业务CPU发生故障时，管理CPU可以重启该业务CPU。
图5为本发明另一实施例提供的多CPU的报文处理系统的结构示意图，如图5所示，所述系统用于与系统外部进行通信，具体包括：业务CPU51和交换单元52，业务CPU51的个数至少为两个，其中的一个业务CPU为主业务CPU，另一个为从业务CPU；
需要说明的是，假设业务CPU的个数为两个以上，本实施例将各业务CPU中的一个业务CPU作为主业务CPU，其他的业务CPU均为从业务CPU。
在本发明的一个可选实施方式中，交换单元52分别与各业务CPU51连接，具体为：
本实施例的交换单元52分别给每个业务CPU提供两个接口，为了数据业务层面和管理控制层面的分离，将其中一个接口(简称业务端口)用于收发业务报文，另外一个接口(第二管理控制端口)收发管理控制报文或鉴权报文。
为了实现各业务CPU之间的负载均衡，本实施例中，将交换单元的各业务端口聚合一起作为业务聚合Trunk端口，分别与各业务CPU的第一端口连接，只允许业务报文通过；将交换单元的各第二管理控制端口分别与各业务CPU的第二端口连接，只允许管理控制报文或鉴权报文通过。
交换单元52，用于接收报文，确定所述报文为业务报文；通过业务聚合Trunk端口，广播负载检测请求消息，以使接收所述负载检测请求消息的各业务CPU分别通过各自的第一端口返回负载检测响应消息，所述负载检测响应消息中包括对应业务CPU的当前负载比率及管理IP地址；根据所述各负载检测响应消息中包含的对应业务CPU的当前负载比率及管理IP地址，将所述业务报文发送给当前负载比率最小的业务CPU；
各业务CPU51，分别用于根据接收到的所述业务报文进行相应的业务操作。
需要说明的是，交换单元52，具体用于根据所述各负载检测响应消息中包含的对应业务CPU的当前负载比率及管理IP地址，获取当前负载比率最小的业务CPU对应的管理IP地址；根据所述获取的管理IP地址，通过与所述当前负载比率最小的业务CPU的第一端口将所述业务报文发送给与所述获取的管理IP地址对应的业务CPU。
在本发明的一个可选实施方式中，所述系统还包括：管理CPU53，与所述交换单元52连接；具体为：
为了实现管理CPU对各业务CPU的统一管理，本实施例的交换单元52提供第一管理控制端口与管理CPU53连接。
交换单元53，还用于接收报文，确定所述报文为管理控制报文；通过第一管理端口，将所述管理控制报文发送给所述管理CPU；
管理CPU53，用于若确定所述管理控制报文中包括配置命令，则将所述配置命令通过所述第一管理控制端口发送给所述交换单元，以使所述交换单元将所述配置命令通过与所述主业务CPU的第二端口对应的第二管理控制端口发送给所述主业务CPU，以使所述主业务CPU通过所述交换单元将所述配置命令同步发送给其他业务CPU，所述配置命令中包含逻辑网口和业务配置参数；
各业务CPU51，分别用于根据所述配置命令中包含的逻辑网口和业务配置参数，进行相应的配置操作；
需要说明的是，所述各业务CPU配置的逻辑网口和业务配置参数是相同的。
管理CPU53，还用于若确定所述管理控制报文为汇总类型的管理控制报文，则将所述汇总类型的管理控制报文通过所述第一管理控制端口发送给所述交换单元，以使所述交换单元将所述汇总类型的管理控制报文通过第二管理控制端口分别发送给各业务CPU，所述汇总类型的管理控制报文包括心跳检测报文或查询报文或统计报文中至少一项，以使各业务CPU通过所述交换单元分别向所述管理CPU返回管理控制响应消息；
管理CPU53，还用于若确定所述管理控制报文为非汇总类型的管理控制报文，则将所述非汇总类型的管理控制报文通过所述第一管理控制端口发送给所述交换单元，以使所述交换单元将所述非汇总类型的管理控制报文通过与所述主业务CPU的第二端口对应的第二管理控制端口发送给所述主业务CPU，以使所述主业务CPU通过所述交换单元向所述管理CPU返回管理控制响应消息。
需要说明的是，本实施例中，各业务CPU的组网配置、业务配置、运行数据(如会话保持表、地址解析协议(Address Resolution Protocol，ARP)表、服务Server状态)都是一样的，不同的是各业务CPU的管理IP不同。
管理CPU通过各业务CPU的管理IP实现对各业务CPU的管理，例如，管理CPU负责为各业务CPU提供统一的对外接口，管理CPU管理各业务CPU的配置、统计和查询；管理CPU通过心跳检测各业务CPU的状态；以及能够加载、重启各业务CPU。
在本发明的一个可选实施方式中，交换单元52，还用于接收报文，确定所述报文为认证请求鉴权报文；通过与所述主业务CPU的第二端口对应的第二管理控制端口，将所述鉴权报文发送给与所述主业务CPU。
需要说明的是，本实施例中，可以在管理CPU上创建一个管理程序，管理CPU通过管理程序维护各业务CPU的管理IP(表1中的IP地址)，实现对各业务CPU的管理与控制，图6为图5所示系统实施例中管理CPU与各业务CPU之间的信令图，具体实现如图6所示：
在本发明的一个可选实施方式中，当管理CPU收到系统外部发送的配置命令时，将配置命令发送给主业务CPU，具体实现时，管理CPU通过第一管理控制端口将配置命令发送给交换单元，交换单元将配置命令通过与主业务CPU的第二端口连接的第二管理控制端口发送给主业务CPU。
主业务CPU处理完配置命令后，实时同步将配置命令发送给各从业务CPU，并等待各从业务CPU返回的配置命令响应。需要说明的是，当某个从业务LBU同步配置不成功时，主业务CPU重新同步将配置命令给该从业务CPU；当所有业务CPU配置完成后，主业务CPU向管理CPU返回配置命令响应，具体实现时，主业务CPU将配置命令响应通过自身的第二端口发送给交换单元，交换单元将配置命令响应通过第一管理控制端口发送给管理CPU，以使管理CPU可以将接收到的配置命令响应返回给系统外部。
需要说明的是，本实施例中，当主CPU收到管理CPU发送的保存配置命令时，主CPU可以将内存中的配置命令保存到例如闪存flash中，当主业务CPU重启时，可以从flash中读取配置命令，并将配置命令存放到内存中。当从业务CPU重启时，可以向主业务CPU请求将配置命令发送给自己。
在本发明的一个可选实施方式中，当管理CPU13收到系统外部发送的汇总类型的管理控制报文，例如汇总类型的查询命令1，将查询命令1发送给主业务CPU，具体实现时，管理CPU通过第一管理控制端口将查询命令1发送给交换单元，交换单元将查询命令1分别通过第二管理控制端口发送给主业务CPU和从业务CPU，主业务CPU和从业务CPU执行完查询命令1后，分别向管理CPU返回查询命令1的响应，具体实现时，主业务CPU和从业务CPU将查询命令1的响应通过自身的第二端口发送给交换单元，交换单元将查询命令1的响应通过第一管理控制端口发送给管理CPU，管理CPU可以将接收到的查询命令1的响应返回给系统外部。
在本发明的一个可选实施方式中，当管理CPU收到系统外部发送的非汇总类型的管理控制报文，例如非汇总类型的查询命令2，将查询命令2发送给主业务CPU，具体实现时，管理CPU通过第一管理控制端口将查询命令2发送给交换单元，交换单元通过与主业务CPU的第二端口对应的第二管理控制端口将查询命令2发送给主业务CPU，主业务CPU执行完查询命令2后，向管理CPU返回查询命令2的响应，具体实现时，主业务CPU将查询命令2的响应通过自身的第二端口发送给交换单元，交换单元将查询命令2的响应通过第一管理控制端口发送给管理CPU，管理CPU可以将接收到的查询命令2的响应返回给系统外部。
需要说明的是，本实施例中，各业务CPU的组网配置、业务配置、运行数据(如会话保持表、地址解析协议(Address Resolution Protocol，ARP)表、服务Server状态)都是一样的，不同的是各业务CPU的管理IP不同。
管理CPU通过各业务CPU的管理IP实现对各业务CPU的管理，例如，管理CPU负责为各业务CPU提供统一的对外接口，管理CPU管理各业务CPU的配置、统计和查询；管理CPU通过心跳检测各业务CPU的状态；以及能够加载、重启各业务CPU。
本发明实施例所述系统接收到业务报文时，可以通过预设的业务聚合Trunk端口向各业务CPU发送负载检测请求消息，用以获取各业务CPU的当前负载比率及对应的管理IP地址，将业务报文通过业务聚合Trunk端口发送给当前负载比率最小的业务CPU，从而可以实现将业务报文均衡的发送给各业务CPU，使得各业务CPU不用争抢系统资源，因此，可以提高系统资源的利用率，因此，本实施例的技术方案可以使得基于非对称多处理技术的多个CPU也能实现多CPU之间的负载均衡。
进一步地，本发明实施例的交换单元可以根据接收的报文的不同类型，分别通过预设的端口将报文发送给对应的CPU，例如，将管理控制报文通过第一管理控制端口发送给管理CPU，可以实现通过管理CPU对各业务CPU进行统一管理和控制，从而可以提高系统的可靠性、可扩充性和抗灾难性。例如，当其中的一个业务CPU发生故障时，管理CPU可以重启该业务CPU。
本发明另一实施例提供一种单板，包括如图5所示实施例所述的多CPU的报文处理系统，具体实现原理和技术效果参见图5所示实施例中的相关内容。
所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统，装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。
在本申请所提供的几个实施例中，应该理解到，所揭露的系统，装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。
所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
另外，在本发明各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用硬件加软件功能单元的形式实现。
上述以软件功能单元的形式实现的集成的单元，可以存储在一个计算机可读取存储介质中。上述软件功能单元存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本发明各个实施例所述方法的部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(Read-Only Memory，简称ROM)、随机存取存储器(Random Access Memory，简称RAM)、磁碟或者光盘等各种可以存储程序代码的介质。
最后应说明的是：以上实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的精神和范围。
Claims (17)
1.一种多CPU的报文处理方法，其特征在于，所述多CPU的报文处理方法应用于多个CPU基于非对称多处理技术的场景，各CPU之间内存子系统以及总线结构相互独立，包括：
交换单元接收报文，确定所述报文为业务报文；
通过业务聚合Trunk端口，广播负载检测请求消息，以使接收所述负载检测请求消息的各业务CPU分别通过各自的第一端口返回负载检测响应消息，所述负载检测响应消息中包括对应业务CPU的当前负载比率及管理IP地址；
根据所述各负载检测响应消息中包含的对应业务CPU的当前负载比率及管理IP地址，将所述业务报文发送给当前负载比率最小的业务CPU。
2.根据权利要求1所述的方法，其特征在于，根据所述各负载检测响应消息中包含的对应业务CPU的当前负载比率及管理IP地址，将所述业务报文发送给当前负载比率最小的业务CPU具体包括：
根据所述各负载检测响应消息中包含的对应业务CPU的当前负载比率及管理IP地址，获取当前负载比率最小的业务CPU对应的管理IP地址；
根据所述获取的管理IP地址，通过与所述当前负载比率最小的业务CPU的第一端口将所述业务报文发送给与所述获取的管理IP地址对应的业务CPU。
3.根据权利要求1所述的方法，其特征在于，还包括：
接收报文，确定所述报文为管理控制报文；
通过第一管理控制端口，将所述管理控制报文发送给与所述管理端口对应的管理CPU，以使所述管理CPU对所述各业务CPU进行管理和控制。
4.根据权利要求1所述的方法，其特征在于，还包括：
接收报文，确定所述报文为鉴权报文；
通过与主业务CPU的第二端口对应的第二管理控制端口，将所述鉴权报文发送给所述主业务CPU，所述主业务CPU为所述各业务CPU的其中一个CPU。
5.一种交换单元，其特征在于，所述交换单元应用于多个CPU基于非对称多处理技术的场景，各CPU之间内存子系统以及总线结构相互独立，包括：
确定模块，用于接收报文，确定所述报文为业务报文；
广播模块，用于在所述确定模块确定所述报文为业务报文的基础上，通过业务聚合Trunk端口，广播负载检测请求消息，以使接收所述负载检测请求消息的各业务CPU分别通过各自的第一端口返回负载检测响应消息，所述负载检测响应消息中包括对应业务CPU的当前负载比率及管理IP地址；
发送模块，用于根据所述广播模块接收的各业务CPU返回的负载检测响应消息中包含的对应业务CPU的当前负载比率及管理IP地址，将所述业务报文发送给当前负载比率最小的业务CPU。
6.根据权利要求5所述的交换单元，其特征在于，所述发送模块，具体用于根据述广播模块接收的各业务CPU返回的负载检测响应消息中包含的对应业务CPU的当前负载比率及管理IP地址，获取当前负载比率最小的业务CPU对应的管理IP地址；根据所述获取的管理IP地址，通过与所述当前负载比率最小的业务CPU的第一端口将所述业务报文发送给与所述获取的管理IP地址对应的业务CPU。
7.根据权利要求5所述的交换单元，其特征在于，所述确定模块，还用于确定所述报文为管理控制报文；
所述发送模块，还用于在所述确定模块确定所述报文为管理控制报文的基础上，通过第一管理控制端口，将所述管理控制报文发送给对应的管理CPU，以使所述管理CPU对所述各业务CPU进行管理和控制。
8.根据权利要求5所述的交换单元，其特征在于，所述确定模块，还用于确定所述报文为认证请求鉴权报文；
所述发送模块，还用于在所述确定模块确定所述报文为鉴权报文的基础上，通过与主业务CPU的第二端口对应的第二管理控制端口，将所述鉴权报文发送给所述主业务CPU，所述主业务CPU为所述各业务CPU的其中一个CPU。
9.一种交换单元，其特征在于，所述交换单元应用于多个CPU基于非对称多处理技术的场景，各CPU之间内存子系统以及总线结构相互独立，包括：处理器，所述处理器具体用于：
接收报文，确定所述报文为业务报文；
通过业务聚合Trunk端口，广播负载检测请求消息，以使接收所述负载检测请求消息的各业务CPU分别通过各自的第一端口返回负载检测响应消息，所述负载检测响应消息中包括对应业务CPU的当前负载比率及管理IP地址；
根据所述各负载检测响应消息中包含的对应业务CPU的当前负载比率及管理IP地址，将所述业务报文发送给当前负载比率最小的业务CPU。
10.根据权利要求9所述的交换单元，所述处理器具体还用于：根据所述各负载检测响应消息中包含的对应业务CPU的当前负载比率及管理IP地址，获取当前负载比率最小的业务CPU对应的管理IP地址；
根据所述获取的管理IP地址，通过与所述当前负载比率最小的业务CPU的第一端口将所述业务报文发送给与所述获取的管理IP地址对应的业务CPU。
11.根据权利要求9所述的交换单元，所述处理器具体还用于：
接收报文，确定所述报文为管理控制报文；
通过第一管理控制端口，将所述管理控制报文发送给对应的管理CPU，以使所述管理CPU对所述各业务CPU进行管理和控制。
12.根据权利要求9所述的交换单元，所述处理器具体还用于：
接收报文，确定所述报文为认证请求鉴权报文；
通过与主业务CPU的第二端口对应的第二管理控制端口，将所述鉴权报文发送给所述主业务CPU，所述主业务CPU为所述各业务CPU的其中一个CPU。
13.一种多CPU的报文处理系统，用于与所述系统外部进行通信，其特征在于，所述系统应用于多个CPU基于非对称多处理技术的场景，各CPU之间内存子系统以及总线结构相互独立，包括：各业务CPU和交换单元，所述各业务CPU至少包括两个业务CPU，所述各业务CPU的其中一个业务CPU为主业务CPU；
所述交换单元分别与所述各业务CPU连接，具体为：所述交换单元的业务聚合Trunk端口分别与所述各业务CPU的第一端口连接，所述交换单元的各第二管理控制端口分别与所述各业务CPU的第二端口连接；
所述交换单元，用于接收报文，确定所述报文为业务报文；通过业务聚合Trunk端口，广播负载检测请求消息，以使接收所述负载检测请求消息的各业务CPU分别通过各自的第一端口返回负载检测响应消息，所述负载检测响应消息中包括对应业务CPU的当前负载比率及管理IP地址；根据所述各负载检测响应消息中包含的对应业务CPU的当前负载比率及管理IP地址，将所述业务报文发送给当前负载比率最小的业务CPU；
所述各业务CPU，分别用于根据接收到的所述业务报文进行相应的业务操作。
14.根据权利要求13所述的系统，其特征在于，所述交换单元，具体用于根据所述各负载检测响应消息中包含的对应业务CPU的当前负载比率及管理IP地址，获取当前负载比率最小的业务CPU对应的管理IP地址；
根据所述获取的管理IP地址，通过与所述当前负载比率最小的业务CPU的第一端口将所述业务报文发送给与所述获取的管理IP地址对应的业务CPU。
15.根据权利要求13所述的系统，其特征在于，还包括：管理CPU，通过第一管理控制端口与所述交换单元连接；
所述交换单元，还用于接收报文，确定所述报文为管理控制报文；通过第一管理端口，将所述管理控制报文发送给所述管理CPU；
所述管理CPU，用于若确定所述管理控制报文中包括配置命令，则将所述配置命令通过所述第一管理控制端口发送给所述交换单元，以使所述交换单元将所述配置命令通过与所述主业务CPU的第二端口对应的第二管理控制端口发送给所述主业务CPU，以使所述主业务CPU通过所述交换单元将所述配置命令同步发送给其他业务CPU，所述配置命令中包含逻辑网口和业务配置参数；
所述各业务CPU，分别用于根据所述配置命令中包含的逻辑网口和业务配置参数，进行相应的配置操作；
所述各业务CPU配置的逻辑网口和业务配置参数是相同的；
所述管理CPU，还用于若确定所述管理控制报文为汇总类型的管理控制报文，则将所述汇总类型的管理控制报文通过所述第一管理控制端口发送给所述交换单元，以使所述交换单元将所述汇总类型的管理控制报文通过第二管理控制端口分别发送给各业务CPU，所述汇总类型的管理控制报文包括心跳检测报文或查询报文或统计报文中至少一项，以使各业务CPU通过所述交换单元分别向所述管理CPU返回管理控制响应消息；
所述管理CPU，还用于若确定所述管理控制报文为非汇总类型的管理控制报文，则将所述非汇总类型的管理控制报文通过所述第一管理控制端口发送给所述交换单元，以使所述交换单元将所述非汇总类型的管理控制报文通过与所述主业务CPU的第二端口对应的第二管理控制端口发送给所述主业务CPU，以使所述主业务CPU通过所述交换单元向所述管理CPU返回管理控制响应消息。
16.根据权利要求13所述的系统，其特征在于，所述交换单元，还用于接收报文，确定所述报文为认证请求鉴权报文；通过与所述主业务CPU的第二端口对应的第二管理控制端口，将所述鉴权报文发送给所述主业务CPU。
17.一种单板，其特征在于，所述单板包括：至少一个如权利要求13-16中任一项所述的多CPU的报文处理系统。
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| PCT/CN2012/079959 WO2014023023A1 (zh) | 2012-08-10 | 2012-08-10 | 多cpu的报文处理方法及系统、交换单元、单板 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN103765837A CN103765837A (zh) | 2014-04-30 |
| CN103765837B true CN103765837B (zh) | 2016-08-10 |
Family
ID=50067405
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201280001081.6A Expired - Fee Related CN103765837B (zh) | 2012-08-10 | 2012-08-10 | 多cpu的报文处理方法及系统、交换单元、单板 |
Country Status (2)
| Country | Link |
|---|---|
| CN (1) | CN103765837B (zh) |
| WO (1) | WO2014023023A1 (zh) |
Families Citing this family (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN104598412A (zh) * | 2014-10-17 | 2015-05-06 | 新浪网技术(中国)有限公司 | 一种数据传输方法及装置 |
| CN111651203B (zh) * | 2016-04-26 | 2024-05-07 | 中科寒武纪科技股份有限公司 | 一种用于执行向量四则运算的装置和方法 |
| CN112468348B (zh) * | 2020-12-16 | 2024-04-26 | 中国航空研究院 | 适配总线型网络和交换型网络的系统 |
Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN1719806A (zh) * | 2005-07-15 | 2006-01-11 | 中国人民解放军国防科学技术大学 | 基于cache的网络处理器的动态负载分配方法及其装置 |
| CN101207550A (zh) * | 2007-03-16 | 2008-06-25 | 中国科学技术大学 | 负载均衡系统及多种业务实现负载均衡的方法 |
| CN101217467A (zh) * | 2007-12-28 | 2008-07-09 | 杭州华三通信技术有限公司 | 核间负载分发装置及方法 |
| CN101662506A (zh) * | 2009-10-14 | 2010-03-03 | 中兴通讯股份有限公司 | 一种基于cpu内核共享的负载均衡方法和装置 |
Family Cites Families (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20020107962A1 (en) * | 2000-11-07 | 2002-08-08 | Richter Roger K. | Single chassis network endpoint system with network processor for load balancing |
| CN100450037C (zh) * | 2006-08-30 | 2009-01-07 | 华为技术有限公司 | 一种ip报文负载分担实现方法及装置 |
| CN101577705A (zh) * | 2008-05-08 | 2009-11-11 | 北京东华合创数码科技股份有限公司 | 一种多核并行的网络业务流负载均衡方法及其系统 |
| CN101494611B (zh) * | 2009-02-20 | 2011-09-14 | 华为技术有限公司 | 一种负载分担调整方法和装置 |
-
2012
- 2012-08-10 WO PCT/CN2012/079959 patent/WO2014023023A1/zh active Application Filing
- 2012-08-10 CN CN201280001081.6A patent/CN103765837B/zh not_active Expired - Fee Related
Patent Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN1719806A (zh) * | 2005-07-15 | 2006-01-11 | 中国人民解放军国防科学技术大学 | 基于cache的网络处理器的动态负载分配方法及其装置 |
| CN101207550A (zh) * | 2007-03-16 | 2008-06-25 | 中国科学技术大学 | 负载均衡系统及多种业务实现负载均衡的方法 |
| CN101217467A (zh) * | 2007-12-28 | 2008-07-09 | 杭州华三通信技术有限公司 | 核间负载分发装置及方法 |
| CN101662506A (zh) * | 2009-10-14 | 2010-03-03 | 中兴通讯股份有限公司 | 一种基于cpu内核共享的负载均衡方法和装置 |
Also Published As
| Publication number | Publication date |
|---|---|
| WO2014023023A1 (zh) | 2014-02-13 |
| CN103765837A (zh) | 2014-04-30 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN110301104B (zh) | 一种光线路终端olt设备虚拟方法及相关设备 | |
| CN105260337B (zh) | 一种单片机的自动编址方法及系统 | |
| CN105024855A (zh) | 分布式集群管理系统和方法 | |
| CN102316043B (zh) | 端口虚拟化方法、交换机及通信系统 | |
| US10992526B1 (en) | Hyper-converged infrastructure networking configuration system | |
| CN104144098A (zh) | 消息推送方法、系统及推送服务器设备 | |
| CN103441935B (zh) | 自动识别服务器与接入交换机的邻接关系的方法及装置 | |
| CN106060088A (zh) | 一种服务管理方法及装置 | |
| US20140098821A1 (en) | System and method for providing remote management of a switching device | |
| CN109565447A (zh) | 网络功能处理方法及相关设备 | |
| CN103765837B (zh) | 多cpu的报文处理方法及系统、交换单元、单板 | |
| CN102957594A (zh) | 基于消息队列的消息处理方法、相关设备及系统 | |
| CN109245926A (zh) | 智能网卡、智能网卡系统及控制方法 | |
| CN115348126A (zh) | 一种网络靶场实体设备接入方法、装置及实现系统 | |
| CN104144130A (zh) | 虚拟机系统互联的方法、系统和接入交换机 | |
| CN103618778A (zh) | 利用Linux虚拟主机实现数据高并发的系统及方法 | |
| CN102932209A (zh) | 服务器机群的状态检测方法和装置 | |
| CN105553865B (zh) | 一种fc交换机芯片信用管理测试方法 | |
| CN105516232A (zh) | San存储系统应用软件管理方法、管理服务器、主机及系统 | |
| US20080062976A1 (en) | System, method and apparatus for remote access to system control management within teamed network communication environments | |
| CN106790411A (zh) | 虚拟交换机与物理交换机的非聚合端口级联系统及方法 | |
| US10320741B2 (en) | Server IP address assignment system and method | |
| CN104104594A (zh) | Vsu的协议报文发送与接收方法、设备及系统 | |
| CN105939242B (zh) | 实现虚拟系统的方法及装置 | |
| CN103281308A (zh) | 一种数据传输方法和设备 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| C06 | Publication | ||
| PB01 | Publication | ||
| C10 | Entry into substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| C14 | Grant of patent or utility model | ||
| GR01 | Patent grant | ||
| TR01 | Transfer of patent right |
Effective date of registration: 20180510 Address after: California, USA Patentee after: Global innovation polymerization LLC Address before: Lun Dun Patentee before: GW partnership Co.,Ltd. Effective date of registration: 20180510 Address after: London, England Patentee after: GW partnership Co.,Ltd. Address before: 518129 Bantian HUAWEI headquarters office building, Longgang District, Guangdong, Shenzhen Patentee before: HUAWEI TECHNOLOGIES Co.,Ltd. |
|
| TR01 | Transfer of patent right | ||
| CF01 | Termination of patent right due to non-payment of annual fee |
Granted publication date: 20160810 |
|
| CF01 | Termination of patent right due to non-payment of annual fee |