Forum Discussion

tm500_165564's avatar
tm500_165564
Icon for Nimbostratus rankNimbostratus
Nov 05, 2014

F5 deployment strategy / Best practice

Hi all -

 

Let me start by saying I'm new to F5, and I'm coming from a Cisco ACE background. I'm looking to install some new F5 BIG IP 2000s to replace our ACE boxes. I've been doing a lot of reading regarding deployment methods, etc. and I guess I just wanted some input from the experts on device groups and "centralized" configuration.

 

Just for your info, I will have up to 5 BIGIP 2Ks for this new deployment. Load is not an issue at the moment because the load balancers in our enviroment are not heavily used. I am hoping to change that, but I'm mainly wondering what opinions you all would have on the below ideas based off your experience. Here are my questions:

 

1 - Is it considered a best practice to have all F5 boxes know of each other in some form of sync-only group? Even if some of the BIGIPs are internal or external(DMZ)?

 

For instance, I would deploy 3 BIGIP boxes internally and have them setup in a sync failover group, with administrative partitions for the different environments between non-prod and production. Then, the DMZ F5s are in their own sync failover group, but share a sync-only group with all boxes to allow for "central" administration? If you happen to have worked with Infoblox, it sort of has this "GRID" deployment methodology and I'm just curious if the same idea is behind device groups. This leads to question 2.

 

2 - Can you only sync certain partitions to difference devices in the cluster? Obviously for security reasons, I'd rather not sync internal configuration out to our DMZ. If it's not a possibility to sync only certain partitions then I will most likely not consider having the DMZ BIGIPs talk in anyway to the internal ones.

 

3 - Of the 3 internal, one of them could be broken off and only service lower environments. But I did like the idea of having a device trust group with all 3 and being able to manage configuration objects from essentially one interface. Thus, promoting configuration among environments will be a matter of working some CLI magic, etc.

 

For instance, one idea I had was to have the 3 of them in a device group, but have traffic classes for our production on 2 of them, and all lower environments going through the third.. where the third would be a standby backup for prod traffic should something drastic happen to 1 or 2.

 

Anyway, I hope I conveyed my questions well enough. Thanks in advance!

 

application delivery
deployment
design
LTM

2 Replies

Sort By
  • tm500_165564's avatar
    tm500_165564
    Icon for Nimbostratus rankNimbostratus
    Nov 05, 2014
    I should mention - we are not utilizing GTM.. only LTM and probably acceleration. Thanks!
  • R_Marc's avatar
    R_Marc
    Icon for Nimbostratus rankNimbostratus
    Nov 06, 2014

    I'm going to hedge. If all your F5's are in a single DC, then yes they could (in theory) all know about each other in some incestuous sync group. I could conceive of a configuration where that is true accross DC's (but there's a lot of other things that would need to be in place to make that work).

     

    It seems to me you are looking for something like BigIQ, which would, in theory, manage all your LTMs if centralized management is your primary goal, or integration into some orchestration tool, from which you could manage all your devices.

     

    I have 50-ish F5s deployed accross the globe doing LTM as well as many other modules. We manage them mostly via iApps, CLI and iControl and only sync between members on the same DMZ(s)/VLAN(s) (I have a couple cases where I have seperate DMZ's/VLANs which share the same security zone). You could, in your case where you have 5, have 3 on one DMZ with a traffic group limited to those 3, and another 2 on some other DMZ with traffic groups limited to those devices, but I think you'd run into operation issues unless you have a seriously disciplined organization. I've managed networks for more than 25 years and I've yet to find one of those.