SQL Virtulization
-
@nets said in SQL Virtulization:
We want to conver the server to a VM and configure a large RAID 10 with all 12 drives. When doing this is it still necessary to have 3 VHDX's if they are going to be on the same array?
I would keep the VHDXs separate, yes. Not "necessary" but good practice. Gives you more flexibility, especially for backups and stuff.
-
If you keep separate VHDXs, you can take advantage of using quality of service management to control the minimum and maximum IOPS.
-
@nets said in SQL Virtulization:
We ran across a server at a new clients that was installed in the last 6 months to host their MS Dynamics install. The system was installed as a physical server with 3 RAID 10's consisting of 4 drives each. The 3 array's are broken up for the DB, Logs, and Backup.
We want to conver the server to a VM and configure a large RAID 10 with all 12 drives. When doing this is it still necessary to have 3 VHDX's if they are going to be on the same array?
Why are vendors still installing on physical systems?
Yes, it is a good practice to to use several VHDXs.
Examples:
- OS.vhdx
- DB.vhdx
- Log.vhdx
- Backup.vhdx
- Data/Apps.vhdx
There are a lot of benefits to doing it this way, depending on your environment. There really is no down side to doing it when it's a VM, only potential benefits.
-
@tim_g That's really the key... no real downsides.
-
@tim_g said in SQL Virtulization:
@nets said in SQL Virtulization:
We ran across a server at a new clients that was installed in the last 6 months to host their MS Dynamics install. The system was installed as a physical server with 3 RAID 10's consisting of 4 drives each. The 3 array's are broken up for the DB, Logs, and Backup.
We want to conver the server to a VM and configure a large RAID 10 with all 12 drives. When doing this is it still necessary to have 3 VHDX's if they are going to be on the same array?
Why are vendors still installing on physical systems?
Yes, it is a good practice to to use several VHDXs.
Examples:
- OS.vhdx
- DB.vhdx
- Log.vhdx
- Backup.vhdx
- Data/Apps.vhdx
There are a lot of benefits to doing it this way, depending on your environment. There really is no down side to doing it when it's a VM, only potential benefits.
I always try to keep the OS and "other" separated jsut because it makes it easier later. it affects nothing regarding performance.
-
Got the okay to proceed with converting to a VM. A little more memory in the system and it will be running the SQL server and a DC soon.
-
@nets said in SQL Virtulization:
Got the okay to proceed with converting to a VM. A little more memory in the system and it will be running the SQL server and a DC soon.
DC's don't require a lot of performance, but mixing and matching services needs to be carefully considered before being implemented.
-
@dustinb3403 said in SQL Virtulization:
They will be separate VM's
-
@nets said in SQL Virtulization:
@dustinb3403 said in SQL Virtulization:
They will be separate VM's
They still share CPU and IOPS, though.
-
@jaredbusch same here. I always keep those separated.
-
@scottalanmiller said in SQL Virtulization:
@nets said in SQL Virtulization:
Why are vendors still installing on physical systems?
Because it makes things more fragile, meaning more support dollars. It's easier to hold customers hostage.
Don't assume that when people make bad decisions it is done deliberately to fleece their customers. Most times, bad decisions are made with the best intentions.
I think one of the reasons that the myth of physical systems being better still exists is that people in the SMB world confuse virtualisation with network storage. In other words, people think that virtualisation means buying two hosts and one SAN (the most common SMB setup).
Then what happens is that the solution ends up being underspecced. SQL gets installed on the SAN and the ERP system performs badly. The user complains to their IT support (which in the UK at least, is nearly always a VAR that sold them them the SAN). The MSP/VAR says "it's not us, blame the ERP guys", normally on the weak grounds that other applications are performing ok (because ERP/SQL is normally the most resource heavy application a user has). The ERP reseller gets annoyed by this, and in future recommends SQL is installed on a physical server for no other reason than to remove network storage issues from the equation.
None of this has anything to do with virtualisation, but people mistakenly assume that it does. So I think what people mean when they say "keep SQL physical" is actually "keep SQL on local storage". It's just a mistake, or it's easier to use the word physical, otherwise the user might wonder why they paid so much money for a SAN.
-
@carnival-boy said in SQL Virtulization:
@scottalanmiller said in SQL Virtulization:
@nets said in SQL Virtulization:
Why are vendors still installing on physical systems?
Because it makes things more fragile, meaning more support dollars. It's easier to hold customers hostage.
Don't assume that when people make bad decisions it is done deliberately to fleece their customers. Most times, bad decisions are made with the best intentions.
Sure, but not normally, especially not in cases where someone makes an outright effort to violate the most fundamental best practices in the industry.
Don't give malicious incompetence a free pass. People are responsible for forcing bad decisions when they didn't need to and took it upon themselves. If they didn't do their homework or aren't knowledgeable and make a decision that makes them more culpable, not less.
-
@carnival-boy said in SQL Virtulization:
I think one of the reasons that the myth of physical systems being better still exists is that people in the SMB world confuse virtualisation with network storage. In other words, people think that virtualisation means buying two hosts and one SAN (the most common SMB setup).
Right, which means these are people who should not be involved in the decisions - because they haven't even learned what the subject matter is let alone how it works or why it matters. Making up some illogical and absolutely incorrect definition and never looking into it yet still making decisions based on that known unfounded fallacy is a form of malice. They have to know that they just made it up and didn't research it, they have to know that they've not done their homework, they have to know that they are making decisions or giving advice based on something that isn't real.
-
@scottalanmiller said in SQL Virtulization:
Right, which means these are people who should not be involved in the decisions - because they haven't even learned what the subject matter is let alone how it works or why it matters.
I think you're exaggerating the badness of the decision to install SQL physical. But I agree that a Dynamics reseller shouldn't be involved in the decision, the user should have separate IT support that can make these decisions. To go back to the OP, the user now has the correct IT support, but I'd be interested to know what they had before.
-
@carnival-boy said in SQL Virtulization:
@scottalanmiller said in SQL Virtulization:
Right, which means these are people who should not be involved in the decisions - because they haven't even learned what the subject matter is let alone how it works or why it matters.
I think you're exaggerating the badness of the decision to install SQL physical. But I agree that a Dynamics reseller shouldn't be involved in the decision, the user should have separate IT support that can make these decisions. To go back to the OP, the user now has the correct IT support, but I'd be interested to know what they had before.
How bad does it need to be before blatantly violating basic and simple best practices for no reason is acceptable? 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. Under what conditions do you give a vendor a pass on something like that? We aren't talking about an oversight or mistake, we are talking about something with intent.
-
A mistake a vendor will correct. "Oh, we didn't realize it said that on the requirements, let's fix that." Or "that's a best practice? We don't have any IT people in our company and we just picked things at random, whoops, let's fix that."
But find a vendor that's doing this that actually takes their product seriously and is willing to fix things like this? You won't. Why? Because they have motives for doing it for their own purposes.
-
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?
