Method and apparatus for mounting storage volume

Abstract

Provided in the embodiments of the present application are a method and apparatus for mounting a storage volume. The method comprises: acquiring a broadcast message sent by a switch, wherein the switch is configured to determine, by means of the interruption condition of a data link message, whether a container storage interface driver and a storage system are online, and the data link message is a message that is sent by the container storage interface driver and the storage system to the switch according to a preset time interval; and when the broadcast message indicates that the container storage interface driver is in a first online state and the storage system is in a second online state, establishing a communication link between a container orchestration system and the storage system, and mounting a storage volume by means of the communication link. By means of the present application, the problem of low mounting accuracy of a storage volume is solved, thereby achieving the effect of improving the mounting accuracy of the storage volume.

Description

Mounting method and device of storage volume

[0001] Cross Reference to Related Applications

[0002] The present application claims priority from a Chinese patent application No. 202411372918.9 filed on September 29, 2024, and entitled "Mounting method and device of storage volume", the content of which is incorporated herein in its entirety. TECHNICAL FIELD

[0003] Embodiments of the present application relate to the field of computers, and in particular, to a mounting method and device of storage volume. BACKGROUND

[0004] In the mounting scenario of storage volume, the mounting of storage volume is usually completed by manual method. The manual method is not only cumbersome and repetitive, but also prone to errors, which leads to the problem of low mounting accuracy of storage volume. Therefore, there is a problem of low mounting accuracy of storage volume.

[0005] In view of the above problems, no effective solution has been proposed so far. SUMMARY

[0006] Embodiments of the present application provide a mounting method and device of storage volume to at least solve the problem of low mounting accuracy of storage volume in the related art.

[0007] According to an embodiment of the present application, a mounting method of storage volume is provided, comprising: obtaining a broadcast message sent by a switch, wherein the switch is configured to determine whether a container storage interface driver and a storage system are online by using an interruption of a data link message, the data link message being a message sent by the container storage interface driver and the storage system to the switch according to a preset time interval; in a case where the broadcast message indicates that the container storage interface driver is in a first online state and the storage system is in a second online state, establishing a communication link between a container orchestration system and the storage system, and realizing mounting of storage volume through the communication link.

[0008] According to another embodiment of the present application, a mounting device of a storage volume is provided, comprising: a first acquisition unit configured to acquire a broadcast message sent by a switch, wherein the switch is configured to determine whether a container storage interface driver and a storage system are online by using an intermittent case of a data link message, the data link message being a message sent by the container storage interface driver and the storage system to the switch according to a preset time interval; and a first establishment unit configured to, in a case where the broadcast message indicates that the container storage interface driver is in a first online state and the storage system is in a second online state, establish a communication link between a container orchestration system and the storage system, and realize mounting of the storage volume through the communication link.

[0009] In an example embodiment, the device further comprises a disconnection unit configured to, after the acquisition of the broadcast message sent by the switch, disconnect the communication link in a case where the broadcast message indicates that the container storage interface driver is changed from an available state to an unavailable state or the storage system is changed from the available state to the unavailable state.

[0010] In an example embodiment, the device further comprises a first determination unit configured to, after the acquisition of the broadcast message sent by the switch, determine that the container storage interface driver is in the first online state in a case where the broadcast message indicates that the container storage interface driver is changed from the unavailable state to the available state; and a second determination unit configured to, after the acquisition of the broadcast message sent by the switch, determine that the storage system is in the second online state in a case where the broadcast message indicates that the storage system is changed from the unavailable state to the available state.

[0011] In an example embodiment, the device further comprises a setting unit configured to, before the acquisition of the broadcast message sent by the switch, set the container storage interface driver to query whether communication is maintained between the container orchestration system and the container storage interface driver according to a first time interval; a third determination unit configured to, before the acquisition of the broadcast message sent by the switch, determine that the container storage interface driver is in the available state in a case where communication is maintained between the container orchestration system and the container storage interface driver; and a fourth determination unit configured to, before the acquisition of the broadcast message sent by the switch, determine that the container storage interface driver is in the unavailable state in a case where communication is disconnected between the container orchestration system and the container storage interface driver.

[0012] In an example embodiment, the apparatus further comprises a second establishing unit configured to re-establish the communication link when the broadcast message sent by the switch indicates that the storage system is updated and the communication link is established after the broadcast message is acquired.

[0013] In an example embodiment, the second establishing unit comprises a first disconnecting module configured to disconnect the communication link, a first acquiring module configured to acquire a new broadcast message sent by the switch, and an establishing module configured to establish the communication link when the new broadcast message indicates that the storage system is not updated and is in the second online state, and the container storage interface driver is in the first online state.

[0014] In an example embodiment, the apparatus further comprises a second acquiring unit configured to acquire host information of the container orchestration system according to a second time interval, and a first sending unit configured to send the host information to the storage system through the communication link to make the storage system create a mount running object which is an entity server or a virtual machine providing a mount point of the storage volume during the process of implementing the mounting of the storage volume through the communication link.

[0015] In an example embodiment, the second acquiring unit comprises at least one of a second acquiring module configured to acquire at least one host name corresponding to the container orchestration system, wherein the host name is used to identify each node in the container orchestration system, a third acquiring module configured to acquire at least one serial number corresponding to the container orchestration system, wherein the serial number is used to track and identify physical hardware in the container orchestration system, and a fourth acquiring module configured to acquire at least one operating system type corresponding to the container orchestration system, wherein the operating system type is a system type supported by the container orchestration system.

[0016] In an example embodiment, the device further comprises: a first editing module configured to edit a configuration file of the persistent storage volume after the host information is transmitted to the storage system via the communication link to enable the storage system to create the mounting running object; an application module configured to apply the configuration file to the container orchestration system after the host information is transmitted to the storage system via the communication link to enable the storage system to create the mounting running object, so as to trigger each node in the container orchestration system to request the storage system to create a corresponding persistent storage volume according to a definition in the configuration file; and a mounting module configured to instruct the storage system to mount the persistent storage volume to the mounting running object in a case where the persistent storage volume is bound to each node in the container orchestration system, so as to provide persistent storage service for the container orchestration system through the persistent storage volume.

[0017] In an example embodiment, the first editing module comprises at least one of: a first adding submodule configured to add an API version adapted to the persistent storage volume in the configuration file; a second adding submodule configured to add a specified type of resource corresponding to the persistent storage volume in the configuration file; a third adding submodule configured to add an identity corresponding to the persistent storage volume in the configuration file; a fourth adding submodule configured to add an access mode corresponding to the persistent storage volume in the configuration file; a fifth adding submodule configured to add a requested storage size corresponding to the persistent storage volume in the configuration file; and a sixth adding submodule configured to add a requested storage type corresponding to the persistent storage volume in the configuration file.

[0018] In an example embodiment, the device further comprises: a second editing module configured to edit a storage class configuration file according to characteristics of the storage system before the configuration file of the persistent storage volume is edited; and a registration module configured to apply the storage class configuration file to the container orchestration system before the configuration file of the persistent storage volume is edited, so as to trigger the container orchestration system to register a storage class resource to each node in the container orchestration system according to a definition in the storage class configuration file, wherein the storage class resource is used to determine how to allocate storage resources brought by the persistent storage service to the persistent storage volume.

[0019] In an example embodiment, the device further comprises: a checking unit configured to perform host checking on the container orchestration system at a third time interval to obtain a checking result.

[0020] In an example embodiment, the checking unit comprises: a traversing module configured to traverse all network card ports of the container orchestration system to obtain port information after establishing a communication link between the container orchestration system and the storage system and implementing mounting of the storage volume through the communication link.

[0021] In an example embodiment, the checking unit comprises: a sending module configured to send the corresponding port information to the switch according to a fourth time interval for each of the all network card ports before establishing a communication link between the container orchestration system and the storage system and implementing mounting of the storage volume through the communication link, wherein the data link message comprises the port information.

[0022] In an example embodiment, the apparatus further comprises: a fifth obtaining module configured to obtain a state notification sent by the switch after the sending of the corresponding port information to the switch according to the fourth time interval for each of the all network card ports, wherein the state notification is used to notify an online state of the storage system; and a returning module configured to return a notification response message corresponding to the state notification to the switch after the sending of the corresponding port information to the switch according to the fourth time interval for each of the all network card ports, wherein the notification response message is used to indicate that the container storage interface driver has received the state notification.

[0023] In an example embodiment, the apparatus further comprises: an editing unit configured to edit a container group configuration file; and an applying unit configured to apply the container group configuration file to the container orchestration system to trigger the container orchestration system to apply container group resources to the container orchestration system according to definitions in the container group configuration file, wherein the container group resources are used to manage running of one or more containers in the container orchestration system on the same node.

[0024] In an example embodiment, the apparatus further comprises a collection unit configured to collect, after the communication link between the container orchestration system and the storage system is established and the mounting of the storage volume is implemented through the communication link, the latest host information of the container orchestration system at a fourth time interval; and a second sending unit configured to send, after the communication link between the container orchestration system and the storage system is established and the mounting of the storage volume is implemented through the communication link, the latest host information to the storage system through the communication link.

[0025] According to yet another embodiment of the present application, a computer nonvolatile readable storage medium is further provided, and the computer nonvolatile readable storage medium stores a computer program. The computer program is configured to execute the steps in any of the method embodiments when running.

[0026] According to yet another embodiment of the present application, an electronic device is further provided, which comprises a memory and a processor. The memory stores a computer program, and the processor is configured to execute the computer program to execute the steps in any of the method embodiments.

[0027] In the mounting scenario of the storage volume, the traditional manual mounting method is not only cumbersome, but also prone to errors, which directly affects the accuracy of the mounting of the storage volume. In order to solve this problem, the present application significantly improves the accuracy of mounting through automated and intelligent means.

[0028] Firstly, the present application uses the broadcast message sent by the switch to judge the online state of the container storage interface driver and the storage system. This is achieved by monitoring the discontinuity of data link messages sent by the container storage interface driver and the storage system to the switch at a preset time interval. The advantage of this method is that it can reflect the online state of the storage interface driver and the storage system in real time and accurately, avoiding the tediousness and inaccuracy of manual inspection.

[0029] Secondly, when the broadcast message indicates that the container storage interface driver and the storage system are both in an online state, the present application automatically establishes a communication link between the container orchestration system and the storage system. The automation of this step not only simplifies the operation process, but also reduces the possibility of human intervention, thereby reducing the error rate.

[0030] Finally, through the automatically established communication link, the present application realizes the automatic mounting of the storage volume. The automation and intelligence of this process greatly improve the accuracy of mounting, as it eliminates errors caused by human factors. At the same time, since the mounting process is automatically completed by the system, the efficiency of mounting is also greatly improved.

[0031] In summary, by the real-time monitoring of the online state, the automatic establishment of the communication link and the automatic mounting, the problem of low mounting accuracy of the storage volume can be solved, and the technical effect of improving the mounting accuracy of the storage volume is achieved. BRIEF DESCRIPTION OF DRAWINGS

[0032] FIG. 1 is a schematic diagram of an application environment of a mounting method of a storage volume according to an embodiment of the present application;

[0033] FIG. 2 is a flowchart of a mounting method of a storage volume according to an embodiment of the present application;

[0034] FIG. 3 is a schematic diagram of a mounting method of a storage volume according to an embodiment of the present application;

[0035] FIG. 4 is a schematic diagram of a mounting method of a storage volume according to an embodiment of the present application;

[0036] FIG. 5 is a structural block diagram of a mounting device of a storage volume according to an embodiment of the present application. DETAILED DESCRIPTION

[0037] Hereinafter, the embodiments of the present application will be described in detail with reference to the accompanying drawings and in conjunction with the embodiments.

[0038] It should be noted that the terms "first", "second" and the like in the specification and claims of the present application and the above-described drawings are used to distinguish similar objects, and do not necessarily have to describe a specific order or sequence.

[0039] The method embodiments provided in the embodiments of the present application can be executed in a server device or a similar computing device. Taking an example of running on a server device, FIG. 1 is a hardware structural block diagram of a server device of a mounting method of a storage volume according to an embodiment of the present application. As shown in FIG. 1, the server device can include one or more (only one is shown in FIG. 1) processors 102 (the processor 102 can include but is not limited to a processing device such as a microprocessor MCU or a programmable logic device FPGA) and a memory 104 configured to store data, wherein the above-mentioned server device can further include a transmission device 106 configured to have a communication function and an input and output device 108. Those skilled in the art can understand that the structure shown in FIG. 1 is only schematic, which does not limit the structure of the above-mentioned server device. For example, the server device can further include more or less components than those shown in FIG. 1, or have a different configuration from that shown in FIG. 1.

[0040] The memory 104 can be configured to store computer programs, such as software programs of application software and modules, such as a computer program corresponding to the mounting method of the storage volume in the embodiments of the present application. The processor 102 can execute various functional applications and data processing, i.e., implement the above method, by running the computer programs stored in the memory 104. The memory 104 can include a high-speed random access memory, and can further include a non-volatile memory, such as one or more magnetic storage devices, flash memories, or other non-volatile solid-state memories. In some examples, the memory 104 can include memories remotely arranged relative to the processor 102, which can be connected to a server device through a network. Examples of the above network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and a combination thereof.

[0041] The transmission device 106 is configured to receive or send data via a network. Examples of the above network can include a wireless network provided by a communication provider of the server device. In one example, the transmission device 106 includes a network adapter (NIC), which can be connected to other network devices through a base station so as to be able to communicate with the Internet. In one example, the transmission device 106 can be a radio frequency (RF) module, which is configured to communicate with the Internet in a wireless manner.

[0042] In the present embodiment, a mounting method of a storage volume is provided. FIG. 2 is a flowchart of the mounting method of the storage volume according to the embodiments of the present application. As shown in FIG. 2, the flow includes the following steps:

[0043] In step S202, a broadcast message sent by a switch is acquired, wherein the switch is configured to determine whether the container storage interface driver and the storage system are online by using an interruption of a data link message. The data link message is a message sent by the container storage interface driver and the storage system according to a preset time interval.

[0044] Optionally, the present embodiment describes a system mechanism, in which the switch is responsible for listening to and acquiring the data link message sent by the container storage interface driver and the storage system. The data link message is sent according to a preset time interval. The switch determines whether the container storage interface driver and the storage system are online by observing the interruption of the data link message (i.e., whether the message is received on time).

[0045] In one example embodiment, the data link message refers to a data packet periodically sent by the container storage interface driver and the storage system to indicate the online state thereof. The interruption refers to whether the data link message arrives on time according to the preset time interval. If there is a delay or a loss, it is considered as an interruption.

[0046] Suppose the container storage interface driver and the storage system send a data link message to the switch every 5 seconds. If the switch does not receive the message within the expected time, for example, more than 6 or 7 seconds, the switch can determine that the component sending the message (the container storage interface driver or the storage system) can be offline.

[0047] Step S204, in the case that the broadcast message indicates that the container storage interface driver is in the first online state and the storage system is in the second online state, a communication link between the container orchestration system and the storage system is established, and mounting of the storage volume is implemented through the communication link.

[0048] Optionally, the embodiment describes an automated process, that is, when the broadcast message from the switch indicates that the container storage interface driver and the storage system are both in the online state, the system automatically establishes a communication link between the container orchestration system and the storage system. Once the communication link is established, the system will automatically implement the mounting of the storage volume through this link without manual intervention.

[0049] In an exemplary embodiment, the first online state refers to the online state of the container storage interface driver, and the second online state refers to the online state of the storage system. When both are in the online state, it means that they can normally communicate and transmit data. The communication link refers to the connection path for data transmission and communication between the container orchestration system and the storage system. The storage volume mounting refers to connecting the storage space (storage volume) in the storage system to the container orchestration system so that it can be accessed and used by the containers in the container orchestration system.

[0050] Suppose there is a container orchestration system managing multiple container applications that need to access data stored in an external storage system. When the information broadcast by the switch shows that the storage interface driver and the storage system are both online, the container orchestration system will automatically establish a communication link with the storage system. Once the link is successfully established, the container orchestration system can automatically mount the required storage volume, enabling the container applications to seamlessly access the data.

[0051] Through the above steps, first of all, the present application uses the broadcast message sent by the switch to determine the online state of the container storage interface driver and the storage system. This is achieved by monitoring the discontinuity of data link messages sent by the container storage interface driver and the storage system to the switch at a predetermined time interval. The advantage of this method is that it can reflect the online state of the storage interface driver and the storage system in real time and accurately, avoiding the tediousness and inaccuracy of manual inspection.

[0052] Secondly, when the broadcast message indicates that both the container storage interface driver and the storage system are in an online state, the application automatically establishes a communication link between the container orchestration system and the storage system. The automation of this step not only simplifies the operation process, but also reduces the possibility of human intervention, thereby reducing the error rate.

[0053] Finally, through the automatically established communication link, the application realizes the automatic mounting of the storage volume. The automation and intelligence of this process greatly improve the accuracy of mounting, as it eliminates errors caused by human factors. At the same time, since the mounting process is automatically completed by the system, the efficiency of mounting is also greatly improved.

[0054] In summary, through real-time monitoring of online status, automatic establishment of communication link, and automatic mounting, the application can solve the problem of low mounting accuracy of storage volumes, thereby achieving the technical effect of improving the mounting accuracy of storage volumes.

[0055] Among them, the execution subject of the above steps can be a server, a terminal, etc., but is not limited thereto.

[0056] The execution order of steps S202 and S204 can be interchanged, i.e., step S204 can be executed first, and then step S202 can be executed.

[0057] As an optional solution, after obtaining the broadcast message sent by the switch, the method further comprises:

[0058] In the case where the broadcast message indicates that the container storage interface driver changes from an available state to an unavailable state, or the storage system changes from an available state to an unavailable state, the communication link is disconnected.

[0059] In optional embodiments, the available state refers to a state in which the container storage interface driver or the storage system can work normally and respond to requests, while the unavailable state indicates that these components cannot work normally or respond to requests due to some reasons (such as failure, maintenance, etc.).

[0060] Disconnecting the communication link refers to terminating or interrupting the communication connection that has been established between the container orchestration system and the storage system, to ensure that no erroneous data transmission or operation occurs when the components are unavailable.

[0061] It should be noted that the present embodiment describes a system response mechanism. After obtaining the broadcast message sent by the switch, the system will judge the state of the container storage interface driver and the storage system according to these messages. If the broadcast message indicates that any of the components changes from an available state to an unavailable state, the system will automatically disconnect the previously established communication link between the container orchestration system and the storage system.

[0062] This mechanism of automatically disconnecting communication links is an important part of the system's robustness and fault tolerance design. By responding to changes in component status in a timely manner, the system can quickly take action when a fault occurs, thereby minimizing the impact of the fault on the overall system operation. In addition, this mechanism can also be combined with other fault recovery and backup strategies to achieve higher levels of system reliability and stability.

[0063] In some embodiments, assume that in a cloud computing environment, a container orchestration system is interacting with a storage system for data exchange. Suddenly, a broadcast message sent by the switch shows that the storage system has changed from an available state to an unavailable state due to a hardware failure. According to this information, the container orchestration system will automatically disconnect the communication link with the storage system to avoid data loss or system crash caused by continuing to attempt communication with the failed storage system.

[0064] This mechanism of automatically disconnecting communication links provided by the present application can significantly improve the robustness and fault tolerance of the system. When a key component fails or becomes unavailable, the system can quickly respond by disconnecting the communication link with the failed component, thereby avoiding the risk of potential data corruption or system crash. At the same time, this also provides administrators with more time to diagnose and repair problems without worrying about further data loss or system instability during the failure period.

[0065] As an optional solution, after obtaining the broadcast message sent by the switch, the method further comprises:

[0066] S1-1, in the case where the broadcast message indicates that the container storage interface driver has changed from an unavailable state to an available state, determining that the container storage interface driver is in a first online state;

[0067] S1-2, in the case where the broadcast message indicates that the storage system has changed from an unavailable state to an available state, determining that the storage system is in a second online state.

[0068] In optional embodiments, the unavailable state refers to a state in which a component (here, the container storage interface driver or the storage system) cannot work normally or respond to requests due to some reason; while the available state indicates that the component has recovered and can work normally and respond to requests. The first online state specifically refers to the state in which the container storage interface driver is determined to be online; the second online state specifically refers to the state in which the storage system is determined to be online.

[0069] It should be noted that the present embodiment describes how the system determines the online state of the container storage interface driver and the storage system after receiving the broadcast message sent by the switch. When the broadcast message indicates that the container storage interface driver or the storage system has recovered from an unavailable state to an available state, the system will accordingly determine that they are in an online state.

[0070] Real-time monitoring and determination of such state is crucial for ensuring the continuity and high availability of the system. By timely capturing the changes in the state of components, the system can respond quickly, for example, re-establishing communication links, resuming data transmission, etc., thereby minimizing the service interruption time caused by component failure.

[0071] In some embodiments, it is assumed that previously due to network failure, both the container storage interface driver and the storage system are in an unavailable state. Now that the network failure has been repaired, the broadcast messages sent by the switch begin to reflect the state changes of the two components. When the system receives a broadcast message indicating that the container storage interface driver has transitioned from an unavailable state to an available state, it determines that the container storage interface driver is in a first online state; similarly, when a broadcast message indicating the state transition of the storage system is received, it determines that the storage system is in a second online state.

[0072] Through the embodiments of the present application, the response speed of the system to the state changes of the components is improved, ensuring that the system can recover to a normal working state in the shortest time. Secondly, by monitoring and determining the online state of the components in real time, the system can more accurately grasp the running status of the entire system, providing valuable operation and maintenance information for administrators. Finally, this mechanism also helps to improve the overall stability and reliability of the system, as the system can quickly adjust when the state of the components changes, thereby avoiding potential problems and failures.

[0073] As an optional solution, before obtaining the broadcast message sent by the switch, the method further comprises:

[0074] S2-1, set the container storage interface driver to query whether communication is maintained between the container orchestration system and the container storage interface driver at a first time interval;

[0075] S2-2, in the case that communication is maintained between the container orchestration system and the container storage interface driver, determine that the container storage interface driver is in an available state;

[0076] S2-3, in the case that communication is disconnected between the container orchestration system and the container storage interface driver, determine that the container storage interface driver is in an unavailable state.

[0077] In optional embodiments, the first time interval refers to a time period set by the system, and the container storage interface driver will query the communication status with the container orchestration system according to this period.

[0078] Keep communication and disconnect communication: Keep communication means that the connection between the container storage interface driver and the container orchestration system is active and can normally exchange data; while disconnect communication means that the connection between the two has been interrupted and cannot exchange data.

[0079] Available state and unavailable state: Available state means that the container storage interface driver is determined to be able to work normally and keep communication with the container orchestration system; while unavailable state means that the container storage interface driver cannot keep communication with the container orchestration system due to some reasons.

[0080] It should be noted that the embodiment describes how the system sets and judges the availability state of the container storage interface driver before obtaining the broadcast message sent by the switch. The system makes the container storage interface driver query the communication state between the container storage interface driver and the container orchestration system at a set time interval (first time interval), so as to judge whether the container storage interface driver is in the available state or the unavailable state according to whether the communication is kept.

[0081] This periodic self-checking mechanism is part of the system robustness design. By making the component actively check its working state and communication state with other components, the system can discover and handle potential problems at an early stage, thereby avoiding the problem from accumulating to a serious level to cause system crash or data loss. In addition, this mechanism can also be combined with other monitoring and alarm systems to provide a more comprehensive system running state view.

[0082] In some embodiments, it is assumed that the system sets that the container storage interface driver will query the communication state between the container storage interface driver and the container orchestration system every 5 seconds. If it is found that the connection between the two is normal at a certain query time, the system will determine that the container storage interface driver is in the available state; otherwise, if it is found that the connection has been disconnected, the system will determine that it is in the unavailable state.

[0083] The periodic self-checking and state judging mechanism of the present application can significantly improve the reliability and stability of the system. First, it can help the system to discover and handle the communication problem between the container storage interface driver and the container orchestration system in time, thereby reducing the risk of service interruption or data loss caused by communication failure. Second, by continuously monitoring the state of the component, the system can more accurately grasp the running condition of the whole system, and provide valuable operation and maintenance information and troubleshooting clues for the administrator. Finally, this mechanism also helps to improve the self-repairing ability of the system, because once the problem is detected, the system can respond quickly and try to recover to the normal working state.

[0084] As an optional solution, after obtaining the broadcast message sent by the switch, the method further comprises:

[0085] In the case where the broadcast message indicates that the storage system has updated and the communication link has been established, the communication link is re-established.

[0086] In optional embodiments, the storage system has updated refers to the storage system has undergone some form of change, which can be an upgrade of software version, modification of configuration file, replacement of hardware device, etc. These changes can affect the communication method and compatibility of the storage system with external components.

[0087] The communication link has been established refers to before the storage system has updated, the container orchestration system and the storage system have successfully established a connection for data transmission and communication.

[0088] The communication link is re-established refers to in the case where the storage system has updated and the original communication link exists, the system will close or disconnect the current communication link and create a new communication link according to the latest configuration or requirements.

[0089] It should be noted that the embodiments described are in specific conditions, the system needs to re-establish the existing communication link. When the system obtains the broadcast message sent by the switch, and these messages indicate that the storage system has updated, and the current communication link has been established, the system will perform the operation of re-establishing the communication link.

[0090] This mechanism of re-establishing the communication link after the storage system updates is a manifestation of the flexibility and adaptability of the system. It allows the system to smoothly transition to new configurations or protocols without interrupting service, thereby maintaining compatibility with changing storage environments. In addition, this mechanism can also be combined with automated error detection and recovery strategies to reduce the impact of potential failures caused by updates on the system.

[0091] In some embodiments, assume that in a cloud data center, the container orchestration system is interacting with the storage system through an established communication link. Suddenly, the storage system has upgraded the software, introducing some new features and communication protocols. The broadcast message sent by the switch captures this change and informs the container orchestration system. In order to ensure smooth communication and data integrity, the container orchestration system will disconnect the existing communication link and re-establish a communication link that complies with the new protocol requirements according to the new configuration of the storage system after the upgrade.

[0092] The effect of re-establishing the communication link in the embodiments of the present application mainly lies in the following aspects: first, it ensures that the system can continue to maintain stable and efficient communication after the storage system is updated, avoiding communication interruption or data loss problems caused by incompatibility. Second, by timely adapting to changes in the storage system, the system can fully utilize the new features and performance improvements brought by the storage system upgrade. Finally, this mechanism improves the overall reliability and maintainability of the system, reducing the operation and maintenance costs and risks caused by storage system updates.

[0093] As an optional solution, re-establishing the communication link includes:

[0094] S3-1, disconnecting the communication link;

[0095] S3-2, obtaining a new broadcast message sent by the switch;

[0096] S3-3, establishing the communication link when the new broadcast message indicates that the storage system has not been updated and is in the second online state, and the container storage interface driver is in the first online state.

[0097] In an optional embodiment, disconnecting the communication link means that the system actively terminates the existing communication connection between the container orchestration system and the storage system.

[0098] New broadcast message: after disconnecting the communication link, the message sent by the switch includes the latest state information of the storage system and the container storage interface driver.

[0099] Second online state: specifically refers to the state in which the storage system is confirmed to be online and available by the broadcast message.

[0100] First online state: specifically refers to the state in which the container storage interface driver is confirmed to be online and available by the broadcast message.

[0101] Establishing the communication link: after meeting certain conditions (such as the storage system and the container storage interface driver being online), the system re-creates the communication connection between the container orchestration system and the storage system.

[0102] It should be noted that the present embodiment describes the steps and conditions of "re-establishing the communication link". First, the system will disconnect the current communication link. Then, the system will obtain a new broadcast message sent by the switch to understand the latest state of the storage system and the container storage interface driver. When the new broadcast message indicates that the storage system has not been updated again, the storage system is in the second online state (i.e., online and available), and the container storage interface driver is in the first online state (i.e., online and available), the system will establish a new communication link.

[0103] This mechanism ensures that the system can safely and effectively resume communication after updates or changes. By disconnecting the old communication link and establishing a new one based on the latest state information, the system can avoid communication failures due to inconsistent states or outdated configurations. Additionally, this step-by-step approach provides the possibility of additional checks or verifications before re-establishing communication, further enhancing the robustness and reliability of the system.

[0104] In some embodiments, consider a cloud storage environment where the container orchestration system needs to maintain continuous communication with the storage system. Due to a software update of the storage system, the system decides to re-establish the communication link. First, the system will disconnect the existing connection. Then, it listens to and obtains new broadcast messages sent by the switch. When these messages show that the storage system has completed the update and is in an online state, while the container storage interface driver is also in an online state, the system will re-establish the communication link between the two according to the latest configuration parameters.

[0105] Through the embodiments of the present application, it is ensured that the system can quickly and accurately restore communication capabilities after experiencing changes such as updates, thereby reducing the possibility of service interruption. Secondly, by establishing a new communication link based on the latest broadcast messages, the system can ensure that both parties of the communication are in the best and consistent state, which helps to improve the efficiency and accuracy of data transmission. Finally, this mechanism also enhances the self-repairing and adaptive capabilities of the system, enabling it to maintain high availability and stability in a dynamic environment.

[0106] As an optional solution, in the process of implementing the mounting of the storage volume through the communication link, the method further comprises:

[0107] S4-1, obtaining host information of the container orchestration system according to a second time interval;

[0108] S4-2, sending the host information to the storage system through the communication link to enable the storage system to create a mounting running object, wherein the mounting running object is an entity server or virtual machine that provides a mounting point for the storage volume.

[0109] In optional embodiments, the second time interval refers to a time period set by the system to determine the frequency of obtaining host information of the container orchestration system.

[0110] Host information: Here refers to the relevant information of the host (which may be a physical server or a virtual machine) where the container orchestration system is located, such as IP (Internet Protocol) address, host name, operating system type, etc. These information are necessary for the storage system to create a mounting running object.

[0111] Mount running object: a logical entity created in the storage system, representing a physical server or virtual machine that can provide a storage volume mount point. When a storage volume needs to be mounted, the system interacts with this mount running object.

[0112] It should be noted that the embodiment describes how the system interacts with the storage system to create mount running objects during the process of implementing storage volume mounting through a communication link. The system obtains host information of the container orchestration system at a set second time interval and sends this information to the storage system through the established communication link. The storage system creates mount running objects based on this information, and these objects represent the entity servers or virtual machines that provide storage volume mount points.

[0113] This mechanism of periodically obtaining and updating host information and interacting with the storage system to create mount running objects ensures that the system can continuously and accurately provide storage volume mounting services in a dynamically changing cloud environment. It enables the system to respond promptly to changes in host status, such as changes in IP addresses, resource additions or reductions, etc., thereby ensuring the reliability and flexibility of storage volume mounting.

[0114] In some embodiments, assume that in a cloud environment, a container orchestration system needs to mount a storage volume for use by the containers it manages. The system obtains the latest information of the host where the container orchestration system is located every 30 seconds (second time interval), such as changes in IP addresses, updates to the operating system, etc. Then, through the communication link already established with the storage system, the host information is sent to the storage system. The storage system creates a mount running object based on this information, and this object represents the server that actually provides the mount point. When the container needs to access the storage volume, it does so through this mount running object.

[0115] By obtaining and updating host information at a second time interval and interacting with the storage system to create mount running objects, the system achieves the following improvements: First, it improves the accuracy and timeliness of storage volume mounting, as the system always performs mounting operations based on the latest host information. Second, it enhances the dynamic adaptability of the system, enabling it to quickly adjust when the host status changes, ensuring service continuity. Finally, this mechanism also helps improve resource utilization efficiency and operational management convenience in the entire cloud environment.

[0116] As an optional solution, obtaining host information of the container orchestration system includes at least one of the following:

[0117] Obtaining at least one host name corresponding to the container orchestration system, wherein the host name is used to identify each node in the container orchestration system;

[0118] Obtain at least one serial number corresponding to the container orchestration system, wherein the serial number is used to track and identify the physical hardware in the container orchestration system.

[0119] Obtain at least one operating system type corresponding to the container orchestration system, wherein the operating system type is the system type supported by the container orchestration system.

[0120] In optional embodiments, hostname: In computer networks, a hostname is a name used to identify a specific computer or network device. In this embodiment, it specifically refers to the name used to identify individual nodes in the container orchestration system.

[0121] Serial number: It is usually a unique code used to identify and track specific physical hardware. In the context of a container orchestration system, the serial number is used to identify and track physical hardware components in the system.

[0122] Operating system type: Refers to the type or version of the operating system running on the container orchestration system. This helps understand the functions and compatibility supported by the system.

[0123] It should be noted that this embodiment describes specific aspects of obtaining host information of a container orchestration system. In the process of obtaining host information, the system will obtain at least one of the following information: the hostname corresponding to the container orchestration system (used to identify individual nodes in the system), the serial number (used to track and identify physical hardware in the system), and the operating system type (representing the system type supported by the container orchestration system).

[0124] Obtaining these host information is crucial for the management and operation of the container orchestration system. By understanding the hostname of each node, the serial number of the physical hardware, and the type of operating system, the system can more accurately allocate resources, troubleshoot and optimize the system. In addition, these information can also be used for security verification, log recording and performance monitoring, etc.

[0125] In some embodiments, obtaining hostname: Assuming a container orchestration system manages multiple nodes, each node has a unique hostname, such as "node1", "node2", etc. The system identifies and manages individual nodes by obtaining these hostnames.

[0126] Obtain serial number: If the container orchestration system runs on specific physical servers, each server has a unique serial number. The system can track and identify the hardware information of each server by obtaining these serial numbers.

[0127] Obtain operating system type: For example, the container orchestration system may run on Linux, Windows or other types of operating systems. The system obtains this information to ensure compatibility and correct function implementation.

[0128] By obtaining the host information of the container orchestration system, the system can achieve the following effects: First, it improves the manageability and visibility of the system, making it easier for administrators to identify and track individual components within the system. Second, it enhances the stability and reliability of the system, as the system can perform intelligent resource allocation and fault prevention based on the obtained information. Finally, the acquisition of this information also helps to improve the security and compliance of the system, as the system can implement more fine-grained access control and auditing strategies based on this information.

[0129] As an optional solution, after sending the host information to the storage system through the communication link to enable the storage system to create the mounting running object, the method further comprises:

[0130] S5-1, editing the configuration file of the persistent storage volume;

[0131] S5-2, applying the configuration file to the container orchestration system to trigger each node in the container orchestration system to request the storage system to create the corresponding persistent storage volume according to the definition in the configuration file;

[0132] S5-3, in the case where the persistent storage volume is bound to each node in the container orchestration system, instructing the storage system to mount the storage volume to the mounting running object, thereby providing persistent storage services for the container orchestration system through the persistent storage volume.

[0133] In an optional embodiment, the persistent storage volume is a storage resource used in the container orchestration system, which can persistently save data, so that the data will not be lost even if the container is deleted or restarted.

[0134] Configuration file: a file containing configuration information related to the persistent storage volume, such as the size, type, access rights, etc. of the storage volume.

[0135] Binding: refers to the establishment of an association between the persistent storage volume and the nodes in the container orchestration system, ensuring that each node can access its corresponding storage volume.

[0136] It is noted that after sending the host information to the storage system and making it create the mount running object, the embodiment also includes a series of steps to configure and apply the persistent storage volume. First, the configuration file of the persistent storage volume needs to be edited, which defines various attributes and parameters of the storage volume. Then, this configuration file is applied to the container orchestration system, which triggers the nodes in the system to request the storage system to create the corresponding persistent storage volume according to the definition of the configuration file. Finally, after the storage volume is successfully bound to the nodes of the container orchestration system, the storage system is instructed to mount the storage volume to the previously created mount running object, thereby providing persistent storage service for the container orchestration system.

[0137] By editing the configuration file, the attributes of the storage volume can be easily changed or new storage volumes can be added. In addition, since the storage volume is bound to the nodes of the container orchestration system, it can be ensured that each node has its dedicated storage space, thereby improving the security and isolation of data.

[0138] In some embodiments, assume that a Kubernetes (an open-source container orchestration platform) cluster needs to be configured with persistent storage volumes to save important data. First, the administrator will edit a configuration file, specifying that the storage volume has a size of 100 GB (Gigabyte) and a type of NFS (Network File System). Then, this configuration file will be applied to the Kubernetes cluster. Each node in the cluster will request the storage system to create a 100 GB NFS storage volume when it starts up. When these storage volumes are successfully bound to the nodes, the storage system will mount them to the previously created mount running object for the Kubernetes cluster. In this way, even if the containers in the Kubernetes cluster are deleted or restarted, the data can be saved through the persistent storage volume.

[0139] By editing and applying the configuration file of the persistent storage volume, and mounting the storage volume to the mount running object, the embodiment achieves the following effects: First, it ensures the persistence of data, so that data is not lost even if containers are deleted or restarted. Second, it improves the availability and reliability of data, because each node has its dedicated storage space. Finally, this method also provides flexible configuration options, so that administrators can easily adjust the attributes of the storage volume or add new storage volumes as needed.

[0140] As an optional solution, editing the configuration file of the persistent storage volume includes at least one of the following:

[0141] Adding the API version of the persistent storage volume adaptation in the configuration file;

[0142] Adding the specified type of resource corresponding to the persistent storage volume in the configuration file;

[0143] Adding the identity corresponding to the persistent storage volume in the configuration file;

[0144] Adding the access mode corresponding to the persistent storage volume in the configuration file;

[0145] Adding the request storage size corresponding to the persistent storage volume in the configuration file;

[0146] Adding the request storage type corresponding to the persistent storage volume in the configuration file.

[0147] In optional embodiments, the API version refers to the interface version adapted by the persistent storage volume, which ensures the compatibility between the storage volume and the container orchestration system.

[0148] The specified type of resource refers to the resource type represented by the storage volume, such as disk, network storage, etc., which helps the system to classify and manage storage resources.

[0149] Identity is the unique identifier of the storage volume, used to accurately identify and track the storage volume in the system.

[0150] Access mode defines the way the storage volume can be accessed, such as read-only, read-write, etc., which ensures the data security and consistency of the storage volume.

[0151] Request storage size refers to the storage space size allocated for the storage volume, which is determined according to the application's requirements.

[0152] Request storage type refers to the type of storage technology used by the storage volume, such as SSD (Solid State Drive), HDD (Hard Disk Drive), etc., different types of storage technology have different performance and cost characteristics.

[0153] It should be noted that editing the configuration file of the persistent storage volume involves multiple key steps, at least including adding the API version of the persistent storage volume adaptation, the specified type of resource, identity, access mode, request storage size and request storage type. These steps ensure that the storage volume can be correctly and efficiently created and used in the container orchestration system, while meeting specific storage requirements and management strategies.

[0154] The process of editing configuration files is an important part of automated storage management. By finely configuring these parameters, administrators can ensure efficient use of storage resources, reliable storage of data, and precise matching of application requirements. In addition, with the continuous development of container technology and cloud-native applications, the flexibility and scalability of configuration files have become increasingly important to adapt to changing business needs and technical environments.

[0155] In some embodiments, in a Kubernetes environment, editing the configuration file of a persistent storage volume (such as PersistentVolume, abbreviated as PV) may involve the following operations: specify apiVersion as v1 in the configuration file, indicating the use of the first version of the Kubernetes API to manage PV. Set the kind field (indicating the type of resource object) to PersistentVolume (a resource object in the Kubernetes cluster used to provide persistent storage resources), indicating that this is a persistent storage volume resource. Assign a unique name to the PV as its identity. Define the access mode of the PV through the accessModes field, such as setting it to ReadWriteOnce, indicating that the PV can only be mounted by one node in read-write mode. Use the resources.requests.storage field to specify the requested storage size, such as 10Gi indicating 10 gigabytes. Specify the storage type in the storageClassName field, such as standard (ordinary storage type) or ssd (solid state disk storage), etc., to select different performance storage backends.

[0156] By editing the configuration file of the persistent storage volume and including the above key information, the following effects can be achieved:

[0157] Compatibility guarantee: By specifying the API version, ensure the compatibility and stability of the storage volume with the container orchestration system.

[0158] Optimization of resource management: The specified type of resource helps the system to more effectively classify and manage different types of storage resources.

[0159] Accurate identification and tracking: Identity allows the storage volume to be uniquely and accurately identified and tracked in the system.

[0160] Enhanced data security: Access mode limits the access method of the storage volume, thereby enhancing the security and consistency protection of data.

[0161] Flexible resource allocation: Requested storage size and type are configured according to actual needs, realizing flexible allocation and efficient use of storage resources.

[0162] As an optional solution, before editing the configuration file of the persistent storage volume, the method further includes:

[0163] S6-1, according to the characteristics of the storage system, edit the storage class configuration file;

[0164] S6-2, apply the storage class configuration file to the container orchestration system, to trigger the container orchestration system to register the storage class resources to each node in the container orchestration system according to the definition in the storage class configuration file, wherein the storage class resources are used to determine how to allocate the storage resources brought by the persistent storage service to the persistent storage volume.

[0165] In optional embodiments, the storage class configuration file: a configuration file specific to the storage system, which defines how to create, manage and allocate storage resources. This usually includes the type of storage, performance parameters, recycling policies, etc.

[0166] Storage class resources: in the container orchestration system, it is an abstract resource type that represents some service capabilities or characteristics of the storage system. Storage class resources are used to dynamically allocate actual storage resources to persistent storage volumes.

[0167] It should be noted that before editing the configuration file of the persistent storage volume, a key step needs to be taken: according to the characteristics of the storage system, edit the storage class configuration file and apply it to the container orchestration system. The purpose of this is to trigger the container orchestration system to register the storage class resources to each node in the system according to the definition in the storage class configuration file. These storage class resources determine how to allocate the storage resources provided by the persistent storage service to the persistent storage volume.

[0168] The editing and application of the storage class configuration file is an important part of cloud-native storage management. By defining different storage classes, administrators can flexibly meet the different needs of various applications for storage, such as performance, reliability, cost, etc. In addition, storage classes also support dynamic volume allocation, that is, automatically creating and destroying storage volumes according to demand, thereby improving the utilization and management efficiency of storage resources.

[0169] In some embodiments, in the Kubernetes environment, the storage class (StorageClass) is a kind of storage class resource. The administrator will first create a StorageClass object, define its name, backend storage provider, recycling policy, etc. Then, when a persistent storage volume (PersistentVolume, PV) needs to be dynamically created, Kubernetes will automatically allocate and manage the actual storage resources according to the definition of the StorageClass.

[0170] By editing and applying storage class configuration files, embodiments of the present application achieve the following effects:

[0171] Increased flexibility: Administrators can define different storage classes according to the characteristics of the storage system and the needs of the application, thereby flexibly managing and allocating storage resources.

[0172] Dynamic resource management: Storage class resources support dynamic volume allocation, making the creation, allocation, and recycling of storage resources more automated and efficient.

[0173] Improved resource utilization: By reasonably configuring storage classes, waste of storage resources can be avoided, and resource utilization can be improved.

[0174] Simplify management complexity: The abstraction of storage classes allows administrators to manage storage resources from a higher level, reducing management complexity and workload.

[0175] As an optional solution, the method further comprises:

[0176] According to the third time interval, the host of the container orchestration system is checked to obtain a checking result.

[0177] In an optional embodiment, the third time interval refers to the time period for performing host checks, which can be minutes, hours, days, etc., and is set according to actual needs and security policies.

[0178] Host check: Check the status and health of the host where the container orchestration system is located, including but not limited to CPU (Central Processing Unit) usage, memory usage, disk space, network connection, etc.

[0179] Checking result: The conclusion obtained after the host check is completed, usually including the running state of the host, existing problems or potential risks, etc.

[0180] It should be noted that the present embodiment also includes a periodic host check step, i.e. performing host checks on the container orchestration system according to the set third time interval and obtaining the checking result. The purpose of this step is to ensure that the host of the container orchestration system is in a healthy state and can run normally and provide services.

[0181] Host check is one of the important measures to ensure the stable operation of the container orchestration system. Through regular checks, potential problems can be discovered and solved in a timely manner, thereby avoiding system crashes or service interruptions. In addition, host checks can also help administrators understand the running status of the system, providing a basis for optimizing resource allocation and performance tuning.

[0182] In some embodiments, assuming that the present embodiment uses Kubernetes as the container orchestration system, a host check is performed every hour (the third time interval is 1 hour). The contents of the check may include whether the CPU and memory usage of the node is too high, whether the disk space is sufficient, whether the network connection is stable, etc. After the check, the system generates a check result report listing the status of all check items and possible problems, such as "the CPU usage of node A exceeds 80%, which may cause performance bottleneck" and the like.

[0183] By performing a host check on the container orchestration system according to the third time interval, the present embodiment achieves the following effects:

[0184] Timely discovery and resolution of problems: Regular checks can help administrators discover problems or potential risks on the host in a timely manner and take appropriate measures to resolve them, thereby ensuring the stable operation of the system.

[0185] Improving system availability: By performing a host check, service interruptions or performance degradation caused by host failures can be prevented or reduced, thereby improving system availability and user experience.

[0186] Optimizing resource allocation: Based on the check results, administrators can understand the resource usage of the host and optimize resource allocation to improve resource utilization and system performance.

[0187] As an optional solution, after establishing a communication link between the container orchestration system and the storage system and mounting the storage volume through the communication link, a host check is performed on the container orchestration system according to the third time interval, and the check result is obtained, including:

[0188] S7-1, traversing all network card ports of the container orchestration system to obtain port information;

[0189] S7-2, in the case where the port information indicates that the network card port is in a port offline state, disconnecting the communication link.

[0190] In optional embodiments, the network card port: a physical or logical port on a network interface card (NIC, Network Interface Card) used for network data transmission.

[0191] Port offline state: a state in which the network card port cannot transmit data due to failure, disconnection, or other reasons.

[0192] Disconnecting the communication link: terminating or disconnecting the previously established communication connection to prevent further data transmission.

[0193] It is necessary to note that after establishing the communication link between the container orchestration system and the storage system and realizing the mounting of the storage volume through the communication link, the system will perform a host check on the container orchestration system at a set third time interval. During this check process, the system will traverse all the network card ports of the container orchestration system to obtain port information. If the port information of a certain network card port shows an offline state, the system will disconnect the communication link associated with the network card port.

[0194] This periodic check mechanism is an important measure to ensure system stability and reliability. By monitoring the status of network card ports, the system can timely discover network connection problems and take appropriate remedial measures. In cloud-native environments and distributed systems, the stability and reliability of network communication are crucial because they directly affect the availability of services and the consistency of data.

[0195] In some embodiments, assuming there is a Kubernetes-based container orchestration system that has established a communication link with a distributed storage system. During system operation, Kubernetes performs a host check at a set time interval (e.g., every hour). During the check process, Kubernetes traverses all the network card ports of its nodes. If it finds that a certain network card port of a node shows an offline state (e.g., because the network cable is pulled out or the network interface is faulty), Kubernetes will disconnect the communication link related to that port to avoid data loss or communication errors.

[0196] By performing a host check on the container orchestration system at a third time interval and paying special attention to the status of network card ports, the embodiments of the present application achieve the following effects:

[0197] Improve system stability: By timely discovering and handling the offline state of network card ports, the risk of service interruption or data loss due to network problems is reduced.

[0198] Enhance fault recovery capability: Once the port is detected offline, the system can quickly disconnect the problematic communication link, creating conditions for subsequent troubleshooting and recovery.

[0199] Optimize resource utilization: Avoid wasting resources on invalid or unreliable communication links, improving the overall resource utilization efficiency of the system.

[0200] As an optional solution, before establishing the communication link between the container orchestration system and the storage system and realizing the mounting of the storage volume through the communication link, performing a host check on the container orchestration system at a third time interval to obtain a check result, including:

[0201] For each of all the network card ports, the corresponding port information is sent to the switch at a fourth time interval, wherein the data link message includes the port information.

[0202] In optional embodiments, the fourth time interval refers to the frequency at which the system sends port information to the switch, which can be adjusted according to network environment and system requirements.

[0203] Port information: detailed data about network card ports, which may include port status, speed, connection type, etc.

[0204] Data link message: in network communication, a formatted data unit used to transmit information at the data link layer, here specifically refers to the message including port information.

[0205] It should be noted that before establishing the communication link between the container orchestration system and the storage system and mounting the storage volume through this communication link, the system performs a periodic host check process. In this process, the system will send the port information of each port to the switch according to the set fourth time interval for all network card ports. The "data link message" mentioned here includes these port information.

[0206] This mechanism of periodically sending port information is very useful for maintaining network stability and monitoring network status. Especially in cloud environments or large distributed systems, the complexity and dynamics of network connections require the system to be able to perceive and adjust network configuration in real time. By sending data link messages including port information, the system can more effectively manage network resources and prevent potential network problems.

[0207] In some embodiments, in a large cloud environment, an administrator is preparing to deploy a new container orchestration system and plans to connect it with the existing storage system. Before that, in order to ensure smooth network communication, the system will periodically check the status of all node network card ports. For example, every 30 seconds (fourth time interval), the system will collect detailed information of each port and encapsulate it in a data link message, which is sent to the switch in the network. In this way, the switch and other network devices can understand the real-time status of the entire network in order to control traffic and prevent faults.

[0208] Through the embodiments of the present application, the method of sending port information to the switch at a fourth time interval achieves the following effects:

[0209] Real-time monitoring: the system can monitor the status of all network card ports in real time, and timely discover and solve potential network problems.

[0210] Prevent faults: by periodically updating the port information in the switch, the system can take preventive measures before network failures occur, reducing the possibility of service interruption.

[0211] Optimized network management: This mechanism provides network administrators with more detailed and timely data, helping them manage network resources more effectively and improve the overall performance and reliability of the network.

[0212] As an optional solution, after sending the corresponding port information to the switch at the fourth time interval for each of the network card ports, the method further includes:

[0213] S8-1, obtaining a state notification sent by the switch, wherein the state notification is used to notify the online state of the storage system;

[0214] S8-2, returning a notification response message corresponding to the state notification to the switch, wherein the notification response message is used to indicate that the container storage interface driver has received the state notification.

[0215] In optional embodiments, the state notification: a message sent by the switch, used to inform the system about the online or offline state of the storage system or other network devices.

[0216] Notification response message: a response message sent by the system after receiving the state notification, used to confirm that the notification has been received.

[0217] Container storage interface driver: in a container orchestration system, a component or module responsible for interacting with the storage system, which handles storage-related requests and responses.

[0218] It should be noted that after periodically sending information of each network card port to the switch, the embodiment further includes the step of receiving state notifications from the switch. These state notifications are used to inform the online state of the storage system. After receiving these notifications, the system will send a notification response message back to the switch to confirm that the container storage interface driver has successfully received these state notifications.

[0219] This mechanism ensures that the system can quickly and accurately respond to changes in the state of the network or storage devices. By receiving and processing state notifications in a timely manner, the system can take necessary measures to maintain service continuity and data integrity, such as switching to a backup storage system or re-establishing communication links.

[0220] In some embodiments, in a cloud-native environment, the container orchestration system communicates with the storage system through a specific driver. When the storage system becomes offline for some reason, the switch connected to it will send a state notification to the container orchestration system. After receiving this notification, the container orchestration system will send a notification response message back to the switch through the container storage interface driver, confirming that it is aware of the current state of the storage system.

[0221] By receiving the status notification of the exchange and sending the notification response message, the embodiments of the present application achieve the following effects:

[0222] State awareness: the system can real-time perceive the online state of the storage system, providing a basis for fast response and fault handling.

[0223] Communication confirmation: by sending the notification response message, the system confirms that the communication with the exchange is effective and reliable.

[0224] Fault recovery preparation: after knowing the state of the storage system, the system can prepare for possible fault recovery operations, such as starting a backup plan or reallocating resources.

[0225] As an optional solution, the method further comprises:

[0226] S9-1, editing a container group configuration file;

[0227] S9-2, applying the container group configuration file to the container orchestration system to trigger the container orchestration system to apply container group resources to the container orchestration system according to the definitions in the container group configuration file, wherein the container group resources are used to manage one or more containers in the container orchestration system running on the same node.

[0228] In an optional embodiment, the container group configuration file: a file including container group related configuration information, used to define how to deploy and manage a container group in the container orchestration system.

[0229] Container group resources: in the container orchestration system, resource objects used to define and control how a group of containers run and cooperate with each other on the same node.

[0230] It should be noted that the embodiment also includes the step of editing the container group configuration file and applying this configuration file to the container orchestration system. The purpose of this is to trigger the container orchestration system to apply container group resources to the system according to the definitions in the configuration file. These container group resources are used to manage one or more containers running on the same node in the container orchestration system.

[0231] By editing and applying the container group configuration file, the container group running in the container orchestration system can be flexibly defined and managed. This not only simplifies the deployment and management process of the container, but also improves the scalability and maintainability of the system. At the same time, the use of the configuration file also makes it easy to record and track the configuration history of the container, facilitating problem troubleshooting and recovery.

[0232] In some embodiments, assuming Kubernetes is used as the container orchestration system, a configuration file for a Pod (a group of containers) can be created (in Kubernetes, a Pod is the smallest, deployable computing unit, representing one or a group of application containers running on the cluster). This configuration file may include information such as the image of the container, the required resources, environment variables, etc. When this configuration file is applied to the Kubernetes cluster, Kubernetes will create one or more Pods according to the definition of this configuration file and ensure that these Pods run as required on the same node.

[0233] By editing the container group configuration file and applying it to the container orchestration system, the embodiments of the present application achieve the following effects:

[0234] Flexible configuration: allows users to customize the configuration of the container group as needed, including the number, type, resource requirements, etc. of the containers.

[0235] Simplify deployment: through the configuration file, the deployment process of the container group is simplified, improving the deployment efficiency.

[0236] Unified management: ensures that the containers on the same node run and manage uniformly according to the definition of the configuration file, improving the stability and maintainability of the system.

[0237] Easy to extend: when the container group needs to be extended or updated, only the configuration file needs to be modified and re-applied, without the need to manually adjust the settings of each container.

[0238] As an optional solution, after establishing the communication link between the container orchestration system and the storage system and realizing the mounting of the storage volume through the communication link, the method further includes:

[0239] S10-1, collect the latest host information of the container orchestration system according to a fourth time interval;

[0240] S10-2, send the latest host information to the storage system through the communication link.

[0241] In optional embodiments, the fourth time interval refers to the frequency at which the system collects and sends host information, which can be adjusted according to the actual needs of the system and the network environment.

[0242] Host information: various data about the host where the container orchestration system is located, which may include the hardware configuration, running state, network configuration, etc. of the host.

[0243] It is necessary to note that after establishing the communication link between the container orchestration system and the storage system and successfully mounting the storage volume through the link, the embodiments of the present application also include a step of periodically collecting information. The system will collect the latest host information of the container orchestration system according to the set fourth time interval, and send these latest information to the storage system through the established communication link.

[0244] This mechanism of periodically collecting and sending host information is crucial for dynamic resource management and optimizing system performance. Especially in cloud-native and distributed computing environments, dynamic allocation and efficient use of resources are key to improving overall system performance and reducing costs. By real-time understanding of host status, the storage system can better cooperate with the container orchestration system to achieve on-demand allocation and efficient use of resources.

[0245] In some embodiments, assuming there is a Kubernetes cluster running in a cloud environment connected to a distributed storage system. In order to ensure that the storage system can real-time understand the status of the cluster and optimize the allocation of storage resources accordingly, Kubernetes will collect the latest information of the cluster host every certain period of time (such as every 5 minutes, i.e. the fourth time interval), such as CPU usage, memory occupation, network bandwidth utilization, etc. Then, these information will be sent to the storage system through the communication link between Kubernetes and the storage system.

[0246] According to the fourth time interval, the latest host information of the container orchestration system is collected and sent to the storage system, which achieves the following effects:

[0247] Real-time state awareness: the storage system can real-time understand the host status of the container orchestration system, providing a data basis for dynamic resource management and optimization.

[0248] Optimized resource allocation: based on the latest host information, the storage system can more intelligently allocate and adjust storage resources to meet the actual needs of the container orchestration system.

[0249] Improve system performance: by reducing resource waste and improving resource utilization efficiency, this approach helps to improve the running performance and response speed of the entire system.

[0250] As an optional solution, for the convenience of understanding, the mounting method of the storage volume is applied to the CSI (Container Storage Interface) drive mounting volume process, which can include two parts, respectively, the pre-process and the mounting process.

[0251] The pre-process mainly establishes RoCE-NVMe (Remote Direct Memory Access over Converged Ethernet-Non-Volatile Memory Express) link and creates a host, and the steps are roughly as follows:

[0252] In the first step, the nvme connect command is executed manually on each K8s node to establish network connection between each K8s node and the storage node, that is, to open the in-band channel between the host (server) and the storage.

[0253] In the second step, the NQN (NVMe Qualified Name) information of each K8s node is manually obtained on the storage system, and a corresponding host is created on the storage to prepare for subsequent volume mounting.

[0254] The mounting process mainly includes the creation of SC (StorageClass), PVC (PersistentVolumeClaim) and POD (Pod). SC is a storage template, PVC is a PV declaration (corresponding volume), and POD is a collection of containers. The process of creating a POD is the process of using a volume.

[0255] In the above process, the first and second steps of the pre-process need to be manually operated. If the number of nodes in the K8s cluster is large, the number of operations in the first and second steps will increase accordingly, which not only makes the process cumbersome and repetitive, but also is prone to errors.

[0256] The main content of the embodiment is to simplify the pre-process of mounting a volume, that is, to automatically implement the first and second steps in the above process based on network intelligent perception, thereby reducing manual intervention and reducing the probability of errors.

[0257] First, the CSI driver and the storage system send an LLDP (Link Layer Discovery Protocol) packet to the switch every 5 seconds to maintain uninterrupted communication with the switch, and the switch uses the discontinuity of the LLDP packet to determine whether the CSI driver and the storage system are online. When the switch discovers that the storage is online or offline, it sends a broadcast message to the local area network to inform the CSI driver of the storage status.

[0258] Second, the CSI driver traverses all the network card port information on the current K8s node, that is, obtains the IP address, port type and active state configured on each port, and listens to the broadcast message on each port through the select mode. Once the message from the switch is listened to, the storage is learned to be online or offline through analysis, and the command nvme connect or nvme disconnect is called to establish or disconnect the connection between the current K8s node and the storage node.

[0259] Third, after the CSI driver establishes the connection between the K8s node and the storage node, that is, the RoCE-NVMe link is opened, the channel between the storage and the K8s node is established, which can be used for communication between the K8s node and the storage node. The CSI driver collects the host information on the K8s node, including the host name, serial number, operating system type and version, and reports the above information to the storage system through the channel.

[0260] Fourth, after the storage system receives the host information from the K8s node, the host is created according to the serial number and NQN in the host information, which will be used for the use (i.e. mounting) of the storage volume.

[0261] The above process is completed by the cooperation of the CSI driver and the storage system, so as to realize the automation and intelligentization of the pre-mounting volume process.

[0262] In an optional embodiment, the CSI driver is deployed as shown in FIG. 3. The CSI driver plays a role of connecting the upper and lower parts between the K8s and the storage system, that is, it is connected to the K8s upward and connected to the storage system downward, and dynamically provides persistent space. The CSI needs 5 sidecar (a design pattern mainly used in microservice architecture) components to connect the K8s, which are external provisioner, external attacher, external snapshotter, external resizer and node-driver-registrar, as follows:

[0263] external provisioner: control and forwarding of creating / deleting volumes and snapshots.

[0264] external attacher: control and forwarding of mounting / unmounting volumes.

[0265] external snapshotter: control and forwarding of creating / deleting snapshots.

[0266] External resizer: control and forwarding of the expanded volume.

[0267] Node-driver-registrar: register CSI driver into kubelet (node agent) service.

[0268] In an optional embodiment, the CSI driver self-checking process is shown in FIG. 4. The host self-checking is a separate thread of the CSI driver, which performs self-checking every 1 second by default. The host self-checking includes the following contents:

[0269] Traverse all the network card ports on the current host, add or update the information of the port, including the IP address of the port, the IP type (IPV4 (Internet Protocol version 4) or IPV6 (Internet Protocol version 6)), whether it is physical, whether it is a vlan (Virtual Local Area Network), and whether it is in the startup state.

[0270] If it is detected that the network card port is offline, that is, the state is in DOWN, then all the established RoCE-NVMe connections on the port are actively disconnected. Of course, it can also be configured whether to actively disconnect the connection.

[0271] In an optional embodiment, the communication interaction process between the CSI driver, the storage system and the switch is shown in FIG. 4. The CSI driver sends an LLDP packet to the switch every 5 seconds according to the latest network card port information obtained in the previous step, so that the switch knows whether the host port is always online. The LLDP announcement packet format sent by the CSI driver is based on the standard LLDP packet, and a custom item of the customer is added.

[0272] In addition, the storage system also sends an LLDP packet to the switch every 5 seconds to maintain the heartbeat between the two. The switch judges whether the storage is online through the LLDP packet sent from the storage. If no packet sent by the storage is received within two minutes, it is considered that the storage is offline. At this time, the switch will organize the message of the offline storage into a new LLDP packet and broadcast it. If a packet sent from the storage is suddenly received, it is considered that the storage is online. Similarly, the switch will also organize the message of the online storage into a new LLDP packet and broadcast it.

[0273] In an optional embodiment, the CSI driver needs to subscribe to the status notification (storage online or storage offline) sent by the switch to receive the corresponding message. When the CSI driver receives the status notification, it first sends an ACK (Acknowledge character) packet to the switch to respond, and then parses the status notification and performs corresponding operations according to the content of the status notification.

[0274] The CSI driver receives the status notification sent by the switch and parses it. If it is a storage online message, it sends an nvme connect association instruction to the host NVMe system. If it is a storage offline message, it sends an nvme disconnect disassociation instruction to the host NVMe system.

[0275] The RoCE-NVMe connection established by the CSI driver is an IP-IP connection from the host port to the storage port. When the CSI driver disconnects, it only identifies the established IP-IP NVMe link. For those NVMe links that do not include IP-IP information, the CSI driver does not process them.

[0276] In an optional embodiment, after establishing the RoCE-NVMe link between the host and the storage, the host information is reported to the storage.

[0277] First, the CSI driver identifies all RoCE-NVMe channels. All channels established in the previous step are obtained through the command ls / dev / |egrep^nvme([0-9]+$), and the channel identifier is generally / dev / nvmeX.

[0278] Second, the CSI driver collects host information every 10 minutes. The host information that needs to be collected includes the host name, serial number, operating system type and version. The host name is obtained through the command hostname, the serial number is obtained through the command dmidecode-t 1|grep‘Serial Number’, and the operating system type and version are obtained by reading the file / dev / os-release.

[0279] Then, the CSI driver reports the host information to the storage system. The host information is reported to the storage system through the channel.

[0280] In an optional embodiment, after the storage system receives the host information reported by the CSI driver, it obtains the NQN information of the host through the RoCE-NVMe link, and then calls the command mkhost to create a host. Note that the 0 type of the host must be RoCE type. This host is used for mounting the volume. At this point, the pre-work for mounting the volume has been completed.

[0281] In an optional embodiment, the configuration file corresponding to the SC is edited, and the SC is created through the command line of K8s, so as to prepare for subsequent creation of PVC. It is noted that each SC corresponds to two storage systems. The detailed information of the SC is generally described through a yaml (YAML Ain't Markup Language, a format used to express data serialization) file, and an example is as follows:

[0282] apiVersion: storage.K8s.io / v1

[0283] kind:StorageClass

[0284] metadata:

[0285] name:sc

[0286] provionser:csi-instorage

[0287] parameters

[0288] storageKind:block

[0289] storageName:storage1

[0290] apiVersion:K8s's API version, which is v1 here.

[0291] kind:K8s's resource type, which is StorageClass, namely SC.

[0292] meta.name:The name of the metadata type, namely the name of the SC.

[0293] spec.provisioner:The provider of the SC, namely the name of the CSI driver.

[0294] spec.parameters.storageKind:The storage type, block representing a block device.

[0295] spec.parameters.storageName:The name of the storage. The SC is created through the command kubectl apply-f sc.yaml, and the process of creating the SC does not require the participation of the CSI driver.

[0296] In an optional embodiment, the configuration file corresponding to the PVC is edited, and the PVC is created through the command line of K8s. The node and the host correspond, the PVC and the storage volume correspond, and the process of creating the PVC is the process of creating a new volume on the storage. The detailed information of the PVC is generally described through a yaml file, and an example is as follows:

[0297] apiVersion: v1

[0298] kind: PersistentVolumeClaim

[0299] metadata:

[0300] name: pvc

[0301] spec:

[0302] accessModes:

[0303] -ReadWriteOnce

[0304] volumeMode: Filesystem

[0305] resources:

[0306] requests:

[0307] storage: 1Gi

[0308] storageClassName: sc

[0309] apiVersion: The API version of K8s, which is v1 here.

[0310] kind: The resource type of K8s, which is PVC here.

[0311] meta.name: The name of the metadata type, that is, the name of the PVC.

[0312] spec.accessModes: The access mode of the PVC, ReadWriteOnce represents that only one K8s node is allowed to access.

[0313] spec.volumeMode: The volume mode of the PVC, FileSystem represents that the volume will be formatted into a file system.

[0314] spec.resources.requests.storage: The PVC size, which is 1Gi here.

[0315] spec.storageClassName: The storage template corresponding to the PVC, that is, the name of the SC.

[0316] Three PVCs are created by the command kubectl apply-f pvc.yaml. The process of creating a PVC requires the participation of CSI, and the command for creating a volume is mkvdisk.

[0317] In an optional embodiment, the configuration file corresponding to the POD is edited, and the POD is created through the command line of K8s. The process of creating a POD first completes the mounting of the master volume on the storage side, then completes the formatting and mapping of the device on the host side, and finally synchronizes the directory into the container. The operation of the container on the directory is the operation on the volume. The POD details are generally described by a yaml file, for example:

[0318] spec.volumes.persistentVolumeClaim.claimName: PVC name. Used to bind a certain PVC.

[0319] The POD is created by the command kubectl apply-f pod.yaml. The process of creating a POD requires the participation of CSI driver, and CSI realizes the mounting of the volume by interacting with the storage and host. The steps are as follows:

[0320] First, call the storage interface lshost to view the host.

[0321] Second, call the storage interfaces mkvdisk, hostmap, lsportip and lshost to mount the master volume corresponding to the PVC to the host and obtain the mounting information.

[0322] Third, call the host interface nvme list_subsys to obtain the RoCE_NVMe link between the host and the storage.

[0323] Fourth, traverse the directory / dev / disk / by-id to obtain the single device information corresponding to the volume.

[0324] Fifth, call the host interface multipath to obtain the multi-path device aggregated by all single-path devices corresponding to the master volume.

[0325] Sixth, call the host interface mkfs to format the volume according to the required file system and mount the volume to the specified directory.

[0326] Through the above steps, the automatic creation of host is completed, and the mounting of the volume is facilitated.

[0327] It should be noted that the embodiment claims a comprehensive network intelligent perception mechanism, which realizes the automation of the pre-mounted volume process through the cooperation of multiple links. The mechanism includes the following core parts:

[0328] Real-time status update: The CSI driver and storage system send LLDP packets to the switch every 5 seconds to update and notify its online status in real time. The switch uses this heartbeat signal to accurately determine the real-time status of the CSI driver and storage system, and broadcasts the status change of the storage system within the local area network, ensuring that all related components in the network can learn the latest status of the storage system in time.

[0329] CSI monitoring and response: CSI has the ability to monitor messages in the local area network, especially the ability to receive and analyze LLDP packets from the switch. According to the packet content, CSI can intelligently determine the online or offline status of the storage system, and automatically establish or disconnect the RoCE-NVMe link accordingly, thereby realizing the automation and intelligentization of link management.

[0330] Host information collection and reporting: In order to maintain the real-time and accuracy of information, the CSI driver is designed to automatically collect host information every 10 minutes and report it to the storage system through a dedicated channel. This mechanism ensures that the storage system can continuously obtain the latest host information, providing reliable data support for subsequent operations.

[0331] Automatic creation of host records: When the storage system receives host information and NQN from the CSI driver, it automatically creates a host record for the host. This function greatly simplifies the subsequent volume mounting process, improving the usability and efficiency of the system.

[0332] In some embodiments, in order to update and notify the switch of its online status in real time, the CSI driver and storage system are specially designed to send LLDP packets to the switch every 5 seconds. The switch uses this heartbeat mechanism to monitor the real-time status of the CSI driver and storage system, and broadcasts the online or offline notification of the storage system within the local area network.

[0333] Furthermore, CSI can monitor messages in the local area network, especially LLDP packets from the switch. Once the packet is received, CSI will immediately analyze it to determine the status of the storage system. If the storage system is online, CSI will automatically establish a RoCE-NVMe link; otherwise, if the storage system is offline, it will automatically disconnect the link.

[0334] In order to maintain the real-time nature of the information, the CSI driver is designed to automatically collect host information every 10 minutes and report it to the storage system through a dedicated channel.

[0335] Further, after receiving the host information and the NQN from the CSI driver, the storage system automatically creates a host record for the host, thereby greatly simplifying the subsequent mounting process of the volume.

[0336] In addition, the embodiment realizes the automation of the pre-mounting process of the volume by the network intelligent perception technology, and can also be widely applied to other systems, such as the Cinder (a component in OpenStack for providing block storage services) driver of OpenStack (an open source cloud computing management platform), thereby improving the intelligence and efficiency of the system.

[0337] Through the embodiment of the present application, with the help of the network intelligent perception technology, the pre-mounting process of the volume is upgraded from the original manual operation to fully automated processing. First, through the intelligent management of the CSI driver, the RoCE-NVMe link between the K8s node and the storage node can be automatically established without human intervention, thereby greatly reducing the work burden of the operation and maintenance personnel and realizing the effective release of human resources. Second, the automatic acquisition of the host information and the automatic creation of the host not only simplify the operation process, but also reduce the error risk that may be introduced by manual operation, and significantly improve the overall operation efficiency of the system.

[0338] Through the above description of the embodiments, those skilled in the art can clearly understand that the method according to the above embodiments can be realized by means of software and the necessary general hardware platform, of course, it can also be realized by hardware, but in many cases the former is a better embodiment. Based on such understanding, the technical solutions of the present application can be embodied in the form of a software product, which is stored in a storage medium (such as a ROM (Read-Only Memory), a RAM (Random Access Memory), a magnetic disk, or an optical disc), and includes a plurality of instructions for causing an end device (which can be a mobile phone, a computer, a server, or a network device) to execute the method of each embodiment of the present application.

[0339] In the present embodiment, a mounting device for a storage volume is also provided, which is configured to implement the above embodiments and optional implementation manners, and will not be described again. As used below, the term "module" can be a combination of software and / or hardware that implements a predetermined function. Although the device described in the following embodiments is preferably implemented in software, hardware or a combination of software and hardware can also be implemented and conceived.

[0340] FIG. 5 is a structural block diagram of a mounting device for a storage volume according to an embodiment of the present application, as shown in FIG. 5, the device includes:

[0341] The first obtaining unit 502 is configured to obtain a broadcast message sent by the switch, wherein the switch is configured to determine whether the container storage interface driver and the storage system are online by using an interruption of a data link message, and the data link message is a message sent by the container storage interface driver and the storage system to the switch according to a preset time interval.

[0342] The first establishing unit 504 is configured to establish a communication link between the container orchestration system and the storage system, and realize mounting of the storage volume through the communication link, in a case where the broadcast message indicates that the container storage interface driver is in the first online state and the storage system is in the second online state.

[0343] The optional embodiment can refer to the examples shown in the above-described mounting method of the storage volume, and details are not described herein in this example.

[0344] As an optional solution, the apparatus further includes:

[0345] The disconnecting unit is configured to disconnect the communication link in a case where the broadcast message indicates that the container storage interface driver is switched from the available state to the unavailable state or the storage system is switched from the available state to the unavailable state after the broadcast message sent by the switch is obtained.

[0346] The optional embodiment can refer to the examples shown in the above-described mounting method of the storage volume, and details are not described herein in this example.

[0347] As an optional solution, the apparatus further includes:

[0348] The first determining unit is configured to determine that the container storage interface driver is in the first online state in a case where the broadcast message indicates that the container storage interface driver is switched from the unavailable state to the available state after the broadcast message sent by the switch is obtained.

[0349] The second determining unit is configured to determine that the storage system is in the second online state in a case where the broadcast message indicates that the storage system is switched from the unavailable state to the available state after the broadcast message sent by the switch is obtained.

[0350] The optional embodiment can refer to the examples shown in the above-described mounting method of the storage volume, and details are not described herein in this example.

[0351] As an optional solution, the apparatus further includes:

[0352] The setting unit is configured to set the container storage interface driver to query whether communication is maintained between the container orchestration system and the container storage interface driver according to a first time interval before the broadcast message sent by the switch is obtained.

[0353] The third determining unit is configured to determine that the container storage interface driver is in an available state in a case where the container orchestration system and the container storage interface driver maintain communication before the broadcast message sent by the switch is acquired.

[0354] The fourth determining unit is configured to determine that the container storage interface driver is in an unavailable state in a case where the container orchestration system and the container storage interface driver break communication before the broadcast message sent by the switch is acquired.

[0355] Optional embodiments can refer to the examples shown in the mounting method of the storage volume described above, which will not be repeated here in this example.

[0356] As an optional solution, the device further comprises:

[0357] The second establishing unit is configured to re-establish the communication link in a case where the broadcast message indicates that the storage system has been updated and the communication link has been established after the broadcast message sent by the switch is acquired.

[0358] Optional embodiments can refer to the examples shown in the mounting method of the storage volume described above, which will not be repeated here in this example.

[0359] As an optional solution, the second establishing unit comprises:

[0360] The first disconnecting module is configured to disconnect the communication link.

[0361] The first acquiring module is configured to acquire a new broadcast message sent by the switch.

[0362] The establishing module is configured to establish the communication link in a case where the new broadcast message indicates that the storage system has not been updated, the container orchestration system is in a second online state, and the container storage interface driver is in a first online state.

[0363] Optional embodiments can refer to the examples shown in the mounting method of the storage volume described above, which will not be repeated here in this example.

[0364] As an optional solution, the device further comprises:

[0365] The second acquiring unit is configured to acquire host information of the container orchestration system at a second time interval.

[0366] The first sending unit is configured to send the host information to the storage system through the communication link to make the storage system create a mounting running object in a process of implementing the mounting of the storage volume through the communication link, wherein the mounting running object is an entity server or a virtual machine that provides a mounting point of the storage volume.

[0367] Optional embodiments can refer to the examples shown in the mounting method of the storage volume described above, which will not be repeated here in this example.

[0368] As an optional solution, the second acquisition unit comprises at least one of the following:

[0369] The second acquisition module is configured to acquire at least one hostname corresponding to the container orchestration system, wherein the hostname is used to identify each node in the container orchestration system;

[0370] The third acquisition module is configured to acquire at least one serial number corresponding to the container orchestration system, wherein the serial number is used to track and identify the physical hardware in the container orchestration system;

[0371] The fourth acquisition module is configured to acquire at least one operating system type corresponding to the container orchestration system, wherein the operating system type is a system type supported by the container orchestration system.

[0372] Optional embodiments can refer to the examples shown in the mounting method of the storage volume described above, which will not be repeated here in this example.

[0373] As an optional solution, the device further comprises:

[0374] The first editing module is configured to edit the configuration file of the persistent storage volume after the host information is sent to the storage system through the communication link to make the storage system create the mounting running object;

[0375] The application module is configured to apply the configuration file to the container orchestration system to trigger each node in the container orchestration system to request the storage system to create a respective persistent storage volume according to the definition in the configuration file after the host information is sent to the storage system through the communication link to make the storage system create the mounting running object;

[0376] The mounting module is configured to instruct the storage system to mount the storage volume on the mounting running object in the case that the persistent storage volume is bound to each node in the container orchestration system, thereby providing persistent storage services for the container orchestration system through the persistent storage volume after the host information is sent to the storage system through the communication link to make the storage system create the mounting running object.

[0377] Optional embodiments can refer to the examples shown in the mounting method of the storage volume described above, which will not be repeated here in this example.

[0378] As an optional solution, the first editing module comprises at least one of the following:

[0379] The first adding submodule is configured to add an API version adapted to the persistent storage volume in the configuration file;

[0380] a second adding sub-module configured to add a specified type of a resource corresponding to the persistent storage volume in the configuration file;

[0381] a third adding sub-module configured to add an identity corresponding to the persistent storage volume in the configuration file;

[0382] a fourth adding sub-module configured to add an access mode corresponding to the persistent storage volume in the configuration file;

[0383] a fifth adding sub-module configured to add a requested storage size corresponding to the persistent storage volume in the configuration file;

[0384] a sixth adding sub-module configured to add a requested storage type corresponding to the persistent storage volume in the configuration file.

[0385] Optional embodiments can refer to the examples shown in the above mounting method of the storage volume, which will not be repeated here in this example.

[0386] As an optional solution, the device further comprises:

[0387] a second editing module configured to edit a storage class configuration file according to characteristics of the storage system before editing the configuration file of the persistent storage volume;

[0388] a registration module configured to apply the storage class configuration file to the container orchestration system before editing the configuration file of the persistent storage volume, so as to trigger the container orchestration system to register storage class resources in each node in the container orchestration system according to definitions in the storage class configuration file, wherein the storage class resources are used to determine how to allocate storage resources brought by the persistent storage service for the persistent storage volume.

[0389] Optional embodiments can refer to the examples shown in the above mounting method of the storage volume, which will not be repeated here in this example.

[0390] As an optional solution, the device further comprises:

[0391] a checking unit configured to perform host checking on the container orchestration system at a third time interval to obtain a checking result.

[0392] Optional embodiments can refer to the examples shown in the above mounting method of the storage volume, which will not be repeated here in this example.

[0393] As an optional solution, the checking unit comprises:

[0394] a traversing module configured to traverse all network card ports of the container orchestration system to obtain port information after establishing a communication link between the container orchestration system and the storage system and realizing mounting of the storage volume through the communication link.

[0395] The second disconnecting module is configured to disconnect the communication link between the container orchestration system and the storage system in a case where the port information indicates that the network card port is in the port offline state after establishing the communication link and mounting the storage volume through the communication link.

[0396] The optional embodiment can refer to the examples shown in the above-mentioned mounting method of the storage volume, which will not be described here in this example.

[0397] As an optional solution, the checking unit comprises:

[0398] The sending module is configured to send the corresponding port information to the switch according to the fourth time interval for each of all the network card ports before establishing the communication link between the container orchestration system and the storage system and mounting the storage volume through the communication link, wherein the data link message comprises the port information.

[0399] The optional embodiment can refer to the examples shown in the above-mentioned mounting method of the storage volume, which will not be described here in this example.

[0400] As an optional solution, the device further comprises:

[0401] The fifth obtaining module is configured to obtain the state notification sent by the switch after sending the corresponding port information to the switch according to the fourth time interval for each of all the network card ports, wherein the state notification is used to notify the online state of the storage system.

[0402] The returning module is configured to return the corresponding notification response message of the state notification to the switch after sending the corresponding port information to the switch according to the fourth time interval for each of all the network card ports, wherein the notification response message is used to indicate that the container storage interface driver has received the state notification.

[0403] The optional embodiment can refer to the examples shown in the above-mentioned mounting method of the storage volume, which will not be described here in this example.

[0404] As an optional solution, the device further comprises:

[0405] The editing unit is configured to edit the container group configuration file.

[0406] The application unit is configured to apply the container group configuration file to the container orchestration system to trigger the container orchestration system to apply the container group resource to the container orchestration system according to the definition in the container group configuration file, wherein the container group resource is used to manage one or more containers in the container orchestration system to run on the same node.

[0407] Optional embodiments can refer to the examples shown in the mounting method of the storage volume described above, and this example will not be repeated here.

[0408] As an optional solution, the device further comprises:

[0409] The collection unit is configured to collect the latest host information of the container orchestration system at a fourth time interval after establishing the communication link between the container orchestration system and the storage system and implementing the mounting of the storage volume through the communication link.

[0410] The second sending unit is configured to send the latest host information to the storage system through the communication link after establishing the communication link between the container orchestration system and the storage system and implementing the mounting of the storage volume through the communication link.

[0411] Optional embodiments can refer to the examples shown in the mounting method of the storage volume described above, and this example will not be repeated here.

[0412] It should be noted that each virtual device (module, unit, sub-module, sub-unit, component, etc.) described above can be implemented by software or hardware, and for the latter, the following implementation manners can be used, but are not limited thereto: all the virtual devices are located in the same processor; or each virtual device is located in a different processor in any combination.

[0413] Embodiments of the present application also provide a computer non-volatile readable storage medium, which stores a computer program, wherein the computer program is configured to execute the steps in any of the method embodiments described above when running.

[0414] In an example embodiment, the computer non-volatile readable storage medium described above can include, but is not limited to, a U disk, a read-only memory (ROM), a random access memory (RAM), a mobile hard disk, a magnetic disk or an optical disk, and various media that can store computer programs.

[0415] Embodiments of the present application also provide an electronic device comprising a memory storing a computer program and a processor configured to execute the computer program to perform the steps in any of the method embodiments described above.

[0416] In an example embodiment, the electronic device described above can further comprise a transmission device connected to the processor and an input and output device connected to the processor.

[0417] The specific examples in this embodiment can refer to the examples described in the above embodiments and exemplary embodiments, which will not be repeated here.

[0418] Obviously, those skilled in the art should understand that the virtual devices or steps of the present application described above can be realized by general computing devices, which can be centralized on a single computing device or distributed on a network composed of multiple computing devices, which can be realized by program codes executable by the computing devices, so that they can be stored in storage devices and executed by the computing devices, and in some cases, the steps shown or described can be executed in different order, or they can be respectively manufactured into individual integrated circuit modules, or multiple modules or steps among them can be manufactured into a single integrated circuit module to realize. Thus, the present application is not limited to any specific combination of hardware and software.

[0419] The above only describes optional embodiments of the present application and is not used to limit the present application. For those skilled in the art, the present application can have various modifications and changes. Any modification, equivalent replacement, improvement, etc. within the principles of the present application shall be included in the protection scope of the present application.

Claims

1. A mounting method of a storage volume, characterized by, The method comprises: acquiring a broadcast message sent by a switch, wherein the switch is configured to determine whether a container storage interface driver and a storage system are online by using an intermittent case of a data link message sent by the container storage interface driver and the storage system to the switch at a preset time interval; in a case where the broadcast message indicates that the container storage interface driver is in a first online state and the storage system is in a second online state, establishing a communication link between a container orchestration system and the storage system, and realizing mounting of a storage volume through the communication link.

2. The method of claim 1, wherein, After the acquiring of the broadcast message sent by the switch, the method further comprises: in a case where the broadcast message indicates that the container storage interface driver is in an unavailable state or the storage system is in the unavailable state from an available state, disconnecting the communication link.

3. The method of claim 2, wherein, After the acquiring of the broadcast message sent by the switch, the method further comprises: in a case where the broadcast message indicates that the container storage interface driver is in the available state from the unavailable state, determining that the container storage interface driver is in the first online state; in a case where the broadcast message indicates that the storage system is in the available state from the unavailable state, determining that the storage system is in the second online state.

4. The method of claim 2, wherein, Before the acquiring of the broadcast message sent by the switch, the method further comprises: setting the container storage interface driver to query whether communication is maintained between the container orchestration system and the container storage interface driver at a first time interval; in a case where communication is maintained between the container orchestration system and the container storage interface driver, determining that the container storage interface driver is in the available state; in a case where communication is disconnected between the container orchestration system and the container storage interface driver, determining that the container storage interface driver is in the unavailable state.

5. The method of claim 1, wherein, After the acquiring of the broadcast message sent by the switch, the method further comprises: in a case where the broadcast message indicates that the storage system is updated and the communication link is established, re-establishing the communication link.

6. The method of claim 5, wherein, The re-establishing of the communication link comprises: disconnecting the communication link; acquiring a new broadcast message sent by the switch; in a case where the new broadcast message indicates that the storage system is not updated and is in the second online state, and the container storage interface driver is in the first online state, establishing the communication link.

7. The method of claim 1, wherein, In the process of realizing the mounting of the storage volume through the communication link, the method further comprises: acquiring host information of the container orchestration system at a second time interval; sending the host information to the storage system through the communication link, so that the storage system creates a mounting running object, wherein the mounting running object is an entity server or a virtual machine providing a mounting point of the storage volume.

8. The method of claim 7, wherein, The acquiring of the host information of the container orchestration system comprises at least one of the following: obtaining at least one hostname corresponding to the container orchestration system, wherein the hostname is used to identify each node in the container orchestration system; obtaining at least one serial number corresponding to the container orchestration system, wherein the serial number is used to track and identify the physical hardware in the container orchestration system; obtaining at least one operating system type corresponding to the container orchestration system, wherein the operating system type is a system type supported by the container orchestration system.

9. The method of claim 7, wherein, After the host information is sent to the storage system through the communication link to enable the storage system to create a mounting running object, the method further comprises: editing a configuration file of a persistent storage volume; applying the configuration file to the container orchestration system to trigger each node in the container orchestration system to request the storage system to create a respective persistent storage volume according to the definition in the configuration file; in the case where the persistent storage volume is bound to each node in the container orchestration system, instructing the storage system to mount the storage volume to the mounting running object, thereby providing persistent storage service for the container orchestration system through the persistent storage volume.

10. The method of claim 9, wherein, The editing of the configuration file of the persistent storage volume comprises at least one of the following: adding an application programming interface (API) version adapted to the persistent storage volume in the configuration file; adding a specified type of resource corresponding to the persistent storage volume in the configuration file; adding an identity corresponding to the persistent storage volume in the configuration file; adding an access mode corresponding to the persistent storage volume in the configuration file; adding a requested storage size corresponding to the persistent storage volume in the configuration file; adding a requested storage type corresponding to the persistent storage volume in the configuration file.

11. The method of claim 9, wherein, Before the editing of the configuration file of the persistent storage volume, the method further comprises: editing a storage class configuration file according to the characteristics of the storage system; applying the storage class configuration file to the container orchestration system to trigger the container orchestration system to register storage class resources to each node in the container orchestration system according to the definition in the storage class configuration file, wherein the storage class resources are used to determine how to allocate storage resources brought by the persistent storage service to the persistent storage volume.

12. The method of claim 1, wherein, The method further comprises: performing host checking on the container orchestration system at a third time interval to obtain a checking result.

13. The method of claim 12, wherein, After the communication link between the container orchestration system and the storage system is established and the mounting of the storage volume is realized through the communication link, the performing of the host checking on the container orchestration system at the third time interval to obtain the checking result comprises: traversing all network card ports of the container orchestration system to obtain port information; in the case where the port information indicates that the network card port is in a port offline state, disconnecting the communication link.

14. The method of claim 13, wherein, Before establishing a communication link between the container orchestration system and the storage system, and before mounting the storage volume through the communication link, the container orchestration system is checked at a third time interval to obtain the check results, including: For each of all the network interface card ports, the corresponding port information is sent to the switch at a fourth time interval, wherein the data link message includes the port information.

15. The method of claim 14, wherein, After sending the corresponding port information to the switch for each of all network interface card ports at a fourth time interval, the method further includes: Obtain the status notification sent by the switch, wherein the status notification is used to notify the storage system of its online status; The notification response message corresponding to the status notification is returned to the switch, wherein the notification response message is used to indicate that the container storage interface driver has received the status notification.

16. The method according to any one of claims 1 to 14, characterized in that, The method further includes: Edit the container group configuration file; The container group configuration file is applied to the container orchestration system to trigger the container orchestration system to apply container group resources to the container orchestration system according to the definition in the container group configuration file, wherein the container group resources are used to manage one or more containers in the container orchestration system to run on the same node.

17. The method of any one of claims 1 to 14, wherein, After establishing a communication link between the container orchestration system and the storage system, and mounting the storage volume through the communication link, the method further includes: Collect the latest host information of the container orchestration system at the fourth time interval; The latest host information is sent to the storage system via the communication link.

18. A mounting device for a storage volume, characterized in that, include: The first acquisition unit is configured to acquire broadcast messages sent by the switch, wherein the switch is configured to use the intermittent status of data link messages to determine whether the container storage interface driver and the storage system are online, and the data link messages are messages sent by the container storage interface driver and the storage system to the switch at preset time intervals. The first establishment unit is configured to establish a communication link between the container orchestration system and the storage system when the broadcast message indicates that the container storage interface driver is in a first online state and the storage system is in a second online state, and to mount the storage volume through the communication link.

19. A computer non-volatile readable storage medium, characterized in that, The computer non-volatile readable storage medium stores a computer program, wherein the computer program, when executed by a processor, implements the steps of the method described in any one of claims 1 to 17.

20. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the method described in any one of claims 1 to 17.

Images