By Joe Keegan – Technical Consultant
If you are in IT long enough you will probably be involved in a project that requires deploying new infrastructure. This could be for a new service offering or to replace aging equipment. In either case, it’s an exciting time to learn about and understand the new offerings available for your project, but it can also be stressful making sure you purchase the right equipment to complete your project successfully.
I’ve been involved in many of these projects, as part of an internal IT staff, as a consultant and as a solution architect with a VAR, and the number one issue I have seen is a lack of understanding of requirements.
Importance of Requirements
Without a good handle on the requirements I’ve seen projects purchase way more equipment than they needed or even worse not purchasing enough. As IT professionals we need to do our best to ensure our designs fit into the “goldilocks zone”; not too much where you are wasting money, but not too little that you can’t meet the SLAs of the services we are delivering.
Even organizations that have a formal process to determine application requirements often handle the infrastructure requirements in an informal manner leading to capacity, performance or availability issues.
Metric Based Requirements
While many different types of requirements exist, metric-based requirements are some of the most critical when determining what equipment is needed for your project.
Metrics based requirements define “how much” of something that the infrastructure with the need to support. As the name implies, metric-based requirements must include a number so they can be measured and scaled. Metric based requirements are used for the sizing of the infrastructure components and are therefore critical to understand before determining what must be purchased for your project. Metric based requirements can be further broken down into high-level metrics and detailed metrics.
High-level metrics are often defined by the business users or stakeholders of a system and are in terms that they or any other consumer of the system would understand. There are items like:
- What type (e.g. Light, Regular, Power User) and how many users must be supported in the case of business application
- The type and number VMs that must be supported in the case of virtualization environment
- Number of page views per seconds in the case of a web application
- Support a specific data copy rate (e.g. 2TB/Hour) in the case of a backup system
High-level metrics are important to understand, but unfortunately, they can not be used by themselves to size a system for this they need to be converted into detailed metrics.
Detailed metrics are requirements that can be used to actually size the infrastructure and include items such as CPU load to be supported in Ghz, the amount of RAM needed, number of IOPS supported. Detailed metrics are usually derived from high-level metrics using a model.
For example if you were building an environment supporting 100 VMs (High-level metric based requirement) and you knew that each VM would use on average 4GBs of RAM, 40GBs of Disk and generate 25 IOPS, then you can determine the total detailed metric based requirements for the infrastructure as needing to support 400 GBs of RAM, 4000 GBs of Disk and 2500 IOPS.
Taking a model approach to determining the detailed metrics allows you to quickly scale the requirements based on changes in the high-level metrics. So say for example you need to cut the number of VMs that you will be hosting in half, or double the number, you can quickly do so with the model.
If you have a good understanding of the need or at least a general consensus of the design target (e.g. support 100 VMs) then you are able to use the model to determine the correct hardware to support that need.
Developing a Model
Developing a useful model is the hardest part of sizing the equipment needed for your project. If you are replacing an existing infrastructure then you are often able to collect the metrics from the current environment and derive a model from there, but for net new environments that task can be difficult. The resources you will have at your disposal will depend on the size of your company, the size of your project and the level of engagement with vendor/manufacturer/VAR.
Your first step should be to review any sizing or architecture guides that are available for the product. These may or may not be helpful, but they should at least give you an idea of the useful metrics needed to size the environment.
Your next big resource is your vendor, be it directly from the manufacturer or a VAR. The vendor will often have access to a sizing tool or a sizing group that will have developed their own sizing models. The vendor can take your high-level metrics and use their model to propose a configuration that will meet those needs. The trick here is that most vendors will not share their model with you, so it’s important to have them explain how they reached the proposed configuration.
The last resource is using load or stress testing to build the model. While this can be expensive and time consuming this is the best way to develop or validate a model. Organizations can often leverage QA or staging environments for their load testing.
It’s important to note that unless you know the application and your workload very well you will not be able to develop a 100% accurate model. Even when using the vendor’s resources I have rarely seen the final configuration be an exact fit. The accuracy of the model should be taken into account when using it to size environments and additional capacity should be built into the initial deployment to offset the risk of inaccuracy.