Network device management method and apparatus

Abstract

The application provides a network device management method and device, the method comprises: receiving a first notification message sent by a second controller in a controller cluster, the first notification message comprising a message type and a device identifier of a network device to be managed; establishing a switching distributed lock according to the message type; releasing the switching distributed lock after a NETCONF session with the network device indicated by the device identifier is established, and determining whether a connection distributed lock is obtained; if the connection distributed lock is obtained, the network device is managed; wherein the first controller is a controller newly added to the controller cluster, or a controller already in the controller cluster, and the second controller is a master controller in the controller cluster.

Description

Technical Field

[0001] This application relates to the field of communication technology, and in particular to a network device management method and apparatus. Background Technology

[0002] With the rapid development of cloud computing and virtualization technologies, traditional networks, which rely on manual deployment, are inefficient and costly, failing to meet the demands of current business growth. Software-Defined Networking (SDN) controllers, through a centralized control approach, enable administrators to quickly automate the deployment of services across various network devices, significantly shortening the deployment cycle. Simultaneously, they allow for dynamic adjustments to adapt to changing business needs.

[0003] To achieve rapid data forwarding, SDN controllers are typically high-performance switches or firewalls, and they use the Network Configuration Protocol (NETCONF) to automate the management and configuration of managed network devices. As the number of network devices in an SDN network continues to increase, effectively and reliably managing this growing number of devices presents a greater challenge to SDN controllers.

[0004] like Figure 1 As shown, Figure 1 This is a schematic diagram of an existing SDN controller cluster. Figure 1 In this architecture, the SDN controller cluster employs a primary-secondary architecture to achieve high availability. The primary controller provides a Representational State Transfer (REST) ​​application programming interface (API) to interface with the management platform or OpenStack (cloud platform). The secondary controllers act as backups to the primary controller, quickly switching over to become the primary controller in case of primary controller failure, thus ensuring high service availability.

[0005] like Figure 2 As shown, Figure 2 This is a diagram illustrating the primary and backup configurations of an existing OpenFlow instance. Figure 2 In this architecture, the SDN controller leverages the master / slave functionality of OpenFlow instances to manage the reliability of network devices. Each network device is configured with an OpenFlow instance, which can connect to multiple controllers simultaneously. These controllers have two roles: master and slave.

[0006] The controller's role is configured during device initialization. If the primary controller fails, the backup controller is elected as the new primary controller. The primary controller can establish NETCONF sessions with network devices, and subsequent service configurations are based on these established NETCONF sessions. If the primary controller subsequently fails, causing a role switch, the controller will automatically switch the NETCONF session accordingly.

[0007] However, the aforementioned method of managing network devices using the primary / standby functionality based on OpenFlow instances also exposes the following drawbacks: 1) As the number of network devices increases, it cannot be guaranteed that the load will be evenly distributed across different controllers. In extreme cases, one controller may become the primary controller for all network devices. This will quickly exhaust the primary controller's resources, triggering service anomalies and affecting the availability and reliability of the entire controller cluster; 2) When adding a controller to the controller cluster, the OpenFlow instance configuration of all network devices needs to be updated. If the added controller is designated as a standby controller for a network device, the existing roles remain unchanged and continue to run, but this cannot solve the potential problem of uneven distribution of primary controller resources. If the added controller is the primary controller for some network devices, this can solve the problem of uneven distribution of primary controller resources, but it may lead to the reconstruction of existing NETCONF sessions, affecting service availability. Summary of the Invention

[0008] In view of this, this application provides a network device management method and apparatus to solve the problems in the existing method where, when the number of network devices increases, it is impossible to guarantee that the network devices are evenly distributed to different controllers, and when the number of controllers increases, existing NETCONF sessions need to be rebuilt, affecting the availability of services.

[0009] In a first aspect, this application provides a network device management method, the method being applied to a first controller, the method comprising:

[0010] Receive a first notification message sent by the second controller in the controller cluster. The first notification message includes a message type and the device identifier of the network device to be managed.

[0011] Establish a switching distributed lock based on the message type;

[0012] After establishing a NETCONF session with the network device indicated by the device identifier, release the switching distributed lock and determine whether the connection distributed lock has been acquired.

[0013] If obtained, the network device will be brought under management;

[0014] Wherein, the first controller is a controller newly added to the controller cluster, or a controller already in the controller cluster, and the second controller is the master controller in the controller cluster.

[0015] Secondly, this application provides a network device management method, the method being applied to a first controller, the method comprising:

[0016] When a second controller is added to the controller cluster, the status attributes of the other controllers in the controller cluster, excluding the second controller, are obtained.

[0017] Based on the status attributes of the other controllers, determine whether to smoothly switch some network devices managed by the other controllers to be managed by the second controller;

[0018] If so, then select a third controller from the other controllers;

[0019] Different first notification messages are sent to the second controller and the third controller respectively, so that the second controller and the third controller can switch the network device under management according to the received first notification messages;

[0020] The first controller is the main controller within the controller cluster.

[0021] Thirdly, this application provides a network device management apparatus, which is applied to a first controller and includes:

[0022] The receiving unit is configured to receive a first notification message sent by the second controller within the controller cluster. The first notification message includes a message type and a device identifier of the network device to be managed.

[0023] A setup unit is used to establish a switching distributed lock based on the message type;

[0024] The release unit is used to release the switching distributed lock and determine whether the connection distributed lock has been acquired after the establishment of a NETCONF session with the network device indicated by the device identifier is completed.

[0025] The management unit is used to manage the network device if it is acquired.

[0026] Wherein, the first controller is a controller newly added to the controller cluster, or a controller already in the controller cluster, and the second controller is the master controller in the controller cluster.

[0027] Fourthly, this application provides a network device management apparatus, which is applied to a first controller, and the apparatus includes:

[0028] The acquisition unit is used to acquire the status attributes of other controllers in the controller cluster besides the second controller when a second controller is added to the controller cluster.

[0029] The determining unit is configured to determine, based on the status attributes of the other controllers, whether to smoothly switch some network devices managed by the other controllers to be managed by the second controller;

[0030] The selection unit is used to select a third controller from the other controllers if the condition is met.

[0031] The sending unit is configured to send different first notification messages to the second controller and the third controller respectively, so that the second controller and the third controller can switch the network device under management according to the received first notification messages;

[0032] The first controller is the main controller within the controller cluster.

[0033] Fifthly, this application provides a network device including a processor and a machine-readable storage medium storing machine-executable instructions that can be executed by the processor, which in turn cause the processor to perform the method provided in the first aspect of this application.

[0034] In a sixth aspect, this application provides a network device including a processor and a machine-readable storage medium storing machine-executable instructions that can be executed by the processor, which in turn cause the processor to perform the method provided in the second aspect of this application.

[0035] Therefore, using the network device management method and apparatus provided in this application, the first controller receives a first notification message sent by the second controller in the controller cluster. The first notification message includes a message type and a device identifier of the network device to be managed. According to the message type, the first controller establishes a switching distributed lock. After completing the establishment of a NETCONF session with the network device indicated by the device identifier, the first controller releases the switching distributed lock and determines whether it has acquired a connection distributed lock. If it has acquired a connection distributed lock, the first controller manages the network device. Here, the first controller is either a controller newly added to the controller cluster or a controller already in the controller cluster, and the second controller is the master controller in the controller cluster.

[0036] This improves the reliability management capabilities of controllers within the controller cluster for network devices, supports dynamic expansion of the number of controllers within the cluster, and enables load balancing without impacting services. It resolves the issues in existing methods where increasing the number of network devices fails to guarantee even load distribution across different controllers, and where increasing the number of controllers leads to the reconstruction of existing NETCONF sessions, impacting service availability. Attached Figure Description

[0037] Figure 1 A schematic diagram of an existing SDN controller cluster;

[0038] Figure 2 This is a diagram illustrating the primary and backup configurations of an existing OpenFlow instance.

[0039] Figure 3 A flowchart illustrating a network device management method provided in this application embodiment;

[0040] Figure 4 A flowchart illustrating another network device management method provided in this application embodiment;

[0041] Figure 5 A structural diagram of a network device management device provided in an embodiment of this application;

[0042] Figure 6 Another network device management device structure diagram provided in the embodiments of this application;

[0043] Figure 7 The network device hardware structure provided in the embodiments of this application. Detailed Implementation

[0044] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numerals in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0045] The terminology used in this application is for the purpose of describing particular embodiments only and is not intended to be limiting of the application. The singular forms “a,” “the,” and “the” used in this application and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used herein refers to and includes any or all possible combinations of one or more of the corresponding listed items.

[0046] It should be understood that although the terms first, second, third, etc., may be used in this application to describe various information, such information should not be limited to these terms. These terms are only used to distinguish information of the same type from one another. For example, without departing from the scope of this application, first information may also be referred to as second information, and similarly, second information may also be referred to as first information. Depending on the context, the word "if" as used herein may be interpreted as "when," "when," or "in response to determination."

[0047] The following is a detailed description of a network device management method provided in an embodiment of this application. See also... Figure 3 , Figure 3 This is a flowchart illustrating a network device management method provided in an embodiment of this application. The method is applied to a first controller. The network device management method provided in this application embodiment may include the following steps.

[0048] Step 310: Receive a first notification message sent by the second controller in the controller cluster. The first notification message includes a message type and the device identifier of the network device to be managed.

[0049] Specifically, the first controller is located within a controller cluster, which already includes multiple controllers. The second controller is the master controller within the controller cluster, and all other controllers are backup controllers. The first controller can be a newly added controller to the controller cluster, or it can be a controller that was already in the controller cluster.

[0050] When the second controller determines that a smooth handover of management authority between controllers is required, the second controller generates and sends a first notification message to the first controller. This first notification message includes the message type and the device identifier of the network device to be managed.

[0051] The first controller can also be referred to as the recipient of management rights. The message type specifically refers to the first notification message being a smooth handover notification. The network device's device identifier specifically refers to the unique ID of the network device.

[0052] The first controller receives the first notification message and obtains the message type and the device identifier of the network device from it.

[0053] In this embodiment, management authority refers to the actual control exercised by the controller over network devices. The second controller determines that a smooth handover of management authority between controllers is necessary in several scenarios.

[0054] In one scenario, when a controller cluster expands its capacity, the second controller determines which network devices will be managed by the newly added controller based on the status attributes of the controllers currently in the cluster, in order to achieve load balancing. For example, if the first controller is a newly added controller, the second controller can determine whether to smoothly switch the network devices managed by the other controllers to be managed by the first controller based on the status attributes of the other controllers in the current cluster, thereby reducing the workload of the other controllers.

[0055] In another scenario, a controller automatically reports to a second controller for load balancing. For example, if the number of network devices managed by a controller exceeds a threshold (e.g., a threshold of 5000, which is half the number of online network devices in the SDN network) or if the current state of a controller does not meet operational requirements, the controller reports this to the second controller. The second controller can then determine, based on the status attributes of other controllers in the current controller cluster, whether to smoothly switch the network devices managed by that controller to other controllers, thereby reducing the workload of that controller.

[0056] Step 320: Establish a switching distributed lock based on the message type;

[0057] Specifically, according to the description of step 310, after the first controller obtains the message type and the device identifier of the network device, it determines that the first notification message is a smooth handover notification based on the message type; based on the device identifier, it also determines that the network device indicated by the device identifier is not managed by itself. Therefore, the first controller determines that the second controller has initiated a smooth handover and intends to bring the network device indicated by the device identifier under the management of the first controller.

[0058] Based on the message type, the first controller establishes a switching distributed lock.

[0059] Furthermore, the controller cluster includes an application module that provides distributed lock functionality and acquisition methods. Controllers can acquire distributed locks by calling the interfaces provided by the application module, or upload created distributed locks and related data to the application module for other controllers to access. The distributed lock is a globally visible variable, visible and accessible to all controllers within the cluster.

[0060] The first controller establishes a distributed lock switching mechanism and calls the application module's interface. The first controller then uploads the switched distributed lock and related data to the application module. Simultaneously, the application module locally records the lock creation, acquisition, and release processes.

[0061] Step 330: After establishing a NETCONF session with the network device indicated by the device identifier, release the switching distributed lock and determine whether the connection distributed lock has been acquired.

[0062] Specifically, according to the description of step 320, after the first controller establishes the switching distributed lock, it establishes a NETCONF session with the network device indicated by the device identifier. After the first controller and the network device complete the establishment of the NETCONF session, the first controller releases the switching distributed lock and determines whether it has acquired the connection distributed lock.

[0063] Understandably, the first controller calls the application module's interface again, requesting the release of the switching distributed lock. The application module responds to this request, records the release process, and updates the occupancy record of the switching distributed lock. Simultaneously, the first controller also requests to acquire the connection distributed lock. If the connection distributed lock is not currently held by another controller, the first controller can acquire it, indicating that it can manage network devices. The application module records the first controller's acquisition process and updates the occupancy record of the connection distributed lock.

[0064] It should be noted that, in this embodiment, the first controller can periodically acquire and switch the distributed lock. The switching distributed lock can also be used to indicate whether a NETCONF session has been successfully established. The controller can only perform service configuration processing on the network device after successfully establishing a NETCONF session with the network device.

[0065] Step 340: If obtained, the network device is then managed.

[0066] Specifically, according to the judgment in step 330, if the first controller acquires the connection distributed lock and has completed the establishment of a NETCONF session with the network device, the first controller will manage the network device.

[0067] Optionally, if the first controller fails to acquire the connection distributed lock, the first controller will try to acquire the connection distributed lock again and continue to determine whether the connection distributed lock has been acquired.

[0068] Therefore, using the network device management method and apparatus provided in this application, the first controller receives a first notification message sent by the second controller in the controller cluster. The first notification message includes a message type and a device identifier of the network device to be managed. According to the message type, the first controller establishes a switching distributed lock. After completing the establishment of a NETCONF session with the network device indicated by the device identifier, the first controller releases the switching distributed lock and determines whether it has acquired a connection distributed lock. If it has acquired a connection distributed lock, the first controller manages the network device. Here, the first controller is either a controller newly added to the controller cluster or a controller already in the controller cluster, and the second controller is the master controller in the controller cluster.

[0069] This improves the reliability management capabilities of controllers within the controller cluster for network devices, supports dynamic expansion of the number of controllers within the cluster, and enables load balancing without impacting services. It resolves the issues in existing methods where increasing the number of network devices fails to guarantee even load distribution across different controllers, and where increasing the number of controllers leads to the reconstruction of existing NETCONF sessions, impacting service availability.

[0070] Optionally, in the foregoing embodiments, the first controller is described as the recipient of the management right. In the embodiments of this application, the first controller can also act as the outputter of the management right, receiving the second notification message.

[0071] Specifically, when the second controller determines that a smooth switch of management rights between controllers is required, the second controller can first select some network devices from all network devices already managed by the first controller, and smoothly switch the management rights of some network devices to other controllers in order to balance the load between controllers.

[0072] The second controller generates and sends a second notification message to the first controller. This second notification message includes the message type and the device identifier of the network device managed by the first controller.

[0073] The first controller can also be referred to as the control authority outputter. The message type specifically refers to the second notification message being a smooth handover notification. The network device's device identifier specifically refers to the network device's unique ID.

[0074] The first controller receives the second notification message and obtains the message type and the device identifier of the network device from it.

[0075] Based on the message type, the first controller determines that the second notification message is a smooth handover notification; based on the device identifier, it also determines that the network device indicated by the device identifier has been managed by it. Therefore, the first controller determines that the second controller has initiated a smooth handover and intends to transfer the management rights of the network device indicated by the device identifier to another controller for management.

[0076] Based on the message type, the first controller determines whether it has acquired the switching distributed lock. The first controller calls the application module's interface to periodically request to acquire the switching distributed lock. If the switching distributed lock is not currently held by another controller, the first controller can acquire the switching distributed lock, indicating that the recipient of the management right has acquired the management capability. The application module records the first controller's acquisition process.

[0077] If the first controller acquires the switching distributed lock, it calls the application module's interface to request the release of the connection distributed lock. The application module responds to this request, records the release process, and updates the connection distributed lock's occupancy record. After releasing the connection distributed lock, the first controller indicates that it has relinquished its control over the network device.

[0078] The first controller closes the NETCONF session established with the network device indicated by the device identifier. The first controller calls the application module's interface to request the release of the switching distributed lock. The application module responds to the request, records the release process, and updates the holding record of the switching distributed lock.

[0079] It should be noted that before receiving the second notification message, the first controller still needs to continue processing the existing tasks of all network devices currently under its management or the new tasks added during the smooth handover process.

[0080] If the first controller fails to acquire the switching distributed lock, it will attempt to acquire the connection distributed lock again and continue to determine whether it has acquired the connection distributed lock.

[0081] Optionally, in this embodiment of the application, the process of the first controller requesting load balancing from the second controller is also included.

[0082] Specifically, in one scenario, the first controller identifies the number of network devices it manages. If the number of network devices managed by the first controller exceeds a threshold (e.g., a threshold of 5000), the first controller determines that it is overloaded. The first controller then generates and sends a third notification message to the second controller.

[0083] In another scenario, when the first controller detects an anomaly or malfunction that makes it unsuitable to manage network devices, i.e., when the current state of the first controller does not meet the requirements for operation, the first controller generates and sends a third notification message to the second controller.

[0084] The aforementioned third notification message includes a message type and the device identifier of the network device managed by the first controller. Specifically, the message type refers to a notification of transfer of management rights. The device identifier of the network device can be the device identifier of some network devices managed by the first controller.

[0085] Understandably, if the first controller determines that its own load is too high or that the current state of the first controller does not meet the working requirements, the first controller may select some network devices from all the network devices under its management and request the second controller to transfer the management rights of the selected network devices.

[0086] After receiving the third notification message, the second controller obtains the message type and the device identifier of the network device from it. Based on the message type, the second controller determines that the third notification message is a notification of transfer of management authority, and determines that the first controller is currently overloaded or its current state does not meet the operating requirements.

[0087] Depending on the message type, the second controller can obtain status attributes of other controllers, including but not limited to the number of managed network devices, CPU and memory usage, etc. Based on these status attributes, the second controller selects a controller with a smaller number of managed devices (e.g., 100 devices) and lower CPU and memory usage (e.g., 20%) as the third controller.

[0088] After the second controller selects the third controller, it generates two fourth notification messages and sends them to the first controller and the third controller, respectively. The fourth notification message sent from the second controller to the first controller can be the same as the aforementioned second notification message, and the fourth notification message sent from the second controller to the third controller can be the same as the aforementioned first notification message.

[0089] The first controller and the third controller perform the management switching of the network devices indicated by the device identifier based on the received fourth notification message. The switching process performed by the third controller can be specifically referred to as steps 310-340 above, and the switching process performed by the first controller can be specifically referred to as the process of receiving the second notification message above, and will not be repeated here.

[0090] Optionally, in this embodiment of the application, the process of the second controller selecting a management controller for a newly added network device after the new network device is added to the SDN network is also included.

[0091] Specifically, when a new network device is added to the SDN network, the second controller obtains the number of NETCONF sessions for each controller in the controller cluster. The second controller selects the first controller with the smallest number of NETCONF sessions as the controller that manages the network device.

[0092] The second controller generates and sends a fourth notification message to the first controller. This fourth notification includes the message type and the device identifier of the newly added network device in the SDN network. Specifically, the message type refers to the fourth notification message being a notification of establishment of management rights.

[0093] Based on the message type, the first controller determines that the fourth notification message is a notification to establish management rights. Based on the device identifier, it also determines that the network device indicated by the device identifier is not managed by itself. Therefore, the first controller determines that the second controller has initiated the establishment of management rights and intends to have the network device indicated by the device identifier managed by the first controller.

[0094] Based on the message type, the first controller acquires the connection distributed lock. The first controller calls the application module's interface to request the connection distributed lock. If the connection distributed lock is not currently held by another controller, the first controller can acquire it, and the application module records the first controller's acquisition process.

[0095] Based on the device identifier, the first controller establishes a NETCONF session with the network device. If the first controller acquires the connection distributed lock and has completed the establishment of the NETCONF session with the network device, the first controller will manage the network device.

[0096] The following describes in detail another network device management method provided in the embodiments of this application. See also Figure 4 , Figure 4 A flowchart illustrating another network device management method provided in this application embodiment. The method is applied to a first controller. The network device management method provided in this application embodiment may include the following steps.

[0097] Step 410: When a second controller is added to the controller cluster, obtain the status attributes of the other controllers in the controller cluster besides the second controller;

[0098] Specifically, the first controller is located within a controller cluster, which already includes multiple controllers. The first controller is the master controller within the cluster, and all other controllers are backup controllers. The second controller can be a newly added controller to the cluster.

[0099] After the second controller is added to the controller cluster, its load is 0 because it is a newly added controller. At this time, the first controller can smoothly switch the network devices managed by other controllers in the controller cluster to the second controller for management, so as to balance the load of each controller.

[0100] To ensure a smooth handover of management authority, the first controller first obtains the status attributes of the other controllers in the controller cluster, excluding the second controller. These status attributes include, but are not limited to, the number of managed network devices, CPU and memory usage, etc.

[0101] Step 420: Based on the status attributes of the other controllers, determine whether to smoothly switch some network devices managed by the other controllers to be managed by the second controller;

[0102] Specifically, according to the description of step 410, after the first controller obtains the status attributes of other controllers, it determines whether to smoothly switch some network devices managed by other controllers to be managed by the second controller based on the status attributes.

[0103] For example, if the number of network devices currently under the load of other controllers exceeds a number threshold (e.g., the number threshold is 5000), or if the current CPU memory utilization of other controllers exceeds a usage threshold (e.g., the usage threshold is 70%), the first controller determines to smoothly switch some network devices managed by other controllers to be managed by the second controller and executes step 430.

[0104] Optionally, if the number of other network devices controlling the current load does not exceed the quantity threshold, or the current CPU memory utilization of other controllers does not exceed the utilization threshold, the first controller may not perform a smooth switch. However, since the number of network devices currently under the load of the second controller is 0, the first controller may also select several network devices from other controllers for smooth switching to further balance the load.

[0105] Step 430: If yes, then select a third controller from the other controllers;

[0106] Specifically, according to the description of step 420, if the first controller determines to smoothly switch some network devices managed by other controllers to be managed by the second controller, the first controller selects a third controller from the other controllers. The number of selected third controllers can be one or more.

[0107] In one example, the first controller selects the controller with the maximum number of managed network devices (e.g., 9000) or the maximum CPU memory utilization (e.g., 90%) as the third controller. That is, the third controller is the one with the largest number of managed devices or the highest CPU memory utilization.

[0108] In another example, the first controller selects multiple controllers as the third controller if the number of managed network devices exceeds a quantity threshold or the CPU memory usage exceeds a usage threshold.

[0109] Step 440: Send different first notification messages to the second controller and the third controller respectively, so that the second controller and the third controller can switch the network device under management according to the received first notification messages.

[0110] Specifically, according to the description in step 430, after the first controller selects the third controller, it generates multiple first notification messages. The first controller sends different first notification messages to the second controller and the third controller respectively. The first notification message sent by the first controller to the second controller may be the same as the first notification message involved in step 310 of the previous embodiment, and the first notification message sent by the first controller to the third controller may be the same as the second notification message in the previous embodiment.

[0111] Upon receiving the first notification message, the second and third controllers respectively perform a management switch for the network devices. Specifically, the second and third controllers perform the management switch based on the received first notification message. The switching process performed by the second controller can be specifically referred to steps 310-340 in the previous embodiment, and the switching process performed by the third controller can be specifically referred to the process of the first controller receiving the second notification message in the previous embodiment; therefore, it will not be repeated here.

[0112] Therefore, using the network device management method provided in this application, when a second controller is added to the controller cluster, the first controller obtains the status attributes of the other controllers in the controller cluster besides the second controller; based on the status attributes of the other controllers, the first controller determines whether to smoothly switch some network devices managed by the other controllers to be managed by the second controller; if so, the first controller selects a third controller from the other controllers; the first controller sends different first notification messages to the second controller and the third controller respectively, so that the second controller and the third controller can switch the management of network devices according to the received first notification messages; wherein, the first controller is the master controller in the controller cluster.

[0113] This improves the reliability management capabilities of controllers within the controller cluster for network devices, supports dynamic expansion of the number of controllers within the cluster, and enables load balancing without impacting services. It resolves the issues in existing methods where increasing the number of network devices fails to guarantee even load distribution across different controllers, and where increasing the number of controllers leads to the reconstruction of existing NETCONF sessions, impacting service availability.

[0114] Optionally, in this embodiment of the application, the process of the first controller selecting a management controller for a newly added network device after the new network device is added to the SDN network is also included.

[0115] Specifically, when a new network device is added to the SDN network, the first controller obtains the number of NETCONF sessions for each controller in the controller cluster. The first controller then selects the fourth controller with the smallest number of NETCONF sessions as the controller that manages the network device.

[0116] The first controller generates and sends a second notification message to the fourth controller. This second notification includes a message type and the device identifier of the newly added network device within the SDN network. Specifically, the message type refers to the second notification message being a notification of establishment of management rights.

[0117] Based on the message type, the fourth controller determines that the second notification message is a notification to establish management rights. Based on the device identifier, it also determines that the network device indicated by the device identifier is not managed by itself. Therefore, the fourth controller determines that the first controller initiated the establishment of management rights and intends to manage the network device indicated by the device identifier through the fourth controller.

[0118] Based on the message type, the fourth controller acquires the connection distributed lock. The fourth controller calls the application module's interface to request the connection distributed lock. If the connection distributed lock is not currently held by another controller, the fourth controller can acquire it, and the application module records the fourth controller's acquisition process.

[0119] Based on the device identifier, the fourth controller establishes a NETCONF session with the network device. If the fourth controller acquires the connection distributed lock and has completed the NETCONF session with the network device, the fourth controller will manage the network device.

[0120] Optionally, in this embodiment of the application, the process of the fifth controller sending a third notification message to the first controller to request load balancing on its own is also included.

[0121] Specifically, in one scenario, the fifth controller identifies the number of network devices it manages. If the number of network devices managed by the fifth controller exceeds a certain threshold, the fifth controller determines that it is overloaded. The fifth controller then generates and sends a third notification message to the first controller.

[0122] In another scenario, when the fifth controller detects an anomaly or malfunction that makes it unsuitable to manage network devices, i.e., when the current state of the fifth controller does not meet the requirements for operation, the fifth controller generates and sends a third notification message to the first controller.

[0123] The aforementioned third notification message includes a message type and the device identifier of the network device managed by the fifth controller. Specifically, the message type refers to a notification of transfer of management rights. The device identifier can be the identifier of some network devices managed by the fifth controller.

[0124] Understandably, if the fifth controller determines that its own load is too high or that the current state of the fifth controller does not meet the working requirements, the fifth controller may select some network devices from all the network devices under its management and request the first controller to transfer the management rights of the selected network devices.

[0125] After receiving the third notification message, the first controller obtains the message type and the device identifier of the network device from it. Based on the message type, the first controller determines that the third notification message is a notification of transfer of management authority, and determines that the fifth controller is currently overloaded or its current state does not meet the operating requirements.

[0126] Based on the message type, the first controller can obtain the status attributes of other controllers, including but not limited to the number of managed network devices, CPU and memory usage, etc. Using these status attributes, the first controller selects a controller with a smaller number of managed devices and lower CPU and memory usage as the sixth controller.

[0127] After the first controller selects the sixth controller, it generates two fourth notification messages and sends them to the fifth and sixth controllers respectively. The fourth notification message sent by the first controller to the fifth controller can be the same as the second notification message in the previous embodiment, and the fourth notification message sent by the first controller to the sixth controller can be the same as the first notification message involved in step 310 of the previous embodiment.

[0128] The fifth and sixth controllers switch the network devices identified by the device identifiers according to the received fourth notification message. The switching process performed by the sixth controller can be referred to in steps 310-340 above, and the switching process performed by the fifth controller can be referred to in the process of receiving the second notification message above, and will not be repeated here.

[0129] Based on the same inventive concept, embodiments of this application also provide a network device management apparatus corresponding to the network device management method. See also Figure 5 , Figure 5 A network device management apparatus is provided in an embodiment of this application. The apparatus is applied to a first controller and includes:

[0130] The receiving unit 510 is configured to receive a first notification message sent by the second controller in the controller cluster, wherein the first notification message includes a message type and a device identifier of the network device to be managed.

[0131] Establishment unit 520 is used to establish a switching distributed lock according to the message type;

[0132] Release unit 530 is used to release the switching distributed lock and determine whether the connection distributed lock has been acquired after the establishment of a NETCONF session with the network device indicated by the device identifier is completed.

[0133] The management unit 540 is used to manage the network device if it is acquired.

[0134] Wherein, the first controller is a controller newly added to the controller cluster, or a controller already in the controller cluster, and the second controller is the master controller in the controller cluster.

[0135] Optionally, the release unit 530 is further configured to, if not acquired, continue to determine whether the connection distributed lock has been acquired.

[0136] Optionally, the receiving unit 510 is further configured to receive a second notification message sent by the second controller, the second notification message including a message type and a device identifier of the network device managed by the first controller;

[0137] The device further includes: a judgment unit (not shown in the figure), used to determine whether the switching distributed lock has been acquired based on the message type;

[0138] The release unit 530 is further configured to, if acquired, release the connection distributed lock and close the NETCONF session established with the network device indicated by the device identifier;

[0139] The release unit 530 is also used to release the switching distributed lock.

[0140] Optionally, the apparatus further includes: a sending unit (not shown in the figure), configured to send a third notification message to the second controller when the number of network devices managed by the first controller exceeds a quantity threshold or the current state of the first controller does not meet the working state. The third notification message includes a message type and a device identifier of the network device managed by the first controller, so that the second controller selects a third controller from other controllers in the controller cluster other than the first controller according to the message type, and sends different fourth notification messages to the first controller and the third controller respectively. The first controller and the third controller switch the management of the network device indicated by the device identifier according to the received fourth notification message.

[0141] Optionally, the receiving unit 510 is further configured to receive a fourth notification message sent by the second controller when the first controller is already in the controller cluster. The fourth notification includes a message type and a device identifier of a newly added network device in the SDN network.

[0142] The device further includes: an acquisition unit (not shown in the figure), used to acquire the connection distributed lock according to the message type;

[0143] An establishment unit (not shown in the figure) is used to establish a NETCONF session with the network device based on the device identifier.

[0144] Therefore, using the network device management device provided in this application, the first controller receives a first notification message sent by the second controller in the controller cluster. The first notification message includes a message type and a device identifier of the network device to be managed. According to the message type, the first controller establishes a switching distributed lock. After completing the establishment of a NETCONF session with the network device indicated by the device identifier, the first controller releases the switching distributed lock and determines whether it has acquired a connection distributed lock. If it has acquired a connection distributed lock, the first controller manages the network device. Here, the first controller is either a controller newly added to the controller cluster or a controller already in the controller cluster, and the second controller is the master controller in the controller cluster.

[0145] This improves the reliability management capabilities of controllers within the controller cluster for network devices, supports dynamic expansion of the number of controllers within the cluster, and enables load balancing without impacting services. It resolves the issues in existing methods where increasing the number of network devices fails to guarantee even load distribution across different controllers, and where increasing the number of controllers leads to the reconstruction of existing NETCONF sessions, impacting service availability.

[0146] Based on the same inventive concept, embodiments of this application also provide a network device management apparatus corresponding to the network device management method. See also Figure 6 , Figure 6 Another network device management apparatus provided in this application embodiment, the apparatus being applied to a first controller, the apparatus comprising:

[0147] The acquisition unit 610 is used to acquire the status attributes of other controllers in the controller cluster besides the second controller when a second controller is added to the controller cluster.

[0148] The determining unit 620 is used to determine, based on the status attributes of the other controllers, whether to smoothly switch some network devices managed by the other controllers to be managed by the second controller;

[0149] Selection unit 630 is used to select a third controller from the other controllers if the condition is met;

[0150] The sending unit 640 is used to send different first notification messages to the second controller and the third controller respectively, so that the second controller and the third controller can switch the network device under management according to the received first notification message;

[0151] The first controller is the main controller within the controller cluster.

[0152] Optionally, the acquisition unit 610 is further configured to acquire the number of NETCONF sessions for each controller in the controller cluster when a new network device is added to the SDN network;

[0153] The device further includes: an execution unit (not shown in the figure), used to select the fourth controller with the smallest number of NETCONF sessions as the controller that manages the network device;

[0154] The sending unit 640 is further configured to send a second notification message to the fourth controller. The second notification message includes a message type and a device identifier of a newly added network device in the SDN network, so that the fourth controller acquires a connection distributed lock according to the message type and establishes a NETCONF session with the network device according to the device identifier.

[0155] Optionally, the device further includes: a receiving unit (not shown in the figure), configured to receive a third notification message sent by a fifth controller within the controller cluster, the third notification message including a message type and a device identifier of the network device managed by the fifth controller;

[0156] The acquisition unit 610 is further configured to acquire the status attributes of other controllers in the controller cluster, excluding the fifth controller, according to the message type.

[0157] The device further includes: a selection unit (not shown in the figure), used to select a sixth controller from the other controllers based on the status attributes of the other controllers;

[0158] The sending unit 640 is further configured to send different fourth notification messages to the fifth controller and the sixth controller respectively, so that the fifth controller and the sixth controller can switch the network device under their management according to the received fourth notification messages.

[0159] Therefore, using the network device management device provided in this application, when a second controller is added to the controller cluster, the first controller obtains the status attributes of the other controllers in the controller cluster besides the second controller; based on the status attributes of the other controllers, the first controller determines whether to smoothly switch some network devices managed by the other controllers to be managed by the second controller; if so, the first controller selects a third controller from the other controllers; the first controller sends different first notification messages to the second controller and the third controller respectively, so that the second controller and the third controller can switch the management of network devices according to the received first notification messages; wherein, the first controller is the master controller in the controller cluster.

[0160] This improves the reliability management capabilities of controllers within the controller cluster for network devices, supports dynamic expansion of the number of controllers within the cluster, and enables load balancing without impacting services. It resolves the issues in existing methods where increasing the number of network devices fails to guarantee even load distribution across different controllers, and where increasing the number of controllers leads to the reconstruction of existing NETCONF sessions, impacting service availability.

[0161] Based on the same inventive concept, embodiments of this application also provide a network device, such as... Figure 7 As shown, the device includes a processor 710, a transceiver 720, and a machine-readable storage medium 730. The machine-readable storage medium 730 stores machine-executable instructions that can be executed by the processor 710. The processor 710 is prompted by the machine-executable instructions to execute the network device management method provided in the embodiments of this application. (The foregoing...) Figure 5 , Figure 6 The network device management device shown can adopt, for example, Figure 7 The hardware structure of the network device shown is implemented.

[0162] The aforementioned computer-readable storage medium 730 may include random access memory (RAM) or non-volatile memory (NVM), such as at least one disk storage device. Optionally, the computer-readable storage medium 730 may also be at least one storage device located remotely from the aforementioned processor 710.

[0163] The processor 710 mentioned above can be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc.; it can also be a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components.

[0164] In this embodiment of the application, the processor 710 reads the machine-executable instructions stored in the machine-readable storage medium 730, and is prompted by the machine-executable instructions to enable the processor 710 itself and the transceiver 720 to execute the network device management method described in the aforementioned embodiment of the application.

[0165] In addition, this application provides a machine-readable storage medium 730 that stores machine-executable instructions. When called and executed by the processor 710, the machine-executable instructions cause the processor 710 itself and the transceiver 720 to execute the network device management method described in the above-mentioned application.

[0166] The specific implementation process of the functions and roles of each unit in the above device can be found in the implementation process of the corresponding steps in the above method, and will not be repeated here.

[0167] For the device embodiments, since they basically correspond to the method embodiments, the relevant parts can be referred to in the description of the method embodiments. The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this application according to actual needs. Those skilled in the art can understand and implement this without creative effort.

[0168] For the network device management device and machine-readable storage medium embodiments, since the methods involved are basically similar to those in the aforementioned method embodiments, the description is relatively simple, and relevant details can be found in the descriptions of the method embodiments.

[0169] The above description is merely a preferred embodiment of this application and is not intended to limit this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of protection of this application.

Claims

1. A network device management method, characterized in that, The method is applied to a first controller, and the method includes: Receive a first notification message sent by the second controller in the controller cluster. The first notification message includes the message type and the device identifier of the network device to be managed. Establish a switching distributed lock based on the message type; After establishing a NETCONF session with the network device indicated by the device identifier, release the switching distributed lock and determine whether the connection distributed lock has been acquired. If obtained, the network device will be brought under management; Wherein, the first controller is a controller newly added to the controller cluster, or a controller already in the controller cluster, and the second controller is the master controller in the controller cluster.

2. The method according to claim 1, characterized in that, The method further includes: Receive a second notification message sent by the second controller, the second notification message including a message type and a device identifier of the network device managed by the first controller; Based on the message type, determine whether the switching distributed lock has been acquired; If acquired, the connection distributed lock is released, and the NETCONF session established with the network device indicated by the device identifier is closed; Release the switched distributed lock.

3. The method according to any one of claims 1 or 2, characterized in that, The method further includes: If the connection distributed lock is not acquired, the process continues to determine whether the connection distributed lock can be acquired. If the switching distributed lock is not acquired, the process continues to determine whether the switching distributed lock can be acquired.

4. The method according to claim 1, characterized in that, The method further includes: When the number of network devices managed by the first controller exceeds the quantity threshold or the current state of the first controller does not meet the working state, a third notification message is sent to the second controller. The third notification message includes a message type and the device identifier of the network device managed by the first controller, so that the second controller selects a third controller from other controllers in the controller cluster other than the first controller according to the message type, and sends different fourth notification messages to the first controller and the third controller respectively. The first controller and the third controller switch the management of the network device indicated by the device identifier according to the received fourth notification message.

5. The method according to claim 1, characterized in that, The method further includes: When the first controller is already in the controller cluster, it receives a fourth notification message sent by the second controller. The fourth notification includes the message type and the device identifier of the newly added network device in the SDN network. Based on the message type, obtain the connection distributed lock; Establish a NETCONF session with the network device based on the device identifier.

6. A network device management method, characterized in that, The method is applied to a first controller, and the method includes: When a second controller is added to the controller cluster, the status attributes of the other controllers in the controller cluster, excluding the second controller, are obtained. Based on the status attributes of the other controllers, determine whether to smoothly switch some network devices managed by the other controllers to be managed by the second controller; If so, then select a third controller from the other controllers; Different first notification messages are sent to the second controller and the third controller respectively, so that the second controller and the third controller can switch the network device under management according to the received first notification messages; The first controller is the main controller within the controller cluster.

7. The method according to claim 6, characterized in that, The method further includes: When a new network device is added to the SDN network, the number of NETCONF sessions for each controller in the controller cluster is obtained; The fourth controller with the smallest number of NETCONF sessions is designated as the controller that manages the network devices. A second notification message is sent to the fourth controller. The second notification message includes a message type and a device identifier of the newly added network device in the SDN network, so that the fourth controller acquires a connection distributed lock according to the message type and establishes a NETCONF session with the network device according to the device identifier.

8. The method according to claim 6, characterized in that, The method further includes: Receive a third notification message sent by the fifth controller in the controller cluster. The third notification message includes a message type and a device identifier of the network device managed by the fifth controller. Based on the message type, obtain the status attributes of the other controllers in the controller cluster, excluding the fifth controller; Based on the state attributes of the other controllers, a sixth controller is selected from the other controllers; Different fourth notification messages are sent to the fifth controller and the sixth controller respectively, so that the fifth controller and the sixth controller can switch the network device under their management according to the received fourth notification messages.

9. A network device management device, characterized in that, The device is applied to a first controller, and the device includes: The receiving unit is used to receive a first notification message sent by the second controller in the controller cluster. The first notification message includes a message type and the device identifier of the network device to be managed. A setup unit is used to establish a switching distributed lock based on the message type; The release unit is used to release the switching distributed lock and determine whether the connection distributed lock has been acquired after the establishment of a NETCONF session with the network device indicated by the device identifier is completed. The management unit is used to manage the network device if it is acquired. Wherein, the first controller is a controller newly added to the controller cluster, or a controller already in the controller cluster, and the second controller is the master controller in the controller cluster.

10. A network device management device, characterized in that, The device is applied to a first controller, and the device includes: The acquisition unit is used to acquire the status attributes of other controllers in the controller cluster besides the second controller when a second controller is added to the controller cluster. The determining unit is configured to determine, based on the status attributes of the other controllers, whether to smoothly switch some network devices managed by the other controllers to be managed by the second controller; The selection unit is used to select a third controller from the other controllers if the condition is met. The sending unit is configured to send different first notification messages to the second controller and the third controller respectively, so that the second controller and the third controller can switch the network device under management according to the received first notification messages; The first controller is the main controller within the controller cluster.

Images