Forum Discussion

Kenny_Barnt's avatar
Kenny_Barnt
Icon for Altostratus rankAltostratus
Jul 23, 2018

Hot-Hot Datacenters with DNS LTM APM SSO

We are getting ready to undertake a major change to our Application Delivery architecture to help improve our DR positioning. Right now we have an HA pair of BIG-IP units running LTM and controlling access to web resources with APM using various WEBSSO methods. We are going to be adding a pair of BIG-IP DNS nodes, one in each of our data centers, as well as another LTM/APM node in our DR data center. We intend to have the LTM/APM pair in our primary site still in a HA failover pair, but the LTM/APM node in our DR site independent.

 

One of the DR goals from leadership is to actually have applications that support it run in a hot-hot configuration, where traffic would be load-balanced (via BIG-IP DNS) between the main and DR sites.

 

One question I've been unable to pin down is how that will play with our use of APM. Is there a way to have APM sessions sync between the main site and DR site without the rest of the configuration synching?

 

APM
apm sso
application delivery
BIG-IP DNS
security

4 Replies

Sort By
  • RossVermette's avatar
    RossVermette
    Icon for Nimbostratus rankNimbostratus
    Jul 24, 2018

    I went through something similar but couldn't find a way to replicate APM sessions to devices that were in different device clusters. We ended up creating a dedicated (reverse proxy)Virtual Server that fronted all our other APM enable vs. We used an iRule that would set a cookie to maintain Data Center persistence. The catch here is you need a link/connection between the F5 BiGIPs between Data centers so they can forward the traffic appropriately.

     

    Look at the following links for details of what we ended up with: https://devcentral.f5.com/s/feed/0D51T00006i7gtQSAQ

     

  • Kenny_Barnt's avatar
    Kenny_Barnt
    Icon for Altostratus rankAltostratus
    Jul 24, 2018

    Thanks, Ross. I think that gets us a little closer to knowing what we need to know. Our situation is a little different (though I don't know that it will matter) in that we will have some applications that will be live in both data centers, but others that would only be in the primary DC, so our concern is more about clients getting one application in the primary DC, and another in the secondary.

     

  • RossVermette's avatar
    RossVermette
    Icon for Nimbostratus rankNimbostratus
    Jul 24, 2018

    Another available option is to use GTM with "global availability option" defined in the pool for the wide ip. (It's similar to priority group activation in LTM, so all your client would resolve/connect to your primary pair of F5s and if they become unavailable, then GTM would resolve to the secondary pair in the other DC only if the primary become unavailable. (Note clients would have to re-connect/re-authenticate as the F5s in opposite DC wouldn't have any APM session states/info) But with this you wouldn't have active/active between DCs, it would be more of Active/standby for apps between DCs. Good luck, let us know what you come up with or if you have any other ideas!

     

  • Andy_McGrath's avatar
    Andy_McGrath
    Icon for Cumulonimbus rankCumulonimbus
    Jul 25, 2018

    You cannot have APM active-active as stated in K13983: BIG-IP APM HA deployments

     

    ...you must deploy HA configurations for APM traffic groups in an active-standby-standby (N + M) topology.

     

    You can use F5 DNS and set persistence to try and ensure once a user is sent to a DC they will stick to it, however this has its problems if using public DNS servers and you will likely find users will flip due to ISP DNS configuration which is out of your control.

     

    So your only real option it you want true active-active data centres, and not rely on F5 DNS persistence, is to look into a data centre affinity solution.

     

    Best option is for you to set a cookie with a value related to each DC and have LTM query this cookie value in an iRule or Policy and if it doesn't match it local value to forward to the other DC.

     

    The difficult bit is making sure you only forward traffic when required and not if users have been forwarded due to a failure in the one DC. So need a method of checking availability of the remote DC Virtual Server/s you will be forwarding too.