Re: 2 node Architecture

  • From: "James Morrow" <morrow.james@xxxxxxxxx>
  • To: ora-apps-dba@xxxxxxxxxxxxx
  • Date: Fri, 30 May 2008 12:04:06 -0500

That may be the case, but the vast majority of Linux implementations
are on an x86
architecture which has (particularly prior to the advent of multi-core
chips) had significant
scalability limitations.  (Even with multi-core, x86 SMP linearity
isn't yet on par with most
RISC architectures).

I don't dispute the capabilities of the Itanium architecture, but the
adoption rate of that
(now 7 year old) platform has been less than stunning to this point.
However, given
HP's stated intent to replace their PA-RISC product line with Itanium,
I suspect that
will begin to change in the future.

As to Infiniband, it is not generally available on the afformentioned
x86/Linux boxes.

For what it's worth, the incorporation of Itanium and Infiniband also
tends to trend
against the "commodity" appeal of most Linux implementations (and more towards
"big iron" market).

-- James

On Fri, May 30, 2008 at 10:35 AM, Luis Freitas <lfreitas34@xxxxxxxxx> wrote:
>
>   There are benchmarks showing near-linear scalability with infiniband
> interconnect.
>
>   Also HP offers some large SMP intel boxes, same size as any of their HP-UX
> offerings, but these are based on Itanium and price is not much different
> from traditional Unix vendors.
>
>   Large boxes have NUMA, they are limited by the backplane bus speed. If you
> have a interconnect that has comparable speed you could get a comparable
> performance, with a properly tuned database workload.
>
> Regards,
> Luis
>
> --- On Fri, 5/30/08, James Morrow <morrow.james@xxxxxxxxx> wrote:
>
> From: James Morrow <morrow.james@xxxxxxxxx>
> Subject: Re: 2 node Architecture
> To: ora-apps-dba@xxxxxxxxxxxxx
> Date: Friday, May 30, 2008, 9:54 AM
>
> The "traditional" 2-node architecture (dbTier + appsTier [admin/CM] on
> one host
> and appsTier [forms/web] on the other) was essentially an outgrowth of the
> old
> single tier architecture.  When the front-end (forms/web) got
> "heavier" and
> scalability was required, it was moved off to a separate box.  The idea
> being
> that additional capacity could be added by "scaling out" (adding
> additional
> forms/web tier nodes) without increasing the size of the RDBMS server.
>
> The enabling factor there being (usually) private LANs between the nodes.
> The
> concurrent managers were kept on the same box as the database for two
> main reasons.
>
> First, the nature of the concurrent manager processes was thought to create
> significant network I/O going to the database.  Secondly, when you
>  had multiple
> forms/web tiers, putting the concurrent managers on them meant you'd have
> to
> configure parallel concurrent processing.  (I'm not sure when that feature
> was
> introduced).
>
> Multiple nodes is now especially popular with the advent of the "commodity
> hardware" (read:  "cheap hardware") based Linux OS on the scene.
> Unfortunately,
> due largely to hardware restrictions, Linux can't currently achieve the
> same
> level of "inside the box" SMP scalability that the "big
> iron" Unix
> vendors can.
> Fortunately, that degree of SMP scalability is really only important on the
> database tier.  Some will argue that "you can scale with RAC".  But
> the fact
> is that RAC, while it does have some scalability features, will never be
> able
> to achieve the same degree of "linearity" as inside-the-box SMP.
>
> So this brings us to one of Oracle's generally recommended architectures
> for
> the E-Business suite.
>
>
>       dbTier:         "big Iron" Unix (Solaris and the like)
>                       to achieve SMP scalability
>       appsTiers:      Linux (single or multiple boxes, shared
>                       applications filesystem).
>       additional:     hardware load-balancer (F5 BigIP, etc.) if there
>                       are 2 or more "forms/web" nodes.
>
> By going with this architecture, you have the "best of both worlds".
> While it
> *is* a heterogenus architecture, since ONLY the database is on Solaris
> (for example),
> it doesn't introduce the patching headaches that you'd have if the
> "appsTier"
> components were on different platforms.
>
> You get the large scale SMP scalability (quite linear up to significant
> numbers
> of CPUs) where it matters most (dbTier).  You get to REDUCE your
> database licensing
> costs (since the box is ONLY doing dbTier, you'd need [perhaps marginally]
> less
> capacity, therefore fewer CPUs [potentially]) on that node.
>
> You also get the "commodity hardware" advantages of
>  using Linux on
> the appsTier
> where scaling by adding boxes doesn't matter much.
>
> As with any multi-node configuration (for any application), you'll want to
> have
> high speed (gigabit these days) switch *private* LANs between the nodes for
> optimal performance.
>
> -- James
>
>
> On Fri, May 30, 2008 at 7:23 AM, Luis Freitas <lfreitas34@xxxxxxxxx>
> wrote:
>>
>>    I am using 11.5.10
>>
>> Regards,
>> Luis
>>
>> --- On Fri, 5/30/08, Pravin RC <pravinrc@xxxxxxxxx> wrote:
>>
>> From: Pravin RC <pravinrc@xxxxxxxxx>
>> Subject: Re: 2 node Architecture
>> To: ora-apps-dba@xxxxxxxxxxxxx
>> Date: Friday, May 30, 2008, 2:24 AM
>>
>> well, thats true, again which version of oracle u are using?
>>
>> On Fri, May 30, 2008 at 3:05 PM, Luis Freitas <lfreitas34@xxxxxxxxx>
> wrote:
>>>
>>> Hi,
>>>
>>>    It
>  was usual on the old days of 11.0, when network was 100Mbits to
> keep
>>> the CM/Reports and DB on the same node.
>>>
>>>    Nowadays as gigabit ethernet is common I have seen many
> installations
>>> with only the DB on one node, and everything else on the other, so you
> only
>>> have to apply patches to one node.
>>>
>>>    This depends on processor power too, CM/reports are CPU intensive,
> so
>>> if you dont have much cpu power or memory on the second node you may
> want to
>>> keep the CM/Reports on the database node to distribute the load.
>>>
>>> Regards,
>>> Luis
>>>
>>> --- On Fri, 5/30/08, Pravin RC <pravinrc@xxxxxxxxx> wrote:
>>>
>>> From: Pravin RC <pravinrc@xxxxxxxxx>
>>> Subject: Re: 2 node Architecture
>>> To: ora-apps-dba@xxxxxxxxxxxxx
>>> Date: Friday, May 30, 2008,
>  1:50 AM
>>>
>>> the only reason i can see is the network trafic, otherwise u can run
> all
>>> the services on different nodes.
>>>
>>> On Fri, May 30, 2008 at 12:25 PM, k srinivas
> <k.sridba@xxxxxxxxx> wrote:
>>>>
>>>> Hi DBAs,
>>>>
>>>> In Multinode setup with 2 nodes,usually we go for
>>>>
>>>> DB/CM/Report server one one node
>>>> and
>>>> Forms/Web server on second node
>>>>
>>>> Whts the logic behind DB/CM/Report sever on same node.
>>>>
>>>> Thanks in advance.
>>>>
>>>>
>>>
>>>
>>> --
>>> Affectionately Yours
>>> Pravin R C
>>
>>
>>
>> --
>> Affectionately Yours
>> Pravin R C
>>
>
> ---------------------------------------------------------------------
> James J. Morrow
>  | Senior Oracle Applications DBA
> morrow.james <at> gmail <dot> com
>



-- 
----------------------------------------------------------------------
James J. Morrow | Senior Oracle Applications DBA
morrow.james <at> gmail <dot> com

Other related posts: