Forum Discussion

Brian_Saunders1's avatar
Brian_Saunders1
Icon for Altostratus rankAltostratus
Dec 13, 2013

GTMs, Route Domains, and Sync Groups

Hey All,

 

I'm curious about an idea and would like to know if it's even possible. Let's say we have two GTMs, GTM_A and GTM_B. Is it possible to split the two GTMs into two seperate route domains (GTM_A_Partition_1, GTM_A_Partition_2, GTM_B_Partition_1, GTM_B_Partition_2)?

 

Is it then possible to have two separate sync groups that act independently from one another - example GTM_A_Partition_1 syncs with GTM_B_Partition_1 and GTM_A_Partition_2 syncs with GTM_B_Partition_2?

 

Thanks,

 

Brian

 

3 Replies

  • as you have already discovered, you can accomplish those requirements without the complication of partitions and RD's.

     

    Does the DR strategy and underlying infrastructure support dynamic failover or a manual? I think that will ultimately dictate how you deploy the GTM.

     

    I personally am of the mind of keeping it simple, but not so simple that it interferes with the use of the technology at our fingertips.

     

  • Well, I'm just thinking about all my options at this point and this idea is a bit more on the radical side. Basically here's the scenario. We have two DCs and 3 different LDNS sources querying WideIPs.

     

    • LDNS_Source_A -> should always resolve Server_A regardless of state
    • LDNS_Source_B -> should always resolve Server_B regardless of state
    • LDNS_Source_C -> should always resolve Server_A until we make Data Center A inactive and activate Data Center B without impacting LDNS_Source_A or LDNS_Source_B queries

     

    The idea would be to have partition 1 on each GTM handle requests from LDNS_Source_A and LDNS_Source_B, always returning the server that resides in the same data center as the source regardless of state. Partition 2 would handle requests from LDNS_Source_C based off the state of the Data Denter on the GTM (or whatever other topology methodology we develop later down the line).

     

    The same idea can be accomplished with just strictly topology and I have it mocked up in my lab and it works. But I don't like the idea of having a lot of topology records and also having to query for the specific pools and then enable / disable depending on the state of the data centers in the event of a DR.

     

    Brian