It’s easy to get confused on ‘supported’. That is, when EMC (or any other vendor) publishes a guide on say, what operating systems are supported, many will ask whether that means if some operating system X that does not appear in the list will work.
The terms ‘work’ and ‘supported’ are not synonymous, and should not be confused.
I’ll be the first to point out that I routinely use CentOS in my lab – a Linux distribution that is most definitely not on the supported operating systems list. It’s a repackaged RedHat Enterprise Server, and I can install it as many times as I want at zero cost. On the other hand, if I needed to actually buy a RedHat Enterprise Server license for every Linux test VM, I’d be very, very poor.
So clearly, CentOS works with NetWorker, even though it’s not supported.
Would I recommend it being used at a customer site in a full production environment? Not without rigorous caveats.
You see, backup is one of those fundamentally low-level scenarios where taking risks is just plain wrong. It’s like the difference between leading edge and bleeding edge. There’s nothing wrong with being leading edge in the backup environment; many companies depend on being leading edge so they can meet their backup and recovery windows. Bleeding edge though – going out and using untested or uncertified configurations, just asks for trouble. Indeed, the term says it all – bleeding.
There are typically two key reasons why something may ‘work’ but be ‘unsupported’. These are:
- The vendor has not had a chance to test that particular configuration. I.e., it’s unqualified. For example, a Widgets Inc. Tape Library with LTO-5 drives and four robot heads may just not have made it to the vendor labs for qualification; so, while it may technically work, it’s never been tested.
- The vendor is not comfortable with the supplier support for the product.
Now, in the case of a solution or a configuration option being unqualified, there’s a solution. EMC for instance will work with customers and partners to determine whether a particular configuration can be qualified – indeed, most vendors have a similar process. While everyone would undoubtedly prefer that they get all the qualification done in their labs, we must also accept that it’s practically impossible to achieve, so some level of on-site qualification must be accepted as required from time to time.
In the second instance though, things are a little more difficult. If a vendor isn’t comfortable that the supplier of a product will be able to suitably support that product at an enterprise level, then getting it qualified is unlikely at best.
In these instances, if you want to deploy unsupported components in your system, ask yourself these questions:
- Is there a supported option available?
- What are the pros and cons of the supported option vs the unsupported option?
- What is the risk to the business if the unsupported option has issues and the vendor refuses to support it?
- If the unsupported option is chosen, can a test lab be setup using the supported option so as to prove, at any point, that the use of the unsupported product does not contribute to an issue?
The last point may seem a little odd – after all, if you can afford the supported option for a lab, why wouldn’t you deploy in production? I’ve actually seen this scenario with CentOS – a company couldn’t afford RedHat Enterprise Server licenses for all their production machines, so they deployed CentOS, but they also did buy a RedHat Enterprise Server license for a lab machine. Whenever an issue occurred that required escalation to the vendor, they’d first reproduce it on the RedHat Enterprise Server. That way, when it went to the vendor, they could (rightly) claim an issue on a supported operating system.
Even so, this isn’t necessarily ideal. What was obviously not accounted for here was the potential for a high severity issue occurring. E.g., if a severity-1 fault occurred on a system, where data recovery was imperative, but recreating the configuration would take a long period of time, the risk remained that either (a) an escalation based on an unsupported operating system would be rejected or (b) the SLAs might be blown out of the water recreating the issue on a supported platform in order to get a successful escalation.
In short – the decision to use unsupported software/hardware is not the decision of IT staff. It must be the decision of senior management. It must be signed off, and stakeholders of affected systems and processes must be aware of the potential consequences.
While unsupported does not necessarily imply doesn’t work, it’s important to remember that unsupported can most definitely mean unsupported when it stops working.
But what do you do when the vendor is totally recalcitrant — for example, Networker is not qualified for AIT tapes above AIT-3 on Qualstar libraries. This is totally preposterous. Further, EMC could do a little bit of due diligence to verify that CentOS is, indeed, identical to RHEL except for the artwork. They really need to do their part, too.
Matt – I’d certainly agree that in some situations, vendors are just being pigheaded in their approach.
I’ve been told by various people that there’s typically two reasons why a vendor’s solution doesn’t make it onto the qualification list – either there’s a genuine hardware/compatibility reason why not to, or for various reasons they were not able to get a hold of an evaluation unit. Less likely is a strategic decision not to support a particular piece of hardware – e.g., look at the NDMP support list and you can see qualification there for a lot of competing equipment, including HDS gear.
In the case of the library, my first stop would be to request qualification – that’s where if you’re using said equipment, you request that EMC review the environment/etc with a view towards qualifying/supporting the equipment. This does get done from time to time – usually it’s a combination of talking to local EMC reps as well as support staff to get the ball rolling.
On the CentOS front, I personally agree – there are few to no reasons to support CentOS given that it’s effectively a recompile-with-new-artwork implementation of RHEL. I can probably see more of a valid reason on EMC’s part for not supporting, in that RedHat doesn’t support CentOS, and the CentOS foundation isn’t a corporate entity they can interact with. However, despite all that … the difference between the two systems is little more than s/RedHat/CentOS/i. I think there’s a growing consensus in the NetWorker (Linux) community that both CentOS and Ubuntu (or some other Debian-based package system) needs to be given support. Hopefully that will eventually get some traction.