Forum Discussion

Ken_Cottrell's avatar
Ken_Cottrell
Icon for Nimbostratus rankNimbostratus
Aug 15, 2014

Looking for solution to keep LTM HA pairs syncronized across 2 data centers.

We have 2 LTM HA pairs, in 2 different data centers. Note: These are both 1 arm configurations. Data Center B HA pair is not yet in use. We are planning to move many of our VIPS to Data Center B and use GTM to determine where to send traffic. We would like to keep Pool, Profile, iRule and other such Data in sync between these 2 Data Centers. Since the Virtual Servers on each pair will have different IP addresses we cannot sync them. We are looking for a solution to ensure all Pool, Profile, iRule etc data are in sync between the 2 data centers. I understand that Sync Only groups are not intended for this purpose. Is anyone else doing this? Are there any tools available to help with this requirement?

 

10 Replies

  • Dual data centre synchronisation is an operational support role. There are no tools for this. The closest you will get is writing tmsh scripts to build the virtuals, pools and servers then maintaining that script for each site. In theory you could write one script and substitute the relevant information. However there is no guarantee this wont disrupt existing operations. It becomes messy very quickly. This is a short example to change pools but its not very clean. The moment something does not match exactly it falls down like a house of cards.

    for dc in d1 d2 d3 d4; do
      for vip in 1.1.1.1 2.2.2.2 3.3.3.3 4.4.4.4; do
        echo "modify /ltm virtual $vip pool newpool" >> run$dc
      done
    done
    
    for dc in d1 d2 d3 d4; do
      scp run$dc root@f5$dc:/root
      ssh root@f5$dc "tmsh < run$dc"
    done
    
  • shaggy's avatar
    shaggy
    Icon for Nimbostratus rankNimbostratus

    Another option could be custom iControl scripts to pull/compare/push config elements from data center A to data center B. Unfortunately, along with Kevin's response, there is no F5 tool for this, and any solution could become messy quickly if proper precaution and checks are not implemented with the solution

     

  • Hey Ken, an interesting conundrum that seems to come up every now and then. Unfortunately I'm not sure what the options are with Sync Only. Some food for thought regardless (hopefully someone might know more about Sync Only);

     

    • You could of course use manual processes but we all know how reliable they are.

       

    • You could use iControl and try and automate things somewhat, or at least make the duplication easier, especially if you 'script' the changes using REST 'commands'.

       

  • Thanks all for the feedback, I was afraid that this is what I would learn. I have been considering trying to write something to compare the bigip.conf files on a regular basis and possibly create a text file I could use with tmsh merge or something to update the other data center, but I'm not sure how tmsh merge treats an update to an existing stanza rather than just merging in a new stanza. I may also take a look at iControl, don't have much experience with that to date. If I come up with something useful will share it.

     

  • Come to think of it, validating configs between data centres is an ideal job for diff.

     

    You could pull the F5 config file bigip.conf from each host as this contains only the non-box specific information such as virtual's, pools, nodes. Then use diff to list differences. If the backend should be the same then the only differences you should find are the virtual IP addresses which then you could easily ignore. Any other differences you find could then be immediately flagged as an issue.

     

    Given we can verify our config this way you can then push config to multiple data center's using iControl. Then as part of your post change verification if there is anything other than the virtual configuration different between DC's you can immediately rollback the change.

     

    Of course this kind of system requires extensive testing, is usually written in-house using python or other iControl supported languages. It's just not a simple task as you need to understand the implications of changing objects on a live production F5 which usually houses many hundreds of applications, not just the one you are making a change for.

     

  • Isn't the F5 Enterprise manager capable of performing this replication ? I haven't used one in real-time, but have read.

     

    I see EM have got a virtual edition, worth a try.

     

    • Gregory_Thiell's avatar
      Gregory_Thiell
      Icon for Employee rankEmployee
      F5 Enterprise Manager won't keep your LTM devices in sync in real-time, but the templates and changesets in F5 Enterprise Manager allow you to deploy configuration objects from one device to as many devices as needed. https://support.f5.com/kb/en-us/products/em/manuals/product/em-templates-changesets-3-1-1/1.htmlconceptid You can create a template from an existing device configuration. The procedure is about the same for changesets. Check out "Creating a template based on an existing device's configuration" on this link: https://support.f5.com/kb/en-us/products/em/manuals/product/em-templates-changesets-3-1-1/2.htmltaskid
  • Bumping this topic to see if there has been any new solution. It is clear that the need is there. I have the same situation. I have two data centers. I would like to have the same configuration at both data centers with Big-IP DNS (GSLB) in front of it. When a pool changes it should change at both data centers. The difference would be that the virtual server addresses would be different between the two.. but health checks, pools, pool members, iRules, data tables and on and on need to be the same.

     

    I currently have processes for DR to 'clone' the configuration over to offline instances, but management is asking for an active / active setup with traffic balanced across both data centers to exactly the same virtual server configurations.

     

    Thank you!

     

  • I don't know what the functionality of the F5 Ansible module(s) is these days but this seems like a scenario where a tool like Ansible would be very useful. Of course, it won't help you with transferring the current configuration but if you deployed all further changes with Ansible (if support for everything you need exists) then there would be no need for synchronisation between devices, you would have full confidence the same change has been deployed on all devices.

     

    Differences with IPs etc. are easily handled with variables.