Data Centre site affinity and persistency

I have 2 data centers using GSLB for banking institution. I need to provide a solution for site persistence and affinity. The problem is as below:

 

 

During the process of establishing connections to the Internet Banking application a client will establish session persistence with a particular Proxy and Web Server in one of the available data center locations. A subsequent DNS request from a particular client may resolve to a different VIP address (i.e. second site), which would send the client to a BIG-IP LTM in a different site. This different resolution becomes a problem for the Internet Banking implementation and as a result a solution is required to ensure a client request is always routed to the data center in the original site as the initial request.

 

 

This is a common problem as large Internet Service Providers (ISP’s), and other organizations host a series of proxy servers that proxy client requests through to the ultimate destination (in this case my banking application). Some of those ISP’s can’t guarantee that client requests are ending up on the same proxy for the duration of a user sessions. Since each of those proxy servers will perform an independent query against the GTM when it comes to resolving the banking URL the same scenario as above could result i.e. a subsequent request is directed to the other site hence breaking affinity and ending the user’s session with banking application. If and how often this scenario could happen is hard to determine since it is dependent on proxy infrastructure and configuration of external companies.

 

 

To ensure all subsequent client requests are delivered to the original site, a location based cookies will be required as follows:

 

 

1. The client sends a lookup request for the online banking site to the DNS server.

 

2. The BIG-IP GTM server responds with the BIG-IP LTM VIP address of Site1

 

3. The client sends a GET request to the VIP address of Site1 with no cookie.

 

4. The BIG-IP injects the location cookie LOCATION=Sit1 to the response from the local server. Client-server interaction proceeds normally.

 

5. At some point in the future, the client sends another lookup request for online banking site to the DNS server.

 

6. This time the DNS server responds with the BIG-IP LTM VIP address of Site2.

 

7. The client sends a GET request to BIG-IP LTM VIP at Site2 with a location cookie of LOCATION=Site1. This cookie string matches the configured location cookie name (LOCATION), but not the cookie value (Site1). The BIG-IP LTM at Site2 searches through the list of location services checking the configured strings against the value in the cookie. In this case, a match is made on service Site1.

 

8. Service Site1 is configured as a destination service on the source group Site2. This service matches on the content rule configured on BIG-IP LTM at Site2. The BIG-IP LTM at Site2 forwards packets from the client to BIG-IP LTM at Site1.

 

9. Because the client already sent a cookie with the GET request in Step 7, there is no need to inject another cookie. Content rule processing continues with no changes. The server response goes back through BIG-IP LTM at Site1 to BIG-IP at Site2 to the client. The client is now stuck to the original site (online banking site) through BIG-IP LTM at Site2.