Dear Members,
Can we use 4x vSAN Standard per socket licenses + 1x vCenter Foundation for 2 node vSAN cluster?
secondly if we need say 4TB usable capacity with RAID1 FTT1, how we gona calculate it for 2 node cluster?
my understanding regarding paper calculation is as follows
Required Usable Capacity = 4TB
Adding RAID1 Overhead = 4TB*2 = 8TB
Adding Slack Space = RAID Overhead +30% = 10TB
Adding Swap Space = Adding Slack Space + 20% = 12TB
Adding Disc Overhead = Adding Swap Space + 10% = 14TB
RAW Capacity Required per Hosts = 14TB / 2(as cluster is a 2 node vSAN cluster) = 7TB
Regards,
Moaz Anjum
Hello Moaz,
"Can we use 4x vSAN Standard per socket licenses + 1x vCenter Foundation for 2 node vSAN cluster?"
Yes - vSAN licensing is separate from ESXi licensing. Additionally, it is only vCenter Essentials edition that has the limitation of being able to only manage 'Essentials' licensed hosts - Foundations does not have this limitation.
Your sizing seems a little on the big side:
- If by "Swap space" you mean for .vswp Objects then you shouldn't need much for this as these can be set to thin (and are default thin in 6.7) and if you have the host memory sizing done correctly then your VMs shouldn't be swapping.
- vSAN Filesystem overhead is only going to take about 1-2% of disk capacity.
- Not sure what you mean by "Adding Disc Overhead" but if you are referring to space for temporary snapshots (e.g. during backups) this likely won't be huge unless you have VMs with rapid data-change and/or slow backup.
6TB per node should be fine but do consider adding for growth and also whether you are basing this on current thin-provisioned VMs that will grow or actual full allocated size.
Other recommendations would be:
- Aim for 'sweet-spot' sized devices which in my opinion is ~1.6-2TB - much smaller and component placement for large Objects can get messy, much larger and performance will go down due to less IO paths aswell as bigger resyncs if a disk fails (potentially causing a node to run out of space and not be able to repair all data to FTT=1).
- Go SAS over SATA if you can, bigger queue-depth and better de-stage rates.
- Size your Cache-tier devices accordingly - if it is a cluster that doesn't require huge write-intensive IOPS then smaller caches (e.g. ~2-400GB) will *likely* suffice but do take the workload profile into account - again this can also depend on the device e.g. I have seen 400GB optanes NVMes do twice the work (and better) than 800GB SAS SSDs. Cache-sizing also varies depending on Hybrid vs All-Flash:
Design Considerations for Flash Caching Devices in vSAN
Designing vSAN Disk groups - All Flash Cache Ratio Update - Virtual Blocks
Bob
Hello Moaz,
"Can we use 4x vSAN Standard per socket licenses + 1x vCenter Foundation for 2 node vSAN cluster?"
Yes - vSAN licensing is separate from ESXi licensing. Additionally, it is only vCenter Essentials edition that has the limitation of being able to only manage 'Essentials' licensed hosts - Foundations does not have this limitation.
Your sizing seems a little on the big side:
- If by "Swap space" you mean for .vswp Objects then you shouldn't need much for this as these can be set to thin (and are default thin in 6.7) and if you have the host memory sizing done correctly then your VMs shouldn't be swapping.
- vSAN Filesystem overhead is only going to take about 1-2% of disk capacity.
- Not sure what you mean by "Adding Disc Overhead" but if you are referring to space for temporary snapshots (e.g. during backups) this likely won't be huge unless you have VMs with rapid data-change and/or slow backup.
6TB per node should be fine but do consider adding for growth and also whether you are basing this on current thin-provisioned VMs that will grow or actual full allocated size.
Other recommendations would be:
- Aim for 'sweet-spot' sized devices which in my opinion is ~1.6-2TB - much smaller and component placement for large Objects can get messy, much larger and performance will go down due to less IO paths aswell as bigger resyncs if a disk fails (potentially causing a node to run out of space and not be able to repair all data to FTT=1).
- Go SAS over SATA if you can, bigger queue-depth and better de-stage rates.
- Size your Cache-tier devices accordingly - if it is a cluster that doesn't require huge write-intensive IOPS then smaller caches (e.g. ~2-400GB) will *likely* suffice but do take the workload profile into account - again this can also depend on the device e.g. I have seen 400GB optanes NVMes do twice the work (and better) than 800GB SAS SSDs. Cache-sizing also varies depending on Hybrid vs All-Flash:
Design Considerations for Flash Caching Devices in vSAN
Designing vSAN Disk groups - All Flash Cache Ratio Update - Virtual Blocks
Bob
Thank you for replying to my question in detail.
Best Regards
Moaz Anjum
Hello Moaz,
"What I can understand from your reply regarding vSAN licensing, it is not necessary to use vSAN Standard ROBO 25VMs Pack, we can use vSAN STD 4 sockets licenses and still be able to download & create witness node on a separate host right?"
No I don't think it would require ROBO licensing as per our licensing guide (6.7):
"The 2-node vSAN deployment model is not restricted to a specific vSAN license edition. In other words, any of the licensing editions can be used with a 2-host configuration."
Bob