Get a firm grasp on your IT environment when you learn Active Directory best practices with Veeam! Watch all, or choose any amount, of this three-part webinar series to improve your skills. From the basics to virtualization and backup, we got you covered.
Course Of The Month
2 days, 3 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
Use this article to create a batch file to backup a Microsoft SQL Server database to a Windows folder. The folder can be on the local hard drive or on a network share. This batch file will query the SQL server to get the current date & time and wi…
In this article we will get to know that how can we recover deleted data if it happens accidently. We really can recover deleted rows if we know the time when data is deleted by using the transaction log.
In this video, viewers are given an introduction to using the Windows 10 Snipping Tool, how to quickly locate it when it's needed and also how make it always available with a single click of a mouse button, by pinning it to the Desktop Task Bar.
Int…
Do you want to know how to make a graph with Microsoft Access? First, create a query with the data for the chart. Then make a blank form and add a chart control. This video also shows how to change what data is displayed on the graph as well as form…
Suggested Courses
Course of the Month2 days, 3 hours left to enroll
Earn Certification
Administering Microsoft SQL Server 2012 Databases (Exam 70-462)
$79.00$71.10
717 members asked questions and received personalized solutions in the past 7 days.
Join the community of 500,000 technology professionals and ask your questions.