December 2, 2014 at 9:43 am
All,
I am going to be setting up two VM Servers. We are also using a SAN so it's technically shared storage. Should I configure the VM in the same way a normal server would be set up? Separate drives for data, logs, temp, etc? Does it really matter much since it's using a SAN? Would I see any performance increase if I created different disks? I wouldn't think I would.
Thanks
December 3, 2014 at 5:54 am
you need to supply a little more info on the intended setup. Will the VMs be using plain virtual HDDs on the ESX datastore or do you plan to attach RDM's from a storage area network for the SQL Server files
-----------------------------------------------------------------------------------------------------------
"Ya can't make an omelette without breaking just a few eggs" 😉
December 3, 2014 at 11:10 am
Great questions. This is the first time I've worked with a SAN. I will ask the systems admin. Do you happen to know of a good write-up/whitepaper to give me some really good in-depth knowledge about SAN's and the relation to SQL Server performance?
December 3, 2014 at 11:15 am
So it doesn't look like we use RDM. Basically we have storage assigned to a host and then spread out that storage among virtual machines.
December 3, 2014 at 1:41 pm
JoshDBGuy (12/3/2014)
So it doesn't look like we use RDM. Basically we have storage assigned to a host and then spread out that storage among virtual machines.
Hi Josh not sure if you got a little info on understanding of SAN from your "San Admin" but that would be a good first step. Hopefully they are friendly 🙂
Also if it's not RDM then you are getting your "drives" allocated from a datastore, which means that storage space is 'again' shared in this case within VMWARE (esx) this means if you ask for Data Drive, Log Drive, TempDB, etc... and you don't ask the VMWARE admin to use different datastores to help balance load and performance.. maybe you can give some parameters so it will help them understand your requirements. Otherwise unless they understand database requirements they could assign everything from the same datastore.
Although what I'm stating might not matter if based on the DB needs performance is good.
--------------------------------------------------
...0.05 points per day since registration... slowly crawl up to 1 pt per day hopefully 😀
December 9, 2014 at 9:27 am
I had a longer conversation with our system admin. So he created multiple LUNS for our environments. For the particular SQL Server, it's shared storage from one LUN, meaning it's basically the same set. Unfortunately I can't change this. So my thinking is that this is shared storage so even if we split up the files among different virtual drives that there won't be a performance benefit.
December 9, 2014 at 9:58 am
JoshDBGuy (12/9/2014)
So he created multiple LUNS for our environments.
yes but are they dedicated for the VM or has the ESX admin created an ESX data store on them?
JoshDBGuy (12/9/2014)
For the particular SQL Server, it's shared storage from one LUN, meaning it's basically the same set. Unfortunately I can't change this. So my thinking is that this is shared storage so even if we split up the files among different virtual drives that there won't be a performance benefit.
No performance benefit there if all on the same ESX data store, just easier data management. Bear in mind that every virtual disk, nic and scsi adapter you attach to the VM, requires a portion of the physical host resources in the form of memory and CPU.
-----------------------------------------------------------------------------------------------------------
"Ya can't make an omelette without breaking just a few eggs" 😉
December 11, 2014 at 7:50 pm
December 12, 2014 at 10:51 am
If you have high minimum performance requirements (it must always be at least this fast), then go back to your SAN admin with that and discuss dedicated storage.
If you do end up using storage that's shared at the physical drive level, then there's zero benefit from splitting up files onto different logical drives.
I do recommend having a logical drive for the OS (typically C:) keeping your SQL data and logs off of it; this is primarily to keep filesystem level fragmentation to a minimum on the SQL drive, and make sure that you can run CHKDSK on one without having to also do the other. If you need to run CHKDSK, it's most likely going to need to be only on the OS (or, perhaps, on on a SQL file); but it operates at a logical drive letter level, so I like to separate those.
Viewing 9 posts - 1 through 8 (of 8 total)
You must be logged in to reply to this topic. Login to reply