Upgrading method, device and system of host in cluster, equipment and medium

Abstract

The invention provides a method, a device, a system and equipment for upgrading hosts in a cluster and a medium. The method comprises the following steps: determining current version information of a target host and version information of other hosts except the target host; when the version information of the other hosts is higher than the current version information of the target host, receiving a first upgrade package from the other hosts of which the version information is higher than the current version information of the target host; and upgrading the target host according to the first upgrade package. Based on the peer-to-peer network, data interaction between hosts can be realized to finish upgrading of the hosts in the cluster; compared with an upgrading scheme completely relying on a central server, the cluster in the application can complete data interaction of the whole cluster through interaction between hosts only by obtaining the upgrading package, and the problems of bandwidth bottleneck, single-point fault risk, service interruption in the upgrading process and the like do not exist.

Description

TECHNICAL FIELD

[0001] The application belongs to the technical field of data processing, and particularly relates to a host upgrading method, device, system, equipment and medium in a cluster. BACKGROUND

[0002] In the related art, a cluster can include multiple hosts; when the multiple hosts in the cluster are upgraded by OTA (Over-The-Air), the multiple hosts depend on a central server for firmware pushing, and there are bandwidth bottlenecks, single-point failure risks, and service interruption problems in the upgrading process. SUMMARY

[0003] In view of the above problems, a host upgrading method, device, system, equipment and medium in a cluster are provided to overcome the above problems or at least partially solve the above problems, comprising: A host upgrading method in a cluster, the cluster including multiple hosts, a peer-to-peer network being established between the multiple hosts, and the method comprising: determining current version information of a target host and version information of other hosts except the target host; when the version information of the other hosts is higher than the current version information of the target host, receiving a first upgrade package from the other hosts whose version information is higher than the current version information of the target host; upgrading the target host according to the first upgrade package.

[0004] In some embodiments, the method further comprises: determining a current resource usage of a host and a historical usage pattern; determining an upgrading sequence of the host according to the current resource usage and the historical usage pattern; when the upgrading sequence of the target host is reached, performing the step of upgrading the target host according to the first upgrade package.

[0005] In some embodiments, the determining of the upgrading sequence of the host according to the current resource usage and the historical usage pattern comprises: determining a current load rate of the host according to the current resource usage; and predicting a remaining duration of the host from a peak load time according to the historical usage pattern; determining a priority of the host according to the current load rate and the remaining duration; determining the upgrading sequence of the host according to the priority of the host.

[0006] In some embodiments, when the target host is a bootstrap node, the target host is also connected with a central server; the method further comprises: receiving a second upgrade package issued by the central server; upgrading the target host according to the second upgrade package, and broadcasting the second upgrade package to the other hosts after the upgrade is completed.

[0007] In some embodiments, when the target host is a non-bootstrap node, the method further comprises: broadcasting the upgrade completion to the other hosts; and broadcasting the first upgrade package to the other hosts.

[0008] In some embodiments, when the target host is a node newly added to the cluster, the method further comprises: querying version information in the hosts, and determining a neighboring node of the target host from the other hosts; when the version information of the neighboring node is the highest, receiving a third upgrade package from the neighboring node; when the version information of the neighboring node is not the highest, receiving the third upgrade package from the host with the highest version information.

[0009] In some embodiments, the method further comprises: performing integrity verification on the first upgrade package; when the integrity verification of the first upgrade package is passed, performing the step of upgrading the target host according to the first upgrade package.

[0010] In some embodiments, the target host stores a snapshot of the current version; the method further comprises: detecting the upgrade process of the target host when upgrading the target host according to the first upgrade package; when the upgrade process of the target host is abnormal, restoring the target host according to the snapshot.

[0011] The application also provides a cluster system, the cluster comprising a plurality of hosts, a peer-to-peer network being established between the plurality of hosts; an upgrade method of the host in the cluster being applied, the system comprising: a communication module for realizing communication between the plurality of hosts; a load scheduling module for detecting the current resource usage and the historical usage mode of the host, and determining the upgrade sequence of the host according to the current resource usage and the historical usage mode; a security verification module for encrypting and decrypting the upgrade package; An upgrading execution module is configured to upgrade the host according to the upgrading sequence.

[0012] The application further provides an upgrading device for hosts in a cluster, wherein the cluster comprises a plurality of hosts, and a peer-to-peer network is established between the plurality of hosts, and the device comprises: A determination module is configured to determine current version information of a target host and version information of other hosts except the target host; A receiving module is configured to receive a first upgrading package from the other host whose version information is higher than the current version information of the target host when the version information of the other host is higher than the current version information of the target host; An upgrading module is configured to upgrade the target host according to the first upgrading package.

[0013] In some embodiments, the receiving module is further configured to determine a current resource usage and a historical usage mode of the host, determine an upgrading sequence of the host according to the current resource usage and the historical usage mode, and perform the step of upgrading the target host according to the first upgrading package when the upgrading sequence of the target host is reached.

[0014] In some embodiments, the receiving module is configured to determine a current load rate of the host according to the current resource usage, predict a remaining time length of the host from a peak load time according to the historical usage mode, determine a priority of the host according to the current load rate and the remaining time length, and determine the upgrading sequence of the host according to the priority of the host.

[0015] In some embodiments, the upgrading module is further configured to connect the target host to a central server when the target host is a bootstrap node, receive a second upgrading package issued by the central server, upgrade the target host according to the second upgrading package, and broadcast the second upgrading package to the other hosts after the upgrading is completed.

[0016] In some embodiments, the upgrading module is further configured to broadcast the upgrading completion to the other hosts and broadcast the first upgrading package to the other hosts when the target host is a non-bootstrap node.

[0017] In some embodiments, the upgrading module is further configured to query version information in the host and determine a neighboring node of the target host from the other hosts when the target host is a node newly added to the cluster, receive a third upgrading package from the neighboring node when the version information of the neighboring node is the highest, and receive the third upgrading package from the host with the highest version information when the version information of the neighboring node is not the highest.

[0018] In some embodiments, the upgrade module is further configured to perform integrity verification on the first upgrade package; when the integrity verification of the first upgrade package passes, the module executes the step of upgrading the target host according to the first upgrade package.

[0019] In some embodiments, the target host stores a snapshot of the current version; the upgrade module is further configured to detect the upgrade process of the target host when upgrading the target host according to the first upgrade package; and to restore the target host according to the snapshot when the upgrade process of the target host is abnormal.

[0020] This application also provides an electronic device, including a processor, a memory, and a computer program stored in the memory and capable of running on the processor, wherein the computer program, when executed by the processor, implements the above-described method for upgrading hosts in a cluster.

[0021] This application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described method for upgrading hosts in a cluster.

[0022] This application has the following advantages: In this application, the current version information of the target host and the version information of other hosts besides the target host are determined. When the version information of other hosts is higher than the current version information of the target host, a first upgrade package is received from the other hosts whose version information is higher than the current version information of the target host. The target host is then upgraded according to the first upgrade package. This application relies on a peer-to-peer network, which enables data interaction between hosts to complete the upgrade of hosts in the cluster. Compared with upgrade schemes that rely entirely on a central server, the cluster in this application only needs to obtain the upgrade package to complete the data interaction of the entire cluster through interaction between hosts. There are no issues such as bandwidth bottlenecks, single points of failure risk, or service interruptions during the upgrade process. Attached Figure Description

[0023] The above and / or additional aspects and advantages of this application will become apparent and readily understood from the description of the embodiments taken in conjunction with the following drawings, in which: Figure 1 This is a flowchart illustrating the steps of an upgrade method for a host in a cluster according to an embodiment of this application. Figure 2 This is a flowchart illustrating the steps of another method for upgrading a host in a cluster according to an embodiment of this application; Figure 3 This is a flowchart illustrating the steps of another method for upgrading a host in a cluster according to an embodiment of this application; Figure 4This is a flowchart illustrating the steps of another method for upgrading a host in a cluster according to an embodiment of this application; Figure 5 This is a flowchart illustrating the steps of another method for upgrading a host in a cluster according to an embodiment of this application; Figure 6 This is a schematic diagram illustrating an upgraded implementation process of an embodiment of this application; Figure 7 This is a schematic diagram of the structure of a cluster system according to an embodiment of this application; Figure 8 This is a schematic diagram of the structure of another cluster system according to an embodiment of this application; Figure 9 This is a schematic diagram of the structure of an upgrade device for a host in a cluster according to an embodiment of this application. Detailed Implementation

[0024] To make the above-mentioned objectives, features, and advantages of this application more apparent and understandable, the application will be further described in detail below with reference to the accompanying drawings and specific embodiments. Obviously, the described embodiments are only some, not all, of the embodiments of this application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.

[0025] To avoid bandwidth bottlenecks, single points of failure, and service interruptions during the upgrade process when upgrading multiple hosts in a cluster, this application provides a method for upgrading hosts in a cluster. This method relies on a peer-to-peer network to enable data interaction between hosts to complete the upgrade. Compared to upgrade schemes that rely entirely on a central server, the cluster in this application only needs to obtain the upgrade package to complete the data interaction of the entire cluster through interaction between hosts, thus eliminating bandwidth bottlenecks, single points of failure, and service interruptions during the upgrade process.

[0026] Reference Figure 1 The diagram illustrates a flowchart of a method for upgrading a host in a cluster according to an embodiment of this application, which may include the following steps: Step 101: Determine the current version information of the target host, as well as the version information of other hosts besides the target host.

[0027] In some embodiments of this application, the cluster may include multiple hosts, and a peer-to-peer (P2P) network may be established between these multiple hosts; the core role of the peer-to-peer network in this application is to realize decentralized dynamic collaboration. Specific effects: (1) Through P2P (such as the DHT (Distributed Hash Table) protocol), after the upgrade package is distributed from the central server, it is automatically forwarded between hosts, reducing server bandwidth pressure and avoiding single points of failure. (2) DHT maintains a list of hosts, and when a new host joins, it automatically discovers the cluster by querying neighboring nodes, realizing firmware synchronization. (3) The P2P network provides real-time node status information, which can be used to dynamically determine the upgrade order.

[0028] In some embodiments, a distributed hash table (DHT) can be used to maintain a list of hosts and version information of their firmware, software, system, etc. This table can be used by the host to determine whether an upgrade is needed.

[0029] For example, the target host can first determine its own version information, i.e., its current version information; in addition, the target host can periodically exchange version information with other hosts via the DHT protocol. The version information can be the host's own version information stored in the DJT, for example, it can include key-value pairs: host ID → firmware version.

[0030] Step 102: When the version information of other hosts is higher than the current version information of the target host, receive the first upgrade package from other hosts whose version information is higher than the current version information of the target host.

[0031] After obtaining version information from other hosts, the target host can compare its current version information with that of other hosts. For example, version information can be represented by an incrementing version number; the larger the version number, the newer the firmware version on the host.

[0032] In some embodiments, if the target host determines that at least one of the other hosts has a version information higher than the target host's current version information, the target host can receive the first upgrade package from that other host whose version information is higher than the target host's current version information. For example, the target host can actively request the first upgrade package, or it can receive it when the other host sends the first upgrade package.

[0033] Conversely, if the target host determines that no other host has a version information higher than its current version information, then the target host may choose not to actively request the first upgrade package or accept the first upgrade package sent by other hosts.

[0034] The first upgrade package can be an upgrade package issued by the central server to the cluster and interacted between the clusters. It can be used for firmware upgrades, software upgrades, system upgrades, etc. of the host. This application embodiment does not limit this.

[0035] Step 103: Upgrade the target host according to the first upgrade package.

[0036] After receiving the first upgrade package, the target host can upgrade its firmware, software, and system based on the package. Compared to obtaining the upgrade package directly from a central server, this application leverages a peer-to-peer network to enable data exchange between hosts to complete the upgrade of hosts within the cluster. Compared to upgrade schemes that rely entirely on a central server, the cluster in this application only needs to obtain the upgrade package to complete data exchange across the entire cluster through host-to-host interaction, eliminating bandwidth bottlenecks, single points of failure, and service interruptions during the upgrade process.

[0037] In this embodiment, the current version information of the target host and the version information of other hosts besides the target host are determined. When the version information of other hosts is higher than the current version information of the target host, a first upgrade package is received from the other hosts whose version information is higher than the current version information of the target host. The target host is then upgraded according to the first upgrade package. This application relies on a peer-to-peer network, which enables data interaction between hosts to complete the upgrade of hosts in the cluster. Compared with upgrade schemes that rely entirely on a central server, the cluster in this application only needs to obtain the upgrade package to complete the data interaction of the entire cluster through interaction between hosts. There are no issues such as bandwidth bottlenecks, single point of failure risks, or service interruptions during the upgrade process.

[0038] Reference Figure 2 The diagram illustrates a flowchart of another method for upgrading a host in a cluster according to an embodiment of this application, which may include the following steps: Step 201: Determine the current version information of the target host, as well as the version information of other hosts besides the target host.

[0039] For example, the target host can first determine its own version information, i.e., the current version information; in addition, the target host can periodically exchange version information with other hosts besides the target host through the DHT protocol.

[0040] Step 202: When the version information of other hosts is higher than the current version information of the target host, receive the first upgrade package from other hosts whose version information is higher than the current version information of the target host.

[0041] After obtaining version information from other hosts, the target host can compare its current version information with that of other hosts. For example, version information can be represented by an incrementing version number; the larger the version number, the newer the firmware version on the host.

[0042] In some embodiments, if the target host determines that at least one of the other hosts has a version information higher than the target host's current version information, the target host can receive the first upgrade package from that other host whose version information is higher than the target host's current version information. For example, the target host can actively request the first upgrade package, or it can receive it when the other host sends the first upgrade package.

[0043] Conversely, if the target host determines that no other host has a version information higher than its current version information, then the target host may choose not to actively request the first upgrade package or accept the first upgrade package sent by other hosts.

[0044] Step 203: Determine the current resource usage of the host and its historical usage patterns.

[0045] In some embodiments, the upgrade order of the target host can be determined before the upgrade is performed; the upgrade order can be used to characterize when the target data will be upgraded. For example, if the upgrade order is [2:00 AM - 4:00 AM], then the target host can perform the upgrade action between 2:00 AM and 4:00 AM.

[0046] In this application embodiment, when determining the upgrade order of the target host, the current resource usage and historical usage patterns of the host can be determined first. For example, the current resource usage may include the host's CPU usage, memory usage, network metrics, etc.; the historical usage patterns can be used to characterize the host's historical usage, such as historical load peak times, etc.

[0047] Step 204: Determine the upgrade order of the host based on the current resource usage and historical usage patterns.

[0048] After determining the current resource usage and historical usage patterns, the upgrade order of hosts can be determined based on these factors. For example, this step of determining the upgrade order can be done by the target host itself; that is, the target host determines its own situation based on the current resource usage and historical usage patterns, and then determines the upgrade order of the target host by interacting with other hosts.

[0049] In another example, the target host can determine the current resource usage and historical usage patterns of all hosts, and further determine the upgrade order of each host based on the current resource usage and historical usage patterns of all hosts. This application embodiment does not limit this.

[0050] In some embodiments of this application, step 204 can be implemented by the following sub-steps: Sub-step 11: Determine the current load rate of the host based on the current resource usage.

[0051] In some embodiments, after determining the current resource usage, the current load rate of the host can be determined based on the current resource usage; for example, the current load rate of the target host can be determined.

[0052] Specifically, current resource usage can include host CPU usage, memory usage, network metrics, etc. After determining the current resource usage, the host load can be comprehensively evaluated from multiple dimensions such as host CPU usage, memory usage, and network metrics to determine the host's current load rate.

[0053] Sub-step 12: Based on historical usage patterns, predict the remaining time before the host reaches peak load.

[0054] In some embodiments, after determining historical usage patterns, the time of the next load peak of the host can also be predicted based on the historical usage patterns; then, based on that time, the remaining time before the peak load moment of the host can be predicted.

[0055] Sub-step 13: Determine the priority of the host based on the current load rate and remaining time.

[0056] In some embodiments, after determining the current load rate and remaining time, the priority of a host can be determined based on the current load rate and remaining time; for example, the priority of a target host can be determined based on the current load rate and remaining time of the target host.

[0057] Specifically, the host's priority can be calculated using the following formula: Priority = α × (1 - current load rate) + β × remaining time; Wherein, α and β are preset weights, and their values ​​can be set according to the actual situation; for example, α=0.6, β=0.4, but this application embodiment does not limit this.

[0058] For example, if the next peak load time for the host is between 8 and 10 pm, the larger the remaining time before that time, the higher the priority.

[0059] Sub-step 14: Determine the upgrade order of hosts based on their priority. After determining the priorities of the hosts, the upgrade order can be determined based on these priorities; for example, hosts with lower scores can be upgraded first. By upgrading low-load hosts first, it ensures that high-load hosts in the cluster always maintain service, achieving a smooth transition. This order is dynamically adjusted: if the load of a low-load host increases, its priority can be recalculated in real time, postponing its upgrade.

[0060] In some embodiments, the priority of all hosts can be determined by a single host, such as the target host, or by each host itself, and then the upgrade order of the hosts can be determined through interaction between the hosts. Alternatively, additional devices, such as a central server or a scheduling module, can determine the upgrade order of the hosts. This application does not impose any restrictions on this.

[0061] Step 205: When the upgrade sequence of the target host is reached, upgrade the target host according to the first upgrade package.

[0062] Once the upgrade order of the target host is determined, the target host can be upgraded according to the first upgrade package when the upgrade order of the target host is reached.

[0063] In some embodiments of this application, the above method may further include the following steps: Perform integrity verification on the first upgrade package; if the integrity verification of the first upgrade package passes, execute the steps to upgrade the target host based on the first upgrade package.

[0064] In some embodiments, after receiving the first upgrade package, the target host can first verify the integrity of the first upgrade package; for example, a hash algorithm or digital signature can be used to verify whether the first upgrade package is completely consistent with the original file provided by the publisher, so as to prevent the file from being tampered with, damaged or replaced. The digital signature can also simultaneously verify the publisher's identity and legitimacy.

[0065] Once the integrity verification of the first upgrade package is successful, the target host can perform the upgrade based on the first upgrade package.

[0066] In some embodiments of this application, the above method may further include the following steps: The target host stores a snapshot of the current version; when upgrading the target host according to the first upgrade package, the upgrade process of the target host is detected; when there is an anomaly in the upgrade process of the target host, the target host is restored according to the snapshot.

[0067] In some embodiments, the target host may also store a snapshot of the current version of firmware, software, or system for use in version rollback.

[0068] After receiving the first upgrade package, the target host can upgrade according to the first upgrade package. If the upgrade is successful, the target host can act as a new seed and automatically forward the first upgrade package to neighboring nodes, thereby achieving efficient distribution.

[0069] Conversely, if an anomaly occurs during the upgrade process of the target host based on the first upgrade package, the target host can be restored based on the snapshot.

[0070] In this embodiment, the current version information of the target host and the version information of other hosts besides the target host are determined. When the version information of other hosts is higher than the current version information of the target host, a first upgrade package is received from the other hosts whose version information is higher than the current version information of the target host. The current resource usage and historical usage patterns of the hosts are determined. Based on the current resource usage and historical usage patterns, the upgrade order of the hosts is determined. When the upgrade order of the target host is reached, the target host is upgraded according to the first upgrade package. This application relies on a peer-to-peer network, which can realize data interaction between hosts to complete the upgrade of hosts in the cluster. Compared with the upgrade scheme that relies entirely on a central server, the cluster in this application only needs to obtain the upgrade package, and can complete the data interaction of the entire cluster through interaction between hosts. There are no problems such as bandwidth bottlenecks, single point of failure risks, and service interruptions during the upgrade process.

[0071] Furthermore, low-load hosts are upgraded based on real-time load data to avoid service interruptions. Unlike static broadcast or unicast, dynamic load balancing scheduling uses real-time load assessment to determine the upgrade order, reducing downtime and improving cluster availability.

[0072] Reference Figure 3 The diagram illustrates a flowchart of another method for upgrading a host in a cluster according to an embodiment of this application, which may include the following steps: Step 301: When the target host is the boot node, the target host is also connected to the central server and receives the second upgrade package issued by the central server.

[0073] In this embodiment, the target host is designated as the bootstrap node; it can act as the initial leader to receive the upgrade package issued by the central server. For example, to distinguish it from the aforementioned upgrade package, this upgrade package is referred to as the second upgrade package. In reality, the first, second, and third upgrade packages can be the same or different.

[0074] In some embodiments, each host runs the DHT protocol to establish a peer-to-peer network. The target host, acting as the initial leader, maintains a version list (v1.0) (the version list is maintained in a distributed manner via the DHT protocol: each host stores its own version information in the DHT (key-value pairs: host ID → firmware version). Hosts periodically exchange version information via the DHT protocol and use the gossip protocol to propagate updates, ensuring eventual consistency), and starts the DHT network as the bootstrap node. After the central server releases the second upgrade package, it can first distribute it to the target host; after receiving the second upgrade package, the target host can distribute it to neighboring nodes; the neighboring nodes can then distribute it to neighboring nodes, thereby completing the upgrade of the entire cluster.

[0075] Step 302: Upgrade the target host according to the second upgrade package, and broadcast the second upgrade package to other hosts after the upgrade is completed.

[0076] In some embodiments, after receiving the second upgrade package, the target host can perform an upgrade based on the second upgrade package.

[0077] After the target host completes the upgrade according to the second upgrade package, it can broadcast the second upgrade package to other hosts, thereby completing the upgrade of the entire cluster.

[0078] Step 303: Determine the current version information of the target host, as well as the version information of other hosts besides the target host.

[0079] In some embodiments, the bootstrap node may include more than just the target host; therefore, the host with the highest version in the cluster may not be the target host. During routine maintenance, the target host can periodically determine its current version information, and the version information of other hosts besides the target host can be determined interactively.

[0080] Step 304: When the version information of other hosts is higher than the current version information of the target host, receive the first upgrade package from other hosts whose version information is higher than the current version information of the target host.

[0081] After obtaining version information from other hosts, the target host can compare its current version information with that of other hosts. For example, version information can be represented by an incrementing version number; the larger the version number, the newer the firmware version on the host.

[0082] In some embodiments, if the target host determines that at least one of the other hosts has a version information higher than the target host's current version information, the target host can receive the first upgrade package from that other host whose version information is higher than the target host's current version information. For example, the target host can actively request the first upgrade package, or it can receive it when the other host sends the first upgrade package.

[0083] Conversely, if the target host determines that no other host has a version information higher than its current version information, then the target host may choose not to actively request the first upgrade package or accept the first upgrade package sent by other hosts.

[0084] Step 305: Upgrade the target host according to the first upgrade package.

[0085] After receiving the first upgrade package, the target host can upgrade its firmware, software, and system based on the package. Compared to obtaining the upgrade package directly from a central server, this application leverages a peer-to-peer network to enable data exchange between hosts to complete the upgrade of hosts within the cluster. Compared to upgrade schemes that rely entirely on a central server, the cluster in this application only needs to obtain the upgrade package to complete data exchange across the entire cluster through host-to-host interaction, eliminating bandwidth bottlenecks, single points of failure, and service interruptions during the upgrade process.

[0086] In this embodiment, when the target host is the bootstrap node, it is also connected to a central server; receives a second upgrade package from the central server; upgrades the target host according to the second upgrade package, and broadcasts the second upgrade package to other hosts after the upgrade is completed; determines the current version information of the target host and the version information of other hosts besides the target host; when the version information of other hosts is higher than the current version information of the target host, receives a first upgrade package from other hosts whose version information is higher than the current version information of the target host; and upgrades the target host according to the first upgrade package. This application relies on a peer-to-peer network, enabling data interaction between hosts to complete the upgrade of hosts in the cluster. Compared to upgrade schemes that rely entirely on a central server, the cluster in this application only needs to obtain the upgrade package to complete the data interaction of the entire cluster through interaction between hosts, eliminating bandwidth bottlenecks, single point of failure risks, and service interruptions during the upgrade process.

[0087] Reference Figure 4 The diagram illustrates a flowchart of another method for upgrading a host in a cluster according to an embodiment of this application, which may include the following steps: Step 401: Determine the current version information of the target host, as well as the version information of other hosts besides the target host.

[0088] In this embodiment of the application, the target host can be a non-booting node, that is, it does not directly receive upgrade packages from the central server.

[0089] Based on the above premises, the target host can first determine its own version information, that is, the current version information; in addition, the target host can also periodically exchange version information with other hosts besides the target host through the DHT protocol.

[0090] Step 402: When the version information of other hosts is higher than the current version information of the target host, receive the first upgrade package from other hosts whose version information is higher than the current version information of the target host.

[0091] After obtaining version information from other hosts, the target host can compare its current version information with that of other hosts. For example, version information can be represented by an incrementing version number; the larger the version number, the newer the firmware version on the host.

[0092] In some embodiments, if the target host determines that at least one of the other hosts has a version information higher than the target host's current version information, the target host can receive the first upgrade package from that other host whose version information is higher than the target host's current version information. For example, the target host can actively request the first upgrade package, or it can receive it when the other host sends the first upgrade package.

[0093] Conversely, if the target host determines that no other host has a version information higher than its current version information, then the target host may choose not to actively request the first upgrade package or accept the first upgrade package sent by other hosts.

[0094] Step 403: Upgrade the target host according to the first upgrade package.

[0095] After receiving the first upgrade package, the target host can upgrade its firmware, software, and system based on the package. Compared to obtaining the upgrade package directly from a central server, this application leverages a peer-to-peer network to enable data exchange between hosts to complete the upgrade of hosts within the cluster. Compared to upgrade schemes that rely entirely on a central server, the cluster in this application only needs to obtain the upgrade package to complete data exchange across the entire cluster through host-to-host interaction, eliminating bandwidth bottlenecks, single points of failure, and service interruptions during the upgrade process.

[0096] Step 404: When the target host is a non-boot node, broadcast the upgrade completion to other hosts.

[0097] In some embodiments, when the target host is a non-boot node, it can broadcast the completion of the upgrade to other hosts after it has completed the upgrade according to the first upgrade package.

[0098] Step 405: Broadcast the first upgrade package to other hosts.

[0099] In some embodiments, after the upgrade is complete, the target host can also act as a new seed to broadcast the first upgrade package to other hosts. For example, the target host can encrypt the first upgrade package before broadcasting the encrypted first upgrade package to other hosts.

[0100] In this embodiment, the current version information of the target host and the version information of other hosts besides the target host are determined; when the version information of other hosts is higher than the current version information of the target host, a first upgrade package is received from other hosts whose version information is higher than the current version information of the target host; the target host is upgraded according to the first upgrade package; when the target host is a non-boot node, the upgrade is broadcast to other hosts; the first upgrade package is broadcast to other hosts.

[0101] Reference Figure 5 The diagram illustrates a flowchart of another method for upgrading a host in a cluster according to an embodiment of this application, which may include the following steps: Step 501: When the target host is a newly added node in the cluster, query the version information in the host and determine the neighboring nodes of the target host from other hosts.

[0102] In some embodiments, the target host can also be a newly added node in the cluster; in related technologies, upgrades are achieved through a predefined list of nodes; however, due to the lack of dynamic discovery and real-time synchronization mechanisms, newly added hosts cannot automatically obtain the latest firmware version. Therefore, it is difficult to meet the elastic scaling requirements of the aftermarket host cluster.

[0103] To address this, this application proposes a method for upgrading hosts in a cluster. In this method, as a newly added node in the cluster, the target host can automatically synchronize and query and obtain the latest firmware through neighboring nodes. Through this application, the cluster supports dynamic expansion and is suitable for aftermarket installation scenarios.

[0104] Specifically, the target host can first query and determine the version information of each host in the cluster.

[0105] In some embodiments, the target host may also determine its neighboring nodes from other hosts.

[0106] For example, in a DHT network, the neighboring nodes of a target host can be determined by querying similarity based on node ID (such as XOR distance).

[0107] Step 502: When the version information of the neighboring node is the highest, receive the third upgrade package from the neighboring node.

[0108] After identifying the target host's neighboring nodes, their version numbers can be compared with those of other nodes. If a neighboring node has the highest version number, the target host can directly receive the third-party upgrade package from that neighboring node for the upgrade.

[0109] Step 503: When the version information of the neighboring node is not the highest, receive the third upgrade package from the host with the highest version information.

[0110] Conversely, if the version number in the version information of a neighboring node is not the highest, the target host can receive the third upgrade package from the host with the highest version number in the version information to complete the upgrade.

[0111] Step 504: Determine the current version information of the target host, as well as the version information of other hosts besides the target host.

[0112] After the target host is added to the cluster, the target host can periodically determine its own version information, i.e., the current version information; in addition, the target host can periodically exchange version information with other hosts besides the target host through the DHT protocol.

[0113] Step 505: When the version information of other hosts is higher than the current version information of the target host, receive the first upgrade package from other hosts whose version information is higher than the current version information of the target host.

[0114] After obtaining version information from other hosts, the target host can compare its current version information with that of other hosts. For example, version information can be represented by an incrementing version number; the larger the version number, the newer the firmware version on the host.

[0115] In some embodiments, if the target host determines that at least one of the other hosts has a version information higher than the target host's current version information, the target host can receive the first upgrade package from that other host whose version information is higher than the target host's current version information. For example, the target host can actively request the first upgrade package, or it can receive it when the other host sends the first upgrade package.

[0116] Conversely, if the target host determines that no other host has a version information higher than its current version information, then the target host may choose not to actively request the first upgrade package or accept the first upgrade package sent by other hosts.

[0117] Step 506: Upgrade the target host according to the first upgrade package.

[0118] After receiving the first upgrade package, the target host can upgrade its firmware, software, and system based on the package. Compared to obtaining the upgrade package directly from a central server, this application leverages a peer-to-peer network to enable data exchange between hosts to complete the upgrade of hosts within the cluster. Compared to upgrade schemes that rely entirely on a central server, the cluster in this application only needs to obtain the upgrade package to complete data exchange across the entire cluster through host-to-host interaction, eliminating bandwidth bottlenecks, single points of failure, and service interruptions during the upgrade process.

[0119] In this embodiment, when the target host is a newly added node in the cluster, the version information of the host is queried, and the neighboring nodes of the target host are determined from other hosts. When the version information of a neighboring node is the highest, a third upgrade package is received from the neighboring node. When the version information of a neighboring node is not the highest, the third upgrade package is received from the host with the highest version information. The current version information of the target host and the version information of other hosts besides the target host are determined. When the version information of other hosts is higher than the current version information of the target host, a first upgrade package is received from other hosts with version information higher than the current version information of the target host. The target host is upgraded according to the first upgrade package. Through this embodiment, the target host, as a newly added node in the cluster, can automatically synchronize and obtain the latest firmware by querying neighboring nodes. The cluster of this application supports dynamic expansion and is suitable for aftermarket installation scenarios.

[0120] Reference Figure 6 The diagram illustrates an upgraded implementation process of an embodiment of this application: 1. Cluster Initialization and P2P Network Construction: A multi-host cluster dynamically adds hosts via post-installation. A P2P network is established between the hosts, and a distributed hash table (DHT) is used to maintain the host list and firmware version information. When a new host joins, it automatically queries and synchronizes the latest firmware version from neighboring hosts. 2. Upgrade Package Preparation and Secure Distribution: The central server generates an encrypted upgrade package (using AES-256 combined with a double XOR mechanism) and distributes it via P2P network broadcast. Hosts within the cluster verify the integrity of the upgrade package, using a blockchain-inspired Merkle tree structure to ensure tamper-proof protection. 3. Load Balancing Upgrade Scheduling: Based on real-time cluster load and usage patterns, the upgrade order is dynamically determined. Low-load hosts are prioritized for upgrades, enabling rolling upgrades and avoiding simultaneous interruptions across the entire cluster. 4. Upgrade Execution and Rollback: The upgrade is performed on each host one by one. If any abnormality is detected during the monitoring process, the host is automatically rolled back to the previous version. After the upgrade is completed, the status update is broadcast to the cluster. 5. Dynamic Adaptation and Fault Handling: Supports real-time addition of newly installed hosts, optimizes cluster data sharing for future upgrade strategies, and allows remaining hosts to take over tasks from failed hosts.

[0121] Implementation details: Taking a home PC cluster as an example, assuming the cluster has 5 hosts (H1-H5), H6 is added later. Implementation steps: 1. Initialization: Each host runs the DHT protocol to establish a P2P network. H1, as the initial leader, maintains the version list (v1.0) (when a new host joins, it retrieves the latest version list through DHT query and updates its own status to synchronize with the new node), and acts as the bootstrap node to start the DHT network.

[0122] 2. Upgrade Package Distribution: The central server publishes the v1.1 upgrade package, which is encrypted and broadcast via H1. It is then fragmented and transmitted using the UTP protocol (the distribution process is hierarchical: initially, the central server sends the upgrade package to a bootstrap node (such as H1), but H1 is not the only distribution point. H1 broadcasts the upgrade package metadata via a P2P network, and then hosts use the UTP protocol for fragmented forwarding. Each host downloads the package, which becomes a new seed and is automatically forwarded to neighboring nodes, achieving efficient distribution). P2P forwarding between hosts verifies the Merkle root hash.

[0123] 3. Load Scheduling: Real-time monitoring of load (H1: High, H2: Low) and peak usage (8-10 PM). Upgrade order: First H2, H4 (low load), then H1, H3, H5. Upgrade window: 2-4 AM.

[0124] 4. Execution: H2 downloads the package, performs the upgrade, and broadcasts a successful update. In case of an error, the CPU takes over the service and performs a rollback: using a snapshot for recovery.

[0125] 5. Post-installation: When H6 joins, it queries H3. H3 may be a neighboring node of H6, rather than being fixedly dependent on H1. This ensures query efficiency. After obtaining version information from H3, H6 does not accept it immediately, but instead sends a multi-way query to the DHT network (based on protocol redundancy parameters, such as the α value of Kademlia). It obtains version lists from multiple nodes (such as H2, H5) and compares the version numbers. If the version number of H3 is lower than the version returned by a majority of nodes, H6 determines that the H3 information is outdated.

[0126] If the H3 information becomes outdated, the DHT protocol will route to other nodes (such as H2 or H5) through timeout and retry mechanisms until the latest version is found.

[0127] Meanwhile, version information is redundantly stored via DHT, with multiple nodes backing up the latest data to ensure synchronization reliability. H6 downloads firmware fragments from the seed node list, verifies the Merkle tree hash, completes the upgrade, and updates its own version to the DHT. It also obtains the seed node list for the latest firmware v1.1 and automatically upgrades and synchronizes.

[0128] The upgrade process for this application can refer to the following steps: 1. Mount the partition; 2. Flash the firmware; 3. Broadcast status. "Mounting the partition" is a core operation for the operating system to manage storage devices, enabling the system to access files on storage devices such as disks and USB drives. "Flashing the firmware" is the operation of updating the host. "Broadcasting status" aims to allow other hosts in the cluster to proactively obtain the current status of the target host.

[0129] This application targets aftermarket multi-home host clusters, with its core being a dynamic discovery and automatic synchronization mechanism. It uses a DHT (Distributed Hash Table) protocol (such as Kademlia) to maintain the host list and firmware version information. This not only enables distributed distribution of upgrade packages but also supports the dynamic addition and real-time synchronization of new hosts. The DHT network allows each host to store a tuple of <host ID, IP address, firmware version> and dynamically update it through a P2P query mechanism. When a new host joins, it does not rely on a central server but automatically obtains the latest firmware version and cluster status by querying neighboring nodes. This design solves the problem of elastic scaling of aftermarket devices, emphasizing dynamic adaptability.

[0130] Using the DHT protocol, this application eliminates the need for a central server, avoiding single points of failure. DHT distributes data across multiple nodes, ensuring the cluster continues to operate even if some nodes fail. DHT has a query complexity of O(log n), enabling rapid resource location. When a new node joins or leaves, DHT automatically adjusts the routing table to maintain its up-to-date state, demonstrating its "dynamic" nature.

[0131] In addition, this application introduces a multi-factor weighted algorithm to dynamically determine the upgrade order and optimize the upgrade process of the entire cluster. Specifically: Real-time load monitoring and prediction: The load scheduling module continuously collects indicators such as CPU, memory, and network utilization, and calculates priorities by combining historical usage patterns (such as the number of hours until the peak period).

[0132] Algorithm formula: Priority = α × (1 - Current load rate) + β × Remaining time. This weighted approach considers not only instantaneous load but also introduces a time dimension, avoiding upgrades during peak hours and thus minimizing service interruptions. The upgrade order is not static but dynamically adjusted based on real-time data. For example, in implementation, low-load hosts (such as H2 and H4) are upgraded first, followed by high-load hosts (such as H1), ensuring that the overall service capacity of the cluster does not degrade.

[0133] The remaining timeout reflects historical usage patterns because it's a regularity indicator derived from long-term data statistics: the cluster continuously monitors load changes and records daily / weekly peak periods. This indicator isn't an instantaneous value, but rather a prediction of future load based on historical patterns. For example, 2 AM is 6 hours before the peak period (8 PM), and the load might be lower. This helps avoid upgrading during potential peak times.

[0134] Furthermore, this application deeply integrates P2P dynamic distribution, load balancing scheduling, security verification, and rollback mechanisms, generating a synergistic effect (reflected in the deep integration of multiple modules: the load scheduling module uses this data to dynamically calculate the upgrade order, the security verification module ensures shard integrity, etc.), solving the OTA problem of multi-home host clusters. Integrating load scheduling into the P2P network, combining dynamic adaptation with load balancing, allows the upgrade process to handle dynamic node additions while ensuring service continuity. Traditional P2P upgrades often ignore the impact of load, and load balancing solutions typically rely on a central scheduler. This invention achieves efficient upgrades through distributed decision-making. The security verification module uses AES-256 encryption combined with double XOR obfuscation and Merkle tree verification to ensure the integrity of the upgrade package, while reducing bandwidth pressure through P2P distribution. This lightweight security design is suitable for resource-constrained IoT devices, while comparative documents do not involve similar integrations. Using Btrfs file system snapshots to achieve second-level rollback, working in conjunction with P2P distribution and load scheduling, ensures rapid recovery in case of upgrade failure.

[0135] When a new host (such as H6) is added to a multi-home host cluster with specific optimizations, the firmware is automatically obtained from the seed node through the P2P network without manual intervention.

[0136] It should be noted that, for the sake of simplicity, the method embodiments are all described as a series of actions. However, those skilled in the art should understand that the embodiments of this application are not limited to the described order of actions, because according to the embodiments of this application, some steps can be performed in other orders or simultaneously. Secondly, those skilled in the art should also understand that the embodiments described in the specification are all preferred embodiments, and the actions involved are not necessarily required by the embodiments of this application.

[0137] Reference Figure 7 This diagram illustrates the structural structure of a cluster system according to an embodiment of this application. The cluster includes multiple hosts, and a peer-to-peer network is established between the multiple hosts. The system can apply the host upgrade method described above. Figure 7 As shown, the system may include: Communication module 701 is used to enable communication between multiple hosts; The load scheduling module 702 is used to detect the current resource usage and historical usage patterns of the host, and determine the upgrade order of the host based on the current resource usage and the historical usage patterns. Security verification module 703 is used to encrypt and decrypt the upgrade package; The upgrade execution module 704 is used to upgrade the host according to the upgrade sequence.

[0138] In some embodiments, the communication module 701 can implement a DHT network based on the Kademlia protocol, thereby enabling communication between multiple hosts; each host stores a <host ID, IP, firmware version> tuple.

[0139] The load scheduling module 702 can be used to detect the current resource usage and historical usage patterns of the host, and determine the upgrade order of the host based on the current resource usage and the historical usage patterns.

[0140] The security verification module 703 can use AES-256-CBC encryption, with the key obfuscated by double XOR (K=K1⊕K2⊕Salt), and the Merkle root hash pre-embedded in the firmware header.

[0141] The upgrade execution module 704 can upgrade the host according to the upgrade order; for example, the upgrade execution module can also perform rollback based on a Btrfs file system snapshot.

[0142] Reference Figure 8 The system may include a cluster; the cluster includes multiple hosts (new host H1, new host H2, new host H6, and target host); communication connections are established between the hosts; the target host includes a communication module, a load scheduling module, a security verification module, and an upgrade execution module.

[0143] The target host acts as a bootstrap node, connecting to the central server via HTTPS and receiving encrypted upgrade packages from the central server.

[0144] New hosts can receive upgrade packages from target hosts through a peer-to-peer network; after joining the cluster, new hosts can also exchange data to complete cluster upgrades.

[0145] The communication module can be deployed with a DHT routing table to store information about other nodes for data exchange between them. It can also deploy a node discovery protocol, a core protocol in distributed networks (such as P2P, blockchain, and DHT networks) for new nodes joining the network or existing nodes maintaining information about their neighbors. Its core objective is to allow nodes to automatically find and connect to other active nodes in the network without centralized coordination, ensuring dynamic updates and connectivity of the network topology. The communication module also includes UTP (Unshielded Twisted Pair) for electrical signal transmission.

[0146] The load scheduling module includes a resource monitoring agent, an upgrade decision engine, and a time window controller. The resource monitoring agent is used to monitor the resource usage of the host, the upgrade decision engine is used to generate the upgrade order, and the time window controller is used to determine the host upgrade time window.

[0147] The upgrade execution module includes a firmware flasher and a snapshot rollback unit; the firmware flasher is used to upgrade the host, and the snapshot rollback unit is used to roll back the host.

[0148] The security verification module may include AES-256 decryption, encryption, and dual XOR key management.

[0149] Reference Figure 9 The diagram shows a structural schematic of an upgrade device for hosts in a cluster according to an embodiment of this application. The cluster includes multiple hosts, and a peer-to-peer network is established between the multiple hosts.

[0150] like Figure 9 As shown, the upgrade device for the hosts in this cluster may include the following modules: The determination module 901 is used to determine the current version information of the target host, as well as the version information of other hosts besides the target host; The receiving module 902 is used to receive the first upgrade package from other hosts whose version information is higher than the current version information of the target host when the version information of other hosts is higher than the current version information of the target host. Upgrade module 903 is used to upgrade the target host according to the first upgrade package.

[0151] In some embodiments of this application, the receiving module 902 is further configured to determine the current resource usage of the host and its historical usage patterns; determine the upgrade order of the host based on the current resource usage and historical usage patterns; and when the upgrade order of the target host is reached, execute the step of upgrading the target host according to the first upgrade package.

[0152] In some embodiments of this application, the receiving module 902 is configured to determine the current load rate of the host based on the current resource usage; and predict the remaining time of the host until the peak load time based on historical usage patterns; determine the priority of the host based on the current load rate and the remaining time; and determine the upgrade order of the host based on the priority of the host.

[0153] In some embodiments of this application, the upgrade module 903 is further configured to: when the target host is a boot node, the target host is also connected to the central server; receive a second upgrade package issued by the central server; upgrade the target host according to the second upgrade package; and broadcast the second upgrade package to other hosts after the upgrade is completed.

[0154] In some embodiments of this application, the upgrade module 903 is further configured to broadcast the upgrade completion to other hosts when the target host is a non-booting node; and to broadcast the first upgrade package to other hosts.

[0155] In some embodiments of this application, the upgrade module 903 is further configured to query the version information in the host when the target host is a newly added node in the cluster, and determine the neighboring nodes of the target host from other hosts; when the version information of the neighboring node is the highest, receive the third upgrade package from the neighboring node; when the version information of the neighboring node is not the highest, receive the third upgrade package from the host with the highest version information.

[0156] In some embodiments of this application, the upgrade module 903 is further configured to perform integrity verification on the first upgrade package; when the integrity verification of the first upgrade package passes, the step of upgrading the target host according to the first upgrade package is executed.

[0157] In some embodiments of this application, the target host stores a snapshot of the current version; the upgrade module 903 is further configured to detect the upgrade process of the target host when upgrading the target host according to the first upgrade package; and when there is an abnormality in the upgrade process of the target host, restore the target host according to the snapshot.

[0158] In this embodiment, the current version information of the target host and the version information of other hosts besides the target host are determined. When the version information of other hosts is higher than the current version information of the target host, a first upgrade package is received from the other hosts whose version information is higher than the current version information of the target host. The target host is then upgraded according to the first upgrade package. This application relies on a peer-to-peer network, which enables data interaction between hosts to complete the upgrade of hosts in the cluster. Compared with upgrade schemes that rely entirely on a central server, the cluster in this application only needs to obtain the upgrade package to complete the data interaction of the entire cluster through interaction between hosts. There are no issues such as bandwidth bottlenecks, single point of failure risks, or service interruptions during the upgrade process.

[0159] This application also provides an electronic device, including a processor, a memory, and a computer program stored in the memory and capable of running on the processor. When the computer program is executed by the processor, it implements the above-described method for upgrading hosts in a cluster.

[0160] This application also provides a computer-readable storage medium on which a computer program is stored. When the computer program is executed by a processor, it implements the above-described method for upgrading hosts in a cluster.

[0161] As the device embodiment is basically similar to the method embodiment, the description is relatively simple, and relevant parts can be found in the description of the method embodiment.

[0162] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. The same or similar parts between the various embodiments can be referred to each other.

[0163] Those skilled in the art will understand that embodiments of this application can be provided as methods, apparatus, or computer program products. Therefore, embodiments of this application can take the form of entirely hardware embodiments, entirely software embodiments, or embodiments combining software and hardware aspects. Furthermore, embodiments of this application can take the form of computer program products 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.

[0164] This application describes embodiments with reference to flowchart illustrations and / or block diagrams of methods, terminal devices (systems), and computer program products according to embodiments of this application. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing terminal device to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing terminal device, generate instructions for implementing the flowchart illustrations. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0165] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing terminal device to operate in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1The function specified in one or more boxes.

[0166] These computer program instructions can also be loaded onto a computer or other programmable data processing terminal equipment, causing a series of operational steps to be performed on the computer or other programmable terminal equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable terminal equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0167] Although preferred embodiments of the present application have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments as well as all changes and modifications falling within the scope of the embodiments of the present application.

[0168] Finally, it should be noted that in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or terminal device that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or terminal device. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or terminal device that includes said element.

[0169] The above provides a detailed description of a method, apparatus, system, device, and medium for upgrading hosts in a cluster. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are only for the purpose of helping to understand the method and core ideas of this application. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of this application. Therefore, the content of this specification should not be construed as a limitation of this application.

Claims

1. A method for upgrading hosts in a cluster, characterized in that, The cluster includes multiple hosts, and a peer-to-peer network is established between the multiple hosts. The method includes: Determine the current version information of the target host, as well as the version information of other hosts besides the target host; When the version information of the other host is higher than the current version information of the target host, the first upgrade package is received from the other host whose version information is higher than the current version information of the target host; The target host is upgraded according to the first upgrade package.

2. The method according to claim 1, characterized in that, The method further includes: Determine the host's current resource usage and historical usage patterns; The upgrade order of the host is determined based on the current resource usage and the historical usage patterns. When the upgrade sequence for the target host is reached, the step of upgrading the target host according to the first upgrade package is executed.

3. The method according to claim 2, characterized in that, Determining the upgrade order of the host based on the current resource usage and the historical usage pattern includes: Based on the current resource usage, determine the current load rate of the host; And, based on the historical usage patterns, predict the remaining time before the peak load time for the host; The priority of the host is determined based on the current load rate and the remaining time. The upgrade order of hosts is determined based on their priority.

4. The method according to claim 1, characterized in that, When the target host is a bootstrap node, the target host is also connected to a central server; the method further includes: Receive the second upgrade package sent by the central server; The target host is upgraded according to the second upgrade package, and the second upgrade package is broadcast to the other hosts after the upgrade is completed.

5. The method according to claim 1, characterized in that, When the target host is a non-booting node, the method further includes: The upgrade was broadcast to the other hosts. And, broadcast the first upgrade package to the other hosts.

6. The method according to claim 1, characterized in that, When the target host is a newly joined node in the cluster, the method further includes: Query the version information in the host, and determine the neighboring nodes of the target host from the other hosts; When the version information of the neighboring node is the highest, the third upgrade package is received from the neighboring node; When the version information of the neighboring node is not the highest, the third upgrade package is received from the host with the highest version information.

7. The method according to claim 1, characterized in that, The method further includes: Perform integrity verification on the first upgrade package; When the integrity verification of the first upgrade package passes, the step of upgrading the target host according to the first upgrade package is executed.

8. The method according to claim 1, characterized in that, The target host stores a snapshot of the current version; the method further includes: When upgrading the target host according to the first upgrade package, the upgrade process of the target host is detected; If an anomaly occurs during the upgrade process of the target host, the target host is restored based on the snapshot.

9. A clustered system, characterized in that, The cluster includes multiple hosts, and a peer-to-peer network is established between the multiple hosts; The application has the method as described in any one of claims 1-8; the system comprises: The communication module is used to enable communication between multiple hosts; The load scheduling module is used to detect the current resource usage and historical usage patterns of the host, and determine the upgrade order of the host based on the current resource usage and the historical usage patterns. The security verification module is used to encrypt and decrypt the upgrade package; The upgrade execution module is used to upgrade the host according to the upgrade order.

10. An upgrade device for a host in a cluster, characterized in that, The cluster includes multiple hosts, and a peer-to-peer network is established between the multiple hosts. The device includes: The determination module is used to determine the current version information of the target host, as well as the version information of other hosts besides the target host; The receiving module is configured to receive a first upgrade package from other hosts whose version information is higher than the current version information of the target host when the version information of the other hosts is higher than the current version information of the target host. The upgrade module is used to upgrade the target host according to the first upgrade package.

11. An electronic device, characterized in that, It includes a processor, a memory, and a computer program stored in the memory and capable of running on the processor, wherein the computer program, when executed by the processor, implements the upgrade method for hosts in the cluster as described in any one of claims 1 to 8.

12. A computer-readable storage medium, characterized in that, A computer program is stored on the computer-readable storage medium, which, when executed by a processor, implements the upgrade method for hosts in the cluster as described in any one of claims 1 to 8.

Images