It appears that there is a significant change that I had overlooked in the new OBI 10.1.3.2, compared to the Analytics 7.8 version.
I had noticed that there was a new webcat structure, that was easy, but one of our contacts spotted that there is a new way of clustering the new Webcat.
Previously, each Webcat server (BI Presentation server) had it’s own copy of the webcat file, held within the Data folder.
If you had two or more webcat servers they would syncronise the contents of the webcat using a utility – something that did not work very well.
Now you have one webcat, irrespective of how many web servers you use. They all point to the same webcat.
This neatly solves the problems you get with Syncoronisation, but introduces one significant flaw – a Single Point of Failure.
What do you do? Put your webcat on a SAN, which has all the RAID you can get. Back up the whole webcat folder every night – obviously!
Now take snapshots of the webcat throughout the day, but be very careful how many you take. Too many will slow the system down.
One thing I have always felt though is that you should cluster for Customers’ High Availability requirements NOT for performance.
The majority of performance issues should be dealt with by database design, prudent Caching (with seeding), adequate memory, and ETL design. Only when these have been worked through should you look for that extra 5% from clustered servers.