Best Desgin for SQL Server on Vmware ?

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 ?

Who is Participating?

Improve company productivity with a Business Account.Sign Up

patkremerConnect With a Mentor Commented:
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.
mohssinmAuthor Commented:
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 ?
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.
mohssinmAuthor Commented:
There is no direct and clear answer . it was describing
mohssinmAuthor Commented:
Thanks patkremer
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.