Other than some cool technology, VCE brings many more benefits to the table. Today, I'm going to dive into the certification matrix. Before we actually talk about the matrix, lets look at what comes before then. Since VCE is comprised of parent company products (VMware, Cisco, EMC, and Intel), we have alpha access to not only new software level releases, but as well as new hardware. VCE's Platform Engineering team is tasked with taking existing hardware as well has new hardware, and coming up with a physical and logical architecture design that meets requirements based upon performance, environmentals, and ease of repeatability. After Platform Engineering has created a validated design, they need to keep the architecture up to date with new hardware released from parent companies which may or may not require the swapping of components for new Vblocks. Have you ever calculated how much time it takes someone like yourself to completely design a virutalized infrastructure such as this? There are literally thousands of options from the main hardware components, types of cables and interconnects, power options, and placement of equipment into racks which dictates power draw, BTUs, and cable lengths. On average, it's close to 300 pieces that are aggregated together.
Now Quality Assurance steps in. QA is responsible for the integration and testing of the design. This integration testing is performed so we know that all components are able to communicate with one another and the Vblock talks as a complete system. This is the first part of the validation process. After all components are validated, their firmware and software versions are noted and then the regression testing begins. This base regression test is for existing component verification. Afterwards, new functionality tests are then performed so new features are fully tested and considered working throughout the stack. Lastly, interoperability tests happen by additional e-lab teams. An example of some tests are: installation and configuration, recovery, stability, load/performance, patch and maintenance testing, interface testing inbound and outbound, negative test strategies, provisioning with and without cloud products like UIM, usability, and physical testing of fault tolerant systems, visual indicators, and thermals. In fact, check out these numbers from January 2012. Over 2000 hours of testing are put into Vblock Platforms during every major release cycle.
Lets talk about the release cycle. VCE will never support new hardware or software levels on the certification matrix on day 0. In fact, it's probably closer to 60 days. There's good reason behind that too. Testing and verification among 300 aggregated components is a massive undertaking. Having the flexibility to upgrade whatever and whenever without standards is a massive contribution to failure. Major releases are set in 6 month intervals with code freezes set. All software, firmware and hardware has been fully tested for operational, performance and interoperability stability and optimization. Minor releases are also maintained mutliple times per year. This type of release may be be deprecated or revoked during the Maintenance period. This type of release is a potential candidate for Integration into the next “Production” Integration Point. VCE is constantly testing new software and firmware levels and has periodically skipped releases of firmware because of bugs found during QA. After Platform has certified a list of releases it gets passed on to our Support Organization so they can get trained on new featured releases which are then passed along to customers with accompanying upgrade guides for major releases.
How do you perform your integration testing today? Do you have a completely identical infrastructure that you use to test new software releases? Do you do the typical "wait for a quarter and let other people find the bugs" approach? Even if you do that, how do you know their infrastructure looks like yours? You can't really be certain that your environment isn't at risk just because a bug was addressed. Have you defined an upgrade cycle for the components in your infrastructure? Are you reading through all the release notes for every update on every component to make sure there aren't any inconsistencies with anything in your environment? Have you ever though about how much risk you have been exposing to your environment? Believe me, I've heard enough people talk about how a specific driver caused havoc with fiber channel or ethernet connectivity. Or how an upgrade process failed and they had to rollback because they weren't at the correct level before upgrading. In fact, here is a real world situation. There was a question I had directed other day about when VCE was going to support vSphere 5.0 Update 1. Come to find out, During QA testing of vSphere5 U1 they uncovered a PSOD issue with the FNIC driver. There are definitely customers that got burned by this, but wouldn't have been exposed if they were running a Vblock with the backing of a certification matrix.
VCE is now assuming all of this risk. VCE has all the equipment to put together your exact Vblock, do the integration testing with all the same infrastructure you have sitting in your datacenter, and validate everything. This reduces the amount of time people in operations facilities spend testing and integrating, reduces the risk of downtime associated with communication issues or failed upgrades, and increases a customers ability to adopt new features without the risk of breaking interoperability.
So lets take a look at VCE's Certification Matrix 2.5 for Vblock 300. This was a major release from back in January 2012. The current matrix as of May 15th 2012 is 2.5.5 so this outdated on purpose. But this gives you a look at what VCE is doing for our customers every single day.
Guide Certification Matrix 300 2.5
You should be able to take away from this article quite a few things. You should be able to quantify the amount of time and resources spent reading release notes and documentation for all the components in your infrastructure. The time being spent doing analysis of firmware codes on spare hardware to perform testing. The amount of time spent documenting your upgrade process and procedures for your particular environment. The amount of money invested into additional infrastructure. You should also be able to identify if you have an upgrade cycle or patch release process and how that compares to what VCE is doing for their customers. This is just one of the many little benefits that VCE brings so you know your investment in a converged infrastructure platform is a sound investment.