We ran testing for Microsoft SQL and MySQL. For Microsoft SQL, the test case was to do multiple database schema deployments on a single host. Then we had single database schemas on multiple hosts, and we also tested high availability clusters for Microsoft SQL on four host nodes.
The performance and flexibility of non-Nutanix workloads are quite good because from a working perspective or a load perspective, scaling of the system is very straightforward. Since we're running the hosts on the normal Nutanix infrastructure, we were able to scale the loads according to what we need and it's really easy to scale up or down as needed.
The big advantage that we found was because we run development processes as well, we can actually generate development, testing, and production databases on the fly without us influencing production. This is one of the big time-saves because, in the past, you would normally have to take a backup of production, sanitize the data, then put it on a test machine. This is something that Nutanix Era makes very simple to do.
This solution has helped to save us on Tier 1 storage, which is important to us because we do a lot of systems in-house. Storage clusters are quite heavily used and they have a large footprint. Being able to save storage space for non-production tasks is significant because, for testing, we have a group of five testers working there. On dev, we have two or three developers that would work there constantly. Saving on that storage means that we can grow our production environments more effectively because we don't have to pay for test and dev storage separately. This means that the cost of ownership is a lot less, which saves us on having to purchase more storage as the system starts crowding.
If you think about it, if we run dev, test, and production all with production data, because that's what they need to do the development and testing on, we would need three times the data every time we deploy it. If the system then grows to two terabytes, that's six terabytes that we have to pay for. With Nutanix, we basically save four terabytes, which is a lot of money.
We have been able to simplify database deployment across multiple database engines. We tested with MySQL and Microsoft SQL. With MySQL, you can also use the APIs to automate that type of deployment. We have not tested the Oracle or the PostgreSQL deployment engines since we don't have those. However, with respect to the two that we tested, it simplifies them both to a large extent.
Using this solution has made the task of cloning databases much simpler and much faster. Previously, it would take us two to two and a half hours to do a clone or a snapshot. Now it's five, six minutes. It's a lot of time that we save.
We have tested the backup and in-place restore of databases but we haven't finally signed off. Once we complete the pilot, we hope to sign off on those. What we did see is that the way Nutanix Era works with the Microsoft backup system is much easier, and it appears to be more stable. This is mainly because on the Microsoft backup side, if you have a load issue, your backups will normally fail. With Nutanix Era, the backup system sits separately from the performance of the database. This means that even if you have a load issue on the data database system, the backups will still go through. Specifically, this is because Era backs up from the storage device and not from the Microsoft database. It is very technical, but as I understand it, the backup will still go through, even if the database is under strain.
We expect that once this system is in production, it will reduce downtime. One of the main selling points for us was that it will reduce update and patching downtime because it manages those updates and patches internally. Even if you deploy Microsoft SQL patches, you can manage and maintain them from the Prism interface, which should reduce downtime. They save the users downtime, and we haven't actually seen that yet, but we expect the pilot will show us that.
We tested the ability to make multiple backups per day and assess the impact that it would have on our workloads. In fact, we were able to make differential backups continuously without affecting the performance of the database engine. We were also able to schedule the backups at different times to make full backups and we couldn't see any impact or load on the database performance while we were doing this.
This will definitely help to limit data loss because we can use a continuous differential backup. We should not see any data loss as long as there's no data corruption. But if there's data corruption, and we can pinpoint the point in time, we should be able to go back to that point.
The ability to do this is very important for us. We have a series of data profiles that we have databases for. We are a university and our systems include everything from financial systems right through to medical systems that they use for the academic hospitals and the veterinary hospital.
When it comes to data management, I can see how Era will help to reduce the time spent on operational database workloads. Since we haven't used it in production for an extended period, I can't really say how much time we've actually saved. During the PoC, we only played around with it and we set up the scheduled tasks that we normally do manually.
Since we can automate a lot of things, we can skip it and schedule it. This should replace a lot of our off-hours work such as patching, upgrades, and similar tasks that can be scheduled so that the reboots can happen automatically. We don't have to sit there and babysit the whole time.
This product has helped us to reduce our database footprint because it gives us the ability to deploy Microsoft SQL instances as MySQL instances on the same host, without actually having to reconfigure or do anything. This means that we can consolidate our database service.
We can also scale them the way we need them and we can, if we really want to, move away from the one database per server type of instances that we have now into a more economical database model where we have multiple database instances on a single host, which does reduce our footprint quite a lot.
At this time, when we provision a database, we do so for a specific server. We assign the memory, CPU, and storage for that specific machine. For about 50% of the lifetime of that database, those resources are never actually utilized, whereas with Era, we can provision those as instances on the same host, and we can scale the host to cater to all of those. This gives us the opportunity to better manage how many resources are sitting idle because we can ramp them up and scale them back as needed, which will save in the long run.
More generally, using this solution will definitely improve the service delivery for our department within the organization. It's going to make it possible for us to cater to more user-centric services and needs. Because of the time-saving and the resource-saving, we'll be able to provide our users with a bigger variety of database services that they might require.
