We use it for backup and for restore, primarily. It's really just for VMs. You can use it for other things, but we don't have other things to work with.
We use it for backup and for restore, primarily. It's really just for VMs. You can use it for other things, but we don't have other things to work with.
Earlier this week, we had a server that was having some issues. One of the database guys came in and said, "Do we have a Snapshot, do we have a backup?" I had looked at all my reports and I said, "Yeah, it looks like the backups worked fine this morning. We've got one as of 1 AM last night or earlier than that." I had saved a bunch of them.
If we didn't have SnapCenter for backups, that situation would have played out a whole lot slower. Without the ability to interact with VMware and have VMware perform the restore using the Snapshot taken by SnapCenter, we would have had to make a clone of the Snapshot and, a lot of times, if you're dealing with RDM drives, you've got to re-present clones of drives. It would all be done within vCenter and we would have to link back to either a vCenter-owned Snapshot or to link back to local Snapshots which might have been taken on the NetApp. The primary storage going to vCenter was through NFS on the NetApp. It would have become a number of more steps and have taken significantly longer to perform a restore than what I've found with using SnapCenter.
Since we have never really done regular backups with vCenter, it would have meant reverting an entire host. It's not convenient to try to do an entire host and then figure out what's changed on all the other VMs on that host. That's basically what it would require. You present the storage for the host to vCenter and it's taken in one shot. You can't just take a little piece of it and restore that, you restore the entire Snapshot. It may only take minutes to restore everything that way, but you're restoring all VMs to the exact same state as the VM you wanted to rescue.
The way that it interconnects with VMware is really handy, because you can go right into your vSphere Client, where you spend a lot of the day anyway, right-click on one of the VMs where you have backups running for however long, and you can restore either some files or restore the entire thing. You pick the Snapshot. I've timed it and it's under two minutes for it to completely rebuild the VM and restore it completely. I really like that feature. It's fast. If people have a problem I can get them back up online in less than five minutes.
I also use the monitoring feature every day. It can send an email every day and tell you, "These worked, these failed," for whatever reason. Typically you have to do some other kind of backup or run it again. That feature is really nice. You can automate it so it tells you afterward what worked, via email.
Finally, it's pretty simple to operate. The interface isn't complicated.
There is one area that needs improvement and that's in the alerting. When you set up your SMTP alerts, it only has - and I don't understand why - the ability to send an anonymous SMTP. It doesn't do basic authentication, which frustrated me for a while until I figured out that I'm not missing something. It's just not there. That's been a drawback and we're trying to figure out some kind of workaround. Obviously, you don't want to have an SMTP server using "anonymous." You want it to be locked down to some kind of authentication domain level. I would like to see that changed.
The SMTP thing is a concern for me. At the moment, we're just using it anyway, until we can figure out something else. In the worst-case scenario, I can set up my own PowerShell script to send an email and use "secure" that way, based on the reports that it's generating. But I can still log in to the website because it's got a web portal. I can go into my web portal and see, "Okay, the backups finished last night." That's not as simple as getting an email, but at the same time I can just open up a website and see the results anyway.
I've had no problems with its stability. I haven't had to restart the server for any reason. Any failed backup that I've seen so far has not been related to SnapCenter. From what I've seen in the last year, it is pretty near bulletproof, as far as being able to run, once you set it up.
I don't think scalability is bad at all. Like I mentioned with the vCenter thing, as long as you understand that if you've got different sites or different vCenter stacks, you're going to have to have a SnapCenter for each one of those. But in terms of scalability, if you actually have a network that is significantly bigger or suddenly grows really big, it would be as simple as going into your hardware, whether it's physical or a VM, and just increasing your resources a little bit. By default, they said you should use 8 gig of RAM and two processors. It doesn't take much up many resources, so scalability doesn't seem like an issue at all, particularly if you end up having SnapCenter for each site.
I talked to technical support when we had the SMTP issue, to try and figure out a way to use domain-level authentication to send an SMTP message rather than just anonymously. And there was the time when I placed a ticket for the vCenter plug-ins, when I was trying to figure out why it wasn't working quite the way I expected between two different sites.
NetApp has always had fantastic response. I get someone on the phone, we do a little preliminary work, and if we need something later, it's usually a matter of single-digit hours to get the higher-level support online. They can do WebEx and get right in there with you and take a look at it. They've got people who are cleared to work on classified networks and that type of environment as well. They've probably been the easiest company, of any of our vendors, that I've had to deal with.
To understand the broader picture of where we were coming from, we had an existing network that was hodge-podge and built over the years; a combination of three different kinds of SAN storage from EMC to EqualLogic and we had a tape backup solution from Dell. They were all running a little bit here, a little bit there. They were using Commvault for some of the stuff and there was major overhead. It was a lot more than one person was going to be able to handle in my position. What we did was build a parallel network that was going to replace the whole thing, based completely on NetApp and using SnapCenter and VMs. It's far more streamlined.
I came across SnapCenter because I had worked previously with contracts with the Navy and Marine Corps and they had been exclusively using NetApp filers for the last nine to ten years that I'd been working on it. They had used a couple of different solutions before that, but then I heard that SnapCenter was coming, as I came out of this contract. We had a NetApp resident on our previous contract and he kept me updated: "Hey, this is coming out," or "We have this new tool." So I heard about it from him. I said, "Let's look into this and see what it's going to take." I read about it on the internet, I looked at some of the documents from NetApp; how to install it, how it works, how it interacts with VMware or Oracle or other databases.
The initial setup was pretty simple. I created a single VM, which didn't have to have huge resources. I grabbed the all-inclusive image that you can apply in your vSphere client to just create a VM with the right operating system, completely configured and ready. I used that and that was really simple.
I just downloaded the file I needed from NetApp, created the VM using that template, and then I logged in to it through a VMware consul and configured an IP address and whatever else I needed to set up on there. It really didn't take very long, once the image had done the work through VMware. The setup took less than half an hour, and it was functional. It was able to talk to the filers, take Snapshots, and interact with vCenter. Part of the implementation is that it configures vCenter with its own little plug-in. It's really pretty slick and it actually installs it on the vCenter. That's what gives you the option to right-click on one of the VMs and see SnapCenter as one of the options. You go in there and choose the type of backup. That's all installed as part of the configuration.
I can't say how long it's going to take vCenter to get its part done, but from the command-line perspective, it was less than half an hour to configure everything else, after the VM was created.
Regarding an implementation strategy, I looked through the NetApp document on SnapCenter 4.0, and read through it briefly. Then I said, "Okay, we need to do this step, this step, this step..." I got a basic image of it in my head and then went forward with it. It wasn't complicated. There weren't a whole lot of extras and hoops you have to jump through. It was pretty simple.
Let me add another observation - and they may already have something in mind to change this. In our environment we have two different sites. We have a vCenter on both sites, but they're not linked; they're completely independent. One thing I noticed is that the vCenter that I set up on "site one" was able to do backups for both of them, but it had trouble seeing the backups on the second site. They had mentioned this on the documentation: If you're not using linked vCenter sites, then it can have problems communicating with the second site. Apparently, if they're linked, it handles backups for both sites, restores for both sites, monitoring, etc. In our environment, it was simple enough for me to repeat the process in our second site, have a second SnapCenter server, just to do that site. That made everything simpler, rather than trying to figure out if backups weren't working.
Going into initial setup, you have to understand that because you don't want to have it try to take care of two completely unrelated vCenters. It doesn't work well for that. Maybe they have some kind of update plan to change that, but for right now, I couldn't get it to work. I went through a couple different cases with NetApp to try and resolve that. Finally, we just said that it's not really designed for one SnapCenter server to be able to run a vCenter plug-in on both sites. That's what it would really amount to: You would have to install a second vCenter plug-in, and its own rules say it can only have one. When you're trying to use just one to do two different sites, you get weird issues in connectivity and the like.
I did it myself.
The timeliness of the backups and the restore turnarounds are the areas of ROI. A lot of times, it's fairly important servers and, if they go down, you don't have half an hour to fiddle around with stuff while you're losing thousands and thousands of bits of data that are supposed to be coming in. The biggest return that I've seen is that once we find a problem, it's done in 60 seconds to a minute-and-a-half, usually.
There's no licensing involved. That was a question I had when I first set everything up. I didn't have any problems with it at all, but everything I had ever used had licenses. I noticed there was a place that said "License" but when I went in there it said "Standard File License." I thought, "Well what do I need to do, what kind of license do I need?" I came to find out they had upgraded some things and they said, "Actually, there is no more license required. Whatever you've got in there, that standard version, is good for everything. You don't have to buy anything. You never have to upgrade it." It's been simple. I've done one upgrade on the OS, one minor patch that came out. It took no time really. It was simple, automated.
There was no license required because they had a contract with NetApp already.
Because it can interact with more than just NetApp, I'm sure you can use it as a stand-alone. But unless they change the way licensing works, I would suspect that you just purchase a license for that one device and there isn't like an ongoing, "you need more licenses." You have the base license and it's yours. I haven't pursued that so I can't tell you for sure.
They had already chosen NetApp as their storage for their filers. We could have looked at a number of different things and at the time that I came onto the contract, they really didn't have anything yet. But I knew from the experience that I had, that I really didn't want to bring Commvault into that solution. There were one or two other more flakey-type solutions that I'd seen in the past and I knew I didn't want to deal with that. I thought that looking at something that was made and supported by the same people who created our filers would make the support a lot simpler for me if I needed to reach out. I knew who I could get and when I could get them. I knew what to expect. That was really why we chose it. The others weren't really much of an option. It wasn't a matter of cost because, if I remember correctly, there really wasn't any cost to having SnapCenter. There's no license involved.
Make sure that you've got some kind of a server in mind for it. If you're not going to be using just an IP address, if you want to use a domain, make sure that you've got access to your domain controllers so that you can create a DNS record. Just download the installation guide form NetApp. A high-schooler could probably pull it off.
As for the number of users in our organization, I'm really the only one. I do all the SAN storage and I overflow into the VMware and the enterprise networking. I'm the only one that interacts with it, although we've got three different people who could if they actually wanted or needed to. It would be easy enough to set up a user for them. We've got one VMware lead, and he primarily takes care of that. I just back him up when he's not here. We've got a primary network lead, and he does our routing and switching and firewall work. Either one of them could step in, had they the need to do so, but right now, I'm really the only guy with a SAN or NAS-type storage background or certifications. They usually just leave it alone. They get a copy of the backup reports if something fails, so at least they are aware of it, even if they don't have to go do anything.
It has been very low maintenance so far. I'm the only one who maintains it. Running whatever upgrades that come out for the OS is really all I have to do. Even if something broke, it doesn't take that much time out of one person's schedule to find out what's wrong. I honestly haven't found anything wrong, other than those couple of points that I mentioned and that wasn't actually broken, it just doesn't function like that.
There is a possibility that we could add backups for Oracle, if for some reason their native backups don't pan out but, other than that, we just see minor growth in the virtualized area. If we have to add more servers, that's really the only kind of growth we're anticipating.
I'm giving it an eight out of ten because, while I really like the way it works and how bulletproof it has been, I believe they could improve it by adding some kind of authentication to their SMTP. Also, they probably could improve by having a single, central spot that can handle multiple vCenter sites. Those two concerns aside, I'm completely happy with it.