Re: 10.2.0.2 EE RAC, RHEL4 and LVM2 support?

On 07/23/2006 05:02:35 PM, Kevin Closson wrote:
>
> The only slogan I can come up with for this is
> "The land of the free and the brave". Folks, GFS
> forces you to have a node that does not host RAC instances
> dedicated to their lock manager.... and then that is a
> single point of failure...but I hear you can cluster the
> lock manager...is that 4 nodes for 2 node RAC?
>
> All this central lock manager madness is just crazy. There
> are fully distributed, symetric, resilient, journalled
> CFS offerings out there. One runs on VMS and the
> other runs on Linux and Windows. I can tell you where
> to get the latter :-)
>
> How "free" is that open source stuff afterall?
>
>

Kevin, ASM is just one among free offerings of equal quality. At the moment, the only proper thing to do, when creating a RAC database is to buy a proper clusterware from the vendor of choice. In case of Linux, there are only two viable vendors: Symantec (Veritas) and Polyserve. If the data is important enough to protect it with a redundant machine, I don't see a problem in buying an appropriate cluster manager. Trying to save money on the cluster manager side amounts to inviting a disaster. Redundancy is expensive and has always been.
I would also question the wisdom of choosing Linux to run your failure resistant database. If you need an urgent support because your database is down, you need the best technical support that the industry can offer. That is not Red Hat's support. Oracle marketing has been extremely successful in marketing RAC, maybe even a bit too successful for their own good. People are using RAC just out of curiosity, sometimes they don't even understand the concepts (I've heard a story about "iSCSI adapters" that would make you laugh) and, of course, are running into problems. The question to ask about RAC are the same as they were 10 years ago, for OPS:

1. What data I need to protect by hardware and software redundancy?
2. How much am I willing to pay for that?
3. What will happen in the event of an outage? How long of an outage can I tolerate?
4. In case of problems, who will help me and under what conditions?

Much of the present day RAC hysteria is created by selling RAC as a massively parallel machine which will solve all your problems, without having to actually buy a mainframe. Linux is unsuitable for that purpose for many reasons. One of the reasons is that Linux is a "black box" system which is notoriously difficult to fine-tune and control. Linux is also a system with some extremely bad and non-performing solutions in the area of I/O drivers. SCSI protocol is implemented as an emulation, on the level above the normal device drivers, which results in the increased number of interrupts and much higher bus contention on the machines with already questionable I/O capabilities. Idea of having 4 server boxes from Dell clustered around a NetApp box and ASM providing the same throughput as an IBM mainframe at a fraction of the cost is just ludicrous. I usually see it considered by the same people who are trying to hire me for $70,000 a year. The real cause of the problem is the invasion of PHB types into the management positions. Cost cutting goes a long way. Instead of an experienced professional with an extensive industry experience, companies tend to hire paper shredders from the now defunct Anderson Consulting, just because they look nice in a suit and will work for peanuts and Baby Ruth candy bars. Not only have the salaries fallen drastically, the offered quality has fallen too. The new breed, the generation X management, likes to live dangerously and experiment with cheapo RAC. I wish they'd try bungee jumping with open source, one-size-fits-all cords instead of RAC. There wouldn't be many complaints if the cord is too long or not elastic enough, like in case of ASM, OCFS or GFS.

-- 
Mladen Gogala
http://www.mgogala.com

--
http://www.freelists.org/webpage/oracle-l