So for me it's a massive temptation to build my own storage array and pop it into production...
It's significantly cheaper and possibly more perfomant than buying a pre-configured brand name unit, and it would be fun to build. Idea's of slapping multiple PCI SSD's into a supermicro chassis, and then filling the drive cages with big SATA tubs really excites me! You can get the best of both worlds - blazing fast SSD's plus big storage all in one unit. Spec up lots of RAM for a really fat cache and you have the potential to blow away most units on the market.
You get some amazing software to give you as little or as much functionality as you could possibly want - eOpen, SAN Symphony, Starwind etc. all give you amazing features or you could go VSA and try the Lefthand or other virtual SAN solution...
Yes I know these idea's are naive, but it's the basis for a lot of the storage companies out there...
So if the hardware is there, and the software is there, then why not...?
Simple - when this solution has problems, all responsibility will lie with you alone. You can't call in the cavalry when you suddenly find there is a massive compatibility issue with a new software version or firmware edition.
I don't know about you, but I have enough stress in my job already, and don't need to be lying in bed at night wondering if a new firmware version is going to fix a bug or create new ones for me... I would rather leave that to a team of professionals who focus all their time and effort on this exact question.
Is there a time I would do it? Yes, definitely. If cost was the single biggest motivating factor for the company, or if I was unable to attain the performance levels that my system required under a specific budget. Also these kinds of solutions are great for dev and test, as long as downtime is permissible and you don't have a 5 9's SLA. You can build a very big storage solution very cost effectively in this manner and you can also build some very fast systems in this way (Tony Rogerson's blog comes to mind). But they are not enterprise class solutions - and if you consider your SQL installation to be enterprise worthy, then why risk the whole thing for a few pounds?
Monday 15 August 2011
Sunday 14 August 2011
On Monitoring
Tonight it occurred to me that monitoring is more important than we probably give it credit for.
The way I see it, it should server 3 purposes:
1) Alerting - this is obvious but sometimes ineffective. As an example, that email that comes in at 3am, to tell you that a critical job has failed, is only going to be read when you wake up in the morning. So not only does it have to be accurate and timious, but it also needs to be appropriately delivered.
2) Provide situational information. So you get the dreaded phone call from the night shift that something is broken. You dial in and open your monitoring tools and you should be immediately be greeted with both what went wrong / is going wrong, and what is causing it. I guess this is a little eutopian to believe that both cause and effect would be shown that easily, but the goal is that at least there is enough info to diagnose the problem directly from the metrics the monitoring is displaying to you.
3) Trending. I guess most people would classify this under a different category to monitoring, but I believe that trending and performance prediction is an integral aspect of any monitoring solution. All the data you need for your capacity planning should be captured by your monitoring solution, and is probably already stored in it's database right now - the question is, can you access it easily?
I have a fetish for monitoring, and believe that none of the 3rd party products I have seen adequately address all facets of SQL monitoring. Most do a reasonable job, and you could get by with almost any of them, but what are you inadvertently missing? To combat this, I prefer to run multiple solutions simultaneously on our high value systems. Yes, this means greater overhead on these servers, but the combination of overlapping redundancy and the different perspectives given buy different monitoring solutions can be extremely enlightening. On course you can be hardcore and roll your own, but I'm too busy doing interesting things to be writing a million scripts that probably only cover 50% of the things that I need to know.
The way I see it, it should server 3 purposes:
1) Alerting - this is obvious but sometimes ineffective. As an example, that email that comes in at 3am, to tell you that a critical job has failed, is only going to be read when you wake up in the morning. So not only does it have to be accurate and timious, but it also needs to be appropriately delivered.
2) Provide situational information. So you get the dreaded phone call from the night shift that something is broken. You dial in and open your monitoring tools and you should be immediately be greeted with both what went wrong / is going wrong, and what is causing it. I guess this is a little eutopian to believe that both cause and effect would be shown that easily, but the goal is that at least there is enough info to diagnose the problem directly from the metrics the monitoring is displaying to you.
3) Trending. I guess most people would classify this under a different category to monitoring, but I believe that trending and performance prediction is an integral aspect of any monitoring solution. All the data you need for your capacity planning should be captured by your monitoring solution, and is probably already stored in it's database right now - the question is, can you access it easily?
I have a fetish for monitoring, and believe that none of the 3rd party products I have seen adequately address all facets of SQL monitoring. Most do a reasonable job, and you could get by with almost any of them, but what are you inadvertently missing? To combat this, I prefer to run multiple solutions simultaneously on our high value systems. Yes, this means greater overhead on these servers, but the combination of overlapping redundancy and the different perspectives given buy different monitoring solutions can be extremely enlightening. On course you can be hardcore and roll your own, but I'm too busy doing interesting things to be writing a million scripts that probably only cover 50% of the things that I need to know.
Subscribe to:
Posts (Atom)