I have a small vmware ESXi 4.1 setup.
3 Hosts and only a few Windows 2008 R2 servers ie: VMs.
One of them will be a SQL 2008 server running our Sharepoint databases.
What's the best practice for this?
Currently I have a 1 TB volume on a Dell Equallogic for my shared Vmware datastore.
That's where all my VMs are going.
Should I just add another virtual hard disk using the VCenter console on the SQL server or should I create another volume on the Equallogic for the SQL databases and make an iSCSI connection from within Windows to it?
Any pros or cons?
I'm thinking just keeping it within the vmware volume would be the easiest but I wasn't sure.
I don't expect the SharePoint SQL database to get over 500GB for a few years and there's more space on the Equallogic so I can expand when that happens.
My concern about going with a seperate volume on the Equallogic for the databases is whether or not Windows will have any problems/corruption if I have to revert to an older snapshot or make a clone for any reason.
Also, since I'm asking now, once this is up and running properly I'll be setting up Exchange 2010 and I'll be asking the same question about where to put those databases.
Safe to assume the answer will be the same for Exchange and SQL?
There is a VMware doc which would help. It relates to ESX3 but the principles are the same: http://www.vmware.com/files/pdf/sql_server_virt_bp.pdf
Storage is key to your SQL performance.
You can use tools such as SQLIO within a VM to see the IOPs and Latency. Running SQLIO tests on multiple VMs in the same LUN will allow you to see the limits of your LUN performance and you can then decide the best storage configuration.
I would personally keep all of the VMDK files for the virtual server in the same VMFS volume rather than spreading the VM across multiple volumes.
I would consider what kind of I/O you expect on the volume and the number of VM you will run on the volume,IMO I would create separate volume for the SQL and, in the future, Exchange, if RDM or VMFS it depends on many things.
Another thing is how big will be the DB and the transaction log and how it is build the storage (cluster size, alignment with VMFS, etc).
microsoft got some simple tools (excel) to help you to build the correct configuration for sql and exchange and from there you may start to build your storage architecture.
Thank you for both your posts.
I need to do some more reading! lol
I guess to further clarify, is it better to have VMWare control the SQL database LUN/Volume or Equallogic/Windows?
If I have to restore the SQL server VM for some reason will I be better off with the database volume being part of the VMware 1TB volume where the VM's are or should I have a seperate volume on the equallogic?
And we really over bought the hardware for our needs (for a while anyway).
No more than 200 users will be accessing Sharepoint regularly and we only have around 400 email accounts using Exchange.
We've had Exchange run on one server for the past 3 years with no performance issues.
So I guess I'm less concerned about performance and more concerned about ease of management.
Unless you have some needs to access the LUN directly (clustering with physical hosts, more than a 2 TB LUN size as examples) I would stick with a virtual disk. But as the other have stated I would be most concerned with performance as to deciding whether or not to use the existing VMFS datastore. The 200 SP / 400 Exchange users aren't going to be too concerned with management ease :). How many disks spindles do you have for the current VMFS datastore? In regards to backup it'll depend on your overall backup strategy. If you plan to use a backup agent within each VM (i.e. more of a traditional backup model), then it doesn't matter if the SQL Server uses a virtual disk or has direct LUN access. If you plan to backup via vSphere then it'll be easier to do with a virtual disk.
I agree with others I would stick with the VMFS, RDM is justify IMO only if you expect need LUN larger than 2TB.
About how to design VMFS I think that this pdf may help you in your architectural design.
I would suggest creating a new LUN on your EqualLogic array. If you can, thick-provision it. Then add VMDK drives as needed to the SQL Server VM and run the lot of it from the new LUN.
Using this approach, EqualLogic's SanHQ will give you long-term performance and usage metrics for the SQL Server seperately. Also you'll be able to set a RAID level preference for it, in case in future another EqualLogic array is added to the pool with a different RAID level.