Storage volume mounting method and device
By automatically judging the online state of the container storage interface and the online state of the storage system, and establishing a communication link, the problem of cumbersome and low accuracy of the storage volume mounting process is solved, and the efficient and accurate automatic mounting process is achieved.
Patent Information
- Application Number
- CN202411372918.9
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2024-09-29
- Publication Date
- 2025-01-24
- Estimated Expiration
- 2044-09-29
AI Technical Summary
In the prior art, the mount process of storage volumes is complicated, the steps are repeated, and error-prone, resulting in low mount accuracy.
By obtaining the broadcast message sent by the switch, judge the online state of the container storage interface driver and the storage system, and automatically establish the communication link between the container arrangement system and the storage system when meeting the specific online state, so as to realize the automatic mounting of the storage volume. Essence
It improves the accuracy and efficiency of storage volume mounting, reduces human intervention and error rates, and realizes an automated and intelligent mounting process.
Smart Images

Figure CN118900234B_ABST
Abstract
Description
Technical Field
[0001] The embodiments of the present application relate to the computer field, and more specifically, to a method and device for mounting a storage volume. Background Art
[0002] In the storage volume mounting scenario, the storage volume mounting is usually completed manually, which is not only cumbersome and repetitive, but also prone to errors, which leads to the problem of low storage volume mounting accuracy. Therefore, there is a problem of low storage volume mounting accuracy.
[0003] To address the above-mentioned problems, no effective solution has been proposed yet. Summary of the invention
[0004] The embodiments of the present application provide a method and device for mounting a storage volume, so as to at least solve the problem of low accuracy in mounting a storage volume in the related art.
[0005] According to an embodiment of the present application, a method for mounting a storage volume is provided, comprising: obtaining a broadcast message sent by a switch, wherein the switch is configured to use the interruption of a data link message to determine whether a container storage interface driver and a storage system are online, and the data link message is a message sent by the container storage interface driver and the storage system to the switch at a preset time interval; when the broadcast information 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 the container orchestration system and the storage system, and mounting the storage volume through the communication link.
[0006] According to another embodiment of the present application, a storage volume mounting device is provided, comprising: a first acquisition unit, used to acquire a broadcast message sent by a switch, wherein the switch is configured to use the interruption of a data link message to determine whether the container storage interface driver and the storage system are online, and the data link message is a message sent by the container storage interface driver and the storage system to the switch at a preset time interval; a first establishment unit, used to establish a communication link between the container orchestration system and the storage system when the broadcast information 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 achieve the mounting of the storage volume through the communication link.
[0007] In an exemplary embodiment, the apparatus further includes: a disconnection unit, configured to disconnect the communication link after acquiring the broadcast message sent by the switch, if the broadcast information indicates that the container storage interface driver changes from an available state to an unavailable state, or the storage system changes from the available state to the unavailable state.
[0008] In an exemplary embodiment, the apparatus further includes: a first determining unit, configured to determine that the container storage interface driver is in the first online state after the broadcast message sent by the acquisition switch is obtained and when the broadcast information indicates that the container storage interface driver changes from the unavailable state to the available state; and a second determining unit, configured to determine that the storage system is in the second online state after the broadcast message sent by the acquisition switch is obtained and when the broadcast information indicates that the storage system changes from the unavailable state to the available state.
[0009] In an exemplary embodiment, the apparatus further includes: a setting unit, configured to set the container storage interface driver before obtaining the broadcast message sent by the switch, and query whether the container orchestration system and the container storage interface driver maintain communication at a first time interval; a third determining unit, configured to determine that the container storage interface driver is in the available state when the container orchestration system and the container storage interface driver maintain communication before obtaining the broadcast message sent by the switch; and a fourth determining unit, configured to determine that the container storage interface driver is in the unavailable state when the container orchestration system and the container storage interface driver disconnect communication before obtaining the broadcast message sent by the switch.
[0010] In an exemplary embodiment, the apparatus further includes: a second establishing unit, configured to reestablish the communication link after acquiring the broadcast message sent by the switch, if the broadcast information indicates that the storage system is updated and the communication link has been established.
[0011] In an exemplary embodiment, the second establishing unit includes: a first disconnecting module, used to disconnect the communication link; a first acquiring module, used to acquire a new broadcast message sent by the switch; and an establishing module, used to establish 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.
[0012] In an exemplary embodiment, the apparatus further includes: a second acquisition unit, configured to acquire host information of the container orchestration system at a second time interval; and a first sending unit, configured to send the host information to the storage system through the communication link during the process of mounting the storage volume through the communication link, so that the storage system creates a mount running object, wherein the mount running object is a physical server or a virtual machine that provides a mount point for the storage volume.
[0013] In an exemplary embodiment, the second acquisition unit includes at least one of the following: a second acquisition module, used 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 acquisition module, used 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; a fourth acquisition module, used 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.
[0014] In an exemplary embodiment, the device further includes: a first editing module for editing a configuration file of a persistent storage volume after the host information is sent to the storage system through the communication link so that the storage system creates a mount operation object; an application module for applying the configuration file to the container orchestration system so as 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 after the host information is sent to the storage system through the communication link so that the storage system creates a mount operation object; a mounting module for instructing the storage system to mount the storage volume to the mount operation object when 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.
[0015] In an exemplary embodiment, the above-mentioned first editing module includes at least one of the following: a first adding sub-module, used to add the API version adapted by the above-mentioned persistent storage volume in the above-mentioned configuration file; a second adding sub-module, used to add the specified type of resources corresponding to the above-mentioned persistent storage volume in the above-mentioned configuration file; a third adding sub-module, used to add the identity identifier corresponding to the above-mentioned persistent storage volume in the above-mentioned configuration file; a fourth adding sub-module, used to add the access mode corresponding to the above-mentioned persistent storage volume in the above-mentioned configuration file; a fifth adding sub-module, used to add the requested storage size corresponding to the above-mentioned persistent storage volume in the above-mentioned configuration file; and a sixth adding sub-module, used to add the requested storage type corresponding to the above-mentioned persistent storage volume in the above-mentioned configuration file.
[0016] In an exemplary embodiment, the above-mentioned device also includes: a second editing module, used to edit the storage class configuration file according to the characteristics of the above-mentioned storage system before editing the configuration file of the persistent storage volume; a registration module, used to apply the above-mentioned storage class configuration file to the above-mentioned container orchestration system before editing the configuration file of the persistent storage volume, so as to trigger the above-mentioned container orchestration system to register the storage class resources to each node in the above-mentioned container orchestration system according to the definition in the above-mentioned storage class configuration file, wherein the above-mentioned storage class resources are used to determine how to allocate the storage resources brought by the above-mentioned persistent storage service to the above-mentioned persistent storage volume.
[0017] In an exemplary embodiment, the apparatus further includes: an inspection unit, configured to perform a host inspection on the container orchestration system at a third time interval to obtain an inspection result.
[0018] In an exemplary embodiment, the inspection unit includes: a traversal module for traversing all network card ports of the container orchestration system to obtain port information after the communication link between the container orchestration system and the storage system is established and the storage volume is mounted through the communication link; a second disconnection module for disconnecting the communication link when the port information indicates that the network card port is in a port offline state after the communication link between the container orchestration system and the storage system is established and the storage volume is mounted through the communication link.
[0019] In an exemplary embodiment, the inspection unit includes: a sending module, which is used to send the corresponding port information to the switch at a fourth time interval for each of all the network card ports before establishing a 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 includes the port information.
[0020] In an exemplary embodiment, the apparatus further includes: a fifth acquisition module, configured to acquire a status notification sent by the switch after sending the corresponding port information to the switch at a fourth time interval for each of all the network card ports, wherein the status notification is used to notify the online status of the storage system; and a return module, configured to return a notification response message corresponding to the status notification to the switch after sending the corresponding port information to the switch at a 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 status notification.
[0021] In an exemplary embodiment, the apparatus further includes: an editing unit, configured to edit a container group configuration file; and an application 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 a 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.
[0022] In an exemplary embodiment, the apparatus further includes: a collecting unit, configured to collect the latest host information of the container orchestration system at a fourth time interval after a communication link is established between the container orchestration system and the storage system and a storage volume is mounted through the communication link; and a second sending unit, configured to send the latest host information to the storage system through the communication link after a communication link is established between the container orchestration system and the storage system and a storage volume is mounted through the communication link.
[0023] According to another embodiment of the present application, a computer-readable storage medium is provided, in which a computer program is stored, wherein the computer program is configured to execute the steps of any one of the above method embodiments when running.
[0024] According to another embodiment of the present application, an electronic device is provided, including a memory and a processor, wherein the memory stores a computer program, and the processor is configured to run the computer program to execute the steps in any one of the above method embodiments.
[0025] In the storage volume mounting scenario, the traditional manual mounting method is not only cumbersome but also error-prone, which directly affects the accuracy of storage volume mounting. In order to solve this problem, the present application significantly improves the mounting accuracy through automated and intelligent means.
[0026] First, the present application utilizes the broadcast messages sent by the switch to determine the online status of the container storage interface driver and the storage system. This is achieved by monitoring the discontinuity of data link messages, which are sent to the switch by the container storage interface driver and the storage system at preset time intervals. The advantage of this method is that it can reflect the online status of the storage interface driver and the storage system in real time and accurately, avoiding the tediousness and inaccuracy of manual inspection.
[0027] Secondly, when the broadcast information indicates that the container storage interface driver and the storage system are both online, the application will automatically establish 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.
[0028] Finally, through the automatically established communication link, the present application realizes the automatic mounting of storage volumes. The automation and intelligence of this process greatly improves the accuracy of mounting because 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.
[0029] In summary, the real-time monitoring of online status, automatic establishment of communication links and automatic mounting of the present 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. BRIEF DESCRIPTION OF THE DRAWINGS
[0030] Figure 1 is a schematic diagram of an application environment of a method for mounting a storage volume according to an embodiment of the present application;
[0031] Figure 2 is a flowchart of a method for mounting a storage volume according to an embodiment of the present application;
[0032] Figure 3 is a schematic diagram of a method for mounting a storage volume according to an embodiment of the present application;
[0033] Figure 4 is a schematic diagram of a method for mounting a storage volume according to an embodiment of the present application;
[0034] Figure 5 It is a structural block diagram of a storage volume mounting device according to an embodiment of the present application. DETAILED DESCRIPTION
[0035] The embodiments of the present application will be described in detail below with reference to the accompanying drawings and in combination with the embodiments.
[0036] It should be noted that the terms "first", "second", etc. in the specification and claims of this application and the above-mentioned drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence.
[0037] The method embodiments provided in the embodiments of the present application can be executed in a server device or a similar computing device. Taking running on a server device as an example, Figure 1 1 is a hardware structure block diagram of a server device of a method for mounting a storage volume in an embodiment of the present application. Figure 1 As shown, the server device may include one or more ( Figure 1Only one is shown in the figure) a processor 102 (the processor 102 may include but is not limited to a processing device such as a microprocessor MCU or a programmable logic device FPGA) and a memory 104 for storing data, wherein the above-mentioned server device may also include a transmission device 106 and an input / output device 108 for communication functions. It can be understood by those skilled in the art that Figure 1 The structure shown is only for illustration and does not limit the structure of the above server device. Figure 1 More or fewer components as shown, or with Figure 1 Different configurations are shown.
[0038] The memory 104 can be used to store computer programs, for example, software programs and modules of application software, such as the computer program corresponding to the method for mounting a storage volume in the embodiment of the present application. The processor 102 executes various functional applications and data processing by running the computer program stored in the memory 104, that is, to implement the above method. The memory 104 may include a high-speed random access memory, and may also include a non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 104 may further include a memory remotely arranged relative to the processor 102, and these remote memories may be connected to the server device via a network. Examples of the above-mentioned network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.
[0039] The transmission device 106 is used to receive or send data via a network. The specific example of the above network may include a wireless network provided by a communication provider of the server device. In one example, the transmission device 106 includes a network adapter (Network Interface Controller, referred to as NIC), which can be connected to other network devices through a base station so as to communicate with the Internet. In one example, the transmission device 106 can be a radio frequency (RF) module, which is used to communicate with the Internet wirelessly.
[0040] In this embodiment, a method for mounting a storage volume is provided. Figure 2 is a flowchart of a method for mounting a storage volume according to an embodiment of the present application, such as Figure 2 As shown, the process includes the following steps:
[0041] Step S202, obtaining a broadcast message sent by the switch, wherein the switch is configured to use the interruption of a data link message to determine whether the container storage interface driver and the storage system are online, and the data link message is a message sent by the container storage interface driver and the storage system to the switch at a preset time interval;
[0042] Optionally, this embodiment describes a system mechanism in which the switch is responsible for monitoring and obtaining data link messages sent by the container storage interface driver and the storage system. These data link messages are sent at preset time intervals. The switch determines whether the container storage interface driver and the storage system are online by observing the interruption of these data link messages (i.e., whether the messages are received on time).
[0043] In an exemplary embodiment, a data link message refers to a data packet periodically sent by a container storage interface driver and a storage system to indicate its online status. Intermittency refers to whether a data link message arrives on time according to a preset time interval. If there is a delay or a missing message, it is considered "intermittent".
[0044] Assume that the container storage interface driver and 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 (container storage interface driver or storage system) may be offline.
[0045] Step S204: When the broadcast information 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 is established between the container orchestration system and the storage system, and the storage volume is mounted through the communication link.
[0046] Optionally, this embodiment describes an automated process, that is, when the broadcast information sent by the switch indicates that the container storage interface driver and the storage system are both online, 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 mount the storage volume through this link without manual intervention.
[0047] 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 communicate and transmit data normally. The communication link refers to the connection path for data transmission and communication between the container orchestration system and the storage system. 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.
[0048] Assume that there is a container orchestration system that is managing multiple container applications that need to access data stored in an external storage system. When the switch broadcasts information indicating that the storage interface driver and the storage system are both online, the container orchestration system automatically establishes a communication link with the storage system. Once the link is established successfully, the container orchestration system can automatically mount the required storage volumes, allowing the container application to seamlessly access the data.
[0049] Through the above steps, first, the present application uses the broadcast message sent by the switch to determine the online status of the container storage interface driver and the storage system. This is achieved by monitoring the discontinuity of the data link message, which is sent to the switch by the container storage interface driver and the storage system at a preset time interval. The advantage of this method is that it can reflect the online status of the storage interface driver and the storage system in real time and accurately, avoiding the tediousness and inaccuracy of manual inspection.
[0050] Secondly, when the broadcast information indicates that the container storage interface driver and the storage system are both online, the application will automatically establish 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.
[0051] Finally, through the automatically established communication link, the present application realizes the automatic mounting of storage volumes. The automation and intelligence of this process greatly improves the accuracy of mounting because 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.
[0052] In summary, the real-time monitoring of online status, automatic establishment of communication links and automatic mounting of the present 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.
[0053] The execution subject of the above steps may be a server, a terminal, etc., but is not limited thereto.
[0054] The execution order of step S202 and step S204 is interchangeable, that is, step S204 may be executed first, and then step S202.
[0055] As an optional solution, after obtaining the broadcast message sent by the switch, the method further includes:
[0056] When the broadcast information 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.
[0057] In an optional embodiment, the available state refers to a state in which the container storage interface driver or storage system can work normally and respond to requests; while the unavailable state means that these components cannot work normally or respond to requests due to some reason (such as failure, maintenance, etc.).
[0058] Disconnecting the communication link: This refers to terminating or interrupting the established communication connection between the container orchestration system and the storage system to ensure that erroneous data transmission or operations do not occur when the component is unavailable.
[0059] It should be noted that this embodiment describes a system response mechanism. After obtaining the broadcast message sent by the switch, the system will determine the status of the container storage interface driver and the storage system based on these messages. If the broadcast information indicates that any component has changed 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.
[0060] This automatic disconnection mechanism is an important part of the robustness and fault tolerance design of the system. By responding to changes in component status in a timely manner, the system can take quick action when a failure occurs, thereby minimizing the impact of the failure on the overall system operation. In addition, this mechanism can be combined with other fault recovery and backup strategies to achieve a higher level of system reliability and stability.
[0061] To further illustrate, let's assume that in a cloud computing environment, a container orchestration system is interacting with a storage system. Suddenly, a broadcast message sent by a switch shows that the storage system has changed from an available state to an unavailable state due to a hardware failure. Based on this information, the container orchestration system automatically disconnects the communication link with the storage system to avoid data loss or system crash caused by continuing to try to communicate with the failed storage system.
[0062] The automatic disconnection mechanism provided by the present application can significantly improve the robustness and fault tolerance of the system. When a key component fails or is unavailable, the system can respond quickly and disconnect the communication link with the failed component, thereby avoiding potential data corruption or system crash risks. At the same time, this also provides administrators with more time to diagnose and fix problems without having to worry about further data loss or system instability during the failure.
[0063] As an optional solution, after obtaining the broadcast message sent by the switch, the method further includes:
[0064] S1-1, when the broadcast information indicates that the container storage interface driver changes from an unavailable state to an available state, determining that the container storage interface driver is in a first online state;
[0065] S1-2: When the broadcast information indicates that the storage system changes from an unavailable state to an available state, determine that the storage system is in a second online state.
[0066] In an optional embodiment, 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 for some reason; while the available state means that the component has recovered and can work normally and respond to requests. The first online state specifically refers to a state in which the container storage interface driver is determined to be online; the second online state specifically refers to a state in which the storage system is determined to be online.
[0067] It should be noted that this embodiment describes how the system determines the online status of the container storage interface driver and the storage system based on the broadcast messages sent by the switch after receiving the broadcast messages. Specifically, when the broadcast information indicates that the container storage interface driver or the storage system has recovered from an unavailable state to an available state, the system will determine that they are online accordingly.
[0068] Real-time monitoring and judgment of this status is crucial to ensure the continuity and high availability of the system. By capturing changes in component status in a timely manner, the system can respond quickly, such as reestablishing communication links and restoring data transmission, thereby minimizing service interruption time caused by component failure.
[0069] To further illustrate, it is optional to assume that previously due to a network failure, both the container storage interface driver and the storage system were in an unavailable state. Now, the network failure has been repaired, and the broadcast messages sent by the switch begin to reflect the state changes of these two components. When the system receives a broadcast message indicating that the container storage interface driver has changed from an unavailable state to an available state, it determines that the container storage interface driver is in a first online state; similarly, when receiving a broadcast message indicating that the storage system has changed state, it determines that the storage system is in a second online state.
[0070] Through the embodiments of the present application, the system's response speed to component status changes is improved, ensuring that the system can return to normal working state in the shortest possible time. Secondly, by real-time monitoring and judging the online status of components, the system can more accurately grasp the operating status of the entire system and provide valuable operation and maintenance information to administrators. Finally, this mechanism also helps to improve the overall stability and reliability of the system, because the system can quickly make adjustments when the component status changes, thereby avoiding potential problems and failures.
[0071] As an optional solution, before obtaining the broadcast message sent by the switch, the method further includes:
[0072] S2-1, setting a container storage interface driver, and querying whether the container orchestration system and the container storage interface driver maintain communication at a first time interval;
[0073] S2-2, while the container orchestration system and the container storage interface driver maintain communication, determine that the container storage interface driver is in an available state;
[0074] S2-3: When the communication between the container orchestration system and the container storage interface driver is disconnected, determine that the container storage interface driver is in an unavailable state.
[0075] In an optional embodiment, 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.
[0076] Maintaining communication and disconnecting communication: Maintaining communication means that the connection between the container storage interface driver and the container orchestration system is active and data exchange can be carried out normally; while disconnecting communication means that the connection between the two has been interrupted and data exchange cannot be carried out.
[0077] Available state and unavailable state: The available state refers to the state in which the container storage interface driver is determined to be able to work normally and maintain communication with the container orchestration system; the unavailable state refers to the state in which the container storage interface driver cannot maintain communication with the container orchestration system for some reason.
[0078] It should be noted that this embodiment describes how the system sets and determines the availability status of the container storage interface driver before obtaining the broadcast message sent by the switch. Specifically, the system allows the container storage interface driver to query the communication status with the container orchestration system at a set time interval (first time interval), thereby determining whether the container storage interface driver is in an available state or an unavailable state based on whether the communication is maintained.
[0079] This regular self-checking mechanism is part of the system's robustness design. By allowing components to proactively check their own working status and the communication status with other components, the system can detect and handle potential problems at an early stage, thus preventing problems from accumulating to a serious level and causing system crashes or data loss. In addition, this mechanism can be combined with other monitoring and alarm systems to provide a more comprehensive view of the system's operating status.
[0080] For further example, it is optional to assume that the system is set to query the communication status between the container storage interface driver and the container orchestration system once every 5 seconds. If the connection between the two is found to be normal during a query, the system will determine that the container storage interface driver is in an available state; conversely, if the connection is found to be disconnected, the system will determine that it is in an unavailable state.
[0081] The regular self-inspection and status judgment mechanism of this application can significantly improve the reliability and stability of the system. First, it can help the system promptly detect and handle communication problems between the container storage interface driver and the container orchestration system, thereby reducing the risk of service interruption or data loss due to communication failures. Secondly, by continuously monitoring the status of components, the system can more accurately grasp the operating status of the entire system and provide administrators with valuable operation and maintenance information and troubleshooting clues. Finally, this mechanism also helps to improve the self-healing ability of the system, because once a problem is detected, the system can respond quickly and try to return to normal working state.
[0082] As an optional solution, after obtaining the broadcast message sent by the switch, the method further includes:
[0083] When the broadcast information indicates that the storage system is updated and the communication link has been established, the communication link is reestablished.
[0084] In an optional embodiment, an update of the storage system refers to some form of change to the storage system, which may be an upgrade of the software version, modification of the configuration file, replacement of the hardware device, etc. These changes may affect the communication method and compatibility between the storage system and external components.
[0085] The communication link is established: This means that before the storage system is updated, a connection for data transmission and communication has been successfully established between the container orchestration system and the storage system.
[0086] Reestablishing the communication link: When confirming that the storage system has been updated and the original communication link exists, the system will close or disconnect the current communication link and recreate a new communication link according to the latest configuration or requirements.
[0087] It should be noted that this embodiment describes that under certain conditions, the system needs to re-establish an existing communication link. Specifically, when the system obtains broadcast messages sent by the switch, and these messages indicate that the storage system has been updated, and the current communication link is already established, the system will perform the operation of re-establishing the communication link.
[0088] This mechanism of reestablishing communication links after a storage system update is a manifestation of system flexibility and adaptability. It allows the system to smoothly transition to new configurations or protocols without interrupting service, thereby maintaining compatibility with the changing storage environment. In addition, this mechanism can be combined with automated error detection and recovery strategies to reduce the impact of potential failures caused by updates on the system.
[0089] As an example, let's 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 undergoes a software upgrade, introducing some new features and communication protocols. The broadcast message sent by the switch captures this change and notifies the container orchestration system. To ensure smooth communication and data integrity, the container orchestration system disconnects the existing communication link and re-establishes a communication link that complies with the new protocol requirements based on the new configuration of the storage system after the upgrade.
[0090] The effect of re-establishing the communication link in the embodiment of the present application is mainly reflected 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 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 about by the storage system upgrade. Finally, this mechanism improves the overall reliability and maintainability of the system and reduces the operation and maintenance costs and risks caused by the storage system update.
[0091] As an optional solution, reestablish the communication link, including:
[0092] S3-1, disconnect the communication link;
[0093] S3-2, obtain the new broadcast message sent by the switch;
[0094] S3-3, establishing a 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.
[0095] In an optional embodiment, disconnecting the communication link refers to the system actively terminating the existing communication connection between the container orchestration system and the storage system.
[0096] New broadcast message: A message sent by a switch after the communication link is disconnected, containing the latest status information of the storage system and container storage interface driver.
[0097] Second online state: specifically refers to the state in which the storage system is confirmed to be online and available by broadcast messages.
[0098] First online state: specifically refers to the state in which the container storage interface driver is confirmed to be online and available by a broadcast message.
[0099] Establishing a communication link: After certain conditions are met (such as the storage system and the container storage interface driver are both online), the system re-establishes the communication connection between the container orchestration system and the storage system.
[0100] It should be noted that this embodiment describes the specific steps and conditions for "reestablishing a communication link". First, the system disconnects the current communication link. Then, the system obtains a new broadcast message sent by the switch to understand the latest status 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 establishes a new communication link.
[0101] This mechanism ensures that the system can safely and effectively restore communication after updates or changes. By disconnecting the old communication link and establishing a new link based on the latest state information, the system can avoid communication failures caused by inconsistent state or outdated configuration. In addition, this step-by-step approach also provides the possibility of additional checks or verifications before re-establishing communication, further enhancing the robustness and reliability of the system.
[0102] As a further example, consider a cloud storage environment where the container orchestration system needs to maintain continuous communication with the storage system. Due to a software update to the storage system, the system decides to reestablish the communication link. First, the system disconnects the existing connection. Then, it listens for new broadcast messages from the switch. When these messages indicate that the storage system has completed the update and is online, and the container storage interface driver is also online, the system reestablishes the communication link between the two according to the latest configuration parameters.
[0103] Through the embodiments of the present application, it is ensured that the system can quickly and accurately restore communication capabilities after undergoing changes (such as updates), thereby reducing the possibility of service interruptions. Secondly, by establishing a new communication link based on the latest broadcast message, the system can ensure that both parties in communication are in an optimal and consistent state, which helps to improve the efficiency and accuracy of data transmission. Finally, this mechanism also enhances the system's self-repair and adaptability, enabling it to maintain high availability and stability in a dynamically changing environment.
[0104] As an optional solution, in the process of mounting the storage volume through the communication link, the method further includes:
[0105] S4-1, obtaining host information of the container orchestration system at a second time interval;
[0106] S4-2, sending the host information to the storage system through the communication link, so that the storage system creates a mount operation object, wherein the mount operation object is a physical server or virtual machine that provides a mount point for the storage volume.
[0107] In an optional embodiment, the second time interval refers to a time period set by the system and is used to determine the frequency of obtaining the host information of the container orchestration system.
[0108] Host information: This 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 the IP address, host name, operating system type, etc. This information is necessary for the storage system to create a mount running object.
[0109] Mount run object: A logical entity created in the storage system that represents 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 run object.
[0110] It should be noted that this embodiment describes how the system interacts with the storage system to create a mount running object in the process of implementing storage volume mounting through a communication link. Specifically, the system obtains the 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. After receiving this information, the storage system will create mount running objects based on it. These objects represent the physical server or virtual machine that provides the storage volume mount point.
[0111] This mechanism of regularly obtaining and updating host information and interacting with the storage system to create mounted 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 to changes in host status in a timely manner, such as changes in IP addresses, increases and decreases in resources, etc., thereby ensuring the reliability and flexibility of storage volume mounting.
[0112] As an example, let's assume that in a cloud environment, a container orchestration system needs to mount a storage volume for use by the containers it manages. Every 30 seconds (the second time interval), the system obtains the latest information about the host where the container orchestration system is located, such as changes in the IP address, updates to the operating system, and so on. Then, through the communication link that has been established with the storage system, this host information is sent to the storage system. Based on this information, the storage system creates a mount run object, which represents the server that actually provides the mount point. When the container needs to access the storage volume, it will do so through this mount run object.
[0113] By acquiring and updating host information at the second time interval, and interacting with the storage system to create a mount operation object, the system achieves the following improvements: First, the accuracy and timeliness of storage volume mounting are improved, because the system always performs mounting operations based on the latest host information. Second, the system's dynamic adaptability is enhanced, allowing the system to quickly adjust when the host status changes to ensure service continuity. Finally, this mechanism also helps to improve the resource utilization efficiency and convenience of operation and maintenance management of the entire cloud environment.
[0114] As an optional solution, obtaining host information of the container orchestration system includes at least one of the following:
[0115] Obtain at least one host name corresponding to the container orchestration system, where the host name is used to identify each node in the container orchestration system;
[0116] Obtain 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;
[0117] At least one operating system type corresponding to the container orchestration system is obtained, where the operating system type is a system type supported by the container orchestration system.
[0118] In an optional embodiment, host name: In a computer network, a host name is a name used to identify a specific computer or network device. In this embodiment, it specifically refers to the name used to identify each node in the container orchestration system.
[0119] Serial number: Typically a unique code that is used to identify and track a specific piece of physical hardware. In the context of a container orchestration system, serial numbers are used to identify and track physical hardware components in the system.
[0120] Operating system type: refers to the type or version of the operating system running on the container orchestration system. This helps to understand the functions and compatibility supported by the system.
[0121] It should be noted that this embodiment describes the specific aspects of obtaining the host information of the container orchestration system. In the process of obtaining the host information, the system will obtain at least one of the following information: the host name corresponding to the container orchestration system (used to identify each node in the system), the serial number (used to track and identify the physical hardware in the system), and the operating system type (indicating the system type supported by the container orchestration system).
[0122] Obtaining this host information is crucial for the management and operation of the container orchestration system. By knowing the host name 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, this information can also be used for security verification, logging, and performance monitoring.
[0123] To further illustrate, optionally obtaining the host name: suppose a container orchestration system manages multiple nodes, each of which has a unique host name, such as "node1", "node2", etc. The system identifies and manages each node by obtaining these host names.
[0124] Get serial number: If the container orchestration system runs on a specific physical server, each server has a unique serial number. The system can track and identify the hardware information of each server by obtaining these serial numbers.
[0125] Obtaining the operating system type: For example, a container orchestration system may run on Linux, Windows, or another type of operating system. The system obtains this information to ensure compatibility and correct functional implementation.
[0126] By obtaining the host information of the container orchestration system, the system can achieve the following effects: First, the manageability and visibility of the system are improved, and administrators can more easily identify and track the various components in the system. Second, the stability and reliability of the system are enhanced, because 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, because the system can implement more sophisticated access control and audit policies based on this information.
[0127] As an optional solution, after sending the host information to the storage system through the communication link so that the storage system creates the mount operation object, the method further includes:
[0128] S5-1, edit the configuration file of the persistent storage volume;
[0129] 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 its corresponding persistent storage volume according to the definition in the configuration file;
[0130] S5-3, when the persistent storage volume is bound to each node in the container orchestration system, instruct the storage system to mount the storage volume to the mount running object, thereby providing persistent storage services for the container orchestration system through the persistent storage volume.
[0131] In an optional embodiment, a persistent storage volume is a storage resource used in a container orchestration system that can persist data so that the data will not be lost even if the container is deleted or restarted.
[0132] Configuration file: A file that contains configuration information related to the persistent storage volume, such as the size, type, and access permissions of the storage volume.
[0133] Binding: refers to establishing an association between a persistent storage volume and a node in the container orchestration system to ensure that each node can access its corresponding storage volume.
[0134] It should be noted that after the host information is sent to the storage system and it creates a mount running object, this embodiment also includes a series of steps to configure and apply persistent storage volumes. First, you need to edit the configuration file of the persistent storage volume, which defines the various properties and parameters of the storage volume. Next, apply this configuration file to the container orchestration system, which will trigger each node 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 each node 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 services for the container orchestration system.
[0135] By editing the configuration file, you can easily change the properties of the storage volume or add a new storage volume. In addition, since the storage volume is bound to the node of the container orchestration system, it can ensure that each node has its dedicated storage space, thereby improving data security and isolation.
[0136] To further illustrate, optionally assume that a Kubernetes cluster needs to configure persistent storage volumes to save important data. First, the administrator will edit a configuration file to specify the size of the storage volume as 100GB and the type as NFS (Network File System). Then, this configuration file will be applied to the Kubernetes cluster. When each node in the cluster starts, it will request the storage system to create a 100GB NFS storage volume according to this configuration file. When these storage volumes are successfully bound to each node, the storage system will mount them to the mount run object previously created 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.
[0137] By editing and applying the configuration file of the persistent storage volume and mounting the storage volume to the mounted running object, this embodiment achieves the following effects: First, it ensures the persistence of data, and data will not be lost even if the container is 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, allowing administrators to easily adjust the properties of the storage volume or add new storage volumes as needed.
[0138] As an optional solution, edit the configuration file of the persistent storage volume, including at least one of the following:
[0139] Add the API version adapted for the persistent storage volume in the configuration file;
[0140] Add the specified type of resources corresponding to the persistent storage volume in the configuration file;
[0141] Add the identity of the persistent storage volume to the configuration file;
[0142] Add the access mode corresponding to the persistent storage volume in the configuration file;
[0143] Add the requested storage size corresponding to the persistent storage volume in the configuration file;
[0144] Add the requested storage type corresponding to the persistent storage volume in the configuration file.
[0145] In an optional embodiment, 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.
[0146] Specified type of resource: refers to the resource type represented by the storage volume, such as disk, network storage, etc. This helps the system classify and manage storage resources.
[0147] Identity: It is a unique identifier of a storage volume and is used to accurately identify and track the storage volume in the system.
[0148] Access mode: defines how a storage volume can be accessed, such as read-only, read-write, etc., which ensures the data security and consistency of the storage volume.
[0149] Requested storage size: refers to the storage space allocated for the storage volume, which is determined based on application requirements.
[0150] Requested storage type: refers to the type of storage technology used by the storage volume, such as SSD, HDD, etc. Different types of storage technologies have different performance and cost characteristics.
[0151] It should be noted that editing the configuration file of a persistent storage volume involves several key steps, including at least adding the API version that the persistent storage volume is adapted to, the specified type of resource, the identity, the access mode, the requested storage size, and the requested 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 policies.
[0152] 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 with application requirements. In addition, with the continuous development of container technology and cloud-native applications, the flexibility and scalability of configuration files are becoming increasingly important to adapt to changing business needs and technical environments.
[0153] To further illustrate, optionally in a Kubernetes environment, editing the configuration file of a persistent storage volume (such as PersistentVolume, PV for short) may involve the following operations: Specify apiVersion as v1 in the configuration file, indicating that the first version of the Kubernetes API is used to manage PV. Set the kind field to PersistentVolume to indicate that this is a persistent storage volume resource. Assign a unique name to PV as its identity. Define the access mode of PV through the accessModes field. For example, setting it to ReadWriteOnce means that PV can only be mounted in read-write mode by one node. Use the resources.requests.storage field to specify the requested storage size, such as 10Gi for 10 gigabytes. Specify the storage type in the storageClassName field, such as standard or ssd, to select storage backends with different performance.
[0154] By editing the persistent storage volume configuration file and including the above key information, you can achieve the following effects:
[0155] Compatibility guarantee: By specifying the API version, the compatibility and stability of storage volumes and container orchestration systems are ensured.
[0156] Resource management optimization: The specified types of resources help the system to more effectively classify and manage different types of storage resources.
[0157] Accurate identification and tracking: Identification enables storage volumes to be uniquely and accurately identified and tracked in the system.
[0158] Improved data security: The access mode restricts the access method of the storage volume, thereby enhancing the security and consistency protection of data.
[0159] Flexible resource allocation: The requested storage size and type are configured according to actual needs, achieving flexible allocation and efficient use of storage resources.
[0160] As an optional solution, before editing the configuration file of the persistent storage volume, the method further includes:
[0161] S6-1, edit the storage class configuration file according to the characteristics of the storage system;
[0162] 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, where 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.
[0163] In an optional embodiment, a storage class profile is a storage system-specific profile that defines how to create, manage, and allocate storage resources. This typically includes the type of storage, performance parameters, and reclaim policies.
[0164] Storage class resources: In container orchestration systems, this is an abstract resource type that represents a certain service capability or feature of a storage system. Storage class resources are used to dynamically allocate actual storage resources for persistent storage volumes.
[0165] It should be noted that before editing the configuration file of the persistent storage volume, a key step is required: edit the storage class configuration file according to the characteristics of the storage system and apply it to the container orchestration system. The purpose of this is to trigger the container orchestration system to register 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 storage resources provided by the persistent storage service to the persistent storage volume.
[0166] The editing and application of storage class configuration files is an important part of cloud native storage management. By defining different storage classes, administrators can flexibly meet the different storage requirements of various applications, 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.
[0167] To further illustrate, in the Kubernetes environment, a storage class is a 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 (PV) needs to be dynamically created, Kubernetes will automatically allocate and manage the actual storage resources according to the definition of StorageClass.
[0168] By editing and applying the storage class configuration file, the embodiments of the present application achieve the following effects:
[0169] Enhanced flexibility: Administrators can define different storage classes based on the characteristics of the storage system and application requirements, thereby flexibly managing and allocating storage resources.
[0170] Dynamic resource management: Storage resources support dynamic volume allocation, making the creation, allocation, and recycling of storage resources more automated and efficient.
[0171] Improved resource utilization: By properly configuring storage classes, you can avoid wasting storage resources and improve resource utilization.
[0172] Simplify management complexity: The abstraction of storage classes allows administrators to manage storage resources at a higher level, reducing management complexity and workload.
[0173] As an optional solution, the method further includes:
[0174] At the third time interval, a host check is performed on the container orchestration system to obtain an inspection result.
[0175] In an optional embodiment, the third time interval refers to the time period for performing host inspection, which can be minutes, hours, days, etc., and is set according to actual needs and security policies.
[0176] Host check: Check the status and health of the host where the container orchestration system is located, including but not limited to CPU usage, memory usage, disk space, network connection, etc.
[0177] Inspection results: The conclusions drawn after the host inspection is completed, usually including information such as the host's operating status, existing problems or potential risks.
[0178] It should be noted that this embodiment also includes a regular host check step, that is, according to the set third time interval, the host of the container orchestration system is checked and the check result is obtained. The purpose of this step is to ensure that the host of the container orchestration system is in a healthy state and can operate normally and provide services.
[0179] Host checking 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 resolved in a timely manner, thus avoiding system crashes or service interruptions. In addition, host checking can also help administrators understand the operating status of the system and provide a basis for optimizing resource allocation and performance tuning.
[0180] To further illustrate, it is optional to assume that Kubernetes is used as the container orchestration system in this embodiment, and a host check is performed every hour (the third time interval is 1 hour). The content 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 will generate an inspection result report, listing the status of all inspection items and possible problems, such as "the CPU usage of node A exceeds 80%, and there may be a performance bottleneck", etc.
[0181] By performing host checks on the container orchestration system at the third time interval, this embodiment achieves the following effects:
[0182] Discover and solve problems in a timely manner: Regular inspections can help administrators discover problems or potential risks in the host in a timely manner and take appropriate measures to solve them, thereby ensuring the stable operation of the system.
[0183] Improve system availability: Host checks can prevent or reduce service interruptions or performance degradation caused by host failures, thereby improving system availability and user experience.
[0184] Optimize resource configuration: Based on the inspection results, the administrator can understand the resource usage of the host and then optimize resource configuration to improve resource utilization and system performance.
[0185] As an optional solution, after establishing a communication link between the container orchestration system and the storage system and implementing the mounting of the storage volume through the communication link, a host check is performed on the container orchestration system at a third time interval to obtain the check result, including:
[0186] S7-1, traverse all network card ports of the container orchestration system to obtain port information;
[0187] S7-2, when the port information indicates that the network card port is in a port offline state, disconnect the communication link.
[0188] In an optional embodiment, network card port: a physical or logical port on a network interface card (NIC) used for transmission of network data.
[0189] Port offline status: The state where the network card port cannot transmit data due to failure, disconnection or other reasons.
[0190] Disconnect communication link: Terminate or disconnect a previously established communication connection to prevent further data transmission.
[0191] It should be noted that after the communication link between the container orchestration system and the storage system is established and the storage volume is mounted through this communication link, the system will perform a host check on the container orchestration system at the set third time interval. During this check, the system will traverse all network card ports of the container orchestration system to obtain port information. If the port information of a network card port is displayed as offline, the system will disconnect the communication link associated with the network card port.
[0192] This regular inspection mechanism is an important measure to ensure system stability and reliability. By monitoring the status of the network card port, the system can promptly detect network connection problems and take appropriate remedial measures. In cloud-native environments and distributed systems, the stability and reliability of network communications are crucial because they directly affect service availability and data consistency.
[0193] To further illustrate, let's assume that there is a container orchestration system based on Kubernetes, which has established a communication link with a distributed storage system. During the operation of the system, Kubernetes will perform host checks at set intervals (such as every hour). During the check, Kubernetes will traverse the network card ports of all its nodes. If a specific network card port of a node is found to be offline (for example, because the network cable is unplugged or the network interface fails), Kubernetes will disconnect the communication link related to the port to avoid data loss or communication errors.
[0194] By performing host checks on the container orchestration system at the third time interval and paying special attention to the status of the network card port, the embodiment of the present application achieves the following effects:
[0195] Improve system stability: By promptly detecting and handling the offline status of the network card port, the risk of service interruption or data loss caused by network problems is reduced.
[0196] Enhanced fault recovery capability: Once a port is detected to be offline, the system can quickly disconnect the problematic communication link, creating conditions for subsequent troubleshooting and recovery.
[0197] Optimize resource utilization: Avoid wasting resources on invalid or unreliable communication links, and improve the resource utilization efficiency of the overall system.
[0198] As an optional solution, before establishing a communication link between the container orchestration system and the storage system and implementing the mounting of the storage volume through the communication link, a host check is performed on the container orchestration system at a third time interval to obtain the check result, including:
[0199] For each of all the network card ports, corresponding port information is sent to the switch at a fourth time interval, wherein the data link message includes the port information.
[0200] In an optional embodiment, the fourth time interval refers to the frequency at which the system sends port information to the switch, and can be adjusted according to the network environment and system requirements.
[0201] Port information: Detailed data about the network card port, which may include port status, speed, connection type, etc.
[0202] Data link message: In network communications, a formatted data unit used to transmit information at the data link layer, specifically a message containing port information.
[0203] 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 regular host check process. In this process, the system sends the port information of each port to the switch for all network card ports according to the set fourth time interval. The "data link message" mentioned here contains this port information.
[0204] This mechanism of sending port information periodically 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 configurations in real time. By sending data link messages containing port information, the system can manage network resources more effectively and prevent potential network problems.
[0205] To further illustrate, in a large cloud environment, the administrator is preparing to deploy a new container orchestration system and plans to connect it to the existing storage system. Prior to this, in order to ensure smooth network communication, the system will regularly check the status of the network card ports of all nodes. For example, every 30 seconds (fourth time interval) the system will collect detailed information for each port, encapsulate this information in a data link message, and send it 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 for flow control and fault prevention.
[0206] Through the embodiment of the present application, the method of sending the port information to the switch at the fourth time interval achieves the following effects:
[0207] Real-time monitoring: The system can monitor the status of all network card ports in real time, and promptly detect and resolve potential network problems.
[0208] Fault prevention: By regularly updating port information in the switch, the system can take preventive measures before network failures occur, reducing the possibility of service interruptions.
[0209] Optimize network management: This mechanism provides network administrators with more detailed and timely data, helping them to manage network resources more effectively and improve the overall performance and reliability of the network.
[0210] As an optional solution, after sending corresponding port information to the switch at a fourth time interval for each of all the network card ports, the method further includes:
[0211] S8-1, obtaining a status notification sent by the switch, wherein the status notification is used to notify the online status of the storage system;
[0212] S8-2, returning a notification response message corresponding to the status notification to the switch, wherein the notification response message is used to indicate that the container storage interface driver has received the status notification.
[0213] In an optional embodiment, status notification: a message sent by a switch to notify the system about the online or offline status of a storage system or other network device.
[0214] Notification response message: A response message sent by the system after receiving a status notification, used to confirm that the notification has been received.
[0215] 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.
[0216] It should be noted that after regularly sending the information of each network card port to the switch, this embodiment also includes the step of receiving status notifications from the switch. These status notifications are used to inform the online status 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 status notifications.
[0217] This mechanism ensures that the system can respond quickly and accurately to changes in the status of the network or storage device. By receiving and processing status 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 reestablishing a communication link.
[0218] To further illustrate, 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 sends a status notification to the container orchestration system. After receiving this notification, the container orchestration system sends a notification response message back to the switch through the container storage interface driver to confirm that it has known the current status of the storage system.
[0219] By receiving the status notification of the switch and sending a notification response message, the embodiment of the present application achieves the following effects:
[0220] Status awareness: The system can perceive the online status of the storage system in real time, providing a basis for rapid response and fault handling.
[0221] Communication confirmation: By sending a notification response message, the system confirms that the communication with the switch is valid and reliable.
[0222] Failure recovery preparation: After knowing the status of the storage system, the system can prepare for possible failure recovery operations, such as starting a backup plan or reallocating resources.
[0223] As an optional solution, the method further includes:
[0224] S9-1, edit the container group configuration file;
[0225] S9-2, apply the container group configuration file to the container orchestration system to trigger the container orchestration system to apply the 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.
[0226] In an optional embodiment, a container group configuration file: a file containing configuration information related to a container group, used to define how to deploy and manage the container group in a container orchestration system.
[0227] Container group resource: In a container orchestration system, a resource object used to define and control how a group of containers run and collaborate with each other on the same node.
[0228] It should be noted that this embodiment also includes the step of editing the container group configuration file and applying the configuration file to the container orchestration system. The purpose of this is to trigger the container orchestration system to apply the container group resources to the system according to the definition 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.
[0229] By editing and applying container group configuration files, you can flexibly define and manage container groups running in the container orchestration system. This not only simplifies the container deployment and management process, but also improves the scalability and maintainability of the system. At the same time, the use of configuration files also makes it easy to record and track the configuration history of containers, making it easier to troubleshoot and recover from problems.
[0230] To further illustrate, optionally assuming that Kubernetes is used as a container orchestration system, a Pod configuration file can be created (in Kubernetes, a Pod is the smallest deployable computing unit, representing one or a group of application containers running on a cluster). This configuration file may contain information such as the container image, required resources, and environment variables. When this configuration file is applied to a Kubernetes cluster, Kubernetes will create one or more Pods based on the definition of this configuration file and ensure that these Pods run as required on the same node.
[0231] 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:
[0232] Flexible configuration: allows users to customize the configuration of container groups according to their needs, including the number, type, and resource requirements of containers.
[0233] Simplified deployment: The deployment process of container groups is simplified through configuration files, which improves deployment efficiency.
[0234] Unified management: Ensures that containers on the same node are run and managed in a unified manner as defined in the configuration file, improving the stability and maintainability of the system.
[0235] Easy to expand: When you need to expand or update your container group, you only need to modify and reapply the configuration file, without having to manually adjust the settings for each container.
[0236] 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, the method further includes:
[0237] S10-1, collecting the latest host information of the container orchestration system at a fourth time interval;
[0238] S10-2, sending the latest host information to the storage system through the communication link.
[0239] In an optional embodiment, the fourth time interval refers to the frequency at which the system collects and sends host information. This interval can be adjusted according to actual needs of the system and the network environment.
[0240] Host information: various data about the host where the container orchestration system is located, which may include the host's hardware configuration, operating status, network configuration, etc.
[0241] It should be noted that after establishing a communication link between the container orchestration system and the storage system and successfully mounting the storage volume through the link, the embodiment of the present application also includes a step of periodically collecting information. Specifically, the system will collect the latest host information of the container orchestration system at a set fourth time interval and send the latest information to the storage system through the established communication link.
[0242] This mechanism of regularly collecting and sending host information is essential for achieving 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 understanding the host status in real time, the storage system can better cooperate with the container orchestration system to achieve on-demand allocation and efficient use of resources.
[0243] To further illustrate, let's assume that there is a Kubernetes cluster running in a cloud environment, which is connected to a distributed storage system. To ensure that the storage system can understand the status of the cluster in real time and optimize the allocation of storage resources accordingly, Kubernetes will collect the latest information of the cluster host at regular intervals (for example, every 5 minutes, i.e., the fourth time interval), such as CPU usage, memory usage, network bandwidth utilization, etc. Then, this information will be sent to the storage system through the communication link between Kubernetes and the storage system.
[0244] Collecting and sending the latest host information of the container orchestration system to the storage system at the fourth time interval achieves the following effects:
[0245] Real-time status perception: The storage system can understand the host status of the container orchestration system in real time, providing a data foundation for dynamic resource management and optimization.
[0246] Optimized resource allocation: Based on the latest host information, the storage system can allocate and adjust storage resources more intelligently to meet the actual needs of the container orchestration system.
[0247] Improve system performance: This approach helps improve the operating performance and responsiveness of the entire system by reducing resource waste and improving resource utilization efficiency.
[0248] As an optional solution, for ease of understanding, the method for mounting a storage volume is applied to the process of CSI driver mounting a volume, wherein the process of CSI driver mounting a volume may include two parts, namely, a pre-process and a mounting process.
[0249] The pre-process mainly involves establishing a RoCE-NVMe link and creating a host. The steps are roughly as follows:
[0250] The first step is to manually execute the nvme connect command on each K8s node to establish a network connection between each K8s node and the storage node, that is, to open up the in-band channel between the host (server) and the storage.
[0251] The second step is to manually create a corresponding host on the storage system based on the NQN information of each K8s node to prepare for the subsequent use of the volume (i.e. mounting).
[0252] The mounting process mainly involves the process of creating SC, PVC, and POD. SC is a storage template, PVC is a declaration of PV (corresponding to volume), and POD is a collection of containers. The process of creating POD is the process of using volume.
[0253] In the above process, the first and second steps of the pre-process both require manual operation. If there are many nodes in the K8s cluster, the number of times the first and second steps need to be executed will increase accordingly, which is not only cumbersome and repetitive, but also prone to errors.
[0254] The main content of this embodiment is to simplify the pre-process of mounting a volume, that is, to automate the first and second steps in the above process based on network intelligent perception, thereby reducing manual intervention and lowering the probability of errors.
[0255] First, the CSI driver and storage system send LLDP messages to the switch every 5 seconds to maintain uninterrupted communication with the switch, and the switch uses the interruption of LLDP messages to determine whether the CSI driver and storage system are online. When the switch finds that the storage is online or offline, it sends a broadcast message to the LAN to inform the CSI driver of the storage status.
[0256] 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 activation status configured on each port, and listens to the broadcast messages on each port in select mode. Once a message from the switch is listened to, it is parsed to find out whether the storage is online or offline, and calls the command nvme connect or nvmedisconnect to establish or disconnect the connection between the current K8s node and the storage node.
[0257] Third, after the CSI driver establishes the connection between the K8s node and the storage node, the RoCE-NVMe link is opened, and a channel is established between the storage and the K8s node, which can be used for communication between the K8s node and the storage node. The CSI driver collects 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.
[0258] Fourth, after the storage system receives the host information from the K8s node, it creates a host based on the serial number and NQN in the host information. The host will be used for storage volume use (i.e. mounting).
[0259] The above process is completed by the cooperation of the CSI driver and the storage system, thus realizing the automation and intelligence of the pre-mounting volume process.
[0260] In an optional embodiment, the CSI driver is deployed as follows Figure 3 As shown in the figure, the CSI driver plays a connecting role between K8s and the storage system, that is, it connects to K8s upward and the storage system downward to dynamically provide persistent space. CSI docking with K8s requires five sidecar components, namely external provisioner, external attacher, external snapshotter, external resizer, and node-driver-registrar, as follows:
[0261] external provisioner: Control and forwarding of creation / deletion of volumes and snapshots.
[0262] external attacher: Control and forwarding of mounting / unmounting volumes.
[0263] external snapshotter: control and forwarding of creation / deletion of snapshots.
[0264] external resizer: Control and forward the expansion volume.
[0265] node-driver-registrar: Registers the CSI driver to the kubelet service.
[0266] In an optional embodiment, the CSI driver self-check process is as follows: Figure 4 As shown in the figure, the host self-test is an independent thread of the CSI driver. By default, the thread performs a self-test every 1 second. The host self-test includes the following:
[0267] Traverse all network card ports on the current host, add or update port information, including the port's IP address, IP type (IPv4 or IPV6), whether it is physical, whether it is a VLAN, and whether it is started.
[0268] If it is detected that the network card port is offline, that is, the status is DOWN, all established RoCE-NVMe connections on the port will be actively disconnected. Of course, you can also configure whether to actively disconnect.
[0269] In an optional embodiment, the communication interaction process between the CSI driver, the storage system and the switch is as follows: Figure 4 As shown in the figure, the CSI driver sends LLDP packets to the switch every 5 seconds for each port based on the latest NIC port information obtained in the previous step, so that the switch knows whether the host port is always online. The LLDP notification message format sent by the CSI driver is based on the standard LLDP message, and adds customer customization items.
[0270] Furthermore, the storage system also sends LLDP messages to the switch every 5 seconds to maintain the heartbeat between the two. The switch uses the LLDP messages sent by the storage to determine whether the storage is online. If no messages are received from the storage within two minutes, the storage is considered offline. At this time, the switch will organize the storage offline message into a new LLDP message and broadcast it. If a message is suddenly received from the storage, the storage is considered online. Similarly, the switch will organize the storage online message into a new LLDP message and broadcast it.
[0271] In an optional embodiment, the CSI driver needs to subscribe to the status notification (storage online or storage offline) sent by the switch in order to receive the corresponding message. When the CSI driver receives the status notification, it first sends an ACK message to the switch as a response, then parses the status notification and performs corresponding operations according to the content of the status notification.
[0272] The CSI driver receives and parses the status notification sent by the switch. If it is a storage online message, it sends the nvme connect command to the host NVMe system. If it is a storage offline message, it sends the nvme disconnect command to the host NMVe system.
[0273] The RoCE-NVMe connection established by the CSI driver is a connection from the host port to the storage port IP-IP. When the CSI driver disconnects, it will only identify the NVMe link of the established IP-IP. For those NVMe links that do not contain IP-IP information, the CSI driver does not process them.
[0274] In an optional embodiment, after the RoCE-NVMe link between the host and the storage is established, the host information is reported to the storage.
[0275] First, the CSI driver identifies all RoCE-NVMe channels. Use the command ls / dev / | egrep ^nvme([0-9]+$) to obtain all channels established in the previous step. The channel identifier is generally / dev / nvmeX.
[0276] Secondly, 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. Use the hostname command to obtain the host name, use the dmidecode -t 1 |grep 'Serial Number' command to obtain the serial number, and read the file / dev / os-release to obtain the operating system type and version.
[0277] Then, the CSI driver reports the host information to the storage system. The host information is reported to the storage system through the channel.
[0278] In an optional embodiment, after receiving the host information reported by the CSI driver, the storage system obtains the NQN information of the host through the RoCE-NVMe link, and then calls the mkhost command to create a host. Note that the 0 type of the host must be the RoCE type. This host is used to mount the volume. At this point, the preparatory work for mounting the volume has been completed.
[0279] In an optional embodiment, edit the configuration file corresponding to the SC and create the SC through the K8s command line to prepare for the subsequent creation of PVC. Note that each SC corresponds to two storage systems. The detailed information of the SC is generally described in a yaml file, as shown below:
[0280] apiVersion: storage.K8s.io / v1
[0281] kind: StorageClass
[0282] metadata:
[0283] name: sc
[0284] provionser: csi-instorage
[0285] parameters
[0286] storageKind: block
[0287] storageName: storage1
[0288] apiVersion: K8s API version, here is v1.
[0289] kind: K8s resource type, here is StorageClass, or SC.
[0290] meta.name: The name of the metadata type, that is, the name of the SC.
[0291] spec.provisioner: SC provider, that is, the name of the CSI driver.
[0292] spec.parameters.storageKind: storage type, block represents block device.
[0293] spec.parameters.storageName: the name of the storage. Use the command kubectl apply -fsc.yaml to create an SC. The process of creating an SC does not require the participation of the CSI driver.
[0294] In an optional embodiment, edit the configuration file corresponding to the PVC, and create the PVC through the K8s command line. The node corresponds to the host, and the PVC corresponds to the storage volume. The process of creating a PVC is the process of creating a new volume on the storage. The detailed information of the PVC is generally described in a yaml file, as shown below:
[0295] apiVersion: v1
[0296] kind: PersistentVolumeClaim
[0297] metadata:
[0298] name: pvc
[0299] spec:
[0300] accessModes:
[0301] -ReadWriteOnce
[0302] volumeMode: Filesystem
[0303] resources:
[0304] requests:
[0305] storage: 1Gi
[0306] storageClassName: sc
[0307] apiVersion: K8s API version, here is v1.
[0308] kind: K8s resource type, which is PVC in this case.
[0309] meta.name: The name of the metadata type, that is, the name of the PVC.
[0310] spec.accessModes: the access mode of PVC. ReadWriteOnce means that it is only accessible to one K8s node.
[0311] spec.volumeMode: the volume mode of the PVC. FileSystem means the volume will be formatted as a file system.
[0312] spec.resources.requests.storage: PVC size, here is 1Gi.
[0313] spec.storageClassName: the storage template corresponding to the PVC, that is, the name of the SC.
[0314] Run the kubectl apply -f pvc.yaml command to create three PVCs. The process of creating PVCs requires the participation of CSI. The command for creating volumes is mkvdisk.
[0315] In an optional embodiment, edit the configuration file corresponding to the POD, and create the POD through the K8s command line. The process of creating a POD first completes the mounting of the main volume on the storage side, then completes the formatting and mapping of the device on the host side, and finally synchronizes the directory to the container. The container's operation on the directory is the operation on the volume. POD detailed information is generally described through a yaml file, as shown below:
[0316] apiVersion: v1
[0317] kind: Pod
[0318] metadata:
[0319] name: block-pod
[0320] spec:
[0321] containers:
[0322] - name: basic-pod
[0323] image: centos-7.6.1812:for-csiplugin
[0324] command: [" / bin / sh", "-c"]
[0325] args: [ "tail -f / dev / null" ]
[0326] volumeMounts:
[0327] - name: k8s-test-01
[0328] mountPath: / mnt / test01
[0329] volumes:
[0330] - name: k8s-test-01
[0331] persistentVolumeClaim:
[0332] claimName: pvc
[0333] metadata.name: POD name.
[0334] spec.volumes.persistentVolumeClaim.claimName: PVC name. Used to bind a PVC.
[0335] Use the command kubectl apply -f pod.yaml to create a POD. The process of creating a POD requires the participation of the CSI driver. CSI mounts volumes by interacting with storage and hosts. The general steps are as follows:
[0336] The first step is to call the storage interface lshost to view the host.
[0337] The second step is to call the storage interfaces mkvdiskhostmap, lsportip, and lshost to mount the primary volume corresponding to the PVC to the host and obtain the mounting information.
[0338] The third step is to call the host interface nvme list_subsys to obtain the RoCE_NVMe link between the host and the storage.
[0339] Step 4: traverse the directory / dev / disk / by-id to obtain the single device information corresponding to the volume.
[0340] The fifth step is to call the host interface multipath to obtain the multipath device after all single-path devices corresponding to the primary volume are aggregated.
[0341] Step 6: Call the host interface mkfs to format the volume according to the required file system and mount the volume to the specified directory.
[0342] Through the above steps, the host is automatically created and the volume is easily mounted.
[0343] It should be noted that this embodiment requires the protection of a comprehensive network intelligent perception mechanism, which realizes the automation of the pre-mounting volume process through the collaborative work of multiple links. Specifically, the mechanism includes the following core parts:
[0344] 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 broadcast the status changes of the storage system in the LAN to ensure that all relevant components in the network can promptly know the latest status of the storage system.
[0345] CSI monitoring and response: CSI has the ability to monitor messages in the LAN, especially to receive and parse LLDP messages from switches. Based on the content of the message, 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 intelligence of link management.
[0346] 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 this information to the storage system through a dedicated channel. This mechanism ensures that the storage system can continuously obtain the latest host information and provide reliable data support for subsequent operations.
[0347] Automatically create 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 feature greatly simplifies the subsequent volume mounting process and improves the ease of use and efficiency of the system.
[0348] To further illustrate, 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 in the LAN.
[0349] Furthermore, CSI can monitor messages in the LAN, especially LLDP messages from switches. Once a message is received, CSI will immediately parse it to determine the status of the storage system. If the storage system is online, CSI will automatically establish a RoCE-NVMe link; conversely, if the storage system is offline, the link will be automatically disconnected.
[0350] To further maintain the real-time nature of the information, the CSI driver is designed to automatically collect host information every 10 minutes and report the information to the storage system through a dedicated channel.
[0351] Furthermore, when the storage system receives the host information and NQN from the CSI driver, it automatically creates a host record for the host, greatly simplifying the subsequent volume mounting process.
[0352] In addition, this embodiment realizes the automation of the pre-mounting volume process through network intelligent perception technology, and can also be widely applied to other systems, such as the Cinder driver of OpenStack, so as to improve the intelligence and efficiency of the system.
[0353] Through the embodiments of the present application, with the help of network intelligent perception technology, the pre-process of mounting volumes is upgraded from the original manual operation to fully automated processing. First, through CSI-driven intelligent management, the RoCE-NVMe link between the K8s node and the storage node can be automatically established without manual intervention, thereby greatly reducing the workload of operation and maintenance personnel and achieving effective release of human resources. Secondly, the automatic acquisition of host information and the automatic creation of hosts not only simplify the operating process, but also reduce the risk of errors that may be introduced due to manual operations, significantly improving the overall operating efficiency of the system.
[0354] Through the description of the above implementation methods, those skilled in the art can clearly understand that the method according to the above embodiment can be implemented by means of software plus a necessary general hardware platform, and of course it can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of the present application, or the part that contributes to the prior art, can be embodied in the form of a software product, which is stored in a storage medium (such as ROM / RAM, disk, CD), and includes a number of instructions for a terminal device (which can be a mobile phone, computer, server, or network device, etc.) to execute the methods of each embodiment of the present application.
[0355] In this embodiment, a storage volume mounting device is also provided, which is used to implement the above embodiments and preferred implementation modes, and will not be repeated here. 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, the implementation of hardware, or a combination of software and hardware, is also possible and conceivable.
[0356] Figure 5 is a structural block diagram of a storage volume mounting device according to an embodiment of the present application, such as Figure 5 As shown, the device comprises:
[0357] A first acquiring unit 502 is configured to acquire 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 the interruption of the 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 at a preset time interval;
[0358] The first establishing unit 504 is used to establish a communication link between the container orchestration system and the storage system when the broadcast information 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.
[0359] For a specific embodiment, reference may be made to the example shown in the above storage volume mounting method, which will not be described in detail in this example.
[0360] As an optional solution, the device also includes:
[0361] The disconnection unit is used to disconnect the communication link after obtaining the broadcast message sent by the switch, if the broadcast information 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.
[0362] For a specific embodiment, reference may be made to the example shown in the above storage volume mounting method, which will not be described in detail in this example.
[0363] As an optional solution, the device also includes:
[0364] A first determining unit is configured to, after acquiring the broadcast message sent by the switch, determine that the container storage interface driver is in a first online state when the broadcast information indicates that the container storage interface driver changes from an unavailable state to an available state;
[0365] The second determining unit is configured to, after acquiring the broadcast message sent by the switch, determine that the storage system is in a second online state when the broadcast information indicates that the storage system changes from an unavailable state to an available state.
[0366] For a specific embodiment, reference may be made to the example shown in the above storage volume mounting method, which will not be described in detail in this example.
[0367] As an optional solution, the device also includes:
[0368] A setting unit is used to set a container storage interface driver before obtaining the broadcast message sent by the switch, and query whether the container orchestration system and the container storage interface driver maintain communication at a first time interval;
[0369] A third determining unit is configured to determine that the container storage interface driver is in an available state while maintaining communication between the container orchestration system and the container storage interface driver before acquiring the broadcast message sent by the switch;
[0370] The fourth determining unit is configured to determine that the container storage interface driver is in an unavailable state when the communication between the container orchestration system and the container storage interface driver is disconnected before acquiring the broadcast message sent by the switch.
[0371] For a specific embodiment, reference may be made to the example shown in the above storage volume mounting method, which will not be described in detail in this example.
[0372] As an optional solution, the device also includes:
[0373] The second establishing unit is used to re-establish the communication link after acquiring the broadcast message sent by the switch, if the broadcast information indicates that the storage system is updated and the communication link has been established.
[0374] For a specific embodiment, reference may be made to the example shown in the above storage volume mounting method, which will not be described in detail in this example.
[0375] As an optional solution, the second establishment unit includes:
[0376] A first disconnection module, used to disconnect the communication link;
[0377] A first acquisition module, used to acquire a new broadcast message sent by the switch;
[0378] The establishing module is used to establish a 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.
[0379] For a specific embodiment, reference may be made to the example shown in the above storage volume mounting method, which will not be described in detail in this example.
[0380] As an optional solution, the device also includes:
[0381] A second acquisition unit is used to acquire host information of the container orchestration system at a second time interval;
[0382] The first sending unit is used to send host information to the storage system through the communication link during the process of mounting the storage volume through the communication link, so that the storage system creates a mount running object, wherein the mount running object is a physical server or virtual machine that provides a mount point for the storage volume.
[0383] For a specific embodiment, reference may be made to the example shown in the above storage volume mounting method, which will not be described in detail in this example.
[0384] As an optional solution, the second acquisition unit includes at least one of the following:
[0385] A second acquisition module is used 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;
[0386] A third acquisition module is used 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;
[0387] The fourth acquisition module is used 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.
[0388] For a specific embodiment, reference may be made to the example shown in the above storage volume mounting method, which will not be described in detail in this example.
[0389] As an optional solution, the device also includes:
[0390] A first editing module is used to edit the configuration file of the persistent storage volume after sending the host information to the storage system through the communication link so that the storage system creates a mount running object;
[0391] The application module is used to send the host information to the storage system through the communication link so that the storage system creates a mounted running object, and then 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 its corresponding persistent storage volume according to the definition in the configuration file;
[0392] The mounting module is used to send host information to the storage system through a communication link so that after the storage system creates a mount running object, when the persistent storage volume is bound to each node in the container orchestration system, instruct the storage system to mount the storage volume to the mount running object, thereby providing persistent storage services for the container orchestration system through the persistent storage volume.
[0393] For a specific embodiment, reference may be made to the example shown in the above storage volume mounting method, which will not be described in detail in this example.
[0394] As an optional solution, the first editing module includes at least one of the following:
[0395] First, add a submodule to add the API version adapted for the persistent storage volume in the configuration file;
[0396] The second adding submodule is used to add the specified type of resources corresponding to the persistent storage volume in the configuration file;
[0397] The third adding submodule is used to add the identity corresponding to the persistent storage volume in the configuration file;
[0398] The fourth adding submodule is used to add the access mode corresponding to the persistent storage volume in the configuration file;
[0399] The fifth adding submodule is used to add the requested storage size corresponding to the persistent storage volume in the configuration file;
[0400] The sixth adding submodule is used to add the requested storage type corresponding to the persistent storage volume in the configuration file.
[0401] For a specific embodiment, reference may be made to the example shown in the above storage volume mounting method, which will not be described in detail in this example.
[0402] As an optional solution, the device also includes:
[0403] A second editing module is used to edit the storage class configuration file according to the characteristics of the storage system before editing the configuration file of the persistent storage volume;
[0404] The registration module is used 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 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.
[0405] For a specific embodiment, reference may be made to the example shown in the above storage volume mounting method, which will not be described in detail in this example.
[0406] As an optional solution, the device also includes:
[0407] The inspection unit is used to perform a host inspection on the container orchestration system at a third time interval to obtain an inspection result.
[0408] For a specific embodiment, reference may be made to the example shown in the above storage volume mounting method, which will not be described in detail in this example.
[0409] As an optional option, the inspection unit includes:
[0410] A traversal module is used 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 mounting the storage volume through the communication link;
[0411] The second disconnection module is used to disconnect the communication link after establishing a communication link between the container orchestration system and the storage system and mounting the storage volume through the communication link, if the port information indicates that the network card port is in a port offline state.
[0412] For a specific embodiment, reference may be made to the example shown in the above storage volume mounting method, which will not be described in detail in this example.
[0413] As an optional option, the inspection unit includes:
[0414] A sending module is used to send corresponding port information to the switch at a fourth time interval for each port of all network card ports before establishing a communication link between the container orchestration system and the storage system and realizing the mounting of the storage volume through the communication link, wherein the data link message includes the port information.
[0415] For a specific embodiment, reference may be made to the example shown in the above storage volume mounting method, which will not be described in detail in this example.
[0416] As an optional solution, the device also includes:
[0417] a fifth acquisition module, configured to acquire a status notification sent by the switch after sending corresponding port information to the switch at a fourth time interval for each of all network card ports, wherein the status notification is used to notify the online status of the storage system;
[0418] The returning module is used to return a notification response message corresponding to the status notification to the switch after sending the corresponding port information to the switch at a fourth time interval for each port of all the network card ports, wherein the notification response message is used to indicate that the container storage interface driver has received the status notification.
[0419] For a specific embodiment, reference may be made to the example shown in the above storage volume mounting method, which will not be described in detail in this example.
[0420] As an optional solution, the device also includes:
[0421] Editing unit, used to edit container group configuration files;
[0422] The application unit is used to apply the container group configuration file to the container orchestration system to trigger the container orchestration system to apply the 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.
[0423] For a specific embodiment, reference may be made to the example shown in the above storage volume mounting method, which will not be described in detail in this example.
[0424] As an optional solution, the device also includes:
[0425] A collecting unit, configured to collect the latest host information of the container orchestration system at a fourth time interval after establishing a communication link between the container orchestration system and the storage system and mounting the storage volume through the communication link;
[0426] The second sending unit is used to send the latest host information to the storage system through the communication link after establishing a communication link between the container orchestration system and the storage system and mounting the storage volume through the communication link.
[0427] For a specific embodiment, reference may be made to the example shown in the above storage volume mounting method, which will not be described in detail in this example.
[0428] It should be noted that the above-mentioned virtual devices (modules, units, sub-modules, sub-units, components, etc.) can be implemented by software or hardware. For the latter, it can be implemented in the following ways, but not limited to: the above-mentioned virtual devices are all located in the same processor; or, the above-mentioned virtual devices are located in different processors in any combination.
[0429] An embodiment of the present application further provides a computer-readable storage medium, in which a computer program is stored, wherein the computer program is configured to execute the steps of any of the above method embodiments when running.
[0430] In an exemplary embodiment, the computer-readable storage medium may include, but is not limited to, various media that can store computer programs, such as a USB flash drive, a read-only memory (ROM), a random access memory (RAM), a mobile hard disk, a magnetic disk or an optical disk.
[0431] An embodiment of the present application further provides an electronic device, including a memory and a processor, wherein a computer program is stored in the memory, and the processor is configured to run the computer program to execute the steps in any one of the above method embodiments.
[0432] In an exemplary embodiment, the electronic device may further include a transmission device and an input / output device, wherein the transmission device is connected to the processor, and the input / output device is connected to the processor.
[0433] For specific examples in this embodiment, reference may be made to the examples described in the above embodiments and exemplary implementation modes, and this embodiment will not be described in detail herein.
[0434] Obviously, those skilled in the art should understand that the above-mentioned virtual devices or steps of the present application can be implemented by a general computing device, they can be concentrated on a single computing device, or distributed on a network composed of multiple computing devices, they can be implemented by a program code executable by a computing device, so that they can be stored in a storage device and executed by the computing device, and in some cases, the steps shown or described can be executed in a different order from that herein, or they can be made into individual integrated circuit modules, or multiple modules or steps therein can be made into a single integrated circuit module for implementation. Thus, the present application is not limited to any specific combination of hardware and software.
[0435] The above description is only the preferred embodiment of the present application and is not intended to limit the present application. For those skilled in the art, the present application may have various modifications and variations. Any modification, equivalent replacement, improvement, etc. made within the principles of the present application shall be included in the protection scope of the present application.
Claims
1. A method for mounting a storage volume, characterized in that: include: Acquire a broadcast message sent by a 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 at a preset time interval; 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, a communication link is established between the container orchestration system and the storage system, and the storage volume is mounted through the communication link.
2. The method according to claim 1, characterized in that After acquiring the broadcast message sent by the switch, the method further includes: When 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 the available state to the unavailable state, the communication link is disconnected.
3. The method according to claim 2, characterized in that After acquiring the broadcast message sent by the switch, the method further includes: In a case where the broadcast message indicates that the container storage interface driver changes from the unavailable state to the available state, determining that the container storage interface driver is in a first online state; In a case where the broadcast message indicates that the storage system changes from the unavailable state to the available state, it is determined that the storage system is in a second online state.
4. The method according to claim 2, characterized in that: Before acquiring the broadcast message sent by the switch, the method further includes: Setting the container storage interface driver to query whether the container orchestration system and the container storage interface driver maintain communication at a first time interval; In a case where the container orchestration system and the container storage interface driver maintain communication, determining that the container storage interface driver is in the available state; In a case where communication between the container orchestration system and the container storage interface driver is disconnected, determining that the container storage interface driver is in the unavailable state.
5. The method according to claim 1, characterized in that After acquiring the broadcast message sent by the switch, the method further includes: When the broadcast message indicates that the storage system is updated and the communication link has been established, the communication link is reestablished.
6. The method according to claim 5, characterized in that The re-establishing the communication link comprises: disconnecting the communication link; Obtain a new broadcast message sent by the switch; The communication link is established 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.
7. The method according to claim 1, characterized in that In the process of implementing the mounting of the storage volume through the communication link, the method further includes: Obtaining host information of the container orchestration system at a second time interval; The host information is sent to the storage system through the communication link, so that the storage system creates a mount operation object, wherein the mount operation object is a physical server or a virtual machine that provides a mount point for the storage volume.
8. The method according to claim 7, characterized in that The obtaining host information of the container orchestration system includes at least one of the following: Obtain 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; Obtaining 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; At least one operating system type corresponding to the container orchestration system is obtained, wherein the operating system type is a system type supported by the container orchestration system.
9. The method according to claim 7, characterized in that: After sending the host information to the storage system through the communication link so that the storage system creates a mount operation object, the method further includes: Edit the configuration file of the 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 the corresponding persistent storage volume according to the definition in the configuration file; When the persistent storage volume is bound to each node in the container orchestration system, the storage system is instructed to mount the storage volume to the mounted running object, thereby providing persistent storage services for the container orchestration system through the persistent storage volume.
10. The method according to claim 9, characterized in that The editing of the configuration file of the persistent storage volume includes at least one of the following: Add the API version adapted by the persistent storage volume to the configuration file; Add the specified type of resources corresponding to the persistent storage volume in the configuration file; Adding an identity identifier corresponding to the persistent storage volume to the configuration file; Adding the access mode corresponding to the persistent storage volume in the configuration file; Add the requested storage size corresponding to the persistent storage volume in the configuration file; Add the requested storage type corresponding to the persistent storage volume in the configuration file.
11. The method according to claim 9, characterized in that Before editing the configuration file of the persistent storage volume, the method further includes: Editing a storage class configuration file according to the characteristics of the storage system; Apply 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 according to claim 1, characterized in that The method further comprises: At a third time interval, a host check is performed on the container orchestration system to obtain a check result.
13. The method according to claim 12, characterized in that After establishing a communication link between the container orchestration system and the storage system and mounting a 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 includes: Traverse all network card ports of the container orchestration system to obtain port information; When the port information indicates that the network card port is in a port offline state, disconnect the communication link.
14. The method according to claim 13, characterized in that Before establishing a communication link between the container orchestration system and the storage system and mounting a 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 includes: 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.
15. The method according to claim 14, characterized in that After sending the corresponding port information to the switch at a fourth time interval for each of all the network card ports, the method further includes: Obtaining a status notification sent by the switch, wherein the status notification is used to notify the online status of the storage system; A 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 comprises: Edit the container group configuration file; 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 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 according to any one of claims 1 to 14, characterized in that 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: Collecting the latest host information of the container orchestration system at a fourth time interval; The latest host information is sent to the storage system through the communication link.
18. A storage volume mounting device, characterized in that: include: A first acquisition unit is configured to acquire a broadcast message sent by a 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, wherein the data link message is a message sent by the container storage interface driver and the storage system to the switch at a preset time interval; The first establishing unit is used 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-readable storage medium, characterized in that: The computer-readable storage medium stores a computer program, wherein the computer program implements the steps of the method described in any one of claims 1 to 17 when executed by a processor.
20. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein: When the processor executes the computer program, the steps of the method described in any one of claims 1 to 17 are implemented.
Citation Information
Patent Citations
Cinder roll mounting method and device and medium
CN115185636A
Container Orchestrator-Aware Storage System
US20230011540A1