WO2018161632A1 - 分布式设备的容量更新方法及装置 - Google Patents

分布式设备的容量更新方法及装置 Download PDF

Info

Publication number
WO2018161632A1
WO2018161632A1 PCT/CN2017/111136 CN2017111136W WO2018161632A1 WO 2018161632 A1 WO2018161632 A1 WO 2018161632A1 CN 2017111136 W CN2017111136 W CN 2017111136W WO 2018161632 A1 WO2018161632 A1 WO 2018161632A1
Authority
WO
WIPO (PCT)
Prior art keywords
cpu
backup
packet
identifier
entry
Prior art date
Application number
PCT/CN2017/111136
Other languages
English (en)
French (fr)
Inventor
肖晓容
Original Assignee
华为技术有限公司
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 华为技术有限公司 filed Critical 华为技术有限公司
Publication of WO2018161632A1 publication Critical patent/WO2018161632A1/zh

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/10—Active monitoring, e.g. heartbeat, ping or trace-route
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/32—Flow control; Congestion control by discarding or delaying data units, e.g. packets or frames
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0896—Bandwidth or capacity management, i.e. automatically increasing or decreasing capacities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/24—Traffic characterised by specific attributes, e.g. priority or QoS

Definitions

  • the present application relates to the field of communications technologies, and in particular, to a method and an apparatus for updating a capacity of a distributed device.
  • the distributed device usually includes a management process unit (MPU), a line-card process unit (LPU), and at least one service process unit (SPU), and each SPU may include at least two central units.
  • the MPU is used to configure the service and manage the CPU in each SPU.
  • the LPU is configured to offload the received service packets to different CPUs, and the CPU in the SPU is used to process the service packets. Since each CPU in the at least one SPU is used to process service messages, the data processing efficiency of the distributed devices is significantly improved compared to the conventional box devices.
  • the distributed device may be generally configured with a backup device, so that the distributed device can continue to provide services instead of the distributed device when the distributed device fails.
  • the distributed device is referred to as a first device
  • the backup device of the distributed device is referred to as a second device, where the standby device is also generally a distributed device.
  • the MPU of the first device may regenerate the traffic distribution table according to each CPU identifier after the number of CPUs changes, and send the regenerated traffic distribution table to the LPU and replace it by the LPU.
  • the stored offload table thereby implementing the capacity update of the first device.
  • the second device can also perform capacity update in accordance with the above method.
  • the LPU of the first device After the first device performs the capacity update, when the LPU of the first device receives the service packet, the LPU of the service packet may be hashed, and the identifier of the CPU used to process the service packet is obtained. The location in the split table. The first device obtains the CPU identifier stored in the location from the stored traffic distribution table, and forwards the service packet to the CPU corresponding to the CPU identifier, so that the CPU performs the service packet by using the stored state table entry. deal with. Each state entry corresponds to a service flow, and each state entry stores a processing policy for processing a service packet on the corresponding service flow and flow information of the corresponding service flow.
  • the stream information may include a combination of a source Internet Protocol (IP) address and a destination IP address, or a combination of a source IP address, a destination IP address, a transport protocol, and a destination port.
  • IP Internet Protocol
  • the first device may periodically back up the state table stored in each CPU to the second device. device.
  • Related technologies To improve the efficiency of backup, you need to ensure that the number of CPUs and CPUs in the first device and the second device are the same. Then, the first device can generate backup packets, and the backup packets carry the first one. Status table entry in the device.
  • the first device sends the backup message to the LPU in the second device. When the LPU receives the backup message, the LPU sends the backup message to the CPU in the at least one SPU included in the second device, so as to facilitate the second
  • Each CPU in the device updates the stored state table entries.
  • the number of CPUs in the first device may change, so that the MPU generated by the MPU of the first device is different from the previously stored split table based on the updated CPU identifier.
  • the CPU may not process the CPU of the service flow to which the service message belongs before the capacity update, and thus does not store the status of the service flow to which the service message belongs. The CPU discards the service packet and the traffic is interrupted.
  • the embodiment of the present invention provides a method and device for updating the capacity of the distributed device.
  • the technical solution is as follows:
  • a method for updating a capacity of a distributed device which is performed by a first device, where the first device is a device for processing a current service packet, and the first device includes at least two CPUs. Each of the at least two CPUs corresponds to a state table entry that holds at least one service flow, and the method includes:
  • the first traffic distribution table carries a CPU identification sequence, and each CPU identifier in the CPU identification sequence respectively indicates one CPU in the second device
  • the first The offloading table is sent to the first device after the number of CPUs included in the second device is changed;
  • each backup message in the at least one backup message carries a CPU identifier and at least one state table entry corresponding to the CPU identifier;
  • the backup completion notification message is sent to the second device, and the first device is switched to a device that does not process the subsequent service packet temporarily.
  • the backup completion notification message is used to instruct the second device to switch the second device to a device for processing a subsequent service packet after updating the stored state table entry.
  • the second device After the first offloading table changes the number of CPUs in the second device, the second device generates the CPU identifier based on the changed CPU, that is, firstly, the number of CPUs in the second device is changed to perform the capacity of the second device. Update, so that when a service packet is received, the service packet can be processed by the first device, and no traffic interruption occurs.
  • the first device may determine, according to the mapping relationship, a mapping relationship between the state table entry and the CPU identifier, and generate at least one backup packet based on the mapping relationship.
  • the status table item in each CPU included in the second device is updated by using one CPU identifier carried in each backup packet and at least one state table entry corresponding to the CPU identifier in the at least one backup packet. Since the CPU identifier carried in each backup packet is determined from the first traffic distribution table, after the device that processes the service packet is switched from the first device to the second device, the second device follows the first traffic distribution. The table diverts subsequent received service packets to different ones. After the CPU, the status table of the service flow to which the service packet belongs is not stored on the CPU, and the CPU is prevented from discarding the service packet to cause traffic interruption.
  • each state entry corresponds to a service flow
  • each state entry stores a processing policy for processing a service packet on the corresponding service flow and flow information of the corresponding service flow, and the flow information It may include a combination of a source IP address and a destination IP address, or a combination of a source IP address, a destination IP address, a transport protocol, and a destination port.
  • the flow information may also be other information, for example, may include a combination of a source IP address, a destination IP address, and a transport protocol of the service flow, or a combination of a source IP address, a destination IP address, and a target port. Wait.
  • the determining the CPU identifier of each state entry in the first device in the first traffic distribution table includes:
  • the first traffic distribution table is generated based on the changed CPU identifier of the second device. Therefore, the flow information stored in each state table stored by the first device is hashed, so that the first traffic distribution table can be used from the first traffic distribution table.
  • the CPU ID corresponding to each status entry is accurately determined, which provides a reliable and accurate guarantee for the subsequent second device to process the service packet.
  • the generating, according to the mapping relationship, the at least one backup packet including:
  • the state table entries stored in the first device are divided into at least one group, and each group of state table entries includes at least one state table entry, and the CPU identifiers corresponding to the same group state table entries are the same;
  • the status table obtained after the backup is obtained.
  • the at least one set of the status table item and the CPU identifier corresponding to the at least one group of the status item may generate at least one backup message, so that each state table item and the status table item are not required.
  • a corresponding backup message is generated by the corresponding CPU identifier. That is, the embodiment of the present invention integrates the state table items backed up to the same CPU into one backup message, so that the number of backup messages can be reduced, thereby improving the state table. Item backup efficiency.
  • the first device may first encapsulate the at least one set of state entries to the at least one backup packet when the first device generates the at least one backup packet based on the CPU identifier corresponding to the at least one set of the state entry and the at least one set of the statelist.
  • the CPU identifier corresponding to each group of status entries is added to the header of the at least one packet, so that at least one backup packet is obtained.
  • a method for updating a capacity of a distributed device which is performed by a second device, where the second device is not a device that processes a current service packet, and the second device includes at least two CPUs.
  • the methods include:
  • the second device After determining that the number of CPUs included in the second device is changed, generating a first traffic distribution table, where the first traffic distribution table carries a CPU identification sequence, and each CPU identifier in the CPU identification sequence indicates that the number of CPUs respectively occurs.
  • Change The second device includes a CPU;
  • each backup message in the at least one backup message carries a CPU identifier and at least one state table entry corresponding to the CPU identifier, where each The CPU identifier carried in the backup packet is determined by the first device from the first traffic distribution table;
  • each backup packet Updating, according to a CPU identifier carried in each backup packet of the at least one backup packet, and at least one state table entry corresponding to the CPU identifier, updating, by the second device, each backup packet carries The status table item stored in the CPU indicated by the CPU identifier;
  • the second device may also be a distributed device, and the second device may also include an MPU, an LPU, and at least one SPU, and each SPU includes at least two CPUs. Therefore, the MPU in the second device may be in the SPU.
  • the CPU monitors to determine if the number of CPUs included in the second device has changed.
  • the second device may update the status table item stored by each CPU included, and then the device that processes the service packet from the first A device is switched to the second device, so that when the second device receives the service packet, the service packet is not stored on the CPU after the service packet is delivered to the CPU according to the first traffic distribution table.
  • the CPU is prevented from discarding service packets to cause traffic interruption.
  • the device for switching the second device to be used for processing a subsequent service packet includes:
  • a priority of the second device to a second priority, where the second priority is higher than a third priority, where the third priority is higher than a first priority, where the first priority is a CPU
  • the priority of the second device before the quantity changes, and the third priority is the current priority of the first device
  • the second device negotiates with the first device, so that the second device is switched to a device for processing a subsequent service packet.
  • Which of the first device and the second device is the device that processes the service packet, and which device serves as the backup device of the device, which is negotiated by the priority between the first device and the second device. And after the update of the status table item stored in each CPU included in the second device is completed, in order to avoid the problem of traffic interruption, the device that processes the service packet needs to be switched from the first device to the second device at this time, so , the priority of the second device needs to be set to the second priority.
  • generating a first offloading table including:
  • the first flow distribution table is generated based on the CPU identifier corresponding to each CPU included in the second device after the CPU is added.
  • the MPU of the second device Since the CPU is added to the second device, that is, the capacity of the second device is expanded, the MPU of the second device needs to allocate a CPU identifier to the newly added CPU.
  • the traffic distribution table is used to offload traffic packets to different CPUs. Therefore, after the number of CPUs changes, the second device needs to split the traffic table to ensure that the service packets can be accurately distributed to different CPUs.
  • the update is performed, that is, the MPU of the second device needs to regenerate the flow distribution table based on the CPU identifier corresponding to each CPU included in the second device after the CPU is added, and the regenerated flow distribution table is referred to as the first flow distribution table.
  • the determining that the number of CPUs included in the second device is changed, and generating a first offloading table including:
  • a first offload table is generated based on the CPU identifier reassigned for each CPU included in the second device.
  • the CPU identifier may be reassigned according to the CPU socket order for each CPU included in the second device after the CPU is reduced, and then based on each The CPU reassigns the CPU identifier, regenerates the offloading table, and refers to the regenerated shunt table as the first shunt table.
  • a capacity update device for a distributed device for implementing the method of the first aspect described above.
  • a capacity update device for a distributed device for implementing the method of the second aspect described above.
  • a capacity update device for a distributed device includes a processor and a memory.
  • the memory is configured to store a program for supporting a capacity device of the distributed device to update a capacity update method of the distributed device provided by the first aspect, and to store a capacity update method for implementing the distributed device provided by the first aspect
  • the processor is configured to execute a program stored in the memory.
  • the capacity update device of the distributed device may further include a communication bus for establishing a connection between the processor and the memory.
  • a capacity update device for a distributed device includes a processor and a memory.
  • the memory is configured to store a program for supporting a capacity device of the distributed device to update a capacity update method of the distributed device provided by the second aspect, and to store a capacity update method for implementing the distributed device provided by the second aspect
  • the processor is configured to execute a program stored in the memory.
  • the capacity update device of the distributed device may further include a communication bus for establishing a connection between the processor and the memory.
  • a computer storage medium for storing computer software instructions for use in a capacity update device of a distributed device of the third aspect and the fifth aspect, or for storing the third aspect or the fifth aspect described above
  • the program involved in the capacity update device of the distributed device is provided.
  • a computer storage medium for storing computer software instructions for use in a capacity update device of a distributed device of the fourth aspect and the sixth aspect, or for storing the fourth or sixth aspect described above
  • the program involved in the capacity update device of the distributed device is provided.
  • the technical solution provided by the embodiment of the present invention has the beneficial effects that, in the embodiment of the present invention, since the first traffic distribution table is sent to the first device, the number of CPUs in the second device is changed, that is, the first switch is changed first.
  • the number of CPUs in the second device is updated to the capacity of the second device, so that when the service packet is received, the service packet can be processed by the first device, and no traffic interruption occurs.
  • the first device can determine the corresponding CPU identifier of each state entry in the first traffic distribution table, the mapping between the state entry and the CPU identifier is formed, and at least one backup packet is generated based on the mapping relationship.
  • the CPU identifier and the at least one state table entry corresponding to the CPU identifier update the state table entry in each CPU included in the second device. Since the CPU identifier carried in each backup packet is determined from the first traffic distribution table, after the second device is switched to the device for processing the subsequent service packet, the second device follows the first traffic distribution. After the service packets are forwarded to different CPUs, the CPU does not store the status entries of the service flows to which the service packets belong, and prevents the CPU from discarding the service packets to cause traffic interruption. Case.
  • FIG. 1A is a structural diagram of a capacity update system of a distributed device according to an embodiment of the present invention.
  • FIG. 1B is a hardware architecture diagram of a firewall system according to an embodiment of the present invention.
  • FIG. 2 is a flowchart of a method for updating a capacity of a distributed device according to an embodiment of the present invention
  • 3A is a schematic structural diagram of a device for updating a capacity of a distributed device according to an embodiment of the present invention
  • 3B is a schematic structural diagram of a generating module according to an embodiment of the present invention.
  • FIG. 4A is a schematic structural diagram of a capacity update apparatus of a distributed device according to an embodiment of the present invention.
  • FIG. 4B is a schematic structural diagram of a switching module according to an embodiment of the present invention.
  • FIG. 1A is a structural diagram of a capacity update system of a distributed device according to an embodiment of the present invention.
  • a distributed device refers to a device for processing network traffic, such as a distributed firewall.
  • the system includes a first device 01 and a second device 02.
  • the first device 01 and the second device 02 can communicate through a wired network or a wireless network.
  • the first device 01 and the second device 02 are both distributed devices, and both the first device 01 and the second device 02 can process the service packets.
  • the second device 02 can serve as a backup device of the first device 01, so that when the first device 01 fails, the second device 02 continues to provide services instead of the first device 01.
  • the second device 02 is the backup device of the first device 01
  • the first device 01 is a device for processing the current service packet
  • the second device is not for processing the current service packet. device.
  • the first device 01 includes an MPU 011, an LPU 012, and at least one SPU 013, and each SPU 013 may include at least two CPUs. That is, the first device 01 includes at least two CPUs.
  • the MPU 011 may be connected to the LPU 012 through a communication bus, or may be connected to the at least one SPU 013 via a communication bus, and the communication bus may include a path for transmitting information between the components.
  • the first device 01 includes one SPU 013, and the SPU 013 includes three CPUs as an example for description.
  • the MPU is used to configure traffic and manage the CPU in each SPU. Specifically, when the system is initialized, the MPU may generate a traffic distribution table according to the CPU identifier in each SPU, and send the traffic distribution table to the LPU, where the traffic distribution table is used to instruct the LPU to offload the received service packets to different ones. On the CPU to achieve load balancing for each CPU. After that, the MPU can also monitor the CPU in each SPU to determine whether the number of CPUs changes. When it is determined that the number of CPUs changes, it is necessary to determine each CPU identifier after the change, and according to each changed The CPU ID regenerates the split table to update the split table to ensure the accuracy of the split table.
  • the MPU may assign an identification to each CPU in the order of the slots of each CPU.
  • the MPU may assign an identification to each CPU in the order of the slots of each CPU.
  • a CPU identification sequence may be generated according to the order of each CPU identifier, and the CPU identification sequence is filled into the blank distribution table to generate a traffic distribution table.
  • the flow distribution table carries a CPU identification sequence, and each CPU identifier in the CPU identification sequence indicates one CPU in the first device.
  • the split table is based on the ID of the CPU inserted in the device. If the length of the traffic distribution table is short, the same storage location in the traffic distribution table may correspond to at least two CPU identifiers. For example, the length of the traffic distribution table is 32, but the number of CPUs inserted is 64. In this way, a storage location in the traffic distribution table corresponds to two CPU identifiers, so that a collision occurs when the received service packet is shunted.
  • the traffic distribution table is used to offload service packets to different CPUs, when the length of the traffic distribution table is long, the CPU load may be unbalanced.
  • the length of the traffic distribution table is 32.
  • the number of CPUs inserted is 31, which causes the first CPU to be larger than other CPUs. Therefore, in order to avoid conflicts and achieve balanced load, it is generally possible to count the number of CPUs that can be inserted in each device. And determine the minimum common multiple of each CPU number as the length of the shunt table, and set it in the device fixedly in the device.
  • the length of the shunt table is set in the first device, and the length is fixed. Therefore, when the first device generates the traffic distribution table, the fixed-length blank traffic distribution table may be generated based on the configured traffic distribution table length, and then the generated CPU identification sequence is filled into the fixed-length blank traffic distribution table.
  • the length of the traffic distribution table is 1023.
  • the first device includes three CPUs, namely CPU1, CPU2, and CPU3.
  • the CPU ID assigned to CPU1 is ID1, the CPU ID assigned to CPU2 is ID2, and the CPU identifier assigned to CPU3.
  • ID1 the CPU ID assigned to CPU2
  • ID2 the CPU ID assigned to CPU3.
  • ID3 the CPU identifier assigned to CPU3.
  • each CPU identifier may be sequentially filled into the blank flow distribution table in the order of ID1, ID2, and ID3, thereby generating a flow distribution table as shown in FIG.
  • Table 1 for ease of understanding, a digital sequence is also schematically carried under the CPU identification sequence, and each digit in the digital sequence is used to indicate the storage of the CPU identifier in the corresponding location in the distribution table. position.
  • the sequence of numbers may not be carried in the offloading table, and the sequence of numbers is simply filled into the split table for ease of understanding.
  • ID1 ID2 ID3 ID1 ID2 ID3 ?? ID2 ID3 ID1 ID2 ID3 1 2 3 4 5 6 ; 1019 1020 1021 1022 1023
  • the LPU includes a plurality of input interfaces and a plurality of output interfaces, and the plurality of input interfaces are configured to receive service packets sent by other devices. After receiving the service packets, the LPU receives the received service packets according to the traffic distribution table generated by the MPU. Diverted to different CPUs. After the CPU processes the service packet, the processed service packet is sent to the next-level device through the multiple output interfaces.
  • the LPU performs the hashing operation on the address information carried in the service packet according to the split table generated by the MPU, and the LPU performs the hash operation on the address information carried in the service packet, and the operation result is obtained.
  • the CPU identifier is obtained from the storage location in the CPU identification sequence, and the service packet is sent to the CPU corresponding to the CPU identifier, so that the service packet is offloaded.
  • the address information carried in the service packet may be a combination of a source IP address and a destination IP address, or a source IP address. A combination of address, destination IP address, transport protocol, and destination port.
  • the combination of the source IP address and the destination IP address carried in the service packet is hashed. If the result of the operation is 6, the storage location can be obtained from the traffic distribution table shown in Table 1 above.
  • the CPU identifier, that is, the ID3, is sent to the CPU corresponding to the ID3, that is, the CPU3, so that the service packet can be offloaded.
  • the multiple input interfaces and the multiple output interfaces may be devices such as any transceiver for communicating with other devices or communication networks, such as Ethernet, Radio Access Network (RAN). ), Wireless Local Area Networks (WLAN), etc.
  • RAN Radio Access Network
  • WLAN Wireless Local Area Networks
  • the CPU in the SPU is configured to receive the service packet sent by the LPU through the offloading, and process the service packet.
  • the first device may also periodically back up the state table items stored in each CPU. That is, a backup message is generated based on the state table items stored in each CPU, and the backup message of each CPU is sent to the second device, so that each CPU in the second device can access the stored state table.
  • the item is updated.
  • Each state entry corresponds to a service flow, and each state entry stores a processing policy for processing a service packet on the corresponding service flow and flow information of the corresponding service flow.
  • the flow information may include a combination of a source IP address and a destination IP address, or a combination of a source IP address, a destination IP address, a transport protocol, and a destination port.
  • the processing of the service packet can be implemented not only by the CPU, but also by a microprocessor, an Application-Specific Integrated Circuit (ASIC), or one or A plurality of integrated circuits for controlling the execution of the program of the present application are implemented.
  • ASIC Application-Specific Integrated Circuit
  • the first device may include a memory, which may be a read-only memory (ROM), a random access memory (RAM), and a storable memory, after including each of the above components.
  • ROM read-only memory
  • RAM random access memory
  • STORable memory a storable memory
  • Other types of static storage devices for static information and instructions other types of dynamic storage devices that can store information and instructions, or electrically erasable programmable read-only memory (EEPROM), read-only Compact Disc Read-Only Memory (CD-ROM), or other optical disc storage, optical disc storage (including compact discs, laser discs, optical discs, digital versatile discs, Blu-ray discs, etc.), disk storage media, or other magnetic storage devices.
  • EEPROM electrically erasable programmable read-only memory
  • CD-ROM compact disc Read-Only Memory
  • optical disc storage including compact discs, laser discs, optical discs, digital versatile discs, Blu-ray discs, etc.
  • disk storage media or other magnetic storage devices.
  • the memory
  • the memory is used to store program code for executing the solution of the present application, and the CPU is configured to execute program code stored in the memory.
  • the capacity update method of the distributed device provided by the embodiment of FIG. 2 below can be implemented by using the CPU and the program code in the memory.
  • the second device is also a distributed device
  • the internal structure of the second device is the same as that of the first device in FIG. 1A. To avoid redundancy, the internal structure of the second device is not performed here. Detailed explanation.
  • the capacity update method of the distributed device may be applied to a firewall system.
  • 1B is a hardware architecture diagram of a firewall system according to an embodiment of the present invention.
  • the firewall system may include an MPU, an LPU, and at least one SPU.
  • the MPU may be separately connected to the at least one SPU through a management bus.
  • the MPU can be connected to the LPU through a monitoring bus.
  • the firewall system can also include a switch fabric, power system redundancy backup, and fan system redundancy backup.
  • FIG. 2 is a flowchart of a method for updating a capacity of a distributed device according to an embodiment of the present invention. The method is described by taking the interaction between the first device and the second device as an example.
  • the first device is a device for processing a current service packet
  • the second device is not a device for processing a current service packet.
  • the capacity update method of the distributed device may include the following steps:
  • Step 201 After determining that the number of CPUs included in the second device is changed, the second device generates a first traffic distribution table, where the first traffic distribution table carries a CPU identification sequence, and each CPU identifier in the CPU identification sequence respectively indicates the number of CPUs. A CPU included in the second device after the change.
  • the second device may also be a distributed device, and the second device may also include an MPU, an LPU, and at least one SPU, and each SPU includes at least two CPUs, that is, the second device includes at least two CPUs. Therefore, the MPU in the second device can monitor the CPU in the SPU to determine whether the number of CPUs included in the second device has changed. If the number of CPUs included in the second device changes, it is determined that the capacity of the second device has been updated. At this time, the MPU of the second device may change each CPU identifier included in the second device after the number of CPUs changes. Regenerate the split table and refer to the regenerated split table as the first split table.
  • the second device may further replace the second traffic distribution table stored in the LPU included in the first device into the first traffic distribution table to implement the update of the traffic distribution table.
  • the second offloading table is generated by the second device before each CPU identifier before the number of CPUs is changed.
  • the CPU identifier is allocated for the newly added CPU, and the first traffic distribution table is generated based on the CPU identifier corresponding to each CPU included in the second device after the CPU is added.
  • the MPU of the second device needs to allocate a CPU identifier to the newly added CPU.
  • the traffic distribution table is used to offload traffic packets to different CPUs. Therefore, after the number of CPUs changes, the second device needs to be offloaded to ensure that service packets can be accurately distributed to different CPUs.
  • the table is updated, that is, the MPU of the second device needs to regenerate the traffic distribution table based on the CPU identifier corresponding to each CPU included in the second device after the CPU is added, and the regenerated flow distribution table is referred to as the first traffic distribution table.
  • the CPUs are inserted into the slots in order, so each CPU can be assigned a CPU identifier according to the slot order of each CPU in the second device, and the first case is to increase the CPU. Therefore, the CPU ID assigned to the increased CPU can be directly increased.
  • the second device includes two CPUs, namely CPU1 and CPU2, and the CPU ID assigned to CPU1 is ID1, and CPU2 is added.
  • the assigned CPU ID is ID2. After adding the CPU, according to the slot order of the CPU, you can directly assign the CPU ID to ID3 for the newly added CPU.
  • the blank distribution table may be sequentially filled in the order of the CPU identifier corresponding to each CPU after the CPU is added, thereby obtaining the first flow distribution table.
  • the length of the traffic distribution table is 1023.
  • the first traffic distribution table can be as shown in Table 2 below.
  • ID1 ID2 ID3 ID1 ID2 ID3 ?? ID2 ID3 ID1 ID2 ID3 1 2 3 4 5 6 ; 1019 1020 1021 1022 1023
  • the CPU identifier is reassigned according to the CPU socket order for each CPU included in the second device after the CPU is reduced, based on each CPU included for the second device. Minute The assigned CPU identifier generates a first split table.
  • the CPU since the CPU is reduced in the second device, that is, the capacity of the second device is reduced, if the reduced CPU slot order is located in the middle of the inserted CPU, thus, after the reduction The CPU ID will be discontinuous, and subsequent service packets may be shunted. Therefore, in order to avoid these problems, CPUs can be reassigned according to the CPU socket order to reduce CPU after each CPU included in the second device.
  • the identifier regenerates the offloading table based on the CPU identifier reassigned for each CPU included in the second device, and refers to the regenerated shunt table as the first offloading table.
  • the CPU identifier may be assigned to each CPU according to the slot order of each CPU in the second device, and the second case is to reduce the CPU, so the CPU slot order may be reduced.
  • Each CPU after the CPU reassigns the CPU ID.
  • the second device includes three CPUs, namely CPU1, CPU2, and CPU3.
  • the CPU ID assigned to CPU1 is ID1
  • the CPU identifier assigned to CPU2 is assigned.
  • ID3 the CPU ID assigned to CPU3
  • the reduced CPU is CPU2.
  • the CPU ID reassigned to CPU1 is ID1
  • the CPU is reassigned to CPU3.
  • the ID is ID2.
  • the blank shunt table may be sequentially filled in the order of reducing the CPU identifier corresponding to each CPU after the CPU, thereby obtaining the first shunt table.
  • the length of the traffic distribution table is 1023.
  • the first traffic distribution table can be as shown in Table 3 below.
  • Step 202 The second device sends the first flow distribution table to the first device.
  • the second device Since the first offloading table is generated based on each CPU identifier included in the second device after the number of CPUs changes, and the second device is a backup device of the first device, in order to facilitate subsequent storage in the first device
  • the state table entry is backed up to the second device, and the second device can send the first offloading table to the first device.
  • Step 203 The first device receives the first traffic distribution table sent by the second device, and determines that each state entry in the first device is in the corresponding CPU identifier in the first traffic distribution table, thereby forming a relationship between the state table entry and the CPU identifier. Mapping relationship.
  • the first device may receive the first traffic distribution table sent by the second device, and store the first traffic distribution table in the LPU of the first device, for any state table entry stored by each CPU included in the first device,
  • the LPU of the first device may perform a hash operation on the flow information stored in the state table entry to obtain an operation result, where the operation result indicates that the CPU identifier corresponding to the state table entry is in a storage location in the CPU identification sequence of the first traffic distribution table.
  • the CPU identifier stored in the storage location is obtained from the first traffic distribution table, and the obtained CPU identifier is determined as the CPU identifier corresponding to the state table entry.
  • a state table entry is selected from at least one state table entry included in the first device, and the following process is performed on the selected state table entry until each state entry included in the first device is processed:
  • the CPU identifier determines that the obtained CPU identifier is the CPU identifier corresponding to the selected state table entry.
  • the first device After receiving the first traffic distribution table sent by the second device, the first device performs hash operation on the flow information stored in the state table entry for any state table item stored by each CPU included in the first device. If the value obtained by the hash operation is 5, the storage location of the CPU identifier corresponding to the state entry in the first traffic distribution table is determined to be 5, and the first device may be based on the storage location 5, The CPU ID corresponding to the status entry is obtained in a traffic distribution table. Assuming that the first traffic distribution table is the foregoing table 2, it may be determined that the CPU identifier corresponding to the state entry is ID2.
  • Each state entry corresponds to a service flow, and each state entry stores a processing policy for processing a service packet on the corresponding service flow and flow information of the corresponding service flow.
  • the flow information may include a combination of a source IP address and a destination IP address of the service flow, or a combination of a source IP address, a destination IP address, a transport protocol, and a destination port.
  • the flow information may also be other information, for example, may include a combination of a source IP address, a destination IP address, and a transport protocol of the service flow, or a combination of a source IP address, a destination IP address, and a target port. Wait.
  • the CPU of the first device stores a status table entry including a processing policy and a flow information of the service packet.
  • the status entry may include not only a processing policy, but also a network address translation (NAT) and a security architecture for IP network (IPSEC) of the service flow corresponding to the status entry. information.
  • the traffic distribution table of the second device since the capacity of the second device is updated first, the traffic distribution table of the second device has changed, so that the state table entry can be accurately backed up to the CPU of the second device.
  • the CPU identifier corresponding to each state table entry is determined from the first traffic distribution table based on the state table entries stored by each CPU included in the first device.
  • the state device since the state device is backed up according to the updated traffic distribution table, that is, the first traffic distribution table, after the second device performs the capacity update, the first device is not needed.
  • the number of CPUs and the CPU ID of the second device are strictly consistent, so that the flexibility of capacity update can be improved.
  • Step 204 The first device generates at least one backup packet according to the mapping relationship, and each backup packet in the at least one backup packet carries a CPU identifier and at least one state table entry corresponding to the CPU identifier.
  • the state table items stored in the first device may be divided into at least one group according to the mapping relationship.
  • Each group of status entries includes at least one status entry, and the CPU IDs of the same group of status entries are the same.
  • a group of backup packets corresponding to each group of status entries is generated, and at least one backup packet is obtained, and the header of each backup packet in the at least one backup packet carries the status in the corresponding group.
  • the CPU ID corresponding to the entry, and each backup packet includes at least one state table entry included in the corresponding group.
  • the CPU identifier corresponding to the at least one state state entry and the at least one state state entry may be generated.
  • At least one backup packet so that it is not necessary to separately generate a backup packet for each state table entry and the CPU identifier corresponding to the state table entry. That is, the embodiment of the present invention integrates the state table items that are backed up to the same CPU into one backup message, so that the number of backup messages can be reduced, thereby improving the backup efficiency of the status entries.
  • the first device may first encapsulate the at least one set of state entries to the at least one backup packet when the first device generates the at least one backup packet based on the CPU identifier corresponding to the at least one set of the state entry and the at least one set of the statelist.
  • the CPU identifier corresponding to each group of status entries is added to the header of the at least one packet, so that at least one backup packet is obtained.
  • Step 205 The first device sends the at least one backup message to the second device.
  • the second device can serve as the backup device of the first device, it is required to determine whether the other device is faulty in real time between the first device and the second device.
  • the heartbeat keep-alive method is mainly used to determine whether the other device is faulty, that is, the first device and the second device can pass the heartbeat interface on the LPU. Send heartbeat packets to each other to determine if the other device is faulty.
  • the LPU includes not only a plurality of input interfaces and a plurality of output interfaces but also a heartbeat interface.
  • the first device may pass the at least one backup packet to the second device.
  • the heartbeat interface on the LPU of the device is sent to the second device.
  • Step 206 The second device receives at least one backup message sent by the first device, and according to a CPU identifier carried in each backup message in the at least one backup message and at least one status entry corresponding to the CPU identifier, The status table stored in the CPU indicated by the CPU identifier carried in each backup packet in the second device is updated.
  • the second device may determine that the stored state table item needs to be updated, and the first device has stored the CPU in each CPU.
  • the status entries are all sent in the at least one backup message.
  • the second device may obtain the CPU identifier carried in each backup packet, and then, according to the CPU identifier carried in each backup packet, at least one state table corresponding to the CPU identifier carried in each backup packet. The entry is stored in the CPU indicated by the CPU identifier in the second device.
  • the at least one backup message is received by the heartbeat interface on the LPU of the second device, that is, the at least one backup message is received by the LPU.
  • the backup packet carries the CPU identifier. Therefore, after receiving the at least one backup packet, the LPU can directly send the backup packet to the corresponding CPU according to the CPU identifier carried in each backup packet.
  • the status table item stored by each CPU included in the second device is updated without offloading the at least one backup message.
  • the second device may replace the previously stored state entry with the state entry in the backup packet to implement the second device. Update of the status table entry stored by the CPU.
  • the second device may also age the state table stored in each CPU, so that when the at least one backup message is received, the device may directly
  • the status table entries in each backup message are stored in the corresponding CPUs to implement the update of the status table entries stored by each CPU in the second device.
  • Step 207 After the first device sends the at least one backup message to the second device, the device sends a backup completion notification message to the second device, and switches the first device to a device that does not process the subsequent service packet.
  • the backup completion notification message is used to notify the second device that the status table item stored in each CPU included in the first device has been backed up, so that the second device can receive the stored status based on the received at least one backup message. After the entry is updated, the second device is switched to a device for processing subsequent service packets, thereby avoiding the problem of traffic interruption.
  • the backup completion notification message may also be sent to the second device through the heartbeat interface, and may also be sent to the second device through other interfaces.
  • Step 208 The second device receives the backup completion notification message sent by the first device, and switches the second device to a device for processing the subsequent service packet.
  • the second device receives the backup completion notification message sent by the first device, and sets the priority of the second device to the second priority, the second priority is higher than the third priority, and the third priority is higher than the first priority.
  • the first priority is the priority of the second device before the number of CPUs changes
  • the third priority is the current priority of the first device.
  • negotiate with the first device thereby switching the second device to a device for processing the subsequent service packet.
  • Which of the first device and the second device is the device that processes the service packet, and which device serves as the backup device of the device, which is negotiated by the priority between the first device and the second device.
  • the device that processes the service packet needs to be switched from the first device to the second device.
  • the priority of the second device needs to be updated, that is, the priority of the second device is set to the second priority, and the second priority is higher than the first priority, where the first priority is before the number of CPUs changes. The priority of the second device.
  • the second device since the device has a higher priority in the negotiation process, which device can be used as a device for processing the service packet, after the priority of the second device is set to the second priority, the second device needs to be ensured.
  • the priority is higher than the current priority of the first device, that is, the third priority.
  • the second device may negotiate with the first device to switch the device that processes the service packet from the first device to the second device.
  • the second device may directly set the priority of the second device to the second priority, and based on the priority and the first of the second device.
  • the current priority of the device is negotiated with the first device, so that the second device is switched to a device for processing subsequent service packets.
  • the second device may first set the priority of the second device to the second priority.
  • the first device is negotiated based on the priority of the second device and the current priority of the first device, so that the second device is switched to be used for processing the subsequent service packet. device.
  • the second device after receiving the backup completion notification message sent by the first device, the second device sets the priority of the second device to the second priority when receiving the switching instruction triggered by the user, and is based on the second device.
  • the priority of the first device and the current priority of the first device are negotiated with the first device, so that the second device is switched to a device for processing subsequent service packets.
  • the embodiment of the present invention does not specifically limit the timing of the negotiation.
  • the first device and the second device may lower the respective priorities, for example, the priority of the first device is set to the first priority, and the priority of the second device is set to the third priority. level. This will facilitate the next master-slave switchover.
  • the first device may also perform capacity update according to the foregoing method.
  • the method for performing the capacity update of the first device may be the same as the method described above. Therefore, the method for performing capacity update on the first device in the embodiment of the present invention is not described in detail.
  • the second device after the first offloading table changes the number of CPUs included in the second device, the second device generates the CPU identifier based on the changed, that is, first, the number of CPUs in the second device is changed.
  • the capacity of the second device is updated, so that when the service packet is received, the service packet can be processed by the first device, and no traffic interruption occurs.
  • the first device can determine the corresponding CPU identifier of each state entry in the first traffic distribution table, the mapping between the state entry and the CPU identifier is formed, and at least one backup packet is generated based on the mapping relationship.
  • the status table item in each CPU included in the second device is updated by using one CPU identifier carried in each backup packet and at least one state table entry corresponding to the CPU identifier in the at least one backup packet. Since the CPU identifier carried in each backup packet is determined from the first traffic distribution table, after the device that processes the service packet is switched from the first device to the second device, the second device follows the first traffic distribution. After the service packets are forwarded to different CPUs, the CPU does not store the status entries of the service flows to which the service packets belong, and prevents the CPU from discarding the service packets to cause traffic interruption. The situation, thus achieving smooth expansion or shrinkage.
  • FIG. 3A is a schematic structural diagram of a device for updating a capacity of a distributed device according to an embodiment of the present invention.
  • the device may be implemented as part or all of the first device by software, hardware, or a combination of the two.
  • the first device may be a figure.
  • the first device is a device for processing a current service packet, where the first device includes at least Two CPUs, each of the at least two CPUs corresponding to a state table entry of at least one service flow.
  • the apparatus includes a receiving module 301, a determining module 302, a generating module 303, a sending module 304, and a switching module 305.
  • the receiving module 301 is configured to perform an operation of receiving the first flow distribution table sent by the second device in step 203 in the embodiment of FIG. 2;
  • the determining module 302 is configured to perform, in step 203 in the embodiment of FIG. 2, determining a CPU identifier corresponding to each state entry in the first device in the first traffic distribution table, thereby forming a mapping between the state table entry and the CPU identifier. Operation of the relationship;
  • a generating module 303 configured to perform step 204 in the embodiment of FIG. 2;
  • the sending module 304 is configured to perform step 205 in the embodiment of FIG. 2;
  • the sending module 304 is further configured to send a backup completion notification message to the second device in step 207 of FIG.
  • the switching module 305 is further configured to perform, in step 207 of FIG. 2, the second device is switched to a device for processing a subsequent service message.
  • the determining module 302 is specifically configured to:
  • the flow information includes a combination of a source IP address and a destination IP address of the service flow corresponding to the selected state table entry, or a combination of a source IP address, a destination IP address, a transmission protocol, and a destination port.
  • the generating module 304 includes:
  • the dividing unit 3041 is configured to divide the state table entries stored in the first device into at least one group according to the mapping relationship, where each group of state table entries includes at least one state table entry, and the CPU identifier corresponding to the same group state table entry the same;
  • the generating unit 3042 is configured to generate, according to the group, a backup packet corresponding to each group of state entries, to obtain at least one backup packet, and a packet header of each backup packet in the at least one backup packet.
  • the CPU identifier corresponding to the status entry in the corresponding group is included, and each backup packet includes at least one status entry included in the corresponding group.
  • the first traffic distribution table is sent to the first device, where the number of CPUs in the second device is changed, that is, the number of CPUs in the second device is changed to update the capacity of the second device, so that the service is received.
  • the service packet can be processed by the first device, and no traffic interruption occurs.
  • the first device can determine the corresponding CPU identifier of each state entry in the first traffic distribution table, the mapping between the state entry and the CPU identifier is formed, and at least one backup packet is generated based on the mapping relationship.
  • the status table item in each CPU included in the second device is updated by using one CPU identifier carried in each backup packet and at least one state table entry corresponding to the CPU identifier in the at least one backup packet.
  • the second device Since the CPU identifier carried in each backup packet is determined from the first traffic distribution table, after the second device is switched to the device for processing the subsequent service packet, the second device follows the first traffic distribution. After the service packets are forwarded to different CPUs, the CPU does not store the status entries of the service flows to which the service packets belong, and prevents the CPU from discarding the service packets to cause traffic interruption. Case.
  • FIG. 4A is a schematic structural diagram of a device for updating a capacity of a distributed device according to an embodiment of the present invention.
  • the device may be implemented as part or all of the second device by software, hardware, or a combination of the two.
  • the second device may be a figure.
  • the second device is not a device that processes the current service packet, and the second device includes at least two CPUs.
  • the apparatus includes a generating module 401, a transmitting module 402, a receiving module 403, an updating module 404, and a switching module 405.
  • a generating module 401 configured to perform step 201 in the embodiment of FIG. 2;
  • the sending module 402 is configured to perform step 202 in the embodiment of FIG. 2;
  • the receiving module 403 is configured to perform the operation of receiving the at least one backup message sent by the first device in step 206 in the embodiment of FIG. 2, and receiving the backup completion notification message sent by the first device in step 208;
  • the update module 404 is configured to perform, according to step 206 in the embodiment of FIG. 2, a CPU identifier that is carried in each backup packet in the at least one backup packet and at least one state entry corresponding to the CPU identifier, and update the second The operation of the state table entry stored in the CPU indicated by the CPU identifier carried in each backup packet in the device;
  • the switching module 405 is configured to perform the step 206 of the embodiment of FIG. 2 after the update is completed, and after receiving the backup completion notification message in step 208, the second device is switched to be used for processing subsequent service packets. device.
  • the switching module 405 includes:
  • the updating unit 4051 is configured to set a priority of the second device to a second priority, a second priority is higher than a third priority, and a third priority is higher than the first priority, where the first priority is the number of CPUs.
  • the priority of the second device before the change occurs, and the third priority is the current priority of the first device;
  • the negotiating unit 4052 is configured to negotiate with the first device according to the priority of the second device and the current priority of the first device, so as to switch the second device into a device for processing the subsequent service packet.
  • the generating module 401 is specifically configured to:
  • the first split table is generated based on the CPU identifier corresponding to each CPU included in the second device after the CPU is added.
  • the generating module 401 is specifically configured to:
  • a first offload table is generated based on the CPU identifier reassigned for each CPU included in the second device.
  • the first device generates at least one backup packet according to the first traffic distribution table. Therefore, when the second device receives the at least one backup packet, the second device may The status table item stored by the CPU is updated, and after receiving the backup completion notification message sent by the first device, the device that processes the service packet is switched from the first device to the second device, so that the second device receives When a service packet is sent to the CPU, the service packet is not sent to the CPU. The CPU does not store the service packet. The situation that caused the traffic to be interrupted.
  • the capacity update device of the distributed device provided by the foregoing embodiment is only illustrated by the division of each functional module in the capacity update. In an actual application, the function may be assigned different functions according to requirements. The module is completed, that is, the internal structure of the device is divided into different functional modules to complete all or part of the functions described above.
  • the capacity update device of the distributed device provided by the foregoing embodiment is the same as the embodiment of the method for updating the capacity of the distributed device. For the specific implementation process, refer to the method embodiment, and details are not described herein again.
  • a person skilled in the art may understand that all or part of the steps of implementing the above embodiments may be completed by hardware, or may be instructed by a program to execute related hardware, and the program may be stored in a computer readable storage medium.
  • the storage medium mentioned may be a read only memory, a magnetic disk or an optical disk or the like.
  • the above embodiments it may be implemented in whole or in part by software, hardware, firmware, or any combination thereof.
  • software it may be implemented in whole or in part in the form of a computer program product.
  • the computer program product includes one or more computer instructions.
  • the computer program instructions When the computer program instructions are loaded and executed on a computer, the processes or functions described in accordance with embodiments of the present invention are generated in whole or in part.
  • the computer can be a general purpose computer, a special purpose computer, a computer network, or other programmable device.
  • the computer instructions can be stored in a computer readable storage medium or transferred from one computer readable storage medium to another computer readable storage medium, for example, the computer instructions can be from a website site, computer, server or data center Transfer to another website site, computer, server, or data center by wire (eg, coaxial cable, light, Digital Subscriber Line (DSL)) or infinite (eg, infrared, wireless, microwave, etc.).
  • the computer readable storage medium can be any available media that can be accessed by a computer or a data storage device such as a server, data center, or the like that includes one or more available media.
  • the usable medium may be a magnetic medium (eg, a floppy disk, a hard disk, a magnetic tape), an optical medium (eg, a Digital Video Disk (DVD)), or a semiconductor medium (such as a Solid State Disk (SSD)). )Wait.
  • a magnetic medium eg, a floppy disk, a hard disk, a magnetic tape
  • an optical medium eg, a Digital Video Disk (DVD)
  • DVD Digital Video Disk
  • SSD Solid State Disk

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Health & Medical Sciences (AREA)
  • Cardiology (AREA)
  • General Health & Medical Sciences (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Hardware Redundancy (AREA)

Abstract

本申请公开了一种分布式设备的容量更新方法及装置，属于通信技术领域。该方法包括：接收第二设备发送的第一分流表，第一分流表携带一个CPU标识序列，CPU标识序列中的每个CPU标识分别指示第二设备中的一个CPU；从第一分流表中确定第一设备中的每个状态表项对应的CPU标识，从而形成状态表项与CPU标识之间的映射关系；根据该映射关系生成至少一个备份报文，并指示第二设备更新其包括的每个CPU的状态表项之后，切换至第二设备来处理业务报文。由于备份报文是按照第一分流表生成的，因此切换至第二设备来处理业务报文之后，第二设备也是按照第一分流表进行报文分流，从而避免业务报文被丢弃以导致流量中断的情况。

Description

分布式设备的容量更新方法及装置
本申请要求于2017年3月9日提交中国专利局、申请号为201710138783.3、申请名称为“分布式设备的容量更新方法及装置”的中国专利申请的优先权，其全部内容通过引用结合在本申请中。
技术领域
本申请涉及通信技术领域，特别涉及一种分布式设备的容量更新方法及装置。
背景技术
随着网络的升级和扩容，传统的盒式防火墙已经很难满足大容量、高性能、可扩展的需求，以分布式防火墙为例的分布式设备应运而生。分布式设备通常包括主控板(Management Process Unit，MPU)、接口板(Line-card Process Unit，LPU)和至少一个业务板(Service Process Unit，SPU)，且每个SPU可以包括至少两个中央处理器(Central Processing Unit，CPU)。其中，MPU用于配置业务和管理每个SPU中的CPU，LPU用于将接收到的业务报文分流到不同的CPU上，SPU中的CPU用于对业务报文进行处理。由于该至少一个SPU中的每个CPU都用于处理业务报文，因此，与传统的盒式设备相比，分布式设备的数据处理效率显著提升。然而，随着数据量的不断增涨，而分布式设备中每个SPU的处理能力是有限的，为了减小分布式设备的数据处理压力，往往需要增加分布式设备中SPU的数量。改变现有分布式设备中SPU的数量的也被称为容量更新。
在实际应用中，为了保证分布式设备提供服务时的稳定性，通常可以为该分布式设备配置备用设备，以便在该分布式设备发生故障时由该备用设备代替该分布式设备继续提供服务。为了便于描述，将该分布式设备称为第一设备，将该分布式设备的备用设备称为第二设备，其中，该备用设备通常也为分布式设备。相关技术中，当第一设备进行容量更新时，第一设备的MPU可以根据CPU数量发生变化后的每个CPU标识重新生成分流表，并将重新生成的分流表发送给LPU并由LPU替换之前存储的分流表，从而实现第一设备的容量更新。同样，第二设备也可以按照上述方法进行容量更新。
在第一设备进行容量更新之后，当第一设备的LPU接收到业务报文时，可以对该业务报文携带的地址信息进行哈希运算，得到用于处理该业务报文的CPU的标识在分流表中的位置。第一设备从存储的分流表中获取在该位置上存储的CPU标识，并将该业务报文转发至该CPU标识对应的CPU，以便于该CPU通过存储的状态表项对该业务报文进行处理。其中，每个状态表项分别对应一条业务流，且每个状态表项中存储有对对应业务流上的业务报文进行处理的处理策略和对应业务流的流信息。该流信息可以包括源互联网协议(Internet Protocol，IP)地址和目的IP地址的组合，或者源IP地址、目的IP地址、传输协议和目的端口的组合。为了便于第一设备在出现故障之后，第二设备可以顺利地代替第一设备继续对业务报文进行处理，第一设备还可以周期性地将每个CPU中存储的状态表项备份到第二设备。相关技术为了提高备份的效率，需要保证第一设备和第二设备中的CPU数量和CPU标识严格一致，之后，第一设备可以生成备份报文，备份报文中携带第一 设备中的状态表项。第一设备将备份报文发送至第二设备中的LPU，第二设备的LPU接收到备份报文时，将备份报文发送给第二设备包括的至少一个SPU中的CPU，以便于第二设备中的每个CPU对存储的状态表项进行更新。
然而，当第一设备进行容量更新之后，第一设备中CPU的数量会发生改变，从而导致第一设备的MPU基于更新后的每个CPU标识生成的分流表与之前存储的分流表不同。进而在第一设备将后续接收到的业务报文发送给一个CPU之后，该CPU可能并非在容量更新前处理该业务报文所属业务流的CPU，因而未存储该业务报文所属业务流的状态表项，此时该CPU会将该业务报文丢弃，进而导致流量中断。
发明内容
为了解决在第一设备进行容量更新之后出现流量中断的问题，本发明实施例提供了一种分布式设备的容量更新方法及装置。所述技术方案如下：
第一方面，提供了一种分布式设备的容量更新方法，由第一设备执行，所述第一设备为用于对当前业务报文进行处理的设备，所述第一设备包括至少两个CPU，所述至少两个CPU中的每个CPU对应保存至少一个业务流的状态表项，所述方法包括：
接收第二设备发送的第一分流表，所述第一分流表携带一个CPU标识序列，所述CPU标识序列中的每个CPU标识分别指示所述第二设备中的一个CPU，所述第一分流表为所述第二设备包括的CPU的数量发生变化后向所述第一设备发送的；
确定所述第一设备中的每个状态表项在所述第一分流表中对应的CPU标识，从而形成状态表项与CPU标识之间的映射关系；
根据所述映射关系，生成至少一个备份报文，所述至少一个备份报文中的每个备份报文携带一个CPU标识以及与所述CPU标识对应的至少一个状态表项；
将所述至少一个备份报文发送给所述第二设备，以指示所述第二设备根据所述每个备份报文携带的一个CPU标识以及与所述CPU标识对应的至少一个状态表项，更新所述第二设备中存储的状态表项；
将所述至少一个备份报文发送给所述第二设备之后，向所述第二设备发送备份完成通知消息，并将所述第一设备切换为暂不对后续业务报文进行处理的设备，所述备份完成通知消息用于指示所述第二设备对存储的状态表项更新之后，将所述第二设备切换为用于对后续业务报文进行处理的设备。
由于第一分流表为第二设备中的CPU数量发生变化之后，第二设备基于变化后的CPU标识生成得到，也即是，先改变第二设备中的CPU数量以对第二设备的容量进行更新，这样在接收到业务报文时，可以通过第一设备对业务报文进行处理，不会出现流量中断的情况。
另外，第一设备可以确定存储的每个状态表项在第一分流表中对应的CPU标识，从而形成状态表项与CPU标识之间的映射关系，并基于该映射关系生成至少一个备份报文，并通过该至少一个备份报文中每个备份报文携带的一个CPU标识和该CPU标识对应的至少一个状态表项，对第二设备包括的每个CPU中的状态表项进行更新。由于每个备份报文中携带的CPU标识是从第一分流表中确定的，因此，将对业务报文进行处理的设备从第一设备切换到第二设备之后，第二设备按照第一分流表将后续接收到的业务报文分流到不同的 CPU之后，就不会出现CPU上未存储该业务报文所属业务流的状态表项的情况，进而避免CPU将业务报文丢弃以导致流量中断的情况。
需要说明的是，每个状态表项分别对应一条业务流，且每个状态表项中存储有对对应业务流上的业务报文进行处理的处理策略和对应业务流的流信息，该流信息可以包括源IP地址和目的IP地址的组合，或者源IP地址、目的IP地址、传输协议和目的端口的组合。
当然，实际应用中，该流信息还可以为其他信息，比如，可以包括该业务流的源IP地址、目的IP地址和传输协议的组合，或者源IP地址、目的IP地址和目标端口的组合等等。
可选地，所述确定所述第一设备中的每个状态表项在所述第一分流表中对应的CPU标识，包括：
从所述第一设备包含的至少一个状态表项中选择出一个状态表项，对选择出的状态表项执行以下处理，直到处理完所述第一设备包含的每个状态表项为止：
对选择出的状态表项中的流信息进行哈希运算得到运算结果，所述运算结果指示所述CPU标识序列中的一个存储位置；
从所述CPU标识序列中的所述存储位置中获取CPU标识，确定获取的所述CPU标识为所述选择出的状态表项对应的CPU标识。
由于第一分流表是基于第二设备变化后的CPU标识生成得到，因此，通过对第一设备存储的每个状态表项中存储的流信息进行哈希运算，从而可以从第一分流表中准确地确定每个状态表项对应的CPU标识，进而为后续第二设备对业务报文进行处理提供可靠且准确的保障。
可选地，所述根据所述映射关系，生成至少一个备份报文，包括：
根据所述映射关系，将所述第一设备中存储的状态表项划分为至少一组，每组状态表项中包括至少一个状态表项，且同一组状态表项对应的CPU标识相同；
以组为单位，生成每组状态表项对应的一个备份报文，从而得到至少一个备份报文，所述至少一个备份报文中的每个备份报文的报文头部携带对应组中的状态表项对应的CPU标识、且所述每个备份报文包括对应组中包括的至少一个状态表项。
由于状态表项对应的CPU标识相同时，可以确定该状态表项会被备份到第二设备中的同一CPU上，因此，基于每个状态表项对应的CPU标识，将备份后得到的状态表项划分为至少一组之后，可以将该至少一组状态表项和该至少一组状态表项对应的CPU标识生成至少一个备份报文，这样就无需将每个状态表项和该状态表项对应的CPU标识单独生成一个备份报文，也即是，本发明实施例将备份到同一CPU的状态表项集成到一个备份报文中，这样可以减少备份报文的数量，从而可以提高状态表项的备份效率。
其中，在第一设备基于至少一组状态表项和该至少一组状态表项对应的CPU标识，生成至少一个备份报文时，第一设备可以先将该至少一组状态表项分别封装到至少一个报文中，然后在该至少一个报文的头部分别添加上各组状态表项对应的CPU标识，从而得到至少一个备份报文。
第二方面，提供了一种分布式设备的容量更新方法，由第二设备执行，所述第二设备不是对当前业务报文进行处理的设备，所述第二设备包括至少两个CPU，所述方法包括：
确定所述第二设备包括的CPU的数量发生变化后，生成第一分流表，所述第一分流表携带一个CPU标识序列，所述CPU标识序列中的每个CPU标识分别指示CPU的数量发生变 化后所述第二设备包括的一个CPU；
向第一设备发送所述第一分流表；
接收所述第一设备发送的至少一个备份报文，所述至少一个备份报文中的每个备份报文携带一个CPU标识以及与所述CPU标识对应的至少一个状态表项，所述每个备份报文携带的CPU标识为所述第一设备从所述第一分流表中确定的；
根据所述至少一个备份报文中的每个备份报文携带的一个CPU标识以及与所述CPU标识对应的至少一个状态表项，更新所述第二设备中所述每个备份报文携带的CPU标识所指示的CPU中存储的状态表项；
接收所述第一设备发送的备份完成通知消息，将所述第二设备切换为用于对后续业务报文进行处理的设备。
由于第二设备也可以为分布式设备，第二设备中也可以包括MPU、LPU和至少一个SPU，且每个SPU中包括至少两个CPU，因此，第二设备中的MPU可以对SPU中的CPU进行监测，以确定第二设备包括的CPU数量是否发生变化。
需要说明的是，在第二设备接收到该至少一个备份报文时，第二设备可以对包括的每个CPU存储的状态表项进行更新，之后，将对业务报文进行处理的设备从第一设备切换到第二设备，这样，第二设备接收到业务报文时，按照第一分流表将业务报文分流到不同的CPU之后，就不会出现某个CPU上未存储该业务报文的状态表项的情况，进而避免CPU将业务报文丢弃以导致流量中断的情况。
可选地，所述将所述第二设备切换为用于对后续业务报文进行处理的设备，包括：
将所述第二设备的优先级设置为第二优先级，所述第二优先级高于第三优先级，所述第三优先级高于第一优先级，所述第一优先级为CPU的数量发生变化之前所述第二设备的优先级，所述第三优先级为所述第一设备当前的优先级；
基于所述第二设备的优先级和所述第一设备当前的优先级，与所述第一设备进行协商，从而将所述第二设备切换为用于对后续业务报文进行处理的设备。
由于第一设备和第二设备中，哪个设备作为对业务报文进行处理的设备，哪个设备作为哪个设备的备用设备，这些都是通过第一设备和第二设备之间的优先级进行协商得到，而且在第二设备包括的每个CPU存储的状态表项更新完成之后，为了避免流量中断的问题，此时需要将对业务报文进行处理的设备从第一设备切换至第二设备，因此，需要将第二设备的优先级设置为第二优先级。
可选地，所述确定所述第二设备包括的CPU的数量发生变化后，生成第一分流表，包括：
如果所述第二设备包括的CPU的数量增加，则为新增的CPU分配CPU标识；
基于增加CPU之后所述第二设备包括的每个CPU对应的CPU标识，生成第一分流表。
由于第二设备中增加了CPU，也即是，对第二设备的容量进行了扩容，因此，第二设备的MPU需要为新增的CPU分配CPU标识。由于分流表是用于将业务报文分流到不同的CPU上，因此，在CPU数量发生变化之后，为了保证后续将业务报文能够准确地分流到不同的CPU上，第二设备需要对分流表进行更新，即第二设备的MPU需要基于增加CPU之后第二设备包括的每个CPU对应的CPU标识，重新生成分流表，并将重新生成的分流表称为第一分流表。
可选地，所述确定所述第二设备包括的CPU的数量发生变化，生成第一分流表，包括：
如果所述第二设备包括的CPU的数量减少，则按照CPU插槽顺序为减少CPU之后第二设备包括的每个CPU重新分配CPU标识；
基于为第二设备包括的每个CPU重新分配的CPU标识，生成第一分流表。
由于第二设备中减少了CPU，也即是，对第二设备的容量进行了缩容，如果减少的CPU的插槽顺序位于已插入的CPU中间，这样，减少后的CPU标识就会不连续，而且后续将业务报文进行分流时可能会出现错误，因此，为了避免这些问题，可以按照CPU插槽顺序为减少CPU之后第二设备包括的每个CPU重新分配CPU标识，进而基于为每个CPU重新分配的CPU标识，重新生成分流表，并将重新生成的分流表称为第一分流表。
第三方面，提供了一种分布式设备的容量更新装置所述装置用于实现上述第一方面所述的方法。
第四方面，提供了一种分布式设备的容量更新装置所述装置用于实现上述第二方面所述的方法。
第五方面，提供了一种分布式设备的容量更新装置，所述分布式设备的容量更新装置的结构中包括处理器和存储器。所述存储器用于存储支持所述分布式设备的容量装置更新执行上述第一方面提供的分布式设备的容量更新方法的程序，以及存储用于实现第一方面提供的分布式设备的容量更新方法所涉及的数据。所述处理器被配置为用于执行所述存储器中存储的程序。所述分布式设备的容量更新装置还可以包括通信总线，该通信总线用于在处理器与存储器之间建立连接。
第六方面，提供了一种分布式设备的容量更新装置，所述分布式设备的容量更新装置的结构中包括处理器和存储器。所述存储器用于存储支持所述分布式设备的容量装置更新执行上述第二方面提供的分布式设备的容量更新方法的程序，以及存储用于实现第二方面提供的分布式设备的容量更新方法所涉及的数据。所述处理器被配置为用于执行所述存储器中存储的程序。所述分布式设备的容量更新装置还可以包括通信总线，该通信总线用于在处理器与存储器之间建立连接。
第七方面，提供了一种计算机存储介质，用于储存上述第三方面和第五方面的分布式设备的容量更新装置所用的计算机软件指令，或存储用于执行上述第三方面或第五方面的分布式设备的容量更新装置所涉及的程序。
第八方面，提供了一种计算机存储介质，用于储存上述第四方面和第六方面的分布式设备的容量更新装置所用的计算机软件指令，或存储用于执行上述第四方面或第六方面的分布式设备的容量更新装置所涉及的程序。
上述第三方面、第五方面和第七方面所获得的技术效果与第一方面中对应的技术手段获得的技术效果近似，在这里不再赘述。
上述第四方面、第六方面和第八方面所获得的技术效果与第二方面中对应的技术手段获得的技术效果近似，在这里不再赘述。
本发明实施例提供的技术方案带来的有益效果是：在本发明实施例中，由于第一分流表为第二设备中的CPU数量发生变化发送给第一设备的，也即是，先改变第二设备中的CPU数量以对第二设备的容量进行更新，这样在接收到业务报文时，可以通过第一设备对业务报文进行处理，不会出现流量中断的情况。之后，第一设备可以确定存储的每个状态表项在第一分流表中对应的CPU标识，从而形成状态表项与CPU标识之间的映射关系，并基于该映射关系生成至少一个备份报文，并通过该至少一个备份报文中每个备份报文携带的一 个CPU标识和该CPU标识对应的至少一个状态表项，对第二设备包括的每个CPU中的状态表项进行更新。由于每个备份报文中携带的CPU标识是从第一分流表中确定的，因此，将第二设备切换为用于对后续业务报文进行处理的设备备之后，第二设备按照第一分流表将后续接收到的业务报文分流到不同的CPU之后，就不会出现CPU上未存储该业务报文所属业务流的状态表项的情况，进而避免CPU将业务报文丢弃以导致流量中断的情况。
附图说明
图1A是本发明实施例提供的一种分布式设备的容量更新系统架构图；
图1B是本发明实施例提供的一种防火墙系统的硬件架构图；
图2是本发明实施例提供的一种分布式设备的容量更新方法流程图；
图3A是本发明实施例提供的一种分布式设备的容量更新装置结构示意图；
图3B是本发明实施例提供的一种生成模块的结构示意图；
图4A是本发明实施例提供的一种分布式设备的容量更新装置结构示意图；
图4B是本发明实施例提供的一种切换模块的结构示意图。
具体实施方式
图1A是本发明实施例提供的一种分布式设备的容量更新系统架构图。在本申请中，分布式设备是指用于对网络流量进行处理的设备，例如分布式防火墙。参见图1A，该系统包括第一设备01和第二设备02，第一设备01和第二设备02之间可以通过有线网络或者无线网络的方式进行通信。其中，第一设备01和第二设备02均为分布式设备，且第一设备01和第二设备02均可以对业务报文进行处理。在一种可能的实现方式中，第二设备02可以作为第一设备01的备用设备，以在第一设备01出现故障时，由第二设备02代替第一设备01继续提供服务。值得注意的是，在第二设备02作为第一设备01的备用设备时，第一设备01为用户对当前业务报文进行处理的设备，而第二设备不为对当前业务报文进行处理的设备。
以第一设备01为例，对分布式设备进行详细说明。参见图1A，第一设备01包括MPU 011、LPU 012和至少一个SPU 013，每个SPU 013可以包括至少两个CPU。也即是，第一设备01包括至少两个CPU。其中，MPU 011可以通过通信总线与LPU 012连接，也可以通过通信总线与该至少一个SPU 013连接，且该通信总线可以包括一通路，在上述组件之间传送信息。需要说明的是，图1A以第一设备01包括一个SPU 013，且该SPU 013中包括3个CPU为例进行说明。
下面针对MPU、LPU和SPU分别进行详细阐述：
对于实现设备管理的MPU：
MPU用于配置业务和管理每个SPU中的CPU。具体地，在系统初始化时，MPU可以根据每个SPU中的CPU标识生成分流表，并将该分流表下发给LPU，该分流表用于指示LPU将接收到的业务报文分流到不同的CPU上，以实现每个CPU的负载均衡。之后，MPU还可以对每个SPU中的CPU进行监测，以确定CPU的数量是否发生变化，当确定CPU的数量发生变化时，需要确定变化后的每个CPU标识，并根据变化后的每个CPU标识重新生成分流表，以对分流表进行更新，从而确保分流表的准确性。
可选地，MPU可以按照每个CPU的插槽顺序为每个CPU分配标识。在分配CPU标识之后，如果MPU需要根据CPU标识生成分流表，则可以根据每个CPU标识的顺序，生成一个CPU标识序列，并将该CPU标识序列填充至空白分流表中，从而生成得到分流表。也即是，分流表中携带一个CPU标识序列，该CPU标识序列中的每个CPU标识分别指示第一设备中的一个CPU。
由于每个设备上可插入的CPU数量一般不同，比如，有的设备可插入的CPU数量为64，而有的设备可插入的CPU数量为32，而且分流表是基于设备中插入的CPU的标识生成得到的，因此，当分流表的长度较短时，可能出现分流表中的同一存储位置会对应至少两个CPU标识，比如，分流表的长度为32，但是已插入的CPU数量为64个，这样就会出现分流表中的一个存储位置对应2个CPU标识，如此在对接收到的业务报文进行分流时会发生冲突。另外，由于分流表是用于将业务报文分流到不同的CPU上，因此，当分流表的长度较长时，可能会出现CPU的负载不均衡的问题，比如，分流表的长度为32，但是已插入的CPU数量为31个，这样就会导致第一个CPU相比于其他的CPU负载较大，因此，为了避免冲突，以及实现均衡负载，一般可以统计每个设备可插入的CPU数量，并将统计的每个CPU数量的最小公倍数确定为分流表的长度，并在设备出厂固定设置于设备中。
也即是，第一设备中设置有分流表的长度，且该长度是固定的。因此，在第一设备生成分流表时，可以先基于设置的分流表长度生成固定长度的空白分流表，之后，将生成的CPU标识序列填充至该固定长度的空白分流表中。
比如，分流表的长度为1023，第一设备中包括3个CPU，分别为CPU1、CPU2和CPU3，对CPU1分配的CPU标识为ID1，对CPU2分配的CPU标识为ID2，对CPU3分配的CPU标识为ID3。假如基于该3个该CPU标识生成的CPU标识序列为ID1、ID2、ID3。在生成分流表时，可以按照ID1、ID2和ID3的顺序，依次将每个CPU标识填充到空白分流表中，从而生成得到如图表1所示的分流表。其中，在下述表1中，为了便于理解，在CPU标识序列的下方还示意性地携带一个数字序列，该数字序列中的每个数字用于指示对应位置上的CPU标识在分流表中的存储位置。实际应用中，分流表中可能并没有携带该数字序列，该数字序列只是为了便于理解而示意性的填充至分流表中。
表1
ID1 ID2 ID3 ID1 ID2 ID3 ...... ID2 ID3 ID1 ID2 ID3
1 2 3 4 5 6 ...... 1019 1020 1021 1022 1023
对于实现业务报文分流的LPU：
LPU包括多个输入接口和多个输出接口，该多个输入接口用于接收其他设备发送的业务报文，在接收到业务报文之后，LPU会按照MPU生成的分流表将接收的业务报文分流到不同的CPU上。在CPU对业务报文进行处理之后，再通过该多个输出接口将处理后的业务报文发送到下一级设备中。
其中，LPU按照MPU生成的分流表将接收到的业务报文分流到不同的CPU上的具体实现过程为：LPU对该业务报文中携带的地址信息进行哈希运算得到运算结果，该运算结果指示分流表携带的CPU标识序列中的一个存储位置。从该CPU标识序列中的该存储位置中获取CPU标识，并将该业务报文发送给该CPU标识对应的CPU，从而实现业务报文的分流。其中，该业务报文携带的地址信息可以为源IP地址和目的IP地址的组合，或者源IP地 址、目的IP地址、传输协议和目的端口的组合。
比如，对该业务报文携带的源IP地址和目的IP地址的组合进行哈希运算，假如得到的运算结果为6，此时，可以从上述表1所示的分流表中获取存储位置为6上的CPU标识，即ID3，并将该业务报文发送给ID3对应的CPU，即CPU3，从而可以实现业务报文的分流。
需要说明的是，该多个输入接口和该多个输出接口可以为任何收发器一类的装置，用于与其它设备或通信网络通信，如以太网、无线接入网(Radio Access Network，RAN)、无线局域网(Wireless Local Area Networks，WLAN)等。
对业务报文进行处理的SPU：
SPU中的CPU用于接收LPU通过分流所发送的业务报文，并对该业务报文进行处理。另外，为了便于第一设备在出现故障之后，第二设备可以顺利地代替第一设备继续对业务报文进行处理，第一设备还可以周期性地对每个CPU中存储的状态表项进行备份，也即是基于每个CPU中存储的状态表项生成备份报文，并将每个CPU的备份报文发送给第二设备，以便于第二设备中的每个CPU能够对存储的状态表项进行更新。其中，每个状态表项分别对应一条业务流，且每个状态表项中存储有对对应业务流上的业务报文进行处理的处理策略和对应业务流的流信息。该流信息可以包括源IP地址和目的IP地址的组合，或者源IP地址、目的IP地址、传输协议和目的端口的组合。
需要说明的是，在本发明实施例中，不仅可以通过CPU来实现业务报文的处理，当然，还可以通过微处理器、特定应用集成电路(Application-Specific Integrated Circuit，ASIC)，或者一个或多个用于控制本申请方案程序执行的集成电路来实现。
不难理解，第一设备除了包括上述每个组件之后，还可以包括存储器，该存储器可以是只读存储器(Read-Only Memory，ROM)、随机存取存储器(Random Access Memory，RAM)、可存储静态信息和指令的其它类型的静态存储设备、可存储信息和指令的其它类型的动态存储设备，也可以是电可擦可编程只读存储器(Electrically Erasable Programmable Read-Only Memory，EEPROM)、只读光盘(Compact Disc Read-Only Memory，CD-ROM)，或者其它光盘存储、光碟存储(包括压缩光碟、激光碟、光碟、数字通用光碟、蓝光光碟等)、磁盘存储介质，或者其它磁存储设备，或者能够用于携带或存储具有指令或数据结构形式的期望的程序代码并能够由第一设备存取的任何其它介质，但不限于此。存储器可以是独立存在，或者通过通信总线与CPU相连接，或者和CPU集成在一起。
综上，存储器用于存储执行本申请方案的程序代码，CPU用于执行存储器中存储的程序代码。第一可以通过CPU以及存储器中的程序代码，来实现下文图2实施例所提供的分布式设备的容量更新方法。
需要说明的是，由于第二设备也为分布式设备，因此，第二设备的内部结构和图1A中第一设备的内部结构相同，为了避免冗余，此处不对第二设备的内部结构进行详细的阐述。
在一种可能的实现方式中，本发明实施例提供的分布式设备的容量更新方法可以应用于防火墙系统中。图1B是本发明实施例提供的一种防火墙系统的硬件架构图，参见图1B，该防火墙系统中可以包括MPU、LPU和至少一个SPU，MPU可以通过管理总线与该至少一个SPU分别连接，该MPU可以通过监控总线与该LPU连接。另外，该防火墙系统还可以包括交换矩阵、电源系统冗余备份和风扇系统冗余备份。
图2是根据本发明实施例提供的一种分布式设备的容量更新方法流程图。该方法以第一设备和第二设备之间的交互为例进行说明。其中，第一设备为用于对当前业务报文进行处理的设备，第二设备不为对当前业务报文进行处理的设备。参见图2，该分布式设备的容量更新方法可以包括如下几个步骤：
步骤201：第二设备确定第二设备包括的CPU的数量发生变化后，生成第一分流表，第一分流表携带一个CPU标识序列，该CPU标识序列中的每个CPU标识分别指示CPU的数量发生变化后第二设备包括的一个CPU。
由于第二设备也可以为分布式设备，第二设备中也可以包括MPU、LPU和至少一个SPU，且每个SPU中包括至少两个CPU，也即是，第二设备包括至少两个CPU，因此，第二设备中的MPU可以对SPU中的CPU进行监测，以确定第二设备包括的CPU的数量是否发生变化。如果第二设备包括的CPU的数量发生变化，则确定已对第二设备的容量进行了更新，此时，第二设备的MPU可以基于CPU的数量发生变化后第二设备包括的每个CPU标识重新生成分流表，并将重新生成的分流表称为第一分流表。同时，第二设备还可以将自身包括的LPU中存储的第二分流表替换为第一分流表，以实现分流表的更新。其中，第二分流表为第二设备基于CPU的数量未变化之前的每个CPU标识生成得到。
然而，由于第二设备包括的CPU的数量发生变化存在两种情况，即第二设备中的CPU的数量可以增加，也可以减少，因此，下面针对这两种情况分别说明：
第一种情况，如果第二设备包括的CPU的数量增加，则为新增的CPU分配CPU标识，基于增加CPU之后第二设备包括的每个CPU对应的CPU标识，生成第一分流表。
在第一种情况中，由于第二设备中增加了CPU，也即是，对第二设备的容量进行了扩容，因此，第二设备的MPU需要为新增的CPU分配CPU标识。由于分流表是用于将业务报文分流到不同的CPU上，因此，在CPU的数量发生变化之后，为了保证后续将业务报文能够准确地分流到不同的CPU上，第二设备需要对分流表进行更新，即第二设备的MPU需要基于增加CPU之后第二设备包括的每个CPU对应的CPU标识，重新生成分流表，并将重新生成的分流表称为第一分流表。
在一种可能的实现方式中，CPU是按照顺序插入插槽中，因此，可以按照第二设备中每个CPU的插槽顺序，对每个CPU分配CPU标识，而第一种情况是增加CPU，因此，对增加的CPU分配的CPU标识可以直接顺序增加得到，比如，未增加CPU之前，第二设备中包括2个CPU，分别为CPU1和CPU2，对CPU1分配的CPU标识为ID1，对CPU2分配的CPU标识为ID2。在增加CPU之后，按照CPU的插槽顺序，此时可以直接为新增的CPU分配CPU标识为ID3。在为新增的CPU分配CPU标识之后，可以按照增加CPU之后的每个CPU对应的CPU标识的顺序，依次填充空白的分流表，从而得到第一分流表。比如，分流表的长度为1023，将ID1、ID2和ID3，按照顺序填充空白的分流表之后，得到的第一分流表可以如下表2所示。
表2
ID1 ID2 ID3 ID1 ID2 ID3 ...... ID2 ID3 ID1 ID2 ID3
1 2 3 4 5 6 ...... 1019 1020 1021 1022 1023
第二种情况，如果第二设备包括的CPU的数量减少，则按照CPU插槽顺序为减少CPU之后第二设备包括的每个CPU重新分配CPU标识，基于为第二设备包括的每个CPU重新分 配的CPU标识，生成第一分流表。
在第二种情况中，由于第二设备中减少了CPU，也即是，对第二设备的容量进行了缩容，如果减少的CPU的插槽顺序位于已插入的CPU中间，这样，减少后的CPU标识就会不连续，而且后续将业务报文进行分流时可能会出现错误，因此，为了避免这些问题，可以按照CPU插槽顺序为减少CPU之后第二设备包括的每个CPU重新分配CPU标识，进而基于为第二设备包括的每个CPU重新分配的CPU标识，重新生成分流表，并将重新生成的分流表称为第一分流表。
在一种可能的实现方式中，可以按照第二设备中每个CPU的插槽顺序，对每个CPU分配CPU标识，而第二种情况是减少CPU，因此，可以按照CPU插槽顺序为减少CPU之后的每个CPU重新分配CPU标识，比如，未减少CPU之前，第二设备中包括3个CPU，分别为CPU1、CPU2和CPU3，对CPU1分配的CPU标识为ID1，对CPU2分配的CPU标识为ID2，对CPU3分配的CPU标识为ID3。在减少CPU之后，假设减少的CPU为CPU2，此时第二设备中只剩下CPU1和CPU3，因此，按照CPU的插槽顺序，为CPU1重新分配的CPU标识为ID1，为CPU3重新分配的CPU标识为ID2。之后，可以按照减少CPU之后的每个CPU对应的CPU标识的顺序，依次填充空白的分流表，从而得到第一分流表。比如，分流表的长度为1023，将ID1和ID2，按照顺序填充空白的分流表之后，得到的第一分流表可以如下表3所示。
表3
ID1 ID2 ID1 ID2 ID1 ID2 ...... ID1 ID2 ID1 ID2 ID1
1 2 3 4 5 6 ...... 1019 1020 1021 1022 1023
步骤202：第二设备向第一设备发送第一分流表。
由于第一分流表是基于CPU的数量发生变化之后第二设备中包括的每个CPU标识生成的，且第二设备是第一设备的备用设备，因此，为了便于后续将第一设备中存储的状态表项备份到第二设备中，第二设备可以将第一分流表发送给第一设备。
步骤203：第一设备接收第二设备发送的第一分流表，并确定第一设备中的每个状态表项在第一分流表中对应的CPU标识，从而形成状态表项与CPU标识之间的映射关系。
具体地，第一设备可以接收第二设备发送的第一分流表，并将第一分流表存储到第一设备的LPU中，对于第一设备包括的每个CPU存储的任一状态表项，第一设备的LPU可以对该状态表项中存储的流信息进行哈希运算得到运算结果，该运算结果指示该状态表项对应的CPU标识在第一分流表的CPU标识序列中的一个存储位置，从第一分流表中获取在该存储位置上存储的CPU标识，并将获取的CPU标识确定为该状态表项对应的CPU标识。
也即是，从第一设备包含的至少一个状态表项中选择出一个状态表项，对选择出的状态表项执行以下处理，直到处理完第一设备包含的每个状态表项为止：
对选择出的状态表项中的流信息进行哈希运算得到运算结果，该运算结果指示第一分流表携带的CPU标识序列中的一个存储位置，从该CPU标识序列中的该存储位置中获取CPU标识，确定获取的该CPU标识为选择出的状态表项对应的CPU标识。
比如，第一设备在接收到第二设备发送的第一分流表之后，对于第一设备包括的每个CPU存储的任一状态表项，对该状态表项中存储的流信息进行哈希运算，假设哈希运算后得到的数值为5，则将该状态表项对应的CPU标识在第一分流表中的存储位置确定为5，此时，第一设备可以基于该存储位置5，从第一分流表中获取该状态表项对应的CPU标识。 假设第一分流表为上述表2，则可以确定该状态表项对应的CPU标识为ID2。
其中，每个状态表项分别对应一条业务流，且每个状态表项中存储有对对应业务流上的业务报文进行处理的处理策略和对应业务流的流信息。该流信息可以包括该业务流的源IP地址和目的IP地址的组合，或者源IP地址、目的IP地址、传输协议和目的端口的组合。当然，实际应用中，该流信息还可以为其他信息，比如，可以包括该业务流的源IP地址、目的IP地址和传输协议的组合，或者源IP地址、目的IP地址和目标端口的组合等等。
需要说明的是，由于第一设备用于对接收到的业务报文进行处理，因此，在第一设备的CPU中会存储包括业务报文的处理策略和流信息的状态表项。另外，状态表项中不仅可以包括处理策略，还可以包括该状态表项对应的业务流的网络地址转换(Network Address Translation，NAT)、IP网络安全协议(Security Architecture for IP network，IPSEC)等相关信息。
在本发明实施例中，由于先对第二设备的容量进行了更新，因此，第二设备的分流表已经发生了变化，所以为了便于能够将状态表项准确地备份到第二设备的CPU中，此时，需要基于第一设备包括的每个CPU存储的状态表项，从第一分流表中确定每个状态表项对应的CPU标识。另外，在本发明实施例中，由于只需在第二设备进行容量更新之后，按照第二设备更新后的分流表，即第一分流表来进行状态表项的备份，因此，无需第一设备和第二设备的CPU数量和CPU标识严格保持一致，从而可以提高容量更新的灵活性。
步骤204：第一设备根据该映射关系生成至少一个备份报文，该至少一个备份报文中的每个备份报文携带一个CPU标识以及与该CPU标识对应的至少一个状态表项。
具体地，基于第一分流表形成第一设备中的每个状态表项与CPU标识之间的映射关系之后，可以根据该映射关系，将第一设备中存储的状态表项划分为至少一组，每组状态表项中包括至少一个状态表项，且同一组状态表项对应的CPU标识相同。以组为单位，生成每组状态表项对应的一个备份报文，从而得到至少一个备份报文，该至少一个备份报文中的每个备份报文的报文头部携带对应组中的状态表项对应的CPU标识、且每个备份报文包括对应组中包括的至少一个状态表项。
由于状态表项对应的CPU标识相同时，可以确定该状态表项会被备份到第二设备中的同一CPU上。因此，基于每个状态表项对应的CPU标识，将备份后得到的状态表项划分为至少一组之后，可以将该至少一组状态表项和该至少一组状态表项对应的CPU标识生成至少一个备份报文，这样就无需将每个状态表项和该状态表项对应的CPU标识单独生成一个备份报文。也即是，本发明实施例将备份到同一CPU的状态表项集成到一个备份报文中，这样可以减少备份报文的数量，从而可以提高状态表项的备份效率。
其中，在第一设备基于至少一组状态表项和该至少一组状态表项对应的CPU标识，生成至少一个备份报文时，第一设备可以先将该至少一组状态表项分别封装到至少一个报文中，然后在该至少一个报文的头部分别添加上各组状态表项对应的CPU标识，从而得到至少一个备份报文。
步骤205：第一设备将该至少一个备份报文发送给第二设备。
需要说明的是，由于第二设备可以作为第一设备的备用设备，因此，第一设备和第二设备之间需要实时地确定对方设备是否出现故障。目前，主要是通过心跳保活的方式来确定对方设备是否出现故障，也即是，第一设备和第二设备之间可以通过LPU上的心跳接口 互相发送心跳包，以确定对方设备是否出现故障。换句话说，LPU上不仅包括多个输入接口和多个输出接口，还包括有心跳接口。在本发明实施例中，为了便于第二设备在接收到备份报文时，将备份报文和输入接口接收到的业务报文进行区分，第一设备可以将该至少一个备份报文通过第二设备的LPU上的心跳接口发送给第二设备。
步骤206：第二设备接收第一设备发送的至少一个备份报文，并根据该至少一个备份报文中的每个备份报文携带的一个CPU标识和该CPU标识对应的至少一个状态表项，更新第二设备中每个备份报文携带的CPU标识所指示的CPU中存储的状态表项。
在第二设备通过LPU上的心跳接口接收到第一设备发送的至少一个备份报文时，第二设备可以确定需要对存储的状态表项进行更新，且第一设备已将每个CPU中存储的状态表项全部在该至少一个备份报文中发送过来。此时，第二设备可以获取每个备份报文中携带的CPU标识，然后根据每个备份报文中携带的CPU标识，将每个备份报文中携带的该CPU标识对应的至少一个状态表项存储到第二设备中该CPU标识所指示的CPU中。
需要说明的是，由于该至少一个备份报文是通过第二设备的LPU上的心跳接口接收到的，也就是说，该至少一个备份报文是LPU接收到的。由于每个备份报文中携带有CPU标识，因此，LPU接收到该至少一个备份报文之后，可以直接按照每个备份报文中携带的CPU标识，将备份报文发送给对应的CPU，以更新第二设备包括的每个CPU存储的状态表项，而无需将该至少一个备份报文进行分流。
其中，由于第二设备中可能之前已存储有状态表项，此时，第二设备可以直接将之前存储的状态表项替换为备份报文中的状态表项，以实现第二设备中每个CPU存储的状态表项的更新。当然，在第二设备向第一设备发送第一分流表时，第二设备还可以将每个CPU中存储的状态表项进行老化，从而在接收到该至少一个备份报文时，可以直接将每个备份报文中的状态表项存储到对应的CPU中，以实现第二设备中每个CPU存储的状态表项的更新。
步骤207：第一设备将该至少一个备份报文发送给第二设备之后，向第二设备发送备份完成通知消息，并将第一设备切换为暂不对后续业务报文进行处理的设备。
该备份完成通知消息用于将第一设备包括的每个CPU中存储的状态表项已经备份完成的消息通知给第二设备，这样便于第二设备基于接收到至少一个备份报文对存储的状态表项更新之后，将第二设备切换为用于对后续业务报文进行处理的设备，从而避免流量中断的问题。
需要说明的是，该备份完成通知消息也可以通过心跳接口发送给第二设备，当然也可以通过其他的接口发送给第二设备。
步骤208：第二设备接收第一设备发送的备份完成通知消息，将第二设备切换为用于对后续业务报文进行处理的设备。
具体地，第二设备接收第一设备发送的备份完成通知消息，将第二设备的优先级设置为第二优先级，第二优先级高于第三优先级，第三优先级高于第一优先级，第一优先级为CPU的数量发生变化之前第二设备的优先级，第三优先级为第一设备当前的优先级。基于第二设备的优先级和第一设备当前的优先级，与第一设备进行协商，从而将第二设备切换为用于对后续业务报文进行处理的设备。
由于第一设备和第二设备中，哪个设备作为对业务报文进行处理的设备，哪个设备作为哪个设备的备用设备，这些都是通过第一设备和第二设备之间的优先级进行协商得到， 而且在第二设备包括的每个CPU存储的状态表项更新完成之后，为了避免流量中断的问题，此时需要将对业务报文进行处理的设备从第一设备切换至第二设备，因此，需要对第二设备的优先级进行更新，也即是将第二设备的优先级设置为第二优先级，第二优先级高于第一优先级，第一优先级为CPU的数量发生变化之前第二设备的优先级。又由于在协商过程中，哪个设备的优先级比较高，哪个设备就可以作为对业务报文进行处理的设备，因此，将第二设备的优先级设置为第二优先级之后，需要确保第二优先级高于第一设备当前的优先级，即第三优先级。之后，第二设备可以和第一设备进行协商，从而将对业务报文进行处理的设备从第一设备切换至第二设备。
在本发明实施例中，第二设备接收到第一设备发送的备份完成通知消息之后，可以直接将第二设备的优先级设置为第二优先级，并基于第二设备的优先级和第一设备当前的优先级，与第一设备进行协商，从而将第二设备切换为用于对后续业务报文进行处理的设备。当然，第二设备也可以在接收到第一设备发送的备份完成通知消息之后，先将第二设备的优先级设置为第二优先级。当接收到用户触发的切换指令时，基于第二设备的优先级和第一设备当前的优先级，与第一设备进行协商，从而将第二设备切换为用于对后续业务报文进行处理的设备。又或者，第二设备在接收到第一设备发送的备份完成通知消息之后，当接收到用户触发的切换指令时，再将第二设备的优先级设置为第二优先级，并基于第二设备的优先级和第一设备当前的优先级，与第一设备进行协商，从而将第二设备切换为用于对后续业务报文进行处理的设备。本发明实施例对协商的时机不做具体限定。
可选地，在主备切换之后，第一设备和第二设备可以同时降低各自的优先级，例如第一设备的优先级设置为第一优先级，第二设备的优先级设置为第三优先级。这样以便于下一次主备切换。
可选地，在第二设备按照上述方法进行容量更新之后，第一设备也可以按照上述方法进行容量更新。由于第一设备进行容量更新方法可以与上述方法相同，因此，本发明实施例对第一设备进行容量更新的方法不再进行详细阐述。
在本发明实施例中，由于第一分流表为第二设备包括的CPU的数量发生变化之后，第二设备基于变化后的CPU标识生成得到，也即是，先改变第二设备中的CPU数量以对第二设备的容量进行更新，这样在接收到业务报文时，可以通过第一设备对业务报文进行处理，不会出现流量中断的情况。之后，第一设备可以确定存储的每个状态表项在第一分流表中对应的CPU标识，从而形成状态表项与CPU标识之间的映射关系，并基于该映射关系生成至少一个备份报文，并通过该至少一个备份报文中每个备份报文携带的一个CPU标识和该CPU标识对应的至少一个状态表项，对第二设备包括的每个CPU中的状态表项进行更新。由于每个备份报文中携带的CPU标识是从第一分流表中确定的，因此，将对业务报文进行处理的设备从第一设备切换到第二设备之后，第二设备按照第一分流表将后续接收到的业务报文分流到不同的CPU之后，就不会出现CPU上未存储该业务报文所属业务流的状态表项的情况，进而避免CPU将业务报文丢弃以导致流量中断的情况，从而实现了平滑扩容或者缩容。
图3A是本发明实施例提供的一种分布式设备的容量更新装置的结构示意图，该装置可以由软件、硬件或者两者的结合实现成为第一设备的部分或者全部，第一设备可以为图1A所示的第一设备。第一设备为用于对当前业务报文进行处理的设备，第一设备包括至少 两个CPU，该至少两个CPU中的每个CPU对应保存至少一个业务流的状态表项。参见图3A，该装置包括接收模块301，确定模块302，生成模块303、发送模块304和切换模块305。
接收模块301，用于执行图2实施例中的步骤203中接收第二设备发送的第一分流表的操作；
确定模块302，用于执行图2实施例中的步骤203中确定第一设备中的每个状态表项在第一分流表中对应的CPU标识，从而形成状态表项与CPU标识之间的映射关系的操作；
生成模块303，用于执行图2实施例中的步骤204；
发送模块304，用于执行图2实施例中的步骤205；
发送模块304，还用于执行图2步骤207中向第二设备发送备份完成通知消息。
切换模块305，还用于执行图2步骤207中将第二设备切换为用于对后续业务报文进行处理的设备。
可选地，确定模块302，具体用于：
从第一设备包含的至少一个状态表项中选择出一个状态表项，对选择出的状态表项执行以下处理，直到处理完第一设备包含的每个状态表项为止：
对选择出的状态表项中的流信息进行哈希运算得到运算结果，该运算结果指示该CPU标识序列中的一个存储位置；
从该CPU标识序列中的该存储位置中获取CPU标识，确定获取的CPU标识为选择出的状态表项对应的CPU标识。
可选地，流信息包括选择出的状态表项对应的业务流的源IP地址和目的IP地址的组合，或者源IP地址、目的IP地址、传输协议和目的端口的组合。
可选地，参见图3B，生成模块304包括：
划分单元3041，用于根据该映射关系，将第一设备中存储的状态表项划分为至少一组，每组状态表项中包括至少一个状态表项，且同一组状态表项对应的CPU标识相同；
生成单元3042，用于以组为单位，生成每组状态表项对应的一个备份报文，从而得到至少一个备份报文，该至少一个备份报文中的每个备份报文的报文头部携带对应组中的状态表项对应的CPU标识、且每个备份报文包括对应组中包括的至少一个状态表项。
由于第一分流表为第二设备中的CPU数量发生变化发送给第一设备的，也即是，先改变第二设备中的CPU数量以对第二设备的容量进行更新，这样在接收到业务报文时，可以通过第一设备对业务报文进行处理，不会出现流量中断的情况。之后，第一设备可以确定存储的每个状态表项在第一分流表中对应的CPU标识，从而形成状态表项与CPU标识之间的映射关系，并基于该映射关系生成至少一个备份报文，并通过该至少一个备份报文中每个备份报文携带的一个CPU标识和该CPU标识对应的至少一个状态表项，对第二设备包括的每个CPU中的状态表项进行更新。由于每个备份报文中携带的CPU标识是从第一分流表中确定的，因此，将第二设备切换为用于对后续业务报文进行处理的设备备之后，第二设备按照第一分流表将后续接收到的业务报文分流到不同的CPU之后，就不会出现CPU上未存储该业务报文所属业务流的状态表项的情况，进而避免CPU将业务报文丢弃以导致流量中断的情况。
图4A是本发明实施例提供的一种分布式设备的容量更新装置的结构示意图，该装置可以由软件、硬件或者两者的结合实现成为第二设备的部分或者全部，第二设备可以为图 1A所示的第二设备。第二设备不是对当前业务报文进行处理的设备，第二设备包括至少两个CPU。参见图4A，该装置包括生成模块401，发送模块402，接收模块403，更新模块404和切换模块405。
生成模块401，用于执行图2实施例中的步骤201；
发送模块402，用于执行图2实施例中的步骤202；
接收模块403，用于执行图2实施例中的步骤206中接收第一设备发送的至少一个备份报文的操作、以及步骤208中接收第一设备发送的备份完成通知消息；
更新模块404，用于执行图2实施例中的步骤206中根据该至少一个备份报文中的每个备份报文携带的一个CPU标识和该CPU标识对应的至少一个状态表项，更新第二设备中每个备份报文携带的CPU标识所指示的CPU中存储的状态表项的操作；
切换模块405，用于执行图2实施例中的步骤206更新完成后且步骤208中接收到所述备份完成通知消息后，将所述第二设备切换为用于对后续业务报文进行处理的设备。
可选地，参见图4B，切换模块405包括：
更新单元4051，用于将第二设备的优先级设置为第二优先级，第二优先级高于第三优先级，第三优先级高于第一优先级，第一优先级为CPU的数量发生变化之前第二设备的优先级，第三优先级为第一设备当前的优先级；
协商单元4052，用于基于第二设备的优先级和第一设备当前的优先级，与第一设备进行协商，从而将第二设备切换为用于对后续业务报文进行处理的设备。
可选地，生成模块401具体用于：
如果所述第二设备包括的CPU的数量增加，则为新增的CPU分配CPU标识；
基于增加CPU之后第二设备包括的每个CPU对应的CPU标识，生成第一分流表。
可选地，生成模块401具体用于：
如果所述第二设备包括的CPU的数量减少，则按照CPU插槽顺序为减少CPU之后第二设备包括的每个CPU重新分配CPU标识；
基于为第二设备包括的每个CPU重新分配的CPU标识，生成第一分流表。
在本发明实施例中，由于第一设备是按照第一分流表生成得到至少一个备份报文，因此，当第二设备接收到该至少一个备份报文时，第二设备可以对包括的每个CPU存储的状态表项进行更新，之后，在接收到第一设备发送的备份完成通知消息时，将对业务报文进行处理的设备从第一设备切换到第二设备，这样，第二设备接收到业务报文时，按照第一分流表将业务报文分流到不同的CPU之后，就不会出现CPU上未存储该业务报文的状态表项的情况，进而避免CPU将业务报文丢弃以导致流量中断的情况。
需要说明的是：上述实施例提供的分布式设备的容量更新装置在容量更新时，仅以上述各功能模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即将设备的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能。另外，上述实施例提供的分布式设备的容量更新装置与分布式设备的容量更新方法实施例属于同一构思，其具体实现过程详见方法实施例，这里不再赘述。
本领域普通技术人员可以理解实现上述实施例的全部或部分步骤可以通过硬件来完成，也可以通过程序来指令相关的硬件完成，所述的程序可以存储于一种计算机可读存储介质中，上述提到的存储介质可以是只读存储器，磁盘或光盘等。
在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。所述计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行所述计算机程序指令时，全部或部分地产生按照本发明实施例所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输，例如，所述计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光线、数字用户线(Digital Subscriber Line，DSL))或无限(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。所述计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。所述可用介质可以是磁性介质，(例如，软盘、硬盘、磁带)、光介质(例如，数字化视频光盘(Digital Video Disk，DVD))、或者半导体介质(例如固态硬盘(Solid State Disk，SSD))等。
以上所述仅为本申请的实施例，并不用以限制本申请，凡基于本申请实施例所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。

Claims (16)

  1. 一种分布式设备的容量更新方法，由第一设备执行，所述第一设备为用于对当前业务报文进行处理的设备，所述第一设备包括至少两个CPU，所述至少两个CPU中的每个CPU对应保存至少一个业务流的状态表项，其特征在于，所述方法包括：
    接收第二设备发送的第一分流表，所述第一分流表携带一个CPU标识序列，所述CPU标识序列中的每个CPU标识分别指示所述第二设备中的一个CPU，所述第一分流表为所述第二设备包括的CPU的数量发生变化后向所述第一设备发送的；
    确定所述第一设备中的每个状态表项在所述第一分流表中对应的CPU标识，从而形成状态表项与CPU标识之间的映射关系；
    根据所述映射关系，生成至少一个备份报文，所述至少一个备份报文中的每个备份报文携带一个CPU标识以及与所述CPU标识对应的至少一个状态表项；
    将所述至少一个备份报文发送给所述第二设备，以指示所述第二设备根据所述每个备份报文携带的一个CPU标识以及与所述CPU标识对应的至少一个状态表项，更新所述第二设备中存储的状态表项；
    将所述至少一个备份报文发送给所述第二设备之后，向所述第二设备发送备份完成通知消息，并将所述第一设备切换为暂不对后续业务报文进行处理的设备，所述备份完成通知消息用于指示所述第二设备对存储的状态表项更新之后，将所述第二设备切换为用于对后续业务报文进行处理的设备。
  2. 如权利要求1所述的方法，其特征在于，所述确定所述第一设备中的每个状态表项在所述第一分流表中对应的CPU标识，包括：
    从所述第一设备包含的至少一个状态表项中选择出一个状态表项，对选择出的状态表项执行以下处理，直到处理完所述第一设备包含的每个状态表项为止：
    对选择出的状态表项中的流信息进行哈希运算得到运算结果，所述运算结果指示所述CPU标识序列中的一个存储位置；
    从所述CPU标识序列中的所述存储位置中获取CPU标识，确定获取的所述CPU标识为所述选择出的状态表项对应的CPU标识。
  3. 如权利要求2所述的方法，其特征在于，所述流信息包括选择出的状态表项对应的业务流的源互联网协议IP地址和目的IP地址的组合，或者源IP地址、目的IP地址、传输协议和目的端口的组合。
  4. 如权利要求1所述的方法，其特征在于，所述根据所述映射关系，生成至少一个备份报文，包括：
    根据所述映射关系，将所述第一设备中存储的状态表项划分为至少一组，每组状态表项中包括至少一个状态表项，且同一组状态表项对应的CPU标识相同；
    以组为单位，生成每组状态表项对应的一个备份报文，从而得到至少一个备份报文，所述至少一个备份报文中的每个备份报文的报文头部携带对应组中的状态表项对应的CPU标识、且所述每个备份报文包括对应组中包括的至少一个状态表项。
  5. 一种分布式设备的容量更新方法，由第二设备执行，所述第二设备不是对当前业务报文进行处理的设备，所述第二设备包括至少两个CPU，其特征在于，所述方法包括：
    确定所述第二设备包括的CPU的数量发生变化后，生成第一分流表，所述第一分流表携带一个CPU标识序列，所述CPU标识序列中的每个CPU标识分别指示CPU的数量发生变化后所述第二设备包括的一个CPU；
    向第一设备发送所述第一分流表；
    接收所述第一设备发送的至少一个备份报文，所述至少一个备份报文中的每个备份报文携带一个CPU标识以及与所述CPU标识对应的至少一个状态表项，所述每个备份报文携带的CPU标识为所述第一设备从所述第一分流表中确定的；
    根据所述至少一个备份报文中的每个备份报文携带的一个CPU标识以及与所述CPU标识对应的至少一个状态表项，更新所述第二设备中所述每个备份报文携带的CPU标识所指示的CPU中存储的状态表项；
    接收所述第一设备发送的备份完成通知消息，将所述第二设备切换为用于对后续业务报文进行处理的设备。
  6. 如权利要求5所述的方法，其特征在于，所述将所述第二设备切换为用于对后续业务报文进行处理的设备，包括：
    将所述第二设备的优先级设置为第二优先级，所述第二优先级高于第三优先级，所述第三优先级高于第一优先级，所述第一优先级为CPU的数量发生变化之前所述第二设备的优先级，所述第三优先级为所述第一设备当前的优先级；
    基于所述第二设备的优先级和所述第一设备当前的优先级，与所述第一设备进行协商，从而将所述第二设备切换为用于对后续业务报文进行处理的设备。
  7. 如权利要求5所述的方法，其特征在于，所述确定所述第二设备包括的CPU的数量发生变化后，生成第一分流表，包括：
    如果所述第二设备包括的CPU的数量增加，则为新增的CPU分配CPU标识；
    基于增加CPU之后所述第二设备包括的每个CPU对应的CPU标识，生成第一分流表。
  8. 如权利要求5所述的方法，其特征在于，所述确定所述第二设备包括的CPU的数量发生变化后，生成第一分流表，包括：
    如果所述第二设备包括的CPU的数量减少，则按照CPU插槽顺序为减少CPU之后所述第二设备包括的每个CPU重新分配CPU标识；
    基于为所述第二设备包括的每个CPU重新分配的CPU标识，生成第一分流表。
  9. 一种分布式设备的容量更新装置，包含于第一设备中，所述第一设备为用于对当前业务报文进行处理的设备，所述第一设备包括至少两个CPU，所述至少两个CPU中的每个CPU对应保存至少一个业务流的状态表项，其特征在于，所述装置包括：
    接收模块，用于接收第二设备发送的第一分流表，所述第一分流表携带一个CPU标识序列，所述CPU标识序列中的每个CPU标识分别指示所述第二设备中的一个CPU，所述第 一分流表为所述第二设备包括的CPU的数量发生变化后向所述第一设备发送的；
    确定模块，用于确定所述第一设备中的每个状态表项在所述第一分流表中对应的CPU标识，从而形成状态表项与CPU标识之间的映射关系；
    生成模块，用于根据所述映射关系，生成至少一个备份报文，所述至少一个备份报文中的每个备份报文携带一个CPU标识以及与所述CPU标识对应的至少一个状态表项；
    发送模块，用于将所述至少一个备份报文发送给所述第二设备，以指示所述第二设备根据所述每个备份报文携带的一个CPU标识以及与所述CPU标识对应的至少一个状态表项，更新所述第二设备中存储的状态表项；
    所述发送模块，还用于将所述至少一个备份报文发送给所述第二设备之后，向所述第二设备发送备份完成通知消息，所述备份完成通知消息用于指示所述第二设备对存储的状态表项更新之后，将所述第二设备切换为用于对后续业务报文进行处理的设备；
    切换模块，用于将所述至少一个备份报文发送给所述第二设备之后，将所述第一设备切换为暂不对后续业务报文进行处理的设备。
  10. 如权利要求9所述的装置，其特征在于，所述确定模块，具体用于：
    从所述第一设备包含的至少一个状态表项中选择出一个状态表项，对选择出的状态表项执行以下处理，直到处理完所述第一设备包含的每个状态表项为止：
    对选择出的状态表项中的流信息进行哈希运算得到运算结果，所述运算结果指示所述CPU标识序列中的一个存储位置；
    从所述CPU标识序列中的所述存储位置中获取CPU标识，确定获取的所述CPU标识为所述选择出的状态表项对应的CPU标识。
  11. 如权利要求10所述的装置，其特征在于，所述流信息包括选择出的状态表项对应的业务流的源互联网协议IP地址和目的IP地址的组合，或者源IP地址、目的IP地址、传输协议和目的端口的组合。
  12. 如权利要求9所述的装置，其特征在于，所述生成模块包括：
    划分单元，用于根据所述映射关系，将所述第一设备中存储的状态表项划分为至少一组，每组状态表项中包括至少一个状态表项，且同一组状态表项对应的CPU标识相同；
    生成单元，用于以组为单位，生成每组状态表项对应的一个备份报文，从而得到至少一个备份报文，所述至少一个备份报文中的每个备份报文的报文头部携带对应组中的状态表项对应的CPU标识、且所述每个备份报文包括对应组中包括的至少一个状态表项。
  13. 一种分布式设备的容量更新装置，包含于第二设备，所述第二设备不是对当前业务报文进行处理的设备，所述第二设备包括至少两个CPU，其特征在于，所述装置包括：
    生成模块，用于确定所述第二设备包括的CPU的数量发生变化后，生成第一分流表，所述第一分流表携带一个CPU标识序列，所述CPU标识序列中的每个CPU标识分别指示CPU的数量发生变化后所述第二设备包括的一个CPU；
    发送模块，用于向第一设备发送所述第一分流表；
    接收模块，用于接收所述第一设备发送的至少一个备份报文，所述至少一个备份报文 中的每个备份报文携带一个CPU标识以及与所述CPU标识对应的至少一个状态表项，所述每个备份报文携带的CPU标识为所述第一设备从所述第一分流表中确定的；
    更新模块，用于根据所述至少一个备份报文中的每个备份报文携带的一个CPU标识以及与所述CPU标识对应的至少一个状态表项，更新所述第二设备中所述每个备份报文携带的CPU标识所指示的CPU中存储的状态表项；
    所述接收模块，还用于接收所述第一设备发送的备份完成通知消息；
    切换模块，用于接收到所述备份完成通知消息后，将所述第二设备切换为用于对后续业务报文进行处理的设备。
  14. 如权利要求13所述的装置，其特征在于，所述切换模块包括：
    更新单元，用于将所述第二设备的优先级设置为第二优先级，所述第二优先级高于第三优先级，所述第三优先级高于第一优先级，所述第一优先级为CPU的数量发生变化之前所述第二设备的优先级，所述第三优先级为所述第一设备当前的优先级；
    协商单元，用于基于所述第二设备的优先级和所述第一设备当前的优先级，与所述第一设备进行协商，从而将所述第二设备切换为用于对后续业务报文进行处理的设备。
  15. 如权利要求13所述的装置，其特征在于，所述生成模块具体用于：
    如果所述第二设备包括的CPU的数量增加，则为新增的CPU分配CPU标识；
    基于增加CPU之后所述第二设备包括的每个CPU对应的CPU标识，生成第一分流表。
  16. 如权利要求13所述的装置，其特征在于，所述生成模块具体用于：
    如果所述第二设备包括的CPU的数量减少，则按照CPU插槽顺序为减少CPU之后所述第二设备包括的每个CPU重新分配CPU标识；
    基于为所述第二设备包括的每个CPU重新分配的CPU标识，生成第一分流表。
PCT/CN2017/111136 2017-03-09 2017-11-15 分布式设备的容量更新方法及装置 WO2018161632A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201710138783.3 2017-03-09
CN201710138783.3A CN108574587B (zh) 2017-03-09 2017-03-09 分布式设备的容量更新方法及装置

Publications (1)

Publication Number Publication Date
WO2018161632A1 true WO2018161632A1 (zh) 2018-09-13

Family

ID=63447296

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2017/111136 WO2018161632A1 (zh) 2017-03-09 2017-11-15 分布式设备的容量更新方法及装置

Country Status (2)

Country Link
CN (1) CN108574587B (zh)
WO (1) WO2018161632A1 (zh)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20220038378A1 (en) * 2019-11-08 2022-02-03 Tencent Technology (Shenzhen) Company Limited Service offloading method, apparatus, and system, electronic device, and storage medium
CN115134372A (zh) * 2022-06-23 2022-09-30 中国民航信息网络股份有限公司 一种数据处理方法和相关装置

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112714011B (zh) * 2020-12-15 2023-06-02 贝壳技术有限公司 分流信息配置方法、装置、电子设备和存储介质

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101354695A (zh) * 2008-09-19 2009-01-28 杭州华三通信技术有限公司 一种进程间通信的方法、系统和分布式设备
CN102929687A (zh) * 2012-10-12 2013-02-13 山东省计算中心 一种节能的云计算数据中心虚拟机放置方法
CN103797774A (zh) * 2013-11-05 2014-05-14 华为技术有限公司 一种网络地址转换设备及方法
CN103905268A (zh) * 2012-12-28 2014-07-02 华为技术有限公司 Gre链路检测方法、主控板、装置及通信防护系统
WO2015096005A1 (zh) * 2013-12-23 2015-07-02 华为技术有限公司 消息处理方法和网关

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102821165B (zh) * 2012-04-13 2016-08-03 中兴通讯股份有限公司 Ip地址转换方法及装置
CN102724119B (zh) * 2012-06-08 2015-05-20 南京贝伦思网络科技有限公司 一种网络负载均衡设备或分流设备规则同步方法
CN103891237B (zh) * 2012-09-29 2017-12-05 华为技术有限公司 一种网络存储的方法、交换设备和控制器
US9461923B2 (en) * 2013-12-06 2016-10-04 Algoblu Holdings Limited Performance-based routing in software-defined network (SDN)
CN104780055B (zh) * 2014-01-10 2018-03-06 华为技术有限公司 一种数据流的处理方法及装置
CN104811400B (zh) * 2014-01-26 2018-04-06 杭州迪普科技股份有限公司 一种分布式网络设备
US9571412B2 (en) * 2014-11-21 2017-02-14 Cavium, Inc. Systems and methods for hardware accelerated timer implementation for openflow protocol
CN105515919A (zh) * 2016-01-20 2016-04-20 中国电子科技集团公司第五十四研究所 一种基于哈希压缩算法的网络流量监控方法

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101354695A (zh) * 2008-09-19 2009-01-28 杭州华三通信技术有限公司 一种进程间通信的方法、系统和分布式设备
CN102929687A (zh) * 2012-10-12 2013-02-13 山东省计算中心 一种节能的云计算数据中心虚拟机放置方法
CN103905268A (zh) * 2012-12-28 2014-07-02 华为技术有限公司 Gre链路检测方法、主控板、装置及通信防护系统
CN103797774A (zh) * 2013-11-05 2014-05-14 华为技术有限公司 一种网络地址转换设备及方法
WO2015096005A1 (zh) * 2013-12-23 2015-07-02 华为技术有限公司 消息处理方法和网关

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20220038378A1 (en) * 2019-11-08 2022-02-03 Tencent Technology (Shenzhen) Company Limited Service offloading method, apparatus, and system, electronic device, and storage medium
CN115134372A (zh) * 2022-06-23 2022-09-30 中国民航信息网络股份有限公司 一种数据处理方法和相关装置
CN115134372B (zh) * 2022-06-23 2023-08-29 中国民航信息网络股份有限公司 一种数据处理方法和相关装置

Also Published As

Publication number Publication date
CN108574587A (zh) 2018-09-25
CN108574587B (zh) 2020-07-24

Similar Documents

Publication Publication Date Title
US11218537B2 (en) Load balancing in distributed computing systems
US10779339B2 (en) Wireless roaming using a distributed store
US10015082B2 (en) Providing non-interrupt failover using a link aggregation mechanism
US11277313B2 (en) Data transmission method and corresponding device
US11398956B2 (en) Multi-Edge EtherChannel (MEEC) creation and management
EP3780552B1 (en) Message processing method in distributed device and distributed device
US20210160181A1 (en) Architecture for a network visibility system
JP6384696B2 (ja) 転送テーブル同期方法、ネットワークデバイスおよびシステム
US20140153577A1 (en) Session-based forwarding
CN111263373B (zh) 数据处理方法、控制器和转发设备
EP3038297B1 (en) Method, system, and device for packet processing
US20220060881A1 (en) Group management method, apparatus, and system
US20150263862A1 (en) Communication system, control apparatus, communication control method, transfer control method, and transfer control program
WO2018161632A1 (zh) 分布式设备的容量更新方法及装置
US11750496B2 (en) Method for multi-cloud interconnection and device
CN110708275B (zh) 一种协议报文的处理方法和装置
US11621915B2 (en) Packet forwarding method, route sending and receiving method, and apparatus
JP6445408B2 (ja) 通信システムおよび設定方法
WO2020181733A1 (zh) 一种基于vpc的多数据中心互通方法及相关设备
US20230035984A1 (en) Mechanism to enforce consistent next hops in a multi-tier network
US20220337503A1 (en) Identifying zero redundancy paths and affected endpoints in a software defined network
WO2023124663A1 (zh) 一种集群仲裁方法、网络设备及系统
CN113545130B (zh) 利用分布式散列的无线客户端的快速漫游和统一策略
EP4184822A1 (en) Method and apparatus for keeping user terminal alive
WO2022001537A1 (zh) 网络拓扑发现方法、装置和计算机可读存储介质

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 17899916

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 17899916

Country of ref document: EP

Kind code of ref document: A1