2011-10-12 06:38 PM
This is related to post :
But I need a bit more basic information to give to the customer, so we can make the decision if SMSQL will be something they will be able to use. The goal is to persuade them to use our product, but I am trying to make a case for it, and I am unfamiliar with how VMDK's relate to SMSQL, as well as the volume / file level snapshots within a VM and a datastore. Will recovery in a case stated as the customer's below planned layout be relatively slow?
This is the current VMDK layout:
C: - 50GB (nothing but OS)
D: - 50GB (SQL binaries, system db’s, analytical stuffs, etc)
F: - 10GB (User db’s MDF/NDF)
L: 10GB (User Logs LDF)
T: - 10GB (Temp db)
X: - 20GB (SQL bkups)
These VMDK's are assigned on a single VM on a single datastore - NFS.
The questions I and the customer have are:
There are 121 Virtual SQL servers, standalone. These are to be migrated onto new FAS6240A.
Appreciate any feedback on this.
2011-10-13 06:48 AM
Hi Rich and welcome to the Community!
Well, a lot of useful info is in the thread you quoted already - especially towards the end of it.
E.g. as per Abhisek's post, single datastore is a no go:
You need to architect your environment keeping VM files and SQL db files on separate datastores. You would require separate vmdk’s for system db’s, user db’s, log files, temp db and log files.
2011-12-06 08:47 AM
How do you plan around the 64 NFS datastore limit in this scenario with 112 Virtualized SQL servers? Have any best practices been written to address the different SMSQL in a VM architectures and restore scenarios?