Re: 2 node Architecture
- From: Luis Freitas <lfreitas34@xxxxxxxxx>
- To: ora-apps-dba@xxxxxxxxxxxxx
- Date: Fri, 30 May 2008 08:35:35 -0700 (PDT)
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
Other related posts:
