We are currently running sql 2008 on server 2008 using iscsi initiator connected disks for our database and log file drives. This works fine for us but we are implementing Zerto replication and have to move the drives to vmdk files.
We have moved 2 of our slightly less used databases over and the drives are connected using a single paravirtual controller for all 6 drives: OS, Pagefile, Database, Logs, TempDB, SysDB. Everything looks to be working fine. We are now looking to move our main SQL server that holds 90% of the companies business.
My question is should we continue with a single paravirtual controller for the drives or a controller per drive?
thanks
lee
i can confirm vfk
i always use 2 controllers for performance and keep in mind the underlying lun RAID level (RAID 10, RAID 5, etc.)
here is a good blog about what controller to use
Which vSCSI controller should I choose for performance? | VMware vSphere Blog - VMware Blogs
Generally I would recommend using two different controllers, one for OS and one for data or other applications as this will give better performance i.e more io queue.
Also, I would recommend reading sql best practise for other recommended settings. http://www.vmware.com/files/pdf/solutions/SQL_Server_on_VMware-Best_Practices_Guide.pdf
i can confirm vfk
i always use 2 controllers for performance and keep in mind the underlying lun RAID level (RAID 10, RAID 5, etc.)
here is a good blog about what controller to use
Which vSCSI controller should I choose for performance? | VMware vSphere Blog - VMware Blogs
Thanks for that, the link explained it a bit better. we have the database and logs on separate raid 10 luns the rest are on raid 5 (I think)
vkf,
when you say use 2 different controllers. use 2 different types or just 2 separate controllers?
After reading Vervoot's link I was planning on setting it up like this
O/S on 0:0 PVSCSI
Database on 1:0 PVSCSI
Logs on 2:0 PVSCSI
Temp on 3:0 PVSCSI
SysDB on 3:1 PVSCSI
PageFile on 3:2 PVSCSI
Just two different controllers, the type of controllers only matters when you are pushing very high IO. Using PVSCSI on O/S doesn't really make much difference and given that you would have to inject the PVSCSI drivers during install, it is not really worth the hassle for no additional gain. PVSCSI for your database is probably good idea.
Looking at your planned configuration IMHO, that is too many too controllers and little over the top. I think you would be fine with just 2. But it all depends on your IO and workload. In virtual environment, KISS principle is a key to successful implementation, be very careful not to over engineer a solution.
The c drive ones are already there. I have it within our base image.
This SQL server is very heavily utilised and runs our main document management system so everyone uses at all times of the day. So I need to get it right first time.
I could set it up as:
O/S on 0:0, Temp on 0:1, SysDB on 0:2, PageFile on 0:3 using 1 PVSCSI
Database on 1:0 PVSCSI
Logs on 2:0 PVSCSI
Just out of curiosity, what is the I/O requirement for this document management system? If you can meet the IO requirement on the storage end, then you could just do, one controller for O/S and everything on the other controller.