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