It happens everyday. Yet another SQL admin falls victim to the technical prejudice of those who provide their storage. It’s a sad story which is seen everyday throughout the currently developed world; at least those working in relatively well-funded companies. UNIX guys make fun of Windows people. Mainframe guys refuse to believe Windows is even available. Oracle guys say their DB is the king. The reality is that Window servers are here to stay in today’s datacenter – whether it’s in house or in the cloud is a story for the future.
My point is to reach out to all you application owners, and although I’m more of a storage guy, I do know a bit about applications and getting them to perform better. I know more about how companies bicker internally after visiting many, many customers with EMC. I give workshops to SQL, Exchange, and SharePoint app owners, and especially when the storage guy is sitting in the room, it seems like a therapy session.
Bad Performance = Bad Code or a Bad Config?
When it comes to SQL performance troubleshooting, a friend of mine always says, “it’s either bad code, or a bad config.” This is not entirely true – there are so many more things which can cause slow performance on a server – but it’s a reality of the situation which typically happens. The storage team says it’s something with SQL. The SQL admins revolt and demand it’s not their fault, and to see how the heck their storage was setup. These two groups are often at war with each other!
So, my friends, I come in peace as a friendly mediator, and I’d offer you these tips:
- Befriend a storage person. If you have to request storage from a storage team or a person, you should identify these people, seek them out, and take them out to lunch or something – it will make life a bit easier.
- Learn about storage a little bit. It’s not all that hard, and the variables are outlined quite simply. Using these words can help you make a proper request for a storage allocation for your servers which of course are running your applications and databases. If you need more, I’d suggest starting with a nice site called SearchStorage, which is part of a larger IT web network.
- Before deploying anything on EMC gear, assume we have a piece of documentation which outlines the steps necessary to put SQL (or Exchange or SharePoint or whatever) on one of our SANs. If we don’t; well, shame on us – and you should push a bit to see if we can whip something up quickly for you. I am not saying RTFM, I am simply stating that we at least owe you the M part.
- Ask about application integration of the in-house storage vendor. Now that you are buddies with someone on the storage team, sit down and ask them about the cool stuff that each storage platform that they run can provide for you like 1) app-consistent snapshots to slice your backup windows down to nothing or 2) app-consistent replication to make sure your app comes up with minimal pain (or data loss) after an outage.
- Wait a Virtual Second. Well, if you are like the rest of the business world, you are probably looking to virtualize some percentage of, or specific servers/applications in your IT environment. If the storage team has done this, you have to make sure you understand a bit about that too because for better or for worse – it changes everything.
- Get them to build a storage request form. Many companies are already doing this. Some as simple as your name, your email, your capacity, and your IOPS. This is enough for most situations, but I would add RAID-type, latency, and LUN sizes if at all possible. If you’ve done all of the above, and taken an appropriate performance measure from the items you are able to monitor, then you should know what specifics should be included in your storage request form (and of course who it goes to).
The more technical version of this needs to make it’s way onto this site soon, and that would have to include a quick review of the performance chain in the SAN world, and how to find the weakest link. Stay tuned.