Backing up SQL and Exchange is our primary use case.
Backing up SQL and Exchange is our primary use case.
We are putting a new SharePoint infrastructure into production - we're upgrading SharePoint - and our users need a test environment for that and they need it refreshed every day. These are big databases. My colleague is able to create a clone of the production database on a daily basis, through scripts, or through SnapCenter's command line interface which comes in handy. He puts in a new database every day for our users.
I'm not sure this would be possible otherwise. I don't know how many databases SharePoint consists of but there are a lot and they're big. If you need a clone of your databases every day, I don't know if it would be possible to do so overnight, using a traditional backup and restore. I don't know if it would be ready the next morning for users to use. But with SnapCenter, now, it is ready.
The difference is that it's more manageable. Backup timeframes are shorter, restore timeframes are shorter, and we have one portal through which we can control everything.
A feature that stands out is cloning databases. If you have a SQL database and it's huge, like one terabyte, the classical SQL way would be to do a backup-restore to create a clone of your database for test purposes. With SnapCenter now, we can clone a database but through the Snapshot technology. That means if you right-click and you click Clone, the one terabyte database is there instantly. It's instantly presentable to our users and in test mode. Clones or duplicates of the original can be used for testing or acceptance.
Also, the backup process finishes very quickly. In the old way of running a SQL backup, you would wait for SQL to read the whole database - and here I'm talking about a full backup. It would have to read through one terabyte of data. That's not necessary anymore. Now you snap the storage in which the SQL database exists, and the backup consists of pointers on disk, as far I understand.
I feel a little bit that during the whole process of putting this software into production we were like a beta program. It was full of bugs. I have made something like 20 calls to NetApp regarding this product. I've used a lot of products in my life and this one has needed the most interaction with the company that made it, to get it working properly in production. There were a lot of bugs and things that didn't work.
For example, we had a problem with truncating our Exchange log files. Exchange creates log files of the mailbox databases. After a full backup of Exchange, those log files were being cleared. It was not working. So we created a backup with SnapCenter of our Exchange environment but the logs were not truncating. Finally, we got in contact with someone from NetApp in Holland and he directed us to a university somewhere here in Holland and they explained to us what they did to fix it.
It has improved over time.
And the GUI is still so-so. I' don't use the GUI that often anymore because it's really slow, refreshing disks, refreshing hosts, and you have to click a lot.
In addition, we had a major production problem due to SnapCenter, because we also use SnapCenter to back up our whole VMware environment. When we did an upgrade of the SnapCenter Server and its plugins - because SnapCenter puts plugins on the host and, in this instance, it puts a plugin on our VMware server - SnapCenter was then supposed to snap our virtual machines and then the whole volume on which the virtual machines reside, and then delete the snaps. This last step, deleting of the snapshots, did not happen. It wasn't deleting snapshots anymore. Our fault was that we didn't record this. We didn't have any measurement of the number of snapshots which were on our VMware infrastructure. After two weeks there were 14 snapshots of each VM in our whole park, and this created a huge performance issue. After we discovered this, we had to delete them and then everything ran fine again.
So after the upgrade of the plugin, there was a bug. We could only work around this bug through manual scripting. Now, we are running a beta plugin from SnapCenter to overcome this problem. So, there have been a lot of bugs.
It's a beautiful product. You can put multiple systems in it but I think they're still really in the stage of developing it. They used SnapDrive before, and now its SnapCenter of course, to create a more general approach, which is great. But they should have tested more and more.
Other than the bugs I mentioned it has been stable.
I can't say anything about scalability because we only have 12 physical hosts in SnapCenter and 20 VMware instances with about 400 virtual machines. We're not a huge ballpark. We're a hospital and we have 6,000 employees. I think that if you are a really big company you would need multiple SnapCenter Servers, but I'm not sure.
For my environment it's perfect: one server, a lot of gigabytes in total memory, http use. It works. And we plan on increasing our usage. Every server which comes into production will now be connected to SnapCenter.
In our organization, almost everything is working with SnapCenter. There are just a couple of SQL Servers that need to be rebuilt, new clusters. My colleagues should finish that somewhere in the first quarter of 2019.
The technical engineers who work at NetApp, here in Amsterdam, are really helpful and willing to help. They're really nice guys and we have no problem with them at all.
We are using Data Protector backup software and SnapCenter. Before SnapCenter we used SnapDrive from NetApp. Before that, we were using EMC Legato NetWorker. We switched to SnapCenter because our colleagues here were already using NetApp. We're a hospital, we don't need high-end banking server rooms with Fibre Channel. This is an NFS solution so we decided to implement this storage. It was an all-in-one package: backup, file services, and VMware. That was really what convinced us to buy SnapCenter.
For normal sysadmins who are working with the product for the first time and who haven't taken a course on it, the setup is complex. And that's especially true for someone who didn't have any NetApp or snapshot technology knowledge prior to this. It's such a universal product - you can work with iSCSI, you can work with VMware, you can put file systems on it - you can do a lot with it. But our main provider of this software did not have any usable knowledge or experience with it either. They used whitepapers which were not that clear. It really could be better.
To install it and for everything to be working it took one to two full days, about 16 hours. That's a lot of time. At times we were saying, "No, this is not working, try it again. Let's try this, let's do this, what does the whitepaper say? How do I interpret this? Oh, let's call NetApp." It was not really that transparent.
We didn't really need any implementation strategy because we started with just one server. We had our regular backup and that continued to do what it does. Then, in addition to the regular infrastructure, we were building this. We did not really have an implementation plan. We said, "Okay we have a test SQL Server, we're going to put it in SnapCenter and see what it does."
We did not use any integrators or consultants. It was just my team. The server was installed and, afterward, we were implementing our servers into this product. I just took it on and did it myself.
Our SQL DBA took some things on also, but that was after I had explored the product and got rid of a lot of bugs with NetApp. It's an extensive software package. You have policies, you have schedule times. There was one person doing the SnapCenter integration, and that was me. Perhaps it would have been better for us to have someone from NetApp in the house. But there's a price hanging over that, of course.
What we should have done initially was put more responsibility for it in the hands of our main supplier and say, "This is not working, we need to do it differently," instead of me fixing all the problems.
Those quicker backup times, and quicker presenting of new environments: From an admin's perspective, this is a great product. But I cannot translate that into financial gain.
Hire someone who has already installed the product ten times, an experienced SnapCenter installer who can implement this product very easily and who knows all the ins and outs and bugs and which patch he should run. Get guidance.
In terms of maintenance, I convinced my colleagues, our Exchange people and our SQL people, to use it often and look into it. We all get alerts if SnapCenter fails or if a backup does not complete, but I'm the main person who is looking at it. There are three people in our organization using it: our Exchange admin, our SQL admin, and our VMware storage admin (me).
SnapCenter is an eight out of ten. In general, it's a great product, and it does what it's supposed to do, but it's buggy. They should spend some more time on the web GUI for users who don't use the CLI that often. I thought, initially, it was slow because of the resources we gave to SnapCenter Server, but that wasn't it. It has slow reaction times and does not radiate security.