Fighting DBAs on virtualizing SQL

L

Life.exe

n00b
Joined
Nov 13, 2012
Messages
13
I swear I need some Jedi mind trick to get my DBAs ok with putting their physical HP "Itanium" SQL servers in vCenter. Any suggestions for reasoning with them other than the fact that it will have better performance, redundancy, and off old unsupported servers.:confused:

I would like to mention they tried in vCenter 3 and and it failed so it seems like some kind of VMware PTSD...if there is such a thing...:rolleyes:
 
Why don't they want to move it?

What are their performance and storage requirements?

What kind of storage can you place it on in VMware? Can you dedicate disks to SQL if necessary?

Are the SQL servers clustered?
 
Well HP Itanium I believe can't be virtualized.

Run some metrics, most servers run at like 5% power of the system. So much waste.
Prove to the dba guys that you can provide better hardware better IO throughput and they will be happy.
 
Child of Wonder said:
Why don't they want to move it?

What are their performance and storage requirements?

What kind of storage can you place it on in VMware? Can you dedicate disks to SQL if necessary?

Are the SQL servers clustered?
Click to expand...

Why don't they want to move it? - Scared of change? not really sure on that one...

What are their performance and storage requirements?
I can match all requirements regarding procs, ram, and IOPS

What kind of storage can you place it on in VMware? Can you dedicate disks to SQL if necessary?
-Disk are 15k SAS mount points from the SAN.

Are the SQL servers clustered?
Yes
 
Wrench00 said:
Well HP Itanium I believe can't be virtualized.

Run some metrics, most servers run at like 5% power of the system. So much waste.
Prove to the dba guys that you can provide better hardware better IO throughput and they will be happy.
Click to expand...

We do not plan on doing a PtoV because of that. We've even got it in our virtual environment at a DR site and have tested functionality. With all that they still refuse to make production virtual. :mad:
 
show the DBAs [in-writing] that HP/VMware supports your deployment. if they still won't budge, go direct to management.
 
Well..they're going to have to do something. MS no longer supports SQL on Itanium. You can't just P2V those boxes but it's easy to migrate a DB.

I run in to this all the time. DBAs don't think they can get the performance they need. I've virtualized some very large SQL and Oracle databases. Just do it properly. Here is some info:

http://www.houseofbrick.com/blog/sq...on-itanium-vs-x86-on-vmware-a-case-study.html

The guys at House of Brick are top notch. We use them sometimes for large Oracle and SQL projects. If you want to bring in some help they are the ones.
 
Do a POC. Dupe the data into x86-based VM SQL and compare query performance.
 
Life.exe said:
Why don't they want to move it? - Scared of change? not really sure on that one...

What are their performance and storage requirements?
I can match all requirements regarding procs, ram, and IOPS

What kind of storage can you place it on in VMware? Can you dedicate disks to SQL if necessary?
-Disk are 15k SAS mount points from the SAN.

Are the SQL servers clustered?
Yes
Click to expand...

Then you're probably right on the first point: they're just scared of change.

You'll probably have to prove to them you can provide the performance numbers they need. Hell, one big benefit is their server won't take 10 minutes to boot up because of memory checks and hardware initializing.

Depending on the required uptime of the DBs, clustering may not even be required anymore since VMware HA can usually get a VM back up in a couple minutes if the host goes down.

It's also nice in a virtual environment to be able to easily add more horsepower, hardware, or resize hard disks to a VM when needed. Log drive running out of space? Increase the VMDK size and extend the volume. Problem solved.

There's a ton of advantages to virtualization. Maybe you can start small by asking them to migrate databases over in phases so you can prove to them it will run fine.
 
Virtualizing is NOT the best idea for everything. If you're not EXTREMELY careful with how it's done, it WILL perform MUCH worse. Database servers are some of the hardest machines to virtualize correctly without a loss in performance. Unless your load requirements are very easy or you can put a lot of money into your storage setup, I must recommend sticking with local storage for a DB server. If you set it up on some cheap NAS/SAN device with just 1-2 gigabit links, it WILL perform like garbage. We currently have this issue at my work because the guy responsible for setting that up doesn't care what I/others have to say about it. Disk performance is the most important thing with databases; CPU isn't even close to as important. Virtualization has benefits, but any sysadmin who think it's right for everything should be fired.

It makes total sense that your DBAs would resist this. I would, too. And if you fought me on it, I'd potentially go to your boss and put in a complaint about you (and for everyone who has responded before this response, I'd be complaining about you, A. for trying to do my job, B. for stupidly thinking that virtualization is always the right option without even mentioning disk I/O)
 
Last edited:
I'd also caution to be overly optimistic disk IO especially considering "Disk are 15k SAS mount points from the SAN". Not all SANs are created equal (EQL pun!), if you, for example, have one of those lower end SANs that put all your spindles into the same array then it's pretty much given that your disk I/O will not be sufficient regardless of what the vendor says about IOPS (if the SAN is running stuff other than the SQL that is). You want fast storage (raid 10, maybe via SSD) for your log files, and then slower storage for your databases. Though of course this all depends on the actual workloads.

dandragonrage said:
Virtualizing is NOT the best idea for everything. If you're not EXTREMELY careful with how it's done, it WILL perform MUCH worse. Database servers are some of the hardest machines to virtualize correctly without a loss in performance. Unless your load requirements are very easy or you can put a lot of money into your storage setup, I must recommend sticking with local storage for a DB server. If you set it up on some cheap NAS/SAN device with just 1-2 gigabit links, it WILL perform like garbage.
Click to expand...

Talk about a sweeping generalization. Top that off with your comment about lodging a complaint with the virtualization admin's boss makes me once more realize how incredibly lucky I am to work with the awesome people I work with who wouldn't on their worst day come up with a notion like that.
 
Thuleman said:
Talk about a sweeping generalization. Top that off with your comment about lodging a complaint with the virtualization admin's boss makes me once more realize how incredibly lucky I am to work with the awesome people I work with who wouldn't on their worst day come up with a notion like that.
Click to expand...

If they weren't talking about disk I/O before we replied, then they clearly don't know what they're talking about. I didn't say it's necessarily an insurmountable challenge, but leaving it out of the discussion is a sign of incompetence. I already have a coworker that was given the okay to virtualize our databases, and it killed our performance because he used low-end SAN equipment that is performing very poorly with our requirements with multiple databases and several other maxchines, etc. (actually, he's ruined a lot more than just our database performance). It's absolutely a good idea to talk to the boss in such a case. Virtualization options must be carefully considered and that includes figuring out what requirements it'll put on your storage and how you can make sure that doesn't become a problem. Again, discussing other advantages of virtualization without even considering storage performance is absolutely insane. I have to deal with our 'official' sysadmin being one of those people. If you had to deal with the same, you'd understand my point of view instead of thinking me some jackass that simply wants to get people in trouble (or otherwise offend them on the internet (oh no)) for no reason. I actually have better things to do with my time than that. And I actually hate having to complain about people, but I feel that it's sometimes necessary if it's not possible to make the person understand the logical point of view.

So OP, want to give us the details on your SAN? What mf/model? How many drives, what drive model(s), how are the arrays set up? How does the SAN hook up to your network (what kind of links, what speed, how many)? What's already on the SAN? Can you expand it if necessary? What do you do with the databases and how many clients are there? etc. We need to figure out this stuff and potentially more before being able to seriously tell you virtualization will work here.
 
Last edited:
dandragonrage said:
Virtualizing is NOT the best idea for everything. If you're not EXTREMELY careful with how it's done, it WILL perform MUCH worse. Database servers are some of the hardest machines to virtualize correctly without a loss in performance. Unless your load requirements are very easy or you can put a lot of money into your storage setup, I must recommend sticking with local storage for a DB server. If you set it up on some cheap NAS/SAN device with just 1-2 gigabit links, it WILL perform like garbage. We currently have this issue at my work because the guy responsible for setting that up doesn't care what I/others have to say about it. Disk performance is the most important thing with databases; CPU isn't even close to as important. Virtualization has benefits, but any sysadmin who think it's right for everything should be fired.

It makes total sense that your DBAs would resist this. I would, too. And if you fought me on it, I'd potentially go to your boss and put in a complaint about you (and for everyone who has responded before this response, I'd be complaining about you, A. for trying to do my job, B. for stupidly thinking that virtualization is always the right option without even mentioning disk I/O)
Click to expand...

That last part seems rather aggressive. Someone's bitter.

Virtualization of an environment is typically an IT initiative that is driven from upper management down at least in my experience. DBA's typically fall under that IT umbrella so going to my boss about me pushing you to go virtual is probably going to get you no where if IT has a whole is embracing this move. There really aren't very many cases where it doesn't fit anymore with storage technologies and virtualization resources being what they are. That's not to say that one-size fits all, but the corner and edge cases are getting smaller and smaller each year.

I really have to go back to the OP and discuss how you went about designing your environment to accommodate your current workloads and how you would scale that environment for future growth and consolidation. Were these servers taken into consideration as part of the overall virtualization plan? If not, doing an assessment of what it will take behooves you tremendously. Gathering statistical data that they can't refute and showing that your environment can accommodate them is the best way to win. If you find you don't have the resources just be ready to purchase whatever you need to move them if that's the ultimate goal.
 
I agree that IO is very important for a database server. There wasn't a lot of specifics posted, but there are lots of gotchas to do the migration including making sure the settings are correct for the sql server since you can't p2v even if the resources are similar. You might or might not beat the current performance.

That being said, you also don't know if that system is well designed or not. If it isn't, it's going to be a nightmare to make it perform well in the new system virtualized because it will magnify the shortcomings.

Unless you are extremely bored, I'd wait for them to come to you when the system has to be migrated. You will need their support, and it would be much more positive experience for you both if you are partners in the migration. Otherwise, the downstream effect is that the customer of the database could be complaining which would ulitimately lead back to the guy that forced them to virtualize.

I've seen a lot of virtualized dbs and even small ones where the performance stinks compared to even small servers. I don't think you are going to want to be responsible for that just so you can virtualize them.
 
In my experience the people who build VM shouldn't. I have moved many different environments to VM without personally having control over the VM and have taken a major performance hits every time.

They either overload the systems or don't build adequate drives.

Get a copy of the DBA's backup and restore it into your own environment then do some perfmon counters.

Also some databases (mine for instance) has 64 gigs of RAM and and execute pretty much all queries from RAM...not too many VM's can handle a single machine that uses 64 gigs of ram.

I side with the DBA on this one...at least until you can prove your environment isn't a piece of shit.
 
Scary thread.
Not enough facts and too many assumptions. :)

Not all database implementations scale the same.
Some scale better horizontally and other better vertically.

There typically is a cost on I/O when you virtualize, but the hope is that you make up for that by better horizontal scaling or the gained flexibility.
Horizontal scaling uses more resources from the extra OS, DB application stack, and caching standpoint.

I have seen much better performance from vertical scaling scenarios with a good cache layer than horizontal ones.
Specially, if you can afford some manual partitioning, focusing on scaling each partition vertically can be a much better strategy.

Now, there are some DB types such as Mongo DB that just do better horizontally by forgoing resiliency at the storage level in favor of resiliency at the plurality of nodes.

So, OP needs to detail the DB implementation type and what the partitioning restrictions are.
 
I'm strangely reminded of the first ever project I worked on for my current employer. It was a 6 month long staff aug for a government agency. My job was to virtualize as many servers as possible.

One day, I was asking someone in IT about server X and if it could be virtualized. One of the other IT guys stands up in his cubicle, glares at me, and says "are you talking about server X? That's MY server!" I asked him if it could be virtualized and received a stern "no" before I could even finish my sentence. Despite my counters to his reasoning for why it had to stay physical, he refused. The next day, the project manager I was working under came to me and said this guy had complained about me to his boss for trying to virtualize HIS server.
 
Just to chime in. If I remember correct MS wants you (prefers you) to eager zero thick the LUNs being presented to the SQL server.
 
Child of Wonder said:
One day, I was asking someone in IT about server X and if it could be virtualized. One of the other IT guys stands up in his cubicle, glares at me, and says "are you talking about server X? That's MY server!" I asked him if it could be virtualized and received a stern "no" before I could even finish my sentence. Despite my counters to his reasoning for why it had to stay physical, he refused. The next day, the project manager I was working under came to me and said this guy had complained about me to his boss for trying to virtualize HIS server.
Click to expand...

Sounds pretty BS if he was just being stubborn. But calling someone out for wanting to virtualize stuff without properly making sure the environment can handle it is completely justified. I have to come into work every day to problems relating to a SAN that can't handle the load we put on it because our 'official' sysadmin didn't design the setup correctly. Nobody should have to deal with that.
 
dandragonrage said:
If they weren't talking about disk I/O before we replied, then they clearly don't know what they're talking about. I didn't say it's necessarily an insurmountable challenge, but leaving it out of the discussion is a sign of incompetence. I already have a coworker that was given the okay to virtualize our databases, and it killed our performance because he used low-end SAN equipment that is performing very poorly with our requirements with multiple databases and several other maxchines, etc. (actually, he's ruined a lot more than just our database performance). It's absolutely a good idea to talk to the boss in such a case. Virtualization options must be carefully considered and that includes figuring out what requirements it'll put on your storage and how you can make sure that doesn't become a problem. Again, discussing other advantages of virtualization without even considering storage performance is absolutely insane. I have to deal with our 'official' sysadmin being one of those people. If you had to deal with the same, you'd understand my point of view instead of thinking me some jackass that simply wants to get people in trouble (or otherwise offend them on the internet (oh no)) for no reason. I actually have better things to do with my time than that. And I actually hate having to complain about people, but I feel that it's sometimes necessary if it's not possible to make the person understand the logical point of view.

So OP, want to give us the details on your SAN? What mf/model? How many drives, what drive model(s), how are the arrays set up? How does the SAN hook up to your network (what kind of links, what speed, how many)? What's already on the SAN? Can you expand it if necessary? What do you do with the databases and how many clients are there? etc. We need to figure out this stuff and potentially more before being able to seriously tell you virtualization will work here.
Click to expand...

We have quite easily brought up massive physical DBs into our Virtual infrastructure and improved performance across the board with technically less available resources. You do your metrics, do you workload testing, certify it, then turn it live. Its not really that daunting of a task at all. Of course it all comes down to their specific environment.
 
dandragonrage said:
Sounds pretty BS if he was just being stubborn. But calling someone out for wanting to virtualize stuff without properly making sure the environment can handle it is completely justified. I have to come into work every day to problems relating to a SAN that can't handle the load we put on it because our 'official' sysadmin didn't design the setup correctly. Nobody should have to deal with that.
Click to expand...

Yep, I did all that. According to my notes (still have them saved after all these years!) physical server was dual core, 8GB RAM, and only used 100 IOPs on average. Basically the guy was being an overprotective Nancy because he thought his server was "special."

Your post reminded me of that. :) You're absolutely correct that not ensuring the virtual environment can meet performance demands on all levels and meet SLAs can cause a mountain of headaches. However, don't take an immediate hostile attitude when someone suggests virtualizing something.
 
Child of Wonder said:
Your post reminded me of that. :) You're absolutely correct that not ensuring the virtual environment can meet performance demands on all levels and meet SLAs can cause a mountain of headaches. However, don't take an immediate hostile attitude when someone suggests virtualizing something.
Click to expand...

I was taking an issue with people saying that the DBAs were just being stubborn without bringing up the specific details of whether the environment could handle it, not the idea that it MIGHT be able to be virtualized. Presenting the option and then considering it with all the performance implications is logical and valid. But most of those who replied before me were essentially saying "the DBAs are just being dumb - go for it." Nobody was discussing performance. I was not in the wrong for calling that part of the discussion out the way that I did. You all just interpreted it as some guy who likes to complain about people at work. But read the replies before I said it - can you seriously say the advice was good? Can you seriously say "Disk are 15k SAS mount points from the SAN" tells us anything useful? A good RAID setup with 7200rpm SATA drives will be MUCH faster than a bad RAID setup with 15000rpm SAS drives. That isn't even CLOSE to enough information, and the fact that the OP didn't see fit to provide (much) more information says to me that he does not know anywhere near enough about this topic to go ahead with a plan like this. If he did, he'd have explained his setup in MUCH more detail than that. It's like wanting advice on what computer parts to buy only to find out the person giving you advice is someone who recommends a video card based solely on their amount of VRAM. Sorry if it sounded mean-spirited (I simply call it being blunt), but it would suck if OP ended up causing the same issues that the sysadmin at my work already has.
 
Last edited:
In one of my environment I have VM with 96 gigs of RAM and its connected to a 10gb backbone (iscsi) SAN.
 
Heh...I love these arguments. When people say "Virtualization sucks!" they really mean "My admins can't properly size and scope an environment!". Virtualizing DBs is no different than anything else. It's all about a proper design.

And dandragonrage...you kind of show this. You say it's better on local disk than a NAS/SAN over 1Gb or 2Gb links. How much throughput do most DBs actually need? The answer is very little. It's all about the IOPS. Most DBs are small I/O..4KB or 8KB. I can do 16,000 8KB IOPS on a single 1Gb link. That's a decent sized DB..and it goes up from there to multiple links to 10Gb/40Gb/100Gb Ethernet.

I see your point... But you go about it the wrong way. Local, SAN, physical, virtual..it doesn't matter. It's all about the design and many people find it's worth the effort to virtualize those DBs for other reasons.
 
NetJunkie said:
Heh...I love these arguments. When people say "Virtualization sucks!" they really mean "My admins can't properly size and scope an environment!". Virtualizing DBs is no different than anything else. It's all about a proper design.

And dandragonrage...you kind of show this. You say it's better on local disk than a NAS/SAN over 1Gb or 2Gb links. How much throughput do most DBs actually need? The answer is very little. It's all about the IOPS. Most DBs are small I/O..4KB or 8KB. I can do 16,000 8KB IOPS on a single 1Gb link. That's a decent sized DB..and it goes up from there to multiple links to 10Gb/40Gb/100Gb Ethernet.

I see your point... But you go about it the wrong way. Local, SAN, physical, virtual..it doesn't matter. It's all about the design and many people find it's worth the effort to virtualize those DBs for other reasons.
Click to expand...
I find that DAS is worse for DB compared to a SAN.
 
Probably because most DAS sucks. People buy the cheap controllers. Far less cache and intelligence. But DBAs like it because they feel they control everything. And then get whiney when it doesn't perform well.
 
It also depends on what is on the VM.

I had some heavy use SiteScope servers on some VM's and Sitescope just slams the CPU to near 100% the entire time. I could get 800 counters a minute on a VM and 1400 on a physical...but the kicker was that I was hitting the VM so hard that it effected everything else on that VM because the CPU load was near 100% all the time so they removed everything off except the sitescope VM. So a virtual server that handled 1 server didn't make much sense.

There could of been a better way to handle this but the VM people didn't know of one and/or didn't build for one.
 
I have customers with 1:1 mappings of large VMs to physical vSphere hosts. Those systems need close to everything they can get..but they still want to virtualize them for several reasons. Hardware abstraction is a big one. No need to move an app when it's time to rev the system. Easier DR and failover. HA failover to another host may not be perfect (performance hit) but better than being down. Things like that.

And really...there is almost nothing that can't be virtualized today. Again, it's usually a badly scoped/designed configuration that's the problem.
 
NetJunkie said:
I have customers with 1:1 mappings of large VMs to physical vSphere hosts. Those systems need close to everything they can get..but they still want to virtualize them for several reasons. Hardware abstraction is a big one. No need to move an app when it's time to rev the system. Easier DR and failover. HA failover to another host may not be perfect (performance hit) but better than being down. Things like that.

And really...there is almost nothing that can't be virtualized today. Again, it's usually a badly scoped/designed configuration that's the problem.
Click to expand...

I agree that everything can be virtualized. But it then comes down to the cost a Physical server vs a 1:1 VM and whether or not those cost are worth it.

In some cases it also mean going from the Physical Hosting team to the Virtual Hosting team and the dynamics in that. In my case the Physical Hosting team was full of competence and the Virtual Hosting team full of incompetence.

You only have to get burned a few times with VM's to be forever skeptical. DBA's especially because they have a lot of pressure and responsibility to the systems being up and performing well.
 
It's a big fat depends.

In my current shop, the entire windows environment is all behind vmware. Exchange 2k3, MSSQL, Domain controllers, App servers, Backup Servers, etc etc etc. Is that the right way to do it? According to my windows admin, it works perfect for his needs. His environment is about 150Ts in total space so its nothing to sneeze at. Sure he runs into issues, but MS usually tells him its not a supported config, but he's able to resolve most issues.

If I tried to do that with my Oracle DBAs, I would be shanked before I even started the process. Oracle is begrudgingly only now starting to see folks want to virtulize thier DBs, and barely if at all support it. If you do run into an issue, the first thing they want you to do is move it back to a physical server. Rumor has it, the newer versions of Exadata will be XEN capable and that will be the only virtulization they support. Who knows.

Anyway, to the OP.. If Vmware, HP, and MS supports it running virtual, then thats a good step. You need to make sure you understand exaclly what the application needs and is doing. Seq Reads / Writes, Random IO, total amount of MAX IOP, Ram and CPU demands. I'm not a big fan of direct mapping of luns, but hey.. If it you have to do it, then go for it. I only don't like it cause its a tiny bit of extra admin.

Maybe its not a good fit, and they just need to migrate it off to another physical x86/x64 windows host.

Sometimes you'll just have to pick your battles. If the dbas just continues to give you the finger, then maybe its just best to let it fall over and die. Keep a good trail of documentaion, and let them take the heat for it.

best of luck.

edit, and im pretty much 100% agreement with Child Of Wonder and Netjunkie. Just didn't feel like quoting them and giving them a thumbs up.
 
NetJunkie said:
Heh...I love these arguments. When people say "Virtualization sucks!" they really mean "My admins can't properly size and scope an environment!". Virtualizing DBs is no different than anything else. It's all about a proper design.

And dandragonrage...you kind of show this. You say it's better on local disk than a NAS/SAN over 1Gb or 2Gb links. How much throughput do most DBs actually need? The answer is very little. It's all about the IOPS. Most DBs are small I/O..4KB or 8KB. I can do 16,000 8KB IOPS on a single 1Gb link. That's a decent sized DB..and it goes up from there to multiple links to 10Gb/40Gb/100Gb Ethernet.

I see your point... But you go about it the wrong way. Local, SAN, physical, virtual..it doesn't matter. It's all about the design and many people find it's worth the effort to virtualize those DBs for other reasons.
Click to expand...

Heh. I love the lack of reading comprehension. Nobody said virtualization sucks. Nor did I say that it can't be done with SAN/NAS. I said it's harder to do right with SAN/NAS (which it absolutely is, period) and nobody was discussing performance, and the OP didn't seem to have enough knowledge to claim that it would be okay to virtualize. If your idea of describing a storage system is "SAN w/ 15K RPM disks in RAID" then I'm sorry but you shouldn't be allowed anywhere near a storage system.

And yes, IOPS are important, but SAN/NAS will always have a much higher latency than DAS and will always be worse at this. But in many cases it can be good enough, yes. As long as it's done by someone who knows there's more to a storage system than "15KRPM disks in RAID."
 
An old addage for enterprise DBs was not to virtualize.
This is because a virtualized DB server needs to be set up specifically and tuned for DB server use.

DB engines are very sophisticated. They consider the hardware and software metrics of the machine when performing. A VM obfuscates this, making it difficult for the DB to perform optimally.
 
san, nas and das are 3 entirely different beasts. It's not any harder to do it with nas, san or das, just a completely different set of steps and requirements that need to be met first. its only hard if you lack the experience to do it in either of those directions.

with that said.. das storage might be faster in your environment compared to your san. there are a lot of factors that can cause it to be faster. but a blanket statement of saying san storage will always have much higher latency is just silly and short sighted.
 
You need to be more cautious and more intelligent about virtualizing SQL servers which many companies don't do. They just treat it like any other migration more often than not, which causes poor results. As mentioned, storage is everything. If it's setup right, it will be fine.

I have worked with many different apps and servers over the years and I have never spent as much time fine-tuning and optimizing as I have with SQL server. There are so many things that can be configured and optimized that if not done correctly will KILL performance.

Since many people don't spend time or care to fine-tune performance, many DBA's are naturally hesitant. Combine that with certain software providers (like Microsoft0 saying they don't want to support those environments than you can understand why DBA's often push back.
 
dandragonrage said:
nobody was discussing performance
Click to expand...

The first response to the OP (mine) immediately called out the performance requirements of the DB and asked if the SAN could handle it, even if disks could be dedicated to the DB alone.

Some may have ignored the performance angle, but since you once got burned you come in here filled with hostility towards the prospect of virtualizing SQL.

While the OP simply pointed out his SAN has 15k SAS disks, we still don't know anything about the DB itself (unless I missed it). It could be a puny 20GB read heavy DB needing only about 500 average IOPs with infrequent peaks of 1,000. If the OP can place this on a dedicated RG of 15k disks in RAID 5 that would work just fine, especially if his SAN has the ability to dynamically cache data such as EMC FAST Cache.

Relax and take a deep breath. We don't know the requirements of the DB nor do we know exactly what disks the OP has available. Outside of a few posts here, for all we know the OP knows these performance requirements and knows he has them covered but the DBAs are just being stubborn. Not like that has never happened before.
 
If you're not considering virtualizing everything you have, and I emphasize "CONSIDER" then you live in the stone age, tied to dedicated hardware with legacy management structure. This is not the optimal way of doing things, period. Mission Critical Apps, db's, whatever. With the compute power that you can provide a VM nowadays, and the low latency of Solid State and High Speed Storage Fabrics, you can provide stellar performance to a majority of workloads.

I don't thinks it's a question of performance anymore, it's a question of dollars versus benefit. The problem with this comparison is that 99% can't determine what the "TRUE" cost is because they are not looking at it from all angles. Customers see one thing, cost. It's our job to educate the customers on what the tangible benefits will be and associate that to a savings.

I think Jason hit the nail on the head when he gave you the example of how he has customers that run a single DB, virtualized mind you, on a single host. To them, the benefits outweighed the cost in manageability. I too have customers that have very large exchange environments with very few Virtual Machines running on a couple of hosts just to support Exchange. They love the fact that it IS easier to manage, easier to recover in the event of an outage..etc. On top of that the performance is steller. Again, another example of where the customer sees the "FULL" Benefit and is not hung up on just $$$.

Even in highly transaction DB's where IOPS and Low Latent connections are king should be considered in your virtualization strategy. There isn't a reason not too and for those that think along those lines, i'm sorry to say that you are not living in the now, and a refusal to accept the change that's occurring right in front of your face will eventually bite you..and I don't want that to happen to anyone.
 
Child of Wonder said:
but since you once got burned you come in here filled with hostility towards the prospect of virtualizing SQL..
Click to expand...

Not true. That's a misunderstanding on your part, one I have addressed several times now, but hey, whatever. I'm hostile against the idea of someone who doesn't understand storage systems well enough (OP seems to be one of those people) having a say in virtualization. Not once did I say it should never be done or that it can't be done right.

I did see your post asking about performance, yes. Fine. You're an exception. But everyone else ignored it. And all those people who ignored it and gave advice anyway should themselves be ignored. THAT is what I was hostile against. I said DAS is easier, and it is, regardless of how many of you think otherwise. DAS is easier. Doesn't mean SAN/NAS can't be done, but DAS is still easier. I didn't say DAS is the only option. If I say it 500 times in a row, will you all understand it then? Yes, I said the SAN setup was done incorrectly at my work. I did not say it's always done incorrectly. But listening to most of the advice in the thread would likely result in SAN done incorrectly.
 
Last edited:
Well as a DBA, first I will say stop talking bad about me!

More to the point, I agree with everything NetJunkie has said. It's about skill sets. If you have a VMware admin that is having problems just managing their environment with file shares than layer on a sophisticated VM using SQL Server they are going to be over their head. If you have a SQL Server admin that can't tell you in very specific terms why they do not want their installation virtualized then they will be over their head in troubleshooting and tuning regardless of physical or virtual.

With my DBA cap on, I have said we are not virtualizing our SQL installs previously because of managing licensing, our ability to effectively troubleshoot both SQL and vSphere needed to grow and because I didn't want anyone pointing fingers either direction. If we had installed SQL on a VM and it performed like crap I know faith would have been lost by some in virtualizing our main applications. I've already got the plans on how we will virtualize our SQL installs but it's easing us into it.

OP the first thing you should do is ask for a list of specific concerns they have about virtualizing their SQL installs. If they refuse to give it to you it's a communication and business problem. If they give it to you then you can address the issues by creating an environment and then proving they are non-issues but creating artificial loads. At that point they either accept it or it is again a communication and business problem. Remember, if they don't have the skill set to provide you specific concerns then they won't have the skill set to properly administer their environment, physical or virtual.
 
Vader said:
If you're not considering virtualizing everything you have, and I emphasize "CONSIDER" then you live in the stone age, tied to dedicated hardware with legacy management structure. This is not the optimal way of doing things, period. Mission Critical Apps, db's, whatever. With the compute power that you can provide a VM nowadays, and the low latency of Solid State and High Speed Storage Fabrics, you can provide stellar performance to a majority of workloads.

I don't thinks it's a question of performance anymore, it's a question of dollars versus benefit. The problem with this comparison is that 99% can't determine what the "TRUE" cost is because they are not looking at it from all angles. Customers see one thing, cost. It's our job to educate the customers on what the tangible benefits will be and associate that to a savings.

I think Jason hit the nail on the head when he gave you the example of how he has customers that run a single DB, virtualized mind you, on a single host. To them, the benefits outweighed the cost in manageability. I too have customers that have very large exchange environments with very few Virtual Machines running on a couple of hosts just to support Exchange. They love the fact that it IS easier to manage, easier to recover in the event of an outage..etc. On top of that the performance is steller. Again, another example of where the customer sees the "FULL" Benefit and is not hung up on just $$$.

Even in highly transaction DB's where IOPS and Low Latent connections are king should be considered in your virtualization strategy. There isn't a reason not too and for those that think along those lines, i'm sorry to say that you are not living in the now, and a refusal to accept the change that's occurring right in front of your face will eventually bite you..and I don't want that to happen to anyone.
Click to expand...

Nailed it, and I pretty much agree with this. I really liked how you said you should consider things, instead of saying you have to do it. Today, I'm not so sure I'm ready to put a highly randomm IO 24TB Oracle OLTP database behind VMware. Even with the amount of backend storage power I have on tap. But give me 2 years, and my tune will change.
 
You must log in or register to reply here.
Back
Top