Recommended Virtual Disk Size on S2D

[jadzea]

Just built a new Server 2022 2 node failover cluster with S2D and thinking about what’s the recommendation when creating a virtual disk on the storage pool to be used as cluster shared volume.

 

Question is, create one virtual disk for the CSV that is maximum space available in the pool, or create several smaller ones to store each virtual machines resources and VHDXs?

 

Coming to this from a dedicated SAN where we would have had volumes related to the LUNs on the SAN (ie faster disks as a LUN and slower disks as a LUN), so wondering what’s the best practice with this?

 

I’m tempted just to create one single virtual disk that occupies the whole storage pool and is set for CSV and then store all our VMs in this, but wondered if this is the optimal use of the disks in S2D? Ie is there some sort of overhead that uses more space with multiple virtual disks as CSV, or is there a speed or other benefit?

 

Any thoughts anyone??

[Aprice]

Best practice is that you break up into smaller volumes, the number of volumes should be a multiple of the number of nodes in the cluster. We have had to support a customer that had a volume fail in their S2D cluster in the past. The disks in that volume had to be restored. (the whole cluster actually needed rebuilding, but that's another story)

 

In your case I would suggest a minimum of two volumes for storing your VHDs

[jadzea]

Brilliant - thanks for your reply and guidance.

 

Do you know of any articles where I could read more about this? Keen to learn more about this topic.

 

Thanks again for your advice - I’ll certainly implement two now.

[Aprice]

No probs, Here's the Microsoft guidance on it:

 

https://learn.microsoft.com/en-us/azure-stack/hci/concepts/plan-volumes

 

Main tips for S2D are:

Separate domain from your main production domain (when things go wrong you then have to troubleshoot your virtualisation platform and your main network). Might be some debate from people around this, but so far it's helped us every time we've had to visit after an incident.

 

Make sure time synchronisation is setup correctly & working (we keep visiting clusters setup by some providers who should know better, where time synchronisation doesn't work / wasn't configured correctly. One Ended in complete failure of the cluster, corrupted volumes, VMs not booting, trust relationship issues between hosts.)

[jadzea]

That’s fantastic - thank you!

 

I completely agree with your comments on time servers - I’ve experienced hyper-v time drift before where virtual machines are supplying the time to the hosts and start to drift further and further.

 

Appreciate your help with this