If you would like to read the other parts in this article series please go to:
- Building Virtual Environments Using HP’s Sizing Tool (Part 2)
- Building Virtual Environments Using HP’s Sizing Tool (Part 3)
Introduction
Sizing a virtual environment sometimes seems like a combination of art and science. However, with enough data, sizing calculations can move quickly to the science side of the equation and be much more accurate, especially if you can get application performance details. That’s where HP’s Unified Sizer tool comes in. Once downloaded, you can install this product onto your Windows machine. When done, you will find a series of sizing utilities installed, much like the ones shown in Figure 1 below.
Figure 1: A number of HP sizing tool apps are installed
However, in my own use of the sizing tool, I have some concerns. While I generally trust companies such as HP to release tools that are useful and provide good information, I also have a great deal of respect for the phrase “trust but verify.” In this context, that phrase is critically important as HP’s sizing tool seems to overestimate hardware needs. From HP’s perspective, I would imagine that the company wants to make absolutely certain that the output from the tool is more than adequate to meet the input requirements. Further, bear in mind that the sizer is recommending only HP gear. It may be useful to use the results of the sizer to shop around a bit. You’ll see what I mean later in this article when you see the second example that I threw at the sizer.
For this article, I configured the sizer with two different sets of inputs. The first set simulated a very large enterprise, with hundreds and hundreds of physical servers, major performance and storage needs and the capacity to push the environment to the limit. In the second example, I used a very modest set of requirements that might even be found in many SMB and small midmarkets to see how the sizer would react. Read on for the results of my tests.
Test 1: An enterprise behemoth
As mentioned, my first test with the sizer revolved around throwing a very large environment at the tool to see what it would return for results. I’ll walk you through the entire process.
The process begins, naturally, by starting up the sizing tool and indicating which Hypervisor platform you intend to use. My tests were done on the assumption that vSphere 5.1 is this fictional organization’s hypervisor of choice. Once you make a hypervisor selection, click the Build Solution button to move on to the next step of the process.
Figure 2: Select your hypervisor of choice
The first screen of interest in the Sizer tool asks you to provide detailed workload specifications for the Sizer to use in its calculations. There are a number of ways that you can get information into the Sizer.
- Use Sample Data. Perhaps you want to take the Sizer for a test drive? Using the Sample Data option, you can do just that. For my purposes in this article, that’s what I’ve done.
- Load from User Data. If you’ve created your own metrics information or saved information from a previous session, you can load the here.
- Load from Microsoft’s MAP “PerfMetricReport” Spreadsheet. The Microsoft Assessment and Planning Toolkit (MAP) is an automated planning and assessment tool. MAP helps to enable quick and easy desktop, server and cloud migrations by providing detailed readiness assessment reports and executive proposals with extensive hardware and software information. MAP also provides server utilization data for server virtualization planning; identifying server placements, and performing virtualization candidate assessments, including ROI analysis for server consolidation. Click here to learn more about MAP.
- Load data directly from a local MAP database. If you’ve saved MAP results to a database, the Sizer can read the results from there instead.
Figure 3: Choose a performance data collection method
For my purposes in this example, I loaded up the sample data a bunch of times and then modified a lot of it to reflect vast quantities of servers. Ok, maybe not vast, but certainly well into the hundreds and low thousands. In Figure 4, you can see some of the selections that I’ve made.
Figure 4: Sample data is loaded and ready to be processed
If you want to save your data set for later – perhaps you’ve like to run multiple scenarios – click the Save Workload button and save your file, as shown in Figure 5. When you’re done, click the Next button to move on to the next step.
Figure 5: Save your workload definitions for future use
Based on the information that was provided with regard to workload sizing, the Sizer now begins estimating what’s needed to run the provided workloads. As you can see in Figure 6, the Sizer estimates that this workload requires around 216,000 IOPS – a pretty big number – and around 12 GB per second of throughput. Again, a big number, but this example was on purpose. With one exception, I’ve asked the Sizer to leave everything at defaults. However, I did indicate that I want to configure my new environment to be able to boot from SAN. I don’t want to install vSphere locally.
Note that you can also choose to define the number of LUNs for a VMFS datastore and indicate how much space should be reserved for VMFS. Click Next once you’re done making you’re selections.
Figure 6: Sizer is beginning to make some calculation and is asking for fine-tuning parameters
On the next screen, the Sizer asks you to define resource upper limits. All limits default to 80%. The Sizer will use these limits while it builds out an environment. These are used in conjunction with the workload details gathered earlier and calculated into the server and storage options recommended. These parameters are adjustable from anywhere between 50% and 100%.
Figure 7: How much overhead do you want to build into the environment?
Once that’s done, it’s time to move on to more substantial decisions. It should be noted that you could just click the Finish button and allow the Sizer to simply use default values for all of the entries.
However, many organizations have standardized on, for example, blade servers and may want to request that the Sizer make recommendations based on that form factor. With the Sizer, you have a number of options at your disposal, as shown in Figure 8.
Figure 8: Choose role server options that match your needs
Role server options
The server options that you have at your disposal are listed below.
- Server platform. Here you can choose form tower, rack, or blade form factors.
- Processor vendor. The two big guys – Intel and AMD – are your options.
- Server. This option allows you to force the Sizer tool to use a specific HP server model, such as a ProLiant BL420c Gen 8 server. If you don’t select anything here, the Sizer chooses server models for you.
- Internal storage type. Do you want the Sizer to use small form factor SAS disks?
- Core. Quad, Hexa, Octa. Do you want the Sizer to spec 4, 6, or 8 core servers?
- Processor speed. Choose your processor speed, from 1.8 GHz to 2.4 GHz.
- Processor count. How many processors per server do you want to specify? 1 or 2?
For blade systems, you have two additional options from which to choose.
- BladeSystem enclosure. If you choose a blade system, you can tell the Sizer that you want either a c3000 or c7000 blade enclosure.
- Virtual connect type. Every server, regardless of whether it’s a blade, rack, or tower needs network connectivity. Here, you can instruct the Sizer tool to include gigabit Ethernet passthrough, a 1 GbE switch, or 10 GbE connectivity.
Summary for part 1
In part 2, we’ll continue our walkthrough of the HP Sizer utility.
If you would like to read the other parts in this article series please go to:
