Once you have gathered the workload requirements using Collector, you can export the data to Sizer and view the Nutanix solutions or recommendations that are best suited based on your workload needs.
You can feed the Collector data to Sizer in a couple of ways:
1) Using the “Export to Sizer” option within Collector Portal or
2) “Import” workload option available in Sizer
There are various options while feeding the Collector data to Sizer. On this help page, we will describe how and when to use the different available options.
For demonstration purposes, we will be exporting the data from Collector Portal to Sizer. To export the data to Sizer, navigate to desired Project in Collector Portal and click Export and select the Export to Sizer option as shown in Figure 1 below.
On clicking “Export to Sizer” you will be shown a pop-up with the various sizing options as seen in Figure 2 below.
At a very high level, the sizing options are based on the number of VMs and their requirements – the compute, memory & storage. Before we jump into the details of the sizing options, you can edit the name of the Sizer Scenario that we are about to create so that you can identify the same in Sizer.
Now, let’s start with the “VMs” option – Powered ON only vs Both powered ON and powered OFF. Nutanix Collector gathers configuration and performance data of all the VMs managed by the IP address specified while establishing the connection. There is one exception though, Collector does not collect the CVMs (Controller VMs) identified by Prism Central or Prism Element as these VMs are never sized. If there are VMs that you don’t wish to size, you can optionally turn them off using the “VM List” tab before exporting to Sizer. In most scenarios, we recommend the users to choose the “Powered ON only” option but you do have an option to select “Both powered ON and powered OFF” VMs in case you plan to run all the discovered VMs on the Nutanix solution.
Warning: When the collected data is that of a VDI workload, we highly recommend our users to carefully look at the CPU utilization values of the powered-off VMs under the “VM List” tab. The VMs may be powered off when Collector gathered the data but these VMs may have been running intermittently and might be consuming resources. If you miss out on exporting these VMs, you might end up under-sizing the solution.
Next, let us look at the “Capacity” option – Consumed vs Provisioned. This option lets the users decide if they would like to size for storage based on the actual consumed storage or the storage that is provisioned for each VM. The selection purely depends on the actual storage utilization value and the future capacity needs.
If the current environment is over-provisioned on storage, we recommend the users go with the “Consumed” option. Don’t worry about running out of storage if you go by the “Consumed” option, Sizer does take care of it and also ensures the recommended solution is capable of handling node failure. Alternatively, you can always go with the “Provisioned” storage values if you are sure that the allocated storage is required or you want to take a more conservative approach.
Now, the most critical part, sizing based on Configuration vs Performance. This option will decide the compute or cores within the solution. Again the selection of this option depends on the CPU utilization values. When we look at the data collected, we see a lot of existing solutions are oversized on the compute or cores. This is usually due to the bad job done during requirement gathering or a very conservative approach taken to avoid CSAT issues.
The cluster summary gives an overall CPU utilization of the cluster and the “Provisioning Status” donut under VMs Summary helps to identify the VMs that are over-provisioned or under-provisioned.
The above two charts should give the users a fair idea and help users to decide on which option to go with when it comes to sizing CPU cores or compute. If the CPU utilization value is very low, we recommend going with “Performance” based sizing. When using the performance-based option, we highly recommend using 95th percentile CPU utilization values to ensure the workload demands are met all the time.
Warning: Selecting performance based on Median or Average may result in under-sizing the solution.
When using 95th percentile-based CPU utilization values, Sizer does add enough cores to the solution to ensure you are not short on CPU cores and the solution can handle node failures.
The last sizing option is Profile vs VMs based workloads. Ever since the launch of “Export to Sizer” we supported “Profile” based workloads. This approach would categorize each collector discovered VM under predefined VM buckets in Sizer – XS, S, M, L, XL.
Beginning 2021, we have started supporting “per VM” based workloads, this results in a much more accurately defined workload feed to Sizer. We highly recommend the “per VM” based option to our users. This option currently has a limitation and supports only up to 300 VMs. If you are trying to export more than 300 VMs you will have to go with “Profile” based workloads.
Now, we are all set to hit the “Done” button to export to Sizer. On successfully exporting to Sizer, you can see the newly created Scenario URL in the banner as shown in Figure 10 below.
Successful export will also generate a CollectorToolsSummaryReport.xlsx with all the details of the VMs data.
Hopefully, this help page provides you more clarity on the options to choose when exporting Collector data to Sizer. By the way, you will also see the same options when you are trying to “Import” workloads in Sizer either via Collector or RVTools data.
If you have any queries feel free to reach out to Collector Support via collector@nutanix.com or alternatively you reach the Collector team via Nutanix Community Page – Sizer Configuration Estimator
For more information please refer to Nutanix Collector User Guide, Security Guide, Release Notes & Nutanix Collector Portal User Guide
For any other queries related to Nutanix Collector, please refer to Collector FAQs