SAN policies: general rules of thumb?

Question

I'm being tasked with defining SAN policies for an external organization. I'm not a sysadmin, these aren't systems we have any authority over. I'm also no SAN expert. Whoever said work had to make sense?

I've come up with a few bullet points based on the documentation provided by the vendors involved (which the external org that will is currently running the SAN has not bothered to look into). Things like "don't put high I/O test storage on the same slice as Prod data stores" which seem like they should be obvious but clearly weren't.

Any recommendations on general SAN conventions that should be in place to improve performance and reliability?

Specific to our setup (EMC hardware, DB2) these are the key items I have:

• Ideally each Logical Unit (LUN) of the SAN will be spread across multiple physical devices to allow concurrent I/O thus improving performance.
• Each LUN should be dedicated to single use (e.g. the DB2 store for a particular application)
• For DB2 transaction logs should be located on a separate LUN on a physically separate spindle or set of spindles from the table data
• Data LUNs should be RAID-5 as it provides the best performance though with reduced redundancy
• Log LUNs should be RAID-10 to provide maximum redundancy
• If LUNs are set up to use file systems instead of raw partitions (which is recommended) tablespaces should use the NO FILE SYSTEM
• CACHING clause to improve performance

Answer 1

Before writing a policy, it'd be useful to know what you're trying to define a policy for. Is it for optimal performance? Data protection? Something specific in regards to company retention policies? Can we assume it's just a generic performance/reliability document based on your statement?

The reason I ask is that a SAN (like any network equipment) is usually customized to fit a role. It's hardware configuration can greatly affect the recommendations one might make for it. For example, SQL LUNs are generally best when they're made up of a numerous fast drives (spindle dependent) whereas something like user shares or archive data is better suited to larger, slower volumes (you seem to be aware of this). That said, I'd be hard pressed to definitively define a RAID level since different vendors have various views of it. For example, EMC might feel RAID10 is preferred whereas NetApp feels a 24 spindle RAID 6 is ideal.

Generically I'd say:

• Isolate data LUNs from database/log LUNs
• RAID levels and spindle counts should be determined by the application and vendor recommendations
• Put low priority data (like user shares and archive data) on slowest disks
• Ideally database/log LUNs have several small, fast drives to increase spindle count
• I/O intensive apps should be split between controllers (if that is an option)
• If you have a test environment that should be isolated to limit its impact on the production environment (separate controller/volume)

It's going to be difficult to give you more beyond those very generic options because you start getting into vendor, hardware, and application specific recommendations. You also get into security and company policy. You'd probably have better success in defining requirements for a specific application than creating a generic SAN guide.