System advise

[H.Merijn Brand (procura]

I've browsed through the subjects, but couldn't choose anything but general :)

We can give an advice to a customer about something we have no experience (yet). It's a scale far beyond we ever had to deal with

What (HP) system could we use for

- Database 1-2 Terabyte
- Strong I/O bound
- less than 100 users
- 7x24 uptime (max 2hour / year down)

[John Poff]

Hi,

We have similar requirements here, and we are running on an rp8400. We've been on it for over six months and we're real happy with it.

JP

[H.Merijn Brand (procura]

John, how many CPU's how many disks, how many memory?

[John Poff]

Hi,

We have 8 CPUs, 12 Gb of RAM. We are connected to an EMC array with about 4 Tb of disk. Our main application is an Oracle database, with about 1.4 Tb of disk allocated and about half of that used (and growing). We also use BCVs for backups.

JP

[Tom Maloy]

N-class is probably not enough.
A V-class or rp8400 with 12-16 CPUs and 12-16 GB RAM would probably be reasonable.

YMMV.

Tom

[A. Clay Stephenson]

It's difficult to tell you much without knowing a bit more about your application. It appears that you have a very I/O intensive but probably not a CPU intensive application. That distiction might determine whether you want a 7410 or an 8400. Of cource, your uptime requirements dictate that this be an MC/SG cluster and I would suggest that this at least two servers rather than relying upon VPars. I don't think the two hours per year dowmtime will be all that difficult to achieve - at least of the unplanned varity. It might be difficult to live with two hours of planned downtime per year but that too is probably okay within an MC/SG cluster. You would switch the package and do the updates. If this is Oracle, it does imply that the Oracle binaries do not move with the data. The real gotcha to meeting the uptime requirement is the time required to upgrade a database. Often those scripts will take hours to run on a large database.

The choice between EMC and perhaps HP's XP arrays will also have to be made but both are good. You also need to give a great deal of thought to the backup process.

[Paula J Frazer-Campbell]

Hi

A large database with high I/O does not necessarily mean that you have to have a server with lots of processors.

For the large database with lots of I/O you obviously require an efficient storage system. The structure of which is dependant upon the nature of the I/O (Read/Write ratio).

100 users can easily be handled by a 4 way N class with 4 Gig Mem..

I am afraid that the real answer is ???It Depends???.

Basically a LARGE database does NOT need a large server.

HTH

Paula

[Animesh Chakraborty]

hi,
If budget permits then go for Superdome 16 way with EMC disk and must use emc software PowerPath for I/O load balancing.
Also, I suggest to use 4 fible channel path to EMC which means a disk will have 3 alternate link beside primary link.

[Tom Geudens]

Hi Merijn,
We've got a server with very similar requirements I think ... :-)

Now 1-2 Terrabyte database ... are we talking Datawarehousing here ? That would also match with the I/O requests (high) and the number of users (low but important ones :-). However, it does not match with your requested uptime ...
Do you have more information with regard to the use of the server ? Is the database used for queries during the day, batchloads during the night ?

Ok, how did we set our datawarehousedatabaseserver up ? Server is N4000, 4 x 550Mhz CPU. 8Gb memory (we went for a non-HP solution there :-). We've got connection to the storage through four fibrechannels (and have a fifth one for the tapebackups). 2 connections are connected to an EMC Symmetrix (and loadbalanced with PowerPath). These Symmetrix disks are hardwaremirrored with SRDF (VERY expensive) and contain the tablespaces of the database that still change. The other 2 connections are connected to an EMC ClarIIon (no loadbalancing, 2nd link is for redundancy only). The ClarIIon disks only contain tablespaces that are read-only and thus do not need expensive hardwaremirroring (in case of emergency the database can be started without the read-only tablespaces).

Note : the four (three actually) links make for good I/O throughput (giving the database a lot of memory also helps :-), but any kind of mirroring (SRDF is no exception) hits you hard in the I/O throughput ... no way around it.

You might also want to read the SAME (Stripe And Mirror Everything) document. I know James posted it a while ago on the forums, but I just can't find it right know :-).

Hope this helps,
Tom

[Stefan Farrelly]

A fully speced N class or dual N class ServiceGuard cluster will be fine. All you need is to fill it full or I/O cards - either SCSI or Fiber. The more the better I/O you will get.

We run some N's here with 4 cpu's and 4-6Gb of memory and DB's in the several hundred GB category with multiple fibres to an EMC and performance is great.

[harry d brown jr]

Where and what is the database stored on?

an pair of RP84xx's in a cluster would do the trick.

I'd start, per server, with at least four if not six fibre cards and two gig-e net cards.

What are you using for backups??

live free or die
harry

[harry d brown jr]

I'd go with two cell's with 2 cpu's a piece.

at least 20GB of ram, 4 internal 36gb disks, 2 mirrored, 2 for swap/dump.

Hey, doesn't HP own a consulting company that could spec this out for you?

live free or die
harry

[H.Merijn Brand (procura]

Finally been able to asign the points, sigh.

Env data is still changing. If I (we) need more tips/tricks/advice (with a c), I'll come back. Thanks so far. [ We might not even get the project ]

[Volker Borowski]

Hi Merijn,

this will be a very hard one!

2 hours downtime a year and TB-Database means,
you will need a shadow database, otherwise, you might not be able to achieve a restore time of two hours !

Now you need to know in detail, how much redo-log information is written within two hours, this will give you the maximum delay, which you can have on the shadow database. I.E. if you have 10GB Redologs per day and your machine is able to recover 10GB of redologs in 1 hour, this would mean you can have the shadow database roughly two days behind the primary DB.

This will be a nice hardware deal, because you'll need lots of disks (mirrors and mirrored-shadowdisks) and lots of boxes, (primary DB-cluster node, failover DB-cluster node, shadow-DB-node and may be shadow-db-failover node, and I guess application servers as well).

But with this requirements, you should check your penalty clauses carfully if it come to operating this landscape.

Interesting Job.
Hope you get it!
Volker

[Brian M Rawlings]

With the high uptime requirement, and high I/O throughput needs, I agree with those above who have recommended a pair of clustered RP7410s, which should suffice for 1-2TB database. The only advantage the RP8400 has here is # of CPUs and double the RAM.

With heavy I/O happening, CPU cycles are not likely to be your bottleneck, and the RP7410 has 14 available I/O slots, all of which are monsters for I/O bandwidth, just what you are looking for.

The expected growth may be the key to whether RP7410 or RP8400 would be needed. If you spec out a 6-CPU RP7410 to work now, but expect 100% growth over 3 years, you're going to outgrow the RP7410 too soon. Then you would position the RP8400. This would be a decision for the customer to make, since cost is a factor too.

One other thing not mentioned is that, with this kind of uptime requirement, MC/Serviceguard clustering may not be workable, since if the database takes, say, 10 minutes to bring down, then move the package, then 10-20 minutes to restart (apps and all), you'd only get four "transitions" per year for planned maintenance.

I would suggest you look into the RAC (formerly Oracle Parallel Server) functionality Oracle offers with 9i database. The cost is pretty serious, although it has come down some from its former incarnation. What RAC offers is "continuous access", rather than "high availability". This is very important for extreme high-uptime environments. Running RAC, if you lose one of the servers, the other takes up the transaction, finishes it, and then keeps running without a restart of anything. Much better.

At least mention RAC to the customer, sometimes they realize that attainable uptime is not worth the cost, or sometimes they go for it.

Regards, --bmr