File client bulk upgrade system

Abstract

Embodiments of the present disclosure disclose a file client batch upgrade system. A specific implementation of the system comprises: an upgrade control server and each file client; the upgrade control server is configured to send upgrade preparation information to each file client; perform an upgrade check task; each file client is configured to perform a local pre-check task; send terminal check results to the upgrade control server; the upgrade control server is configured to send write emptying information to each file client; each file client is configured to perform a corresponding write emptying task; send write emptying results to the upgrade control server; the upgrade control server is configured to send upgrade information to each file client; each file client is configured to perform an upgrade task; and send upgrade status information to the upgrade control server. The implementation can improve processing efficiency during upgrade and reduce hardware loss of the system.

Description

TECHNICAL FIELD

[0001] Embodiments of the present disclosure relate to the field of computer technology, and in particular, to a file client batch upgrade system. BACKGROUND

[0002] The file client batch upgrade system is a system for batch upgrading each file client. At present, when upgrading each file client, the commonly used way is that the upgrade system updates each business Pod corresponding to each file client according to the upgrade file, so as to upgrade the file client one by one.

[0003] However, when each file client is upgraded by using the above way, the following technical problems often exist:

[0004] In the process of upgrading each file client one by one, it is easy to cause the existence of running new and old version file clients at the same time, which is easy to reduce the compatibility between each file client, and is easy to cause the old version file client to cause system freezing when processing new requests due to poor compatibility, thereby easily causing the processing efficiency to be low during upgrading, and easily causing the hardware to be greatly damaged due to frequent freezing.

[0005] The above information disclosed in the BACKGROUND section merely to enhance the understanding of the background of the present inventive concept, and therefore, can include information that does not form the prior art known by those of ordinary skill in the art in the country. SUMMARY

[0006] The summary of the present disclosure is used to introduce the concept in a brief form, which will be described in detail in the specific embodiments section. The summary of the present disclosure is not intended to identify key or essential features of the claimed technical solution, nor is it intended to be used to limit the scope of the claimed technical solution.

[0007] Some embodiments of the present disclosure propose a file client batch upgrade system to solve one or more of the technical problems mentioned in the above BACKGROUND section.

[0008] In a first aspect, some embodiments of the present disclosure provide a file client batch upgrade system, comprising: an upgrade control server and a plurality of file clients; and the upgrade control server is configured to perform the following steps: sending preset upgrade preparation information to the plurality of file clients; performing a corresponding upgrade check task to obtain an upgrade check result; each of the plurality of file clients is configured to perform the following steps: in response to receiving the upgrade preparation information sent by the upgrade control server, performing a local pre-check task corresponding to the upgrade preparation information to obtain a terminal check result; sending the terminal check result to the upgrade control server; the upgrade control server is further configured to, in response to determining that the received terminal check results and the upgrade check result satisfy a preset check result condition, send preset write empty information to the plurality of file clients; each of the plurality of file clients is further configured to perform the following steps: in response to receiving the write empty information sent by the upgrade control server, performing a corresponding write empty task to obtain a write empty result; sending the write empty result to the upgrade control server; the upgrade control server is further configured to, in response to determining that the received write empty results satisfy a preset empty condition, send preset upgrade information to the plurality of file clients; each of the plurality of file clients is further configured to perform the following steps: in response to receiving the upgrade information sent by the upgrade control server, performing an upgrade task corresponding to the upgrade information to obtain upgrade status information; sending the upgrade status information to the upgrade control server.

[0009] The above various embodiments of the present disclosure have the following beneficial effects: the file client batch upgrade system of some embodiments of the present disclosure can improve the processing efficiency during upgrade and reduce the hardware loss of the system. Specifically, the reason for the low processing efficiency and large hardware loss during upgrade is that in the process of upgrading the file clients one by one, it is easy to cause the coexistence of new and old version file clients, reduce the compatibility between the file clients, cause the system to freeze due to poor compatibility when the old version file client processes a new request, and thus easily cause the processing efficiency to be low during upgrade, and easily cause the hardware loss of the system to be large due to frequent freezing. Based on this, the file client batch upgrade system of some embodiments of the present disclosure includes an upgrade control server and a plurality of file clients, and the upgrade control server is configured to perform the following steps: first, send the preset upgrade preparation information to the plurality of file clients. In this way, the upgrade preparation information can be sent to the plurality of file clients to prompt the plurality of file clients to start preparing for upgrade. Secondly, perform a corresponding upgrade check task to obtain an upgrade check result. In this way, the upgrade controller can check whether the current state of itself can upgrade the plurality of file clients to obtain the upgrade check result. Then, each file client in the plurality of file clients is configured to perform the following steps: then, in response to receiving the upgrade preparation information sent by the upgrade control server, perform a local pre-check task corresponding to the upgrade preparation information to obtain a terminal check result. In this way, each file client can prepare for upgrade and detect whether it can normally upgrade at the current time. Then, send the terminal check result to the upgrade control server. Then, the upgrade control server is further configured to, in response to determining that the received plurality of terminal check results and the upgrade check result satisfy a preset check result condition, send preset write empty information to the plurality of file clients. In this way, when the upgrade controller determines that it can upgrade the plurality of file clients and each file client can normally upgrade, the write empty information is sent to the plurality of file clients. Then, each file client in the plurality of file clients is further configured to perform the following steps: then, in response to receiving the write empty information sent by the upgrade control server, perform a corresponding write empty task to obtain a write empty result. In this way, the file client can perform the write empty task. Then, send the write empty result to the upgrade control server. Then, the upgrade control server is further configured to, in response to determining that the received plurality of write empty results satisfy a preset empty condition, send preset upgrade information to the plurality of file clients. In this way, when the upgrade control server determines that the write empty task of each file client is completed, the upgrade information can be sent to the plurality of file clients to simultaneously upgrade the plurality of file clients.Then, each of the file clients is further configured to perform the following steps: then, in response to receiving the upgrade information sent by the upgrade control server, performing an upgrade task corresponding to the upgrade information, to obtain upgrade status information. In this way, the file client can start the upgrade. Finally, the upgrade status information is sent to the upgrade control server. Because the upgrade control server can upgrade each file client at the same time, and only after all file clients complete the task of the current stage, the next step is started, the probability of system freezing caused by poor compatibility of each file client can be reduced, the upgrade efficiency during the upgrade can be improved, and the hardware loss of the system can be reduced. BRIEF DESCRIPTION OF DRAWINGS

[0010] The above and other features, advantages and aspects of embodiments of the present disclosure will become more apparent by describing in detail some embodiments thereof with reference to the attached drawings in which:

[0011] Figure 1 is a structural schematic diagram of some embodiments of the file client batch upgrade system according to the present disclosure;

[0012] Figure 2 is a timing diagram of some embodiments of the file client batch upgrade system according to the present disclosure. DETAILED DESCRIPTION

[0013] Embodiments of the present disclosure will be described in detail with reference to the drawings. Although some embodiments of the present disclosure are shown in the drawings, it should be understood that the present disclosure can be implemented in various forms, and should not be interpreted as being limited to the embodiments set forth herein. On the contrary, these embodiments are provided so that the present disclosure can be more thoroughly and completely understood. It should be understood that the drawings and embodiments of the present disclosure are only for exemplary purposes, and are not intended to limit the scope of protection of the present disclosure.

[0014] In addition, it should be noted that only the parts related to the invention are shown in the drawings for ease of description. The embodiments and features in the present disclosure can be combined with each other without conflict.

[0015] It should be noted that the concepts of "first", "second", etc. mentioned in the present disclosure are only used to distinguish different devices, modules or units, and are not intended to limit the order or interdependence of the functions performed by these devices, modules or units.

[0016] It should be noted that the modification of "one", "a plurality of" mentioned in the present disclosure is illustrative but not restrictive, and those skilled in the art should understand that unless otherwise explicitly indicated in the context, it should be understood as "one or more".

[0017] The names of the messages or information exchanged between the plurality of devices in the embodiments of the present disclosure are only for illustrative purposes, and are not used to limit the scope of the messages or information.

[0018] The present disclosure will be described in detail below with reference to the accompanying drawings and in conjunction with embodiments.

[0019] Figure 1 is a structural schematic diagram of some embodiments of the file client batch upgrade system according to the present disclosure.

[0020] As Figure 1 shown, the file client batch upgrade system provided by the present disclosure can include an upgrade control server 1 and each file client 2. The upgrade control server 1 can be a server for upgrading each file client 2. Each file client 2 can be a client that needs to be upgraded. The upgrade control server 1 is in communication connection with each file client 2.

[0021] Reference is made below to Figure 2 , which shows a timing diagram of the file client batch upgrade system according to the present disclosure.

[0022] As Figure 2 shown, a file client batch upgrade system includes an upgrade control server and each file client. The interaction steps between the upgrade control server and each file client can include the following steps:

[0023] In some embodiments, the upgrade control server can be configured to perform the following steps:

[0024] Step 201, the upgrade control server sends the preset upgrade preparation information to each file client.

[0025] In some embodiments, the upgrade control server can send preset upgrade preparation information to each of the file clients. The upgrade control server corresponds to an identifier and a distributed lock. The identifier can be a UUID (Universally Unique Identifier) corresponding to the upgrade control server. Each of the file clients corresponds to a mount point, a database, a hardware storage, a mounted storage container, a node agent, and a container storage plug-in. The mount point can be a directory entry corresponding to the file client and used to connect to a file system or a storage device. The mount point corresponds to a mount point identifier. The mount point identifier can be a string used to uniquely identify the mount point. For example, the mount point identifier can be “<mount_identifier>”. The database can be a memory corresponding to the file client. The hardware storage can be a disk corresponding to the file client. The mounted storage container can be a container used to run the file client. For example, the mounted storage container can be a Mount Pod corresponding to the file client. The mounted storage container corresponds to a container name. The container name can be a name corresponding to the mounted storage container. The node agent can be a node used to forward data between the file client and the upgrade control server. The node agent corresponds to an IP address and a process control symbol. The container storage plug-in can be an interface used to store data. For example, the container storage plug-in can be a CSI (Container Storage Interface). The upgrade preparation information can be information used to prompt each of the file clients to prepare for an upgrade. The upgrade preparation information can include a transaction number and configuration information. The transaction number can be a transaction ID corresponding to an upgrade event. The upgrade event can be an event of upgrading each of the file clients through interaction between the upgrade control server and each of the file clients. The configuration information can be information needed to be used when upgrading each of the file clients. The configuration information can include, but is not limited to, current version information, target version information, running mount configuration, and update time range data. The current version information can be a name corresponding to a current version of each of the file clients. For example, the current version information can be mount:v1.2.2. The target version information can be information corresponding to a version to which each of the file clients needs to be upgraded. The target version information can include a version name and version verification data. The version name can be a name corresponding to a version to which each of the file clients needs to be upgraded. For example, the version name can be mount:v1.2.3.The version check data can be a checksum for facilitating the integrity check of the target version information by the file clients. The running mount configuration can represent parameters that need to be adjusted by the file clients during the upgrade. The update time range data can be an interval representing a time range for upgrading the file clients. For example, the update time range data can be "[1:00, 4:00]", representing that the update can be performed between 1:00 am and 4:00 am.

[0026] At step 202, the upgrade control server performs a corresponding upgrade check task to obtain an upgrade check result.

[0027] In some embodiments, the upgrade control server can perform a corresponding upgrade check task to obtain an upgrade check result. The upgrade check task can be a task for detecting the upgrade control server itself. The upgrade check result can be a label representing whether the upgrade control server can upgrade the file clients at the current time. For example, the upgrade check result can be "upgradeable" or "unupgradeable".

[0028] In some optional implementations of some embodiments, the upgrade control server can be further configured to perform a corresponding upgrade check task to obtain an upgrade check result by the following steps:

[0029] First, based on preset upgrade path information, perform compatibility detection processing on the current version information and the target version information included in the upgrade preparation information to obtain a version detection result. The upgrade path information can be information of an upgrade mode that needs to be followed when upgrading the file clients. The upgrade path information can include various upgrade paths. Each upgrade path in the various upgrade paths can represent a path when upgrading the file clients. For example, the upgrade path can be "mount:v1.2.2-mount:v1.2.3", representing that the file clients must be upgraded from mount:v1.2.2 to mount:v1.2.3. The version detection result can be a label representing whether the file clients can be upgraded from the current version information to the target version information. For example, the version detection result can be "upgradeable" or "unupgradeable".

[0030] In practice, first, the upgrade control server can combine the current version information and the target version information into version path information through a connector. The connector can be a symbol used to connect the current version information and the target version information. For example, the connector can be “-”. Then, the upgrade control server can find the version path information from the upgrade path information through a find function to obtain a find result. The find function can be a function capable of finding a specific character. For example, the find function can be a find function. The find result can be a return value of the find function. For example, the find result can be character position information or “undefined”. The character position information can be the position of the data identical to the searched string. “Undefined” can represent that no data identical to the searched string is found. Then, in response to determining that the find result meets a preset find result condition, the upgrade control server can determine “upgradeable” as the version detection result. The find result condition can be that the find result is not “undefined”. In response to determining that the find result does not meet the find result condition, the upgrade control server can determine “non-upgradeable” as the version detection result.

[0031] Secondly, the cluster state detection result is generated based on preset cluster state detection information, a preset target server, and preset health threshold data. The cluster state detection information can be a command used to check the state of all nodes of a service or system. For example, the cluster state detection information can be a kubectl get nodes command. The target server can be a server that needs to be detected for health status. The health threshold data can be a preset numerical value. The specific setting of the health threshold data is not limited. The cluster state detection result can be a label used to represent whether the current state of the system is suitable for upgrade. For example, the cluster state detection result can be “upgradeable” or “non-upgradeable”.

[0032] Thirdly, current time data is obtained. The current time data can be a current time point. In practice, the upgrade control server can obtain the current time point as the current time data through a time obtaining function. The time obtaining function can be a function capable of obtaining the current time. For example, the time obtaining function can be a time. Now () function.

[0033] Fourthly, a time detection result is generated based on the current time data and the update time range data. The time detection result can be a label used to represent whether the current time is suitable for upgrading the respective file clients. For example, the time detection result can be “upgradeable” or “non-upgradeable”.

[0034] In practice, the upgrade control server can determine the data corresponding to the right interval in the update time range data as the maximum time data. Secondly, the data corresponding to the left interval in the update time range data can be determined as the minimum time data. In response to determining that the current time data satisfies the preset time range condition, "can upgrade" can be determined as the time detection result. The time range condition can be that the current time data is greater than or equal to the minimum time data and less than or equal to the maximum time data. Then, in response to determining that the current time data does not satisfy the time range condition, "cannot upgrade" can be determined as the time detection result.

[0035] In the fifth step, a corresponding memory resource detection task is performed to obtain memory remaining data. The memory remaining data can be data representing the available memory capacity in the upgrade control server. In practice, the upgrade control server can determine the corresponding memory remaining data through a memory query instruction. The memory query instruction can be a command that can query the size of the remaining memory. For example, the memory query instruction can be the free command.

[0036] In the sixth step, based on the memory remaining data and a preset memory threshold data, a remaining memory detection result is generated. The memory threshold data can be a preset numerical value. Here, the specific setting of the memory threshold data is not limited. The remaining memory detection result can be a label representing whether the remaining memory in the upgrade control server can successfully upgrade the various file clients. For example, the remaining memory detection result can be "can upgrade" or "cannot upgrade".

[0037] In practice, in response to determining that the memory remaining data is greater than the memory threshold data, "can upgrade" can be determined as the remaining memory detection result. In response to determining that the memory remaining data is less than or equal to the memory threshold data, "cannot upgrade" can be determined as the remaining memory detection result.

[0038] In the seventh step, the metadata server is detected for connectivity, and a metadata connectivity detection result is obtained. The metadata server can be a server for coordinating the storage and communication relationship between the upgrade control server and each file client. For example, the metadata server can be a Redis (Remote Dictionary Server). The metadata connectivity detection result can be a label indicating whether the connectivity between the upgrade control server and the metadata server can successfully upgrade each file client. For example, the metadata connectivity detection result can be "upgradeable" or "not upgradeable".

[0039] In practice, the execution subject can send the preset connectivity information to the metadata server. The connectivity information can be an instruction for detecting the connectivity between the upgrade control server and the metadata server. For example, the connectivity information can be a PING command. Next, character information sent by the metadata server is received. The character information can be a character indicating whether the upgrade control server is connected to the metadata server. For example, the character information can be "PONG", indicating that the upgrade control server is connected to the metadata server. Then, in response to determining that the character information satisfies the preset connectivity condition, "upgradeable" can be determined as the metadata connectivity detection result. The connectivity condition can be that the character information is "PONG". Then, in response to determining that the character information does not satisfy the connectivity condition, "not upgradeable" can be determined as the metadata connectivity detection result.

[0040] In the eighth step, based on the preset access information, the interface server is detected for connectivity, and an interface connectivity detection result is obtained. The access information can be an instruction for detecting whether the upgrade control server and the interface server can normally interact. For example, the access information can be a PING command. The interface server can be a server for providing a programming interface. For example, the interface server can be a Kubernetes API. The interface connectivity detection result can be a label indicating whether the connectivity between the upgrade control server and the interface server can normally upgrade each file client. For example, the interface connectivity detection result can be "upgradeable" or "not upgradeable".

[0041] In practice, the upgrade control server can send the access information to the interface server. Then, the data returned by the interface server is received as return result data. Then, in response to determining that the return result data satisfies a preset return condition, the upgrade control server can determine that the interface connectivity detection result is “upgradeable”. The return condition can be that the return result data is a preset interface return data. The interface return data can be a preset string. For example, the interface return data can be “PONG”. Then, in response to determining that the return result data does not satisfy the return condition, the interface connectivity detection result can be determined to be “non-upgradeable”.

[0042] In the ninth step, the mutual exclusion detection result is generated based on the identifier information corresponding to the upgrade control server. The identifier information can be a UUID corresponding to the upgrade control server. The mutual exclusion detection result can be a label representing whether the upgrade control server can upgrade the file clients. For example, the mutual exclusion detection result can be “upgradeable” or “non-upgradeable”.

[0043] In practice, the upgrade control server can connect to the metadata server through a data connection instruction. The data connection instruction can be a command for connecting to the metadata server. For example, the data connection instruction can be a redis-cli command. Then, the identifier information corresponding to the distributed lock of the upgrade control server at the current time can be obtained as return identifier information through an identifier viewing instruction. The identifier viewing instruction can be a command for viewing the identifier information of the distributed lock of the upgrade control server at the current time. For example, the identifier viewing instruction can be a GET command. Then, the return identifier and the identifier information corresponding to the upgrade control server can be compared through a comparison function to obtain an identifier comparison result. The comparison function can be a function that can compare two strings. For example, the comparison function can be a strcmp function. The identifier comparison result can be the return value of the comparison function. Then, in response to determining that the identifier comparison result satisfies a preset identifier comparison condition, the mutual exclusion detection result can be determined to be “upgradeable”. The identifier comparison condition can be that the identifier comparison result is a preset comparison return value. The comparison return value can be a preset numerical value. For example, the comparison return value can be 0. Then, in response to determining that the identifier comparison result does not satisfy the identifier comparison condition, the mutual exclusion detection result can be determined to be “non-upgradeable”.

[0044] In the tenth step, based on the version detection result, the cluster state detection result, the time detection result, the remaining memory detection result, the interface connectivity detection result, and the mutual exclusivity detection result, an upgrade check result is generated.

[0045] In practice, first, in response to determining that the version detection result, the cluster state detection result, the time detection result, the remaining memory detection result, the interface connectivity detection result, and the mutual exclusivity detection result satisfy a preset upgrade detection condition, “can be upgraded” is determined as the upgrade check result. The upgrade detection condition can be that the version detection result, the cluster state detection result, the time detection result, the remaining memory detection result, the interface connectivity detection result, and the mutual exclusivity detection result are all “can be upgraded”. Second, in response to determining that the version detection result, the cluster state detection result, the time detection result, the remaining memory detection result, the interface connectivity detection result, and the mutual exclusivity detection result do not satisfy the upgrade detection condition, “cannot be upgraded” is determined as the upgrade check result.

[0046] In some optional implementations of some embodiments, the upgrade control server can be further configured to generate a cluster state detection result based on preset cluster state detection information, a preset target server, and preset health threshold data by the following steps:

[0047] In the first step, based on the cluster state detection information and the target server, health node quantity data and node total quantity data are generated. The health node quantity data can be data used to represent the number of nodes in the target server that are in a normal state. The node total quantity data can be data used to represent the number of all nodes in the target server. The cluster state detection information can be a command used to check the state of all nodes in a service or system. For example, the cluster state detection information can be a kubectl get nodes command.

[0048] In practice, the upgrade control server can obtain the node state information of each node corresponding to the target server through the cluster state detection information. Each node state information can be information representing the running state of the node. Each node state information can include a node name and a node state. The node name can be the name of the node. The node state can be a label representing the current running state of the node. For example, the node state can be “Ready” or “NotReady”. When the node state is “Ready”, it means that the node is ready to run. When the node state is “NotReady”, it means that the node is not ready to run. Then, the number of node state information can be determined as the total number of nodes data. Then, the node state information satisfying the preset preparation state condition can be determined as the target node state information. The preparation state condition can be that the node state included in the node state information is “Ready”. Then, the number of target node state information can be determined as the number of healthy nodes data.

[0049] In the second step, the ratio of the number of healthy nodes data to the total number of nodes data is determined as the healthy node ratio data.

[0050] In the third step, in response to determining that the healthy node ratio data is greater than or equal to the health threshold data, a preset first cluster detection result is determined as the cluster state detection result. The first cluster detection result can be a label representing that the upgrade control server can normally upgrade the file clients in the current state. For example, the first cluster detection result can be “upgradeable”.

[0051] In the fourth step, in response to determining that the healthy node ratio data is less than the health threshold data, a preset second cluster detection result is determined as the cluster state detection result. The second cluster detection result can be a label representing that the upgrade control server cannot normally upgrade the file clients in the current state. For example, the second cluster detection result can be “not upgradeable”.

[0052] In some embodiments, each file client of the file clients can be configured to perform the following steps:

[0053] In step 203, each file client of the file clients performs a local pre-check task corresponding to the upgrade preparation information to obtain a terminal check result in response to receiving the upgrade preparation information sent by the upgrade control server.

[0054] In some embodiments, each of the file clients can perform a local pre-checking task corresponding to the upgrade preparation information to obtain a terminal checking result in response to receiving the upgrade preparation information sent by the upgrade control server. The terminal checking result can be a label indicating whether the file client can normally perform the upgrade.

[0055] In the process of solving the above technical problems by using technical solutions, the following problems often occur:

[0056] When using the upgrade system to directly upgrade the file clients, the time consumed during the upgrade is long due to insufficient memory of the file clients, slow data loading speed, and other factors, resulting in a large amount of power resources consumed by the upgrade system during the upgrade.

[0057] In the face of the above technical problems, the following solutions are adopted:

[0058] In some optional implementations of some embodiments, each of the file clients can be further configured to perform the local pre-checking task corresponding to the upgrade preparation information to obtain the terminal checking result by the following steps:

[0059] First, based on a pre-generated temporary controller, a corresponding image preheating task is performed to obtain an image preheating result. The temporary controller can be a pre-generated controller for batch processing one-time tasks. For example, the temporary controller can be a Job controller in Kubernetes. The image preheating result can be a label indicating whether the file client can be upgraded at present according to the execution of the image preheating task. For example, the image preheating result can be “can be upgraded” or “cannot be upgraded”.

[0060] In practice, first, the container image required for upgrading can be automatically pulled by the temporary controller. Then, each of the file clients can check whether the temporary controller successfully pulls the container image by a container image checking instruction, obtaining a container image checking result. The container image checking instruction can be a command for checking the running state of the temporary controller. For example, the container image checking instruction can be a jobs command. The container image checking result can be data for representing the running state of the temporary controller. For example, the container image checking result can be "Running", "Stopped" or "Done". The "Running" can represent that the temporary controller is running. The "Stopped" can represent that the temporary controller stops running. The "Done" can represent that the temporary controller has ended running and exits normally. Then, in response to determining that the container image checking result meets a preset container image checking condition, "can upgrade" can be determined as the image warm-up result. The container image checking condition can be that the container image checking result is "Done". Finally, in response to determining that the container image checking result does not meet the container image checking condition, "cannot upgrade" can be determined as the image warm-up result.

[0061] In the second step, a corresponding resource checking processing task is performed to obtain memory resource data and processor resource usage data. The memory resource data can be the remaining memory capacity in the file client. The processor resource usage data can be the CPU utilization (Central Processing Unit) corresponding to the file client. In practice, each of the file clients can first obtain the memory resource data using a memory remaining resource checking instruction. The memory remaining resource checking instruction can be an instruction that can check the remaining memory capacity. For example, the memory remaining resource checking instruction can be a free command. Secondly, the processor resource usage data can be obtained by a processor resource query instruction. The processor resource query instruction can be an instruction that can check the processor resource usage data. For example, the processor resource query instruction can be a top command.

[0062] Thirdly, the metadata server is detected for connectivity, and a connectivity detection result is obtained. The connectivity detection result can be a label indicating whether the connectivity between the file client and the metadata server can be upgraded. For example, the metadata connectivity detection result can be "upgradable" or "not upgradable". In practice, each of the file clients can send the connectivity information to the metadata server. Then, the character information sent by the metadata server is received. If it is determined that the character information satisfies the connectivity condition, the connectivity detection result can be "upgradable". If it is determined that the character information does not satisfy the connectivity condition, the connectivity detection result can be "not upgradable".

[0063] Fourthly, a virtual device file is detected, and a virtual device detection result is obtained. The virtual device file can be a module for processing file system operation requests. For example, the virtual device file can be FUSE (Filesystem in Userspace). The virtual device file corresponds to a file descriptor (FD). The virtual device detection result can be a label indicating whether the file client can be normally upgraded according to the detection of the virtual device file. For example, the virtual device detection result can be "upgradable" or "not upgradable".

[0064] In practice, first, each of the file clients can check whether the virtual device file exists through a device checking instruction, and obtain a device checking result. The device checking instruction can be an instruction for checking whether the virtual device file exists. For example, the device checking instruction can be "ls -l / dev / fuse". The device checking result can be a return value corresponding to the device checking instruction. For example, the device checking result can be "No such file or directory", indicating that the virtual device file does not exist, or the device checking result can be 0, indicating that the virtual device file exists. Then, in response to determining that the device checking result meets a preset device checking condition, the virtual device file is loaded through a device loading instruction. The device checking condition can be that the device checking result is 0. The device loading instruction can be a command that can load the virtual device file. For example, the device loading instruction can be "modprobe fuse". Then, it can be determined whether the virtual device file is loaded successfully through a loading checking instruction, and a return value corresponding to the loading checking instruction is obtained as loading data. The loading checking instruction can be a command that can determine whether the virtual device file is loaded successfully. For example, the loading checking instruction can be "lsmod|grep fuse". Then, in response to determining that the loading data meets a preset loading condition, "can be upgraded" can be determined as the device checking result. The loading condition can be that the loading data contains a preset string. The preset string can be a pre-set string. For example, the preset string can be "fuse". Then, in response to determining that the loading data does not meet the loading condition, "cannot be upgraded" can be determined as the device checking result.

[0065] In the fifth step, the query rate, average delay data, throughput data, and queue depth data corresponding to the file client are obtained. The query rate can be the query rate per second corresponding to the file client. The average delay data can be the time delay corresponding to the file client. The throughput data can be the throughput corresponding to the file client. The queue depth data can be the length of the waiting queue corresponding to the file client.

[0066] In practice, each of the file clients can obtain the query rate, average delay data, throughput data, and queue depth data corresponding to the file client from a preset performance index database. The performance index database can be a database for storing the performance indexes of file clients in real time. The performance indexes can be data for representing the performance of file clients. The performance indexes can include, but are not limited to, the query rate, average delay data, throughput data, and queue depth data.

[0067] In the sixth step, based on the preset threshold data, the query rate, the average delay data, the throughput data, the queue depth data and the processor resource usage data are standardized to obtain standardized query rate, standardized average delay data, standardized throughput data, standardized queue depth data and standardized processor resource usage data.

[0068] The threshold data can be data representing the threshold corresponding to the query rate, the average delay data, the throughput data, the queue depth data and the processor resource usage data. The threshold data can include query rate threshold, average delay threshold, throughput threshold, queue depth threshold and processor threshold. The query rate threshold can be the threshold corresponding to the query rate. For example, the query rate threshold can be 1000 req / s. The average delay threshold can be the threshold corresponding to the average delay data. For example, the average delay threshold can be 100 ms. The throughput threshold can be the threshold corresponding to the throughput data. For example, the throughput threshold can be 500 MB / s. The queue depth threshold can be the threshold corresponding to the queue depth data. For example, the queue depth threshold can be 50. The processor threshold can be the threshold corresponding to the processor resource usage data. For example, the processor threshold can be 70%.

[0069] In practice, first, each of the file clients can determine the ratio of the query rate to the query rate threshold as the query rate ratio. Then, in response to determining that the query rate ratio is greater than a preset standard value, the standard value can be determined as the standardized query rate. The standard value can be a preset numerical value. For example, the standard value can be 1. Then, in response to determining that the query rate ratio is less than or equal to the standard value, the query rate ratio can be determined as the standardized query rate. The way to generate the standardized average delay data, the standardized throughput data, the standardized queue depth data and the standardized processor resource usage data can refer to the specific embodiments of generating the standardized query rate, which will not be described here.

[0070] In the seventh step, based on the preset weight data, the standardized query rate, the standardized average delay data, the standardized throughput data, the standardized queue depth data and the standardized processor resource usage data, the comprehensive load data is generated.

[0071] The weight data can include query rate weight data, average delay weight data, throughput weight data, queue depth weight data, and processor resource weight data. The query rate weight data can be a weight corresponding to the normalized query rate. The average delay weight data can be a weight corresponding to the normalized average delay data. The throughput weight data can be a weight corresponding to the normalized throughput data. The queue depth weight data can be a weight corresponding to the normalized queue depth data. The processor resource weight data can be a weight corresponding to the normalized processor resource usage data.

[0072] In practice, first, each of the file clients can determine a product of the normalized query rate and the query rate weight data as query rate weighted data. Second, the normalized average delay data and the average delay weight data can be determined as average delay weighted data. Third, the normalized throughput data and the throughput weight data can be determined as throughput weighted data. Fourth, the normalized queue depth data and the queue depth weight data can be determined as queue depth weighted data. Fifth, the normalized processor resource usage data and the processor resource weight data can be determined as processor resource weighted data. Finally, a sum of the query rate weighted data, the average delay weighted data, the throughput weighted data, the queue depth weighted data, and the processor resource weighted data can be determined as the comprehensive load data.

[0073] In the eighth step, based on the image preheating result, the memory resource data, the connectivity detection result, the virtual device detection result, and the comprehensive load data, a terminal check result is generated. In practice, first, each of the file clients can determine that "upgrade is not possible" as a load detection result in response to determining that the comprehensive load data is greater than a preset load threshold. The load threshold can be a preset value. Here, the specific setting of the load threshold is not limited. Second, "upgrade is possible" can be determined as the load detection result in response to determining that the comprehensive load data is less than or equal to the load threshold. Third, "upgrade is possible" can be determined as the terminal check result in response to determining that the image preheating result, the memory resource data, the connectivity detection result, the virtual device detection result, and the load detection result satisfy a preset pre-check condition. The pre-check condition can be that the image preheating result, the memory resource data, the connectivity detection result, the virtual device detection result, and the load detection result are all "upgrade is possible". Then, "upgrade is not possible" can be determined as the terminal check result in response to determining that the image preheating result, the memory resource data, the connectivity detection result, the virtual device detection result, and the load detection result do not satisfy the pre-check condition.

[0074] The technical scheme and related content thereof combined with steps 201 to 2010 are an inventive point of the embodiment of the present disclosure, and solve the problem of "high power resource consumption". Factors leading to high power resource consumption are often as follows: when using an upgrade system to directly upgrade each file client, the time consumed during the upgrade is likely to be long due to factors such as insufficient memory of the file client and slow data loading speed, resulting in high power resource consumption of the upgrade system during the upgrade. If the above factors are solved, power resource consumption can be reduced. To achieve this effect, the present disclosure first performs a corresponding image warm-up task based on a pre-generated temporary controller to obtain an image warm-up result. Thus, the file client can perform image warm-up in advance to speed up the upgrade. Second, a corresponding resource inspection processing task is performed to obtain memory resource data and processor resource usage data. Thus, the file client can determine the memory resource data and processor resource usage data at the current time. Then, a connectivity detection processing is performed on the above metadata server to obtain a connectivity detection result. Then, a detection processing is performed on the preset virtual device file to obtain a virtual device detection result. Thus, the file client can detect whether the virtual device file can be normally invoked. Then, the query rate, average delay data, throughput data and queue depth data corresponding to the file client are obtained. Then, based on the preset threshold data, the query rate, the average delay data, the throughput data, the queue depth data and the processor resource usage data are standardized to obtain standardized query rate, standardized average delay data, standardized throughput data, standardized queue depth data and standardized processor resource usage data. Then, based on the preset weight data, the standardized query rate, the standardized average delay data, the standardized throughput data, the standardized queue depth data and the standardized processor resource usage data, comprehensive load data is generated. Thus, the comprehensive load data of the file client can be determined through the query rate, average delay data, throughput data, queue depth data and processor resource usage data of the file client at the current time. Finally, based on the image warm-up result, the memory resource data, the connectivity detection result, the virtual device detection result and the comprehensive load data, a terminal inspection result is generated. Thus, it can be determined through the generated terminal inspection result whether the file client can be normally upgraded at the current time. Also, before upgrading the file client, the file client can be allowed to perform image warm-up in advance, and the current memory size and processor resource utilization of the file client can be used to determine whether the file client can be normally upgraded at the current time, so that the probability of the time consumed during the upgrade being long due to factors such as insufficient memory of the file client and slow data loading speed can be reduced, and thus the power resource consumed by the upgrade system during the upgrade can be reduced.

[0075] Step 204, each of the file clients sends the terminal check result to the upgrade control server.

[0076] In some embodiments, each of the file clients can send the terminal check result to the upgrade control server.

[0077] Step 205, the upgrade control server sends the preset write empty information to each of the file clients in response to determining that the received terminal check results and the upgrade check result meet a preset check result condition.

[0078] In some embodiments, the upgrade control server can send the preset write empty information to each of the file clients in response to determining that the received terminal check results and the upgrade check result meet a preset check result condition. The check result condition can be that the terminal check results sent by each of the file clients are received within a preset check time range and each of the terminal check results is "upgradeable". The check time range can be from when the upgrade control server sends the upgrade preparation information to a preset time thereafter. The preset time can be a time preset by a technician. For example, the preset time can be 5 minutes. The write empty information can be information for prompting each of the file clients to start performing a corresponding write empty task.

[0079] In practice, in response to determining that the received terminal check result and the upgrade check result satisfy the check result condition, the upgrade control server can send the write drain information to each node agent corresponding to each file client. Then, each node agent can be configured to send a preset drain marker to the metadata server in response to receiving the write drain information sent by the upgrade control server, to prompt the corresponding file client to perform the corresponding write drain task. The drain marker can be a string for prompting the file client to perform the corresponding write drain task. For example, the drain marker can be "upgrade:drain:<mount_identifier>=ON". The drain marker can include a drain template string, a mount point identifier, and a drain identifier. The drain template string can be a fixed string corresponding to the drain marker. For example, the drain template string can be "upgrade:drain". The mount point identifier can be a string for uniquely identifying a mount point. The mount point can be a directory entry corresponding to the file client for connecting to the file system or the storage device. For example, the mount point identifier can be "<mount_identifier>". The drain identifier can be a string for indicating whether draining is needed. For example, the drain identifier can be "ON" or "OFF". "ON" can be used to indicate that draining is needed. "OFF" can be used to indicate that draining is not needed.

[0080] In some embodiments, each file client of the plurality of file clients can be configured to perform the following steps:

[0081] At step 206, each file client of the plurality of file clients performs a corresponding write drain task in response to receiving the write drain information sent by the upgrade control server, to obtain a write drain result.

[0082] In some embodiments, each file client of the plurality of file clients can perform a corresponding write drain task in response to receiving the write drain information sent by the upgrade control server, to obtain a write drain result. The write drain result can be a label for indicating whether the write drain task is successfully performed. For example, the write drain result can be "drain success" or "drain failure".

[0083] In the process of solving the above technical problems by adopting the technical solutions, the following problems are often accompanied:

[0084] When each file client is directly upgraded by using the upgrade system, the file client needs to be terminated, and data in the file client is easily lost due to interruption of running of the file client, additional computing resources need to be allocated by the system to handle the data loss, and the system consumes more computing resources.

[0085] To solve the above technical problems, the following solutions are adopted:

[0086] In some optional implementations of some embodiments, each of the above file clients can be further configured to perform a corresponding write draining task by the following steps to obtain a write draining result:

[0087] Firstly, a mode detection process is performed on the mount point corresponding to the file client to obtain a mode detection result. The mount point can be a directory entry corresponding to the file client for connecting to the file system or the storage device. The mount point identifier can be a string for uniquely identifying the mount point. For example, the mount point identifier can be “<mount_identifier>”. The mode detection result can be a label for indicating whether the write operation corresponding to the file client is closed. For example, the mode detection result can be “closed” or “not closed”.

[0088] In practice, firstly, each of the above file clients can combine a preset draining template string and a mount point identifier corresponding to the mount point into mount query information. The draining template string can be a preset string. For example, the draining template string can be “upgrade:drain”. Then, the mount query information can be found in the metadata server by using a search instruction to obtain data returned by the search instruction as search return data. The search instruction can be a command that can search for a specific string in the metadata server. For example, the search instruction can be a SCAN command. Then, in response to determining that the search return data meets a preset search return condition, “not closed” can be determined as the mode detection result. The search return condition can be that the search return data contains a preset search string. The search string can be a preset string. For example, the search string can be “ON”. Then, in response to determining that the search return data does not meet the search return condition, “closed” can be determined as the mode detection result.

[0089] The second step involves a state transition process for the mode corresponding to the mount point, in response to the determination that the above mode detection result does not meet the preset empty mode condition. The mode corresponding to the mount point can be a write mode. The empty mode condition can be that the above mode detection result is "closed". In practice, each file client can disable its write operation using a preset write control command to perform the state transition process for the mode corresponding to the mount point. The write control command can be a command that controls the write operation of the file client. For example, the write control command can be the `mesg` command.

[0090] As an example, each of the file clients mentioned above can disable the write operation of the file client by using "mesg n" to perform state transition processing on the mode corresponding to the above mount point.

[0091] Third, in response to the determination that the above pattern detection results meet the above emptying pattern conditions, the following steps are performed:

[0092] The first sub-step involves determining the database corresponding to the file client as the terminal database. This database can be the memory corresponding to the file client.

[0093] The second sub-step, based on the loop count data, executes the following loop steps:

[0094] Sub-step one: Update the loop count data based on a preset value. The preset value can be a pre-defined value, such as 1. The loop count data can be data representing the number of times the loop step has been executed. In practice, each file client can determine the loop count data by summing the loop count data with the preset value, and then update the loop count data accordingly.

[0095] Sub-step two involves updating the hardware storage corresponding to the aforementioned file clients based on the terminal database. This hardware storage can be the disk corresponding to the file client. In practice, each file client can use a data transfer command to transfer data stored in the terminal database to the hardware storage, thereby updating the hardware storage corresponding to the file client. This data transfer command can be any command capable of transferring data from the terminal database to the hardware storage. For example, the data transfer command could be a `sync` command.

[0096] Sub-step three, data cleaning processing is performed on the terminal database to update the terminal database. In practice, each of the file clients can clean the data in the terminal database through a data cleaning instruction. The data cleaning instruction can be a command that can clean the data in the memory. For example, the data cleaning instruction can be "echo 3 > / proc / sys / vm / drop_caches".

[0097] Sub-step four, data detection processing is performed on the updated terminal database to obtain a data detection result. The data detection result can be a label indicating whether there is data in the updated terminal database. For example, the data detection result can be "there is data" or "there is no data".

[0098] In practice, each of the file clients can check whether there is data in the updated terminal database through a data checking instruction to obtain terminal data usage data. The data checking instruction can be a command for checking the usage of the updated terminal database. For example, the data checking instruction can be the free command in the Linux system. The terminal data usage data can be data indicating the size of the memory occupied by the data stored in the terminal database. Then, in response to determining that the terminal data usage data satisfies a preset data usage condition, "there is data" can be determined as the data detection result. The data usage condition can be that the terminal data usage data is greater than a preset memory usage threshold. The memory usage threshold can be a preset value. Here, the specific setting of the memory usage threshold is not limited. In response to determining that the terminal data usage data does not satisfy the data usage condition, "there is no data" can be determined as the data detection result.

[0099] Sub-step five, in response to determining that the data detection result does not satisfy a preset database detection condition, the updated terminal database is used to perform the above-mentioned loop step again. The database detection condition can be that the data detection result is "there is no data".

[0100] Sub-step six, in response to determining that the data detection result satisfies the database detection condition, a preset first emptying state is determined as the write emptying result. The first emptying state can be a label indicating that the file client is successfully emptied. For example, the first emptying state can be "emptying success".

[0101] In response to determining that the updated cycle count data satisfies a preset cycle execution condition, a preset second emptying state is determined as the write emptying result. The second emptying state can be a label representing a file client emptying failure. For example, the second emptying state can be "emptying failure". The cycle execution condition can be that the updated cycle count data is greater than a preset cycle count threshold. The cycle count threshold can be a preset numerical value. Here, the specific setting of the cycle count threshold is not limited.

[0102] The technical scheme and related content thereof, combined with steps 201 to 2010, serve as one inventive point of the embodiments of the present disclosure, and solve the problem of "more computing resources consumed by the system". Factors that lead to lower system security are often as follows: when upgrading the system directly to upgrade each file client, the file client needs to terminate running, which is likely to cause data loss in the file client due to the interruption of file client running, leading to the system needing to allocate additional computing resources to handle the situation of abnormal data loss, resulting in more computing resources consumed by the system. If the above factors are solved, the computing resources consumed by the system can be reduced. To achieve this effect, the present disclosure first performs mode detection processing on the mounting point corresponding to the file client to obtain a mode detection result. Thus, the current write mode of the mounting point can be determined. Secondly, in response to determining that the mode detection result does not meet the preset emptying mode condition, state conversion processing is performed on the mode corresponding to the mounting point. Thus, when the current write mode of the file client is not prohibited from writing, the mode can be converted to a prohibited write mode. Then, in response to determining that the mode detection result meets the emptying mode condition, the following steps are performed: Then, the database corresponding to the file client is determined as a terminal database. Then, based on the cycle number data, the following loop steps are performed: Then, the cycle number data is updated based on a preset value. Then, based on the terminal database, the hardware memory corresponding to the file client is updated. Thus, the data in the terminal database can be stored in the hardware memory corresponding to the file client. Then, the terminal database is subjected to data clearing processing to update the terminal database. Thus, the data in the terminal database can be cleared. Then, the updated terminal database is subjected to data detection processing to obtain a data detection result. Thus, it can be detected whether there is remaining data in the updated terminal database. Then, in response to determining that the data detection result does not meet the preset database detection condition, the updated terminal database is used to perform the loop steps again. Thus, when the data detection result does not meet the database detection condition, the loop steps can be performed again. Then, in response to determining that the data detection result meets the database detection condition, a preset first emptying state is determined as a write emptying result. Finally, in response to determining that the updated cycle number data meets a preset cycle execution condition, a preset second emptying state is determined as the write emptying result. Thus, the write emptying result can be determined. Also, when upgrading the file client, the data temporarily stored in the memory of the file client can be saved to the hard disk in advance, so that the probability of data loss due to the interruption of file client running can be reduced, and the probability of the system needing to allocate additional computing resources to handle the situation of abnormal data loss can be reduced, and thus the computing resources consumed by the system can be reduced.

[0103] Step 207, each of the file clients sends the write emptying result to the upgrade control server.

[0104] In some embodiments, each of the file clients can send the write emptying result to the upgrade control server.

[0105] Step 208, the upgrade control server sends preset upgrade information to each of the file clients in response to determining that the received write emptying results meet preset emptying conditions.

[0106] In some embodiments, the upgrade control server can send preset upgrade information to each of the file clients in response to determining that the received write emptying results meet preset emptying conditions.

[0107] The emptying conditions can be that the upgrade control server receives the write emptying results sent by each of the file clients within a preset emptying time range, and each of the write emptying results is “emptying success”. The emptying time range can be from when the upgrade control server sends the write emptying information to a preset emptying time thereafter. The preset emptying time can be a time preset by a technician. For example, the preset emptying time can be 5 minutes. The upgrade information can be information for prompting each of the file clients to prepare to start upgrading.

[0108] In some embodiments, each of the file clients can be configured to perform the following steps:

[0109] Step 209, each of the file clients performs an upgrade task corresponding to the upgrade information received from the upgrade control server, to obtain upgrade state information.

[0110] In some embodiments, each of the file clients can perform an upgrade task corresponding to the upgrade information received from the upgrade control server, to obtain upgrade state information. The upgrade state information can be a label for indicating whether the file client upgrade is successful. For example, the upgrade state information can be “upgrade success” or “upgrade failure”.

[0111] In some optional implementations of some embodiments, each of the file clients can be further configured to perform an upgrade task corresponding to the upgrade information, to obtain upgrade state information, by the following steps:

[0112] In a first step, upgrade mode information is determined based on a pre-stored executable upgrade file. The executable upgrade file can be a file used to upgrade a file client. The executable upgrade file corresponds to a file extension. The upgrade mode information can be information used to represent an upgrade mode to be used when upgrading the file client. For example, the upgrade mode information can be "rebuild upgrade" or "binary upgrade". In practice, first, each of the file clients can determine the file extension corresponding to the executable upgrade file as a target file extension. Then, in response to determining that the target file extension satisfies a preset extension condition, "binary upgrade" can be determined as the upgrade mode information. The extension condition can be that the target file extension contains a preset extension string. The extension string can be a string preset by a technician. For example, the extension string can be "bin".

[0113] In a second step, in response to determining that the upgrade mode information satisfies a preset rebuild upgrade condition, the following upgrade steps are performed based on a mount storage container corresponding to the file client:

[0114] In a first sub-step, a mount point corresponding to the file client is determined as a file mount point. The rebuild upgrade condition can be that the upgrade mode information is "rebuild upgrade".

[0115] In a second sub-step, temporary file data, file descriptor data, and descriptor state information are generated based on the file mount point. The temporary file data can be a file snapshot corresponding to the file mount point. The file snapshot can be used to record data blocks and meta information of all files included by a system or device at a specific time point. The file descriptor data can be a file descriptor (FD) corresponding to the virtual device file. The descriptor storage state information can be a tag used to represent whether a node agent corresponding to the file client can normally run the virtual device file corresponding to the file descriptor data. For example, the descriptor storage state information can be "can normally run" or "cannot normally run".

[0116] In practice, first, each of the file clients can generate a file snapshot corresponding to the file mount point as temporary file data through a file system snapshot tool. The file system snapshot tool can be a tool capable of backing up data. For example, the file system snapshot tool can be an Rsnapshot tool. Second, the file descriptor corresponding to the virtual device file can be determined as file descriptor data. Then, the IP address corresponding to the node agent can be viewed through a running instruction, and the data returned by the node agent is received as node return data in response. The node return data can be data representing whether the node agent is running normally. For example, the node return data can be "Destination host unreachable", representing that the node agent is not running normally, or "Reply from 192.168.1.1: bytes=32 time<1ms TTL=128", representing that the node agent is running normally. Then, in response to determining that the node return data meets a preset node return condition, "can run normally" can be determined as the descriptor storage state information. The node return condition can be that the node return data is not "Destination host unreachable". Then, in response to determining that the node return data does not meet the node return condition, "cannot run normally" can be determined as the descriptor storage state information.

[0117] Third sub-step, in response to determining that the descriptor state information meets a preset descriptor state condition, a storage container corresponding to the executable upgrade file is generated based on the executable upgrade file. The descriptor state condition can be that the descriptor state information is "can run normally". The storage container can be a Mount Pod for running a file client.

[0118] In practice, first, each of the file clients can combine a preset system name and the target version information into a file name. The system name can be the name of the file system corresponding to the file client. For example, the system name can be "juicedata". Second, the container name corresponding to the file client can be modified into the file name by a data modification instruction to point the container name corresponding to the file client to the executable upgrade file. The data modification instruction can be an instruction capable of modifying the parameters corresponding to the file client. For example, the data modification instruction can be a kubectl edit command. The container name can be the name of the mounted storage container corresponding to the file client. Then, the mounted storage container corresponding to the file client can be deleted by a container deletion instruction. The container deletion instruction can be a command capable of deleting the mounted storage container. For example, the container deletion instruction can be a kubectl delete pod command. Then, in response to determining that the mounted storage container corresponding to the file client has been deleted, a container storage plug-in corresponding to the file client can automatically generate a new mounted storage container as a storage container corresponding to the executable upgrade file. The container storage plug-in can be a CSI (Container Storage Interface). The storage container corresponds to a container name.

[0119] In the fourth sub-step, the temporary file data and the file descriptor data are stored into the storage container to update the storage container.

[0120] In the fifth sub-step, a state detection process is performed on the updated storage container to obtain container state information. The container state information can be a label used to represent whether the updated storage container can normally operate. For example, the container state information can be "can normally operate" or "cannot normally operate".

[0121] In practice, each of the file clients can view the storage container information corresponding to the storage container through the container state detection instruction and the container name corresponding to the storage container. The container state detection instruction can be a command that can view the running state of the mounted storage container. For example, the container state detection instruction can be a kubectl get pod command. As an example, when the container state detection instruction is a kubectl get pod command and the container name corresponding to the storage container is "mypod", the storage container information of the storage container with the container name "mypod" can be viewed through the "kubectl get pod mypod" command. The storage container information can be information corresponding to the storage container. The storage container information can include, but is not limited to, the container name and the container state. The container name can be the name corresponding to the storage container. The container state can be information used to represent the running state of the storage container. For example, the container state can be "Running" or "Pending". When the container state is "Running", it can represent that the storage container is running. When the container state is "Pending", it can represent that the storage container has not yet run. Then, in response to determining that the container state included in the storage container information satisfies the preset container detection return condition, "can normally run" can be determined as the container state information. The container detection return condition can be that the container state is "Running". Then, in response to determining that the container state included in the storage container information does not satisfy the container detection return condition, "cannot normally run" can be determined as the container state information.

[0122] In the sixth sub-step, in response to determining that the container state information does not satisfy the preset container detection condition, the updated storage container is used as the mounted storage container, and the upgrade step is executed again. The container detection condition can be that the container state information is "can normally run".

[0123] In the seventh sub-step, in response to determining that the number of times of executing the upgrade step is greater than the preset upgrade number threshold, a preset first upgrade state is determined as the upgrade state information. The upgrade number threshold can be a preset numerical value. Here, the specific setting of the upgrade number threshold is not limited. The first upgrade state can be a label used to represent the failure of the execution of the upgrade step. For example, the first upgrade state can be "upgrade failure".

[0124] An eighth sub-step of determining the preset second upgrade state as the upgrade state information in response to determining that the container state information satisfies the container detection condition. The second upgrade state can be a label representing that the upgrade step is successfully executed. For example, the second upgrade state can be "upgrade success".

[0125] In some optional implementations of some embodiments, each of the file clients can be further configured to generate the temporary file data, the file descriptor data and the descriptor state information based on the file mount point by the following steps:

[0126] A first step of performing the following mounting step based on the file mount point:

[0127] A first sub-step of obtaining the file descriptor data and the temporary file data corresponding to the file mount point. The temporary file data can be a file snapshot corresponding to the file mount point. The file snapshot can be a file recording data blocks and metadata of all files of a system or device at a specific time point. The file descriptor data can be a file descriptor (FD) corresponding to the virtual device file.

[0128] In practice, each of the file clients can generate the temporary file data corresponding to the file mount point by using the file system snapshot tool. Then, the file descriptor corresponding to the virtual device file can be determined as the file descriptor data.

[0129] A second sub-step of sending the file descriptor data to the node agent corresponding to the file client.

[0130] A third sub-step of performing a process query on the file descriptor data to obtain a node process query result. The node process query result can be a process identifier (PID) corresponding to the file descriptor data.

[0131] In practice, each of the file clients can view the virtual device file corresponding to the file descriptor data through a process viewing instruction to obtain process query data. The process viewing instruction can be an instruction capable of viewing process query data corresponding to the file client. For example, the process viewing instruction can be an lsof command. The process query data can be a structured table in which each row corresponds to a virtual device file and each column corresponds to a data name. Each column of the process query data can correspond to a data name. The data names can include, but are not limited to, a process name, a file descriptor data, and a process control symbol. Then, a character finding instruction can be used to find a row corresponding to the file descriptor data as a target row. The character finding instruction can be an instruction capable of finding a specific character string. For example, the character finding instruction can be a find command. Then, a data name corresponding to a column in which data included in the target row is located can be determined as the process control symbol, and the data name is determined as the node process query result.

[0132] In the fourth sub-step, descriptor storage state information is generated based on the node process query result and the node agent corresponding to the file client. The descriptor storage state information can be a label used to represent whether the node agent can normally run the virtual device file corresponding to the file descriptor data. For example, the descriptor storage state information can be "can normally run" or "cannot normally run".

[0133] In practice, the process control symbol corresponding to the node agent can be determined as a target process control symbol. Then, a string comparison function is used to compare the target process control symbol and the node process query result, and a return value of the string comparison function is obtained as a string comparison result. The string comparison function can be a function capable of comparing two character strings to determine whether the two character strings are the same. For example, the string comparison function can be a strcmp function. Then, in response to determining that the string comparison result satisfies a preset string comparison condition, "can normally run" can be determined as the descriptor storage state information. The string comparison condition can be that the string comparison result is a preset comparison value. The comparison value can be a preset numerical value. For example, the preset comparison value can be 0. Then, in response to determining that the string comparison result does not satisfy the string comparison condition, "cannot normally run" can be determined as the descriptor storage state information.

[0134] In the second step, in response to determining that the descriptor storage state information does not satisfy a preset descriptor storage condition, the mounting step is performed again. The descriptor storage condition can be that the descriptor storage state information is "can normally run".

[0135] The third step is to determine the preset mounting success information as the descriptor state information in response to determining that the descriptor storage state information satisfies the descriptor storage condition. The mounting success information can be information indicating that the mounting step is successful. For example, the mounting success information can be "mounting success".

[0136] The fourth step is to determine the preset mounting failure information as the descriptor state information in response to determining that the number of times of executing the mounting step is greater than the preset mounting threshold. The mounting threshold can be a preset value. The mounting failure information can be information indicating that the mounting step is unsuccessful. For example, the mounting failure information can be "mounting failure".

[0137] Optionally, each of the file clients can be further configured to determine the upgrade mode information based on the pre-stored executable upgrade file, and the file client batch upgrade system can be further configured to perform the following steps:

[0138] Each of the file clients is further configured to perform the following binary upgrade steps in response to determining that the upgrade mode information satisfies the preset binary upgrade condition.

[0139] The first step is to determine the mounting storage container corresponding to the file client as the target mounting storage container. The binary upgrade condition can be that the upgrade mode information is "binary upgrade".

[0140] The second step is to store the executable upgrade file and the preset configuration file to the target mounting storage container to update the target mounting storage container. The configuration file can be a configuration file corresponding to the executable upgrade file.

[0141] The third step is to determine the process mounting information based on the preset configuration signal and the updated target mounting storage container. The configuration signal can be a SIGHUP signal. The process mounting information can be information indicating whether the file client is successfully upgraded. For example, the process mounting information can be "upgrade success" or "upgrade failure".

[0142] In practice, each of the file clients can send the configuration signal to the updated target mounted storage container, so that the updated target mounted storage container starts to load the configuration file again. Then, each of the file clients can determine the current version number of the file client through a version checking instruction. The version checking instruction can be a command for checking the current version number of the file client. For example, the version checking instruction can be a juicefs version command. Then, the version number and the version name included in the target version information can be compared through the string comparison function, and the return value of the string comparison function is taken as the version number comparison result. Then, in response to determining that the version number comparison result satisfies the preset version number comparison condition, the process mounting information can be determined as "upgrade success". The version number comparison condition can be that the version number comparison result is the comparison value. Then, in response to determining that the version number comparison result does not satisfy the version number comparison condition, the process mounting information can be determined as "upgrade failure".

[0143] In practice, in response to determining that the process mounting information satisfies the preset process mounting condition, "execution success" can be determined as the upgrade status information. The process mounting condition can be that the process mounting information is "upgrade success". In response to determining that the process mounting information does not satisfy the process mounting condition, "execution failure" can be determined as the upgrade status information.

[0144] In practice, in response to determining that the process mounting information satisfies the preset process mounting condition, "execution success" can be determined as the upgrade status information. The process mounting condition can be that the process mounting information is "upgrade success". In response to determining that the process mounting information does not satisfy the process mounting condition, "execution failure" can be determined as the upgrade status information.

[0145] Step 2010, each of the file clients sends the upgrade status information to the upgrade control server.

[0146] In some embodiments, each of the file clients can send the upgrade status information to the upgrade control server.

[0147] Optionally, the file client batch upgrade system can be further configured to perform the following steps:

[0148] The upgrade control server is further configured to perform the following steps:

[0149] In a first step, in response to determining that the received respective upgrade status information satisfies the preset upgrade status condition, the preset transaction status information is updated based on a preset upgrade success character. The upgrade success character can be a character representing that the respective file client is upgraded successfully. For example, the upgrade success character can be "COMMITTED". The transaction status information can be information representing a status of an upgrade task. The upgrade task can be a task of upgrading the respective file client by the upgrade control server.

[0150] In a second step, in response to determining that the received respective upgrade status information does not satisfy the preset upgrade status condition, the transaction status information is updated based on a preset upgrade failure character. The upgrade failure character can be a character representing that the respective file client fails to be upgraded. For example, the upgrade failure character can be "FAILED".

[0151] Optionally, after the upgrade control server is further configured to send the preset upgrade information to the respective file client in response to determining that the received respective write empty result satisfies the preset empty condition, the file client batch upgrade system can be further configured to perform the following steps:

[0152] In a first step, the upgrade control server is further configured to send preset write rollback information to the respective file client. The write rollback information can be information prompting the respective file client to start performing a rollback step.

[0153] In a second step, each of the respective file client is further configured to perform the following rollback step:

[0154] In a first sub-step, a mount point corresponding to the file client is determined as a target file mount point.

[0155] A second sub-step is to perform a mode detection process on the target file mount point to obtain mount mode information. The mount mode information can be a label indicating whether the write operation of the file client is closed or not. For example, the mount mode information can be "closed" or "not closed". In practice, each of the file clients can first determine the mount point identifier corresponding to the target file mount point as a target mount point identifier. Then, the empty template string and the target mount point identifier can be combined into target query information. Then, the target query information can be searched in the metadata server through the search instruction, and the data returned by the search instruction is taken as target search return data. Then, in response to determining that the target search return data meets the search return condition, "not closed" can be determined as the mount mode information. Finally, in response to determining that the target search return data does not meet the search return condition, "closed" can be determined as the mount mode information.

[0156] A third sub-step is to, in response to determining that the mount mode information does not meet a preset write condition, perform mode adjustment on the target file mount point to update the target file mount point. The write condition can be that the mount mode information is "not closed".

[0157] In practice, each of the file clients can start the write operation of the file client through the write control instruction to perform mode adjustment on the target file mount point. As an example, each of the file clients can start the write operation of the file client through "mesg y" to perform mode adjustment on the target file mount point.

[0158] The above various embodiments of the present disclosure have the following beneficial effects: the file client batch upgrade system of some embodiments of the present disclosure can improve the processing efficiency during upgrade and reduce the hardware loss of the system. Specifically, the reason for the low processing efficiency and large hardware loss during upgrade is that in the process of upgrading the file clients one by one, it is easy to cause the coexistence of new and old version file clients, reduce the compatibility between the file clients, cause the system to freeze due to poor compatibility when the old version file client processes a new request, and thus easily cause the processing efficiency to be low during upgrade, and easily cause the hardware loss of the system to be large due to frequent freezing. Based on this, the file client batch upgrade system of some embodiments of the present disclosure includes an upgrade control server and a plurality of file clients, and the upgrade control server is configured to perform the following steps: first, send the preset upgrade preparation information to the plurality of file clients. In this way, the upgrade preparation information can be sent to the plurality of file clients to prompt the plurality of file clients to start preparing for upgrade. Secondly, perform a corresponding upgrade check task to obtain an upgrade check result. In this way, the upgrade controller can check whether the current state of itself can upgrade the plurality of file clients to obtain the upgrade check result. Then, each file client in the plurality of file clients is configured to perform the following steps: then, in response to receiving the upgrade preparation information sent by the upgrade control server, perform a local pre-check task corresponding to the upgrade preparation information to obtain a terminal check result. In this way, each file client can prepare for upgrade and detect whether it can normally upgrade at the current time. Then, send the terminal check result to the upgrade control server. Then, the upgrade control server is further configured to, in response to determining that the received plurality of terminal check results and the upgrade check result satisfy a preset check result condition, send preset write empty information to the plurality of file clients. In this way, when the upgrade controller determines that it can upgrade the plurality of file clients and each file client can normally upgrade, the write empty information is sent to the plurality of file clients. Then, each file client in the plurality of file clients is further configured to perform the following steps: then, in response to receiving the write empty information sent by the upgrade control server, perform a corresponding write empty task to obtain a write empty result. In this way, the file client can perform the write empty task. Then, send the write empty result to the upgrade control server. Then, the upgrade control server is further configured to, in response to determining that the received plurality of write empty results satisfy a preset empty condition, send preset upgrade information to the plurality of file clients. In this way, when the upgrade control server determines that the write empty task of each file client is completed, the upgrade information can be sent to the plurality of file clients to simultaneously upgrade the plurality of file clients.Then, each of the file clients is further configured to perform the following steps: Then, in response to receiving the upgrade information sent by the upgrade control server, performing an upgrade task corresponding to the upgrade information, to obtain upgrade status information. In this way, the file client can start the upgrade. Finally, the upgrade status information is sent to the upgrade control server. Because the upgrade control server can upgrade each file client at the same time, and only after all the file clients complete the task of the current stage, the next step is started, the probability of system freezing caused by poor compatibility of each file client can be reduced, the upgrade efficiency during the upgrade can be improved, and the hardware loss of the system can be reduced.

[0159] In some embodiments, the client, server can communicate using any currently known or future developed network protocol, such as HTTP (HyperText Transfer Protocol), and can be interconnected with digital data communications (e.g., a communications network) of any form or medium (e.g., wire or wireless, etc.). Examples of communications networks include local area networks ("LAN"), wide area networks ("WAN"), internetworks (e.g., the Internet), and peer-to-peer networks (e.g., ad hoc peer-to-peer networks), as well as any currently known or future developed networks.

[0160] The flow and block diagrams in the drawings show possible architectures, functional and operational, for systems, methods and computer program products according to various embodiments of the present disclosure. In this regard, each block in the flow and block diagrams can represent a module, a segment, or a portion of code that comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that in some alternative implementations, the functions noted in the blocks can occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently or the blocks may

[0161] The functions described above in this detailed description above can be performed at least in part by one or more hardware logic components. For example, and without limitation, illustrative types of hardware logic components that can be used include Field-programmable Gate Arrays (FPGAs), Program-specific Integrated Circuits (ASICs), Program-specific Standard Products (ASSPs), System-on-a-chip systems (SOCs), Complex Programmable Logic Devices (CPLDs), etc.

[0162] The above description is merely exemplary of some preferred embodiments of the present disclosure and technical principles of the present disclosure. It should be understood by those skilled in the art that the scope of the application involved in the embodiments of the present disclosure is not limited to the technical solutions formed by the specific combinations of the above technical features, and should also cover other technical solutions formed by the combinations of the above technical features or equivalent features without departing from the above inventive concept. For example, the above features and technical features with similar functions disclosed in the embodiments of the present disclosure (but not limited to) are replaced with each other to form technical solutions.

Claims

1. A file client bulk upgrade system, comprising: An upgrade control server and a plurality of file clients; The upgrade control server is configured to perform the following steps: sending preset upgrade preparation information to the plurality of file clients; performing corresponding upgrade check tasks to obtain upgrade check results; Each of the plurality of file clients is configured to perform the following steps: in response to receiving the upgrade preparation information sent by the upgrade control server, performing a local pre-check task corresponding to the upgrade preparation information to obtain terminal check results; sending the terminal check results to the upgrade control server; The upgrade control server is further configured to, in response to determining that the received terminal check results and the upgrade check results satisfy a preset check result condition, send preset write emptying information to the plurality of file clients; Each of the plurality of file clients is further configured to perform the following steps: in response to receiving the write emptying information sent by the upgrade control server, performing a corresponding write emptying task to obtain write emptying results; sending the write emptying results to the upgrade control server; The upgrade control server is further configured to, in response to determining that the received write emptying results satisfy a preset emptying condition, send preset upgrade information to the plurality of file clients; Each of the plurality of file clients is further configured to perform the following steps: in response to receiving the upgrade information sent by the upgrade control server, performing an upgrade task corresponding to the upgrade information to obtain upgrade state information, wherein each of the plurality of file clients corresponds to a mount point and a mount storage container; and each of the plurality of file clients is further configured to perform the upgrade task corresponding to the upgrade information to obtain the upgrade state information by the following steps: determining upgrade mode information based on a pre-stored executable upgrade file; in response to determining that the upgrade mode information satisfies a preset reconstruction upgrade condition, performing the following upgrade steps based on the mount storage container corresponding to the file client: determining the mount point corresponding to the file client as a file mount point; generating temporary file data, file descriptor data, and descriptor state information based on the file mount point; in response to determining that the descriptor state information satisfies a preset descriptor state condition, generating a storage container corresponding to the executable upgrade file based on the executable upgrade file; storing the temporary file data and the file descriptor data to the storage container to update the storage container; performing state detection processing on the updated storage container to obtain container state information; in response to determining that the container state information does not satisfy a preset container detection condition, using the updated storage container as a mount storage container to perform the upgrade steps again; in response to determining that the number of times of performing the upgrade steps is greater than a preset upgrade number threshold, determining a preset first upgrade state as the upgrade state information; In response to determining that the container state information satisfies the container detection condition, determining a preset second upgrade state as the upgrade state information; sending the upgrade state information to the upgrade control server.

2. The file client bulk upgrade system of claim 1, wherein, The file client batch upgrade system further comprises: The upgrade control server is further configured to perform the following steps: In response to determining that each received upgrade state information satisfies a preset upgrade state condition, updating preset transaction state information based on a preset upgrade success character; In response to determining that each received upgrade state information does not satisfy the upgrade state condition, updating the transaction state information based on a preset upgrade failure character.

3. The file client bulk upgrade system of claim 1, wherein, Each of the file clients corresponds to a mount point; and after the upgrade control server is further configured to send preset upgrade information to the file clients in response to determining that each received write emptying result satisfies a preset emptying condition, the file client batch upgrade system further comprises: The upgrade control server is further configured to send preset write rollback information to the file clients; Each of the file clients is further configured to perform the following rollback steps: determining the mount point corresponding to the file client as a target file mount point; performing mode detection processing on the target file mount point to obtain mount mode information; In response to determining that the mount mode information does not satisfy a preset write condition, performing mode adjustment on the target file mount point to update the target file mount point.

4. The file client bulk upgrade system of claim 1, wherein, The upgrade preparation information comprises configuration information, the configuration information comprises current version information, target version information, and update time range data, and the upgrade control server corresponds to identifier information; The upgrade control server is further configured to perform corresponding upgrade check tasks to obtain upgrade check results by the following steps, comprising: performing compatibility detection processing on the current version information and the target version information included in the upgrade preparation information based on preset upgrade path information to obtain a version detection result; generating a cluster state detection result based on preset cluster state detection information, a preset target server, and a preset health threshold value data; obtaining current time data; generating a time detection result based on the current time data and the update time range data; performing a corresponding memory resource detection task to obtain memory remaining data; generating a remaining memory detection result based on the memory remaining data and a preset memory threshold value data; performing connectivity detection processing on a preset metadata server to obtain a metadata connectivity detection result; performing connectivity detection processing on a preset interface server based on preset access information to obtain an interface connectivity detection result; generating an exclusivity detection result based on the identifier information corresponding to the upgrade control server; generating an upgrade check result based on the version detection result, the cluster state detection result, the time detection result, the remaining memory detection result, the interface connectivity detection result, and the exclusivity detection result.

5. The file client bulk upgrade system of claim 4, wherein, The upgrade control server is further configured to generate a cluster state detection result based on preset cluster state detection information, a preset target server, and preset health threshold data, including: generating health node quantity data and node total quantity data based on the cluster state detection information and the target server; determining a health node proportion data as a ratio of the health node quantity data to the node total quantity data; determining a preset first cluster detection result as the cluster state detection result in response to determining that the health node proportion data is greater than or equal to the health threshold data; determining a preset second cluster detection result as the cluster state detection result in response to determining that the health node proportion data is less than the health threshold data.

6. The file client bulk upgrade system of claim 1, wherein, Each of the file clients corresponds to a node agent, and each of the file clients is further configured to generate temporary file data, file descriptor data, and descriptor state information based on the file mount point, including: based on the file mount point, performing the following mounting steps: obtaining file descriptor data and temporary file data corresponding to the file mount point; sending the file descriptor data to the node agent corresponding to the file client; performing a process query on the file descriptor data to obtain a node process query result; generating descriptor storage state information based on the node process query result and the node agent corresponding to the file client; in response to determining that the descriptor storage state information does not satisfy a preset descriptor storage condition, performing the mounting step again; in response to determining that the descriptor storage state information satisfies the descriptor storage condition, determining preset mount success information as the descriptor state information; in response to determining that the number of times of performing the mounting step is greater than a preset mounting threshold, determining preset mount failure information as the descriptor state information.

7. The file client bulk upgrade system of claim 1, wherein, Each of the file clients corresponds to a mount storage container, and after each of the file clients is further configured to determine upgrade mode information based on a pre-stored executable upgrade file, the file client batch upgrade system further includes: Each of the file clients is further configured to perform the following binary upgrade steps in response to determining that the upgrade mode information satisfies a preset binary upgrade condition: determining the mount storage container corresponding to the file client as a target mount storage container; storing the executable upgrade file and a preset configuration file to the target mount storage container to update the target mount storage container; determining process mounting information based on a preset configuration signal and the updated target mount storage container; determining upgrade state information based on the process mounting information.

Images