Re: RAC or Large SMP...?
From: DA Morgan <damorgan_at_psoug.org>
Date: Fri, 10 Oct 2008 06:12:55 -0700
Message-ID: <1223644373.335231@bubbleator.drizzle.com>
>
> Our analysis of costs and ROI came out about the same, plus we found
> that if we hit the max load, adding another large SMP box was going to
> be a lot more cost and would likely add a lot more power than needed
> than adding another node to the RAC. As we have seen fairly steady
> increase in processing power requirements rather than large jumps, RAC
> seemed a better choice and we get the additional risk mitigation.
>
> I'm also not convinced that the fewer servers are easier to administer
> arguement is as valid these days. This was certainly true in the past,
> but modern package management has become quite sophisticated.
> Managing larger numbers of servers dedicated to the same role isn't that
> much of an overhead anymore. At least we haven't seen a substantial
> increase in administration since moving to RAC. In fact, the added
> fault tolerance has reduced impact and stress on staff when hardware
> failures occur.
>
> Tim
Date: Fri, 10 Oct 2008 06:12:55 -0700
Message-ID: <1223644373.335231@bubbleator.drizzle.com>
Tim X wrote:
> DA Morgan <damorgan_at_psoug.org> writes:
>
>> At Oracle OpenWorld in 2005 I built a 24 node cluster on the third >> level of Moscone West. We had someone from Sun price it out using >> SMP and RAC. The difference in price, for just one comparable SMP >> machine as compared to our one RAC cluster was in excess of $250,000 >> USD. That pays for a lot of training. >> >> There is a word that describes companies with a single large SMP >> box at a single location. That word is "vulnerable."
>
> Our analysis of costs and ROI came out about the same, plus we found
> that if we hit the max load, adding another large SMP box was going to
> be a lot more cost and would likely add a lot more power than needed
> than adding another node to the RAC. As we have seen fairly steady
> increase in processing power requirements rather than large jumps, RAC
> seemed a better choice and we get the additional risk mitigation.
>
> I'm also not convinced that the fewer servers are easier to administer
> arguement is as valid these days. This was certainly true in the past,
> but modern package management has become quite sophisticated.
> Managing larger numbers of servers dedicated to the same role isn't that
> much of an overhead anymore. At least we haven't seen a substantial
> increase in administration since moving to RAC. In fact, the added
> fault tolerance has reduced impact and stress on staff when hardware
> failures occur.
>
> Tim
And one argument I didn't make but you reminded me of ... try to perform a rolling upgrade on an SMP box.
It may not be perfect with RAC but I can guarantee you it is impossible with a single server.
-- Daniel A. Morgan Oracle Ace Director & Instructor University of Washington damorgan_at_x.washington.edu (replace x with u to respond) Puget Sound Oracle Users Group www.psoug.orgReceived on Fri Oct 10 2008 - 08:12:55 CDT