BI File Location on SAN

[pwpaton]

Hello Everyone,

We are close to implementing a SAN storage solution on our network. The primary reason is to utilize the Fibre Channel interface to allow is to relocate the fail-over node in our ServiceGuard cluster to another building on our campus and still connect to our QAD MfgPro databases from either node. The other SAN capabilities such as data consolidation, tape libraries, high availability, etc are secondary considerations. Our servers are HP N-4000's with Jamaica HASS enclosures shared between them. Access to individual disks is controlled by the ServiceGuard software. The intent is to migrate the databases from the Jamaica drives to the SAN. The SAN solution is based on HP VA7100 arrays and we will not be using the AutoRAID capability. We will use RAID 1+0 with the mirrors located with the fail-over node.

My question pertains to the BI files. My understanding is that, for best performance, each BI file should be located on its own drive. This is our current configuration, although this causes us to waste most of a 9.1Gb drive. With the SAN, however, the minimum drive sizes are greater (18Gb and we're actually considering populating the enclosures with 73Gb drives), so the wasted space is considerable, considering our average BI size on our production database is about 500Mb. How are others out there addressing this problem, or can anyone offer some advice?

Thanks,
Patrick Paton
Schefenacker Vision Systems

 

[toby.Harman]

I don't believe there is a solution to this. I certainly never found one!

The importance of BI on it's own disk is solely to do with transaction throughput. Essentially by buying extra disks for the .bi files you are buying performance.

You can consolidate multiple bi files from less transactional databases onto a single spindle, thereby getting "better" utilisation of the disks space.

This whole discussion comes down to whether or not you view your disks as space or spindles. For performance you should view them as spindles.

The AI files should be on spindles which do not contain other parts of the same database. This is to protect your AI files from being damaged by the same event that damages the database (after all, they are there for recovery!).

If you want the fastest performance, paying for an extra set of spindles is a relatively cheap way of achieving it.

If the waste of space is too much for you to handle :awink:, one suggestion is to use Solid State disks (Compaq used to sell them occasionally so they should be available thriough HP). These plug into the array just like ordinary disk - They jut cost rather a lot more!

 

[pwpaton]

Thanks Toby,

I think the question has become moot, though. I've discovered that, due to the way the HP VA7xxx virtual arrays work internally, you can't specify certain drives for specific uses. All of the installed drives are combined by the array to form a single storage 'space' which is then used to carve LUNs out of. You don't have any say over where the data actually lives physically on the drives. The array handles all of that. Then, depending on whether you use the AutoRAID or RAID 1+0 mode (it's got to be one or the other), you loose up to 50% of the raw capacity for redundancy. In our case, we loose the entire redundant array on node 2, also, as it's really just a mirror of the first array. Double redundancy, so to speak. In effect, we end up with 25% of the combined raw storage capacity as usable space. That's pretty hard to swallow, but I guess it's the cost of a disaster tolerant system.

Anyway, the best I can do is create dedicated LUNs and place my BI files on them, even though in reality they could be spread anywhere in the array. I don't know how it will effect performance. We're not using AI, yet (sorry Dan ;-)), but hope to in the future. I'll have to think about the ramifications for the AI file.

Patrick

 

[toby.Harman]

Eeek

This sounds almost like the bad old days of EMC (You can have whatever you like so long as you don't ask questions!).

I'll be honest here and say that my guess is someone is not telling you the whole truth. My guess is that there is someone inside HP who can help you - but theres are probably only a few people who really know how to make this stuff work.

If I was handed this I would be on the Sales guys desk from now until he delivered with threats like "Take this heap of junk away or get me someone who can configure it". A bit blunt but if he believes you can do it, it may get his attention.

I would also start making noises to management about your inability to performance tune your databases on this disk array!

Is the HP array based on the Hitachi True North platform?

Best of luck!