Choosing the right backup appliance – physical or virtual – does not have to be complicated so long as an organization knows the right questions to ask and gathers the appropriate information. However, as organizations are gathering this information, most conclude that a virtual backup appliance is NOT the right answer in most circumstances. In this fifth and final installment of DCIG’s interview with STORServer President Bill Smoldt, he explains how to choose the most appropriate backup appliance for your environment and why a virtual backup appliance is probably not the choice you will be making.
Jerome: What advice do you provide for choosing the software and sizing the appliance?
Bill: I would turn those around. It really has more to do with choosing the right size. STORServer has tried to make it simple to help a customer through the concept of:
- I have this much storage
- I have this long of a retention requirement
- I want to deliver this type of recovery experience to my end users
Those requirements dictate the size of the appliance you need.
STORServer has a tool for doing just what you are suggesting on our website. But, quite a few of our customers come in already knowing that they want either a TSM engine or a CommVault engine. Some of that is based on their experience, a previous job, or the reputation of the products. But, they often have already made a choice.
From our perspective, other than some of the fringe things that we have to do, it is fine for them to use either product. We have selected these products because they are the best and we know we can solve problems with them. There are a few things that are available on one that are not on the other, but we can use both to supplement features across appliance lines.
What is interesting is that though our customer already typically knows which platform they want, we help them through the decision making process. We help them decide on the size of the appliances and which features they will use, such as instant restore or automated disaster recovery. We also make them aware of features like backing up mobile devices.
Jerome: Is STORServer seeing demands for a virtual appliance?
Bill: There was a time early on in virtualization that I thought there was going to be a significant wave in virtual appliances. We actually started shipping a virtual appliance in 2009. That was our V-Series of appliances.
At that time, it made sense for us to ship our virtual appliance on a pre-built ESX server so we were shipping this on our appliance hardware. We are a VMware system builder, so we were allowed to build and then ship them as a single unit.
We did that because when you think about backing up an enterprise and putting this in a virtual environment, if this is the primary and only backup for that enterprise, we are trying to back up on the same environment that we’re backing up. There is always a little bit of a danger with that approach so you have to design for those issues, and we did that.
But in this case, because of the performance demands, we were going to pretty well take up resources of the entire physical ESX server. The ESX server that we were shipping was the same model—the same hardware as our appliance—so, at the time, we consumed just about all the available I/O, CPU cycle and network bandwidth on that system.
It still gave us the advantage of integrating in with the customer’s environment. But when we got into some of the updates and matching their current virtual environment and putting that into a cluster, it did not make quite as much sense to ship it as an ESX server.
Subsequent to the V-Series, we still ship a virtual appliance. We still have customers that will buy a virtual appliance for very specific needs within their environment. However, back to my point from our V-Series, what we learned is that if a customer takes our virtual appliance to back up their entire environment, there are several reasons you virtualize.
- First, you have shared computer, network and storage resource that you are not consuming. If you want to share that among multiple machines, we are going to consume all of the computer and a lot of your data storage and network bandwidth.
- Second, to solve that problem, we have to put that data right back on the same big expensive SAN storage device that we are backing up. You do not want to do that because we are backing that up to account for the possibility of that going down.
In short, most of the advantages of virtualization don’t exist when it comes to putting the backup server in a virtual appliance.
This led us back to using the appliance as most companies are going to add cheaper storage somewhere else anyway. We can do this even more efficiently by adding a physical appliance with our own less expensive storage. Again, we are going to consume all the CPU, network and storage on the ESX server anyway. Using an appliance, you now have less expensive storage that is removed from the expensive SAN storage that all of your virtual environments are sharing.
We map those LUNs directly onto our hardware appliance so all of the data movement goes directly over the SAN into our appliance, not disturbing your ESX server. Your whole virtual environment is offloaded which just makes more sense.
There was another issue that really became problematic in the virtual environment. If the physical machine itself fails, I could put my backup appliance on another machine. But, any time we have a tape library or any other device directly attached using NPIV, we could not move that machine off of one ESX server as well.
Having said of all of that, it still makes perfect sense in some environments such as remote offices where there is a virtual environment, to put a small physical or a virtual appliance on that environment, and then replicate that data back to the main data center. Otherwise, using a virtual appliance as a solution for backing up the entire environment does not make sense.