Ready to get started with anonymous questions today? It's easy! Learn more.
COURSE of the MONTH
8 days, 14 hours left to enrollBecome a Premium Member and unlock a new, free course in leading technologies each month.
Solved
Best Desgin for SQL Server on Vmware ?
Posted on 2011-03-04
Dear all,
as we have around three cluster env for SQL 2005,2008 for Many Apps as well for SharePoint .
Now we decide to go through VMware .I know the VM is a great product when I decide to go with VM I understand the support through SVV program and all of version of SQL Supported on ESX 6.
but now when I discuss with VM engineer I found SQL Cluster is supported on VM but when we install cluster VM is working fine and everything wokring great BUT when I check VM feature like Snapshot ,VMotion is not supported with VM only standalone . So it was big challenge as well review design something is must ?
My question in my case it is better to go with Standalone with many servers OR go with Cluster option . Of course still we have one physical server for critical systems .
?
with Cluster we loose many feature + complex troubleshooting .
with STD alone will be easier but it will be many servers as well many management?
Looking for best ?
Thanks
as we have around three cluster env for SQL 2005,2008 for Many Apps as well for SharePoint .
Now we decide to go through VMware .I know the VM is a great product when I decide to go with VM I understand the support through SVV program and all of version of SQL Supported on ESX 6.
but now when I discuss with VM engineer I found SQL Cluster is supported on VM but when we install cluster VM is working fine and everything wokring great BUT when I check VM feature like Snapshot ,VMotion is not supported with VM only standalone . So it was big challenge as well review design something is must ?
My question in my case it is better to go with Standalone with many servers OR go with Cluster option . Of course still we have one physical server for critical systems .
?
with Cluster we loose many feature + complex troubleshooting .
with STD alone will be easier but it will be many servers as well many management?
Looking for best ?
Thanks
[X]
Welcome to Experts Exchange
Add your voice to the tech community where 5M+ people just like you are talking about what matters.
- Help others & share knowledge
- Earn cash & points
- Learn & ask questions
-
3
2
5 Comments
For simplicity's sake, I'll use a Windows guest with a 30GB C: drive in this example. For a normal guest, the storage works like this: a raw LUN is presented to an ESX host. The ESX host formats the LUN with a VMFS filesystem, creating a Datastore. A VM is created with a 30GB C: drive. That C: drive shows up as a single 30GB file on the datastore. The
ESX server presents that single 30GB file to the Windows guest attached to a virtual SCSI controller, so as far as the guest is concerned it's seeing a regular SCSI disk. Any other VM can use the remaining space on the Datastore.
Microsoft clustering requires raw LUNs. VMware accomplishes this with Raw Device Mappings (RDM). The LUN is not formatted by the ESX server as a VMFS datastore, it is formatted directly by the VM as NTFS volume - the entire LUN is used for this. You can not create any other disks on it like you can for a VMFS datastore.
Unfortunately, if you use RDMs, you can't use vMotion or snapshots.
We've been moving away from MS clusters due to their complexity. It seems for every issue that MS clustering solves, it causes others. We'll run into a situation where the MS cluster just seems to hang on failover for no obvious reason. Sometimes the node that owns a resource doesn't release it. The extra Windows licenses are expensive, the spare physical hardware is extremely expensive, and we have to pay for the rack space, cooling costs, power, etc. SQL VMs reboot much faster than physical servers - they even reboot faster than a cluster failover in many cases. A VM makes upgrades easier to deal with because you can revert to a snapshot, backups and restores easier, and DR is easier because we don't have to worry about similar hardware in DR. All we have to do is ensure that the DR hardware is on the VMware HCL and we're OK. We use VMware HA to protect against an ESX hardware failure.
VMs have sped up our patching cycles - in many cases a VM can reboot after patching faster than a physical cluster would fail over. Also, there is only 1 server to patch and it has decreased the workload on the DBAs when a SQL patch comes along.
We now only do physical clusters for the heaviest, most mission critical workloads where we have no other choice. We wouldn't virtualize a big SQL cluster with 200GB+ of RAM, but for most of our SQL servers with 4-50GB, a VM works just fine. We size our VMware SQL clusters for performance instead of consolidation ratios.
ESX server presents that single 30GB file to the Windows guest attached to a virtual SCSI controller, so as far as the guest is concerned it's seeing a regular SCSI disk. Any other VM can use the remaining space on the Datastore.
Microsoft clustering requires raw LUNs. VMware accomplishes this with Raw Device Mappings (RDM). The LUN is not formatted by the ESX server as a VMFS datastore, it is formatted directly by the VM as NTFS volume - the entire LUN is used for this. You can not create any other disks on it like you can for a VMFS datastore.
Unfortunately, if you use RDMs, you can't use vMotion or snapshots.
We've been moving away from MS clusters due to their complexity. It seems for every issue that MS clustering solves, it causes others. We'll run into a situation where the MS cluster just seems to hang on failover for no obvious reason. Sometimes the node that owns a resource doesn't release it. The extra Windows licenses are expensive, the spare physical hardware is extremely expensive, and we have to pay for the rack space, cooling costs, power, etc. SQL VMs reboot much faster than physical servers - they even reboot faster than a cluster failover in many cases. A VM makes upgrades easier to deal with because you can revert to a snapshot, backups and restores easier, and DR is easier because we don't have to worry about similar hardware in DR. All we have to do is ensure that the DR hardware is on the VMware HCL and we're OK. We use VMware HA to protect against an ESX hardware failure.
VMs have sped up our patching cycles - in many cases a VM can reboot after patching faster than a physical cluster would fail over. Also, there is only 1 server to patch and it has decreased the workload on the DBAs when a SQL patch comes along.
We now only do physical clusters for the heaviest, most mission critical workloads where we have no other choice. We wouldn't virtualize a big SQL cluster with 200GB+ of RAM, but for most of our SQL servers with 4-50GB, a VM works just fine. We size our VMware SQL clusters for performance instead of consolidation ratios.
Hi ,
Thanks for all those information . It really helpful . So let me understand for critical Application with physical cluster but for medium application will go VMWare .
Thats look good for me but how can improve VMWare guest with standalone SQL Sever .I mean what is best to use like some feature in VM like HA or choose log-shipping or mirroring in SQL ?
Thanks for all those information . It really helpful . So let me understand for critical Application with physical cluster but for medium application will go VMWare .
Thats look good for me but how can improve VMWare guest with standalone SQL Sever .I mean what is best to use like some feature in VM like HA or choose log-shipping or mirroring in SQL ?
HA protects you against physical hardware failure - it restarts your VM on another physical server if the server the VM is running on dies. It offers no protection if there's actually something wrong with the VM like an OS or SQL corruption.
Log shipping is simply a way to ensure that your transaction logs are applied to another SQL server so you have a ready-to-run copy of your database online. If your primary VM goes down, you have the backup available with some manual intervention.
We generally don't use log shipping for the VMs - we are confident that our restore process is fast enough to get us back to where we need to be. We have used it to back up a non-clustered physical node though.
Log shipping is simply a way to ensure that your transaction logs are applied to another SQL server so you have a ready-to-run copy of your database online. If your primary VM goes down, you have the backup available with some manual intervention.
We generally don't use log shipping for the VMs - we are confident that our restore process is fast enough to get us back to where we need to be. We have used it to back up a non-clustered physical node though.
Featured Post
Question has a verified solution.
If you are experiencing a similar issue, please ask a related question
After restoring a Microsoft SQL Server database (.bak) from backup or attaching .mdf file, you may run into "Error '15023' User or role already exists in the current database" when you use the "User Mapping" SQL Management Studio functionality to al…
Hi all,
It is important and often overlooked to understand “Database properties”. Often we see questions about "log files" or "where is the database" and one of the easiest ways to get general information about your database is to use “Database p…
This tutorial will teach you the special effect of super speed similar to the fictional character Wally West aka "The Flash"
After Shake : http://www.videocopilot.net/presets/after_shake/
All lightning effects with instructions : http://www.mediaf…
Sometimes it takes a new vantage point, apart from our everyday security practices, to truly see our Active Directory (AD) vulnerabilities. We get used to implementing the same techniques and checking the same areas for a breach. This pattern can re…
Suggested Courses
Course of the Month8 days, 14 hours left to enroll
764 members asked questions and received personalized solutions in the past 7 days.
Join the community of 500,000 technology professionals and ask your questions.