I have a question related to the "vSAN Capacity Meter" under Cluster > Monitor > vSAN > Capacity and how it relates to a vSAN stretched cluster deployment.
My understanding is: vSAN is a cluster level construct and capacity is viewed logically at the cluster level. So if we are looking at capacity from a vSAN stretched cluster point of view, this is the capacity that the entire system has for both sites (combined).
So my question is this... ideally we should try to keep capacity to under 50% of this meter. As this is a stretched cluster, one of the main use cases is having a solution that can withstand / mitigate an entire site failure. If we lost one of the sites... the one surviving site would host all of the storage (goes from 50 to 100%).
Is this correct?
Thanks!
@sevenlogic, No that wouldn't be necessary. The default policy for Stretched cluster is stores data as FTT=1,RAID1 across sites e.g. data-replica on SiteA + data-replica on SiteB + witness component on Witness site.
So, let's say you had 80% used of the total cluster storage, then you lost SiteA, the data would remain accessible from SiteB (but would be functionally FTT=0), the clusters total capacity would be halfed but the usage at SiteB would still be 80% (of this now lower total amount).
You should leave enough available capacity on the cluster for growth/increase of vmdk size (as almost everyone stores these as thin-provisioned these days), any additional data that may be moved to the cluster and for any temporary space usage (e.g. snapshots during backups or changes).
@sevenlogic, No that wouldn't be necessary. The default policy for Stretched cluster is stores data as FTT=1,RAID1 across sites e.g. data-replica on SiteA + data-replica on SiteB + witness component on Witness site.
So, let's say you had 80% used of the total cluster storage, then you lost SiteA, the data would remain accessible from SiteB (but would be functionally FTT=0), the clusters total capacity would be halfed but the usage at SiteB would still be 80% (of this now lower total amount).
You should leave enough available capacity on the cluster for growth/increase of vmdk size (as almost everyone stores these as thin-provisioned these days), any additional data that may be moved to the cluster and for any temporary space usage (e.g. snapshots during backups or changes).