Use small-scale tests for a cheaper alternative to expensive, duplicate test environments, but be wary of limitations, such as hardware functionality and performance.
Debuting new products can cause stress, but in the age of software-defined technology, IT administrators can use infrastructure testing, even on a small, inexpensive scale, to prepare for launches.
More infrastructure is becoming software-defined, and products such as VMware Workstation enable the nesting of ESXi and other infrastructure software. Administrators are better able to perform infrastructure testing before installing upgrades in production environments. This gives IT personnel hands-on experience with the software and installation process, which reduces the threat of outages and other negative effects.
This is a huge step forward for administrators who previously had to do upgrades on production systems and plan for all of the contingencies that could occur. IT should be entering the golden age of quick, non-disruptive upgrades with free nights and weekends for IT administrators. Limitations still abound, of course, so administrators must navigate cost concerns and communicate clearly what the chosen testing plan can and can't account for.
Infrastructure testing varies between lab and production environments
A lab environment is never the same as the production environment, no matter what administrators test. Even if similar gear is available, it's never completely identical.
Often, management commits to creating an environment that's identical to production to follow best practices for the IT Infrastructure Library and other frameworks, but cost concerns eventually catch up. Once management receives requests for new Fibre Channel directors or other enterprise-class storage area network frames, the conversation about infrastructure testing can shift from identical to good enough.
Cost is usually the primary limitation to the extent of infrastructure testing. Administrators must explore whether the benefits outweigh the costs for creating a duplicate infrastructure. Without duplicating everything in production -- including workloads -- it's impossible to know exactly how infrastructure will behave.
It might be necessary to strategically cut some corners when determining what to test and how. Ultimately, the purpose of testing is to verify the steps in the installation process and learn what might happen, so admins should explore alternatives.
Alternative actions on a smaller testing scale can be more cost-effective. Cost can push testing platforms more toward limited scale infrastructure testing, but administrators must understand the limits of this testing and know how best to work within them.
Consider cloning an existing vCenter appliance
The ability to test a vCenter upgrade may be an ideal small-scale approach to verify the functionality of key plug-ins and other third-party software. This can also help verify if the database will accept the update.
This type of update will affect all of your hosts, especially those with custom builds of ESXi because those might contain specific hardware drivers for their platforms. As a consequence, this infrastructure testing method will work, but it's limited.
Without the complete, costly resources to make a full duplicate, however, IT will inevitably hit limitations.
The same goes for deploying new products or features, such as NSX and vSAN. Small-scale infrastructure testing works for the initial setup and installation of software, but not always in hardware functionality or performance. This makes sense because of its scale, but it can surprise those unfamiliar with the limitations if the software doesn't perform as expected.
Management might express frustration, confused as to why IT didn't test everything. Without the complete, costly resources to make a full duplicate, however, IT will inevitably hit limitations. This situation can be frustrating, so communication about the extent and limits of testing is necessary.
Smaller scale infrastructure testing gives admins an initial experience that lets them see the new product or update and get a feeling for initial conflicts or issues that might arise. This testing will likely miss the possible hardware interaction and performance aspects. These are key considerations when it comes to an upgrade, and they require accountability. This doesn't mean they require testing, but infrastructure testing results must be clear about limitations that preclude those aspects. This transparency can help remove confusion and prevent unrealistic expectations about what small-scale testing can do.
