Communication method, apparatus and device

Abstract

This application provides a communication method, apparatus, and device. The method is applied to the master controller in a multi-controller storage system, which includes a master controller and at least one slave controller. The method includes: when the master controller generates data to be sent to an external network address, determining the target drift address corresponding to this communication; encapsulating the data to be sent, the external network address, and the target drift address into an application layer data packet; querying the current location of the target drift address; and when the current location of the target drift address is located at a target slave controller, sending the application layer data packet to the target slave controller, so that the target slave controller can parse the data to be sent and send the data to the external network address using the target drift address as the source address. The method provided in this application does not rely on external gateways or routers, reducing dependence on external network devices and improving the autonomy and reliability of the multi-controller storage system.

Description

Technical Field

[0001] This application relates to the fields of computer communication and distributed storage technology, and in particular to a communication method, apparatus and device. Background Technology

[0002] Multi-controller storage systems typically consist of one master controller and multiple slave controllers. To ensure high availability and load balancing, multi-controller storage systems are usually configured with shifted Internet Protocol (IP) addresses, which serve as a unified external access point. When the master controller generates data to be sent to an external network address, it must ensure that the data is sent to the external network address using the currently active shifted address as the source address.

[0003] In related technologies, to address the issue that the master controller cannot directly use a drifted address as its source address when it is on the slave controller, a Source Network Address Translation (SNAT) scheme using an external gateway or router is typically employed. The specific process is as follows: the master controller directly sends the data packet to be transmitted; the gateway device deployed at the front end of the multi-controller storage system intercepts the data packet, modifies its source address to the currently configured drifted address, and then forwards it to the external network address. However, implementing source address translation through a gateway adds additional network device dependency, reducing the autonomy and reliability of the multi-controller storage system. Summary of the Invention

[0004] This application provides a communication method, apparatus, and device. When the main controller generates data to be sent, it encapsulates the data to be sent, an external network address, and a target drift address into an application layer data packet, determines the target drift address corresponding to this communication, and sends the application layer data packet to the target slave controller when the current location of the target drift address is located at the target slave controller. The target slave controller parses the application layer data packet and sends the data to be sent to the external network address using the target drift address as the source address. This eliminates the need to rely on external gateways or routers, reduces dependence on external network devices, and improves the autonomy and reliability of the multi-controller storage system.

[0005] In a first aspect, embodiments of this application provide a communication method applied to a master controller in a multi-controller storage system, the multi-controller storage system including a master controller and at least one slave controller, the method comprising:

[0006] When the main controller generates data to be sent to an external network address, it determines the target drift address corresponding to this communication.

[0007] Encapsulate the data to be sent, the external network address, and the target drift address into an application layer data packet;

[0008] Query the current location of the target drift address;

[0009] When the current location of the target drift address is at the target slave controller, the application layer data packet is sent to the target slave controller so that the target slave controller can parse the data to be sent, the external network address and the target drift address from the application layer data packet, and send the data to be sent to the external network address with the target drift address as the source address. The target slave controller can be any slave controller in the multi-controller storage system.

[0010] By generating data to be sent by the main controller, encapsulating application-layer data packets, and then proxying the transmission from the controller, this mechanism solves the technical challenge of the main controller being unable to directly use the target migration address to send data when the target migration address is located on the slave controller. This avoids the complexity of configuring additional gateway SNAT rules required in traditional solutions. Simultaneously, through application-layer encapsulation and internal forwarding, it ensures that the source address for data transmission is always a unified target migration address, improving the reliability and compatibility of external communication in multi-controller storage systems. This is particularly suitable for business scenarios requiring a fixed source address, such as alarms and log uploads.

[0011] In one possible implementation, the data to be sent, the external network address, and the target drift address are encapsulated into an application-layer data packet, including:

[0012] The application layer protocol is used to encapsulate the data to be sent, the external network address, and the target drift address to obtain the application layer data packet; the application layer protocol can be Hypertext Transfer Protocol (HTTP).

[0013] The application layer data packet header carries the external network address, communication port number, destination drift address, and business communication protocol type. The business communication protocol type indicates the application layer communication protocol followed by the data to be sent. The business communication protocol type can include Lightweight Directory Access Protocol (LDAP) or Simple Mail Transfer Protocol (SMTP).

[0014] By using this application-layer protocol-based encapsulation method, the main controller can package the three core elements—who to send to, what identity to use, and what content to send—into a standardized application-layer data packet. When the target receives this application-layer data packet from the controller, it only needs to parse the HTTP header to quickly obtain all the metadata required for forwarding and can call the corresponding processing logic to accurately send the data to be sent in the HTTP body to the external network address, using the target's drift address as the source address. This not only leverages the universality and ease of use of the HTTP protocol but also achieves the separation of control signaling from the business data to be sent.

[0015] In one possible implementation, after sending the application layer data packet to the target slave controller, the method further includes:

[0016] The target receives the network connectivity status returned by the controller. The network connectivity status is obtained by the target from the controller after parsing the data to be sent, using the target's drift address as the source address to perform network layer reachability detection on the external network address.

[0017] When the network connectivity status indicates that the network is unreachable, re-query the current location of the target drift address, or re-determine the target drift address corresponding to this communication, in order to attempt to resend the data to be sent;

[0018] If resending fails within a preset number of attempts, a message indicating that the data to be sent has failed is returned to the business module that initiated the data transmission.

[0019] By employing pre-send detection and failure retry mechanisms, the multi-controller storage system not only enables cross-node proxy transmission of data to be sent, but also endows the communication link with self-awareness and fault avoidance capabilities, greatly improving the delivery rate of critical services such as operation and maintenance alarms and log uploads in complex network environments.

[0020] In one possible implementation, the method further includes:

[0021] When the current position of the target drift address is at the main controller, the data to be sent is parsed from the application layer data packet;

[0022] Using the target drift address as the source address, the parsed data to be sent is sent to the external network address.

[0023] By combining local direct sending and cross-node proxy sending modes, the multi-controller storage system ensures that outgoing data packets always carry a unified and valid target address, regardless of which node (master controller or any slave controller) the target address migrates to within the system. This not only avoids the problem of outgoing data packets being blocked by external firewalls due to source address mismatches, but also allows the business module initiating the data transmission to be completely unaware of the underlying IP's physical location when sending data, achieving complete decoupling between business logic and network topology changes.

[0024] In one possible implementation, the method further includes:

[0025] After successfully sending the data to be sent to the external network address, the mapping between the external network address and the target drift address used in this communication is added to the cache table;

[0026] Before querying the current location of the target drift address, first query the cache table; if the target drift address corresponding to the external network address exists in the cache table, directly determine the target drift address in the cache table as the target drift address corresponding to this communication;

[0027] When a target drift address is detected to have drifted, when a network unreachable feedback message for an external network address is received from the controller, when a record in the cache table is detected to have exceeded its preset lifespan, or when the configuration of the target drift address is detected to have changed, the corresponding record in the cache table is cleared.

[0028] Through a closed-loop mechanism of cache table recording, cache acceleration, and aging-out purging, the multi-controller storage system can effectively reduce the computing load of the controller and the latency of internal signaling interaction while ensuring the reliability of external communication, thereby achieving dual optimization of performance and stability.

[0029] Secondly, embodiments of this application provide a communication method applied to a target slave controller in a multi-controller storage system, the multi-controller storage system further including a master controller and at least one other slave controller, the method comprising:

[0030] The application layer data packet is received from the main controller. The application layer data packet is obtained by the main controller when it generates data to be sent to an external network address, determines the target drift address corresponding to this communication, and finds that the current position of the target drift address is after the target slave controller. The data to be sent, the external network address and the target drift address are then encapsulated.

[0031] Extract the data to be sent, the external network address, and the target drift address from the application layer data packet;

[0032] The data to be sent is sent to the external network address using the target drift address as the source address.

[0033] Since the master controller has already queried the location information of the target drift address before encapsulation, the application layer data packet is directly sent to the target slave controller corresponding to the target drift address, avoiding the delay of intermediate forwarding. The target slave controller directly uses the target drift address as the source address to send the data to be sent, which meets the routing response requirements of the external network and ensures bidirectional smooth TCP / IP communication.

[0034] In one possible implementation, the method further includes:

[0035] Before sending the data to the external network address, perform a network layer reachability check on the external network address;

[0036] When the detection result indicates that the external network address is reachable, the system returns the network connectivity status indicating network reachability to the main controller and executes the step of sending the data to be sent to the external network address.

[0037] When the detection result indicates that the external network address is unreachable, feedback information indicating that the external network address is unreachable is returned to the main controller, so that the main controller can re-query the current location of the target drift address or redetermine the target drift address based on the feedback information.

[0038] By proactively verifying the validity of network paths before data transmission, the reliability and intelligence of communication can be improved. When the network is reachable, the data to be sent can be transmitted in a timely and accurate manner, ensuring business continuity and efficiency. When network unreachability is detected, the system feeds back the abnormal information to the main controller and triggers a rerouting mechanism, effectively preventing invalid transmission and loss of data in faulty links. This achieves dynamic optimization of communication paths and automatic fault avoidance. It not only reduces communication failure rates and retransmission overhead but also enhances the stability and self-healing capabilities of external communication in a multi-controller environment.

[0039] Thirdly, embodiments of this application provide a communication device applied to a master controller in a multi-controller storage system. The multi-controller storage system includes a master controller and at least one slave controller. The device includes:

[0040] The drift address determination module is used to determine the target drift address corresponding to this communication when the main controller generates data to be sent to an external network address;

[0041] The encapsulation module is used to encapsulate the data to be sent, the external network address, and the target drift address into an application layer data packet;

[0042] The location query module is used to query the current location of the target drift address;

[0043] The first sending module is used to send application layer data packets to the target slave controller when the current position of the target drift address is located at the target slave controller, so that the target slave controller can parse the data to be sent, the external network address and the target drift address from the application layer data packets, and send the data to be sent to the external network address with the target drift address as the source address. The target slave controller can be any slave controller in the multi-controller storage system.

[0044] In one possible implementation, the encapsulation module is specifically used for:

[0045] The application layer protocol is used to encapsulate the data to be sent, the external network address, and the target drift address to obtain the application layer data packet;

[0046] The header of the application layer data packet carries the external network address, communication port number, target drift address, and business communication protocol type; the business communication protocol type is used to indicate the application layer communication protocol followed by the data to be sent.

[0047] In one possible implementation, the first transmitting module is further configured to:

[0048] The target receives the network connectivity status returned by the controller. The network connectivity status is obtained by the target from the controller after parsing the data to be sent, using the target's drift address as the source address to perform network layer reachability detection on the external network address.

[0049] When the network connectivity status indicates that the network is unreachable, re-query the current location of the target drift address, or re-determine the target drift address corresponding to this communication, in order to attempt to resend the data to be sent;

[0050] If resending fails within a preset number of attempts, a message indicating that the data to be sent has failed is returned to the business module that initiated the data transmission.

[0051] In one possible implementation, the first transmitting module is further configured to:

[0052] When the current position of the target drift address is at the main controller, the data to be sent is parsed from the application layer data packet;

[0053] Using the target drift address as the source address, the parsed data to be sent is sent to the external network address.

[0054] In one possible implementation, the device further includes a cache module, which is used for:

[0055] After successfully sending the data to be sent to the external network address, the mapping between the external network address and the target drift address used in this communication is added to the cache table;

[0056] Before querying the current location of the target drift address, first query the cache table; if the target drift address corresponding to the external network address exists in the cache table, directly determine the target drift address in the cache table as the target drift address corresponding to this communication;

[0057] When a target drift address is detected to have drifted, when a network unreachable feedback message for an external network address is received from the controller, when a record in the cache table is detected to have exceeded its preset lifespan, or when the configuration of the target drift address is detected to have changed, the corresponding record in the cache table is cleared.

[0058] Fourthly, embodiments of this application provide a communication device applied to a target slave controller in a multi-controller storage system. The multi-controller storage system further includes a master controller and at least one other slave controller. The device includes:

[0059] The receiving module is used to receive application layer data packets sent by the main controller. The application layer data packets are obtained by the main controller when it generates data to be sent to an external network address, determines the target drift address corresponding to this communication, and finds that the current position of the target drift address is after the target slave controller. The data to be sent, the external network address, and the target drift address are then encapsulated.

[0060] The parsing module is used to parse the data to be sent, the external network address, and the target drift address from the application layer data packets;

[0061] The second sending module is used to send the data to be sent to an external network address, using the target drift address as the source address.

[0062] In one possible implementation, the second transmitting module is specifically used for:

[0063] Before sending the data to the external network address, perform a network layer reachability check on the external network address;

[0064] When the detection result indicates that the external network address is reachable, the system returns the network connectivity status indicating network reachability to the main controller and executes the step of sending the data to be sent to the external network address.

[0065] When the detection result indicates that the external network address is unreachable, feedback information indicating that the external network address is unreachable is returned to the main controller, so that the main controller can re-query the current location of the target drift address or redetermine the target drift address based on the feedback information.

[0066] Fifthly, embodiments of this application provide a communication device, including:

[0067] At least one processor; and

[0068] A memory that is communicatively connected to at least one processor; wherein,

[0069] The memory stores instructions that can be executed by at least one processor to enable the at least one processor to perform the methods shown in either the first aspect or the second aspect.

[0070] In a sixth aspect, embodiments of this application provide a non-transitory computer-readable storage medium storing computer instructions, wherein the computer instructions are used to cause a computer to perform the methods shown in any of the first or second aspects.

[0071] In a seventh aspect, embodiments of this application provide a computer program product, including a computer program that, when executed by a processor, implements the methods shown in any of the first or second aspects.

[0072] The communication method, apparatus, and device provided in this application embodiment, through the method of generating data to be sent by the main controller, encapsulating application layer data packets, and sending them on behalf of the controller, ensures that the source address of the sent data packets is always a drift address recognized by the external server. This avoids outgoing data packets being blocked by firewalls or rejected by servers due to source address mismatch, thereby avoiding the problem of the main controller being unable to communicate because the target drift address is not local, and realizing high-availability communication in a multi-controller storage system. Even if the main controller fails, after the slave controller takes over the drift address, it can still use the same mechanism (if the service switches to run on the slave controller) or cooperate with a new main controller to continue to complete external communication, ensuring the continuity of the operation and maintenance channel. Attached Figure Description

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

[0074] Figure 1 A schematic diagram illustrating an application scenario provided in an embodiment of this application;

[0075] Figure 2 A flowchart illustrating a communication method provided in an embodiment of this application;

[0076] Figure 3 A flowchart illustrating another communication method provided in an embodiment of this application;

[0077] Figure 4 A flowchart illustrating yet another communication method provided in an embodiment of this application;

[0078] Figure 5This is a schematic diagram of the structure of a communication device provided in an embodiment of this application;

[0079] Figure 6 This is a schematic diagram of another communication device provided in an embodiment of this application;

[0080] Figure 7 This is a schematic diagram of the structure of a communication device provided in an embodiment of this application.

[0081] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation

[0082] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0083] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0084] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, use and processing of the relevant data must comply with relevant laws, regulations and standards, and corresponding operation entry points are provided for users to choose to authorize or refuse.

[0085] To facilitate understanding, the following will be combined with... Figure 1 The application scenarios applicable to the embodiments of this application will be described.

[0086] Figure 1 This is a schematic diagram illustrating an application scenario provided by an embodiment of this application. Please refer to [link / reference]. Figure 1This application scenario includes a multi-controller storage system 10 and a target server 20. The two establish a communication connection through an external network (such as an enterprise intranet, wide area network, or the Internet) to jointly complete the external business interaction of the storage system.

[0087] The multi-controller storage system 10 includes a master controller 110 and at least one slave controller (such as...). Figure 1 The system comprises slave controllers 121, 122, and 123. Each component achieves low-latency, highly reliable data interaction through an internal high-speed network, jointly managing the backend disk array and providing unified storage and management capabilities externally. The master controller 110 handles the core business logic and external management requests of the multi-controller storage system 10. Slave controllers, acting as hot backups, are interconnected with the master controller 110 through an internal high-speed network and are used to take over services in the event of a failure of the master controller 110 to ensure high system availability.

[0088] Specifically, the main controller 110 is responsible for handling core business logic, such as input / output (I / O) scheduling, data redundancy management, and external management requests, such as receiving configuration instructions from clients and responding to queries from the monitoring platform. When the multi-controller storage system 10 needs to actively initiate communication with the outside world (such as sending fault alarms, uploading operation logs, or verifying user identity), the main controller 110 is the initiator of the business logic, responsible for generating the business data to be sent (such as alarm content, log files, and authentication request messages) and coordinating the subsequent data sending process.

[0089] The slave controller acts as a hot backup node for the master controller 110, normally in standby mode, synchronizing the configuration and status information of the master controller 110 in real time. When the master controller 110 fails, the slave controller can take over the work of the master controller 110 through a drift mechanism, ensuring uninterrupted storage services. At the same time, the slave controller also acts as a proxy for data transmission. When the master controller 110 needs to send data using a drift address, but the drift address is currently located at the target slave controller, the target slave controller will receive the data to be sent forwarded by the master controller 110 and, using the drift address as the source address, ultimately send the data to the external target server 20.

[0090] The target server 20 is the receiver of external communication of the multi-controller storage system 10. Its type is determined by the specific business needs of the multi-controller storage system 10, and can be an alarm server, log / monitoring server, authentication server or file server, etc.

[0091] In this scenario, the communication between the multi-controller storage system 10 and the target server 20 must meet the source address validity requirement. That is, the source address of the data packets sent by the multi-controller storage system 10 must be the drift address (virtual IP address, which can be dynamically drifted to the master / slave controller) of the multi-controller storage system 10. Otherwise, it may be blocked by the firewall of the target server 20 or the authentication may fail.

[0092] When the drift address is located on the slave controller, the master controller 110 cannot directly send data using the drift address as the source address (because the source address needs to be bound to the physical network card). In this case, the master controller 110 can forward the service data to be sent to the slave controller holding the drift address, and the slave controller will complete the final transmission, ensuring that the source address of the data packet received by the target server 20 is a valid drift address, thereby ensuring the reliability and compliance of communication.

[0093] Through the above architecture, the multi-controller storage system 10 not only achieves high availability and disaster recovery internally, but also solves the technical problem of source address legality when actively communicating with the outside world, and can provide the target server 20 with stable and reliable business interaction capabilities.

[0094] Multi-controller storage systems typically consist of one master controller and multiple slave controllers. To ensure high availability and load balancing, a drift address is usually configured as a unified external access point in such systems. The drift address can be dynamically bound to the currently active master controller or a slave controller after failover. When the master controller generates data to be sent to an external network address, it must ensure that the source address of the data packet strictly uses the actual active target drift address in the current multi-controller storage system to ensure that the data packet can be correctly received and responded to by the external network.

[0095] In related technologies, to address the issue that the master controller cannot directly use the drift address on the slave controller as the source address to send data when the drift address is currently located on the slave controller (i.e., the standby controller), a source network address translation (SNAT) scheme using an external gateway or router is typically employed. The specific process is as follows: The master controller directly sends the data packet to be sent, at which point the source address of the data packet is the master controller's local service address (not the drift address). The gateway device deployed at the front end of the multi-controller storage system intercepts this data packet using preset SNAT rules, forcibly changing its source address to the currently configured drift address, and then forwards the data packet to the external network address.

[0096] However, relying on external gateways to implement SNAT functionality increases the dependence of multi-controller storage systems on third-party network devices. A single point of failure or performance bottleneck in the gateway can directly lead to the failure of external communication for the entire multi-controller storage system, reducing its autonomy and reliability and contradicting the original intention of high availability design. Furthermore, introducing independent gateway devices not only increases hardware deployment and maintenance costs but also requires configuring complex SNAT rules and routing policies, increasing the management complexity of the multi-controller storage system.

[0097] This application proposes a communication method. This method replaces the SNAT scheme, which relies on an external gateway, with a collaborative communication mechanism between controllers within a multi-controller storage system, ensuring that data packets ultimately sent to the external network use the correct drift address as the source address. When the master controller generates data to be sent, it first encapsulates the data to be sent, the external network address, and the target drift address into a custom application-layer data packet. Through an internal state synchronization mechanism (such as heartbeat detection or a cluster management protocol), the master controller obtains the actual location of the current drift address in real time (i.e., determines which controller the target drift address is currently bound to, either the master controller itself or a slave controller).

[0098] If the target drift address is currently located locally on the main controller, the main controller will directly use that drift address as the source address to send the data to be sent.

[0099] If the target drift address is currently located at the target slave controller (i.e., the slave controller currently holds the target drift address), the master controller will send the encapsulated application layer data packet directly to the target slave controller through an internal high-speed communication link (such as a dedicated cluster intranet).

[0100] After receiving the application layer data packet from the controller, the target parses out the original data to be sent, the external network address, and the target drift address. Then, using this target drift address as the source address, it directly sends the data to the external network address. Since the data is sent from the controller by the target that actually holds the drift address, the legitimacy of the source address is fundamentally guaranteed, ensuring that the external network can receive and respond normally, thus guaranteeing successful communication. This eliminates the need for external gateways or routers, reducing reliance on external gateway devices, enhancing the autonomy and reliability of the multi-controller storage system, and significantly reducing its complexity and maintenance costs.

[0101] The method described in this application will now be illustrated through specific embodiments. It should be noted that the following embodiments may exist independently or in combination with each other; identical or similar content will not be repeated in different embodiments.

[0102] Figure 2This is a flowchart illustrating a communication method provided in an embodiment of this application. Please refer to [link / reference]. Figure 2 This method can be applied to the master controller in a multi-controller storage system, which includes a master controller and at least one slave controller. The method may include:

[0103] S201. When the main controller generates data to be sent to an external network address, determine the target drift address corresponding to this communication.

[0104] Specifically, when the main controller detects an event requiring external communication (such as a hard drive failure requiring an alarm), it can first generate the data to be sent (e.g., the alarm content) and determine the virtual identity that must be used for this communication, which is the target migration address. For example, in a multi-controller storage system where all alarms must be sent using the IP address "192.168.1.100", the main controller can use this IP address as the target migration address for this communication.

[0105] S202. Encapsulate the data to be sent, the external network address, and the target drift address into an application layer data packet.

[0106] Specifically, to avoid routing errors or verification failures caused by sending data directly from sources not located locally, the main controller can encapsulate the sending task into an application-layer data packet. This application-layer data packet includes a payload and metadata. The payload contains the original data to be sent (e.g., alarm content), while the metadata adds custom fields to the application-layer header to explicitly record the external network address (e.g., 202.100.1.50) and the target drift address (e.g., 192.168.10.100).

[0107] This encapsulation transforms the sending behavior at the network layer into data transmission at the application layer, allowing the data packet to be transmitted within the internal network like a regular file, without being restricted by the underlying IP address.

[0108] S203. Query the current location of the target drift address.

[0109] In a multi-controller storage system, the slave controller is a hot backup node of the master controller, and the drift address can be dynamically drifted between the master controller and the slave controller.

[0110] Specifically, after encapsulation, the main controller can query the cluster status table or the drift IP management module (the component responsible for managing the drift status of drift IPs) through the internal high-speed management bus, such as the Peripheral Component Interconnect Express (PCIe) or the internal Ethernet, to query the current location of the target drift address, i.e., which node the target drift address is mounted on.

[0111] S204. When the current location of the target drift address is at the target slave controller, the application layer data packet is sent to the target slave controller so that the target slave controller can parse the data to be sent, the external network address and the target drift address from the application layer data packet, and send the data to be sent to the external network address with the target drift address as the source address.

[0112] In this embodiment of the application, the target slave controller is any slave controller in a multi-controller storage system.

[0113] Specifically, when the query results show that the current location of the target drift address is located in any slave controller in the multi-controller storage system, it indicates that the master controller cannot directly use the target drift address to send data and must seek assistance from the target slave controller where the target drift address is currently located.

[0114] Specifically, the master controller can send the encapsulated application layer data packets to the target slave controller via the internal network. In this case, the internal transmission uses the physical IP between the master and slave controllers and does not involve external IP migration.

[0115] After receiving the application layer data packet, the target controller can parse the application layer header of the packet to extract the original data to be sent, the external network address, and the target drift address. Then, it calls the local network protocol stack to construct the final Transmission Control Protocol / Internet Protocol (TCP / IP) data packet.

[0116] The source address can be the target drift address (e.g., 192.168.10.100); the destination IP can be the external network address (e.g., 202.100.1.50); ​​and the data can be the data to be sent (e.g., alarm content).

[0117] Finally, the target controller can send TCP / IP packets containing the data to be sent to an external network address.

[0118] In practical implementation, the master controller obtains the current location of the drifting address in real time through an internal state synchronization mechanism (such as heartbeat detection or cluster management protocol). For example, when the master controller detects that an alarm email needs to be sent, it first calls the drifting IP management module to query whether the target drifting address has drifted to the slave controller. If the drifting address is located on the slave controller, the master controller sends the encapsulated application layer data packet to the target slave controller through an internal high-speed communication link (such as the cluster intranet). After parsing the data packet, the target slave controller sends the data to the external network with the drifting address as the source address. This technical solution ensures that the source address is always a legitimate drifting address through master-slave controller collaboration, avoiding firewall blocking or communication failures caused by source address mismatch, while reducing dependence on external gateways and improving system autonomy and reliability.

[0119] The communication method provided in this application, which generates data to be sent by the main controller, encapsulates application-layer data packets, and then proxies the transmission from the controller, ensures that the source address of the sent data packets is always a drift address recognized by the external server. This avoids TCP / IP data packets being blocked by firewalls or rejected by servers due to source address mismatches, thereby preventing the main controller from being unable to communicate because the target drift address is not local. This achieves high-availability communication in a multi-controller storage system. Even if the main controller fails, after the slave controller takes over the drift address, it can still use the same mechanism (if the service switches to run on the slave controller) or cooperate with a new main controller to continue external communication, ensuring the continuity of the operation and maintenance channel.

[0120] In one possible implementation, the data to be sent, the external network address, and the destination drift address are encapsulated into an application layer data packet. This includes: encapsulating the data to be sent, the external network address, and the destination drift address using an application layer protocol to obtain the application layer data packet; wherein the header of the application layer data packet carries the external network address, the communication port number, the destination drift address, and the business communication protocol type; the business communication protocol type is used to indicate the application layer communication protocol followed by the data to be sent. The business communication protocol type may include a lightweight directory access protocol or a simple mail transfer protocol, and the application layer protocol may be a hypertext transfer protocol.

[0121] Specifically, to efficiently and transparently transmit data to be sent and its associated network metadata within the storage system's internal network, the master controller can encapsulate the data using HTTP. This encapsulation method abstracts the underlying network communication details into standard application-layer protocols, making data interaction between the master and slave controllers more flexible and easier to parse.

[0122] Specifically, the main controller can encapsulate the data to be sent (such as specific alarm content, log files, or authentication requests), the external network address (i.e., the IP address of the target server that will ultimately receive the data), and the target drift address (i.e., the source address that must be bound to in this communication) into a standard HTTP application layer data packet.

[0123] In the encapsulation structure of this HTTP application layer data packet, key information is precisely placed in the HTTP headers, while the HTTP body is used to carry the actual business data.

[0124] For HTTP header fields, when constructing an HTTP request, the main controller can insert custom or standard key-value pairs into the HTTP header to carry necessary communication metadata such as external network address and communication port number, target drift address, and business communication protocol type.

[0125] The external network address and communication port number refer to the fact that the main controller can write the target server's IP address (i.e., external network address) and port number into the HTTP header. This allows the receiving end (and the slave controller) to know explicitly which external address the data to be sent should ultimately be forwarded to.

[0126] The target drift address refers to the source IP address (i.e., the target drift address) that the main controller can write into the HTTP header to indicate that the controller should use this target drift address to send data.

[0127] The business communication protocol type refers to the business protocol type identifier that can be carried in the HTTP header to accommodate various different business scenarios. This field is used to explicitly indicate the original protocol type of the data to be sent, including but not limited to LDAP (commonly used for user authentication) or SMTP (commonly used for sending alarm emails).

[0128] The body of an HTTP request can be a binary stream or a text format, used to directly store the raw data to be sent. For example, if the service type is SMTP, the body of the HTTP request contains the complete email message content; if the service type is LDAP, the body of the HTTP request contains the LDAP authentication request message.

[0129] In practical implementation, HTTP header fields (such as the business communication protocol type) are used to guide the parsing logic of the target slave controller. For example, when the business type is LDAP, the target slave controller calls the LDAP protocol processor to parse the data packets; when the business type is SMTP, it calls the SMTP protocol processor to construct the email message. Through protocol type identification, the target slave controller can uniformly handle heterogeneous business traffic (such as authentication requests and email transmissions), avoiding parsing failures due to protocol conflicts. Furthermore, standardized encapsulation of HTTP headers reduces the integration complexity of cross-vendor devices and improves system compatibility.

[0130] This HTTP-based encapsulation method allows the main controller to package three core elements—who to send to, what identity to use, and what content to send—into a standardized application-layer data packet. When the target receives this HTTP application-layer data packet from the controller, it only needs to parse the HTTP header to quickly obtain all the metadata required for forwarding. It can then invoke the corresponding processing logic to accurately send the data to be sent in the HTTP body to the external network address, using the target's drift address as the source address. This not only leverages the universality and ease of use of the HTTP protocol but also achieves the separation of control signaling from the business data to be sent.

[0131] In one possible implementation, after sending the application layer data packet to the target slave controller, the method further includes: receiving the network connectivity status returned by the target slave controller; the network connectivity status is obtained by the target slave controller after parsing the data to be sent, using the target drift address as the source address to perform network layer reachability detection on the external network address; when the network connectivity status indicates that the network is unreachable, re-querying the current location of the target drift address, or re-determining the target drift address corresponding to this communication, to attempt to resend the data to be sent; when resending fails within a preset number of times, returning a prompt message indicating that the data to be sent has failed to be sent to the service module that initiated the data to be sent.

[0132] Specifically, in order to further improve the reliability of external communication of the multi-controller storage system and avoid resource waste or business blockage caused by blindly sending data packets, the master controller can also execute a rigorous pre-send detection and failure retry mechanism after sending application layer data packets to the target slave controller.

[0133] Specifically, when the target controller receives the application layer data packet forwarded by the master controller and parses it to obtain the data to be sent, the external network address, and the target drift address, it does not immediately send the data. Instead, the target controller can first perform an L3 reachability check, sending a probe message, such as an Internet Control Message Protocol (ICMP) Echo Request (Ping) operation, to the external network address using the target drift address as the source address, to confirm whether the network link from the current node to the external target server is unobstructed. After the check is completed, the target controller can return the obtained network connectivity status (such as network reachable or unreachable) as a response message to the master controller.

[0134] After receiving the network connectivity status returned by the target from the controller, the main controller can make intelligent decisions based on the network connectivity status.

[0135] If the network connectivity status indicates that the network is unreachable, the master controller can trigger retry logic instead of directly reporting an error to the service module that initiated the data transmission. First, it can re-query the current location of the target drift address, or re-determine the target drift address for this communication. For example, a multi-controller storage system may be configured with multiple available drift addresses. The master controller can switch to another drift address and query its node (which may be another slave controller), attempting to resend the encapsulated application layer data packet via a new path. This pre-transmission detection and failure retry mechanism effectively avoids single-point network failures or anomalies in the link where a specific drift IP resides.

[0136] In practice, the target controller verifies network layer reachability via ICMP Ping or TCP connection checks. For example, before sending an alarm email, the target controller sends an ICMP Echo Request message to the target server using the drifted address as the source IP, and determines network connectivity based on whether an Echo Reply is received. If the check fails, it returns a "network unreachable" message to the master controller, triggering the master controller to re-query the drifted address location or switch the drifted address. This pre-detection avoids invalid transmissions, reduces redundant data packet transmission, and distinguishes between network layer failures (such as routing interruptions) and address layer failures (such as drifted IP synchronization issues), thus improving communication reliability.

[0137] Furthermore, to prevent getting stuck in an infinite retry loop under extreme network failures, this embodiment also introduces a retry limit (e.g., a preset maximum of 3 retries). The main controller can record the current number of retries. Once all attempted paths (including changing the drift address or changing the slave controller) return network unreachable or transmission failure within the preset number of retries, the main controller can stop retries and return a clear message indicating that the data transmission failed to send to the service module that initiated the data transmission (e.g., alarm management module, log management module, SMS notification module, automated operation and maintenance module).

[0138] By employing pre-send detection and failure retry mechanisms, the multi-controller storage system not only enables cross-node proxy transmission of data to be sent, but also endows the communication link with self-awareness and fault avoidance capabilities, greatly improving the delivery rate of critical services such as operation and maintenance alarms and log uploads in complex network environments.

[0139] In one possible implementation, the method further includes: parsing the data to be sent from the application layer data packet when the current location of the target drift address is at the main controller; and sending the parsed data to be sent to an external network address using the target drift address as the source address.

[0140] Specifically, this communication method not only covers scenarios involving cross-node proxy transmission, but also fully encompasses the local direct transmission process when the target drift address is located on the main controller. When the main controller detects that the current location of the target drift address is within itself, it does not need to perform cross-node forwarding and can directly call the local network protocol stack to complete the data transmission.

[0141] Specifically, when the main controller confirms that the target drift address is currently mounted on the local network card, it can directly process the encapsulated application layer data packets locally. At this time, the main controller no longer needs to forward the application layer data packets to other nodes, but directly calls the local application layer parsing module to extract the core data to be sent (such as specific alarm messages, log file contents, etc.) from the application layer data packets, and at the same time extracts the metadata such as the external network address originally encapsulated in the HTTP header.

[0142] After parsing the data to be sent, the main controller can directly construct the final outgoing data packet using its local underlying network protocol stack (such as the TCP / IP protocol stack). During the construction process, the main controller can specify the destination IP address as the source IP address of the outgoing data packet and the external network address as the destination IP address. Since the destination IP address is currently bound to the main controller's virtual interface, the main controller can legally use this destination IP address as its identifier to directly send the parsed data to the external network address.

[0143] By combining local direct sending and cross-node proxy sending modes, the multi-controller storage system ensures that outgoing data packets always carry a unified and valid target address, regardless of which node (master controller or any slave controller) the target address migrates to within the system. This not only avoids the problem of outgoing data packets being blocked by external firewalls due to source address mismatches, but also allows the business module initiating the data transmission to be completely unaware of the underlying IP's physical location when sending data, achieving complete decoupling between business logic and network topology changes.

[0144] In one possible implementation, the method further includes: after successfully sending the data to be sent to the external network address, adding the correspondence between the external network address and the target drift address used in this communication to a cache table; querying the cache table before querying the current position of the target drift address; if the target drift address corresponding to the external network address exists in the cache table, directly determining the target drift address in the cache table as the target drift address corresponding to this communication; when the target drift address is detected to have drifted, when a network unreachable feedback information for the external network address is received from the controller, when a record in the cache table is detected to have exceeded a preset lifespan, or when the configuration of the target drift address is detected to have changed, clearing the corresponding record in the cache table.

[0145] Specifically, to further improve communication efficiency and reduce unnecessary system overhead, this embodiment introduces a cache-accelerated intelligent address decision-making and aging mechanism. By recording the forwarding paths in historical communication processes, the main controller can quickly make decisions when faced with recurring external communication needs, and can also flexibly respond to dynamic changes in network topology.

[0146] Specifically, after the master controller (or via a slave controller agent) successfully sends the data to be sent to the external network address, the master controller can add the mapping between the external network address used in this successful communication and the target drift address as a new entry to the local cache table. At the same time, an initial time to live (TTL) can be set for this entry, such as 5 minutes or 10 minutes.

[0147] In subsequent operations, when the main controller generates data to be sent to the same external network address again, it can first query the local cache table before triggering complex logic such as querying the current location of the target drift address.

[0148] If the record corresponding to the external network address is found in the cache table, the main controller can directly extract the target drift address from the cache and determine it as the target drift address for this communication.

[0149] This skips the process of recalculation or traversal query, greatly shortens the preparation time before data encapsulation, and improves the response speed of multi-controller storage systems to high-frequency external communication (such as continuous reporting of monitoring logs).

[0150] Meanwhile, to prevent cached records from becoming invalid due to changes in the network environment (e.g., the drifted address has migrated, or an external link has failed), a strict cache eviction policy can be set. When any of the following situations are detected: the target drifted address has drifted; a network unreachable feedback message for the external network address is received from the controller; a record in the cache table exceeds its preset lifespan; or the configuration of the target drifted address has changed, the main controller can immediately clear the corresponding record in the cache table, allowing the multi-controller storage system to re-probe in real time during the next communication.

[0151] Physical migration of a drifting address refers to the detection that the target drifting address has drifted from one controller to another (e.g., detecting a change in IP ownership through a heartbeat mechanism).

[0152] Receiving network unreachable feedback means receiving network unreachable feedback information from the target back from the controller for that external network address (indicating that the currently cached path has expired).

[0153] Cache record timeout refers to the detection that a record in the cache table has exceeded its preset lifespan, which triggers a regular aging and clearing process to ensure that the path status is refreshed periodically.

[0154] A configuration change refers to the detection that the system administrator has manually changed the underlying configuration of the target drift address (such as modifying the network segment of the drift address or the bound virtual network card).

[0155] In implementation, the cache table manages the lifecycle of records through a preset time-to-live (TTL) policy. For example, cached records are automatically cleared when they exceed the TTL, preventing unlimited memory growth. Furthermore, when a drift address configuration change is detected or a network unreachable feedback is received, the corresponding record in the cache table immediately becomes invalid. This dynamic clearing strategy ensures strict consistency between cached data and the real-time topology, while preventing excessive memory usage from degrading system performance. When a drifting target address is detected, the corresponding record in the cache table is immediately cleared to ensure strict consistency between the cache and the real-time topology; if no drift event occurs, the cached record is automatically cleared after the preset TTL, preventing unlimited memory growth. If a drift event and TTL timeout occur simultaneously, the clearing operation triggered by the drift event is executed first. This dynamic strategy balances real-time performance and stability, preventing communication failures due to cache expiration.

[0156] Furthermore, in order to enjoy the performance improvement brought by caching acceleration while minimizing the risk of packet loss caused by cache address lag (e.g., drifting just before TTL timeout), this embodiment can also introduce a lightweight status pre-check mechanism after cache hit.

[0157] Specifically, when the main controller finds the target drift address corresponding to the external network address in the cache table, it can perform a fast address attribution check instead of directly encapsulating and sending the data. This address attribution check can be achieved by sending a low-overhead probe message (such as a lightweight heartbeat packet or a liveness request with specific flags) to the target drift address currently recorded in the cache.

[0158] If the main controller receives a normal response from the target drift address within a preset, very short timeout period, it proves that the target drift address is still active and its ownership has not changed. At this point, the data to be sent is then formally encapsulated and transmitted. This not only ensures the real-time accuracy of the communication path but also avoids the transmission of invalid data packets.

[0159] Conversely, if the probe message times out without a response, or if feedback indicating an unreachable address or changed ownership is received, the main controller can determine that the current cached record, although not expired, has become invalid. In this case, the main controller can immediately clear the cached record and trigger real-time location re-query logic to obtain the latest target drift address before sending the data. This defensive strategy of verifying before sending effectively addresses the packet loss issues that may arise from caching mechanisms in scenarios with rapid changes in extreme network topology, further improving the system's communication reliability.

[0160] Through a closed-loop mechanism of cache table recording, cache acceleration, and aging-out purging, the multi-controller storage system can effectively reduce the computing load of the controller and the latency of internal signaling interaction while ensuring the reliability of external communication, thereby achieving dual optimization of performance and stability.

[0161] Figure 3 This is a flowchart illustrating another communication method provided in an embodiment of this application. Please refer to... Figure 3 This method can be applied to a target slave controller in a multi-controller storage system, which also includes a master controller and at least one other slave controller. The method may include:

[0162] S301, Receive application layer data packets sent by the main controller.

[0163] In this embodiment of the application application, the application layer data packet is obtained by the main controller when it generates data to be sent to an external network address, determines the target drift address corresponding to this communication, queries the current position of the target drift address after it is located at the target slave controller, and encapsulates the data to be sent, the external network address and the target drift address.

[0164] Specifically, the multi-controller storage system includes a master controller, one or more other slave controllers, and the target slave controller in this embodiment.

[0165] The target slave controller can first receive application-layer data packets sent from the master controller. These application-layer data packets are not ordinary network data packets, but rather a dedicated data structure encapsulated by the master controller after intelligent decision-making. The specific encapsulation process includes: when the master controller generates data to be sent to an external network address, it first determines the target drift address corresponding to this communication. Next, the master controller queries the global state table to confirm that the current location of the target drift address is on the target slave controller. Then, the master controller encapsulates the three-tuple information of the data to be sent, the external network address (destination address), and the target drift address (source address) to generate the aforementioned application-layer data packet and sends it to the target slave controller.

[0166] After the target receives the application layer data packet from the controller, it can perform a parsing operation to extract the original data to be sent, the external network address, and the target drift address.

[0167] After successfully parsing the above information, the target controller, as the actual executor of this communication, can execute the final sending step. Specifically, the parsed target drift address can be used as the source address for network communication, and the external network address can be used as the destination IP address. By calling the underlying network protocol stack, the final TCP / IP data packet is constructed based on the target drift address, the data to be sent, and the external network address, and then sent to the external network address to send the data to be sent to the external network.

[0168] Because the master controller has already queried the location information of the target drift address before encapsulation, application layer data packets are directly sent to the target slave controller corresponding to the target drift address, avoiding delays caused by intermediate forwarding. The target slave controller directly uses the target drift address as the source address to send the data, complying with the routing response requirements of the external network and ensuring bidirectional TCP / IP communication. In specific implementations, the target slave controller sends data packets with the drift address as the source address, complying with the routing response requirements of the external network. For example, when an alarm email is sent to the alarm server via the target drift address, the alarm server's response message will be directly sent back to the controller (master or slave controller) bound to the drift address, avoiding routing failures due to source address mismatches. Thus, by verifying the validity of the source address, bidirectional TCP / IP communication is ensured.

[0169] In one possible implementation, the method further includes: performing a network layer reachability test on the external network address before sending the data to be sent to the external network address; when the test result indicates that the external network address is network reachable, returning a network connectivity status indicating network reachability to the main controller and executing the step of sending the data to be sent to the external network address; when the test result indicates that the external network address is network unreachable, returning feedback information indicating network unreachability of the external network address to the main controller, so that the main controller can re-query the current location of the target drift address or re-determine the target drift address based on the feedback information.

[0170] Specifically, in order to further improve the stability of external communication of the multi-controller storage system and avoid data packet loss or invalid retransmission caused by blindly sending data, this embodiment introduces an active network layer reachability detection mechanism before the data is actually sent.

[0171] Specifically, after the target receives and parses the data to be sent and the external network address from the controller, a pre-detection process can be triggered before the underlying network protocol stack is actually invoked to send the data. The target can initiate a network layer reachability check from the controller, using the target's drifting address as the source address, to the external network address to be accessed. For example, it can send an ICMP Echo Request (Ping) probe message or attempt to establish a lightweight TCP connection probe. Through this proactive probe, the target can detect in advance whether the physical link or logical route from the current node to the external target server is in a normal connectivity state.

[0172] If the probe results indicate network reachability, for example, by successfully receiving an ICMP echo reply message within a preset timeout period, the target slave controller can determine that the current communication link is healthy. At this point, the target slave controller can perform two operations: firstly, it sends a network connectivity confirmation message indicating network reachability back to the master controller, informing the master controller that the current path is clear; secondly, it immediately executes the original data transmission steps, encapsulating the parsed data to be transmitted and sending it successfully to the external network address using the target drift address as the source address. This mechanism ensures that actual service data is transmitted only when the link is clear, greatly improving the data transmission success rate.

[0173] If the probe results indicate network unreachability (e.g., probe messages time out without response, or ICMP error messages indicating destination unreachability are received), the target slave controller can immediately intercept the original service data transmission action to prevent data from entering the black hole network. Subsequently, the target slave controller can return a clear network unreachability feedback message to the master controller. Upon receiving this feedback, the master controller can determine that the path currently occupied by the target slave controller is faulty, and then re-query the current location of the target drift address (e.g., confirm whether the drift address has drifted to another healthy slave controller), or re-determine the target drift address corresponding to this communication according to a preset policy (e.g., switch to a backup drift address). Then, the master controller can re-encapsulate the data to be sent and forward it to the new target node, thereby attempting to complete the data transmission through another healthy path.

[0174] In practice, the target controller feeds back the communication status to the master controller based on the network layer reachability detection results. The master controller then dynamically adjusts its retry strategy based on this feedback. For example, if network unreachability is detected, the master controller can re-query the location of the drifting address or switch to a different drifting IP. This collaborative verification of network status by the master and slave controllers reduces the load on the master controller while ensuring end-to-end reliability from the application layer to the network layer, thus improving the communication success rate.

[0175] By proactively verifying the validity of network paths before data transmission, the reliability and intelligence of communication can be improved. When the network is reachable, the data to be sent can be transmitted in a timely and accurate manner, ensuring business continuity and efficiency. When network unreachability is detected, the system effectively avoids invalid transmission and loss of data in faulty links by feeding back abnormal information to the main controller and triggering a rerouting mechanism. This achieves dynamic optimization of communication paths and automatic fault avoidance. It not only reduces communication failure rates and retransmission overhead but also enhances the stability and self-healing capabilities of external communication in multi-controller environments, making it particularly suitable for applications with stringent network reliability requirements, such as industrial control and critical information infrastructure.

[0176] In some embodiments, for the main controller, encapsulating the data to be sent, the external network address, and the target drift address into an application layer data packet includes: identifying the business communication protocol type corresponding to the data to be sent, where the business communication protocol type includes at least one of SMTP and File Transfer Protocol (FTP); and selecting the corresponding encapsulation strategy according to the business communication protocol type. Specifically, if the business communication protocol type is SMTP, the email header information of the data to be sent is retained in the application layer data packet; if the data volume of the data to be sent exceeds a preset threshold, the data to be sent is compressed, and the compressed data is encapsulated into the application layer data packet.

[0177] Through protocol-aware encapsulation optimization, key metadata (such as email headers) for specific protocols such as SMTP are not lost. At the same time, compression of large data (such as log files) significantly reduces the bandwidth consumption of internal network forwarding and improves the efficiency of large file transfers.

[0178] Furthermore, in some embodiments, the main controller may also include a method for dynamically adjusting the cache lifetime based on the operating status of the multi-controller storage system. Specifically, the main controller can monitor in real time the migration frequency and network topology change status of the target drift address in the multi-controller storage system; and dynamically adjust the preset lifetime of the target drift address corresponding to the external network address in the cache table based on the monitoring results; wherein, if the migration frequency of the target drift address is detected to exceed a preset frequency threshold, the preset lifetime of the corresponding record in the cache table is shortened; if the target drift address is detected to be in a stable state, the preset lifetime of the corresponding record in the cache table is extended.

[0179] By dynamically adjusting the preset lifetime of the cache, the problems of slow cache entry expiration (leading to incorrect path selection) when drifting addresses frequently migrate or fast expiration (increasing query overhead) are avoided, thereby optimizing the resource allocation of the multi-controller storage system and improving communication efficiency.

[0180] In some embodiments, for the target slave controller, when performing network layer reachability detection, the specific detection protocol type can be further defined, and another protocol can be automatically switched to for detection if one protocol fails. Specifically, before sending the data to be sent to the external network address, network layer reachability detection is performed on the external network address, including: sequentially attempting to probe the external network address using ICMP, TCP, and application layer protocols; if the detection result of the current protocol indicates that the network is unreachable, the system automatically switches to the next priority protocol to continue detection; if the detection results of all attempted protocols indicate that the network is unreachable, feedback information indicating that the network is unreachable is returned to the master controller. This solves the problem that a single protocol (such as ICMP) may be blocked by the firewall, leading to a false judgment of network unreachability.

[0181] By using multi-protocol (such as ICMP, TCP, HTTP) detection and intelligent fallback, the true connectivity status of the network can be determined more accurately, avoiding invalid retries or communication failures caused by protocol limitations.

[0182] In one possible implementation, data forwarding between the master and slave controllers can use the TCP protocol instead of the HTTP protocol. Specifically, the master and slave controllers pre-establish a TCP keep-alive connection, and data packets are forwarded directly through the TCP channel. For example, in an alarm email sending scenario, the master controller encapsulates data packets into a TCP stream and sends it directly to the slave controller via the keep-alive connection. The slave controller's agent module parses the TCP stream, constructs SMTP data packets, and sends them. This technique significantly reduces communication latency by minimizing the overhead of HTTP request header parsing and status code processing, making it suitable for high-concurrency scenarios (such as real-time monitoring and alarms).

[0183] In one possible implementation, the drift IP caching strategy can incorporate machine learning models (such as time series forecasting) to analyze historical drift IP cache hit rates, predict potentially future drift IP combinations, and pre-load them into the cache table. Specifically, the main controller learns the association patterns between drift IPs and target network addresses through model training, proactively loading high-probability drift IP combinations into the cache table before communication requests arrive. This technique reduces the frequency of drift IP queries, improves cache hit rates, and further reduces communication latency and system overhead.

[0184] In one possible implementation, the drift IP management module achieves load balancing through a round-robin or weighted round-robin algorithm. For example, when the master controller queries the location of the target drift address, the drift IP management module dynamically allocates the target drift address based on the load status of the slave controllers. If slave controller 1 has a load of 80% and slave controller 2 has a load of 40%, the drift IP management module prioritizes returning the IP address of slave controller 2 as the target drift address. This technique optimizes the resource allocation of slave controllers by dynamically adjusting the drift address selection strategy, thereby improving the overall system throughput and stability.

[0185] Figure 4 This is a flowchart illustrating another communication method provided in an embodiment of this application. Figure 4 As shown, when the master controller 110 generates data to be sent to the target server 20, it first determines the target drift address corresponding to this communication. Then, it encapsulates the data to be sent, the external network address corresponding to the target server 20, and the target drift address into an application layer data packet. Next, it queries the current location of the target drift address, and when the current location of the target drift address is within the target slave controller 120, it sends the application layer data packet to the target slave controller 120. The target slave controller 120 can receive the application layer data packet sent by the master controller 110 and parse the data to be sent, the external network address, and the target drift address from the application layer data packet. Then, the target slave controller 120 can perform a network layer reachability test on the external network address corresponding to the target server 20. If the test result indicates that the external network address is reachable, it returns a network connectivity status indicating network reachability to the master controller 110. Finally, using the target drift address as the source address, it sends the data to be sent to the external network address corresponding to the target server 20.

[0186] Figure 5 This is a schematic diagram of a communication device provided in an embodiment of this application. Please refer to [link / reference]. Figure 5 The communication device is used in the master controller of a multi-controller storage system, which includes a master controller and at least one slave controller. The device may include:

[0187] The drift address determination module 51 is used to determine the target drift address corresponding to this communication when the main controller generates data to be sent to an external network address.

[0188] Encapsulation module 52 is used to encapsulate the data to be sent, the external network address, and the target drift address into an application layer data packet.

[0189] The location query module 53 is used to query the current location of the target drift address.

[0190] The first sending module 54 is used to send application layer data packets to the target slave controller when the current position of the target drift address is located at the target slave controller, so that the target slave controller can parse the data to be sent, the external network address and the target drift address from the application layer data packets, and send the data to be sent to the external network address with the target drift address as the source address. The target slave controller is any slave controller in the multi-controller storage system.

[0191] In one possible implementation, the encapsulation module 52 is specifically used for:

[0192] The application layer protocol is used to encapsulate the data to be sent, the external network address, and the target drift address to obtain the application layer data packet.

[0193] The header of the application layer data packet carries the external network address, communication port number, target drift address, and business communication protocol type; the business communication protocol type is used to indicate the application layer communication protocol followed by the data to be sent.

[0194] In one possible implementation, the first transmitting module 54 is further configured to:

[0195] The target receives the network connectivity status returned by the controller. The network connectivity status is obtained by the target from the controller after parsing the data to be sent, using the target drift address as the source address to perform network layer reachability detection on the external network address.

[0196] When the network connectivity status indicates that the network is unreachable, re-query the current location of the target drift address, or re-determine the target drift address corresponding to this communication, in order to attempt to resend the data to be sent.

[0197] If resending fails within a preset number of attempts, a message indicating that the data to be sent has failed is returned to the business module that initiated the data transmission.

[0198] In one possible implementation, the first transmitting module 54 is further configured to:

[0199] When the current location of the target drift address is at the main controller, the data to be sent is parsed from the application layer data packet.

[0200] Using the target drift address as the source address, the parsed data to be sent is sent to the external network address.

[0201] In one possible implementation, the device further includes a cache module, which is used for:

[0202] After successfully sending the data to be sent to the external network address, the mapping between the external network address and the target drift address used in this communication is added to the cache table.

[0203] Before querying the current location of the target drift address, first query the cache table; if the target drift address corresponding to the external network address exists in the cache table, directly determine the target drift address in the cache table as the target drift address corresponding to this communication.

[0204] When a target drift address is detected to have drifted, when a network unreachable feedback message for an external network address is received from the controller, when a record in the cache table is detected to have exceeded its preset lifespan, or when the configuration of the target drift address is detected to have changed, the corresponding record in the cache table is cleared.

[0205] Figure 6 This is a schematic diagram of another communication device provided in an embodiment of this application. Please refer to... Figure 6 The communication device is used in a target slave controller in a multi-controller storage system, which also includes a master controller and at least one other slave controller. The device includes:

[0206] The receiving module 61 is used to receive application layer data packets sent by the main controller. The application layer data packets are obtained by the main controller when it generates data to be sent to an external network address, determines the target drift address corresponding to this communication, queries the current position of the target drift address after the target slave controller is located, and encapsulates the data to be sent, the external network address and the target drift address.

[0207] The parsing module 62 is used to parse the data to be sent, the external network address, and the target drift address from the application layer data packet.

[0208] The second sending module 63 is used to send the data to be sent to an external network address using the target drift address as the source address.

[0209] In one possible implementation, the second transmitting module 63 is specifically used for:

[0210] Before sending the data to the external network address, perform a network layer reachability check on the external network address.

[0211] When the detection result indicates that the external network address is reachable, the system returns the network connectivity status indicating network reachability to the main controller and executes the step of sending the data to be sent to the external network address.

[0212] When the detection result indicates that the external network address is unreachable, feedback information indicating that the external network address is unreachable is returned to the main controller, so that the main controller can re-query the current location of the target drift address or redetermine the target drift address based on the feedback information.

[0213] The communication device provided in this application embodiment can execute the technical solution shown in the above method embodiment. Its implementation principle and beneficial effects are similar, and will not be described again here.

[0214] Figure 7 This is a schematic diagram of the structure of a communication device provided in an embodiment of this application. Please refer to... Figure 7 The communication device may include a memory 71 and a processor 72. Exemplarily, the memory 71 and the processor 72 are interconnected via a bus 73.

[0215] Memory 71 is used to store program instructions;

[0216] The processor 72 is used to execute the program instructions stored in the memory, so that the data processing device performs the method shown in the above method embodiment.

[0217] The communication device provided in this application embodiment can execute the technical solution shown in the above method embodiment. Its implementation principle and beneficial effects are similar, and will not be described again here.

[0218] This application provides a computer-readable storage medium storing computer-executable instructions, which are used to implement the above-described method when executed by a processor.

[0219] This application embodiment may also provide a computer program product, including a computer program that, when executed by a processor, can implement the above-described method.

[0220] All or part of the steps in the above-described method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a readable memory. When the program is executed, it performs the steps of the above-described method embodiments; and the aforementioned memory (storage medium) includes: read-only memory (ROM), random access memory (RAM), flash memory, hard disk, solid-state drive, magnetic tape, floppy disk, optical disc, and any combination thereof.

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

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

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

[0224] Obviously, those skilled in the art can make various modifications and variations to the embodiments of this application without departing from the spirit and scope of this application. Therefore, if these modifications and variations to the embodiments of this application fall within the scope of the claims of this application and their equivalents, this application also intends to include these modifications and variations.

[0225] In this application, the term "comprising" and its variations can refer to non-limiting inclusion; the term "or" and its variations can refer to "and / or". The terms "first", "second", etc., in this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. In this application, "multiple" refers to two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. The character " / " generally indicates that the preceding and following related objects have an "or" relationship.

Claims

1. A communication method, characterized in that, A master controller applied in a multi-controller storage system, the multi-controller storage system including the master controller and at least one slave controller, the method comprising: When the main controller generates data to be sent to an external network address, it determines the target drift address corresponding to this communication. The data to be sent, the external network address, and the target drift address are encapsulated into an application layer data packet; Query the current position of the target drift address; When the current location of the target drift address is at the target slave controller, the application layer data packet is sent to the target slave controller, so that the target slave controller can parse the data to be sent, the external network address and the target drift address from the application layer data packet, and send the data to be sent to the external network address with the target drift address as the source address. The target slave controller is any slave controller in the multi-controller storage system.

2. The method according to claim 1, characterized in that, The step of encapsulating the data to be sent, the external network address, and the target drift address into an application layer data packet includes: The data to be sent, the external network address, and the target drift address are encapsulated using an application layer protocol to obtain the application layer data packet; The header of the application layer data packet carries the external network address, communication port number, target drift address, and service communication protocol type; the service communication protocol type is used to indicate the application layer communication protocol followed by the data to be sent.

3. The method according to claim 1, characterized in that, After sending the application layer data packet to the target slave controller, the method further includes: The target receives the network connectivity status returned by the controller; the network connectivity status is obtained by the target from the controller after parsing the data to be sent, using the target drift address as the source address to perform network layer reachability detection on the external network address; When the network connectivity status indicates that the network is unreachable, the current location of the target drift address is re-queried, or the target drift address corresponding to this communication is re-determined, in order to attempt to resend the data to be sent; If resending fails within a preset number of attempts, a message indicating that the data to be sent has failed is returned to the service module that initiated the data to be sent.

4. The method according to claim 1, characterized in that, The method further includes: When the current position of the target drift address is located at the main controller, the data to be sent is parsed from the application layer data packet; Using the target drift address as the source address, the parsed data to be sent is sent to the external network address.

5. The method according to any one of claims 1 to 4, characterized in that, The method further includes: After successfully sending the data to be sent to the external network address, the correspondence between the external network address and the target drift address used in this communication is added to the cache table; Before querying the current position of the target drift address, the cache table is queried first; if the target drift address corresponding to the external network address exists in the cache table, the target drift address in the cache table is directly determined as the target drift address corresponding to this communication. When the target drift address is detected to have drifted, when the target receives network unreachable feedback information from the controller regarding the external network address, when the record in the cache table exceeds the preset lifespan, or when the configuration of the target drift address is detected to have changed, the corresponding record in the cache table is cleared.

6. A communication method, characterized in that, A target slave controller applied in a multi-controller storage system, the multi-controller storage system further including a master controller and at least one other slave controller, the method comprising: The system receives application layer data packets sent by the main controller. These application layer data packets are obtained by the main controller when it generates data to be sent to an external network address, determines the target drift address corresponding to this communication, and finds that the current position of the target drift address is after the target slave controller. The system then encapsulates the data to be sent, the external network address, and the target drift address. The data to be sent, the external network address, and the target drift address are parsed from the application layer data packet; Using the target drift address as the source address, the data to be sent is sent to the external network address.

7. The method according to claim 6, characterized in that, The method further includes: Before sending the data to be sent to the external network address, a network layer reachability check is performed on the external network address; When the detection result indicates that the external network address is reachable, the system returns the network connectivity status indicating network reachability to the main controller and executes the step of sending the data to be sent to the external network address. When the detection result indicates that the network of the external network address is unreachable, feedback information regarding the unreachability of the external network address is returned to the main controller, so that the main controller can re-query the current location of the target drift address or redetermine the target drift address based on the feedback information.

8. A communication device, characterized in that, A master controller used in a multi-controller storage system, the multi-controller storage system including the master controller and at least one slave controller, the device comprising: The drift address determination module is used to determine the target drift address corresponding to this communication when the main controller generates data to be sent to an external network address; The encapsulation module is used to encapsulate the data to be sent, the external network address, and the target drift address into an application layer data packet; The location query module is used to query the current location of the target drift address; The first sending module is configured to send the application layer data packet to the target slave controller when the current position of the target drift address is located at the target slave controller, so that the target slave controller can parse the data to be sent, the external network address and the target drift address from the application layer data packet, and send the data to be sent to the external network address using the target drift address as the source address. The target slave controller is any slave controller in the multi-controller storage system.

9. A communication device, characterized in that, A target slave controller applied in a multi-controller storage system, the multi-controller storage system further including a master controller and at least one other slave controller, the device comprising: The receiving module is used to receive application layer data packets sent by the main controller. The application layer data packets are obtained by the main controller when it generates data to be sent to an external network address, determines the target drift address corresponding to this communication, and queries the current position of the target drift address after the target slave controller is located. The main controller then encapsulates the data to be sent, the external network address, and the target drift address. The parsing module is used to parse the data to be sent, the external network address, and the target drift address from the application layer data packet; The second sending module is used to send the data to be sent to the external network address using the target drift address as the source address.

10. A communication device, characterized in that, include: At least one processor; as well as A memory communicatively connected to the at least one processor; wherein, The memory stores instructions executable by the at least one processor, which, when executed by the at least one processor, enables the at least one processor to perform the method of any one of claims 1 to 5 or any one of claims 6 to 7.

Images