12 Drives, 2 controllers... what to do?

[jsohr]

Hi,

We have an HP N4000 with two 550 Mhz processors running HP-UX 11 and Progress 9.1D (no AIW). Databasize size is roughly 8 GB, and 140 self-service clients running.

We are have recently added 4 more drives to our HP Mod 20 array (with two controllers), for a total of 12 4.3 GB drives, and are looking to re-arrange our data layout.

Currently, on controller one we have 4 disks running RAID 0/1. These drives hold the application and some database extents. Controller two also has 4 disks running RAID 0/1 and holds the remainder of the database extents as well as the BI file.

Which new configuration would be "better":

1) On controller 1: 6 drives running RAID 0/1 for DB extents
On controller 2: 4 drives running RAID 0/1 for app code, logs, etc.
2 drives running RAID 1 for BI file
OR
2) On controller 1: 6 drives running RAID 0/1 for DB extents,app code
On controller 2: 6 drives running RAID 0/1 for DB extents, BI file

OR
something else???

The benefit of Option (1) is the BI file is on its own spindle, but the DB is only on six spindles-- whereas the benefit of Option (2) is the DB is spread across 12 spindles-- but they are shared with the application and the BI file.

Any opinions, or things I should look at to factor in?

Thanks,
James


BTW, the drives are SCSI-FWD (SCSI-2). If we went with Option 2, I presume we would look at splitting the busiest tables between Controllers 1 and 2...

 

[CtL]

You have resources to play with, and you've got a pretty good idea how to use them. Keep up this ugly trend and you'll put all us freelancers out of work!

Okay, I like the option #1. Option #2 is interesting, but it is almost always the case that if you have the choice between using the disks in a stripe, or breaking them up and manually balancing the extents, the stripe is better.

Reasoning: Even if you constantly monitor and tweak your db you will end up with the performance worse on a single disk set if your db is spread across more than one disk set. I've seen a number of sites where people elected to split their extents over disks, and there is always some (and usually a lot) of uneven IO loading. In a stripe, all the disks usually work equally hard. I say usually, because there are key blocks (Master Index Blocks) that are hit again and again, but with any sort of cache these just go to memory and are not an issue.

So...

You need three disks for your primary db... and you want mirror/stripe, so that eats up 6 disks. You should also have a dedicated controller. There go half your resources right there.

How about the same thing for the second set? It is a very good idea to seperate your AI/BI/Backups, I just saw a case where the AI and the db both got munged by a single bad controller. And yes, go AI, you should be able to with your setup.

One different option for the second 6 disks and controller is to go would be a single disk/mirror for your BI. Although this sounds like heresy (From an old movie: "Sir! You speak treason!" the answer: "Fluently!"), you might want to consider it. There is some degree of single threading in a BI (and AI). That would leave four disks (17 GB) for everything else, and possible a nice disk db backup area, although you would forgo mirroring for this.

Let us know what you end up doing!

 

[toby.Harman]

OK - my preferences for what they are worth...!

My Rules!!
1. Multi-path access to the data is good - therefore do the RAID 1 between controllers.
2. Multi-spindle volumes are good, therefore use RAID 0 on a controller.

3. You don't mention AI....... If you aren't using it you should consider it

My choice would be to
1. Buy some more disks! If you can still get 4.3GB drives then get as many as you can.
2. For the DB. On each controller set up a RAID0 (stripe) of 3 disks and then mirror them using HP-UX disk management. This gives you 6 disks in RAID0+1.
3. For the BI. On each controller select one disk and mirror using the HP-UX Disk management.
4. For the AI. Same as for the BI.
5. For the Application, Temp files, O/S etc use the last pair of disks.

Advantages of "software mirroring" (although all mirroring is actually software - it just where it runs!)
1. You can disable the mirror for an "instant backup".
2. If one controller fails (and they do eventually!) you should still be able to access the database.
3. Reads from the database can be handled by either controller, depending on which is busier.

Disadvantages
1. You nearly double the traffic over the bus to the controllers.
2. It is a little more tricky to administer.
3. It uses a little bit of CPU.

In this configuration you minimise the disk head contention over the BI and AI disks (nothing else is writing to them) which will reduce latch times for transactions. You still have 6 disks for the database.

This layout is fairly heavily optimised towards write intensive databases!

I would prefer to see the operating system spread out onto more spindles but that is a system admin choice!

Lastly I would get another controller set and 4 disks and create an unmirrored stripe set. This would be used as an area to back the database up to or for index rebuilds and sort files. This kind of area come in VERY useful when you need it, and can sit idle when you don't. It is not a waste of money, since you will reduce your disaster recovery time significantly by having this available.