To Partition or not to Partition?

The way partitions work, at least the way I understand it is, if you want to provide extend administrative abilities to specific VIPs and Pools to other users, but not necessarily provide them with access to the entire configuration. Thus you can give say application owners to control thier own VIP and pools but not access other vips and pools they don't own and support.

 

 

I hope this helps

 

 

CB

 

 

Do you have a business requirement now or potentially in the future to logically separate configuration objects vertically so that one administrative user wouldn't be able to modify the configuration objects of another? If so, that would be a good reason to use partitions. If not, then it might not be worth the added complexity of using partitions.

 

 

Aaron

We have only had problems with partitions and have backed out of using them. The biggest issues we had with them is with iRules on each partition conflicting with the others. We wanted a 'dev' and 'qa' partition where an iRule could be promoted up through each one. The problem we ran into is that you can not have the same named iRule in different partitions and can't even use the same global variable names in different partitions. We had variables in one partition over-writing data in variables in the other partitions, took weeks to debug the issue with F5.

 

 

It is good if you just need simple administrative separation, but we were initially sold as allowing for 'virtual' LTM systems which is it not.

 

 

-Dan