Posts

Posted on

Sizer BOT

SizerBot is here to assist the Sizer team is answering questions that are of repetitive nature. This guide breaks down our approach for Phase 1 and our plan to continuously build on feedback generated.

 

Types of questions on the Sizer Channel

We classify questions on Sizer into two specific buckets:

  1. The first set of questions typically hold answers based on unique configurations and combinations of sizing
  2. The second set of questions are more generic such that its answers can be found through the wiki

 

What questions does the bot address?

Extensive research within the fields of ‘conversational AI’ are underway to mine through the first set of questions. This requires larger sets of data as well as the ability to interpret the context of questions, which we are currently exploring for the next few phases of the bot.

 

For the first phase we are targeting a small subset of repetitive questions that we are building on using content from this channel as well as from the Sizer product managers.

 

How does the bot work?

Based on a list of questions stored, we use a matching algorithm to identify if a similar question, as asked on the slack channel, exists in the database. While we can get the bot to provide a response to every question asked on the slack channel, we are avoiding this by increasing the threshold to 90%. This means, unless the probability of the match is greater than 90%, no answer will be provided. This is often referred to as the trade-off between precision and recall which helps address the question of do we want the bot to provide more answers, or do we want the bot to provide more answers accurately?

 

Improving the bots performance

We currently have two ways of improving the bots performance:

  1. When a question is answered by the bot – The feedback provided is used to upvote or downvote the bots response
  2. When a question is not answered by the bot – We first identify if the question is repetitive in nature, if so the questions are automatically logged back to a database through a separate slack channel

 

Suggestions

 

We are always open to more suggestions and recommendations on how to improve this process. You can reach out to revathi.anilkumar@nutanix.com with your feedback.

Posted on

November 2018 Sprint

November Sprint

  • Collector 1.1 Support  – Sizer to include median values from Collector.  We mine the VCenter data and get actual core usage.  THIS VERY COOL AS CAN SAVE CBL CORES WHICH COSTS LOTS OF $$.
  • Velocity models for partners and Nutanix users –  Velocity models are the NX-1065-G6 and can be up to 8 nodes but offer better discounts.
  • XC Core support.  Quotes and BOM show CBL and XC Core. Budgetary quote coming soon
  • Applied spectre adjustment for VDI and Xenapp – Windows 7 – 20% hit, Windows 10 version 1709 – 7% hit, Windows 10 version 1803 – 11% hit
  • Performance Improvements.  Homogeneous sizing typically reduced by 50%, while heterogeneous sizing reduced by 30%
  • File Services updates like setting Erasure Coding to ON by default
  • Budgetary quote improvements – can now apply discounts for SW Only quotes or NX Disaggregated quotes
  • New product updates for various vendors
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

October 2018 Sprint

Hi everyone

We released the October sprint

• The BIG thing is Hardware Disaggregated quoting is now in Sizer. As a SFDC user you can start a scenario and tie it to a account and opportunity as you do today. If that account is a Software Choice account (where disaggregated is used) then Sizer will create the proper quote where it includes the Software licenses (Capacity based licenses), Hardware and the Hardware support. In addition, you will see that quote reflected in the BOM. Soon the budgetary quote will be provided too. If the customer is not enabled for Software Choice then the regular appliance quote can be created as it is today.

• Collector and RVTools summary (excel you receive from Sizer after uploading the tool output) now gives explanation when certain VMs are not sized. For example, if the VM was powered off.

• SFDC syncing on daily basis. Now we pull SFDC changes once a day automatically. So any price changes or product changes are updated in Sizer. This is key for sizing but also when we show budgetary numbers

• Nutanix G5 models except the NX-1175S-G5, 8150-G5 and 3155G-G5 are in manual only since only these G5 models can still be quoted.  In manual sizing you can still do a sizing with the G5 models.

 

Posted on

September 2018 Sprint

September sprint includes:

Budgetary Quote UI:

User doesn’t have to download excel to see the pricing on quote. The new interactive UI will allow one to see list prices and apply discounts to see the sales/net price. You can iterate the entire process (size, generate budgetary quote and apply discounts) and download the quote when fully satisfied.

Enhancements to the Financial assumptions:

– Support levels have been sorted

– Monthly support terms (14months, 26 months..etc.) have been added

– Brief description has been been added next to each support level

– Ability to apply discounts to Budgetary Quote has been moved to the new Budgetary Quote UI.

Regular/Robo Models

There was confusion on how robo models like the 1175S should be sized.  For Regular models which are used in data centers,  PM originally wanted to restrict the 1175S to just backup usage.  That in ROBO they could be used as application nodes that could be 1, 2, or 3+ nodes.

That brought some confusion when SE wanted to size a small cluster with say qty 5 of the 1175S.  Sure could do it in ROBO, but SE would say it is not a ROBO customer project.

So I worked with PM and we streamlined the rules and now models like the 1175S (lot of vendors have similar ones) are treated as fully functional models as follows:

Regular Model Rules

  • All models included
  • All use cases are allowed – main cluster application, remote cluster application and remote snapshots
  • 3+ nodes are recommended for any model. It is considered good data center practice to have a minimum of 3 nodes.

ROBO Model Rules

  • All models but only some models like the 1175S can size for 1 or 2 node, while others require 3 min nodes
  • All use cases – main cluster application, remote cluster application and remote snapshots
  • All models can go to 3+ nodes depending on sizing requirements

So what should you do

  • Just stay with Regular models for most of your sizing needs. It is default and models like 1175S can indeed run applications.  Any recommendation would be 3+ nodes
  • Only go to ROBO if you need 1 or 2 node for 1175S

For more info go to the Sizer wiki –  ROBO-Regular

Rack Awareness:

Nutanix has always had node awareness and for long time block awareness both of which are in Sizer.  With this release, Sizer will also have rack awareness where Data Availability is maintained even in an event of an entire rack or top-of-the-rack switch failure.

Supported Use Cases

  • Heterogeneous solution made up of several different homogeneous blocks

–    For example, could have several 3460 blocks and several 3360 blocks

–    Here the 3460 blocks are all identical, while all the 3360 blocks are identical.  Given that, the 3460 block is homogeneous and the 3360 block is homogeneous.

–    These homogeneous blocks are dispersed across sufficient racks to meet rack awareness

  • We will support a cluster wide setting for rack awareness and assume all workloads in that cluster must adhere to rack awareness

Other things

  • Share notice in email. Sharing has been around forever and put in your Shared Scenarios but now when a person shares a scenario an email goes to them.  Great to increase collaboration and we will do more
  • We have all Sizer and “non-Sizer” parts for all HP and Cisco models. Non-Sizer parts are things sizer does not analyze like say storage controller, boot drives , etc.  Where before we asked you to click link to HFCL we got in the BOM.
  • Lots of product updates
  • Inspur is a new vendor
  • 3060-G6 NVME is there
  • We allowed “no modification” as option for VDI when selecting desktop or office version.  Sometimes people have need to size for so much MHz or Cores per user and don’t want the modification.  In future Collector will use that option too when we upload a collector output

 

 

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.