Support Me, Support Me Not...
Given that vSphere hypervisors are used extensively in many data centres globally, it is not uncommon to see vSphere installed on various server vendor platforms. To provide assurance, support and availability, it is extremely critical that these hardware vendors comply to certain requirements. These requirements are then both verified and validated by both parties (hardware and software vendors).
It becomes more critical when it comes to vSAN, where data is now hosted on vSphere nodes. We certify extensively various servers and components to ensure that under no circumstances that a system will be compromised. As some may know, we have a long list of 15 different server vendors that have built pre-certified nodes, that is also known as vSAN Ready Nodes. We also do extensive certifications on a plethora of components from HDD's to IO Controllers. These certifications and support goes both ways, between both hardware & software providers.
vSAN Ready Node Compatibility
vSAN Hardware Compatibility Lists
vSAN Ready Node List (updated weekly)
Why is support and certifications important both ways?
While it is true, hardware being commodity, there are still aspects of it that is reliant on software. For example, firmware and drivers. Assuming VMware had issues on a particular hardware component, we can either create a custom driver / patch / fix for it easily if required. But assuming it is something that violates the support or broke other feature/functions of a particular hardware component, it may or may not be advisable to do so. Also, it would probably makes perfect sense that both VMware and hardware component vendor worked collaboratively to rectify it. You can't work in isolation.
It is not just hypervisors specifically, but what if the applications had certain compatibility constraints or bugs in relation to the a combination of the hardware and software stack. Would a hardware vendor necessarily have expertise that could rectify application issues?
To side track, we recently had a blog post about SAP HANA on vSAN that is coming soon. SAP HANA deployments have historically been strict with the choice of platform that it is runs on. What took so long for vSAN to certify on HANA? Probably in part because SAP only released SAP HANA Certification Guidelines for HCI earlier this year. Read about SAP HANA on vSAN here.
Tying it back to our discussion on support and certification, some vendors have committed to customers, that they were supporting SAP HANA on HCI, as far back as 2 years ago (though SAP only came out with guidelines recently). One can only assume it is a 1-way support model then. Would you then consider running mission critical workloads on it?
Many competitors, taut 1-way certification as a non-issue, because they can always work on the basis of TSANET.org. Just in case you weren't aware of TSANET, they are a not-for-profit organisation that provides legal framework and contact database to foster multi-vendor problem-solving. Sounds workable to some sense (I stand corrected on this, but it doesn't seem like they are a governing body of sorts) but no mention on the level of commitment or SLA's.
Unless its a niche solution that only 1 vendor can deliver (which leaves you little choice), I don't see why would anyone take that a risk and not consider other available solutions that are "approved and certified".
Peeling back the onion, the motion of pushing TSANET as replacement for official certification and support looks a lot like an easy way to make a quick sale... the only loser here is the end-user.
