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.
Denny
2 Responses
Hear, hear!
As a DBA, it does get tiresome being made to feel guilty about asking the storage admin/sysadmin/network admin/etc for specific configurations. I’m just trying to provide the most robust data tier I can, which is what my company pays me to do.
One does have to be cognizant of ongoing support requirements, of course. There’s also a cost to administering systems, and the performance or reliability benefit to be realized always has to be weighed against the real cost of maintaining a system for the duration of its useful life.
More often than not, though, it’s not the ongoing maintenance cost that’s what you – or at least I – hears from people. It’s typically resistance based on not wanting the work dumped on their desks (with which I sympathize, obviously; I don’t like it when someone comes over and hands me a pile of fiddly work, either. That’s the job, though).
Really like this post Denny. All too often we think the job of application development is to make something that works and is easy for us to do, when in reality our job is to make the end user’s job easy, even if and when it is hard for us to do that.