Management Center "Maximum number of policy revisions to store" best practice

Products

• Management Center
• Management Center - VA

Issue/Introduction

Management Center  feature allow Administrators to keep a previous copies of policies (e.g. CPL, VPM, Universal VPM etc) and scripts after saving iteration of policy or script.     The default are set  0 (unlimited)  and can be changed as needed. 

There are two areas "Maximum number of policy revisions  to store" where it can be set , they are :

•  Globally -  This setting  can be found under MC UI > Administration > Settings > General) .  Global configuration (screenshot below) applies for each policy, i.e.  if set as 100,  each policy would keep 100 maximum  (e.g. 5 policies reaching the set limit of 100  will be 500 total)   

•  Per policy.   This feature is available since MC version 3.3.2.1 and can be seen when creating new policy or by going to "Info tab" when editing a previously created policy (screenshot below) .  Policy level version control setting overrides global settings. 

You can not use CLI to configure any of the settings above.

Environment

Management Center  (MC) "Maximum number of policy revisions  to store" was left to default or set with very high numbers

 

Cause

Depends on the size of policy and how often policy change, leaving the settings to default and/or keeping hundreds of policy versions can be problematic with subtle  symptoms, such as:   

-  Disk usage nearing 85%, close to getting full or full.  Any of these condition could also cause inability to create MC backups. 

- Slow page rendering when  navigating, editing, saving policies. 

- Slow repository index rebuild, and may cause UI access to fail.

-  In rare cases viewing/searching, loading or editing a very large policy that has hundreds of versions will cause a high disk paging that could also lead to out of memory java heap space crashes.   

-  For deployment that has failover,  we also seen that after fully-synced-failover got disabled, the secondary MC  experienced a very slow ( i.e. > 30 minutes) repository index rebuild leading to  MC UI not accessible (i.e. serving 404 HTTP response).

Resolution

• For newly deployed MC, set  the global settings as 100 (or lower), save and activate.   No other steps needed to be done afterwards. 

 

• If MC has been in production for sometime, further steps are necessary  and may need to be executed during maintenance window:

 

• • Optional for MC Virtual appliance: From host device, shutdown /power off MC,  take a snapshot, power on MC.

1. Set  the global settings as 100 (or lower), save and activate.   Set a number globally (e.g. 100) even if you choose to configure the number per policy or not.  

• • Optional - if maintaining multiple policies, set a number on per policy for select policies as needed.  

Note: Setting the number globally or per policy does NOT purge the older version on its own.   Purging old policy versions happens every time a policy is saved.  

2. Edit and save the policy to start purging the old versions .  Changing a reference device and  save or; adding /  removing unused shared object from policy and save or;  launching / saving VPM should trigger the actual purge of older versions for said policy.  

Note: Dependent on policy size and versions to purge, the initial purge may take a while  and could cause browser connection to timeout (sample screenshot below) but the purge should continue at the background.  Clicking "save"  whenever error appears  or simply waiting for several minutes until MC becomes responsive again.

  

• • Optional - After the initial purge finished, revisit the "version" tab of the policy and note the highest and lowest number of policy, which should equal to the value set.     Saving policy would purge the oldest version while the policy version increment by one  (FIFO algorithm).  

3. Rebuild repository index by running  "service-action rebuild-repository-index" in MC CLI/SSH privilege/enable mode.

• • Optional: run "show disk-usage" before and after purging the policy and rebuilding the repository index.  You may see significant decrease of space being used  at data/bluecoat/bccm/rt/jcr/repository/index  directory.

Note: depends on the policy got purge in previous steps, rebuilding the repository index should NOT take more than 30 minutes.   

 

Additional Information

 

Future MC releases may change the Global default of "Maximum number of policy revisions  to store" to 100 (TBD).  This is planned to only affect new deployments.   

The current behavior of MC for   "Maximum number of policy/script revisions  to store" (along with other settings)  is to preserve its setting when doing upgrades, backup/ restore and replicated when using failover.  No plan to change this current behavior in future releases.