Server, method of mounting shared storage, and computer readable storage medium

Abstract

The present disclosure relates to the technical field of computer cloud platform software, and particularly relates to a server, a shared storage mounting method and a computer readable storage medium. The method comprises the following steps: receiving mounting information for mounting a file system; wherein the mounting information at least comprises a target mounting path determined based on a specified storage path of a service instance and first configuration parameters of the file system, the target mounting path is a first directory path in the server, and the first configuration parameters at least comprise a first mounting identifier for indicating whether to use shared mounting; determining a first mounting path based on the first mounting identifier; wherein the same first configuration parameters correspond to the same first mounting path, the first mounting path is a second directory path in the server, and the first directory path is different from the second directory path; mounting the file system to the first mounting path, and / or mounting the first mounting path to the target mounting path.

Description

Technical Field

[0001] This disclosure relates to the field of computer cloud platform software technology, and in particular to a server, a method for mounting shared storage, and a computer-readable storage medium. Background Technology

[0002] In Kubernetes container cloud platforms, to meet the access requirements of shared remote storage under multi-tenant microservice architectures, existing Container Storage Interface (CSI) storage solutions rely on the binding mechanism of persistent volumes (PVs) and persistent volume claims (PVCs), or directly use CSI temporary volumes for mounting. However, the strong binding relationship between PVs and PVCs and the limitation that PVCs cannot be reused across namespaces force administrators to repeatedly create independent PVs and PVCs for the same external storage system in each namespace, resulting in logically identical storage resources being isolated into multiple non-shareable instances. While the CSI temporary volume solution used to circumvent this limitation simplifies configuration, Kubernetes treats each temporary volume as an independent mount request, triggering the CSI driver to mount it separately for each Pod. Even if the mount parameters are completely identical, it cannot reuse the underlying filesystem in userspace (FUSE) or kernel driver cache and connection state, resulting in resource redundancy, performance degradation, and network connection bloat. This design contradiction exposes the core technical problem of the current Kubernetes storage abstraction layer lacking a unified mounting and reuse mechanism when sharing the same remote storage instance across namespaces, which seriously restricts storage efficiency and operational scalability in high-density, multi-tenant scenarios. Summary of the Invention

[0003] To address the aforementioned technical problems, this disclosure provides a server, a method for mounting shared storage, and a computer-readable storage medium.

[0004] In a first aspect, this disclosure provides a server, comprising: a communicator configured to: receive mount information for mounting a file system; wherein the mount information includes at least a target mount path determined based on a specified storage path of a service instance and first configuration parameters of the file system, the target mount path being a first directory path in the server, and the first configuration parameters including at least a first mount identifier for indicating whether to use shared mount; and a controller configured to: determine a first mount path based on the first mount identifier; wherein the same first configuration parameter corresponds to the same first mount path, the first mount path being a second directory path in the server, and the first directory path being different from the second directory path; mount the file system to the first mount path, and / or mount the first mount path to the target mount path.

[0005] Secondly, this disclosure provides a method for mounting shared storage, comprising: receiving mount information for mounting a file system; wherein the mount information includes at least a target mount path determined based on a specified storage path of a service instance and first configuration parameters of the file system, the target mount path being a first directory path in a server, and the first configuration parameters including at least a first mount identifier for indicating whether to use shared mounting; determining a first mount path based on the first mount identifier; wherein the same first configuration parameter corresponds to the same first mount path, the first mount path being a second directory path in a server, and the first directory path being different from the second directory path; mounting the file system to the first mount path, and / or mounting the first mount path to the target mount path.

[0006] Thirdly, this disclosure provides a computer-readable storage medium, including: storing a computer program on the computer-readable storage medium, the computer program being executed by a controller using a shared storage mounting method as provided in any of the second aspects.

[0007] Fourthly, this disclosure provides a computer program product that, when run on a computer, causes the computer to perform a shared storage mounting method as provided in any of the second aspects.

[0008] It should be noted that the aforementioned computer instructions may be stored, in whole or in part, on the first computer-readable storage medium. The first computer-readable storage medium may be encapsulated together with the server's controller, or it may be encapsulated separately from the server's controller; this disclosure does not impose any limitations on this.

[0009] The descriptions of the second, third, and fourth aspects in this disclosure can be referenced to the detailed description of the first aspect; and the beneficial effects of the descriptions of the second, third, and fourth aspects can be referenced to the analysis of the beneficial effects of the first aspect, which will not be repeated here.

[0010] In this disclosure, the names of the aforementioned servers do not constitute a limitation on the devices or functional modules themselves. In actual implementation, these devices or functional modules may appear under other names. As long as the functions of each device or functional module are similar to those of this disclosure, they fall within the scope of this disclosure and its equivalents.

[0011] These or other aspects of this disclosure will become more readily apparent in the following description.

[0012] The technical solution provided in this disclosure has the following advantages compared with the prior art: The server disclosed herein includes: a communicator configured to: receive mount information for mounting a file system; wherein the mount information includes at least a target mount path determined based on a specified storage path of a service instance and a first configuration parameter of the file system, the target mount path being a first directory path in the server, and the first configuration parameter including at least a first mount identifier indicating whether to use shared mount; and a controller configured to: determine a first mount path based on the first mount identifier; wherein the same first configuration parameter corresponds to the same first mount path, the first mount path being a second directory path in the server, and the first directory path being different from the second directory path; mount the file system to the first mount path, and / or mount the first mount path to the target mount path, thereby achieving dual mount mapping. It can be seen that for multiple business containers running on the same server, even if they are identified as different volumes in a container cloud platform (such as Kubernetes), as long as they share the same underlying file system, they can be uniformly mounted to the same first mount path on the server. Subsequently, by mounting the first mount path into the target mount path of each business container, the sharing and reuse of storage resources is realized; this solves the technical bottleneck of the Kubernetes storage abstraction layer lacking a unified mount reuse mechanism when sharing the same remote storage instance across namespaces, and significantly improves the storage usage efficiency and operational scalability in high-density, multi-tenant scenarios. Attached Figure Description

[0013] The accompanying drawings, which are incorporated in and form a part of this specification, illustrate embodiments consistent with this disclosure and, together with the description, serve to explain the principles of this disclosure.

[0014] To more clearly illustrate the technical solutions in the embodiments of this disclosure or the prior art, the accompanying drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0015] Figure 1 One of the flowcharts illustrating the method for mounting shared storage provided in this application embodiment; Figure 2 System architecture diagram of the shared storage mounting method provided in the embodiments of this application; Figure 3 A second flowchart illustrating the method for mounting shared storage provided in this application embodiment; Figure 4 The third flowchart illustrating the shared storage mounting method provided in this application embodiment; Figure 5 The fourth flowchart illustrates the method for mounting shared storage provided in this application embodiment; Figure 6 Fifth flowchart illustrating the method for mounting shared storage provided in this application embodiment; Figure 7 A flowchart illustrating the method for mounting shared storage provided in this application embodiment is shown in Figure 6. Figure 8 This is a schematic diagram of the server structure provided in an embodiment of this application; Figure 9 This is a schematic diagram of a chip system provided in an embodiment of this application. Detailed Implementation

[0016] To better understand the above-mentioned objectives, features, and advantages of this disclosure, the solutions disclosed herein will be further described below. It should be noted that, unless otherwise specified, the embodiments and features described herein can be combined with each other.

[0017] Numerous specific details are set forth in the following description in order to provide a full understanding of this disclosure, but this disclosure may also be implemented in other ways different from those described herein; obviously, the embodiments in the specification are only some, and not all, of the embodiments of this disclosure.

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

[0019] In this embodiment, the Pod is the basic unit of Kubernetes scheduling. It is not a single container, but a logical package of containers used to encapsulate a group of containers that need to work together.

[0020] In this disclosed embodiment, Kubelet is a key component running on each node in a Kubernetes cluster. It acts as a node agent, responsible for managing containers and Pods on that node.

[0021] The server provided in this disclosure embodiment can be a server. When the server executes the shared storage mounting method provided in this disclosure embodiment, it can be the server's CSI service.

[0022] The following embodiments use the CSI service of the aforementioned server as an example to illustrate the method of the shared storage mounting method provided in this disclosure.

[0023] This application provides a method for mounting shared storage, such as... Figure 1 As shown, the method for mounting the shared storage may include S11-S13.

[0024] S11. Receive mount information for mounting the file system; wherein the mount information includes at least a target mount path determined based on a specified storage path of the service instance and a first configuration parameter of the file system, the target mount path being a first directory path in the server, and the first configuration parameter including at least a first mount identifier for indicating whether to use shared mount.

[0025] In some examples, the shared storage mounting method provided in this disclosure is applied to, for example... Figure 2 The system architecture shown includes: a platform central server 1, a client 2, and a container cloud consisting of at least one server 3. Each server 3 includes a node control tool 3-1 and a container storage interface (CSI) 3-2.

[0026] When a user needs to deploy a business service instance (Pod), the user can perform the deployment operation on client 2. At this time, the central platform server 1 will receive the creation command sent by client 2, which instructs the creation of the Pod. Then, the central platform server 1 determines the server that can execute the creation command, such as the target node. Next, the central platform server 1 sends the creation information to the target node. Then, when the node control tool of the target node (such as kubelet) receives the creation information sent by the central platform server 1, it parses the creation information to determine the first configuration parameters of the file system and the specified storage path contained in the creation information; simultaneously, the kubelet generates the target mount path based on the specified storage path. Then, when the kubelet determines that the system type of the file system is the specified type, it calls the container storage interface 3-2 to send mount information to the CSI service. Then, when the CSI service receives the mount information sent by the kubelet for mounting the file system, it determines the first mount path based on the first mount identifier. Finally, the CSI service mounts the file system to the first mount path and mounts the first mount path to the target mount path.

[0027] In some examples, the specified storage path includes the specified volume and mount points.

[0028] In some examples, the first configuration parameter also includes one or more of the following: CSI volume identifier, remote server address, storage volume name (such as the name of the CSI volume), and source path.

[0029] S12. Determine the first mount path based on the first mount identifier; wherein, the same first configuration parameter corresponds to the same first mount path, the first mount path is the second directory path in the server, and the first directory path is different from the second directory path.

[0030] In some examples, when determining the first mount path based on the first mount identifier, the first mount path can be determined based on the identifier result of the first mount and the configuration information of the actual mounts already mounted on the server. For example, if the first mount identifier indicates the use of a shared mount, and there is no actual mount on the server with the same first configuration parameters, the first theoretical mount path is obtained; the first mount path is then determined as the first theoretical mount path. Alternatively, if the first mount identifier indicates the use of a shared mount, and there is an actual mount on the server with the same first configuration parameters, the second mount path corresponding to the actual mount is used as the second theoretical mount path; the first mount path is then determined as the second theoretical mount path.

[0031] In some examples, when determining the first mount path based on the first mount identifier, the first mount identifier and the configuration information of the actual mounts already mounted on the server can be input into the path model for calculation to obtain the first mount path. The training process of the path model includes: Obtain the first training sample data and the first labeling result of the first training sample data. The first training sample data includes historical mount identifiers, and the first labeling result includes the actual mount path corresponding to each historical mount identifier.

[0032] The first training sample data is input into the first neural network model for learning, and the first prediction result of the first neural network model on the first training sample data is obtained.

[0033] Based on the first labeling result and the first prediction result, the network parameters of the first neural network model are adjusted until the first neural network model converges to obtain the path model.

[0034] In some examples, obtaining the first theoretical mount path includes: randomly generating a mount path as the first theoretical mount path.

[0035] Alternatively, a first theoretical mount path can be generated based on the server's current operating parameters (such as CPU utilization, system load average, context switching frequency, run queue length, or one or more of these), the storage's current operating parameters (such as read / write speed, queue depth, cache hit ratio, Redundant Array of Independent Disks (RAID) status and health information, and Solid State Drive (SSD) lifespan and wear status, or one or more of these). For example, the base path can be determined based on the storage type (such as SSD, Hard Disk Drive (HDD), or RAID); the first theoretical mount path can be obtained based on the base path, storage capacity, path name corresponding to the performance level, server identifier, and timestamp.

[0036] Alternatively, the current operating parameters of the server and the current operating parameters of the storage can be input into the mounting model for calculation to obtain the first theoretical mounting path. The training process of the mounting model includes: Obtain the second training sample data and the second labeling result of the second training sample data. The second training sample data includes at least one set of historical operation information, and the second labeling result includes the actual mounting path corresponding to each set of historical operation information. Each set of historical operation information includes the server's operating parameters and the storage's operating parameters at the same time.

[0037] The second training sample data is input into the second neural network model for learning, and the second prediction result of the second neural network model on the second training sample data is obtained.

[0038] Based on the second prediction result and the second labeling result, the network parameters of the second neural network model are adjusted until the second neural network model converges, thus obtaining the mounting model.

[0039] S13. Mount the file system to the first mount path, and / or mount the first mount path to the target mount path.

[0040] In some examples, the first mount identifier is used to indicate that when a shared mount is not used, the file system corresponding to the first mount identifier is mounted to the target mount path.

[0041] In some examples, the shared storage mounting method provided in this disclosure involves the CSI service recording the successful mounting of any file system corresponding to the mount information and reporting the successful mounting to the node control tool (kubelet). After receiving the successful mounting report, the node control tool (kubelet) continues to execute other tasks, thus completing the creation and startup of the business service instance.

[0042] The shared storage mounting method disclosed herein receives mount information for mounting a file system; determines a first mount path based on a first mount identifier; mounts the file system to the first mount path, and / or mounts the first mount path to a target mount path, thereby achieving dual mount mapping. It can be seen that for multiple business containers running on the same server, even if they are identified as different volumes in a container cloud platform (such as Kubernetes), as long as they share the same underlying file system, they can be uniformly mounted to the same first mount path on the server. Subsequently, by mounting this first mount path into the target mount path of each business container, the sharing and reuse of storage resources is achieved.

[0043] In some feasible examples, combining Figure 1 ,like Figure 3 As shown, S12 can be implemented by S120 and S121, and S13 can be implemented by S130.

[0044] S120. The first mount identifier is used to indicate the use of shared mount and when there is no actual mount in the server that is the same as the first configuration parameter, the first theoretical mount path is obtained.

[0045] S121. Determine the first mount path as the first theoretical mount path.

[0046] S130. Mount the file system to the first mount path, and mount the first mount path to the target mount path.

[0047] The shared storage mounting method disclosed herein receives mount information for mounting a file system; a first mount identifier is used to indicate the use of shared mounting, and when no actual mount with the same first configuration parameters exists on the server, a first theoretical mount path is obtained. The first mount path is determined as the first theoretical mount path; the file system is mounted to the first mount path, and the first mount path is mounted to the target mount path, achieving dual mount mapping. It can be seen that for multiple business containers running on the same server, even if they are identified as different volumes in a container cloud platform (such as Kubernetes), as long as they share the same underlying file system, they can be uniformly mounted to the same first mount path on the server. Subsequently, by mounting this first mount path into the target mount path of each business container, the sharing and reuse of storage resources is achieved.

[0048] In some feasible examples, combining Figure 3 ,like Figure 4 As shown, the above S120 can be specifically implemented through the following S1200 and S1201.

[0049] S1200: When the first mount identifier is used to indicate the use of shared mount, and there is no actual mount in the server that is the same as the first configuration parameter, a random mount path is randomly generated.

[0050] S1201. Use the random mount path as the first theoretical mount path.

[0051] The shared storage mounting method disclosed herein receives mount information for mounting a file system. When a first mount identifier indicates the use of shared mounting, and no actual mount with the same first configuration parameters exists on the server, a random mount path is randomly generated. This random mount path is used as the first theoretical mount path. The file system is mounted to the first mount path, and the first mount path is mounted to the target mount path, achieving dual mount mapping. It can be seen that for multiple business containers running on the same server, even if they are identified as different volumes in a container cloud platform (such as Kubernetes), as long as they share the same underlying file system, they can be uniformly mounted to the same first mount path on the server. Subsequently, by mounting this first mount path into the target mount path of each business container, the sharing and reuse of storage resources is achieved.

[0052] In some feasible examples, combining Figure 1 ,like Figure 5As shown, S12 can be implemented by S122 and S123, and S13 can be implemented by S131.

[0053] S122. When the first mount identifier is used to indicate the use of shared mount, and there is an actual mount in the server that is the same as the first configuration parameter, the second mount path corresponding to the actual mount is taken as the second theoretical mount path.

[0054] S123. Determine the first mounting path as the second theoretical mounting path.

[0055] S131. Mount the first mount path to the target mount path.

[0056] In some examples, since there is an actual mount that is the same as the first configuration parameter, that is, the file system with the same configuration parameter has already been mounted to the first mount path, there is no need to mount the file system to the first mount path again. Instead, you can directly mount the first mount path to the target mount path, thus improving mounting efficiency.

[0057] The shared storage mounting method disclosed herein receives mount information for mounting a file system. When a first mount identifier indicates the use of shared mounting, and an actual mount with the same first configuration parameters exists on the server, the second mount path corresponding to the actual mount is used as the second theoretical mount path. The first mount path is determined as the second theoretical mount path; the file system is mounted to the first mount path, and the first mount path is mounted to the target mount path, achieving dual mount mapping. It can be seen that for multiple business containers running on the same server, even if they are identified as different volumes in a container cloud platform (such as Kubernetes), as long as they share the same underlying file system, they can be uniformly mounted to the same first mount path on the server. Subsequently, by mounting this first mount path into the target mount path of each business container, the sharing and reuse of storage resources is achieved.

[0058] In some feasible examples, combining Figure 1 ,like Figure 6 As shown, the shared storage mounting method provided in this embodiment of the disclosure further includes S14 and S15.

[0059] S14. Receive unloading information for unloading the file system. The unloading information includes at least a second configuration parameter of the file system, and the second configuration parameter includes at least a second mount identifier for indicating whether to use shared mount.

[0060] S15. When the second mount identifier is used to indicate the use of shared mount, and there is no actual mount in the server that is the same as the second configuration parameter, unmount the file system on the third theoretical mount path corresponding to the second mount identifier.

[0061] In some examples, the second mount identifier is used to indicate that when a shared mount is not used, it is not necessary to check whether the corresponding third theoretical mount path is shared by other business service instances.

[0062] The shared storage mounting method disclosed herein receives unloading information for unloading a file system. Its core logic lies in controlling resource management in a shared mounting scenario. When the second mount identifier contained in the unloading information indicates that the current operation is in shared mount mode, and there are no other actual mounts on the server side that match the second configuration parameter in the unloading information, the system will execute an unloading operation, unloading the file system on the third theoretical mount path corresponding to the second mount identifier. The main purpose of this mechanism is to ensure that in a shared mounting environment, the unloading operation is only actually executed when it is confirmed that no other business or container depends on the storage resource, thereby avoiding data access anomalies or service interruptions caused by accidental unloading. In this way, the system can manage the lifecycle of shared storage resources more securely and intelligently, improving the stability and resource utilization of the storage system. By introducing a matching check between the mount identifier and configuration parameters, fine-grained control of shared mounted resources is achieved, solving the resource conflict and management problems of traditional mounting mechanisms in complex multi-tenant environments. The matching check between the mount identifier and configuration parameters ensures the safe unloading of storage resources in a shared mounting environment, avoiding service interruptions caused by accidental operations. The shared storage mounting mechanism achieves unified management and efficient utilization of storage resources through the mapping relationship between theoretical mounting paths and actual mounting paths.

[0063] In some feasible examples, combining Figure 6 ,like Figure 7 As shown in the embodiments of this disclosure, the method for mounting shared storage further includes S16.

[0064] S16. When the second mount identifier is used to indicate the use of shared mount, and there is an actual mount in the server that is the same as the second configuration parameter, the file system on the third theoretical mount path corresponding to the second mount identifier is not unmounted.

[0065] The shared storage mounting method disclosed herein receives unmounting information for unmounting a file system. Its core logic lies in controlling resource management in shared mounting scenarios. When a second mount identifier indicates the use of shared mounting, and an actual mount with the same second configuration parameters exists on the server, the file system on the third theoretical mount path corresponding to the second mount identifier is not unmounted. This effectively avoids data access interruptions or service anomalies caused by accidental unmounting. By preserving the shared mount file system, the continuity and stability of multiple business containers or services sharing the same storage resources are ensured, improving system reliability and resource utilization. This mechanism is particularly suitable for high-density, multi-tenant environments, enhancing the fine-grained control capabilities of storage resource management.

[0066] The foregoing mainly describes the solutions provided by the embodiments of this application from a methodological perspective. To achieve the above functions, it includes corresponding hardware structures and / or software modules for executing each function. Those skilled in the art should readily recognize that, based on the units and algorithm steps of the examples described in conjunction with the embodiments disclosed herein, this application can be implemented in hardware or a combination of hardware and computer software. Whether a function is executed in hardware or by computer software driving hardware depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0067] This application embodiment can divide the server into functional modules according to the above method example. For example, each function can be divided into its own functional modules, or two or more functions can be integrated into one processing unit. The integrated modules can be implemented in hardware or as software functional modules. It should be noted that the module division in this application embodiment is illustrative and only represents one logical functional division. In actual implementation, there may be other division methods.

[0068] like Figure 8 As shown in the diagram, an embodiment of this application provides a schematic diagram of a server structure, including a communicator 101 and a controller 102.

[0069] The communicator 101 is configured to receive mount information for mounting a file system; wherein the mount information includes at least a target mount path determined based on a specified storage path of the service instance and a first configuration parameter of the file system, the target mount path being a first directory path in the server, and the first configuration parameter including at least a first mount identifier for indicating whether to use shared mount. Controller 102 is configured as follows: Based on the first mount identifier, the first mount path is determined; wherein, the same first configuration parameter corresponds to the same first mount path, the first mount path is the second directory path in the server, and the first directory path is different from the second directory path; Mount the file system to the first mount path, and / or mount the first mount path to the target mount path.

[0070] In some implementable examples, the controller is further configured to, when performing the determination of the server's first mount path based on the first mount identifier: When the first mount identifier is used to indicate the use of shared mount, and there is no actual mount in the server that is the same as the first configuration parameter, obtain the first theoretical mount path; The first mount path is determined to be the first theoretical mount path; When the controller mounts the file system to the first mount path, and / or mounts the first mount path to the target mount path, it is further configured to: Mount the file system to the first mount path, and then mount the first mount path to the target mount path.

[0071] In some implementable examples, when the controller 102 executes the first mount identifier indicating the use of a shared mount, and no mount with the same first configuration parameter exists on the server, it obtains the theoretical mount path and is further configured as follows: When the first mount identifier is used to indicate the use of shared mount, and there is no actual mount in the server that is the same as the first configuration parameter, a random mount path is randomly generated. The random mount path is taken as the first theoretical mount path.

[0072] In some implementable examples, controller 102 is further configured to, when performing the determination of the first mount path of the server based on the first mount identifier: When the first mount identifier is used to indicate the use of shared mount, and there is an actual mount in the server that is the same as the first configuration parameter, the second mount path corresponding to the actual mount is taken as the second theoretical mount path. The first mount path is determined as the second theoretical mount path; When the controller mounts the file system to the first mount path, and / or mounts the first mount path to the target mount path, it is further configured to: Mount the first mount path to the target mount path.

[0073] In some implementable examples, communicator 101 is also configured to receive unloading information for unloading a file system; wherein the unloading information includes at least a second configuration parameter of the file system, the second configuration parameter including at least a second mount identifier for indicating whether a shared mount is used. Controller 102 is also configured as follows: When the second mount identifier is used to indicate the use of shared mount, and there is no actual mount on the server that is the same as the second configuration parameter, the file system on the third theoretical mount path corresponding to the second mount identifier is unmounted.

[0074] In some implementable examples, controller 102 is executed and also configured as follows: When the second mount identifier is used to indicate the use of shared mount, and an actual mount with the same second configuration parameters exists on the server, the file system on the third theoretical mount path corresponding to the second mount identifier is not unmounted.

[0075] All relevant content of each step involved in the above method embodiments can be referenced from the functional description of the corresponding functional module, and their functions will not be repeated here.

[0076] Of course, the server provided in this application embodiment includes, but is not limited to, the modules described above. For example, the server may also include a memory 103. The memory 103 can be used to store the program code of the server, and can also be used to store data generated by the server during operation, such as data in write requests.

[0077] like Figure 9 As shown, this application embodiment also provides a chip system that can be applied to the server in the foregoing embodiments. The chip system includes at least one processor 1501 and at least one interface circuit 1502. The processor 1501 can be the processor in the aforementioned server. The processor 1501 and the interface circuit 1502 can be interconnected via a line. The processor 1501 can receive and execute computer instructions from the server's memory through the interface circuit 1502. When the computer instructions are executed by the processor 1501, the server can perform the various steps executed by the server in the foregoing embodiments. Of course, the chip system may also include other discrete devices, which are not specifically limited in this application embodiment.

[0078] This application also provides a computer-readable storage medium for storing computer instructions executed by the aforementioned server.

[0079] The above description is merely a specific embodiment of this disclosure, enabling those skilled in the art to understand or implement it. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this disclosure. Therefore, this disclosure is not to be limited to the embodiments described herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A server, characterized in that, include: The communicator is configured to receive mount information for mounting a file system; wherein the mount information includes at least a target mount path determined based on a specified storage path of a service instance and a first configuration parameter of the file system, the target mount path being a first directory path in the server, and the first configuration parameter including at least a first mount identifier for indicating whether to use shared mount. The controller is configured as follows: Based on the first mount identifier, a first mount path is determined; wherein, the same first configuration parameter corresponds to the same first mount path, and the first mount path is the second directory path in the server, and the first directory path is different from the second directory path; Mount the file system to the first mount path, and / or mount the first mount path to the target mount path.

2. The server according to claim 1, characterized in that, When the controller determines the first mount path of the server based on the first mount identifier, it is further configured to: When the first mount identifier is used to indicate the use of shared mount, and there is no actual mount in the server that is the same as the first configuration parameter, obtain the first theoretical mount path; The first mount path is determined to be the first theoretical mount path; When the controller mounts the file system to the first mount path and / or mounts the first mount path to the target mount path, it is further configured to: The file system is mounted to the first mount path, and the first mount path is mounted to the target mount path.

3. The server according to claim 2, characterized in that, When the controller executes the first mount identifier indicating the use of a shared mount, and no mount with the same first configuration parameter exists on the server, it obtains the theoretical mount path and is further configured as follows: When the first mount identifier is used to indicate the use of a shared mount, and there is no actual mount in the server that is the same as the first configuration parameter, a random mount path is randomly generated. The random mounting path is taken as the first theoretical mounting path.

4. The server according to claim 1, characterized in that, When the controller determines the first mount path of the server based on the first mount identifier, it is further configured to: When the first mount identifier is used to indicate the use of shared mount, and there is an actual mount in the server that is the same as the first configuration parameter, the second mount path corresponding to the actual mount is taken as the second theoretical mount path; The first mount path is determined to be the second theoretical mount path; When the controller mounts the file system to the first mount path and / or mounts the first mount path to the target mount path, it is further configured to: Mount the first mount path to the target mount path.

5. The server according to claim 1, characterized in that, The communicator is further configured to: receive unloading information for unloading a file system; wherein the unloading information includes at least a second configuration parameter of the file system, and the second configuration parameter includes at least a second mount identifier for indicating whether to use shared mount; The controller is also configured to: When the second mount identifier is used to indicate the use of shared mount, and there is no actual mount in the server that is the same as the second configuration parameter, the file system on the third theoretical mount path corresponding to the second mount identifier is unmounted.

6. The server according to claim 5, characterized in that, The controller, in its execution, is also configured to: When the second mount identifier is used to indicate the use of shared mount, and there is an actual mount in the server that is the same as the second configuration parameter, the file system on the third theoretical mount path corresponding to the second mount identifier is not unmounted.

7. A method for mounting shared storage, characterized in that, include: Receive mount information for mounting a file system; wherein the mount information includes at least a target mount path determined based on a specified storage path of the service instance and a first configuration parameter of the file system, the target mount path being a first directory path in the server, and the first configuration parameter including at least a first mount identifier for indicating whether to use shared mount; Based on the first mount identifier, a first mount path is determined; wherein, the same first configuration parameter corresponds to the same first mount path, and the first mount path is the second directory path in the server, and the first directory path is different from the second directory path; Mount the file system to the first mount path, and / or mount the first mount path to the target mount path.

8. The method for mounting shared storage according to claim 7, characterized in that, The step of determining the first mount path of the server based on the first mount identifier includes: When the first mount identifier is used to indicate the use of shared mount, and there is no actual mount in the server that is the same as the first configuration parameter, obtain the first theoretical mount path; The first mount path is determined to be the first theoretical mount path; Mounting the file system to the first mount path, and / or mounting the first mount path to the target mount path, includes: The file system is mounted to the first mount path, and the first mount path is mounted to the target mount path.

9. The method for mounting shared storage according to claim 8, characterized in that, When the first mount identifier indicates the use of a shared mount, and there is no actual mount on the server that matches the first configuration parameters, obtaining the first theoretical mount path includes: When the first mount identifier is used to indicate the use of a shared mount, and there is no actual mount in the server that is the same as the first configuration parameter, a random mount path is randomly generated. The random mounting path is taken as the first theoretical mounting path.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the method of shared storage mounting as described in any one of claims 6-9.

Images