SQL Virtulization
-
Now we can make the argument that the requirements are old. And that's reasonable, or was reasonable a decade ago. But this presumes that it is okay to have products that haven't been tested in a standard production environment for a bit more than a decade and were on legacy style environments before that point long enough to have established their requirements that way. In IT, platforms aren't reliable for that long. We don't really want to be running products in production today that haven't been being actively maintained already for more than a decade. Even assuming just ten years of abandonment, and assuming we want to get five years only from the product, that's fifteen years towards the end of our cycle for the ghost ship to have been adrift.
-
@scottalanmiller said in SQL Virtulization:
I think the mistake is thinking that there is a threshold for when being reckless is okay.
...
The issue is that someone is making a conscious, deliberate effort to keep the system from being baseline stable and production ready.How is a physical SQL install unstable, reckless or not production ready? I don't see how virtualised or physical effects stability.
-
@carnival-boy said in SQL Virtulization:
@scottalanmiller said in SQL Virtulization:
I think the mistake is thinking that there is a threshold for when being reckless is okay.
...
The issue is that someone is making a conscious, deliberate effort to keep the system from being baseline stable and production ready.How is a physical SQL install unstable, reckless or not production ready? I don't see how virtualised or physical effects stability.
That's the core value of virtualization and why it's been used anytime it was available since 1964. Virtualization was all about stability and reliability. The use of it for things like consolidation are "extras" that become popular later. There is a reason that 100% of workloads outside of the commodity space are virtualized, only in the SMB commodity space has physical been considered acceptable for decades. And when virtualization finally got there, it was so over-hyped as a cost savings measure that people forgot why it was really there - protection.
Not that cost savings isn't a good reason for some people, I don't want to belittle cost savings. But that's not the core reason and never the reason for the "always use virtualization."
Virtualization, while seemingly to do the opposite, dramatically reduces complexity in system design making the operating system to hardware interface more standardized and stable. That hardware abstraction is the fundamental value point and given that virtualization is free is why we say to never skip it - when do you want to not get stability bonuses for free?
Beyond that, virtualization protects against the unknown. It limits you not at all, but provides many avenues for flexibility. Most things that you can do with virtualization you can do without it, but you can do more things, more easily, in more ways, and in more standard ways with it. From simplified and cheaper storage abstraction, consolidation, mobility, recovery, etc. All things that make no sense to give up when there is no reason to give them up.
-
I get all the different benefits of virtualising, but I'm still not getting how physical is less stable, or is reckless. Can you give an example?
-
@carnival-boy said in SQL Virtulization:
I'm still not getting how physical is less stable.
One quick example comes to mind, when dealing with servers in numbers.
With virtualization, you have a lot less physical hardware that can fail. You will normally have 25-100 virtual machines on a single physical server.
Otherwise, you'd have 25-100 physical servers. The chance of failure and data loss go through the roof in comparison to a single server.
You'll have to have a completely different backup routine, a whole web of things, so many more moving parts and potential failures.
Going physical with your servers decreases stability of your infrastructure ten-fold.
This is just one or two points regarding less stability going physical off the top of my head.
-
@carnival-boy said in SQL Virtulization:
I'm still not getting how physical is reckless.
It's reckless because you are introducing a lot more risk... basically by going physical you are purposely removing all of the benefits from your infrastructure that virtualization provides. You are knowingly (likely) not implementing the best solution, and putting the business at a greater risk. That is very reckless.
-
@tim_g said in SQL Virtulization:
Otherwise, you'd have 25-100 physical servers. The chance of failure and data loss go through the roof in comparison to a single server.
No. By your logic, the President and Vice President of the US should always travel in the same plane, because less planes, the less chance of failure and loss of life.
But we're not talking about 25-100 physical servers. We're talking about one physical server, with one SQL Server. How does virtualising that increase stability? How does keeping it physical mean being reckless?
And just saying not following best practice is reckless isn't an answer. Explain why. What risk are you introducing? Remember, the probability of physical failure is identical.
-
@carnival-boy said in SQL Virtulization:
We're talking about one physical server, with one SQL Server. How does virtualising that increase stability?
I think two better questions to ask are:
- "How does virtualization decrease stability?"
- "How is virtualization reckless?"
If a specific server deployment scenario you are doing can't provide a legitimate non-mythological concerns to those questions, then you are purposely choosing to not use proven good practice for no reason at all, and that is reckless, because you are missing out on many benefits and knowingly implementing issues and caveats from the start.
-
@tim_g said in SQL Virtulization:
@carnival-boy said in SQL Virtulization:
We're talking about one physical server, with one SQL Server. How does virtualising that increase stability?
I think two better questions to ask are:
- "How does virtualization decrease stability?"
- "How is virtualization reckless?"
If a specific server deployment scenario you are doing can't provide a legitimate non-mythological concerns to those questions, then you are purposely choosing to not use proven good practice for no reason at all, and that is reckless, because you are missing out on many benefits and knowingly implementing issues and caveats from the start.
Did @scottalanmiller take over your account and start posting as you?!
-
@carnival-boy said in SQL Virtulization:
No. By your logic, the President and Vice President of the US should always travel in the same plane, because less planes, the less chance of failure and loss of life.
That's not how it works.
Check out this article:
http://www.smbitjournal.com/2012/05/when-no-redundancy-is-more-reliable/
-
You and I seem to have a different concept of defining system stability, so I'm not sure I can add anything else.
-
@tim_g said in SQL Virtulization:
@carnival-boy said in SQL Virtulization:
No. By your logic, the President and Vice President of the US should always travel in the same plane, because less planes, the less chance of failure and loss of life.
That's not how it works.
Check out this article:
http://www.smbitjournal.com/2012/05/when-no-redundancy-is-more-reliable/
I don't need to read an essay to understand probability. The probability of a single SQL server suffering from physical failure is the same regardless of whether or not other servers share the same box.
If I get in a car, the probability of me being in accident does not go down the more passengers there are.
