To RAC or not to RAC

Today i’ve re-read mogens nogard (his name is unwritable for me, but also for him)  post on high avalability of last month. It is very interesting what mogens says.  I’ve recently read the book “Oracle Insights” from witch i desume that mogens is a step above others.

I completely agree with the quote “Complexity is the enemy of availability” , i’m conservative. So i think that technologies pushed to simplify management may became a boomerang.  On the other hand i think that RAC, with 10g standard edition has reason to be. It give us a little scalability at a competitive cost.

What mogens says in a comment is the real point:

“For political reasons you might have to implement all sorts of things, and I still haven’t found an effective way of preventing that from happening.”

Marketing and politics really drive our (mine) managers so i have to implement things that for me give no advantages.

however i’ve to say that my little experience with RAC, not about HA, is at last good.  What remains are all the bugs that we can encounter, with RAC as with Standalone instance.

RAC Virtual IP

At first installation of Oracle 10g RAC which i’ve seen, made by an Oracle consultant about two years ago (version 10.1.0.2.0 on Linux Suse EL on x86_64 platform) , the network configuration of Operating System were as this:

eth0: 10.0.100.1 private interconnection interface
eth1:198.168.33.1:”public” interface

apart from the fact that also with 10.2 release VIPCA complains that “public” interface has not a pubblic class IP, i’ve noticed another problem that i don’t know how to resolve: virtual IP is being created on first interface without possibility to change it, that is “eth0” that is the private interface. In a correct configuration such interface would be connected to a switch with other private interfaces of other nodes of the cluster, separated from “public” network to which would be connected “public” interface. With such architecture i would have:

eth0: 10.0.100.1 private interconnection interface
eth0:1 192.168.33.3 RAC VIRTUAL IP
eth1:198.168.33.1:”public” interface

VIP on eth0, on network card attached on private switch, not reachable from clients connected to public switch. NO GOOD. The only workaround that i’ve found is to reconfigure operating system (in new installations) to put private ip on lower interfaces (eth0) and public IP on higher interfaces.

Do anybody know a remedy for my first installation? Note, in that installation all interfaces are connected to the same switch and so all goes well. Something is not as high available as it may be, there are not redundant network interfaces.

hwclock and date

We use RAC with Linux, Standard Edition RAC, 10g with 2 nodes with no more than 2 CPUs per machine. Today i’ve encountered a systemistic anomaly. Some time ago i’ve noticed that time in a RAC instation was different between the two nodes. SO is Linux Suse EL 9. System administrator did not configured a sincronization mechanism for time so during a downtime period i manually setted time of one server “equal” to that of the other with “date” command. This morning someone rebooted (it really was a black-out) the machines and in /var/log/messages of one machine i’ve noticed a 20 minutes lag back in time:

5:45 ..
5:49 ..
6:02 ..
shutdown
5:41 ..

And so i’ve remebered what i’ve already noticed with my test of RAC installation on VMWARE virtual machines
System Clock is not Hardware Clock. When linux boots, it sets system time equals to hardware time and then it may diverge. So the moral is; use hwclock