A cluster equipment software management method and device

Abstract

The present invention discloses a cluster device software management method and device, and relates to the application field of embedded devices. The steps of the method include: step A, splitting the software package of each device into multiple sub-software packages, placing all sub-software packages in a unified format, and each sub-software package has a unique directory name; step B, creating a device software package, the directory information of the device software package includes specific device information, and each specific device information will be associated with the placement location of the required sub-software package; step C, deploying the device software package and all sub-software packages to form a download source for cluster devices to download and synchronize. The present invention not only reduces the storage requirements, but also unifies the storage form, the local storage is consistent with the server storage form, and is managed through a synchronization mechanism for easy maintenance. At the same time, the present invention also realizes that the management mode of any server is exactly the same regardless of where it is deployed, simplifying the management process.

Description

Technical Field

[0001] The present invention relates to the field of embedded device applications, and in particular to a cluster device software management method and device. Background Art

[0002] At present, the main solution for cluster device software management is for the management end to connect to each managed device, inform the managed device where to obtain the software version, and direct the actions of each device. The key points of the above solution are: the management end needs to initiate actions on each managed device; different types of devices need to specify different publishing sources.

[0003] The management end prepares different release sources for different devices, so as to manage each device independently (such as downloading, upgrading, etc.), and each release source contains a complete device software package for the device. However, multiple device software packages with different formats and release locations and duplicate resources will not only occupy a large amount of storage space on the management end, but also increase the management difficulty of the management end (difficult to manage uniformly). Summary of the invention

[0004] In view of the defects existing in the prior art, the technical problem solved by the present invention is: when performing software management on cluster devices, how to optimize the storage space of the management end and reduce the management difficulty of the management end.

[0005] To achieve the above objectives, the cluster device software management method provided by the present invention comprises the following steps:

[0006] Step A: split the software package of each device into multiple sub-software packages, place all the sub-software packages in a unified format, and the directory name of each sub-software package is unique;

[0007] Step B: Create a device software package. The directory information of the device software package includes specific device information. Each piece of device information under the specific device information directory is associated with the placement location of the required sub-package.

[0008] Step C: deploy the device software package and all sub-software packages to form a download source for cluster devices to download and synchronize.

[0009] Based on the above technical solution, the following steps are also included before device synchronization: determine whether the current node device is an edge node. If so, configure the node device to only manage local node data; otherwise, use the node device as the server of the downstream node device, and request and cache the resources required by the downstream node device from the upstream device.

[0010] On the basis of the above technical solution, the method of requesting and caching the resources required by the downstream node device from the upstream device includes any one of the following two methods:

[0011] (1) A cache area of ​​a specified size is set for the current node device to store the resources required by the downstream node device. When the downstream node requests a resource, the current node device determines whether the resource size is greater than the remaining capacity of the cache area. If so, after clearing the cache area, the current node device requests the resources required by the downstream node device from the upstream device and synchronizes them to the cache area. Otherwise, the current node device directly requests the resources required by the downstream node device from the upstream device and synchronizes them to the cache area for download by the downstream node device.

[0012] (2) Cache the resources required by the specified downstream node device.

[0013] Based on the above technical solution, before device synchronization, the following settings need to be performed on each node device:

[0014] (1) Add synchronization sources, which include remote sources and local synchronization sources. The remote source includes the download source in step C; the local synchronization source includes a local specified path or an external storage path;

[0015] (2) Select the synchronization source: that is, specify a synchronization source as the preferred source. When the remote source data is synchronized with the local internal storage data, the preferred source automatically switches to the local synchronization source.

[0016] (3) Check the synchronization source: Determine whether the preferred source is synchronized with the local synchronization source. If so, no synchronization is required. Otherwise, the software version information related to the device in the preferred source is displayed, and a version in the preferred source is selected as the version to be used for the next startup.

[0017] (4) Local source management service: When a node device synchronizes only the resources required by its own device, it configures the information required for synchronization of its own device; when a node device is a server for a downstream node, it configures the information required for synchronization of the downstream device.

[0018] On the basis of the above technical solution, the rules for splitting the software package of each device into multiple sub-software packages in step A include: splitting the software package of each device into multiple sub-software packages according to the CPU architecture, chip and function used by each device; a description file for obtaining complete information of the software package exists in the sub-software package; the directory name of the sub-software package is its own hash value; the description information of the device software package in step B includes two levels of sub-directories, the first level is the product, and the second level is the specific device information, and each device information under the specific device information directory is associated with the required sub-software package by the hash value.

[0019] The cluster device software management device provided by the present invention comprises a software package splitting module, a device software package creating module and a download server;

[0020] The software package splitting module is used to split the software package of each device into multiple sub-packages, and place all sub-packages in a unified format. The directory name of each sub-package is unique.

[0021] The device software package creation module is used to: create a device software package, the directory information of the device software package includes specific device information, and each device information under the specific device information directory will be associated with the placement location of the required sub-package;

[0022] The download server is used to deploy the device software package and all sub-software packages to form a download source for cluster devices to download and synchronize.

[0023] Based on the above technical solution, the device also includes a software source management module arranged on each node device, which is used to: before device synchronization, determine whether the current node device is an edge node. If so, configure the node device to only manage local node data; otherwise, use the node device as a server of the downstream node device, and request and cache the resources required by the downstream node device from the upstream device.

[0024] On the basis of the above technical solution, the software source management module requests the upstream device and caches the resources required by the downstream node device in any one of the following two ways:

[0025] (1) A cache area of ​​a specified size is set for the current node device to store the resources required by the downstream node device. When the downstream node requests a resource, the current node device determines whether the resource size is greater than the remaining capacity of the cache area. If so, after clearing the cache area, the current node device requests the resources required by the downstream node device from the upstream device and synchronizes them to the cache area. Otherwise, the current node device directly requests the resources required by the downstream node device from the upstream device and synchronizes them to the cache area for download by the downstream node device.

[0026] (2) Cache the resources required by the specified downstream node device.

[0027] On the basis of the above technical solution, the software source management module is further used before the device synchronization:

[0028] (1) Adding a synchronization source, the synchronization source includes a remote source and a local synchronization source, the remote source includes the download source; the local synchronization source includes a local specified path or an external storage path;

[0029] (2) Select the synchronization source: that is, specify a synchronization source as the preferred source. When the remote source data is synchronized with the local internal storage data, the preferred source automatically switches to the local synchronization source.

[0030] (3) Check the synchronization source: Determine whether the preferred source is synchronized with the local synchronization source. If so, no synchronization is required. Otherwise, the software version information related to the device in the preferred source is displayed, and a version in the preferred source is selected as the version to be used for the next startup.

[0031] (4) Local source management service: When a node device synchronizes only the resources required by its own device, it configures the information required for synchronization of its own device; when a node device is a server for a downstream node, it configures the information required for synchronization of the downstream device.

[0032] On the basis of the above technical solution, the rules for the software package splitting module to split the software package of each device into multiple sub-software packages include: splitting the software package of each device into multiple sub-software packages according to the CPU architecture, chip and function used by each device; a description file for obtaining complete information of the software package exists in the sub-software package; the directory name of the sub-software package is its own hash value; the description information of the device software package created by the device software package creation module includes two levels of sub-directories, the first level is the product, and the second level is the specific device information, and each device information under the specific device information directory is associated with the required sub-software package with the hash value.

[0033] Compared with the prior art, the advantages of the present invention are:

[0034] (1) Compared with the prior art in which a download source is provided for each device, the present invention can manage all sub-software packages and device software packages in a unified format together, thereby providing only one download source.

[0035] On this basis, the present invention not only reduces the storage requirements, any version release of any device only needs to provide "incremental files" and expand them to the above-mentioned download source path; it also unifies the storage form, the local storage and the server storage form are consistent, and it is easy to maintain through management through a synchronization mechanism. At the same time, the present invention also realizes that the management mode of any server is exactly the same regardless of where it is deployed, and the only difference is the local cache size, which simplifies the management process.

[0036] In summary, the present invention not only significantly saves storage space at the management end, but also greatly reduces the management difficulty at the management end.

[0037] (2) The core node of the present invention can automatically serve as the downstream node server, the central station connected to the core node can configure the service capacity according to the actual needs of the downstream, and the edge node uses the adjacent upstream node as the server. Therefore, the present invention significantly reduces the load of the management end and ensures the data transmission rate. BRIEF DESCRIPTION OF THE DRAWINGS

[0038] Figure 1Schematic diagram of the synchronization sequence between node devices in an embodiment of the present invention. DETAILED DESCRIPTION

[0039] In order to make the purpose, technical solution and advantages of the embodiments of the present application clearer, the technical solution in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without making creative work are within the scope of protection of this application.

[0040] See also Figure 1 As shown, the cluster device software management method in the embodiment of the present invention includes the following steps:

[0041] S1: Develop a software package management solution: According to the CPU architecture (same or different, i.e., arch), chip (chip driver) and function (software module) used by each device, split the "complete software package" of each device into multiple "sub-soft packages". There are description files in the sub-soft packages to facilitate obtaining complete information of the software package; the internal structure of the sub-soft packages can adopt an open source solution or a private solution, and the specific structure does not fall within the scope of protection of the present invention.

[0042] S2: Since different devices may use the same functions and chips, the corresponding software modules and hardware drivers have strong consistency, and the multiple split software packages must be managed in a unified manner; therefore, all sub-software packages are placed in a unified format, and the directory name of each sub-software package is unique, and the directory name is preferably named after its own hash value.

[0043] Preferably, in this embodiment, the format of the sub-package is the following tree structure, from which it can be seen that the sub-package strips away how the device uses the software and only provides the content of the software. The following S3 will provide "how to use these tiled software".

[0044]

[0045] S3: Create a device software package. Each product corresponds to a device software package. The description information of the device software package includes two levels of sub-directories. The first level is the product and the second level is the specific device information (such as the device model and its specific release version). Under the above directory, based on the internal organizational structure of the device, the specific description information of various devices is given. The description information is released for each specific hardware.

[0046] The specific format of the device software package in this embodiment is:

[0047]

[0048] At the same time, each specific device information in the second-level subdirectory will be associated with the location of the required sub-package, and the association method is preferably: to associate with the hash value of each sub-package, that is, the description information includes the hash values ​​of all verified packages used by the device and can achieve the complete functions of the device. Each hash value has a corresponding sub-package, for example:

[0049] [pkglist]

[0050] KERNEL_HASH_OF_PKG

[0051] BOOTSTRAP_HASH_OF_PKG

[0052] …

[0053] SOMEFUNCTION_HASH_OF_PKG

[0054] S4: deploy the above-mentioned device software package and all sub-software packages to form a download source for cluster devices to download and synchronize. The specific implementation method can be: configure the core server to provide software download services, the software download service can be through ftp, sftp, http, https and other general methods, or independently develop a custom transmission protocol; the software provided by the core server for download is the above-mentioned download source.

[0055] The comparison between the prior art and the present invention is as follows:

[0056] In the prior art, the upgraded devices A and B are different devices:

[0057] Upgrade device A

[0058] ->telnet ip_of_ptn-seriesA-1

[0059] ->update ip_of_server / path_to_ / ptn-seriesA-type-version1

[0060] Upgrade device B

[0061] ->telnet ip_of_ptn-seriesB-1

[0062] ->update ip_of_server / path_to_ / ptn-seriesB-type-verions1

[0063] The present invention upgrades devices A and B that are different at both ends, and only requires the following steps, wherein set_remote_service can be set once according to the actual network topology when the network is constructed.

[0064] ->telnet ip_of_ptn_the_first_node

[0065] ->show_service

[0066] 1,localmirror=HIDDEN_PATH

[0067] 2,localexternalmirror= / path_to_external_disk

[0068] 3,remotemirror=ftp: / / ip_of_server / path_to_service_root

[0069] ->select_service 3

[0070] ->sync

[0071] It can be seen from this that compared with the prior art of providing a download source for each device, the present invention can aggregate all sub-software packages and device software packages in a unified format and manage them together, thereby providing only one download source, which not only significantly saves the storage space of the management end, but also reduces the management difficulty of the management end.

[0072] S5: Perform management configuration on each node device (i.e., managed device), specifically: determine whether the current node device is an edge node:

[0073] If yes, it means that the node device usually has limited performance and storage capacity, and has no downstream nodes. For such a device, it is configured to only manage local node data and does not need to serve as a downstream device server. For example, in the following configuration data, localseries is set to the local node, and server_service and slave_series are both set to empty:

[0074] [sync_config]

[0075] product=ptn

[0076] localseries=seriesA

[0077] server_service=

[0078] slave_series=

[0079] If not, it means there is a downstream node device. In this case, the current node device is used as the server of the downstream node device, and requests and caches the resources required by the downstream node device from the upstream device so that the downstream node device can download them. According to the performance of the current node device, the following two caching methods can be used:

[0080] (1) In general, the core device has stronger performance, and its local computing power and storage resources are very rich. When it acts as the server of the downstream node device, the impact on the local end is relatively small. At this time, the current node device sets a cache area of ​​a specified size to place the resources required by the downstream node device. When the downstream node applies for resources, the current node device determines whether the resource size is greater than the remaining capacity of the cache area. If so, after clearing the cache area, it applies to the upstream device for the resources required by the downstream node device and synchronizes them to the cache area. Otherwise, it directly applies to the upstream device for the resources required by the downstream node device and synchronizes them to the cache area for the downstream node device to download.

[0081] For example, to set the current node device to use "automatic mode", refer to the following content, that is, to set the local service to automatic:

[0082] [sync_config]

[0083] …

[0084] server_service=auto

[0085] server_cache=400M

[0086] slave_series=

[0087] After such configuration, when the downstream node applies for resources, the local source management service of this node confirms the resources required by the downstream node and synchronizes the corresponding resources to the node. At this time, slave_series can be unconfigured, but server_cache needs to be configured, which indicates the data cache size that the downstream node applies to the local node. As shown in the above example, it is set to 400M. When the total size of the data requested by the downstream node device to the local node device exceeds 400M, or is greater than the remaining capacity of server_cache, the local node needs to automatically start garbage collection to recycle the files that are no longer in use in order to obtain new untransmitted files.

[0088] (2) For complex networking environments, non-core nodes may also use devices with higher performance and specifications. Due to pressures such as equipment costs, storage resources may not be able to assume the server-side responsibilities of all downstream nodes. In this case, the resources required by the downstream node devices are specified according to the performance cache of the current device node, that is, the manual configuration mode is allowed. Refer to the following configuration data server_service is set to manual, allowing caching of the two downstream devices.

[0089] [sync_config]

[0090] server_service=manual

[0091] slave_series=ptn / seriesB,otn / seriesX

[0092] This configuration means that this end only caches the resources of the two devices. When other downstream nodes except the above devices request resources from this node, no synchronization operation is performed.

[0093] The setting principle and effect of S5 are as follows: in the prior art, each node device applies for resources from the management end, which will dramatically increase the load of the management end and thus seriously affect the data transmission rate. However, referring to S5, it can be seen that the present invention uses all node devices except edge nodes as servers of downstream node devices, so that downstream node devices can apply for resources from adjacent upstream node devices, which significantly reduces the load of the management end and ensures the data transmission rate.

[0094] At the same time, in order to implement the S5 process, the following settings need to be performed on each node device:

[0095] (1) Add synchronization source: that is, set the synchronization mode. The synchronization path can be a remote synchronization path (i.e., remote source, which is the download source in S4 or the resource download path of the upstream node). When set as a remote source, the new software version can be obtained to synchronize to the local source; the synchronization path can also be a local specified path or an external storage path. When the remote source is not set, only the local synchronization source of the product node is displayed; when the remote source is set, all server information is displayed.

[0096] (2) Select the synchronization source: that is, specify a synchronization source (remote source or local source) as the "preferred source", usually the network management; the remote synchronization source based on the local Ethernet port can be an independent server; based on the local external storage device such as a USB flash drive. Selecting a remote source is "temporary". When the remote source data is synchronized with the local internal storage data, it will automatically switch to the local synchronization source.

[0097] (3) Check the synchronization source: Determine whether the preferred source is synchronized with the local synchronization source. If so, no synchronization is required. Otherwise, the software version information related to the device in the preferred source is displayed, and a version is selected in the preferred source as the version to be used for the next startup. When the version is synchronized to the local, it is set as the version to be used for the next startup. In addition, if there is a problem with the integrity or reliability of the currently specified synchronization source, the local synchronization process will not be started temporarily.

[0098] (4) Local source cleanup: Only all packages related to the currently used version are retained, and packages that no longer have necessary lines are cleaned up to save space.

[0099] (5) Local source management service: When a node device synchronizes only the resources required by its own device, configure the information required for synchronization of its own device; when a node device is a server of a downstream node, confirm the type of downstream device and configure the information required for synchronization of the downstream device.

[0100] The method of synchronizing data depends on the type of "source". For example, if the local source can directly access the pluggable storage, the synchronization process can use the copy command; if the remote source is an ftp or http server visible to the local Ethernet port, the synchronization process can use the wget command to obtain the corresponding file.

[0101] In actual operation, the software source management module set on each node device executes all the processes of S5. The software source management module manages the software of the entire device according to its own device type. Among them, the product form is implanted in the local storage of the device as a fixed attribute, and the remote source is allowed to be modified as an active configuration. At the same time, the deployment difference of the software source management module on the device management side and the device side is only the synchronization configuration information mentioned above. The slave_series in the configuration information on the management side contains all supported devices.

[0102] S6: Synchronize node devices according to the configuration of S5.

[0103] As can be seen from the above, there are multiple paths to choose from when synchronizing, allowing the workstation or any device node to be set up as a server. When the device node sets the workstation as the synchronization source, the device synchronizes the software package from the workstation. This process is similar to the traditional upgrade method. After any node synchronizes the data, the node can be used as a synchronization source for other devices; in the case of the above usage, the bandwidth between the workstation and the downstream node is effectively utilized, and the same data only needs to be transmitted from the workstation once.

[0104] See for example Figure 1As shown, the workstation is directly connected to Node1 (Node1), and Node1 sets the workstation as the synchronization source. After synchronizing the data to the local, the software version is switched based on the local synchronization source. Node 5 is connected to the workstation through the in-band service channel between Node 1. Node 5 is of the same type as Node 1, and Node 1 can be set as the synchronization source. If the types of Node 5 and Node 1 are different, the workstation is usually directly set as the synchronization source. Because the software package maintenance form of the patent solution maintains all the software of any device in one method, when the types of Node 5 and Node 1 are different, Node 1 can also be set as the synchronization source of Node 5. The local source management service can sink all the resources related to Node 5 on the workstation to Node 1. Due to the software package management mechanism of the solution, even if Node 1 and Node 5 are of different types, there are a large number of duplicate software packages, which has little impact on the storage space of Node 1. In the configuration example above, the cache size is set to 400M. When the difference in software packages between Node 5 and Node 1 is less than 400M, Node 1 will completely cache all the required files in Node 5. When the software package difference between node 5 and node 1 is greater than 400M, node 1 needs to start garbage collection to clean up the cache so that other untransmitted files can be cached locally - because the data in the cache has been completely obtained by node 5 and is no longer needed.

[0105] The method of the present invention is specifically described below through a specific embodiment.

[0106] The hardware of the cluster device in this embodiment is as follows: there are multiple different processing units in the cluster device, and the functions of different processing units are the same or different, and the processors used are different. The processors used include: arm, arm64, ppc64. Based on this hardware environment, the following implementation content is available.

[0107] First, corresponding to S1 above, the software is broken up into multiple sub-packages. Then, for a device, many sub-packages can be formed, such as the system-level:

[0108] rootfs.pkg, kernle.pkg, and upper application level: service.pkg. Due to different architectures, the above packages are named according to the architecture names as follows:

[0109] rootfs_arm.pkg, kernel_arm.pkg, service_arm.pkg;

[0110] rootfs_ppc64.pkg, kernel_ppc64.pkg…

[0111] Second, corresponding to S2 to S4 above, configure the download service on the core server and organize the server files in the following form:

[0112]

[0113] The profile-board description file is organized according to the format in S3 above and will not be described here.

[0114] Third, corresponding to S5 above, develop a device software source management module to complete the following functions for software management:

[0115] set_service: Add synchronization source.

[0116] show_service: Displays source server configuration information.

[0117] select_service: Select the synchronization source.

[0118] check_service: Checks the integrity of the synchronization source and whether it is synchronized with the local synchronization source. The integrity check can be configured not to expire, and the check can be repeated until the integrity check passes.

[0119] show_versions: Displays the synchronization source.

[0120] select_version: Select the startup version.

[0121] service_gc: gc=garbage clean, local source cleanup.

[0122] When the directory structure on the server is standardized, the method to refresh the device software to the required version is as follows:

[0123] Use set_service to add a remote synchronization source, and use select_service to set the remote source as the preferred source. Use show_service to see that the synchronization source is set to the remote synchronization source. There may be multiple versions on the remote synchronization source at this time. Use show_versions to view multiple version information in the remote synchronization source. Use select_version to select a version as the version to be used next time. At this time, if the selected version is on the remote source, all the contents of the remote source will be synchronized to the local path, and then set_service will be automatically executed to set the local source as the synchronization source. At this time, since the corresponding version of the remote source has been synchronized to the local source, the remote source information can no longer be retained. At this time, as shown in the following execution process, use show_service to see that the synchronization source switches back to the local path after synchronization:

[0124] The following is an example of control using the local console:

[0125] -> indicates the console prompt, and # indicates a comment on the line above.

[0126] ->show_service

[0127] #Show server configuration

[0128] 1,localmirror=HIDDEN_PATH

[0129] #1 is a local image. Usually, the local image is hidden and protected, and no path is provided for viewing.

[0130] 2,remotemirror=ftp: / / ip_of_server / path_to_service_root

[0131] #2 is the remote mirror path, path_to_service_root is the path provided by the server->select_service 2

[0132] #Select the second server as the preferred server

[0133] ->show_service

[0134] # Check the server configuration again. You can see that the preferred server has been switched to the remote server.

[0135] 1,remotemirror=ftp: / / ip_of_server / path_to_service_root

[0136] 2, localmirror = HIDDEN_PATH

[0137] ->check_service 1

[0138] #Check the preferred server, and it will show that it is not synchronized with the local server.

[0139] Remotemirror not syncd

[0140] ->sync

[0141] #Execute synchronous actions

[0142] ->show_service

[0143] #After executing synchronization, check the server again and you will find that the preferred server has been switched to the local source

[0144] 1,localmirror=HIDDEN_PATH

[0145] 2,remotemirror=ftp: / / ip_of_server / path_to_service_root

[0146] ->check_service 2

[0147] #Check the remote server at this time, you will see that the remote source and the local source are synchronized

[0148] Remotemirror synced

[0149] After the device restarts, it will use the version specified in the above process.

[0150] On the server or device side, there may be multiple device upgrade actions. To save space, you can execute service_gc to clean up local sources after a certain period of time.

[0151] On the service side, local source cleanup usually involves retaining the latest version of all current devices, specifically:

[0152]

[0153]

[0154] On the device side, cleanup usually involves retaining the version currently in use, specifically:

[0155]

[0156] All directories corresponding to the HASH values ​​referenced in the profile are retained, and all unreferenced directories are cleared to save space.

[0157] Fourth, when using it, set the device node to synchronize the server data. The IP_OF_WORK_[X] in the following text indicates the IP configured as a certain node:

[0158] NODE1 is configured as:

[0159] [mirrorlist]

[0160] IP_OF_WORK_STATION

[0161] NODE2 is configured as:

[0162] [mirrorlist]

[0163] IP_OF_NODE1

[0164] NODE3 is configured as:

[0165] [mirrorlist]

[0166] IP_OF_NODE1

[0167] NODE4 is configured as:

[0168] [mirrorlist]

[0169] IP_OF_NODE1

[0170] NODE5 is configured as:

[0171] [mirrorlist]

[0172] IP_OF_NODE1

[0173] NODE6 is configured as:

[0174] [mirrorlist]

[0175] IP_OF_NODE5

[0176] NODE7 is configured as:

[0177] [mirrorlist]

[0178] IP_OF_NODE5

[0179] NODE8 is configured as:

[0180] [mirrorlist]

[0181] IP_OF_NODE5

[0182] When any node starts synchronization, it first needs to use check_service to check the integrity and reliability of the synchronization source. For node 8, since it is set to synchronize from node 5, it is necessary to check node 5. However, it is very likely that when synchronization is started, node 5 has not yet officially prepared the data and needs to wait. After check_service passes the integrity and reliability check, subsequent synchronization actions can be performed.

[0183] The cluster device software management device in the embodiment of the present invention includes a software package splitting module, a device software package creating module and a download server.

[0184] The software package splitting module is used to: split the software package of each device into multiple sub-packages, place all the sub-packages in a unified format, and the directory name of each sub-package is unique; the rules of the software package splitting module for splitting the software package of each device into multiple sub-packages include: splitting the software package of each device into multiple sub-packages according to the CPU architecture, chip and function used by each device; there is a description file in the sub-package for obtaining complete information of the software package; the directory name of the sub-package is its own hash value.

[0185] The device software package creation module is used to: create a device software package, the directory information of the device software package includes specific device information, and each device information under the specific device information directory will be associated with the placement location of the required sub-package; specifically, the description information of the device software package includes 2 levels of sub-directories, the first level is the product, and the second level is the specific device information, and each device information under the specific device information directory is associated with the required sub-package with the hash value.

[0186] The download server is used to deploy the device software package and all sub-software packages to form a download source for cluster devices to download and synchronize.

[0187] The device also includes a software source management module arranged on each node device, which is used to: before device synchronization, determine whether the current node device is an edge node, if so, configure the node device to only manage local node data; otherwise, use the node device as a server for the downstream node device, and request and cache the resources required by the downstream node device from the upstream device.

[0188] The software source management module requests the upstream device and caches the resources required by the downstream node device in any of the following two ways:

[0189] (1) A cache area of ​​a specified size is set for the current node device to store the resources required by the downstream node device. When the downstream node requests a resource, the current node device determines whether the resource size is greater than the remaining capacity of the cache area. If so, after clearing the cache area, the current node device requests the resources required by the downstream node device from the upstream device and synchronizes them to the cache area. Otherwise, the current node device directly requests the resources required by the downstream node device from the upstream device and synchronizes them to the cache area for download by the downstream node device.

[0190] (2) Cache the resources required by the specified downstream node device.

[0191] Before device synchronization, the software source management module is also used to:

[0192] (1) Adding a synchronization source, the synchronization source includes a remote source and a local synchronization source, the remote source includes the download source; the local synchronization source includes a local specified path or an external storage path;

[0193] (2) Select the synchronization source: that is, specify a synchronization source as the preferred source. When the remote source data is synchronized with the local internal storage data, the preferred source automatically switches to the local synchronization source.

[0194] (3) Check the synchronization source: Determine whether the preferred source is synchronized with the local synchronization source. If so, no synchronization is required. Otherwise, the software version information related to the device in the preferred source is displayed, and a version in the preferred source is selected as the version to be used for the next startup.

[0195] (4) Local source management service: When a node device synchronizes only the resources required by its own device, it configures the information required for synchronization of its own device; when a node device is a server for a downstream node, it configures the information required for synchronization of the downstream device.

[0196] It will be appreciated by those skilled in the art that all or some of the steps, systems, and functional modules / units in the methods disclosed above may be implemented as software, firmware, hardware, and appropriate combinations thereof. In a hardware implementation, the division between the functional modules / units mentioned in the above description does not necessarily correspond to the division of physical components; for example, a physical component may have multiple functions, or a function or step may be performed by several physical components in cooperation. Some or all physical components may be implemented as software executed by a processor, such as a central processing unit, a digital signal processor, or a microprocessor, or may be implemented as hardware, or may be implemented as an integrated circuit, such as an application-specific integrated circuit. Such software may be distributed on a computer-readable storage medium, which may include a computer-readable storage medium (or a non-transitory medium) and a communication medium (or a temporary medium).

[0197] As is known to those of ordinary skill in the art, the term computer-readable storage media includes volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storing information (such as computer-readable instructions, data structures, program modules or other data). Computer-readable storage media include, but are not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disk (DVD) or other optical disk storage, magnetic cassettes, magnetic tapes, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to store the desired information and can be accessed by a computer. In addition, it is known to those of ordinary skill in the art that communication media typically contain computer-readable instructions, data structures, program modules or other data in a modulated data signal such as a carrier wave or other transmission mechanism, and may include any information delivery medium.

[0198] Exemplarily, the computer-readable storage medium may be an internal storage unit of the electronic device of the aforementioned embodiment, such as a hard disk or memory of the electronic device. The computer-readable storage medium may also be an external storage device of the electronic device, such as a plug-in hard disk, a smart memory card (Smart Media Card, SMC), a secure digital (SecureDigital, SD) card, a flash card (Flash Card), etc. equipped on the electronic device.

[0199] The above are only specific implementations of the embodiments of the present invention, but the protection scope of the embodiments of the present invention is not limited thereto. Any technician familiar with the technical field can easily think of various equivalent modifications or replacements within the technical scope disclosed in the embodiments of the present invention, and these modifications or replacements should be included in the protection scope of the embodiments of the present invention. Therefore, the protection scope of the embodiments of the present invention shall be based on the protection scope of the claims.

Claims

1. A cluster device software management method, characterized in that: The method comprises the following steps: Step A: split the software package of each device into multiple sub-software packages, place all the sub-software packages in a unified format, and the directory name of each sub-software package is unique; Step B: Create a device software package. The directory information of the device software package includes specific device information. Each piece of device information under the specific device information directory is associated with the placement location of the required sub-package. Step C: deploy the device software package and all sub-software packages to form a download source for cluster devices to download and synchronize.

2. The cluster device software management method according to claim 1, characterized in that: Before device synchronization, the following steps are also included: determine whether the current node device is an edge node. If so, configure the node device to only manage local node data; otherwise, use the node device as a server for the downstream node device, and request and cache the resources required by the downstream node device from the upstream device.

3. The cluster device software management method according to claim 2, characterized in that: The method of requesting and caching the resources required by the downstream node device from the upstream device includes any one of the following two methods: (1) A cache area of ​​a specified size is set for the current node device to store the resources required by the downstream node device. When the downstream node requests a resource, the current node device determines whether the resource size is greater than the remaining capacity of the cache area. If so, after clearing the cache area, the current node device requests the resources required by the downstream node device from the upstream device and synchronizes them to the cache area. Otherwise, the current node device directly requests the resources required by the downstream node device from the upstream device and synchronizes them to the cache area for download by the downstream node device. (2) Cache the resources required by the specified downstream node device.

4. The cluster device software management method according to claim 2, characterized in that: Before synchronizing the devices, the following settings need to be performed on each node device: (1) Add synchronization sources, which include remote sources and local synchronization sources. The remote source includes the download source in step C; the local synchronization source includes a local specified path or an external storage path; (2) Select the synchronization source: that is, specify a synchronization source as the preferred source. When the remote source data is synchronized with the local internal storage data, the preferred source automatically switches to the local synchronization source. (3) Check the synchronization source: Determine whether the preferred source is synchronized with the local synchronization source. If so, no synchronization is required. Otherwise, the software version information related to the device in the preferred source is displayed, and a version in the preferred source is selected as the version to be used for the next startup. (4) Local source management service: When a node device synchronizes only the resources required by its own device, it configures the information required for synchronization of its own device; when a node device is a server for a downstream node, it configures the information required for synchronization of the downstream device.

5. The cluster device software management method according to any one of claims 1 to 4, characterized in that: The rules for splitting the software package of each device into multiple sub-software packages in step A include: splitting the software package of each device into multiple sub-software packages according to the CPU architecture, chip and function used by each device; a description file for obtaining complete information of the software package exists in the sub-software package; the directory name of the sub-software package is its own hash value; the description information of the device software package in step B includes two levels of sub-directories, the first level is the product, and the second level is the specific device information, and each device information under the specific device information directory is associated with the required sub-software package with the hash value.

6. A cluster equipment software management device, characterized in that: The device comprises a software package splitting module, a device software package creating module and a download server; The software package splitting module is used to split the software package of each device into multiple sub-packages, and place all sub-packages in a unified format. The directory name of each sub-package is unique. The device software package creation module is used to: create a device software package, the directory information of the device software package includes specific device information, and each device information under the specific device information directory will be associated with the placement location of the required sub-package; The download server is used to deploy the device software package and all sub-software packages to form a download source for cluster devices to download and synchronize.

7. The cluster device software management device according to claim 6, characterized in that: The device also includes a software source management module arranged on each node device, which is used to: before device synchronization, determine whether the current node device is an edge node, if so, configure the node device to only manage local node data; otherwise, use the node device as a server for the downstream node device, and request and cache the resources required by the downstream node device from the upstream device.

8. The cluster device software management device according to claim 7, characterized in that: The software source management module requests the upstream device and caches the resources required by the downstream node device in any one of the following two ways: (1) A cache area of ​​a specified size is set for the current node device to store the resources required by the downstream node device. When the downstream node requests a resource, the current node device determines whether the resource size is greater than the remaining capacity of the cache area. If so, after clearing the cache area, the current node device requests the resources required by the downstream node device from the upstream device and synchronizes them to the cache area. Otherwise, the current node device directly requests the resources required by the downstream node device from the upstream device and synchronizes them to the cache area for download by the downstream node device. (2) Cache the resources required by the specified downstream node device.

9. The cluster device software management device according to claim 7, characterized in that: Before the device is synchronized, the software source management module is also used to: (1) Adding a synchronization source, the synchronization source includes a remote source and a local synchronization source, the remote source includes the download source; the local synchronization source includes a local specified path or an external storage path; (2) Select the synchronization source: that is, specify a synchronization source as the preferred source. When the remote source data is synchronized with the local internal storage data, the preferred source automatically switches to the local synchronization source. (3) Check the synchronization source: Determine whether the preferred source is synchronized with the local synchronization source. If so, no synchronization is required. Otherwise, the software version information related to the device in the preferred source is displayed, and a version in the preferred source is selected as the version to be used for the next startup. (4) Local source management service: When a node device synchronizes only the resources required by its own device, it configures the information required for synchronization of its own device; when a node device is a server for a downstream node, it configures the information required for synchronization of the downstream device.

10. The cluster device software management device according to any one of claims 6 to 9, characterized in that: The rules for the software package splitting module to split the software package of each device into multiple sub-software packages include: splitting the software package of each device into multiple sub-software packages according to the CPU architecture, chip and function used by each device; a description file for obtaining complete information of the software package exists in the sub-software package; the directory name of the sub-software package is its own hash value; the description information of the device software package created by the device software package creation module includes two levels of sub-directories, the first level is the product, and the second level is the specific device information, and each device information under the specific device information directory is associated with the required sub-software package by the hash value.

Images