Posted by: Denny Cherry
Social Commentary, SQL Server, Storage
So I got an email from someone (and yes he told me that I can publish this post about it) because he was having an argument with his storage / systems team about LUN config for the SQL Servers. He wanted smaller LUNs so that they could be more easily moved around if performance problems showed up on the array. His storage / system folks big argument against this was that it was complex to setup, so they didn’t want to do it. When I got to this “argument” I knew that this blog post was coming.
As IT professionals our job is to design and build systems which meet the performance requirements of the applications which will sit upon them. And to keep those systems running for as long as the business determines that those systems are useful to making the company money. We as professionals (those that know me can stop snickering when I call myself a professional) shouldn’t be designing systems a specific way just because it is easier to do so. If that way doesn’t support the needs of the application then it is the wrong way.
In the case of storage, there are lots of systems out there that needs lots of LUNs for one reason or another (usually to spread the load out). After carving up the LUNs and presenting them to the SQL Server, you mount them as mount points and setup the dependencies in the cluster admin tool (this server is clustered I’m told) and you are done. There’s not much do “manage” from the disk level at this point on a day to day basis. If everything is sized correctly then the LUNs won’t need to be grown for quite some time and everything can just be left as is.
In short, quit being so lazy when designing systems. Don’t take the easy way out just because you can. Design the system correctly so that you don’t have to redesign it later. I can’t tell you the number of months that I’ve spent redesigning systems because they weren’t done correctly the first time. If you need help designing a system ask someone, there are lots of people who will be happy to help. But don’t make poor planning decisions just because you don’t want to do a little bit of extra work.