A Redis-based NAPT gateway disaster recovery method

Abstract

This invention discloses a Redis-based NAPT gateway disaster recovery method. It uses Redis as the data channel for the NAPT gateway, removing the limitations of dedicated HA ports and synchronizing NAPT conversion information. The primary and standby gateways share the same NAPT conversion table. After disaster recovery, the synchronized NAPT conversion table is used to convert streams, ensuring no service interruption occurs during TCP connections. After identifying the primary and standby gateways, they are connected and synchronized. Redis is used as the data channel for synchronization between the primary and standby gateways. The primary gateway sends all configurations requiring synchronization to the standby gateway, and the standby gateway synchronizes all configurations from the primary gateway. This invention uses Redis as the data channel, effectively reducing development and adaptation difficulties, enabling rapid feature deployment, easy expansion, and significantly improving the stability of the data channel.

Description

Technical Field

[0001] This invention belongs to the technical field of NAT gateway high availability deployment, specifically relating to a NAPT gateway disaster recovery method based on Redis. Background Technology

[0002] In practical use of NAPT gateways, to ensure uninterrupted service and reduce downtime caused by power outages or program execution errors, which would prevent internal network users from accessing public network resources, HA (High Availability) deployment is generally adopted. However, existing solutions typically use a dedicated network port as the HA port for keep-alive between primary and backup machines, as well as for data and stream status synchronization. Since this port is a dedicated HA port and does not participate in data forwarding, it wastes hardware resources. In an era where device performance is nearing its limit and manufacturers are pushing the limits, this presents a potential breakthrough. With equivalent hardware, an additional network port can be added for forwarding services, reducing the pressure on device forwarding performance; conversely, with the same forwarding performance requirements, one less port can be added, reducing equipment costs. Secondly, the use of a dedicated HA port limits deployment flexibility. The two devices must be connected by a line, and cross-datacenter deployment requires adjusting the network cabling and adding a line connecting the two datacenters. Finally, due to the excessive number of data structures during HA synchronization, each message needs to be processed during the synchronization process. The code for encapsulating / decapsulating data is quite redundant, and different devices must have the same version to decode data correctly. When there are data differences between different versions, it can easily cause the system to crash during synchronization.

[0003] Existing patent CN201911393100.4 discloses a method to avoid TCP connection interruption during NAT gateway master-slave failover. This method addresses issues such as NAT translation asymmetry, TCP connection state synchronization, and reduced HA port waste by simultaneously sending packets to both the master and slave devices. However, this implementation only supports NAT gateways, not NAPT gateways. Since NAPT gateways translate source ports, and existing source port generation algorithms cannot guarantee that the ports generated by both devices are consistent, service interruption and TCP connection uninterruption cannot be guaranteed during master-slave failover due to port asymmetry. Secondly, both the master and slave devices' uplink or downlink interfaces need to be connected to the same VLAN switch to send packets, increasing deployment requirements. Furthermore, the slave device needs to continuously process all packets, leading to significant unnecessary energy consumption. In common solutions, the slave device does not need to process packets and operates in an idle state.

[0004] In summary, when deploying NAPT gateways in HA scenarios, if the primary NAPT gateway fails, the backup NAPT gateway will switch roles and become the primary NAPT gateway to continue forwarding services. This presents several problems: First, a dedicated HA port is needed to ensure configuration synchronization, status detection, and NAPT translation table synchronization between the primary and backup NAPT gateways, which undoubtedly increases deployment costs. Second, deployment is cumbersome for users, requiring the primary and backup servers to be placed in the same data center or additional network lines to be added. Third, synchronizing various data using the same channel consumes system resources during data encapsulation and decapsulation, impacting forwarding performance.

[0005] For the reasons mentioned above, this invention proposes a Redis-based NAPT gateway disaster recovery method. Redis is used as the data channel for the NAPT gateway, removing the limitations of a dedicated HA port and synchronizing NAPT conversion information. The primary and backup machines share the same NAPT conversion table. After disaster recovery, the synchronized NAPT conversion table is used to convert the streams, ensuring that TCP connections are not interrupted. Summary of the Invention

[0006] The purpose of this invention is to provide a Redis-based NAPT gateway disaster recovery method to solve the above-mentioned problems.

[0007] This invention is mainly achieved through the following technical solutions:

[0008] A Redis-based NAPT gateway disaster recovery method uses Redis as the data channel for the NAPT gateway, removing the limitations of dedicated HA ports and synchronizing NAPT conversion information. The primary and standby servers share the same NAPT conversion table. After disaster recovery, the synchronized NAPT conversion table is used to convert the streams, ensuring that TCP connections are not interrupted. The method includes the following steps:

[0009] Step S100: Deploy two NAPT gateways in the same data center or across data centers;

[0010] Step S200: Initialize the configuration of the NAPT gateway and configure the HA parameters of the NAPT gateway: configure the default HA deployment role of the NAPT gateway, the HA primary / standby election weight, the interface used for HA data synchronization and keep-alive, and the HA IP of the peer NAPT gateway;

[0011] Step S300: Activate the role modules of the two NAPT gateways and perform HA detection connection;

[0012] Step S400: Determine the role status of the two NAPT gateways, designate the NAPT gateway with the primary role as the master, and the NAPT gateway with the backup role as the standby.

[0013] Step S500: The master and standby machines are connected to the network and perform synchronization initialization. Redis is used as the data channel for synchronization between the master and standby machines. The master sends all the configurations that need to be synchronized to the standby machine, and the standby machine synchronizes all the configurations of the master.

[0014] Step S600: On the host, use the synchronization module to query events and check if there are any triggered events. If there are, select different Redis channels to send messages according to the event; otherwise, repeat the query until the set number of queries is reached. If no triggered event is found, perform a health synchronization check.

[0015] Step S700: In the standby machine, use the synchronization module to check if there are any messages. If there are, accept the message from the Redis channel and load it into the functional component. Otherwise, repeat the check until the set number of checks is reached. If no message is found, perform a health synchronization check.

[0016] To better realize the present invention, step S400 further includes the following steps:

[0017] Step S410: The role modules of the two NAPT gateways respectively detect the connection results of the HA probe connection. The NAPT gateway actively initiates an HA probe connection to the other NAPT gateway, denoted as Flow1, and the HA probe connection from the other NAPT gateway to the NAPT gateway is denoted as Flow2. The detection result is recorded as F1. If F1 is 0, proceed to step S300; if F1 is greater than 0, send F1 to the other NAPT gateway through the HA probe connection actively initiated by the NAPT gateway. After the NAPT gateway receives the detection result reported by the other NAPT gateway, it records the received detection result as F2.

[0018] Step S420: The role modules of the two NAPT gateways enter the role judgment state respectively to determine the relationship between F1 and F2. If F1 is greater than F2, then this NAPT gateway is set as the master and the other NAPT gateway is set as the standby. If F2 is greater than F1, then this NAPT gateway is set as the standby and the other NAPT gateway is set as the master.

[0019] To better implement the present invention, step S400 further includes step S430: if F1 equals F2, the role modules of the two NAPT gateways enter the role election state respectively, and report the HA primary / backup election weight and HA default deployment role of the NAPT gateway to the other NAPT gateway through the connection Flow1 of the NAPT gateway; if the HA default deployment roles of the two NAPT gateways are inconsistent, the NAPT gateway with the primary HA default deployment role is selected as the master, and the other NAPT master is selected as the backup; if the default deployment roles of the two NAPT gateways are consistent, the primary / backup election weight is determined, and the NAPT gateway with the larger primary / backup election weight is selected as the master, and the other NAPT gateway is selected as the backup.

[0020] To better implement the present invention, step S400 further includes the following steps:

[0021] Step S440: If the primary / backup election weights of the two NAPT gateways are consistent, the role modules of the two NAPT gateways enter the role random election state respectively, and randomly elect any one of the NAPT gateways as the host using a random hit algorithm. Since both NAPT gateways will conduct random elections at this time, the random value needs to be recorded to select the election result of one of the two NAPT gateways as the final result. This NAPT gateway reports the random value and the random election result to the other NAPT gateway through the connection Flow1. If the random election results of the two NAPT gateways are consistent, the random election result is directly used as the final result; if the random election results are inconsistent, the random values ​​of the two NAPT gateways are judged, and the random election result with the smaller random value is selected as the final result.

[0022] Step S450: If the random values ​​of the two NAPT gateways are also the same, then select the NAPT gateway with the smaller HA IP as the master and the other NAPT gateway as the backup.

[0023] To better implement this invention, further, in step S300, this NAPT gateway initiates an HA probe connection, accesses the HA probe port of another NAPT gateway, and repeats the probe connection within a set number of repetitions. If the connection is successful, proceed to step S410; if the connection fails, wait 10 seconds and initiate the HA probe connection again. If the number of retries reaches the default set number of retries and the connection still fails, it is considered that the other device is offline, and proceed to step S430 according to the configured default HA deployment role of the NAPT gateway; if the HA function of the NAPT gateway is turned off during the retry connection process, the process ends.

[0024] To better implement the present invention, step S500 further includes the following steps:

[0025] Step S510: The master's synchronization module starts the Redis service in Master mode, listens on the default Redis service port, and waits for the standby machine to connect; the standby machine's synchronization module attempts to initiate a network connection using the master's HA IP and Redis service port.

[0026] Step S520: The host uses the Redis pub / sub channels mechanism to send the default configuration data that needs to be synchronized in channel 'conf_sync'; the configuration data is synchronized according to the Redis hash, set and other data structure formats, and there is no need to encapsulate / decapsulate the data yourself, Redis will automatically complete the encapsulation / decapsulation of the data;

[0027] Step S530: The standby machine subscribes to channel 'conf_sync' and channel 'napt_sync'.

[0028] To better implement the present invention, further, in step S600, the host's synchronization module calls the event query function at 0.1ms intervals to query whether there is a configuration change event, a NAPT conversion table update entry event, a host health check failure event, and whether the host has disabled the HA function, or any one or more of these.

[0029] To better implement this invention, further, if the HA function is found to be disabled, the synchronization module of the host is stopped and the process ends; if a configuration change time event is found, the host enters the primary / standby synchronization-configuration synchronization state and sends the configuration data carried in the event in channel 'conf_sync'; if a NAPT translation table update entry event is found, the host enters the primary / standby synchronization-NAPT synchronization state and sends the NAPT data carried in the event in channel 'napt_sync'; if a host health check failure event is found, the host attempts to send a role adjustment message to the standby host without waiting for a response from the standby host and proceeds to step S300.

[0030] To better implement the present invention, further, in step S600, during the health synchronization check, the host enters the master-slave synchronization-health check state, and the host sends a KeepAlive message to the standby machine. If the standby machine responds, the health check is successful; if the standby machine does not respond, the host repeatedly sends the KeepAlive message. If the number of repetitions reaches the preset number of health check repetitions, a host health check failure event is created.

[0031] To better implement the present invention, further, in step S700, the standby machine's synchronization module checks whether there are messages in the channel at 0.1s intervals. If there are messages in channel 'conf_sync', the message in channel 'conf_sync' is accepted, converted into configuration data, and the configuration is loaded into the functional component through the configuration module. If there are messages in channel 'napt_sync', the standby machine enters the primary-standby synchronization-NAPT synchronization state, accepts messages in channel 'napt_sync', and loads the data in the messages into the standby machine's NAPT conversion table.

[0032] The beneficial effects of this invention are as follows:

[0033] This invention perfectly supports NAPT gateways, ensuring complete consistency of the NAPT translation tables between the primary and backup machines, thus resolving the issue of TCP connections causing service interruptions during disaster recovery. It reduces deployment requirements, eliminating the need for additional wiring or an extra network port; only one pair of network-reachable ports on the primary and backup machines is required. It also reduces the power consumption of the backup machine, which can operate in low-power mode without processing data packets, switching to high-power mode only when switching back to the primary machine. This invention uses Redis as the data channel, effectively reducing development and adaptation difficulties, enabling rapid feature deployment, easy expansion, and improved data channel stability. Attached Figure Description

[0034] Figure 1 This is a schematic diagram of the connection structure between two NAPT gateways;

[0035] Figure 2 This is a flowchart of the present invention. Detailed Implementation

[0036] Example 1:

[0037] A Redis-based NAPT gateway disaster recovery method uses Redis as the data channel for the NAPT gateway, removing the limitations of dedicated HA ports and synchronizing NAPT conversion information. The primary and standby servers share the same NAPT conversion table. After disaster recovery, the synchronized NAPT conversion table is used to convert the streams, ensuring that TCP connections are not interrupted. The method includes the following steps:

[0038] Step S100: Deploy two NAPT gateways in the same data center or across data centers;

[0039] Step S200: Initialize the configuration of the NAPT gateway and configure the HA parameters of the NAPT gateway: configure the default HA deployment role of the NAPT gateway, the HA primary / standby election weight, the interface used for HA data synchronization and keep-alive, and the HA IP of the peer NAPT gateway;

[0040] Step S300: Activate the role modules of the two NAPT gateways and perform HA detection connection;

[0041] Step S400: Determine the role status of the two NAPT gateways, designate the NAPT gateway with the primary role as the master, and the NAPT gateway with the backup role as the standby.

[0042] Step S500: The master and standby machines are connected to the network and perform synchronization initialization. Redis is used as the data channel for synchronization between the master and standby machines. The master sends all the configurations that need to be synchronized to the standby machine, and the standby machine synchronizes all the configurations of the master.

[0043] Step S600: On the host, use the synchronization module to query events and check if there are any triggered events. If there are, select different Redis channels to send messages according to the event; otherwise, repeat the query until the set number of queries is reached. If no triggered event is found, perform a health synchronization check.

[0044] Step S700: In the standby machine, use the synchronization module to check if there are any messages. If there are, accept the message from the Redis channel and load it into the functional component. Otherwise, repeat the check until the set number of checks is reached. If no message is found, perform a health synchronization check.

[0045] Preferably, step S400 includes the following steps:

[0046] Step S410: The role modules of the two NAPT gateways respectively detect the connection results of the HA probe connection. The NAPT gateway actively initiates an HA probe connection to the other NAPT gateway, denoted as Flow1, and the HA probe connection from the other NAPT gateway to the NAPT gateway is denoted as Flow2. The detection result is recorded as F1. If F1 is 0, proceed to step S300; if F1 is greater than 0, send F1 to the other NAPT gateway through the HA probe connection actively initiated by the NAPT gateway. After the NAPT gateway receives the detection result reported by the other NAPT gateway, it records the received detection result as F2.

[0047] Step S420: The role modules of the two NAPT gateways enter the role judgment state respectively to determine the relationship between F1 and F2. If F1 is greater than F2, then this NAPT gateway is set as the master and the other NAPT gateway is set as the standby. If F2 is greater than F1, then this NAPT gateway is set as the standby and the other NAPT gateway is set as the master.

[0048] Preferably, step S400 further includes step S430: if F1 equals F2, the role modules of the two NAPT gateways enter the role election state respectively, and report the HA primary / backup election weight and HA default deployment role of the NAPT gateway to the other NAPT gateway through the connection Flow1 of the NAPT gateway; if the HA default deployment roles of the two NAPT gateways are inconsistent, the NAPT gateway with the primary HA default deployment role is selected as the master, and the other NAPT master is selected as the backup; if the default deployment roles of the two NAPT gateways are consistent, the primary / backup election weight is determined, and the NAPT gateway with the larger primary / backup election weight is selected as the master, and the other NAPT gateway is selected as the backup.

[0049] Preferably, step S400 further includes the following step:

[0050] Step S440: If the primary / backup election weights of the two NAPT gateways are consistent, the role modules of the two NAPT gateways enter the role random election state respectively, and randomly elect any one of the NAPT gateways as the host using a random hit algorithm. Since both NAPT gateways will conduct random elections at this time, the random value needs to be recorded to select the election result of one of the two NAPT gateways as the final result. This NAPT gateway reports the random value and the random election result to the other NAPT gateway through the connection Flow1. If the random election results of the two NAPT gateways are consistent, the random election result is directly used as the final result; if the random election results are inconsistent, the random values ​​of the two NAPT gateways are judged, and the random election result with the smaller random value is selected as the final result.

[0051] Step S450: If the random values ​​of the two NAPT gateways are also the same, then select the NAPT gateway with the smaller HA IP as the master and the other NAPT gateway as the backup.

[0052] Preferably, in step S300, this NAPT gateway initiates an HA probe connection to access the HA probe port of another NAPT gateway and repeats the probe connection within a set number of repetitions. If the connection is successful, proceed to step S410; if the connection fails, wait 10 seconds and initiate the HA probe connection again. If the number of retries reaches the default set number of retries and the connection still fails, it is assumed that the other device is offline, and proceed to step S430 according to the configured default HA deployment role of the NAPT gateway; if the HA function of the NAPT gateway is turned off during the retry connection process, the process ends.

[0053] Preferably, step S500 includes the following steps:

[0054] Step S510: The master's synchronization module starts the Redis service in Master mode, listens on the default Redis service port, and waits for the standby machine to connect; the standby machine's synchronization module attempts to initiate a network connection using the master's HA IP and Redis service port.

[0055] Step S520: The host uses the Redis pub / sub channels mechanism to send the default configuration data that needs to be synchronized in channel 'conf_sync'; the configuration data is synchronized according to the Redis hash, set and other data structure formats, and there is no need to encapsulate / decapsulate the data yourself, Redis will automatically complete the encapsulation / decapsulation of the data;

[0056] Step S530: The standby machine subscribes to channel 'conf_sync' and channel 'napt_sync'.

[0057] Preferably, in step S600, the host's synchronization module calls the event query function every 0.1ms to check whether there is a configuration change event, a NAPT translation table update entry event, a host health check failure event, or whether the host has disabled the HA function, or any one or more of these events.

[0058] Preferably, if the HA function is found to be disabled, the synchronization module of the host is stopped and the process ends; if a configuration change time event is found, the host enters the primary / standby synchronization-configuration synchronization state and sends the configuration data carried in the event in channel 'conf_sync'; if a NAPT translation table update entry event is found, the host enters the primary / standby synchronization-NAPT synchronization state and sends the NAPT data carried in the event in channel 'napt_sync'; if a host health check failure event is found, the host attempts to send a role adjustment message to the standby host without waiting for a response from the standby host and proceeds to step S300.

[0059] Preferably, in step S600, during the health synchronization check, the host enters the master-slave synchronization-health check state, and the host sends a KeepAlive message to the standby machine. If the standby machine responds, the health check is successful; if the standby machine does not respond, the host repeatedly sends the KeepAlive message. If the number of repetitions reaches the preset number of health check repetitions, a host health check failure event is created.

[0060] Preferably, in step S700, the standby machine's synchronization module checks for messages in the channel every 0.1s. If there is a message in channel 'conf_sync', it accepts the message in channel 'conf_sync', converts it into configuration data, and loads the configuration into the functional component through the configuration module. If there is a message in channel 'napt_sync', the standby machine enters the primary / standby synchronization - NAPT synchronization state, accepts the message in channel 'napt_sync', and loads the data in the message into the standby machine's NAPT conversion table.

[0061] This invention perfectly supports NAPT gateways, ensuring complete consistency of the NAPT translation tables between the primary and backup machines, thus resolving the issue of TCP connections causing service interruptions during disaster recovery. It reduces deployment requirements, eliminating the need for additional wiring or an extra network port; only one pair of network-reachable ports on the primary and backup machines is required. It also reduces the power consumption of the backup machine, which can operate in low-power mode without processing data packets, switching to high-power mode only when switching back to the primary machine. This invention uses Redis as the data channel, effectively reducing development and adaptation difficulties, enabling rapid feature deployment, easy expansion, and improved data channel stability.

[0062] Example 2:

[0063] A Redis-based NAPT gateway disaster recovery method uses Redis as the data channel for the NAPT gateway, removes the limitations of dedicated HA ports, and completes the synchronization of NAPT conversion information. The primary and backup machines have the same NAPT conversion table. After disaster recovery, the synchronized NAPT conversion table is used to convert the stream, ensuring that the TCP connection will not experience business interruption.

[0064] like Figure 1 As shown, the NAPT gateway includes a role module, a synchronization module, and functional components. Figure 2 As shown, the present invention includes the following steps:

[0065] Step 1: Deploy two NAPT gateways in the same data center or across data centers, start the machines, and proceed to Step 2.

[0066] Step 2: Perform initial configuration and configure the HA parameters for the two NAPT gateways: Enable the HA function of the NAPT gateway, configure the default HA deployment role of the NAPT gateway, set the HA primary / standby election weight of the NAPT gateway (used for the NAPT gateway role module election host), set the interface of the NAPT gateway for HA synchronization data and keep-alive, and set the HA IP of the peer NAPT gateway (the interfaces reachable from both NAPT gateways must be selected, and the IPs on the interfaces must be in the same network segment), then proceed to Step 3.

[0067] Step 3: The role modules of both NAPT gateways are started, listening on the HA probe port. An HA probe connection is initiated to access the HA probe port of the other NAPT gateway. If the connection fails, wait 10 seconds and initiate the HA probe connection again. If the number of retries reaches the default retry limit, the other device is considered offline. The deployment role of the NAPT gateway is set according to the configured default HA deployment role, and proceed to Step 9. If the default retry limit is not reached, retries continue until a connection is successful, then proceed to Step 4. If the HA function of the NAPT gateway is disabled during the retry process, the process ends. If the connection is successful, proceed to Step 4.

[0068] Step 4: The role modules of the two NAPT gateways respectively detect the connection results of the HA probe connection. There should be an HA probe connection initiated by this NAPT gateway to the other NAPT gateway, denoted as Flow1, and an HA probe connection from the other NAPT gateway to this NAPT gateway, denoted as Flow2. Record the detection result as F1. If F1 is 0, proceed to step 3 and re-perform the HA probe; if F1 is greater than 0, send F1 to the other NAPT gateway through the HA probe connection initiated by this NAPT gateway. After this NAPT gateway receives the detection result reported by the other NAPT gateway, record the received detection result as F2 and proceed to step 5.

[0069] Step 5: The role modules of the two NAPT gateways enter the role judgment state respectively to determine the relationship between F1 and F2. If F1 is greater than F2, then set this NAPT gateway as the master and the other NAPT gateway as the standby, and proceed to step 8; if F2 is greater than F1, then set this NAPT gateway as the standby and the other NAPT gateway as the master, and proceed to step 8; if F1 is equal to F2, proceed to step 6.

[0070] Step 6: The role modules of both NAPT gateways enter the role election state respectively. Through the connection Flow1 of each NAPT gateway, they report the HA primary / standby election weight and the HA default deployment role of their respective NAPT gateways to the other NAPT gateway. If the default deployment roles of the two NAPT gateways are inconsistent, the NAPT gateway with the primary default deployment role is selected as the master, and the other NAPT master is selected as the standby, proceeding to Step 8; if the default deployment roles of the two NAPT gateways are consistent, the primary / standby election weight is determined, and the NAPT gateway with the larger primary / standby election weight is selected as the master, and the other NAPT gateway is selected as the standby, proceeding to Step 8; if the primary / standby election weights of the two NAPT gateways are consistent, proceed to Step 7.

[0071] Step 7: The role modules of the two NAPT gateways enter the role random election state, and a random hit algorithm is used to randomly elect one of the NAPT gateways as the host. Since both NAPT gateways will conduct random elections at this time, the random value needs to be recorded to select the election result of one of the two NAPT gateways as the final result. The random value and random election result are reported to the other NAPT gateway through the connection Flow1. If the random election results of the two NAPT gateways are the same, the random election result is directly used as the final result; if the random election results are different, the random values ​​of the two NAPT gateways are compared, and the random election result with the smaller random value is selected as the final result; if the random values ​​of the two NAPT gateways are also the same, the NAPT gateway with the smaller HA IP is selected as the host, and the other NAPT gateway is selected as the standby host, and proceed to Step 8.

[0072] Step 8: The two NAPT gateways disconnect from Flow1 and Flow2 respectively, and the role modules of the two NAPT gateways stop working. Proceed to Step 9.

[0073] Step 9: Since the role status of the NAPT gateway has been determined at this point, the NAPT gateway with the primary role will be referred to as the master gateway, and the NAPT gateway with the backup role will be referred to as the standby gateway. The synchronization modules of the master and standby gateways will begin to work. The master gateway proceeds to step 10, and the standby gateway proceeds to step 17.

[0074] Step 10: The primary machine enters the initial state of primary-standby synchronization. The primary machine's synchronization module starts the Redis service in Master mode, listens on the default Redis service port, and waits for a connection from the standby machine. If a standby machine connects, proceed to Step 11.

[0075] Step 11: The host enters the master-slave synchronization - configuration synchronization state. Utilizing the Redis pub / sub channels mechanism, it sends the default configuration data to be synchronized in channel 'conf_sync'. The configuration data is synchronized according to Redis's hash, set, and other data structure formats; no manual data encapsulation / decapsulation is required, as Redis will automatically handle this. After all configuration data has been sent, proceed to Step 12.

[0076] Step 12: The host enters the master-slave synchronization-waiting state. The host's synchronization module calls the event query function every 0.1ms to check for configuration change events, NAPT translation table update entries, host health check failure events, and whether the host has disabled HA function. If HA function is disabled, the host's synchronization module stops, and the process ends; if there are no events, Step 12 is repeated. If the number of consecutive repetitions reaches the preset time, the repetition count is checked, and then proceed to Step 16; if there are events, if the event is a configuration change event, proceed to Step 13; if the event is a NAPT translation table update entry event, proceed to Step 14; if the event is a host health check failure event, proceed to Step 15.

[0077] Step 13: The host enters the master-slave synchronization-configuration synchronization state, and sends the configuration data carried in the event in channel 'conf_sync'. After the data is sent, proceed to step 12.

[0078] Step 14: The host enters the master-slave synchronization-NAPT synchronization state and sends the NAPT data carried in the event in channel 'napt_sync'. After the data is sent, proceed to step 12.

[0079] Step 15: The host health check failed. Attempt to send a role adjustment message to the standby host. No need to wait for the standby host's response. Proceed to Step 3.

[0080] Step 16: The host enters the primary-standby synchronization-health check state. The host sends a KeepAlive message to the standby host. If the standby host responds, the health check is successful and proceeds to step 12. If there is no response, the KeepAlive message is sent repeatedly. If the number of repetitions reaches the preset number of health check repetitions, a host health check failure event is created and proceeds to step 12.

[0081] Step 17: The standby machine enters the initial state of primary-standby synchronization. The standby machine's synchronization module attempts to initiate a network connection using the primary machine's HA IP and Redis service port. If the connection is successful, proceed to step 18; if the connection fails, repeat this step until the connection is successful. After a successful connection, proceed to step 18; if the standby machine disables the HA function during the retry process, the process ends.

[0082] Step 18: The standby machine enters the primary / standby synchronization-waiting state and subscribes to channels 'conf_sync' and 'napt_sync'. The standby machine's synchronization module checks whether there are messages in the channels every 0.1s. If there are messages in channel 'conf_sync', proceed to step 19. If there are messages in channel 'napt_sync', proceed to step 20. Otherwise, proceed to step 21.

[0083] Step 19: The standby machine enters the primary / standby synchronization-configuration synchronization state, receives messages from channel 'conf_sync', converts them into configuration data, and loads the configuration into the functional components through the configuration module. After processing all messages, it proceeds to step 18.

[0084] Step 20: The standby machine enters the primary / standby synchronization-NAPT synchronization state, receives messages from channel 'napt_sync', and loads the data from the messages into the standby machine's NAPT translation table. After processing all messages, proceed to step 18.

[0085] Step 21: The standby machine enters the primary / standby synchronization - health check state, checks whether it has received a KeepAlive (heartbeat keep-alive) message initiated by the primary machine. If it receives the message, it replies to the primary machine. Proceed to Step 18.

[0086] This invention perfectly supports NAPT gateways, ensuring complete consistency of the NAPT translation tables between the primary and backup machines, thus resolving the issue of TCP connections causing service interruptions during disaster recovery. It reduces deployment requirements, eliminating the need for additional wiring or an extra network port; only one pair of network-reachable ports on the primary and backup machines is required. It also reduces the power consumption of the backup machine, which can operate in low-power mode without processing data packets, switching to high-power mode only when switching back to the primary machine. This invention uses Redis as the data channel, effectively reducing development and adaptation difficulties, enabling rapid feature deployment, easy expansion, and improved data channel stability.

[0087] The above description is merely a preferred embodiment of the present invention and is not intended to limit the present invention in any way. Any simple modifications or equivalent changes made to the above embodiments based on the technical essence of the present invention shall fall within the protection scope of the present invention.

Claims

1. A Redis-based NAPT gateway disaster recovery method, characterized in that, Using Redis as the data channel for the NAPT gateway removes the limitations of the dedicated HA port and completes the synchronization of NAPT transformation information. The primary and backup servers have the same NAPT transformation table. After disaster recovery, the synchronized NAPT transformation table is used to transform the streams to ensure that TCP connections are not interrupted. This includes the following steps: Step S100: Deploy two NAPT gateways in the same data center or across data centers; Step S200: Initialize the configuration of the NAPT gateway and configure the HA parameters of the NAPT gateway: configure the default HA deployment role of the NAPT gateway, the HA primary / standby election weight, the interface used for HA data synchronization and keep-alive, and the HA IP of the peer NAPT gateway; Step S300: Activate the role modules of the two NAPT gateways and perform HA detection connection; Step S400: Determine the role status of the two NAPT gateways, designate the NAPT gateway with the primary role as the master, and the NAPT gateway with the backup role as the standby. Step S500: The master and standby machines are connected to the network and perform synchronization initialization. Redis is used as the data channel for synchronization between the master and standby machines. The master sends all the configurations that need to be synchronized to the standby machine, and the standby machine synchronizes all the configurations of the master. Step S600: On the host, use the synchronization module to query events and check if there are any triggered events. If there are, select different Redis channels to send messages according to the event; otherwise, repeat the query until the set number of queries is reached. If no triggered event is found, perform a health synchronization check. Step S700: In the standby machine, use the synchronization module to check if there are any messages. If there are, accept the message from the Redis channel and load it into the functional component. Otherwise, repeat the check until the set number of checks is reached. If no message is found, perform a health synchronization check. Step S500 includes the following steps: Step S510: The master's synchronization module starts the Redis service in Master mode, listens on the default Redis service port, and waits for the standby machine to connect; the standby machine's synchronization module attempts to initiate a network connection using the master's HA IP and Redis service port. Step S520: The host uses the Redis pub / sub channels mechanism to send the default configuration data that needs to be synchronized in channel 'conf_sync'; the configuration data is synchronized according to the Redis hash and set data structure format, and there is no need to encapsulate / decapsulate the data yourself, as Redis will automatically complete the encapsulation / decapsulation of the data; Step S530: The standby machine subscribes to channel 'conf_sync' and channel 'napt_sync'.

2. The Redis-based NAPT gateway disaster recovery method according to claim 1, characterized in that, Step S400 includes the following steps: Step S410: The role modules of the two NAPT gateways respectively detect the connection results of the HA probe connection. The NAPT gateway actively initiates an HA probe connection to the other NAPT gateway, denoted as Flow1, and the HA probe connection from the other NAPT gateway to the NAPT gateway is denoted as Flow2. The detection result is recorded as F1. If F1 is 0, proceed to step S300; if F1 is greater than 0, send F1 to the other NAPT gateway through the HA probe connection actively initiated by the NAPT gateway. After the NAPT gateway receives the detection result reported by the other NAPT gateway, it records the received detection result as F2. Step S420: The role modules of the two NAPT gateways enter the role judgment state respectively to determine the relationship between F1 and F2. If F1 is greater than F2, then this NAPT gateway is set as the master and the other NAPT gateway is set as the standby. If F2 is greater than F1, then this NAPT gateway is set as the standby and the other NAPT gateway is set as the master.

3. The Redis-based NAPT gateway disaster recovery method according to claim 2, characterized in that, Step S400 also includes step S430: If F1 equals F2, the role modules of the two NAPT gateways enter the role election state respectively, and report the HA primary / backup election weight and HA default deployment role of the NAPT gateway to the other NAPT gateway through the connection Flow1 of the NAPT gateway; if the HA default deployment roles of the two NAPT gateways are inconsistent, the NAPT gateway with the HA default deployment role as the primary is selected as the primary, and the other NAPT primary is selected as the backup. If the default deployment roles of the two NAPT gateways are the same, then the primary / standby election weight is determined, and the NAPT gateway with the larger election weight is selected as the primary, and the other NAPT gateway is selected as the standby.

4. The Redis-based NAPT gateway disaster recovery method according to claim 3, characterized in that, Step S400 further includes the following steps: Step S440: If the primary / backup election weights of the two NAPT gateways are consistent, the role modules of the two NAPT gateways enter the role random election state respectively, and randomly elect any one of the NAPT gateways as the host using a random hit algorithm. Since both NAPT gateways will conduct random elections at this time, the random value needs to be recorded to select the election result of one of the two NAPT gateways as the final result. This NAPT gateway reports the random value and the random election result to the other NAPT gateway through the connection Flow1. If the random election results of the two NAPT gateways are consistent, the random election result is directly used as the final result; if the random election results are inconsistent, the random values ​​of the two NAPT gateways are judged, and the random election result with the smaller random value is selected as the final result. Step S450: If the random values ​​of the two NAPT gateways are also the same, then select the NAPT gateway with the smaller HA IP as the master and the other NAPT gateway as the backup.

5. The NAPT gateway disaster recovery method based on Redis according to claim 3, characterized in that, In step S300, this NAPT gateway initiates an HA probe connection to access the HA probe port of another NAPT gateway. The probe connection is repeated within the set number of retry attempts. If the connection is successful, proceed to step S410. If the connection fails, wait 10 seconds and initiate the HA probe connection again. If the connection still fails after the default retry count is reached, the other device is considered offline. According to the configured default HA deployment role of the NAPT gateway, proceed to step S430. If the HA function of the NAPT gateway is turned off during the retry connection process, the process ends.

6. The NAPT gateway disaster recovery method based on Redis according to claim 1, characterized in that, In step S600, the host's synchronization module calls the event query function every 0.1ms to check for any one or more of the following: configuration change event, NAPT translation table update entry event, host health check failure event, and whether the host has disabled HA function.

7. A Redis-based NAPT gateway disaster recovery method according to claim 6, characterized in that, If the HA function is found to be disabled, the synchronization module of the host is stopped and the process ends; if a configuration change time event is found, the host enters the primary / standby synchronization-configuration synchronization state and sends the configuration data carried in the event in channel 'conf_sync'; if a NAPT translation table update entry event is found, the host enters the primary / standby synchronization-NAPT synchronization state and sends the NAPT data carried in the event in channel 'napt_sync'; if a host health check failure event is found, the host attempts to send a role adjustment message to the standby host without waiting for a response from the standby host and proceeds to step S300.

8. The NAPT gateway disaster recovery method based on Redis according to claim 1, characterized in that, In step S600, during the health synchronization check, the host enters the primary-standby synchronization-health check state, and the host sends a KeepAlive message to the standby machine. If the standby machine responds, the health check is successful. If the standby machine does not respond, the master machine will repeatedly send KeepAlive messages. If the number of repetitions reaches the preset number of health check repetitions, a master health check failure event will be created.

9. A Redis-based NAPT gateway disaster recovery method according to claim 1, characterized in that, In step S700, the standby machine's synchronization module checks for messages in the channel every 0.1s. If there is a message in channel 'conf_sync', it accepts the message in channel 'conf_sync', converts it into configuration data, and loads the configuration into the functional component through the configuration module. If there is a message in channel 'napt_sync', the standby machine enters the primary / standby synchronization - NAPT synchronization state, accepts the message in channel 'napt_sync', and loads the data in the message into the standby machine's NAPT conversion table.

Images