## 4.1.4  Client Connection Recovery After Takeover
Connection recovery after a takeover can be done with network-based IP redirection or network-based DNS redirection.
After a takeover, the client or the application server need to be able to continuously reach the SAP HANA system, no matter which system is currently the primary system after takeover.
After a takeover, the new primary database server is not aware of previous connections which existed between clients and the former primary server. If the client application does not issue a new request and keeps waiting
for a reply from the server, it will not receive an explicit request to close these connections from either of the servers and will keep waiting indefinitely. To prevent this, the SAP HANA client library supports the TCP keepalive feature provided by the operating system. This feature will lead the client to abort the invalid connection on its end and to trigger a reconnect after a specified period during which the former primary server is not reachable.
However, the default keepalive settings for the operating system (2 hours) may lead the client processes to wait for a long time before they abort the connection on their end and trigger a reconnect with the new primary system. For example, the default Linux settings leave the clients waiting for more than two hours before aborting the connection. For more information, see SAP Note 2053504 . For instructions on how to configure the keepalive settings to match your needs, see the corresponding documentation for your operating system.
There are different possibilities for enabling client connection recovery:
- IP redirection A virtual IP address is assigned to the virtual host name. In case of a takeover, the virtual IP will unbind from the network adapter of the primary system and bind to the adapter on the secondary system.
- DNS redirection In this scenario the IP for the host name in the DNS will be changed from the address of the primary to the address of the secondary system.
Both methods have their advantages. If there are no existing constraints, the IP redirection has the clear benefit of being faster to process in a script rather than synchronizing changes of DNS entries over a global network.
## Network-based IP Redirection
The principle of IP redirection is to define an additional "logical" host name (hana1, in the diagram below) with its own separate logical IP address (10.68.105.51), and then map this initially to the MAC address of the original host in the primary system (by binding it to one of the host's interfaces). As part of the takeover procedure, a script is executed which re-maps the unchanged logical IP address to the corresponding takeover host in the
secondary system. This must be done pair-wise, for each host in the primary system. The remapping affects the L2 (OSI layer 2: data link ) switching, as can be seen in step 4 of the following diagram:
<!-- image -->
IP redirection can be implemented using a number of actual techniques, for instance with the use of Linux commands which affect the network ARP tables (ip addr add/del…), by configuring L2 network switches directly, or by using cluster management software. Following the IP redirection configuration, the ARP caches should be flushed, to provide an almost instantaneous recovery experience to clients.
IP redirection requires that both the primary and failover host(s) are on the same L2 network. If the standby system is in a completely separate L3 network, then DNS redirection is the preferred alternative solution.
## Network-based DNS Redirection
DNS redirection is an alternative to IP redirection. DNS is a binding from a logical domain name to an IP address. Clients contact a DNS server to obtain the IP address of the SAP HANA host (step 1 below) they wish to reach. As part of the takeover procedure, a script is executed that changes the DNS name-to-IP mapping from the primary host to the corresponding host in the secondary system (pair-wise for all hosts in the system). From that point in time, clients are redirected to the failover hosts, as in step 2 of the following diagram:
<!-- image -->
<!-- image -->
This solution shares the advantage with IP redirection that there are no client­specific configurations. Further, it supports disaster recovery configurations where the primary and secondary standby systems may be in two completely different network domains (separated by routers). One drawback of this solution is that modifying DNS mappings requires a vendor-proprietary solution. Further, due to DNS caching in nodes (both clients and intermediate network equipment), it may take a while (up to hours) until the DNS changes are propagated, causing clients to experience downtime despite the recovery of the system.
HA/DR providers can inform external entities about activities inside SAP HANA scale-out (such as Host AutoFailover) and SAP HANA system replication setups. In a Python script actions can be defined which should be executed before or after certain activities (for example, startup, shutdown, failover, takeover, connection changed, service state changed). One example for these so-called hooks is moving virtual IP addresses after takeover in SAP HANA system replication. Additionally, external cluster management software can be used to perform the client reconnect after takeover. For more information, see Implementing HA/DR Providers .
## Related Information
Implementing a HA/DR Provider Connecting Using Active/Active (Read Enabled)
SAP Note 2053504