NetApp Cloud Volumes ONTAP Reviews

The primary use is virtualization as well as filer storage, pretty much all the features of the ONTAP suite.

We don't have any cloud footprint for contractual obligations. So, it's all pretty much on-prem, but it's in a co-location.

We use it to replicate between data centers. It is for our DR site as well. We use it to create redundancy.

We do on-prem S3 for StorageGRID. The on-prem infrastructure is cheap. It works just the same. It's S3, so it works very well as far as integration and things that use S3 in our environment.

The most valuable features are the native filer capabilities because a lot of SAN providers don't do that. When they do it, they do it with an appliance or a secondary. With this, it is just baked in right there on the system that you require. You don't have to have anything extra.

The solution’s Snapshot copies and thin clones in terms of operational recovery are the best thing since sliced bread. Rollback is super easy. It's just simple, and it works. It's very efficient.

The stability is good. I've been with NetApps for a long time, so I've seen them fall and come back. However, with cDOT and all this new stuff, it is great. It just works.

We're not that big, storage footprint-wise. However, it's simple. You just add nodes. So, it works.

We have not really used the technical support.

We had previous experiences with deploying ONTAP at other companies successfully.

ONTAP makes our storage solutions more flexible. Traditionally, that's hard to do. ONTAP gives you those features which you typically have to build yourself.

It's straightforward. But you do have to know what you're doing. Things do what you expect them to do. There is quite a bit of initial setup, but with things like Ansible and all this new stuff that they're doing, it makes it much easier and automated. So, it's simple.

I did the deployment myself with a little help from our vendor's professional services.

We have had less downtime.

Cost is a big factor, because a lot of companies can't afford enterprise grade equipment all the time. They skimp where they can. I would recommend that they improve the cost.

This company that I work for now is just acquiring quite a bit of NetApp equipment. We will be doing SnapMirror. I have done it in the past at another company.

It does exactly what it does, and it does it well. It works, and that's what really matters at the end the day: uptime, functionality, and scalability.

I would rate it a nine out of 10. There is always room for improvement. No one is ever going to be a 10.

We are using it for storing files, to get high-performance access to files. We are also using NetApp for DR. We copy the information to the same system in other regions.

The solution's high-availability features are cost-effective for us because we are able to use the cloud benefits to reduce the cost of DR. For example, if we have it in one region, we can copy the data to another region. They keep it powered off and then they power it on for a few minutes, copy the data, send the data again, and shut it down again. That reduces the costs by approximately 80 percent.

Similarly, the data protection provided by the solution's disaster recovery technology is cost-effective and simple.

We're using Cloud Manager to automate some of the management. We use it for bringing the DR environment up and down as well as for scheduling data synchronization between different regions, worldwide. It's almost impossible to do that manually. Compared to an engineer doing it manually, it's about 90 percent faster. That's specifically for this kind of operation. In reality, the automation is enabling such capabilities. It's not actually reducing the time taken. If it didn't exist, we would never do it. That's even better than saving time.

Overall, NetApp has standardized and certified file services, both on-prem and in the cloud, corporate-wide. In addition, by using the automation, it has provided us cost-effective DR and management. In the cloud it has enabled us to provide tailor-made storage solutions for each of our cloud customers. The storage efficiency has reduced our storage footprint because we are offloading all the data to the storage account. So it has reduced the cost of corporate storage. And the data-tiering has also saved us money.

What is most valuable is that the system is the same as what we use on-prem. So the guys who are responsible here for managing NetApp feel comfortable with it& and that they have enough knowledge to manage the system in the cloud. We are able to& keep the same standards that we have on-prem in the cloud.

The usability is& great. We don't have any issues with it.

We're using snapshots as well and it's a pretty useful feature. That is one of the main NetApp benefits. Knowing how to use snapshots in the on-prem environment, using snapshots on the cloud solution was natural for us.

The DR has room for improvement. For example, we now have NetApp in Western Europe and we would like to back up the information to another region. It's impossible. We need to bring up an additional NetApp in that other region and create a Cloud Manager automation to copy the data. So we do that once, at night, to another region and then shut down the destination. It's good because it's using Cloud Manager and its automation, but I would prefer it to be a more integrated solution like it was in the NetApp solution about a year ago. I would like to see something like AltaVault but in the cloud.

We have been using it for about half a year in production; longer when we include the PoC.

The stability has been great. We haven't had any issues.

We still haven't needed to scale up, but I think the scalability is good.

We are using it for a system which stores files and parts of databases, but the system is used by hundreds of customers. NetApp is not used directly by them, rather through the system. We may plan to increase NetApp according to the usage of the system but we still have no specific plans.

We are using NetApp engineers and they are great.

Before NetApp we used a home-grown server in the cloud, a Linux server with a big disk. It was less simple to manage.

We're also using Avere, a storage solution that was purchased by Microsoft a month or two ago. It's mainly responsible for real-time data synchronization between on-prem and the cloud environment. It's different than NetApp which doesn't provide the kind of synchronization solution that Avere does. It's two-way, real-time data synchronization between the Oracle storage solutions which we have on-prem and the Avere solution that we have in Azure. NetApp does not help with such requirements.

The initial setup was very simple. It was quite easy to set up the environment in just one day. We started with a small implementation and then added more and more parts of the solution. We started with just one desktop and then added additional ones and then added tiering.

It required a small number of staff members. That's all we needed because it was pretty simple. We did a few sessions online and one or two onsite, for the entire solution. For our specific case it requires almost no maintenance. It only requires management to expand the disk capacity or perform the management operations, per-request. Generally we wouldn't require an increase to our storage team to manage the solution.

We used a NetApp engineer to help us.

In addition to the standard licensing fees, there are fees for Azure, the VMs themselves and for data transfer. The DR environment is billed by the hour and paid to Azure directly and NetApp is paid on a yearly license.

We checked Dell EMC and HPE but we chose NetApp. The Storage team made the decision. One of the main reasons they chose NetApp was the existence of NetApp on-prem and the knowledge of it the team had. We are familiar with NetApp and the products are good, so we decided to extend the success to the cloud as well.

Implement it. Do not think about it. It's very simple and very useful.

For the most part, we're using it to move data off-prem. We have the ability to do mirrors from on-prem to Cloud Volumes ONTAP and we also have both single-node instances and HA instances. We are running it in both AWS and Azure.

We're using all of the management tools that go along with it. We're using both OnCommand Cloud Manager and OnCommand Unified Manager, which means we can launch System Manager as well.

Unified Manager is what monitors the environment. OnCommand Cloud Manager allows you to deploy and it does have some monitoring capabilities, but it's not like Unified Manager. And from OnCommand Cloud Manager you can launch System Manager, which gives you the lower-level details of the environment.

Cloud Manager will allow you to create volumes, do CIFS shares, NFS mounts, and create aggregates. But the rest of the networking components and other work for the SVMs and doing other configurations are normally done at that lower level. System Manager is where you would do that, whereas Unified Manager allows you to monitor the entire environment.

Say I have 30 instances running out there. Unified Manager allows me to monitor all 30 instances for things like volume-full alerts, near volume-full alerts, I-nodes, full network components being offline, paths, back-end storage paths, aggregate fulls. All those items that you would want to monitor for a healthy environment are handled through Unified Manager.

We're sitting at multiple petabytes of storage on our NetApp infrastructure. We're talking hundreds of thousands of shares across thousands of volumes. Even with that size of infrastructure, it's being supported by three people. And it's not like we're working 24/7. It gives us the ability to do a lot, to do more with less. Those three people manage our entire NAS environment. I've got two intermediate and one senior storage engineer in our environment who handle things. They're handling those multiple petabytes of on-prem and I'm just starting to get them involved in the cloud version, Cloud Volumes ONTAP. So, for the most part, it's just me on the Cloud Volume side.

In terms of the storage efficiency reducing our storage footprint, the answer I'd like to say is "yes." The problem I have is that nobody ever wants to delete anything. We have terabytes of data on-prem in multiple locations, in both primary and DR backed-up. And now, we're migrating it to the cloud. But eventually, the answer will be yes.

I'm very familiar with working from the command line, but Unified Manager, System Manager, and Cloud Manager are all GUI-based. It's easy for somebody who has not been exposed to this for years to pick it up and work with it. Personally, for the most part, I like to get in with my secure CRT and do everything from the command line.

We do a lot of DR testing of our environment, so we're using a couple of components. We use Unified Manager to link with WFA, Workflow Automation, and we do scripted cut-overs to build out. We use the mirroring to mirror our volumes to our DR location. We also create snapshots for backups. Snapshots will create a specified snapshot to be able to do a DR test without disrupting our standard mirrors. That means we can create a point-in-time snapshot, then use the ability of FlexClones to make a writeable volume to test with, and then blow it away after the DR test.

We could also do that in an actual disaster. All we would do is quiesce and break our mirrors, our volumes would become writeable, and then we would deploy our CIFS shares and our NFS mounts. We would have a full working environment in a different geographic location. Whether you're doing it on-prem or in the cloud, those capabilities are there. But that's all done at a lower level.

The data protection provided by the Snapshot feature is a crucial part of being able to maintain our environment. We stopped doing tape-based backups to our NAS systems. We do 35 days of snapshots. We keep four "hourlies," two dailies, and 35 nightly snapshots. This gives us the ability to recover any data that's been accidentally deleted or corrupted, from an application perspective, and to pull it out as a snapshot. And then there are the point-in-time snapshots, being able to create one at a given point in time. If I want to use a FlexCone to get at data, which are just pointers to the back-end data, right now, and use that as a writeable volume without interrupting my backup and DR capabilities, those point-in-time snapshots are crucial.

The user can go and recover the file himself so we don't have to have a huge number of people working on recovering things. The user has the ability to get to that snapshot location to recover the file and go however many days back. Being that it's a read-only a file to the user community, users can get at that data, as long as they have proper rights to that file. Somebody else could not get to a file for which they don't have rights. There's no security breach or vulnerability. It just provides the ability for a user who owns that data to get to a backup copy of that data, to recover it, in case they've deleted or had a file corruption.

We also use their File Services Solutions in the cloud, CIFS and NFS. It works just as well as on-prem. The way we configure an environment, we have the ability to talk back to our domain controllers, and then it uses the standard AD credentials and DNS from our on-prem environments.

Cloud Volumes ONTAP in the cloud, versus Data ONTAP on-prem, are the exact same products. If you have systems on-prem that you're migrating to the cloud, you won't have to retrain your workforce because they'll be used to everything that they'll be doing in the cloud as a result of what they've been doing on-prem. In that sense, Cloud Volumes ONTAP is the exact same product, unless you're using a really old version of Data ONTAP on-prem. Then there's the standard change between Data ONTAP versions.

Some of the licensing is a little kludgy. We just created an HA environment in Azure and their licensing for SVMs per node is a little kludgy. They're working on it right now. We're working with them on straightening it out.

We're moving a grid environment to Azure and the way it was set up is that we have eight SVMs, which are virtual environments. Each of those has its own CIFS servers, all their CIFS and NFS mounts. The reason they're independent of one another is that different groups of business got pulled together, so they had specific CIFS share names and you can't have the same name in the same server more than once on the network. You can't have CIFS share called "Data" in the same SVM. We have eight SVMs because of the way the data was labeled in the paths. God forbid you change a path because that breaks everything in every application all down the line. It gives you the ability to port existing applications from on-prem into cloud and/or from on-prem into fibre infrastructure.

But that ability wasn't there in Cloud Volumes ONTAP because they assume that it was going to be a new market and they licensed it for a single SVM per instance built out in the cloud. They were figuring: New market and new people coming to this, not people porting these massive old-volume infrastructures. In our DR infrastructure we have 60 SVMs. That's not how they build out the new environments. 

We're working with them to improve that and they're making strides. The licensing is the only thing that I can see they can improve on and they're working on it, so I wouldn't even knock them on that.

I've been using it since its inception. Prior to it being called Cloud Volumes ONTAP, it was named a couple of different things as it went along. I've been working with the on-prem Data ONTAP for about 16 years now. When they first offered the Cloud Volumes ONTAP, I started testing that out in a Beta program. It's been a few years now with Cloud Volumes ONTAP. I'm our lead storage engineer, but I'm also on a couple of our cloud teams and I'm a cloud administrator for our organization. We started looking at it when AWS ( /products/amazon-aws-reviews ) first started coming on the scene, at what we could do in the cloud. And as a company direction, we're implementing cloud-first, where available.

We've had no issues.

In an HA environment, it will scale up to 358 terabytes. That's not bad per-system. We've had no difficulties.

We will be moving more stuff off-prem into the cloud. Right now it's at about 15 percent of our entire environment, and we plan on at least 10 percent, or more, per quarter, over the next few years.

We'll be doing the tiering and using the Cloud Sync as well. We're a financial and insurance company, so some things have to remain on-prem, and some things, from a PCI perspective, have a lot of different requirements around them. And because we're across multiple countries worldwide, there are all sorts of HIPAA and other types of legal and financial ramifications from a security perspective. In the UK and in Europe there are the privacy components. There are different things in Hong Kong and Singapore, in Spain, etc. Each country unit requires different types of policies to be adhered to. Everything we have is encrypted at rest, as well as encrypted in-flight.

Cloud Volumes ONTAP will also support doing data encryption at a volume level, a software encryption. But from a PCI perspective, we use the NSE drives, which give us hardware encryption. So they're double encrypted. They are hardware encrypted. We're having to use a management appliance to keep and maintain the encryption keys, and we do quarterly encryption-key replacement. But there are also the volumes that are encrypted as well. We also use TLS for transporting the data, doing encryption in-flight. There are all sorts of things that it supports which allow you to be compliant.

Another feature it has is disk sanitize, a destruction component which allows you to do a DoD wipe of the data. Once you've decommissioned an environment, it is completely wiped so nobody can get access to the data that was there previously. That's all built into Data ONTAP, including Cloud Volumes.

NSE drives are a little different because you are not getting physical drives in the cloud environment, so you couldn't do that. But you can do the volume encryption, from Cloud Volumes. In terms of a DoD wipe, you wouldn't be doing that on Azure's or AWS's environments because it's a virtual disk.

I've rarely used tech support. I've got so much experience deploying these environments that it's like breathing. It's second nature. And when they first came out with OnCommand Cloud Manager, I was doing beta testing and debugging with the group out of Israel to build the product.

The initial setup was very straightforward. If you use an OnCommand Cloud Manager to deploy it into AWS or Azure, it's point-and-click stupid-simple. It takes less than 15 minutes, depending upon your connectivity and bandwidth. That 15 minutes is to build out a brand-new filer and create CIFS shares on it. It automatically deploys it for you: the back-end storage, the EC2 instances, if you're in an AWS. In Azure, it creates the Blob space. It creates the VMs. 

It's all done for you with just a couple of screens. You tell it what you want to call it, you tell it what account or subscription you're using, depending upon whether it's AWS or Azure. You tell it how big you want the device to be, how much storage you want it to have, and what volumes you want it to create; CIFS shares, etc. You click next, next, next. As long as you have the ability to provision what you've gone into, whether it's AWS or Azure, and turned on programmatic deployment, it gives you the access. The only thing you have to do outside Cloud Volumes ONTAP under OnCommand Cloud Manager is turn it on to allow it to run. It picks up everything else. It'll pick up what VPC you have, what subnet you have. You just tell it what security group you want it to use. It's fairly simple.

If somebody hasn't utilized or isn't familiar with how to deploy anything in either AWS or Azure, it might be a tad more complicated because they'd need to get that information to begin with. You have to have at least moderate experience with your infrastructure to know which VPC and subnet and security group to specify.

In my opinion, we're getting a good return on investment.

I always try new products. I've used the SoftNAS product, and a couple of other generic NAS products. They don't even compare. They're not on the same page. They're not even in the same universe. I might be a little biased but they're not even close. 

I have looked at Azure NetApp Files, which is another product that NetApp is putting out. Instead of Cloud Volumes it's cloud files. You don't have to deploy an entire NetApp infrastructure. It gives you the ability to do CIFS at file level without having to manage any of the overhead. That's pre-managed for you.

For somebody who's never used it before, the biggest thing is ease of use. In terms of advice, as long as you design your implementation correctly, it should be fine. I would do the due diligence on the front-end to determine how you want to utilize it before you deploy.

We have over 3,000 users of the solution who have access to snapshots, etc. but only to their own data. We have multiple SVMs per business unit and a locked-down security on that. Only individuals who own data have access to it. We are officially like a utility. We give them storage space. We give them the ability to use it and then they maintain their data. From an IT perspective, we can't really discern what is business-critical and what isn't to a specific business unit. We're global, we're not just U.S., we're all over the world.

We've gone into doing HA. It's the same as what's on-prem, and HA on-prem is something we've always done. When we would buy a filer for on-premise, we'd always buy a two-node HA filer with a switch back-end to be able to maintain the environment. The other nice thing, from an on-prem perspective with a switched environment, is that we can inject and eject nodes. We can do a zero-downtime lifecycle. We can inject new nodes and mirror the data to the new nodes. Once everything's on those new nodes, eject the old nodes and we will have effectively lifecycled the environment, without having to take any downtime. Data ONTAP works really well for that. The only thing to be aware of is that to inject new nodes into an existing cluster, they have to be at the same version of Data ONTAP.

In terms of provisioning, we keep that locked down because we don't want them running us out of space. We have a ticketing system where users request storage allocation and the NAS team, which supports the NetApp infrastructure, will allocate the space with the shares, to start out. After that, our second-level support teams, our DSC (distributed service center) will maintain the volumes from a size perspective. If something starts to get near-full, they will automatically allocate additional space. The reason we have that in place is that if it tries to grow rapidly, like if there's an application that's out of control and just keeps spinning up and eating more and more of the utilization, it gives us the ability to stop that and get with the user before they go from using a couple a hundred gigs to multiple terabytes, which would cost them X amount. There is the ability to auto-grow. We just don't use it in our environment.

In terms of the data protection provided by the solution's disaster recovery technology, we use that a lot. Prior to clustered ONTAP - this is going back to 7-Mode - there was the ability to auto-DR with a single command. That gave us the ability to do a cut-over to another environment and automatically fail. We're currently using WFA to do that because, when they first came out with cluster mode, they didn't have the ability to auto-DR. I have not looked into whether they've made auto-DR a feature in these later versions of Data ONTAP.

OnCommand Cloud Manager doesn't allow you to do DR-type stuff. There are other things within the suite of the cloud environment that you can do: There's Cloud Sync which allows you to create a data broker and sync between CIFS shares or NFS mounts into an S3 bucket back-end. There's a lot of stuff that you can do there, but that's getting into the other product lines.

As for using it to deploy Kubernetes, we are working through that right now. That process is going well. We've really just started getting through it and it hasn't been overly complicated. Cloud Volumes ONTAP's capabilities for deploying Kubernetes means it's been fairly easy.

In terms of the cloud, one thing that has made things a little easier is that previously, within the AWS environment, we used to have to create a virtual filer in each of our subscriptions or accounts because we really wanted the filer to be close to the database instances or the servers within that same account, without traversing VPCs. Now, since they have given us the ability to do VPC peering, we can create an overarching primary account and then have it talk to all the instances within that storage account, or subscription in Azure, without having to have one spun up in every single subscription or account. We have a lot of accounts so it has allowed us to reel that back by creating larger HA components in a single account and then give access through VPCs to the other accounts. All that traffic stays within Azure or AWS. That saves money because we don't have to pay them for multiple subscriptions of Cloud Volumes ONTAP and/or additional virtual filers.

For my use, Cloud Volumes ONTAP is a ten out of ten.

The primary use case is for SAP production environments. We are running the shared file systems for our SAP systems on it.

It's helped us to dive into the cloud very fast. We didn't have to change any automations which we already had. We didn't have to change any processes we already had. We were able to adopt it very fast. It was a huge benefit for us to use the same concepts in the cloud as we do on-premise. We're running our environment very efficiently, and it was very helpful that our staff, our operators, didn't have to learn new systems. They have the same processes, all the same knowledge they had before. It was very easy and fast.

We did a comparison, of course, and it was cheaper to have Cloud Volumes ONTAP running with the deduplication and compression, compared to storing everything, for example, on HA disks and have a server running all the time as well. And that was not even for the biggest environment.

The data tiering saves us money because it offloads all the code data to the Blob Storage. However, we use the HA version and data tiering just came to HA with version 9.6 and we are not on 9.6 in our production environment. It's still on RC, the pre-release, and not on GA release. In our testing we have seen that it saves a lot of money, but our production systems are not there yet.

The high availability of the service is a valuable feature. We use the HA version to run two instances. That way there is no downtime for our services when we do any maintenance on the system itself.

For normal upgrades or updates of the system - updates for security fixes, for example - it helps that the systems and that the service itself stay online. For one of our customers, we have 20 systems attached and if we had to ride that customer all the time and say, "Oh, sorry, we have to take your 20 systems down just because we have to do maintenance on your shared file systems," he would not be amused. So that's really a huge benefit.

And there are the usual NetApp benefits we have had over the last ten years or so, like snapshotting, cloning, and deduplication and compression which make it space-efficient on the cloud as well. We've been taking advantage of the data protection provided by the snapshot feature for many years in our on-prem storage systems. We find it very good. And we offload those snapshots as well to other instances, or to other storage systems.

The provisioning capability was challenging the first time we used it. You have to find the right way to deploy but, after the first and second try, it was very easy to automate for us. We are highly automated in our environment so we use the REST API for deployment. We completely deploy the Cloud Volumes ONTAP instance itself automatically, when we have a new customer. Similarly, deployment on the Cloud Volumes ONTAP for the Volumes and access to the Cloud Volumes ONTAP instance are automated as well.

But for that, we still use our on-premise automations with WFA (Workflow Automation). NetApp has a tool which simplifies the automation of NetApp storage systems. We use the same automation for the Cloud Volumes ONTAP instances as we do for our on-premise storage systems. There's no difference, at the end of the day, from the operating system standpoint.

In addition, NetApp's Cloud Manager automation capabilities are very good because, again, it's REST-API-driven, so we can completely automate everything. It has a good overview if you want to just have a look into your environment as well. It's pretty good.

Another feature which gets a lot of attention in our environment is the File Services Solutions in the cloud, because it's a completely, fully-managed service. We don't have to take care of any updates, upgrades, or configurations. We're just using it, deploying volumes and using them. We see that, in some way, as being the future of storage services, for us at least: completely managed.

Scale-up and scale-out could be improved. It would be interesting to have multiple HA pairs on one cluster, for example, or to increase the single instances more, from a performance perspective. It would be good to get more performance out of a single HA pair. My guess is that those will be the next challenges they have to face.

One difficulty is that it has no SAP HANA certification. The asset performance restrictions create challenges with the infrastructure underneath: The disks and stuff like that often have lower latencies than SAP HANA itself has to have. That was something of a challenge for us: where to use HA disks and where to use Cloud Volumes ONTAP in that environment, instead of just using Cloud Volumes ONTAP.

The stability is very good. We haven't had any outages.

Right now, the scalability is sufficient in what it provides for us, but we can see that our customer environments are growing. We can see that it will reach its performance end in around a year or so. They will have to evolve or create some performance improvements or build some scale-up/scale-out capabilities into it.

In terms of increasing our usage, the tiering will be definitely used in production as soon as its GA for Azur. They're already playing with the Ultra SSDs, for performance improvements on the storage system itself. As soon as they become generally available by Microsoft, that will probably a feature we'll go to.

As for end-users, for us they are our customers. But the customers have several hundred or 1,000 users on the system. I don't really know how many end-users are ultimately using it, but we have about ten customers.

Technical support has been very good. The technical people who are responsible for us at NetApp are very good. If we contact them we get direct feedback. We often have direct contact, in our case at least, to the engineers as well. We have direct contacts with NetApp in Tel Aviv.

It's worth mentioning that when we started with Cloud Volumes ONTAP in the past, we did an architecture workshop with them in Tel Aviv, to tell them what our deployments look like in our on-premise environment, and to figure out what possibilities Cloud Volumes ONTAP could provide to us as a service provider. What else could we do on it, other than just running several services? For example: disaster recovery or doing our backups. We did that at a very early stage in the process.

We only used native Azure services. We went with Cloud Volumes ONTAP because it was a natural extension of our NetApp products. We have a huge on-premise storage environment from NetApp and we have been familiar with all the benefits from these storage systems for several years. We wanted to have all the benefits in the cloud, the same as we have on-premise. That's why we evaluated it, and we're in a very early stage with it.

To say the initial setup was complex is too strong. We had to look into it and find the right way to do it. It wasn't that complex, it was just a matter of understanding what was supported and what was not from the SAP side. But as soon as we figured that out, it was very straightforward to figure out how to build our environment.

We had an implementation strategy: Determining what SAP systems and what services we would like to deploy in the cloud. Our strategy was that if Cloud Volumes ONTAP made sense in any use case, we would want to use it because it's, again, highly automated and we could use it with our scripting already. Then we had to look at what is supported by SAP itself. We mixed that together in the end and that gave us our concept.

Our initial deployment took one to two weeks, maximum. It required two people, in total, but it was a mixture of SAP and storage colleagues. In terms of maintenance, it doesn't take any additional people than we already have for our on-premise environment. There was no additional headcount for the cloud environment. It's the same operating team and the same people managing Cloud Volumes ONTAP as well as our on-premise storage systems. It requires almost no maintenance. It just runs and we don't have to take care of updating it every two months or so for security reasons.

We didn't use a third-party.

We have seen return on investment but I don't have the numbers. 

The standard pricing is online. Pricing depends. If you're using the PayGo model, then it's just the normal costs on the Microsoft page. If you're using Bring Your Own License, which is what we're doing, then you get with your sales contact at NetApp and start figuring out what price is the best, in the end, for your company. We have an Enterprise Agreement or something similar to that. So we get a different price for it.

In terms of additional costs beyond the standard licensing fees, you have to run instances in Azure, virtual machines and disks. You still have to pay for the Azure disks, and Blob Storage if you're using tiering. What's also important is to know is the network bandwidth. That was the most complicated part in our project, to figure out how much data would be streamed out of our data center into the cloud and how much data would have to be sent back into our data center. It's more challenging than if you have a customer who is running only in Azure. It can be expensive if you don't have an eye on it.

We have a single-vendor strategy.

Don't be afraid of granting permissions because that's one of the most complex parts, but that's Azure. As soon as you've done that, it's easy and straightforward. When you do it the first time you'll think, "Oh, why is it so complicated?" That's native Azure.

The biggest lesson I've learned from using Cloud Volumes ONTAP is that from an optimization standpoint, our on-premise instance was a lot more complex than it had to be. That's was a big lesson because Cloud Volumes ONTAP is a very easy, light, wide service. You just use it and it doesn't require that much configuring. You can just use the standards which come from NetApp and that was something we didn't do with our on-premise environment.

In terms of disaster recovery, we have not used Cloud Volumes ONTAP in production yet. We've tested it to see if we could adopt Cloud Volumes ONTAP for that scenario, to migrate all our offloads or all our storage footprint we have on-premise to Cloud Volumes ONTAP. We're still evaluating it. We've done a lot of cost-comparison, which looks pretty good. But we are still facing a little technical problem because we're a CSP (cloud service provider). We're on the way to having Microsoft fix that. It's a Microsoft issue, not a NetApp Cloud Volumes ONTAP issue.

I would rate the solution at eight out of ten. There are improvements they need to make for scale-up and scale-out.

Our primary usage is as a repository for the application servers. It's mostly for NFS, with very good replication options and backup features. There are also tools that we need to put there and replicate between our on-prem and AWS locations.

We tried to use EFS, for example, but one of the cons of EFS was that the performance was degraded once we had a lot of files and very large storage. It took it a while to handle everything. Also, backing up was harder and we needed a third-party. With NetApp it's much easier. Performance is very good and there was no need to change our environments, our speeds, or our automation because we have NetApps on-prem as well. When you have 100,000 files on smaller volumes, or you have bigger volumes with millions of files, it's almost impossible to work with EFS. With NetApp we didn't even feel it. It's all flowing really well.

The snapshot ability we're using is very good, SnapMirror. For example, we have a vault account and we can SnapMirror our volumes to that vault account. It has a NetApp that sits on it as three buckets and acts as our offset backups.

The FlexClones make all the management easier for us.

They're making the right improvements right now. The only issue we had lately was that outside our VPC we could not reach the virtual IP, the floating IP. I heard that they have fixed that as well. That's a good advantage.

We've been using it for two years already.

The stability has been very good. The only time that it was down was because someone took the machine down. That was in the beginning and then we fixed the permissions. But it wasn't an issue on NetApp's end that caused the system to go down.

Both performance and scalability are really good. We started with a small system but have grown really fast. We needed to change the type of system and the license. We were able to do that online with no issues. Doing so, and going with the bigger type of system, also gives us better performance. 

So if you need more performance, you can always change the type of system. Working with NetApp, they provide us with a consultant, if needed, to determine what the best type of system is for our use case, based on the performance that we need. They're flexible.

We're growing all the time. We have several sites already and we're adding more sites when needed. We are keeping the on-prem as well because it doesn't always make sense to move to the cloud. It depends on budget, the CapEx and OpEx. But we are growing.

The support has been great. Every time we've had a question or something that we didn't know how to do, a setup issue, they have helped us. There was one time that we set up a new one on a new version and there was a small bug that was fixed really fast. It wasn't within how the system functions, it was a bug in the deployment part. They helped us really quickly and we were able to manage that as well.

There was a lot of downtime with our previous solution. Also, the performance wasn't what it should be. Any update that we did required downtime, and there were quite a lot of updates because there were a lot of bugs. That's where Cloud Volumes ONTAP is very good because they're using the same software as in their devices. There are no special needs or special bugs. They're using a very mature a solution.

The initial one we set up was more complex until we understood the parts. There is a manager that is doing everything for you, but you need to know which IP, what are the prerequisites, etc. It took a while to understand that. But once we did the first one, it became very easy to deploy. My team can now do it in one or two hours, with all the integration that we need.

In terms of an implementation strategy, we get the requirements from the business. Whenever we need a new environment, for example, my team sets it up really fast. We can set all the configuration like any other systems we have: with our monitoring tools, the backup, snapshots; everything the same way. It's easy to manage and replicate things to look the same.

Migration was pretty easy. We could use SnapMirror or we could use NetApp's XCP Migration Tool. That was pretty awesome. It replicated the data faster than any other tool that I've seen. That was a big help.

For deployment, there are two guys from my team who work together. Of course, we have a network guy setting up all the network stuff, and there's the cloud team that is doing that part of the configuration. Once we have all the prerequisites, they can set it up really fast.

For maintenance, it requires less than one person. We have a small group, about eight people for 150 systems, which manages systems worldwide, not just on the cloud but also on-prem. It's part of managed systems and it's being managed with the management tools. We don't see that as something where we need to add more people if we add another system.

We used a third-party, mostly for the cloud itself, for the VPC configuration, the environment-related stuff that my company uses. But we did not use one for NetApp itself.

Since we're a SaaS business, we need to have stable environments for our customers. We can't have downtime every week or so. Stability is very important for us, as well as a guarantee that data is being backed up. If someone, even by mistake, deletes something, there is a way to recover it. Stability, availability, performance, all these kinds of things, mean we're eventually getting more customers and more satisfied customers.

We've been working with NetApp on pricing. They allow a special price if you are working closely with them. Since we have a lot of NetApp systems, we got some kind of discount. That's something they do for other customers, not just for us. The price was fair.

In addition to the licensing fees, you're paying Amazon for your usage, the instances, the storage. It's using EBS drives or S3 buckets. So there are all the Amazon fees that you usually have. But overall, we compared the price we have with NetApp and the price for going with DFS and there was a difference, but it was worth the performance, stability, and to have the capabilities NetApp has for doing backups. All these features are covered.

It's NetApp. It's what we know. Our NetApp on-prem has been really good, so we continue to maintain that.

There is a 30-day trial that you can use to get a feel for it. You can work with NetApp in case you have questions in deploying it. They're helpful with that. If you're planning big, to deploy in several sites or a few systems, and you have plans for the future, you can always talk with NetApp and work on getting the right price for you and what makes sense. It depends on your growth and how big your footprint is. They will help you, of course. 

I would rate it between nine and ten out of ten. I don't have any complaints. Maybe it could be cheaper but as for how it functions, it's really doing what it needs to do.

The tool integrates very well the contents that are deployed there. Each aspect is well structured and responsibly what allows it to advance and achieve success. 

This tool allows working with clean and safe servers. We made a complement and therefore we made progress in optimizing each launch platform in a matter of days.

One of the features of this tool is the ease of use, in addition to the control access and the dynamics with which it is structured.

It does not have tutorials in languages such as French, German, Spanish. Adding these options would improve the support service of NetApp Cloud Volumes ONTAP.

It provides flexibility for our VM environments. We use it to transport data between on-premise systems and the cloud.

AWS is the biggest and most common use case for integration with ONTAP.

We have a number of systems that we run on-premise and have not been moved to AWS for various reasons. ONTAP allows us to manage our portfolio across two domains. 

It manages our environments with a single purview of data management, especially as each variant of ONTAP uses identical metadata and file system formats. Then, data can be universally managed and manipulated throughout the data fabric.

SnapMirror helps mirror metadata and data volumes between endpoints in a data fabric.

The navigation on some of the configuration parameters is a bit cumbersome, making the learning curve on functions somewhat steep.

I would like them to make upgrading simpler. I would like it if they could offer a simpler upgrade guide which you can generate through their website, because their current version is full of dozens of complicated CLI commands. 

It is very stable and versatile, but you need to have an advanced degree to administer or monitor it.

Since it has seamless integration with AWS, scalability is not an issue.

NetApp ONTAP and AWS work really well together. ONTAP was designed to run within Amazon Elastic Compute Cloud instances. Once Cloud Volumes ONTAP is installed, Amazon Elastic Block Store (EBS) volumes are assigned to the Cloud Volumes ONTAP EC2 compute instance to create the equivalent of a Data ONTAP storage array.

Purchasing this solution through the AWS Marketplace was simple, which was why our organization chose to go through it. The AWS consumer-based pricing model makes it easy for developers to use their credit cards to spin up virtual servers immediately.

Compared to other storage vendors, NetApp, is not always able to compete with their pricing. Yet, we acknowledge the ease of use ONTAP brings with the AWS integration.

We are making good use of the product. It has a lot of features and is an efficient/stable product. The recovery using Snapshots is a big plus, alongside the flexibility in volume creation for Unix, as well as Windows environments. Its challenges are on the learning curve, as well as its pricing could be improved.

Lo usamos para la seguridad en la navegación y la administración de fuentes de datos alternativas con el fin de mantener activos todos los procesos.

Nos permite sincronizar los métodos de sincronización, basados ​​en la plataforma B2B, para agregarlos correctamente a las listas de correo electrónico del cliente. Nos proporciona calidad y seguridad al mismo tiempo, utilizando estrategias tecnológicas avanzadas. Los resultados son sorprendentes en términos de funcionalidad y defensa contra terceros. 

La característica más valiosa se define por la seguridad en la que se muestran los datos y las acciones recíprocas para establecer los criterios de búsqueda. Su funcionalidad y soporte técnico son adecuados para ayudar a prevenir fallas debido a errores.

Funciona muy bien con datos externos cargados en la nube desde otras plataformas. La integración ha sido exitosa y segura. 

El producto mantiene un enfoque arraigado en los procesos no alternativos. Esto logra dificultad en la conexión de la vulnerabilidad en los procesos. Me gustaría verlos mejorar la perspectiva de inicio y búsqueda en los paneles. Esto permitiría una mejor visualización de los contenidos que se capturan en la herramienta. 

Actualmente, no tenemos ningún problema al enfatizar la herramienta. Confiamos plenamente en la estructura de seguridad que gestiona esta plataforma multifuncional.

Lo usamos en toda la empresa.

El trato con el vendedor era aceptable; El precio es razonable. Los recursos adquiridos con esta herramienta valen el costo.

Es una herramienta que nos permite mantener una perspectiva sobre el estado de la información.

We use it for file services, both CIFS and NFS.

The university didn't have a centralized file service before we moved to NetApp. Now, departments can share information across 24,000 students, across 10,000 faculty and staff. They can share data without doing it through email, which was the old way.

It has definitely helped reduce the overall costs of storage. We actually started out with the IBM M-Series seven years back. We switched to NetApp. The same hardware from NetApp is a better price than it was through IBM, and the support is better. So it has reduced our expenses through that path. And since it's so easily supported, we don't need a lot of people to support it, so our support costs are lower.

We've had a lot of centralization going on. We have 13 schools, each of which had its own IT department. All those IT departments are now out of business because their work has been centralized into our department. Part of that was due to the economy changing and the school changing its business models, but that put our NetApp storage heavily into use. So it's hard to distinguish cause and effect.

I can't specify the amount of space saved, but the deduplication and compression in ONTAP are very effective. We're probably getting 35 - 40 percent savings because of dedupe and compression. And because every volume we put out is a quoted Qtree on a volume, we don't have wasted whitespace. I'm billing for 800 terabytes every single month, that's running on one petabyte of rotating disk. So, it's very good at saving me space. I'm running with about 20 percent available disk, above and beyond what I'm billing. So it's pretty good at that.

We're charging four cents per gigabyte per month and, unfortunately, I'm making money at that rate. We're not allowed to make a profit. I've been looking at reducing what we're charging our customers because it is so cost-effective.

The ability for our users to restore data from the Snapshots is very valuable.

I would like to see more cloud integration. NetApp had nothing for cloud integration about three or four years back and then, all of a sudden, they got it going and got it going quickly, catching up with the competition. They've done a very good job. NetApp's website has seen phenomenal changes, so I greatly appreciate that.

It's very stable. We've only had two outages with NetApp in seven years. One was a planned outage to fix a problem - that one was seven minutes long. The other was an unplanned failure, which caused us to be down for about five hours. Overall, we're still within our five- and six-nines of availability, so we're happy.

It's completely scalable, as long as you're willing to buy the hardware. That's why we're looking at cloud for the future, so we can stop buying hardware and maybe use the cloud instead.

It's excellent. The technical support has been very good.

One thing I find very annoying is the new web interface, where it takes you through a little AI assistant, a little robot thing, to try to answer your question first. That thing is infuriating because we've already done the research, we know we need support. Fortunately, there's a link so you can get past that quickly.

What I like about NetApp Support is that, generally, the person who takes your case is the one who works it to the end. There aren't a lot of handoffs or a lot of callbacks.

We had always done block storage and we had a large IBM infrastructure, a large ESX infrastructure, physical servers. We knew that we needed a file service, so we set that up. It was really a first for our university. We switched from IBM to NetApp because we thought we'd get better support from NetApp, and we really have. IBM did a good job, but it was obvious that IBM and NetApp didn't always play well together. IBM was slower to put out patches and fixes compared to NetApp. When IBM was telling us to go to the NetApp site to find support, we figured we'd just switch to NetApp.

The initial setup was quite straightforward because we knew what we were going to do with it and we hired Sirius on for a limited part of the job. We did most of it on our own.

I know we're providing our service very cost-effectively, and it's selling faster than we expected. Money is coming in faster than we expected and, therefore, I need to drop what I'm charging per gigabyte per month so I don't make a profit, because we're not allowed to. So it's obviously successful.

Our shortlist was really only NetApp. We looked at about a dozen other products, Hitachi and everything else, but NetApp really had the best product.

Talk to any peer you can find about what products they looked at. We spoke to a dozen peer institutions - universities, colleges - about what they were doing for file services. We found a lot that were failing and a lot that were successful. The successful ones were mostly on NetApp.

It's a very solid product. I've been using if for about seven years, and it's been mostly bulletproof. They have very good support and a very good quality hard drive.

We use it for mission-critical applications but less than we used to. A lot of our mission-critical stuff is now going out to cloud. That's why I'm here at NetApp Insight 2018, to see how we can tie this into the cloud. Absolutely, all of the university's "crown jewels" used to be on NetApp storage. Now, some have gone out to AWS and we're integrating into AWS more and more. For example, Blackboard is no longer running off out NetApp storage. It's now running out of the cloud. The same is true for all the financial stuff, all the Workday and the like. They've moved off of NetApp and out to the cloud.

In terms of machine-learning, AI, real-time analytics, and those kinds of ground-breaking apps for storage, that's more the research support side. We're not doing that. We're doing more of the general file systems support, for general-purpose use.

I don't have any opinion about NVME over Fabrics, I haven't researched it yet.

We bought our equipment through Sirius Computer Solutions, and we're very pleased with that. They care. We've had a couple different senior salespeople with them over the years and they've both been excellent. They're very committed to their customers.

I rate NetApp ONTAP Cloud at eight out of then. I won't give a ten. There's always something that's better out there, but you're going to be paying double or triple for it. For the price, the quality of the hardware, the quality of the support, the features it offers, I'm thrilled with NetApp.

It just gives us the capability to get cloud resources.

The primary use case for ONTAP Cloud is getting data into the cloud.

We are using the product for our future planning in the following:

• Disaster recovery in the cloud
• Backup in the cloud
• Development in the cloud.

• SnapMirror
• SnapVault
• Fast, persistent storage in the cloud

Just more scale out. It can only do two nodes. One SVM, which would be okay as long as I can scale easily.

It needs to be matured with more capabilities.

So far, so good.

It's limited. We're trying to figure out better methods as we need to scale out more.

We have built-in support. It is good. They are an onsite resource.

We needed persistent storage in the cloud for platforms, and there's really not options right now in AWS or Azure.

We also use Avere Gateways. That's pretty much it.

I was the one who evaluated and approved the use of ONTAP Cloud.

It functions and I think in the future it will be a reasonable method of getting NFS and the cloud.

The most important factor that lead us to use OTC versus a native cloud storage solution was having enough fast capabilities and social capabilities. It is extremely important that our storage enable us to render and integrate on-premise systems with cloud services. Cloud integration is also very important for us in our selection of a future on-premise storage system.

We use AWS cloud service.

Most important criteria when selecting a vendor: We are 95% on NetApp on-premise. We wanted compatibility with their on-premise solutions.