Network equipment management method and system

Abstract

The invention discloses a network equipment management method and system, which enable a network manager to flexibly schedule and execute tasks in a specified format in advance, and greatly enhance the accuracy and safety of command execution through a series of measures. According to the technical scheme, the system comprises a task arrangement module used for processing a network equipment operation command list input by a user or an external interface into a task list and issuing the task list to a scheduling execution module; the scheduling execution module is used for scheduling, dispatching, controlling and operating the tasks; the network adapter is used for adapting to various brands and series of equipment; the message queue is used for publishing and subscribing a specified type of message and establishing a communication channel between the scheduling execution module and the network adapter; the task state machine is used for maintaining a unified task state conversion rule and the execution state of each task; and the equipment lock is used for recording and maintaining lock states of all network equipment in the whole network area.

Description

Technical Field

[0001] The present invention relates to a device management method and system, and in particular to a command line-based network device management method and system. Background Art

[0002] With the rapid development of network technology, software-defined networks are becoming more and more popular and their market share is gradually increasing. However, the use of software-defined networks is usually accompanied by additional cost investment and uncontrollable operation and maintenance. Among them, the additional cost investment is usually caused by the high redundancy of the software-defined network architecture, the high bandwidth of the link, the high performance of the equipment, and the additional control nodes. The uncontrollable operation and maintenance is usually caused by factors such as the lack of maturity of software-defined networks, the opacity of network systems, and the complexity of usage logic. Therefore, for cost-sensitive, high-controllability network requirements, and simple demand scenarios, traditional network equipment is still the best choice and will inevitably occupy an important position in the future data center network for a long time.

[0003] However, the digital management of traditional network equipment has always been a difficult problem in the operation and maintenance management of various data centers. Technically, the development of network operation and maintenance automation technology has led to the emergence of protocols such as SNMP, NETCONF, and RESTCONF, which can realize the automated management of network equipment. However, in actual application, network engineers often do not choose to use these network operation and maintenance automation protocol technologies. Even after decades of development, their popularity is still low. The reason is that the CLI (command line) human-computer interaction experience required by network engineers is seriously mismatched with the experience of using system interaction protocols such as SNMP, NETCONF, and RESTCONF. Most network engineers cannot read system interaction protocols such as SNMP, NETCONF, and RESTCONF, and cannot perform operation and maintenance on these scenarios when abnormalities occur. Therefore, CLI human-computer interaction using protocols such as TELNET / SSH is still the best management method for network engineers.

[0004] In CLI interactive mode, network engineers usually use command lines to operate and manage devices. That is, they log in to network devices through protocols such as TELNET / SSH, enter network commands supported by the devices, and obtain corresponding echo information to view and configure network devices, check the status of network devices, and handle them based on operation and maintenance experience. This is basically a necessary skill for network engineers.

[0005] However, command-line device management has many problems:

[0006] 1. Limitation of the number of CLI sessions for network devices. For device management using command lines, users can usually log in to a network device once and then execute any number of commands within their authority. After all commands are completed, they can execute commands to exit the device. Logging in to a network device using protocols such as SSH will occupy the device's session resources, and the number of sessions for a network device is limited. If the number of sessions exceeds the limit, other users or devices will not be able to access the device. Therefore, the management of session resources is very important.

[0007] 2. Cross-influence between CLI operations: If there are multiple connections accessing the same device and modifying the network configuration of the same section, the configurations may be overwritten, affecting the normal operation of the device.

[0008] 3. Batch execution of command lines is insecure and inefficient. On the one hand, when using CLI interaction for batch execution, CLI will not interrupt for exceptions, so batch flushing will have certain risks. If you want to reduce the risk, you must execute in small batches, which will reduce efficiency. On the other hand, when users are interacting with CLI, they can only modify one device at a time. Even if there is no cross-influence between multiple devices, concurrent modification is not possible.

[0009] At the same time, with the development of network automation, network management software for commercial traditional network equipment has emerged in an endless stream, but it generally adopts a black box design approach, shielding the underlying operation process from users and only informing users of the execution results. When an abnormality occurs, it is difficult for professional network engineers to intervene, affecting the efficiency of handling. In this black box network management software, users manage devices by filling out forms on the page, clicking the mouse, etc., and the visibility of the device background output is not high. Without the experience and judgment of professional network engineers in the CLI command line mode, the process becomes less controllable and difficult to intervene, and the efficiency of handling abnormalities will also become low. Moreover, once the execution process takes a long time, it is easy for network operation and maintenance personnel to have anxiety and fear of unknown situations, and the experience will deteriorate.

[0010] As one of the most basic infrastructures in a data center, the operational security of network equipment is of vital importance. Usually, the login environment is strictly isolated and controlled. At the same time, in the data center networking architecture, the number of network devices is large and complex, and there is an urgent need to use automated means for unified management. Summary of the invention

[0011] A brief summary of one or more aspects is given below to provide a basic understanding of these aspects. This summary is not an exhaustive overview of all conceived aspects, and is neither intended to identify the key or critical elements of all aspects nor to define the scope of any or all aspects. Its only purpose is to give some concepts of one or more aspects in a simplified form as a prelude to a more detailed description that will be given later.

[0012] The purpose of the present invention is to solve the above-mentioned problems and provide a network device management method and system, which is based on CLI human-computer interaction and takes into account the traditional network device management system with device session number limitation, cross-influence between operations, batch execution security and transparent interaction process. It can effectively improve the efficiency and quality of traditional network operation and maintenance and improve the digital level of enterprise operation and maintenance.

[0013] The technical solution of the present invention is as follows: The present invention discloses a network device management system, the system includes a task scheduling module, a scheduling execution module, a network adapter, a task state machine, a device lock and a message queue, wherein:

[0014] The task scheduling module is used to process the network device operation command list input by the user or the external interface to form a network device operation task list that can be recognized and executed by the scheduling execution module, and the formed network device operation tasks are sent to the scheduling execution module for unified operation and execution;

[0015] The scheduling and execution module is used to schedule, assign, control and run the received network equipment operation tasks;

[0016] Network adapters are used to adapt to various brands and series of devices, including logging into network devices to execute commands and obtain command line output, abstracting commands by network device brand and series, and parsing command output text;

[0017] Message queue, used to publish and subscribe to messages of specified types and establish a communication channel between the scheduling execution module and the network adapter;

[0018] Task state machine, used to maintain unified task state transition rules and the execution status of each task;

[0019] Device lock is used to record and maintain the lock status of all network devices in the entire network area.

[0020] According to an embodiment of the network device management system of the present invention, the task scheduling module solidifies a configuration template, i.e., a baseline configuration, in advance for network device configuration scenarios that are frequently used by users, and uses identifiers to represent parameter placeholders; after receiving a network device operation task, the scheduling execution module first schedules the network device operation task according to the current time window and the scheduled execution time of the task, and at the same time applies for locks of all network devices involved in the network device operation task; after the task is successfully scheduled, the network device adapter is connected to create a device session, the contents of the subtasks are executed in sequence, the execution status of the network device operation task is controlled and managed, and the execution result and output content of the network device operation task are returned to the user side, wherein an asynchronous execution framework is adopted between the scheduling execution module and the network adapter.

[0021] The present invention also discloses a network device management method, which is run on the network device management system as described above, and the method comprises:

[0022] Step S1: Arrange and form a task list according to the instructions or command set input by the user or fill in parameters according to a predefined template;

[0023] Step S2: Schedule the task according to the task attributes, executable time window and task planned start time, and request to obtain the device locks of all network devices in the task;

[0024] Step S3: the scheduling execution module notifies the network adapter to establish a device session, and the notification information includes the login information of the network device;

[0025] Step S4: the network adapter establishes and maintains a session with the network device according to the instruction, and at the same time creates a command line topic in the message queue and subscribes to message updates in the topic;

[0026] Step S5: the scheduling execution module publishes the to-be-executed commands in the subtasks to the command queue one by one according to the steps of the task, so as to be asynchronously executed by the network adapter;

[0027] Step S6: The network adapter sends a command to the physical network device, obtains the echo result, parses it according to predefined rules, and outputs it to the result message queue;

[0028] Step S7: The scheduling execution module receives the echo result, determines whether the command execution of the subtask is successful, and then controls and updates the task status;

[0029] Step S8: During the task execution, the user can perform operations such as pausing, continuing, and terminating the task as needed to deal with emergencies that occur during the task execution;

[0030] Step S9: After the task is completed, the scheduling execution module completes the cleanup work according to the task execution status.

[0031] According to an embodiment of the network device management method of the present invention, step S1 further comprises:

[0032] Step S1-1: For the original command set input from the outside, divide it into several command groups according to the functional purpose, arrange and process it into a task, which has a globally unique identification number and contains several context-independent subtasks;

[0033] Step S1-2: For network device configuration scenarios that are frequently used by users, a configuration template, i.e., a baseline configuration, is solidified in advance, and a parameter placeholder is indicated by an identifier;

[0034] Step S1-3: The network adapter provides adaptation and abstraction of commands of various brands and series, abstracts commands of the same function into specific instructions, and exposes them to users;

[0035] Step S1-4: The task formed after the final arrangement includes the login information of all network devices and a series of subtasks, wherein the login information of all network devices includes the name of the network device, the management IP address, the login protocol, the brand and series of the network device, the user name, the password, and the super authority password; the content of the subtask includes at least the fields including the command or command group to be executed, the command to enter the specified command level, the command to return to the root level, the expected interaction and confirmation, the output echo format, the parsing rules, and the expected output results.

[0036] According to an embodiment of the network device management method of the present invention, step S2 further includes:

[0037] Step S2-1: judging whether the task is allowed to be executed according to the attributes of the task and the executable time window;

[0038] Step S2-2: When creating an executable to-do task according to user needs in step S1, specify the planned execution time of the task, and the scheduling execution module initiates scheduling of the task when the time arrives;

[0039] Step S2-3: To avoid sending multiple tasks to operate the same network device at the same time, for operation tasks, it is necessary to obtain the locks of all network devices involved in the task before allowing task instructions. If one or some network devices in the task are occupied by other tasks, this task will not be scheduled.

[0040] According to an embodiment of the network device management method of the present invention, step S4 further includes:

[0041] Step S4-1: the network adapter simulates the console terminal to log in to the network device using protocols including SSH according to the login information of the network device carried in the task, establishes a session with the network device, and maintains the session handle;

[0042] Step S4-2: The network adapter dynamically creates a topic in the message queue according to the task number and the network device identifier. This topic is dedicated to receiving subscriptions from the network adapter and receiving all commands that need to be sent to this network device in the current task. The topic is destroyed after the task is completed.

[0043] Step S4-3: During the execution of the task, the network adapter always maintains the session connection to the network device until all contents of the task are executed.

[0044] According to an embodiment of the network device management method of the present invention, step S5 further includes:

[0045] Step S5-1: Before each subtask is released, check and ensure that the task status is in the executing state;

[0046] Step S5-2: before the command is formally executed, the network adapter needs to switch the command line to the corresponding level according to the command field configuration for entering the specified command level in the subtask;

[0047] Step S5-3: After the execution of the command of the subtask is completed, the network adapter returns the command line level of the current session to the root level according to the command field configuration of returning to the root level in the subtask to avoid affecting the operation of the next subtask.

[0048] According to an embodiment of the network device management method of the present invention, step S6 further includes:

[0049] Step S6-1: The network adapter subscribes to the command to be issued from the command queue. If it is an abstract instruction, the network adapter translates it into a real one according to the brand and series of the network device. The network adapter sends the command to the physical network device through the currently held network device session connection to obtain the echo result;

[0050] Step S6-2: The network adapter determines whether there is any error message in the output of the current command;

[0051] Step S6-3: If the command line is executed successfully, determine whether the output result needs to be parsed according to the pre-configuration of the output echo format field in the current subtask;

[0052] If no parsing is required, the output text is directly sent to the result message queue as a message;

[0053] If parsing is required, the parsing is performed according to the predefined parsing rule fields in the subtask, and the parsing results are output to the result message queue in JSON format.

[0054] According to an embodiment of the network device management method of the present invention, step S7 further includes:

[0055] Step S7-1: The scheduling execution module receives the result returned from the network adapter and makes a judgment based on the success flag. If it fails, the entire task is judged to have failed, and all subsequent subtasks will stop running;

[0056] Step S7-2: If the command is executed successfully, the scheduling execution module determines whether the subtask is successful based on the expected output result field content of the current subtask;

[0057] Step S7-3: If the command execution or output result is judged to be a failure, the entire task status is judged to be a failure, and the task status is set to failure through the state machine, and subsequent subtasks will stop running.

[0058] Step S7-4: The scheduling execution module forwards the result generated from the network adapter to the user in its entirety.

[0059] According to an embodiment of the network device management method of the present invention, step S8 further includes:

[0060] Step S8-1: According to the task status transition rules, if any doubt is found during the task process, the user is provided with a pause operation for the task being executed, so as to analyze and troubleshoot the problem;

[0061] Step S8-2: After the problem is solved, continue to execute the current task;

[0062] Step S8-3: If it is confirmed that a serious problem is found and the subsequent task is not allowed to continue, the current task is terminated.

[0063] Compared with the prior art, the present invention has the following beneficial effects: through the network equipment management system and method of the present invention, network management personnel can flexibly schedule and execute commands and instructions after arranging them into tasks in a specified format in advance, and through a series of measures, the accuracy and security of command execution are greatly enhanced. In detail, the present invention has three characteristics: normalized task scheduling, asynchronous execution framework, and security protection mechanism, which are described in detail as follows.

[0064] 1. Normalized task scheduling

[0065] The present invention designs a normalized task arrangement function and format, converting the command line script that the user needs to manually input into a task, and its technical effects are:

[0066] (1) Set expected results in advance to facilitate control of task execution interruptions;

[0067] (2) Facilitate unified task scheduling management and device lock scheduling;

[0068] (3) Facilitate the concurrent execution of tasks;

[0069] (4) Full decoupling of the user demand (office) side and the network management execution side.

[0070] 2: Asynchronous execution framework

[0071] The present invention designs an asynchronous execution framework on the execution side, and its technical effects are:

[0072] (1) The separation of task management (scheduling execution) and device adaptation (adapter) can fully realize microservices;

[0073] (2) The adapter can achieve load balancing and fully support the concurrent execution of multiple tasks and multiple devices;

[0074] (3) The adapter can maintain device sessions for a long time during the task, avoiding frequent device logins;

[0075] (4) Avoid problems such as long waiting and timeout caused by differences in command execution time in synchronous mode;

[0076] (5) Query (collection) tasks can fully reuse the network device connection resources established by the adapter.

[0077] 3: Security protection mechanism

[0078] The present invention designs a series of safety protection mechanisms to effectively ensure the sequential execution of tasks and quickly respond to unexpected problems. Its technical effects are:

[0079] (1) Check and obtain device locks during task scheduling to avoid multiple tasks operating on the same device;

[0080] (2) The task process is fully controlled by the scheduling execution module and automatically terminated when encountering suspicious errors;

[0081] (3) Set expected results in task scheduling in advance, and automatically determine whether the task is successful based on the expected results during execution;

[0082] (4) Command output results are displayed to users in a timely manner, so that users can receive timely feedback and conduct analysis based on experience;

[0083] (5) Detect the time window in which the task can be executed to avoid affecting the development of production business;

[0084] (6) Set up manual intervention measures to be able to "brake" the task when encountering suspicious problems or emergency processing. BRIEF DESCRIPTION OF THE DRAWINGS

[0085] The above features and advantages of the present invention can be better understood after reading the detailed description of the embodiments of the present disclosure in conjunction with the following drawings. In the drawings, the components are not necessarily drawn to scale, and components with similar related properties or features may have the same or similar reference numerals.

[0086] Figure 1 A schematic diagram of the structure of an embodiment of a system for managing network devices of the present invention;

[0087] Figure 2 for Figure 1 A topology diagram of data flows and relationships of the illustrated system embodiment;

[0088] Figure 3 A flowchart of an embodiment of a network device management method of the present invention;

[0089] Figure 4 for Figure 3 The task state transition diagram corresponding to the method embodiment shown. DETAILED DESCRIPTION

[0090] The present invention is described in detail below in conjunction with the accompanying drawings and specific embodiments. Note that the aspects described below in conjunction with the accompanying drawings and specific embodiments are only exemplary and should not be construed as limiting the scope of protection of the present invention in any way.

[0091] Figure 1 FIG. 1 shows the structure of an embodiment of the network device management system of the present invention. Figure 1 The system of this embodiment can transparently, efficiently, accurately and securely send command line tasks to network devices. The system of this embodiment includes: a task scheduling module, a scheduling execution module, a network adapter, a task state machine, a device lock and a message queue. The above modules can run independently in the container in the form of microservices and communicate with each other through RESTful API or message queues. Please refer to the data flow of the system Figure 2 As shown, the modules involved in the data flow are Figure 1 The steps in the data flow of each module of the system shown are Figure 3 The corresponding steps are shown.

[0092] The task scheduling module is used to process the network device operation command list input by the user or the external interface to form a network device operation task list that can be recognized and executed by the scheduling execution module. The formed network device operation tasks are sent to the scheduling execution module for unified operation and execution, where the network device operation tasks are arranged into multiple subtasks. In particular, to further facilitate use, for network device configuration scenarios that users use more frequently, configuration templates (baseline configurations) can be solidified in advance and parameter placeholders can be represented by specific identifiers, so that users only need to fill in a small number of parameter values ​​to complete the orchestration of the specified scenario operation tasks. Common ones such as switch interface configuration, firewall policy configuration, etc. can be solidified into baseline configurations for different brands and models.

[0093] The scheduling execution module is used to schedule, assign, control and run the received network device operation tasks, and is the central module for task execution. Specifically, after receiving the network device operation task, the scheduling execution module first schedules the network device operation task according to the current time window and the scheduled execution time of the task, and at the same time applies for the locks of all network devices involved in the network device operation task. After the task is successfully scheduled, the network device adapter is connected to create a device session, the contents of the subtasks are executed in sequence, the execution status of the network device operation task is controlled and managed, and the execution results and output content of the network device operation task are returned to the user side. An asynchronous execution framework is used between the scheduling execution module and the network adapter.

[0094] The network adapter is used to adapt to various brands and series of devices, mainly including: logging in to the network device to execute commands and obtain command line output, abstracting commands according to network device brands and series, parsing command output text, etc. Specifically, the network adapter creates and maintains network device connections according to the instructions of the scheduling execution module, creates and listens to the command message queue, sends the received commands to the physical network device, receives and analyzes the command execution results, parses the results as needed, and finally returns the results to the message queue that stores the results.

[0095] The message queue is used to publish and subscribe to messages of specified types and establish a communication channel between the scheduling execution module and the network adapter. Specifically, the message queue mainly includes the command queue and the result queue. The command queue is created by the network adapter at the start of the task. Each device in each task has an independent command queue. The scheduling execution module is responsible for issuing commands, and the network adapter defines and executes the commands; conversely, the result queue is used to transfer the results generated by the network adapter to the scheduling execution module.

[0096] The task state machine is used to maintain unified task state transition rules and the execution status of each task.

[0097] The device lock is used to record and maintain the lock status of all network devices in the entire network area. It is usually only effective for operation tasks (the operation is the configuration operation). When the network device is in a locked state, it is prohibited to be accessed by other operation tasks to prevent problems such as session occupation and configuration conflicts caused by multiple tasks operating the same network device at the same time. Furthermore, it is agreed that if multiple network devices are involved in the same operation task, the task is allowed to be executed only when the locks of all network devices are obtained.

[0098] Figure 3 The flow chart of an embodiment of the network device management method of the present invention is shown. Figure 3 , the implementation steps of the method of this embodiment are described in detail as follows.

[0099] Step S1: Arrange and form a task list according to the instructions or command set input by the user or fill in parameters according to a predefined template.

[0100] User commands are arranged into tasks, which are uniformly managed and run by the subsequent scheduling and execution modules, achieving complete decoupling of the user (office) side and the network management (execution) side, meeting the security management requirements of most production environments.

[0101] Further, step S1 includes:

[0102] Step S1-1: For the original command set input from the outside (user or API interface), it is divided into several command groups according to functional purposes, and the command groups are arranged and processed to form a task, which has a globally unique identification number and contains several context-independent subtasks.

[0103] Step S1-2: For network device configuration scenarios that users use more frequently, a configuration template (baseline configuration) is solidified in advance and a specific identifier is used to represent the parameter placeholder, so that the user only needs to fill in a small number of parameter values ​​to complete the arrangement of the specified scenario operation tasks.

[0104] Step S1-3: The network adapter provides adaptation and abstraction of commands of various brands and series, abstracts commands of the same function into specific "instructions", and exposes them to users. When users operate network devices, they only need to send abstracted operation instructions to the task scheduling module, which will be "translated" into real commands by the network adapter. For example, Cisco's "showrunning-config" and Huawei's "display current-configuration" can be named the same abstract "get_config" instruction.

[0105] The processing of step S1-3 is mainly due to the fact that there are many types of network equipment brands. The command system and data model of each brand of equipment are very different. In addition, there are still differences in product series, models, system versions, etc. within the same brand, which makes it difficult to manage them in a unified manner. This has always been a difficulty in the field of network automation.

[0106] Step S1-4: The task finally formed after arrangement includes at least the login information of all network devices and a series of subtasks.

[0107] The login information of all network devices includes at least the name of the network device, management IP address, login protocol (such as SSH, TELNET, etc.), brand and series of the network device (such as Huawei, etc.), user name, password, and super authority password.

[0108] The content of the subtask includes at least fields including the command (group) to be executed, the command to enter the specified command level, the command to return to the root level, the expected interaction and confirmation, the format of the output echo, the parsing rules, and the expected output results, as described in detail below.

[0109] Commands to be executed (group): refers to one or more commands used to complete a specific query or configuration function, such as the configuration of multiple information such as description, shutdown status, VLAN, etc. of a specified switch interface;

[0110] Commands that enter a specified command level: For some brands and types of network devices, configuration commands must be entered at a specific command level before they can be entered, otherwise they will not take effect. For such commands, it is necessary to specify how to enter the specified command line level so that the execution module can run correctly;

[0111] Command to return to the root level: To avoid confusion caused by switching between command line levels, this embodiment stipulates that after each subtask is completed, the command line level will be returned to the root level (the level after default login), so as to truly achieve the independence of each subtask and the operation content is independent of the context. This field specifies how to return to the root level after the current subtask operation is completed;

[0112] Expected interaction and confirmation: When operating the command line of a network device, you will often encounter scenarios that require user interaction, such as requiring the user to enter Y / N to confirm before proceeding to the next step. Similarly, simulating command line operations in a programmatic manner will also encounter similar problems. In this regard, the user needs to clearly inform the execution module what kind of prompt information may be encountered after the command is entered, and what characters should be entered for confirmation;

[0113] Output echo format: Usually, the result of command output is text. The network adapter in this embodiment provides the ability to parse the text and extract the fields required by the user. The "output echo format" field indicates whether the command line output in the current subtask needs to be parsed;

[0114] Parsing rules: The network adapter in this embodiment predefines a series of parsing scripts that can extract key information from the command line output text. This field specifies the name and location of the parsing script that the adapter needs to use during parsing;

[0115] Expected output result: indicates the effect that the user can expect after the command input in the current subtask is completed, such as the output result must contain certain strings, or certain strings must not exist.

[0116] Step S2: Schedule the task according to the task attributes, executable time window and task planned start time, and request to obtain the device locks of all network devices in the task.

[0117] Further, step S2 includes:

[0118] Step S2-1: Determine whether the task is allowed to be executed based on the attributes of the task (command) and the executable time window.

[0119] In this embodiment, the attributes of network device management tasks are divided into viewing (i.e., collection) and operation categories. Viewing tasks refer to only viewing the current running configuration and current running status of the network device, which will not affect the operation of the device. Usually, such commands start with words such as show / display / get; operation tasks will modify the configuration file of the device, thereby affecting the actual operation of the device.

[0120] The executable time window refers to the time period preset by the system during which tasks are allowed to be executed. For example, during the working hours of 8:00-17:00, only viewing tasks are allowed, and operation tasks are not allowed. The setting of the executable time window can prevent tasks from running during certain critical time periods, prevent misoperation or performance issues from affecting the development of online production environment business, and improve system security.

[0121] Step S2-2: When creating an executable to-do task according to user needs in step S1, the planned execution time of the task is specified (the planned execution time is the start time), and the scheduling execution module initiates scheduling of the task when this time arrives.

[0122] Step S2-3: To avoid sending multiple tasks to operate the same network device at the same time, for operation tasks, it is necessary to obtain the locks of all network devices involved in the task before allowing task instructions. If one or some network devices in the task are occupied by other tasks, this task will not be scheduled.

[0123] To avoid deadlock of network devices, during the lock application process, once it is found that the lock of a network device has been occupied by other tasks, the device lock already obtained in this task must be released immediately.

[0124] The purpose of introducing the above lock mechanism is to further improve the security of the system's operation of network devices. For viewing (i.e., collection) tasks, since they do not actually affect the running configuration of the network device, read-only operations will not cause configuration conflicts and confusion, etc., so this embodiment allows multiple tasks to concurrently execute collection commands on the same network device, and the lock mechanism of the network device is only effective for operation tasks.

[0125] Step S3: The scheduling execution module notifies the network adapter through the RESTful interface to establish a device session, and the notification information includes the login information of the device.

[0126] Further, step S3 includes:

[0127] Step S3-1: The scheduling execution module sends instructions to the state machine to set the task status to "executing";

[0128] Step S3-2: the scheduling execution module notifies the network adapter to establish a device session through the RESTful interface;

[0129] In particular, when all network adapters are running independently in a containerized manner and there are multiple network adapter instances, the scheduling execution module selects a network adapter instance randomly or in a load balancing manner to avoid overloading a network adapter. Once a network adapter instance is selected, subsequent network device command execution will be proxied by this network adapter instance.

[0130] Step S4: the network adapter establishes and maintains a session with the network device according to the instruction, and at the same time creates a command line topic in the message queue and subscribes to message updates in the topic.

[0131] Further, step S4 includes:

[0132] Step S4-1: the network adapter simulates the console terminal to log in to the network device using protocols such as SSH according to the login information of the network device carried in the task, establishes a session with the network device, and maintains the session handle;

[0133] Step S4-2: The network adapter dynamically creates a topic in the message queue according to the task number and the network device identifier. This topic is dedicated to receiving subscriptions from the network adapter and receiving all commands that need to be sent to this network device in the current task. The topic is destroyed after the task is completed.

[0134] Among them, the message queue topic is dynamically created to form a dedicated command transmission channel, which can make the command issuance process of different tasks and different network devices independent of each other to avoid misoperation;

[0135] The introduction of the message queue makes the interaction between the scheduling execution module and the network adapter asynchronous. Compared with synchronous methods such as RESTful API, it avoids problems such as HTTP request timeouts caused by the uncertainty of the time required for command line execution.

[0136] Among them, the asynchronous communication method, compared with the HTTP request method, brings another advantage that the network adapter can maintain the session connection of the network device for a long time. In the same task, multiple subtasks do not need to log in to the network device repeatedly when executing, which greatly saves the time of device login. If the HTTP method is used, the network device session cannot be maintained, and the network adapter needs to log in to the device once before each subtask is executed, which brings additional overhead and increases the pressure on the network device itself.

[0137] Step S4-3: During the execution of the task, the network adapter always maintains the session connection to the network device until all contents of the task are executed.

[0138] Step S5: The scheduling execution module publishes the to-be-executed commands in the subtasks to the command queue one by one according to the steps of the task, so as to be asynchronously executed by the network adapter.

[0139] Further, step S5 includes:

[0140] Step S5-1: Before each subtask is released, check and ensure that the task status is "in progress";

[0141] Step S5-2: before the command is formally executed, the network adapter needs to switch the command line to the corresponding level according to the configuration of the "command to enter the specified command level" field in the subtask;

[0142] Step S5-3: After the execution of the command of the subtask is completed, the network adapter returns the command line level of the current session to the root level according to the "Command to return to the root level" field configuration in the subtask to avoid affecting the operation of the next subtask.

[0143] Step S6: The network adapter sends a command to the physical network device, obtains the echo result, parses it according to predefined rules, and outputs it to the result message queue.

[0144] Further, step S6 includes:

[0145] Step S6-1: The network adapter subscribes to the command to be issued from the command queue. If it is an abstract instruction, the network adapter translates it into a real one according to the brand and series of the network device. The network adapter sends the command to the physical network device through the currently held network device session connection to obtain the echo result;

[0146] Step S6-2: The network adapter determines whether there is error information in the output of the current command. Specifically, the network adapter collects common output error samples of network devices of various brands and series, such as "Error:", "at'^'" and other common error information signs, and determines whether the execution of the current command is successful by matching these error characters in the output text, and returns a sign of whether the execution is successful to the scheduling execution module;

[0147] Step S6-3: If the command line is executed successfully, determine whether the output result needs to be parsed according to the pre-configuration of the "output echo format" field in the current subtask.

[0148] If no parsing is required, the output text is directly sent as a message to the result message queue;

[0149] If parsing is required, it is parsed according to the "Parsing Rule" field predefined in the subtask. The "Parsing Rule" specifies which parsing script to use, or the specific location of the script. The network adapter extracts the required fields according to the script, and the final result is output to the result message queue in JSON format;

[0150] The parsing of command line output is part of the network device adaptation. A large number of parsing scripts of different brands and series have been predefined in the network adapter to extract the key field information that users are most concerned about from the text output. In this embodiment, most of these parsing scripts are written in Python regular expressions, or implemented using the TextFSM module (a template-based state machine engine, commonly used to parse semi-structured text).

[0151] Step S7: The scheduling execution module receives the echo result, determines whether the command execution of the subtask is successful according to the "expected output result" field, and then controls and updates the task status.

[0152] Further, step S7 includes:

[0153] Step S7-1: The scheduling execution module receives the result returned from the network adapter and makes a judgment based on the success flag. If it fails, the entire task is judged to have failed, and all subsequent subtasks will stop running;

[0154] Step S7-2: If the command is executed successfully, it only means that there is no error in the command line execution, but it does not mean that the command is indeed effective. The scheduling execution module also determines whether the subtask is successful based on the content of the "expected output result" field of the current subtask.

[0155] The Expected Output field can generally contain two types:

[0156] The "Must include" field in "Expected output results" indicates that the user expects that certain text lines or field values ​​must be included in this output. If they do not exist, it means that the command is not actually effective and the task fails. For example, if a subtask configures an IP address of 10.1.1.1 for a switch port, you can set the "ip address 10.1.1.1" string to be included in the expected output results to verify it;

[0157] The "Must exclude (exclude)" field in "Expected output results" indicates that the user expects that the output of this time must not contain certain text lines or field values, or that these text lines or field values ​​will be eliminated after the current command takes effect. If the actual inspection finds that the output results of the command still contain the above content, it is considered that the command is not effective and the task fails. For example, in a certain operation, the user plans to change the VLAN number of a switch port from 100 to 200 through a command. At this time, you can set "access vlan 100" in "Must exclude (exclude)" in "Expected output results". That is, if it is found that the VLAN is still 100, it means that the command entered this time has not taken effect;

[0158] Step S7-3: If the command execution or output result is judged to be a failure, the entire task status is judged to be a failure, and the task status is set to FAIL (failure) through the state machine, and all subsequent subtasks will stop running.

[0159] Step S7-4: The scheduling execution module completely forwards the result (command line echo) generated from the network adapter to the user, so that the user can view the command line echo in time and quickly find problems in task execution.

[0160] Step S8: During the task execution process, the user can pause, continue, terminate, and perform other operations on the task as needed to deal with emergencies that occur during the task execution process and enhance the system's emergency response capabilities.

[0161] Further, step S8 includes:

[0162] Step S8-1: According to Figure 4 The task status transition rules shown in the figure, if any questions are found during the task process, the user can perform the "pause" operation on the task that is "in progress" to analyze and troubleshoot the problem;

[0163] Step S8-2: After the problem is solved, you can "continue to execute" this task;

[0164] Step S8-3: If it is confirmed that a serious problem is found and the subsequent task is not allowed to continue, the task can be "terminated".

[0165] Step S9: After the task is completed, the scheduling execution module completes the cleanup work according to the task execution status.

[0166] Further, step S9 includes:

[0167] Step S9-1: The scheduling execution module promptly notifies the network adapter to close the session connection with the network device according to the task execution status (success / failure) to avoid long-term occupation of limited session resources;

[0168] Step S9-2: For operation tasks, release the device lock occupied by the current task to allow it to be operated by other tasks.

[0169] Although the above methods are illustrated and described as a series of actions for simplicity of explanation, it should be understood and appreciated that these methods are not limited by the order of the actions, because according to one or more embodiments, some actions may occur in a different order and / or concurrently with other actions from those illustrated and described herein or not illustrated and described herein but understandable to those skilled in the art.

[0170] Those skilled in the art will further appreciate that the various illustrative logic blocks, modules, circuits, and algorithm steps described in conjunction with the embodiments disclosed herein may be implemented as electronic hardware, computer software, or a combination of the two. To clearly illustrate this interchangeability of hardware and software, various illustrative components, blocks, modules, circuits, and steps are generally described above in terms of their functionality. Whether such functionality is implemented as hardware or software depends on the specific application and the design constraints imposed on the overall system. The technician may implement the described functionality in different ways for each specific application, but such implementation decisions should not be interpreted as resulting in a departure from the scope of the present invention.

[0171] The various illustrative logic blocks, modules, and circuits described in conjunction with the embodiments disclosed herein may be implemented or executed with a general purpose processor, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. A general purpose processor may be a microprocessor, but in the alternative, the processor may be any conventional processor, controller, microcontroller, or state machine. The processor may also be implemented as a combination of computing devices, such as a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors in cooperation with a DSP core, or any other such configuration.

[0172] The steps of the method or algorithm described in conjunction with the embodiments disclosed herein may be embodied directly in hardware, in a software module executed by a processor, or in a combination of the two. The software module may reside in a RAM memory, a flash memory, a ROM memory, an EPROM memory, an EEPROM memory, a register, a hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art. An exemplary storage medium is coupled to a processor so that the processor can read and write information from / to the storage medium. In an alternative, a storage medium may be integrated into a processor. The processor and the storage medium may reside in an ASIC. The ASIC may reside in a user terminal. In an alternative, the processor and the storage medium may reside in a user terminal as discrete components.

[0173] In one or more exemplary embodiments, the functions described may be implemented in hardware, software, firmware, or any combination thereof. If implemented as a computer program product in software, each function may be stored on or transmitted by a computer-readable medium as one or more instructions or codes. Computer-readable media include both computer storage media and communication media, including any medium that facilitates the transfer of a computer program from one place to another. Storage media may be any available medium that can be accessed by a computer. As an example and not limitation, such a computer-readable medium may include RAM, ROM, EEPROM, CD-ROM or other optical disk storage, disk storage or other magnetic storage device, or any other medium that can be used to carry or store the desired program code in the form of an instruction or data structure and can be accessed by a computer. Any connection is also properly referred to as a computer-readable medium. For example, if the software is transmitted from a website, a server, or other remote source using a coaxial cable, a fiber optic cable, a twisted pair, a digital subscriber line (DSL), or wireless technologies such as infrared, radio, and microwaves, the coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio, and microwaves are included in the definition of the medium. Disk and disc as used herein include compact disc (CD), laser disc, optical disc, digital versatile disc (DVD), floppy disk and Blu-ray disc, wherein disk often reproduces data magnetically, while disc reproduces data optically with lasers. Combinations of the above should also be included within the scope of computer-readable media.

[0174] The previous description of the disclosure is provided to enable any person skilled in the art to make or use the disclosure. Various modifications to the disclosure will be apparent to those skilled in the art, and the general principles defined herein may be applied to other variations without departing from the spirit or scope of the disclosure. Thus, the disclosure is not intended to be limited to the examples and designs described herein, but should be granted the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A network device management system, characterized in that: The system includes a task scheduling module, a scheduling execution module, a network adapter, a task state machine, a device lock, and a message queue, wherein: The task scheduling module is used to process the network device operation command list input by the user or the external interface to form a network device operation task list that can be recognized and executed by the scheduling execution module, and the formed network device operation tasks are sent to the scheduling execution module for unified operation and execution; The scheduling and execution module is used to schedule, assign, control and run the received network equipment operation tasks; Network adapters are used to adapt to various brands and series of devices, including logging into network devices to execute commands and obtain command line output, abstracting commands by network device brand and series, and parsing command output text; Message queue, used to publish and subscribe to messages of specified types and establish a communication channel between the scheduling execution module and the network adapter; Task state machine, used to maintain unified task state transition rules and the execution status of each task; Device lock is used to record and maintain the lock status of all network devices in the entire network area.

2. The network device management system according to claim 1, characterized in that: The task scheduling module solidifies the configuration template, i.e., the baseline configuration, in advance for the network device configuration scenarios that are frequently used by users, and uses identifiers to represent parameter placeholders; after receiving the network device operation task, the scheduling execution module first schedules the network device operation task according to the current time window and the scheduled execution time of the task, and at the same time applies for the locks of all network devices involved in the network device operation task. After the task is successfully scheduled, the network device adapter is connected to create a device session, the contents of the subtasks are executed in sequence, the execution status of the network device operation task is controlled and managed, and the execution results and output contents of the network device operation task are returned to the user side. An asynchronous execution framework is used between the scheduling execution module and the network adapter.

3. A network device management method, running on the network device management system according to any one of claims 1 to 2, characterized in that: Methods include: Step S1: Arrange and form a task list according to the instructions or command set input by the user or fill in parameters according to a predefined template; Step S2: Schedule the task according to the task attributes, executable time window and task planned start time, and request to obtain the device locks of all network devices in the task; Step S3: the scheduling execution module notifies the network adapter to establish a device session, and the notification information includes the login information of the network device; Step S4: the network adapter establishes and maintains a session with the network device according to the instruction, and at the same time creates a command line topic in the message queue and subscribes to message updates in the topic; Step S5: the scheduling execution module publishes the to-be-executed commands in the subtasks to the command queue one by one according to the steps of the task, so as to be asynchronously executed by the network adapter; Step S6: The network adapter sends a command to the physical network device, obtains the echo result, parses it according to predefined rules, and outputs it to the result message queue; Step S7: The scheduling execution module receives the echo result, determines whether the command execution of the subtask is successful, and then controls and updates the task status; Step S8: During the task execution, the user can perform operations such as pausing, continuing, and terminating the task as needed to deal with emergencies that occur during the task execution; Step S9: After the task is completed, the scheduling execution module completes the cleanup work according to the task execution status.

4. The network device management method according to claim 3, characterized in that: Step S1 further comprises: Step S1-1: For the original command set input from the outside, divide it into several command groups according to the functional purpose, arrange and process it into a task, which has a globally unique identification number and contains several context-independent subtasks; Step S1-2: For network device configuration scenarios that are frequently used by users, a configuration template, i.e., a baseline configuration, is solidified in advance, and a parameter placeholder is indicated by an identifier; Step S1-3: The network adapter provides adaptation and abstraction of commands of various brands and series, abstracts commands of the same function into specific instructions, and exposes them to users; Step S1-4: The task formed after the final arrangement includes the login information of all network devices and a series of subtasks, wherein the login information of all network devices includes the name of the network device, the management IP address, the login protocol, the brand and series of the network device, the user name, the password, and the super authority password; the content of the subtask includes at least the fields including the command or command group to be executed, the command to enter the specified command level, the command to return to the root level, the expected interaction and confirmation, the output echo format, the parsing rules, and the expected output results.

5. The network device management method according to claim 3, characterized in that: Step S2 further comprises: Step S2-1: judging whether the task is allowed to be executed according to the attributes of the task and the executable time window; Step S2-2: When creating an executable to-do task according to user needs in step S1, specify the planned execution time of the task, and the scheduling execution module initiates scheduling of the task when the time arrives; Step S2-3: To avoid sending multiple tasks to operate the same network device at the same time, for operation tasks, it is necessary to obtain the locks of all network devices involved in the task before allowing task instructions. If one or some network devices in the task are occupied by other tasks, this task will not be scheduled.

6. The network device management method according to claim 3, characterized in that: Step S4 further comprises: Step S4-1: the network adapter simulates the console terminal to log in to the network device using protocols including SSH according to the login information of the network device carried in the task, establishes a session with the network device, and maintains the session handle; Step S4-2: The network adapter dynamically creates a topic in the message queue according to the task number and the network device identifier. This topic is dedicated to receiving subscriptions from the network adapter and receiving all commands that need to be sent to this network device in the current task. The topic is destroyed after the task is completed. Step S4-3: During the execution of the task, the network adapter always maintains the session connection to the network device until all contents of the task are executed.

7. The network device management method according to claim 3, characterized in that: Step S5 further comprises: Step S5-1: Before each subtask is released, check and ensure that the task status is in the executing state; Step S5-2: before the command is formally executed, the network adapter needs to switch the command line to the corresponding level according to the command field configuration for entering the specified command level in the subtask; Step S5-3: After the execution of the command of the subtask is completed, the network adapter returns the command line level of the current session to the root level according to the command field configuration of returning to the root level in the subtask to avoid affecting the operation of the next subtask.

8. The network device management method according to claim 3, characterized in that: Step S6 further comprises: Step S6-1: The network adapter subscribes to the command to be issued from the command queue. If it is an abstract instruction, the network adapter translates it into a real one according to the brand and series of the network device. The network adapter sends the command to the physical network device through the currently held network device session connection to obtain the echo result; Step S6-2: The network adapter determines whether there is any error message in the output of the current command; Step S6-3: If the command line is executed successfully, determine whether the output result needs to be parsed according to the pre-configuration of the output echo format field in the current subtask; If no parsing is required, the output text is directly sent to the result message queue as a message; If parsing is required, the parsing is performed according to the predefined parsing rule fields in the subtask, and the parsing results are output to the result message queue in JSON format.

9. The network device management method according to claim 3, characterized in that: Step S7 further comprises: Step S7-1: The scheduling execution module receives the result returned from the network adapter and makes a judgment based on the success flag. If it fails, the entire task is judged to have failed, and all subsequent subtasks will stop running; Step S7-2: If the command is executed successfully, the scheduling execution module determines whether the subtask is successful based on the expected output result field content of the current subtask; Step S7-3: If the command execution or output result is judged to be a failure, the entire task status is judged to be a failure, and the task status is set to failure through the state machine, and subsequent subtasks will stop running. Step S7-4: The scheduling execution module forwards the result generated from the network adapter to the user in its entirety.

10. The network device management method according to claim 3, characterized in that: Step S8 further comprises: Step S8-1: According to the task status transition rules, if any doubt is found during the task process, the user is provided with a pause operation for the task being executed, so as to analyze and troubleshoot the problem; Step S8-2: After the problem is solved, continue to execute the current task; Step S8-3: If it is confirmed that a serious problem is found and the subsequent task is not allowed to continue, the current task is terminated.

Images