1

I know that similar questions have been asked already, but I feel that they were on a rather theoretical level and are not quite applicable to my case.

We're operating 3 ESXi 6.0 hosts, all backed by the same HP EVA P6300 via FC. As proposed by the EVA P6300 Best Practice Guide (https://h41368.www4.hp.com/h41111/rfg_formprocessor/SWD_Installed_Base/pl/pl/pdf/TWP_4AA3-2641ENW.PDF), we've put all out 48 disks (600GB, 10k RPM) into the same Disk Group.

I like to use vRaid6 because I personally feel a bit uneasy when using a Raid0 over 6x Raid5s with 8 Disks each (which is essentially what EVA does with vRaid5).

Overall we have about 40 VMs, most of them (~35) with very little Disk I/Os, and a few (~5) with high Disk I/O spikes every couple of minutes (SQL servers / file servers).

For handling reasons, it would be easiest to just create one big LUN/Datastore. Given the fact that all LUNs we create would be backed by the same physical disks anyway, are there any performance implications when only having one LUN? Is there a point in having more than one LUN because of locking or I/O queues?

The HP Best Practice Guide states that one should "Follow operating system and application requirements for LUN count", but I couldn't find any information by VmWare regarding a recommended LUN count.

Thanks in advance for any insight!

Improve this question

2 Answers 2

Reset to default
1

Although we're phasing out our P6xxx boxes I've had a lot of experience with them in this exact situation - firstly the 'one big disk group' is the right way forward, secondly please avoid RAID 5/50 (we can bore you with the numbers behind it but essentially it's quite a dangerous thing to use the larger the disks are), use R6/60 or R1/10 ok.

are there any performance implications when only having one LUN?

Yes but very minor, the vSphere Performance Guidelines document for v6 state that ideally you should have more smaller LUNs than one big one but it's not that big a deal. Time was when one VM writing would lock that LUN but that's been gone for a long time and while there are one or two very small issues (the queues issue you mention is one) with very large LUNs you're only talking a couple of percent difference in performance. Personally I like 2TB LUNs but feel free to have larger ones if you like.

Improve this answer
1
  • 1
    Totally correct answer. Just to add, usually, LUN separation may only be required if your backup routine includes storage snapshots. In most cases LUN size has no impact on the performance and stability of storage subsystem.
    – Strepsils
    Aug 8, 2016 at 13:45
3

It would be great to know your current IOPS level, what does esxtop or VeeamOne report say? Also, how much space do you need for the VMs? How much of that for the 5 active ones? Calculating storage for your task requires additional variables to be precise.

With 48 Drives in a RAID 5 you can get 27.4 TB @ ~1600 - ~2800 IOPS (calulated for mixed Random I/O workload). I'm not 100% sure this will be sufficient performance for roughly 40 VMs. 5 intensive ones may eat a lot of the array's performance easily and make other 35 suffer. What I would suggest is to do a RAID 10 LU for the 5 I/O-intensive VMs which will give them around 3.6 TB @ 1400 IOPS and guaranteed low latency. Remaining drives go into ~20 TB RAID6 and still give you ~1200-2100 IOPS which is not that far from the original 1600-2800 you had when doing a 48-drive RAID6.

I don't want to go further into theoretical storage so I'll stay tuned for additional inputs about your environment. The idea above illustrates the approach I recommend to take with I/O-intensive VMs.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .