RE: Scaledown hardware
- From: "Mark W. Farnham" <mwf@xxxxxxxx>
- To: <ax.mount@xxxxxxxxx>, <oracle-l@xxxxxxxxxxxxx>
- Date: Sun, 24 Sep 2006 19:53:38 -0400
Hmm. Well first of all .25 * 3600 is 900, not 1200.
Maybe that shouldn't even be first, though. It has been quite a few years
since I've done an actual "scale down service" under duress project.
However, since the alternative was that the IT department of the client was
to be told that DR was too expensive as an insurance policy, and hardware
was still very very expensive, they were happy to pay my rates and I was
happy to do the project.
But the first thing you need to do is figure out how much batch load you
have. After that you have to figure out whether it is possible to time shift
any of the batch load when operating under duress. Now some of that batch
activity *MAY* scale with interactive use. Figure out how much less it might
be at a service level to support one quarter of the normal interactive
throughput. The result is a SWAG of batch load that you cannot defer even
when operating under duress. So you do the math when you get those numbers,
but if you're at 70% with 30 active users it might easily be that 20% or 65%
of the machine load has nothing to do with the interactive users.
You probably also need to build a login control screen where you route folks
to a "sorry, try again later" screen if they would be the nth+1 active user
when you want to limit to n users.
Then, when you have that in place and you can easily toggle the number from
900 to 3600 (or 4000 or whatever), you need to arrange for a test under
normal conditions as a proof of concept. First you can establish just how
low you can toggle the active interactive users until you cannot transact
critical business. If the real answer is much higher than 25%, then you need
to adjust for the much more significant problem of doing the real horsepower
constrained test. Depending on the hardware and the OS you may be able to
simply software partition your hardware to a functionally less capable
state. Otherwise you may need to get a vendor loaner of the "25%" machine.
But for most businesses needing a 12 CPU server in the first place, it would
not be prudent to proceed without a real test under conditions where it is
easy to revert to full horsepower.
Lately though, after you figure out what the costs are for the above
exercise, you just call it a wash and buy a matching machine for business
continuation with the money you would have paid to make the test.
Now you *may* be able to shrink both machines a little by running deferrable
reports on the standby. That is only dependent on being able to identify the
reports and load from those reports that is deferrable, so it costs no where
near as much as a restricted horsepower and load test. You may also be able
to shift things like extractions to a datawarehouse to the standby, as long
as you remember to be sure that the upgrade of the business continuation
site and the newly commissioned remote site will happen within the time you
can operate without putting new data in the datawarehouse.
Make sure you include some "C" level folks in this decision loop. When the
CEO and CFO cast their attention on just what the operational logistics
would be to operate with limited computer resources it may affect your
budget.
_____
From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx]
On Behalf Of amonte
Sent: Friday, September 22, 2006 6:02 AM
To: oracle-l@xxxxxxxxxxxxx
Subject: Scaledown hardware
Hi
I am sizing a server for a database which will be used for disaster
purposes. It should support 25% of production load.
Right now I have a production server with 12 CPU and 48Gb memory, in peak
time 70% of CPU usage is observed (30 Active database users) and 40GB is
used. This supports 3600 users roughly.
Is this that simple divide my actual HW by 4? i.e 3 CPU and 12 GB to support
1200 users? I think I can do that for memory but not that sure for CPU
usage.
TIA
Alex
Other related posts:
