Usable Remaining Capacity is the amount of storage that is available to the customer AFTER workloads, RF, storage savings are applied.  It represents what they should have remaining once deployed.

Sizer presents the values in both RF2 and RF3.

Usable Remaining Capacity (Assumming RF2)

• HDD Usable Remaining  Capacity = (Raw + Compression Savings + Dedupe Savings + ECX Savings – Workload – RF Overhead – CVM overhead ) / 2
• SSD Usable Remaining  Capacity =  (Raw + Compression Savings + Dedupe Savings + ECX Savings – Workload – RF Overhead – CVM overhead + Oplog ) / 2
• Notes:
  • Usable capacity is basically RAW + storage savings with data reduction techniques like compression less workload, RF overhead and CVM overhead.
  • 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 as it is a Write log and so is available for user data.

Extent Store

This is a concept that is used in the Nutanix Bible.  This is RAW capacity less CVM.  It represents the capacity that is available to a customer

Effective Capacity

Used in Storage Calculator or DesignBrewz.  This is the Extent Store * Storage Efficiency setting in  Storage calculator.  So if the Extent Store is 10TiB and the Storage Efficiency factor is set to 1.5:1 then the Effective Capacity is 15 TiB.   Storage Efficiency factor is the expected benefit of storage reduction approaches like compression, dedupe, ECX.  Effective Capacity then is what is hoped to be available with these reduction techniques

In Sizing Details you may see an odd number like 40.27 cores for RAW cores as shown below

Actual Core Capacity

This is the total number of cores in the recommendation.

By clicking on the tooltip by the node you get the information

So in this recommendation we have 3 nodes where each has 2 cpu and each cpu has 8 cores.  So the Actual core capacity is 3 nodes * 2 cpu/node * 8 cores/cpu = 48 cores

Applied Weight

Intel designs a wide range of cpus to meet different market needs.  Core count certainly varies but the speed of a core is not the same across all cpu’s.

We need some benchmark to adjust for the core speed differences.  We use SPECInt 2006.  It is the best benchmark in terms of being an industry standard where vendors who publish numbers have to use standard testing process and publically publish the numbers.  We see consistency as well for a given CPU across all the vendors.  Thus this is a good benchmark to use for us to adjust for different values

So applied weight is where we have adjusted the cores to the baseline processor which runs at 42.31 specints

Review the Processor Table page with their core count, specints, and adjusted cores

Using this example we have a recommendation of 3 nodes with each node have quantity 2 2620v4 processors.  The table (calculation is shown in that page too) shows the 2620 v4 adjusted cores is 14.9 cores with nodes having 2 cpus

Thus in this recommendation total effective cores is 14.91 cores/node * 3 nodes = 44.73 cores.  We take applied weight adjustment of -3.26

Memory Adjustments

Broadwell Processors

With Broadwell processors “unbalanced DIMM” configuration depends on how they are laid out on the motherboard.  When it occurs there is a 10% increased access latency

To determine whether Sizer takes a discount it takes total count of DIMMs in a node and divides by 4. If odd number then it is Unbalanced and Sizer applies the discount.
If even, then no reduction is needed

Example

12x32GB in a node. 12 DIMMs/4 = 3 and so unbalanced
8X32GB in a node 8 DIMMs/4 = 2 and so balanced

If unbalanced core capacity is  reduced.

– Actual Core Capacity = Cores/Node * Node count
– Applied Wieght = extra or less cores vs baseline
– Adjustment due to Memory Issues = -10% * (RAW Cores+Applied Wieght)

It should be noted that if single processor system then NO adjustment is needed.

Skylake Processors

Skylake processors is more complex compared to Broadwell in terms of whether a system  has unbalanced dimms

We now test for the following

• CPU – skylake
• Model – Balanced_Motherboard – true  (described below)
• Memory bandwidth – go with slower figure for either memory or CPU.  If 2133 Mhz then -10% memory adjustment.   If 2400Mhz or 2666Mhz (most common with skylake models) we take a 0% adjustment

Like before, we find the DIMM count per socket.  There is typically 2 sockets (cpu’s) but can be 1 and starting to introduce 4 socket models

Using the quantity of DIMMs per socket we should apply following rules

If CPU is skylake

• If dimm count per socket is 5,7,9,10,11 then the model is considered unbalanced and we need to take a -50% memory adjustment
• if dimm count per socket is 2,3,4, or 12 it is balanced and memory adjustment = 0%
• if model is balanced and DIMM count per socket is 6 or 8 then it is balanced and memory adjustment = 0%
• if model is unbalanced and DIMM count per socket is 6 or 8 then it is unbalanced and memory adjustment = -50%

After determining the adjustment percent we would make the adjustment as we do currently

• Actual core capacity = Total cores in the cluster
• Applied weight = adjustment vs baseline specint
• Adjustment = Adjustment Percent * (Actual core capacity – Applied weight)

Here is the table of processors

SPEC 2017 Integer Ratings, refer to this Google Sheet

The data is based on the data published on

https://www.spec.org/cgi-bin/osgresults

SPECint Adjusted Core is simply adjusting cores vs a baseline CPU (Intel E5 2680 v2) of 4.44 SPEC 2017 Integer Ratings per Core

For example, the 2620 v4 has 16 cores but only at 4.14 SPEC 2017 Integer Ratings per core

• SPEC 2017 Interger Ratings per adjusted cores = 16 * SPEC 2017 Integer Ratings int per core / Baseline = 16 * 4.14/4.44 = 14.91
• Basically, this is saying the 2620 v4 has 16 cores, but it is equivalent to 14.91 baseline cores in 2 CPU nodes
• For a single CPU, it would be just 14.91/2 = 7.455

Looking at a high-speed CPU, the 6128 has just 12 cores but screams at 6.89 SPEC 2017 Integer Rate per core

• Specint Adjusted cores = 12 * specint per core/ baseline = 12 * 6.89/4.44 = 19.31
• Basically, this is saying the 6128 has 12 cores, but it is equivalent to 19.31 baseline cores

For the complete list of CPUs supported by Sizer and their SPEC 2017 Integer Ratings, refer to this Google Sheet.

Continue reading “CVM (Cores, Memory, HDD, SSD)”

At times no optimal solution can be found

Typical – No Optimal Solution Found Issues

When Sizer cannot find a solution given various settings and constraints it will simply say No Optimal Solution found. For example, if set node count to 3 nodes and ask for extremely large workloads it will say No Optimal Solution found as there is no 3 nodes solution to cover that many users.

So here is the list of common things users set that may cause No Optimal Solution.

• Node count set too low in the Auto Sizing panel
• Budget set too low in the Auto Sizing
• Set models to say 1065 and ask for lot of demand that requires more than 8 nodes
• NearSync is selected and using ROBO models like 1175S

What to do

• Get back to Automatic Sizing with
  • No Node Count filter
  • No Max Budget filter
  • Set model types to All Regular models