RAID with SAN

S

SSuhaib

Member
Hi,

I have 2 queries :

1) One of our consultant told us that SAN has its own stripping & mirroring system and it does not use RAID 10 or any form of RAID for that matter. Is that true.

2) DB blocksize of a DB is 8K wheareas linux OS block size is 4k. Does it effect performance of the system.

Thanks in advance.
 
You are not mentioning your Progress/OpenEdge version or what SAN.

  1. AFAIK, some SAN vendors name their technologies different, some don't. When the Progress/OpenEdge database files will be located on the SAN you should not be satisfied with the answer from the consultant. Instead he should be able to explain to you what the technology is all about and not what it's not. Uses it's own technology, IMHO, does not fit in the category sufficient answer. Especially if it may be the case in the future that performance issue land on your table.
  2. General rule of thumb:
    • Never, never, never DB blocksize smaller FS blocksize - it's really bad, bad, bad, bad ...
    • DB blocksize equal or a multiple of FS blocksize is okay.
      • Depending on the Progress/OpenEdge version you are running having the DB blocksize bigger than the FS blocksize introduces a risk of silent database corruption.
HTH, RealHeavyDude.
 
This kind of BS has been going on since the dawn of computing. It is a major red flag. Be very, very wary of this "consultant". He is either deliberately trying to deceive you or he has allowed himself to be deceived by someone else.

Believing that you don't need to understand how something works is the #1 cause of intractable performance problems.

You should demand a clear, plain english and verifiable explanation of the SAN's workings. If the consultant cannot provide one or you cannot independently verify it then he doesn't actually know what he's talking about and you should not implement that technology.

(If you tell us what sort of SAN it is someone here may actually know how it works.)

As RHD says, a DB block size which is a multiple of the OS block size is fine (the "OS block size" that matters is actually the memory "page size" -- file systems are no longer actually organized in blocks the way they used to be...). If you have your storage areas properly configured 8k db blocks should perform somewhat better than 4k blocks. Especially on heavy read workloads.
 
You know, I don't have any knowledge I can add to the discussion (Tom and RHD pretty much covered it), but I thought some might get a kick out of this, considering my past Infor rants.

A long, long time ago, in a galaxy where I wasn't fully in charge of IT yet, I was told to buy our new ERP system server from Infor. They wanted to sell me a SAN with the server--and, at the time, SAN technology was still incredibly expensive. They wanted over $100k for the SAN (without much disk--something like 500GB total). When I pressed them for a reason why...they didn't know. "It's faster." Faster than what, I asked. Why is it faster, I asked. How is it $100k faster, I asked.

Just dead silence was the only response I got. When we did wind up putting in a SAN a few years ago (for $20k, with--at the time--3 TB of disk), I knew what I was putting in and how it operated.
 
From what I have experienced most SAN vendors tell their prospects that it will be lightning fast and solve all their disaster recovery issues.

Seldom have I seen these promises come true for "lightning fast" and not once have I seen the "solve all your disaster recovery issues" com true.

Still you need a disaster recovery strategy set up - and your SAN will play a part in it, but it will never be THE disaster recovery strategy.

Only in those rare occasions when you have a really good consultant - one that understands what's the difference between plain file storage and a database of which parts are loaded into memory - helping you setting it up to fit your needs, you may succeed.

Regards, RealHeavyDude.
 
I'm currently reviewing a situation where a "high end" SAN has been purchased and then minimally configured in the worst possible way. For the money that was spent 4 "lesser", but far more appropriate, systems could have been purchased and properly configured to provide 10x the performance and all of the capabilities that are needed (but not implemented) in the high end box. The choice now comes down to 1) pouring money into the under configured box to expand it and get it up to snuff or 2) scrap it and put in something that is a better fit. I'm betting that IT will push for #1 with a lot of hand waving and goobledygook designed to divert attention away from the uncomfortable mistake that was made. And then wonder why management doesn't trust them.
 
Thanks all for your responses.

But still cant resist asking this: Does SAN has its own RAID ( whatever be the type of SAN), if so how different is it from disk attatched storages (DAS) devices which uses the standard RAID system.

Thanks again.
 
Without knowing what particular brand of SAN you're considering we cannot really say how it works.

But, in general, RAID of some sort is the foundation that SANs are built on. There is often a substantial RAM cache (to help hide the vile performance of RAID5 and its ilk) and high performance controllers as well.

The most important thing to remember is that parity based RAID (i.e. RAID5) will only provide a parody of performance. The RAM cache will often hide the performance problems quite well 98% of the time. But that other 2% of the time turns out to be the times when you need performance the most.

It is possible to have great success with a SAN but bad configuration is endemic in these systems. It always starts with the sales guy telling the customer they they no longer need to worry how it is setup.
 
Tom is absolutely correct--if you can provide the type of SAN, most likely someone can answer more specifically.

We have a Dell MD3000i (I can't afford the name brand stuff--just the store brand) and I manage the RAID levels that it uses. I actually have a couple of RAID groups of different types; some RAID 5, some RAID 10. It's all configurable by me.

Most likely the SAN you're investigating works similarly...the consultant just doesn't know or doesn't care about sharing the details.
 
You must log in or register to reply here.
Back
Top