Why should you care about how you lay your storage out? Maybe because it’s your job or because it’s the right thing to do. Perhaps it’s because your application performance isn’t acceptable or your boss won’t let you buy shelves full of 15K RPM disks anymore. It’s not uncommon for pure frustration to stream out of a CIO’s mouth regarding how expensive enterprise storage is and that they’re “sick of throwing fibre channel disks at a problem”.
Even if your array does this “automatically” or you’ve got performance to spare, here are some things to keep in mind as you scale:
1. Analytics tools are your best friend – If you have no instrumentation, you’re flying blind. Your storage should allow you to see what’s going on underneath the covers so you can track down performance issues. Third-party tools to do this are available but make sure you buy the analytics tools when you purchase an array. We want to know if latency is horrible or if IOPs are high but throughput is low.
2. Workloads on the same RAID groups should be complimentary (caveat, see #3) – If you’ve got SQL and Exchange, try putting SQL log LUNs on the Exchange data LUN RAID group and Exchange log LUNs on the SQL data RAID group. Don’t put two of the same type of workloads in the same RAID group and expect harmony.
3. Pick an array that has some sort of QoS – If you’ve got the space and want to put the video storage on the same RAID group as SQL logs, do it but make sure you can put some restrictions on video if SQL should get better performance.
4. Monitor performance periodically and move LUNs to different tiers – If you’re using a ton of the expensive fibre channel disk space for an app that doesn’t need the performance, move it to more dense fibre channel or SATA disks.
If you have a finite budget and need to be more mindful of storage costs, this will all start to mean something. If you’re lost and don’t know how to begin monitoring then ask a storage systems engineer for help or call your SAN vendor’s support line.
