Database clustering

Anon (no@email.com) on 9/30/11 wrote:
---------------------------

>I know the trick in your comment above about uptime also
>as it is often measured by averaging the components of the
>cluster and will naturally be lower then than an
>equivalently costed single system (or at least should be!)
>however that is not the point - uptime for the provided
>service can be significantly better - the figure that
>counts.
>

Actually it may be about services. Clustered sevices are quite vunerable to certain types of events that single-box services are not. Especially problems with network can bring clustered services down, while normal OS services don't care at all; what's more they don't have "private" networks to be dependant on. Same with other services; like dependance on time synch. between nodes or existance of voting disks, or state of cluster configuration files, IP conflicts, in case of Oracle even about DNS.

It seems that cluster service desingners are very cautions about hazards of concurrent acces to shared data, so they do it in a way that is very eager to bring the services down when some event or bad state occurs, while normal OS services can continue running on a partially broken system.

The second point is about repairing broken clusters, especially during non-typical failures. This may mean longer diagnostics and repair time for a cluster. Basically a complexity factor.

For a single box an OS & application repair may just mean reimaging / bringing back last snapshot of a boot LUN (assuming the data is on separate LUNs) plus applying latest patches. For a broken cluster you have to diagnose much more elements, like the ones I mentioned (some of which are external to cluster!). And if reinstall is necessary then making a cluster lasts longer and more likely to end in a failure.

On the other hand it may even be beneficial. The fact that your services go down when something is wrong may be a way to force a lousy IT departament to make things right: to fix their network switch infrastructure, to monitor systems more closely and react to warnings more eagerly.

Some of the problems of clusters can be mitigated by proper hardware design. Like not using core switches for private network but 2 small, private ones, in the same chassis as servers, and connected to the same power connect. Having multiple voting disks placed on differend disk groups or even arrays etc. All this adds to price of both purchase, configuration and later maintenance.

In a way it's bad to rely on a single cluster. You should have some backup plan in case it fails. Some compamnies I saw had a testing/development/teaching environment to which production database can be linked (as LUN) or recoverd from backup in case of cluster failing. For the time of the cluster repair development and courses would cease and this would work as production.

Or simply keep a second set of turned off standby hardware plus some LUNs with installed and configured database software.