Data Backup and Recovery

Volume and Datastore configuration for SQL Server VM's using VMDK's

markwidrig
3,101 Views

I've read the most recent Microsoft SQL Server and SnapManager for SQL on NetApp Storage Best Practices Guide (TR-4003), but am still unclear of the the Netapp Volume and VM Datastore configuration for SQL Server VM's using VMDK's. The question is:

  • Should we create a separate Netapp Volume for each SQL Server VM (apx. 20 VM’s), then place all the Database VMDK’s for each SQL Server into these dedicated Volumes/Datastores?

There seem to be some conflicting limitations on the VM and Netapp side that have made this a more difficult decision:

  • Since we use NFS on our VM hosts, each Netapp Volume will correspond to a single datastore. A VM host (or cluster) is limited to a maximum of 64 datastores, so 20 volumes/datastores would consume a large portion of the maximum limit.
  • If we mix the VMDK's for several SQL Servers into a single Datastore, then we will need to offset the snapshot schedules for those SQL Servers, so they do not conflict with each other.
  • Since there is a maximum of 255 snapshots per Volume, having multiple SQL Servers in a single Volume/Datastore would mean we would need to schedule fewer snapshots per SQL Server or a have a shorter snapshot retention period.

Thanks.

Mark.

2 REPLIES 2

abhisek
3,101 Views

Hi Mark ,

How many SQL Server instances are you planning to run per VM? The restriction with 64 datastores is gone with ESX 5.0 .So there is a more  headroom for drawing the layout architecture.This is not a hard and fast rule to have a datastore dedicated to a single SQL VM .

You can still have multiple datastores for a single VM if there are high number of SQL instances running per VM.

Regards,

Abhishek

markwidrig
3,101 Views

Abhisek,

Thanks for the quick response. We only run one SQL Server instance per VM.

We are also in the process of upgrading our VMWare environment from v4.1 to v5.0. So, that will help with the datastore limitation.

Thanks again.

Mark.

Public