Server management method, device and equipment and readable storage medium

Abstract

The invention provides a server management method, device and equipment and a readable storage medium, and the method comprises the steps: receiving an offline message sent by a managed server, obtaining an identity recognition identifier of an associated server according to the offline message, and marking the identity recognition identifier in an identity recognition table; receiving a keep-alive message sent by the server, and querying a marked and matched identity recognition identifier in the identity recognition table according to the identity recognition identifier of the server associated with the keep-alive message; and according to the marked and matched identity identification identifier inquired in the identity identification table, deleting the marked and matched identity identification identifier and the corresponding address information, and adding the identity identification identifier and the corresponding address information again according to the keep-alive message. The technical scheme of the invention is adopted.

Description

Technical Field

[0001] This specification relates to the field of communication technologies, and in particular, to a server management method, apparatus, device, and readable storage medium. Background Art

[0002] Most server operation and maintenance monitoring software mainly realizes real-time monitoring and batch deployment of server hardware by managing the IP addresses of the dedicated ports or shared ports of the server's BMC (Baseboard Management Controller). However, in actual applications, when the number of servers is large or the network environment changes, these traditional methods cannot automatically re-manage the server devices after network changes, resulting in low management efficiency and prone to management loopholes.

[0003] When the server network is re-planned, or when the network IP automatically obtained by the server through DHCP (Dynamic Host Configuration Protocol) expires and is renewed, the IP address of the server will change. At this time, since the management software cannot sense the offline state of the server, the device status will become unknown, or the latest server IP address cannot be automatically updated. This requires the administrator to manually re-add the server IP, increasing the operation and maintenance cost and the risk of errors.

[0004] To ensure the uniqueness of the managed devices, generally, the UUID (Universally Unique Identifier) and network IP of the server are stored in a data table together. If the original unknown network IP server devices are not deleted, when manually adding again or automatically searching through the local area network to find the newly changed server IP devices, the system will report an error indicating that the device has been added. This further limits the automation ability of the management software and reduces the operation and maintenance efficiency. Summary of the Invention

[0005] In view of this, this specification provides a server management method, apparatus, electronic device, and readable storage medium to improve the above-mentioned problem of high operation and maintenance difficulty.

[0006] Specific technical solutions are as follows:

[0007] This specification provides a server management method, which is applied to a management device that manages servers. The method includes: receiving a downline message sent by a managed server, obtaining the identity identification of the associated server according to the downline message, and marking the identity identification in the identity identification table; receiving a keep-alive message sent by the server, querying for the marked and matching identity identification in the identity identification table according to the identity identification of the server associated with the keep-alive message; deleting the marked and matching identity identification and the corresponding address information according to the identity identification queried in the identity identification table, and re-adding the identity identification and the corresponding address information according to the keep-alive message.

[0008] As a technical solution, the identity identification is a UUID, the address information is an IP address, and the identity identification table includes the correspondence between the UUID and the IP address.

[0009] As a technical solution, the management device starts the M-SEARCH request thread of the SSDP:discover message; the step of receiving a downline message sent by a managed server, obtaining the identity identification of the associated server according to the downline message, and marking the identity identification in the identity identification table includes: receiving an NTS:ssdp:byebye message sent by a managed server after its IP address changes, obtaining the UUID of the server according to the USN parameter of the NTS:ssdp:byebye message, and marking the entry of the UUID in the UUID table.

[0010] As a technical solution, the step of receiving a keep-alive message sent by the server, querying for the marked and matching identity identification in the identity identification table according to the identity identification of the server associated with the keep-alive message includes: receiving an NTS:ssdp:alive message re-sent by a server that has sent an NTS:ssdp:byebye message, obtaining the UUID of the server according to the USN parameter of the NTS:ssdp:alive message, and querying in the UUID table whether there is an entry of a matching and marked UUID.

[0011] As a technical solution, the step of deleting the marked and matching identity identification and the corresponding address information according to the identity identification queried in the identity identification table, and re-adding the identity identification and the corresponding address information according to the keep-alive message includes: if there is an entry of the matching and marked UUID in the UUID table, deleting the entry of the UUID. The entry of the UUID includes the UUID and the IP address, and regenerating and adding an entry of the UUID according to the NTS:ssdp:alive message.

[0012] This specification also provides a server management device, which is applied to a management device that manages servers. The device includes: a first unit for receiving a shutdown message sent by a managed server, obtaining the identity identification of the associated server according to the shutdown message, and marking the identity identification in the identity identification table; a second unit for receiving a keep-alive message sent by the server, and querying for the marked and matching identity identification in the identity identification table according to the identity identification of the server associated with the keep-alive message; a third unit for deleting the marked and matching identity identification and the corresponding address information according to the marked and matching identity identification queried in the identity identification table, and re-adding the identity identification and the corresponding address information according to the keep-alive message.

[0013] As a technical solution, the identity identification is a UUID, the address information is an IP address, and the identity identification table includes the correspondence between the UUID and the IP address.

[0014] As a technical solution, the management device starts the M-SEARCH request thread of the SSDP:discover message; the receiving of the shutdown message sent by the managed server, obtaining the identity identification of the associated server according to the shutdown message, and marking the identity identification in the identity identification table includes: receiving the NTS:ssdp:byebye message sent after the IP address of the managed server changes, obtaining the UUID of the server according to the USN parameter of the NTS:ssdp:byebye message, and marking the entry of the UUID in the UUID table.

[0015] As a technical solution, the receiving of the keep-alive message sent by the server, and querying for the marked and matching identity identification in the identity identification table according to the identity identification of the server associated with the keep-alive message includes: receiving the NTS:ssdp:alive message re-sent by the server that has sent the NTS:ssdp:byebye message, obtaining the UUID of the server according to the USN parameter of the NTS:ssdp:alive message, and querying whether there is an entry of the UUID that is matching and marked in the UUID table.

[0016] As a technical solution, the deleting of the marked and matching identity identification and the corresponding address information according to the marked and matching identity identification queried in the identity identification table, and re-adding the identity identification and the corresponding address information according to the keep-alive message includes: if there is an entry of the matching and marked UUID in the UUID table, deleting the entry of the UUID, the entry of the UUID includes the UUID and the IP address, and regenerating and adding the entry of the UUID according to the NTS:ssdp:alive message.

[0017] This specification also provides an electronic device, including a processor and a readable storage medium. The readable storage medium stores machine-executable instructions that can be executed by the processor, and the processor executes the machine-executable instructions to implement the aforementioned server management method.

[0018] This specification also provides a readable storage medium. The readable storage medium stores machine-executable instructions, and when the machine-executable instructions are called and executed by a processor, the machine-executable instructions cause the processor to implement the aforementioned server management method.

[0019] The above technical solutions provided by this specification at least bring the following beneficial effects:

[0020] Receive the offline message of the server to mark the device to be updated, and actively trigger the IP address deletion and re-registration mechanism in combination with the keep-alive message to realize the real-time perception and automatic synchronization of dynamic IP changes. This method decouples the strong binding relationship between the device identifier and the IP, eliminates the uniqueness verification conflict caused by IP duplication, and at the same time, based on the standard SSDP protocol extension, is compatible with existing devices and does not require additional configuration, significantly reducing the manual maintenance cost and improving the real-time performance and reliability of device management in a large-scale dynamic network environment. BRIEF DESCRIPTION OF THE DRAWINGS

[0021] In order to more clearly illustrate the embodiments of this specification or the technical solutions in the prior art, the following will briefly introduce the drawings required for the description of the embodiments of this specification or the prior art. Obviously, the drawings in the following description are only some embodiments recorded in this specification. For those of ordinary skill in the art, other drawings can also be obtained according to these drawings of the embodiments of this specification.

[0022] Figure 1 is a flowchart of the server management method in an embodiment of this specification;

[0023] Figure 2 is a structural diagram of the server management device in an embodiment of this specification;

[0024] Figure 3 is a hardware structural diagram of the electronic device in an embodiment of this specification.

[0025] Reference numerals: the first module 21, the second module 22, the third module 23. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0026] The terms used in the embodiments of this specification are for the purpose of describing specific embodiments only and are not intended to limit this specification. The singular forms "a", "the", and "said" used in this specification and the 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" used herein refers to any and all possible combinations of one or more of the associated listed items.

[0027] It should be understood that although the terms first, second, third, etc. may be used in the embodiments of this specification 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 each other. For example, without departing from the scope of this specification, the first information may also be referred to as the second information, and similarly, the second information may also be referred to as the first information. Depending on the context, in addition, the word "if" used may be interpreted as "when" or "while" or "in response to a determination".

[0028] In a technical solution, the device discovery mechanism of the server management system is based on the following steps: Device broadcast for going online: When the server HDM starts up or accesses the network, it periodically sends ssdp:alive messages through the SSDP protocol. The messages contain information such as the unique identifier (UUID) of the device, the current IP address, the port number, and the service type; Management software listens and takes over management: The management software continuously listens for SSDP messages in the network. When it captures an ssdp:alive message, it extracts the IP and UUID information, adds the device to the management list, and establishes a "UUID - IP" binding relationship; Device uniqueness verification: The system ensures device uniqueness through double verification of UUID and IP. If a duplicate UUID or IP is detected, duplicate takeover management is rejected or the device is marked as an abnormal device.

[0029] The above - mentioned solution can operate stably in a static network environment, but problems are exposed when there is dynamic IP allocation (such as in a DHCP environment) or network topology adjustment (such as subnet migration, load balancing).

[0030] When the IP address of the server changes due to the expiration of the DHCP lease, network configuration changes, or failover, the new IP of the HDM cannot be perceived by the management software. The old IP record remains in the original management list, resulting in the device status being displayed as "offline" or "unknown". The above - mentioned solution only relies on the one - way announcement of the existence of the device by the ssdp:alive message and lacks an active notification mechanism for IP changes. The management software cannot distinguish between the two scenarios of "device offline" and "IP change" and needs to rely on manual intervention to delete the old record and rediscover the new IP device.

[0031] If the original IP is not released (for example, the DHCP address pool is not refreshed), the new device may be assigned the same IP address as the original device. At this time, due to the "UUID-IP" binding conflict, the management software can neither update the IP of the old device nor manage the new device, resulting in a management deadlock. After the IP is changed, the residual old records may cause operation and maintenance operations (such as firmware upgrade, configuration distribution) to incorrectly point to an invalid IP, leading to network congestion or operation failure.

[0032] In view of this, this specification provides a server management method, device, electronic device, and readable storage medium to improve the above technical problems.

[0033] The specific technical solution is as follows.

[0034] In one implementation, this specification provides a server management method applied to a management device that manages servers. The method includes: receiving a downline message sent by the managed server, obtaining the identity identification of the associated server according to the downline message, and marking the identity identification in the identity identification table; receiving a keep-alive message sent by the server, querying the marked and matching identity identification in the identity identification table according to the identity identification of the server associated with the keep-alive message; deleting the marked and matching identity identification and the corresponding address information according to the identity identification queried in the identity identification table, and re-adding the identity identification and the corresponding address information according to the keep-alive message.

[0035] Specifically, as Figure 1 , it includes the following steps:

[0036] Step S11: Receive a downline message sent by the managed server, obtain the identity identification of the associated server according to the downline message, and mark the identity identification in the identity identification table.

[0037] When the HDM (Hardware Device Manager) of the server detects that the network IP has changed or is about to go offline, it sends a downline message of the ssdp:byebye type. After receiving this message, the management device first extracts the unique service name (USN) of the server from it, that is, the identity identification. Then, find the entry corresponding to this USN in the identity identification table inside the management device and mark it, indicating that the server is currently unavailable. For example, if the USN of server A is uuid:A-UUID::upnp:rootdevice, then mark this USN as "unavailable" in the identity identification table.

[0038] Step S12: Receive a keep-alive message sent by the server, query the marked and matching identity identification in the identity identification table according to the identity identification of the server associated with the keep-alive message.

[0039] Once the server comes back online, its HDM will send a keep - alive message of the ssdp:alive type to notify other devices in the network that it has resumed being online. After receiving this keep - alive message, the management device also extracts the USN of the server from the message. Then, the management device looks up in its identity recognition table for an entry that has been marked as "unavailable" and matches the USN in the newly received keep - alive message. Suppose server A sends a keep - alive message again, and its USN is still uuid:A - UUID::upnp:rootdevice, then the system will find the corresponding entry that was previously marked as "unavailable" in this step.

[0040] Step S13: According to the marked and matched identity recognition identifier queried in the identity recognition table, delete the marked and matched identity recognition identifier and the corresponding address information, and re - add the identity recognition identifier and the corresponding address information according to the keep - alive message.

[0041] After confirming the existence of a marked entry that matches the USN in the keep - alive message, the management device will delete all relevant information of this entry in the identity recognition table, including its old network IP address, etc. Then, based on the information provided in the latest keep - alive message (such as the new network IP address), re - add the record of this server in the identity recognition table. For example, if server A obtains a new IP address 192.168.1.100 after network adjustment, then the management device will update all records about server A in its internal database with this new address to ensure that subsequent management and monitoring operations are based on the latest data.

[0042] In one implementation, when the network configuration of the server changes (such as an IP address change), the server will actively send a offline message (such as the ssdp:byebye message in the SSDP protocol). After receiving this offline message, the management device obtains the identity recognition identifier associated with the server (such as UUID or SN number) according to the message content. After receiving this message, the management device extracts the unique identifier uuid:device - uuid - A of server A from the USN field and marks this identifier in the identity recognition table, indicating that the server is about to go offline or the network status has changed.

[0043] After the server completes the network configuration change, it will send a keep-alive message (such as the ssdp:alive message in the SSDP protocol) to notify the management device of its new network status and address information. After receiving the keep-alive message, the management device queries the identity recognition table for the marked and matching identifiers based on the identity recognition identifier in the message. The management device extracts the identity recognition identifier uuid:device-uuid-A from the USN field and looks up this identifier in the identity recognition table. If it is found that the identifier has been marked (i.e., the corresponding ssdp:byebye message has been received before), then the next step of processing is entered.

[0044] After the management device queries the identity recognition table and finds the marked and matching identity recognition identifier, it deletes this identifier and its corresponding old address information, and re-adds this identifier and address according to the new address information in the keep-alive message.

[0045] In this embodiment, the management device can perceive the network status change of the server in real time and automatically update the server's address information without manual intervention. This method not only improves the automation level of server management, but also significantly reduces the operation and maintenance costs, and enhances the flexibility and adaptability of the management system. For example, in a large-scale data center, the dynamic change of the server IP address occurs frequently. The present invention can effectively solve the management loopholes caused by IP changes in the prior art, ensure that the server is always in the managed state, and improve the overall operation and maintenance efficiency and stability of the data center.

[0046] In one implementation manner, the identity recognition identifier is a UUID, the address information is an IP address, and the identity recognition table includes the corresponding relationship between the UUID and the IP address.

[0047] In one implementation manner, the management device starts the M-SEARCH request thread of the SSDP:discover message; receives the offline message sent by the managed server, obtains the identity recognition identifier of the associated server according to the offline message, and marks this identity recognition identifier in the identity recognition table, including: receiving the NTS:ssdp:byebye message sent by the managed server after the IP address change, obtaining the UUID of this server according to the USN parameter of this NTS:ssdp:byebye message, and marking the entry of this UUID in the UUID table.

[0048] In one implementation, for the keep-alive message sent by the receiving server, query the identity recognition identifier that has been marked and matched in the identity recognition table according to the identity recognition identifier of the server associated with the keep-alive message, including: receiving the NTS:ssdp:alive message resent by the server that has sent the NTS:ssdp:byebye message, obtaining the UUID of the server according to the USN parameter of the NTS:ssdp:alive message, and querying whether there is an entry in the UUID table that matches and is marked with the UUID.

[0049] In one implementation, according to the identity recognition identifier that has been marked and matched queried in the identity recognition table, delete the identity recognition identifier and the corresponding address information that have been marked and matched, and re-add the identity recognition identifier and the corresponding address information according to the keep-alive message, including: if there is an entry in the UUID table that matches and is marked with the UUID, delete the entry of the UUID. The entry of the UUID includes the UUID and the IP address, and regenerate and add the entry of the UUID according to the NTS:ssdp:alive message.

[0050] In one implementation, the standard SSDP protocol defines the behavior of the device going offline actively: when the server detects that the network configuration is about to change (such as the expiration of the DHCP lease or the reset of the network card), it actively sends an offline notification message containing the device unique identifier (UUID) and the lifecycle serial number (BOOTID) to the management device. This message is different from the passive offline detection of the traditional SSDP and provides a clear "pre-offline" signal for the management device.

[0051] After parsing the offline message, the management device creates a mark to be updated for the corresponding UUID in the identity recognition table, retains its original IP address but sets the status to "to be refreshed". In this stage, the record is not immediately deleted, but an association channel between the old IP address and the new online behavior is established to provide a verification benchmark for the subsequent keep-alive message.

[0052] A certain server needs to switch its IP from 192.168.1.10 to a new address due to network migration. Before disconnecting from the original network, its HDM actively sends an offline message carrying the UUID (such as 7a8b3c01-d905-40a0-b4e2-8a9f1b3c5d6d). After receiving it, the management device marks the IP record associated with the UUID as "to be refreshed", but retains the original IP information for subsequent matching.

[0053] When the server comes back online with a new IP address, the keep-alive message it sends contains, in addition to the UUID, an incremented lifecycle sequence number (BOOTID) and a network interface fingerprint (a hash value based on the MAC address and VLAN). The management device performs a three-layer verification: filters records in the identity recognition table with a status of "to be refreshed" and the same UUID; compares the old and new BOOTID values to ensure the lifecycle update of the device instance corresponding to the new message; and verifies the consistency of the network interface fingerprint to rule out the risk of IP conflicts between different physical devices.

[0054] If multiple "to be refreshed" records with the same UUID are detected (such as repeated offline due to network jitter), the record with the largest BOOTID is preferentially selected for update to avoid interference from historical messages.

[0055] After the server switches to the new IP (192.168.1.15), it sends a keep-alive message in which the BOOTID is incremented by 1 compared to the original value, and the network interface fingerprint remains unchanged. After the management device matches the "to be refreshed" record through the UUID, it confirms that the BOOTID increment logic is valid and the interface fingerprint has not changed, and determines that it is a legal IP update rather than a device replacement.

[0056] The management device performs transactional data reconstruction on the successfully matched records, moves the original IP address into the historical address pool and marks the expiration time to retain the audit traceability ability. Inserts the new IP address, port, and the latest BOOTID, and restores the device status to "online". Pushes the change event to the operation and maintenance system to trigger the automatic adaptation of associated configurations such as API endpoints and monitoring policies. An optimistic lock mechanism is used to handle the multi-management node scenario: when multiple management devices simultaneously detect an update of the same UUID, version arbitration is performed based on the BOOTID timestamp, and only the latest data version is retained to ensure data consistency in a distributed environment.

[0057] After the address update is completed, the operation and maintenance platform immediately marks 192.168.1.10 as a historical IP, and all management operations (such as remote login and firmware upgrade) automatically point to the new address 192.168.1.15. If the server triggers another IP change after 10 seconds, the system will identify a new round of update requirements through the incremented BOOTID to form a continuous closed-loop management.

[0058] In one implementation, the network IP of the server HDM is automatically added to the operation and maintenance software by discovering the server HDM through the local area network, relying on the ssdp::alive message in the SSDP service of the HDM. The HDM actively sends the ssdp::alive message. After monitoring this message, the server network IP is obtained by acquiring the data in the message and then automatically added and managed. The SSDP:alive message is used to announce the presence of a device or service in the network. This message is sent when the device starts up or becomes available. It is sent in the form of a NOTIFY message.

[0059] When the HDM network IP changes, an NTS:ssdp:byebye message is sent. Among them, the M-SEARCH request thread of the SSDP:discover message in the UniSystem background is always enabled. When an ssdp:byebye message is monitored, the UUID unique identifier of the server is obtained through the USN parameter in the message and compared with the server UUID in the UniSystem database table. If a matching UUID is found, at the same time, the M-SEARCH request thread of the SSDP:discover message in the UniSystem obtains and monitors the alive message sent by the HDM. If the UUID in the alive message is the same as the UIID in the monitored byebye message, the network IP of the server HDM in the UniSystem background database table is automatically deleted, and then the latest network IP of the server HDM is obtained through the information in the alive message for automatic management replacement of the old IP.

[0060] In one implementation, such as Figure 2 , this specification also provides a server management device, which is applied to a management device that manages servers. The device includes: a first unit, configured to receive a logout message sent by the managed server, obtain the identity identification of the associated server according to the logout message, and mark the identity identification in the identity identification table; a second unit, configured to receive a keep-alive message sent by the server, query the marked and matching identity identification in the identity identification table according to the identity identification of the server associated with the keep-alive message; a third unit, configured to delete the marked and matching identity identification and the corresponding address information according to the marked and matching identity identification queried in the identity identification table, and re-add the identity identification and the corresponding address information according to the keep-alive message.

[0061] In one implementation, the identity identification is a UUID, the address information is an IP address, and the identity identification table includes the corresponding relationship between the UUID and the IP address.

[0062] In one embodiment, the management device starts the M-SEARCH request thread of the SSDP:discover message; receives the offline message sent by the managed server, obtains the identity identification of the associated server according to the offline message, and marks the identity identification in the identity identification table, including: receiving the NTS:ssdp:byebye message sent by the managed server after the IP address change, obtaining the UUID of the server according to the USN parameter of the NTS:ssdp:byebye message, and marking the entry of the UUID in the UUID table.

[0063] In one embodiment, the management device receives the keep-alive message sent by the server, queries the marked and matching identity identification in the identity identification table according to the identity identification of the server associated with the keep-alive message, including: receiving the NTS:ssdp:alive message resent by the server that has sent the NTS:ssdp:byebye message, obtaining the UUID of the server according to the USN parameter of the NTS:ssdp:alive message, and querying whether there is an entry of the UUID that is matching and marked in the UUID table.

[0064] In one embodiment, according to the marked and matching identity identification queried in the identity identification table, the marked and matching identity identification and the corresponding address information are deleted, and the identity identification and the corresponding address information are re-added according to the keep-alive message, including: if there is an entry of the matching and marked UUID in the UUID table, the entry of the UUID is deleted. The entry of the UUID includes the UUID and the IP address, and an entry of the UUID is regenerated and added according to the NTS:ssdp:alive message.

[0065] The device embodiments are the same as or similar to the corresponding method embodiments, and will not be elaborated herein.

[0066] In one embodiment, this specification provides an electronic device, including a processor and a readable storage medium. The readable storage medium stores machine-executable instructions that can be executed by the processor. The processor executes the machine-executable instructions to implement the foregoing server management method. In terms of the hardware level, the schematic diagram of the hardware architecture can be seen Figure 3 as shown.

[0067] In one embodiment, this specification provides a readable storage medium. The readable storage medium stores machine-executable instructions. When the machine-executable instructions are called and executed by a processor, the machine-executable instructions cause the processor to implement the foregoing server management method.

[0068] Here, the readable storage medium can be any electronic, magnetic, optical, or other physical storage device that can contain or store information such as executable instructions, data, and so on. For example, the readable storage medium can be: RAM (Random Access Memory), volatile memory, non-volatile memory, flash memory, storage drives (such as hard disk drives), solid state drives, any type of storage disk (such as optical discs, DVDs, etc.), or similar storage media, or a combination thereof.

[0069] The systems, devices, modules, or units illustrated in the above embodiments can be specifically implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a computer, and the specific form of the computer can be a personal computer, laptop computer, cellular phone, camera phone, smart phone, personal digital assistant, media player, navigation device, email transceiver, game console, tablet computer, wearable device, or a combination of any several of these devices.

[0070] For the convenience of description, when describing the above devices, they are divided into various units according to their functions and described separately. Of course, when implementing this specification, the functions of each unit can be implemented in the same or multiple software and / or hardware.

[0071] Those skilled in the art should understand that the embodiments of this specification can be provided as a method, system, or computer program product. Therefore, this specification can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Moreover, the embodiments of this specification can take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0072] This specification is described with reference to the flowcharts and / or block diagrams of methods, devices (systems), and computer program products according to the embodiments of this specification. It should be understood that each flow and / or block in the flowchart and / or block diagram, and the combination of flows and / or blocks in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to the processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing device to generate a machine, such that the instructions executed by the processor of the computer or other programmable data processing device generate a device for implementing the specified functions in Figure 1 one process or multiple processes and / or blocks Figure 1 one block or multiple blocks.

[0073] Moreover, these computer program instructions can also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to work in a particular manner, such that the instructions stored in the computer-readable memory produce a manufacture including an instruction device that implements the functions specified in one process Figure 1 or more processes and / or blocks Figure 1 or more blocks.

[0074] These computer program instructions can also be loaded onto a computer or other programmable data processing apparatus, so that a series of operation steps are executed on the computer or other programmable apparatus to generate a computer-implemented process, and thus the instructions executed on the computer or other programmable apparatus provide steps for implementing the functions specified in one process Figure 1 or more processes and / or blocks Figure 1 or more blocks.

[0075] Those skilled in the art should understand that the embodiments of this specification can be provided as a method, a system, or a computer program product. Therefore, this specification can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Moreover, this specification can take the form of a computer program product implemented on one or more computer-usable storage media (which may include, but are not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0076] The above are only the embodiments of this specification and are not used to limit this specification. For those skilled in the art, various changes and modifications can be made to this specification. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principle of this specification shall be included within the scope of the claims of this specification.

Claims

1. A server management method, characterized in that: Applied to a management device, the management device managing a server, the method comprising: Receive an offline message sent by a managed server, obtain an identity identifier of the associated server according to the offline message, and mark the identity identifier in an identity identification table; Receive the keep-alive message sent by the server, and search the identity identification table for a marked and matching identity identification according to the identity identification of the server associated with the keep-alive message; According to the marked and matched identity identification identifier queried in the identity identification table, the marked and matched identity identification identifier and the corresponding address information are deleted, and the identity identification identifier and the corresponding address information are re-added according to the keep-alive message.

2. The method according to claim 1, characterized in that The identity identification identifier is a UUID, the address information is an IP address, and the identity identification table includes a correspondence between the UUID and the IP address.

3. The method according to claim 1, characterized in that The management device starts an M-SEARCH request thread of the SSDP:discover message; The receiving the offline message sent by the managed server, obtaining the identity identification of the associated server according to the offline message, and marking the identity identification in the identity identification table includes: Receive an NTS:ssdp:byebye message sent by a managed server after its IP address is changed, obtain the UUID of the server according to the USN parameter of the NTS:ssdp:byebye message, and mark the entry of the UUID in the UUID table.

4. The method according to claim 3, characterized in that The receiving server sends a keep-alive message, and searching the identity identification table for a marked and matching identity identification according to the identity identification of the server associated with the keep-alive message, including: Receive the NTS:ssdp:alive message resent by the server that sent the NTS:ssdp:byebye message, obtain the UUID of the server according to the USN parameter of the NTS:ssdp:alive message, and query whether there is a matching and marked UUID entry in the UUID table.

5. The method according to claim 4, characterized in that The method of deleting the marked and matched identity identification identifier and the corresponding address information according to the queried identity identification identifier in the identity identification table, and re-adding the identity identification identifier and the corresponding address information according to the keep-alive message includes: If there is a table entry of the matched and marked UUID in the UUID table, the table entry of the UUID is deleted, the table entry of the UUID includes the UUID and the IP address, and the table entry of the UUID is regenerated and added according to the NTS:ssdp:alive message.

6. A server management device, characterized in that: Applied to a management device, the management device manages a server, and the device includes: The first unit is used to receive an offline message sent by a managed server, obtain an identity identification identifier of the associated server according to the offline message, and mark the identity identification identifier in an identity identification table; The second unit is used to receive a keep-alive message sent by the server, and query the identity identification identifier that has been marked and matched in the identity identification table according to the identity identification identifier of the server associated with the keep-alive message; The third unit is used to delete the marked and matched identity identification identifier and the corresponding address information according to the marked and matched identity identification identifier queried in the identity identification table, and re-add the identity identification identifier and the corresponding address information according to the keep-alive message.

7. The device according to claim 6, characterized in that The identity identification identifier is a UUID, the address information is an IP address, and the identity identification table includes a correspondence between the UUID and the IP address.

8. The device according to claim 6, characterized in that The management device starts an M-SEARCH request thread of the SSDP:discover message; The receiving the offline message sent by the managed server, obtaining the identity identification of the associated server according to the offline message, and marking the identity identification in the identity identification table includes: Receive an NTS:ssdp:byebye message sent by a managed server after its IP address is changed, obtain the UUID of the server according to the USN parameter of the NTS:ssdp:byebye message, and mark the entry of the UUID in the UUID table.

9. The device according to claim 8, characterized in that The receiving server sends a keep-alive message, and searching the identity identification table for a marked and matching identity identification according to the identity identification of the server associated with the keep-alive message, including: Receive the NTS:ssdp:alive message resent by the server that sent the NTS:ssdp:byebye message, obtain the UUID of the server according to the USN parameter of the NTS:ssdp:alive message, and query whether there is a matching and marked UUID entry in the UUID table.

10. The device according to claim 9, characterized in that The method of deleting the marked and matched identity identification identifier and the corresponding address information according to the queried identity identification identifier in the identity identification table, and re-adding the identity identification identifier and the corresponding address information according to the keep-alive message includes: If there is a table entry of the matched and marked UUID in the UUID table, the table entry of the UUID is deleted, the table entry of the UUID includes the UUID and the IP address, and the table entry of the UUID is regenerated and added according to the NTS:ssdp:alive message.

11. An electronic device, characterized in that: include: A processor and a readable storage medium, wherein the readable storage medium stores machine executable instructions that can be executed by the processor, and the processor executes the machine executable instructions to implement any method described in claims 1-5.

12. A readable storage medium, characterized in that: The readable storage medium stores machine executable instructions, and when the machine executable instructions are called and executed by a processor, the machine executable instructions prompt the processor to implement any one of the methods of claims 1-5.

Images