| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Mailing Lists -> Oracle-L -> Re: 10g RAC without vendor clusterware
Matthew,
Thanks a lot for nice explanation.
I do not like clusters or at least what is called the cluster. A lots of components from different vendors that you cannot manage or even install.
Who ever did OPS or RAC installation knows how costly and hard is to get it installed and working. To not say which kind of tricks and design consideration you need to make you app working scalable on RAC.
Our biggest telecom customers are not even eager to consider RAC :)
My mane problem is that we have a lots of huge
customers whith multi-CPU servers (from 4 to 64 and
even more CPU's). I do not have the opportunity to try
Oracle 10g without clusterware that often, especially
on the HW/SW configurations they are going to use in
the production. I can imagine that nowdays even Oracle
cannot do proper testing with all SW - easy to see the
list of bugs.
That means recommending something or using something
that Oracle does not have a big reference site, while
dealing with real-time telecom systems (prepaid, ..)
looking crazy for the moment.
> In fact, I don't believe in RAC on large UNIX boxes.
> I think it misses the point.
Do you mean this because of the cost or something
else?
Hard to see the difference in is something big or
small, for me is similar.
One our customer is on 24-CPU box and no more space to
add CPU's, we recommended RAC and they refused of
course. Now we are changing the apps to work across
multiple non RAC Oracle nodes. In RAC case no need to
change apps, just to put different things across
different nodes. In that case 2 24 way nodes will be
fine, especially because some things can be nicely
partitioned. But anyway they will pay us too, not only
Oracle :)
Thanks again,
Zoran
>
> Well, see, here's the thing. I don't believe in
> third-party=20
> clusterware for RAC. At all.
>
> In fact, I don't believe in RAC on large UNIX boxes.
> I think it misses=20=
>
> the point.
>
> This is almost straight out of my standard
> talking-to-an-analyst spiel,=20=
>
> but here it is - RAC's achilles heel is its
> complexity. The only=20
> reason the Sun/IBM big box teams have any
> justification at all for=20
> their servers as an Oracle delivery platform is that
> RAC is hard to get=20=
>
> working, hard to understand, and hard to manage.
>
> The reason for that isn't just the new architecture
> - its that there=20
> are now additional moving parts. There's
> clusterware, possible volume=20=
>
> managers, possibly clustered filesystems, not to
> mention a different=20
> configuration and deployment process. All of that
> means complexity,=20
> which means time, which means money.
>
> When the clusterware is provided by a third-party -
> when its an=20
> addition vendor, a new version of an old software,
> its one more moving=20=
>
> part that has, in one way or another, been
> shoehorned into Oracle. On=20=
>
> top of that, the different clusterware technologies
> start to introduce=20=
>
> their own requirements above and beyond what oracle
> requires. More=20
> complexity.
>
> And for the privilege of that additional complexity,
> the third-party=20
> asks you to hand out additional money upfront, and
> every year=20
> thereafter for support.
>
> Oracle's clusterware, for 9i, is very stable. CRS -
> not so much so. =20
> To answer your specific questions, the problems we
> see currently=20
> revolve around the cluster occasionally hanging
> under specific=20
> circumstances - note that the cluster hang does not
> mean the database=20
> is unavailable, it just means that our neat
> "allocate processing power=20=
>
> on the fly" functionality doesn't work. The other
> problem is that the=20=
>
> CRS can occasionally reboot individual nodes in the
> cluster.
>
> I'm not arguing that CRS is a better product than,
> say, Veritas=20
> advanced edition for RAC. I'm arguing that it costs
> less, both in the=20=
>
> short and long-term.
>
> And yes, Oracle is fixing these problems. Are our
> customers 24 x 7=20
> with these problems? It really depends on your
> definition of 24 x 7. =20
> Is their application up and available and the system
> manageable all the=20=
>
> time? Yes.
>
> Thanks,
> Matt
-- http://www.freelists.org/webpage/oracle-lReceived on Tue Feb 15 2005 - 14:42:23 CST
 |
 |