vSAN1

 View Only
  • 1.  VSAN Maximum Storage Capacity

    Posted Jun 19, 2014 07:36 AM

    Hello there,

    Can you please confirm to me if my understanding is correct and that this is below the configuration maximums of VSAN?

    In case I want to deploy a 3 hosts VSAN where each host is capable of handling 16 HDDs.

    Per host: (2* 200GB SSD  + 14*1200GB SAS)

    Total (14*1200GB*3Hosts = 50400GB/almost 5TB RAW)

    Is this a valid configuration and what would be the usable capacity available? and will my 3 hosts accommodate for 42 disks?

    Regards,



  • 2.  RE: VSAN Maximum Storage Capacity

    Posted Jun 19, 2014 10:00 AM

    I think its 50,4TB Raw.

    200GB ssd per disk group off 8,4TB (7*1,2) is relative low. Although the 10% rule is no longer in place you should be really sure that less than 2,5% is enough.



  • 3.  RE: VSAN Maximum Storage Capacity

    Posted Jun 19, 2014 11:13 AM

    it seems low on SSD indeed. with a 10% rule you would be around 800GB per disk group, you list 200GB... Why the low number?



  • 4.  RE: VSAN Maximum Storage Capacity

    Posted Jun 28, 2014 03:08 PM

    Depping, maybe you can help clarify this. The Virtual SAN Design and Sizing Guide (https://www.vmware.com/files/pdf/products/vsan/VSAN_Design_and_Sizing_Guide.pdf) states:

    The general recommendation for sizing flash capacity for Virtual SAN is to use 10 percent of the anticipated

    consumed storage capacity before the number of failures to tolerate is considered.

    The example then demonstrates you size the flash based on the storage allocated to VMs so it's a front-end capacity calculation.

    Considering the configuration being discussed here, the disk group size stated by Mouhamad is 7 x 1.2TB HDDs = 8.4TB. You are suggesting 800GB per disk group which is 10% of the raw capacity.

    If we are to assume the default policy is consumed for FTT=1, after metadata overhead, 20% free space recommendation, etc. the maximum amount of provisioned storage would be between 3.3TB and 4TB per disk group.

    Wouldn't this  suggest a 400GB flash capacity per disk group based on the design guide approach?

    I'm asking because I've been sizing environments based on my math above but it would seem that your suggestion would make my configurations undersized in terms of flash.



  • 5.  RE: VSAN Maximum Storage Capacity

    Posted Jun 28, 2014 08:53 PM

    cmiller78 wrote:

    Depping, maybe you can help clarify this. The Virtual SAN Design and Sizing Guide (https://www.vmware.com/files/pdf/products/vsan/VSAN_Design_and_Sizing_Guide.pdf) states:

    The general recommendation for sizing flash capacity for Virtual SAN is to use 10 percent of the anticipated

    consumed storage capacity before the number of failures to tolerate is considered.

    The example then demonstrates you size the flash based on the storage allocated to VMs so it's a front-end capacity calculation.

    Considering the configuration being discussed here, the disk group size stated by Mouhamad is 7 x 1.2TB HDDs = 8.4TB. You are suggesting 800GB per disk group which is 10% of the raw capacity.

    If we are to assume the default policy is consumed for FTT=1, after metadata overhead, 20% free space recommendation, etc. the maximum amount of provisioned storage would be between 3.3TB and 4TB per disk group.

    Wouldn't this  suggest a 400GB flash capacity per disk group based on the design guide approach?

    I'm asking because I've been sizing environments based on my math above but it would seem that your suggestion would make my configurations undersized in terms of flash.

    Sure, if you follow that rule of 10% of anticipated consumed storage before FTT you can probably do with less. Personally I am not a fan of the rule because it requires you to have a good understanding of "anticipated" and I feel it will be a lot of guess work. I would rather have more than enough cache than too little. Hence I personally always just do 10%. But either works and both methods are just suggestions. If you want to do 1% cache you can even do that, but it probably will never properly perform