Sizing Details – Sizer Wiki Production

Sizing Detail Video

Sizing Details:

First of all you can look at Sizing Details for each cluster or All clusters.

In the top part are the resource requirements (Cores, RAM, HDD, SSD) from one or more workloads. These numbers are computed by the workload modules. Here we have a couple workloads and the resources are totaled under Total

The bottom section is the Capacity calculations for the recommendation.

The Raw Capacity row is the total available resources (cores, RAM, HDD, SSD) in the cluster(s). A few things need to be explained
- Cores is adjusted by specint weight and if there are memory issues like unbalanced DIMMS
  - here is the tooltip which shows the adjustment. There are total of 72 physical cores in the recommendation. This is number of models * number of cpu’s per model * number of cores per cpu
  - Sizer needs to adjust different core speeds as they can vary widely and SpecINt2006 is the standard used. Here it is -2.23 vs baseline processor. More information on how Applied Weight is calculated here Sizing Approaches and Logic
  - Sizer does test for unbalanced dimms and here there is no issue and so adjustment = 0. More information on how Unbalanced DIMMs is accounted for is here Sizing Approaches and Logic

So for Sizer in this example it assumes there are 69.77 “baseline” cores.

RAM – Here Sizer computes total RAM and converts it to TiB.

Here there are 3 nodes and each node has 32GB x 8 Dimms for a total of 768GB of RAM in the recommendation
A note of trivia, RAM is sold as GB but in reality is GiB. Since 32GB is less than 32 GiB there is no issue in marketing them in GB as customer is getting more than they expected. Sizer is very exact though and so we acknowledge its full potential of 32 GiB per DIMM and so here there are 768 GiB in the recommendation
Converting to TiB it is 768 GiB/1024 = 0.75 TiB ( there are 1024 GiB in 1 TiB, while 1000 GB in 1 TB)

HDD Here Sizer computes total HDD and converts it to TiB.

Here there are 3 nodes and each node has 4x2TB drives for a total of 24TB of HDD in the recommendation
Converting to TiB it is 24TB * 0.909494702 TiB/TB = 21.83 TiB

SSD Here Sizer computes total SSD and converts it to TiB.

Here there are 3 nodes and each node has 2x960GB drives for a total of 5760GB of SSD in the recommendation
We do allocate space for downstroking (80GB per drive) for regular SSDs but no downstroking if Encrypted drives
so here need to discount downstroking for 6 drives or 480GB. Now the net is 5760 GB – 480 GB = 5280 GB. This is 5.28 TB as there are 1000 GB per TB.
Converting to TiB it is 5.28TB * 0.909494702 TiB/TB = 4.80 TiB

Compression Savings is the total amount of compression savings found in the workload modules.

Dedupe Savings and ECX Savings (none in this example) are found in the workload modules

RF Overhead is the total amount of HDD or SSD needed to meet the RF2 or RF3 requirements that were set in the workload modules.

CVM overhead is calculated by Sizer following latest rules. See the next section. Also more information on how CVM Sizing is here Sizing Approaches and Logic

Workload total is the same numbers from workload section

Usable Remaining Capacity (Assuming RF2)

HDD Usable Remaining Capacity = (Raw + Compression Savings + Dedupe Savings + ECX Savings – RF Overhead – CVM overhead ) / 2
SSD Usable Remaining Capacity = (Raw + Compression Savings + Dedupe Savings + ECX Savings – RF Overhead – CVM overhead + Oplog ) / 2
Notes:
- If All Flash, Compression Savings, Dedupe Savings , ECX Savings, RF Overhead, and CVM overhead that would be attributed to HDD’s is applied to SSDs
- For SSD Capacity,Oplog is included as part of CVM overhead for SSDs but also added back into Usable capacity as it is a Write log and so is available for user data.

Usable Remaining Capacity (Assuming RF3)

HDD Usable Remaining Capacity = (Raw + Compression Savings + Dedupe Savings + ECX Savings – RF Overhead – CVM overhead ) / 3
SSD Usable Remaining Capacity = (Raw + Compression Savings + Dedupe Savings + ECX Savings – RF Overhead – CVM overhead + Oplog ) / 3
Notes:
- If All Flash, Compression Savings, Dedupe Savings , ECX Savings, RF Overhead, and CVM overhead that would be attributed to HDD’s is applied to SSDs
- For SSD capacity, Oplog is included as part of CVM overhead for SSDs but also added back into Usable capacity as it is a Write log and so is available for user data.

Extent Store (Assuming RF2)

As the tooltip indicates Extent Store is RAW less CVM. It represents the amount of storage left after CVM . Put another way it is amount storage available to the customer before workloads are added. Here workloads are not included. The workload RF copies are not included. Storage efficiencies such as compression or dedupe is not included. Extent store is a concept in the Nutanix Bible.
HDD Extent Store (Assuming RF2) = (RAW – CVM)/2 = (21.83 – 2.63)/2 = 9.6 TiB
SSD Extent Store (Assuming RF2) = (RAW – CVM)/2 = (4.8 – 2.03)/2 = 1.38 TiB

Extent Store (Assuming RF3)

As the tooltip indicates Extent Store is RAW less CVM. It represents the amount of storage left after CVM . Put another way it is amount storage available to the customer before workloads are added. Here workloads are not included. The workload RF copies are not included. Storage efficiencies such as compression or dedupe is not included. Extent store is a concept in the Nutanix Bible.

HDD Extent Store (Assuming RF3) = (RAW – CVM)/2 = (21.83 – 2.63)/3 = 6.4 TiB

SSD Extent Store (Assuming RF3) = (RAW – CVM)/3 = (4.8 – 2.03)/3 = 0.92 TiB

What are the details on CVM overheads?
- HDD numbers can be seen by clicking the “I” button
- SSD numbers can be seen by clicking the “I” button
- In case of AF all the CVM components are applied to SSD CVM
- In this example here is the HDD

In this example here is the SSD

Refer to Sizing Approaches and Logic for information on how these numbers are calculated

Sizing Detail Video

Extent Store (Assuming RF2)

Extent Store (Assuming RF3)

What are the details on CVM overheads?

Leave a Reply Cancel reply