| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 2031.1 | apple != orange | NNTPD::"cherkus@buff.zk3.dec.com" | Dave Cherkus | Tue Apr 29 1997 12:28 | 12 |
| Re: scaling: The 17k number is quite new, the 30k number is getting
quite old. The 30k cluster used 300 MHz cpus, MC 1.0 boards, an
older operating system and compilers, rz28 disks.
Re: mode of operation: the main difference is the ASE will have two
instances of the database whereas the production server will have one.
I'm no db expert, but that usually presents operational difficulties
that should be avoided. Most folks don't like idle hardware, so
balancing the instances can be difficult.
Dave
[Posted by WWW Notes gateway]
|
| 2031.2 | some comments | ALFAM7::GOSEJACOB | | Tue Apr 29 1997 13:31 | 25 |
| re .0
If you are just looking for the failover capability I would always go
for ASE. Even if the recovery of the failed Oracle instance takes
longer. In the ASE case Oracle basically needs to recover from a
crashed database just like on a single node after a system crash.
With OPS the surviving instance will automatically recover the open
transactions of the failed instance while it keeps on running. So
clients connected to the surviving instance will just keep on working.
If you really want to exploit the resources of 2 machines and get your
database application to scale you need to put quite a bit of effort
into the database and application layout. A 'normal' database
application is usually not 'OPS ready'. In certain cases running an
existing database application on OPS without changes may even be slower
than on a single node.
On the other hand if your database and application can be 'partitioned'
scaling will be just fine; e.g. building several Oracle indexes in
parallel scales close to 100%.
Just my 2 Pfennige
Martin
|
| 2031.3 | Trying to summarise. | MEOC02::JANKOWSKI | | Wed Apr 30 1997 00:52 | 29 |
| Thanks for the responses.
I did not realise that the 17k and 30k results are from different
generations.
I also did not realise that the recovery of the database in a
production cluster may be faster than in ASE environment.
This may be important for very large and active databases when there
is a customer imposed limit on recovery time.
Trying to summarise the discussion so far I believe that the economics
are against TCR Production Server in the scenario described in .0
If the baseline single machine 2CPU configuration yields troughput
of 1, then from a cluster of two such machines we can expect
say 1.5 without significant programming work in the application.
By comparison the ASE configuration with the whole application
running on 1 node of 3 processors virtually guarantees nearly
1.5 throughput with no programming work and no licencing and
operational costs of running TCR Production Cluster and OPS.
This still leaves an idle second machine with 1 CPU in it
for failover prupuses.
And if 1 CPU is deemed not enough a second one can be purchased
for an equivqlent of about 10days work of an Oracle consultant. (:-)).
Is this a reasonable approach?
Chris Jankowski
Melbourne Australia
|
| 2031.4 | more comments | ALFAM7::GOSEJACOB | | Wed Apr 30 1997 07:41 | 18 |
| re .3
Well the recovery with OPS is not only faster but clients can access
the database (on the surviving node) all of the time. The clients which
were connected to the failed node will have to re-connect to the
surviving node though.
You also need to configure your I/O subsystem for media/controller/cable
failure. So if database downtime is not acceptable for any longer period
of time you would need to go for OPS. Remember you are basically using
2 (up to 4) machines to access the exact same data.
And for the 3 CPU/1 CPU setup you need to find out if the lesser
equiped system can sustain the normal user load (if that's required).
And you are also working on the assumption that the database
application scales with the number of CPU's on a single node. Which may
not always be the case.
Martin
|
| 2031.5 | Can the Applic fully use TruCluster ? | BROUGH::DAVIES | Hype is a 4 letter word ! | Wed Apr 30 1997 07:45 | 24 |
| I agree with .2 in that there are a lot of ORACLE applications out there
which WILL NOT RUN ON OPS. For example, An application uses X.25 for all its
transactions which are POS & Cash Machine Operations. The System holds the X.25
address of the caller and does a match on the incoming addres and allows the
call into the application. The applic also stores the PID of the PARENT process
so that it can tidy up. The application consists of many processes that
communicate to each other. There is also some hardware that just cannot be
shared, for example a DES Encryption module.
If you put all this together, you see that ASE is preferable to TruCluster.
But and its a BIG BUT, salesmen will always try to sell as much as possible.
I have been in the situation where I have had to explain to the customer that
his TruCluster is in reality a speedier ASE, in terms of Failover as you don't
have to failover ORACLE.
The merits of ASE vs TruCluster can be debated until the cows come home. It is
sometimes difficult to explain to both Sales & Customer why they should spend
a little less on Software (and buy more disk instead).
Unless the application can REALLY take full advantage of multiple instances etc
then play safe and go for ASE. If you are in any doubt, benchmark it.
Stephen Davies
|