Re: 10.2.0.2 EE RAC, RHEL4 and LVM2 support?

  • From: Mladen Gogala <gogala@xxxxxxxxxxxxx>
  • To: kevinc@xxxxxxxxxxxxx
  • Date: Sun, 23 Jul 2006 17:37:17 -0400

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

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

Other related posts:

  1. Home
  2. oracle-l
  3. Archive
  4. 07-2006