Author: Ratan Kumar

Posted on

Processor input for workload(s)

What is this feature all about? 

Now Sizer provides an option to select the type of processor the workload (existing or proposed) is running on. This gets factored in while sizing for the workload adding precision to the sizing and overall recommendation.

To give an example of how it helps.. an existing worklaod (say Server Virt, 100 of them) running on a weak processor (say a Haswell 2699v3, specint-38.58) would require less cores in sizing than the same 100 VMs running on a high performing CPU( like Skylake 8156 specInt -68.85).

Previously, the processor for existing workload was not taken into account, though Sizer always used a baseline processor[E5 2680v2] . So irrespective of whether the current worklaod is running on a slowest processor or the fastsest one, sizings used to remain the same.

With this new addition, there is a lot more precision added to sizing as we account for the incremental changes due to different type of processors.

 

How do we handle the processor input during sizing? 

Here is an example: input processor Broadwell E5 2690v4[46.43 specInt]

  • Lets say sizing comes to 32 cores 
  • This sizing is at the baseline [E5 2680v2, 42.31 specInt]  – Sizer defualt used until now
  • This has to be adjusted against the input processor E5 2690v4
  • 32*[46.43/42.31] = 35.11
  • The way to read this: 
    • If your existing processor was E5 2680v2(42.31), then the workload would require 32 cores 
    • If your existing processor(E5 2690v4) is stronger than the above baseline (specInt wise), you would need more cores

 

Where do we select the processor input for the workload? 

In the page where we give the workload name and select the type of workload, there is a dropdown to select the processor the workload is running on.

Currently, we support only one processor type per workload , however, there are chances that sometimes a workload can be running on mixed CPUs. In that case, it is advisable to go with the processor with better performance among the two.

Please note: This feature only deals with sizing based on the selected processor. It does not reflect or has any influence on the type of processor chosen for the recommended hardware. The HW recommendation continues to be driven based on the optimal HW solution based on the resources required (cores/flash/capacity)

Posted on

Cold tier data adjusted in Hot tier

Sizer always finds ways to propose the most optimal solution in terms of resources and cost.

As part of this effort, in certain cases , Sizer adjusts the workload data suposed to be sitting on the cold tier storage(HDDs) onto the hot tier storage(SSDs).

This happens in circumstances where there is surplus of SSDs in the BOM which is unutilized. The unutilised flash capacity is used for cold tier data if it helps reduce the overall number of nodes or if it helps avoid adding additional disks to met large HDD requirement if the extra SSD capacity can meet the same. The defined threshold levels are maintained and does not change for this adjustment in particular.

The same can be seen in a separate row in the calculation table and the Sizer BOM . Sample below:

 

Posted on

BOM contents for SW only platforms

Thi article explains the contents of the BOM for SW only platforms like HPE, Cisco, Dell PE etc

Sizer specifically focuses on certian parts of a server. The workload which is being sized determines the number and quantity of each of these parts. These are primarily the CPUs, Memory, SSDs/HDDs and NICs.

However, a server has other non sizer parts which does not impact sizing but are equally important to be a valid and qualified combination. Examples of non sizer parts are boot drive, power supplies, storage controller, chassis etc

The Sizer BOM lists both the sizer and non sizer parts. We need to make sure that all components listed on the HCL are accounted for on the BOM built by your partner. We cannot have any omissions of required components.

An example of a Cisco UCS BOM:

The Sizer parts listed with details and quantity of the CPUs/Memory/SSD/HDD/NICs required.

It is followd by listing of the non sizer parts. This includes Boot Drive, Chassis, Power supply, Storage Controller, Network Adapters.

 

 

 

Posted on

VDI Sizing with Collector

VDI Sizing

“Workload type” column in Collector?

Collector has a column “Workload Type” in the VMInfo tab where you can define the workload type for each VM.  Currently, only two type of workload is supported – Server Virtualization or VDI.  The defualt is set to Server Virtualization as this workload has been supported since beginning.

For VDI, you can go to each VM and change the Workload Type to VDI against each row.

Note: User has to explicitly go to each row and set the Workload Type as “VDI” .We will change it to dropdown to make it more intutive in future.

 

Defining the workload profiles 

Each VM which is marked as VDI is bucketed into one of the 25 profiles based on the CPU(MHz) and RAM allocated to the VM.

CPU

  • Small  <= (0-2000MHz)
  • Medium  <= (2000-4000MHz)
  • Large <= (4000-8000MHz)
  • X-Large  <= (8000 – 16000 MHz)
  • XX-Large <= (16000 – 32000 MHz)

RAM

  • Small = <1.024GB
  • Medium <2.048 GB
  • Large <8.2 GB
  • X-Large <16GB
  • XX-Large <32 GB

The 25 workload profiles based on the above.

  • VDI Small CPU Small RAM
  • VDISmall CPU Medium  RAM
  • VDI Small CPU Large  RAM
  • VDI Small CPU X-Large  RAM
  • VDI Small CPU XX-Large  RAM
  • VDI Medium CPU Small RAM
  • VDI Medium CPU Medium  RAM
  • VDI Medium  CPU Large RAM
  • VDI Medium  CPU X-Large RAM
  • VDI Medium  CPU XX-Large  RAM
  • VDI Large CPU Small RAM
  • VDI Large CPU Medium  RAM
  • VDI Large CPU Large  RAM
  • VDI Large CPU X-Large  RAM
  • VDI Large CPU XX-Large  RAM
  • VDI X-Large CPU Small RAM
  • VDI X-Large CPU Medium  RAM
  • VDI X-Large CPU Large  RAM
  • VDI X-Large CPU X-Large  RAM
  • VDI X-Large CPU XX-Large  RAM
  • VDI XX-Large CPU Small RAM
  • VDI XX-Large CPU Medium  RAM
  • VDI XX-Large CPU Large  RAM
  • VDI XX-Large CPU X-Large  RAM
  • VDI XX-Large CPU XX-Large  RAM

Storage for each workload profile is calculated by adding the capacity for each VM in that profile (same as done for Server Virtualization)

Sizer asks for the VDI attributes upon Collector import:

Defualt values already selected.

The default values ( or user selected values ) captured here becomes the basis  for initial VDI sizing.

Edit workload :

User can go to each VDI workload and make edits. However, this will overwrite the data collected from Collector (for ex: on capacity,ram etc) . The standard pre-defined templates ( defined in the normal VDI sizing) is applied once edited and parameters changed( like worker type, provision type, etc).

VM Performance data:

Collector also has performance data for the VMs collected over a 7 day period.  The VM CPU utilization over past 7 days collected at 30 minute interval is collected and  displayed. in the UI.  While sizing, users can either go with allocated CPU or factor in the utilization rate to optimise on the overall CPU requirement for the VMs based on their historical usage.  Basically, the utilization rate is a multiplier to the allocated CPU and a buffer is added to come up with net CPU.  For more information on that, please refer to the Collector section.