NetApp Cloud Volumes ONTAP for Google Cloud is a powerful data management platform that enhances the built-in services of Google Cloud by providing critical features and capabilities such as storage efficiency, data protection, cloning, and more. But Cloud Volumes ONTAP can be especially useful for organizations with demanding Google Cloud performance needs.
In this article we will present the results of a recent performance benchmark that examined how Cloud Volumes ONTAP for Google Cloud performs for OLTP, streaming reads, streaming writes, and mixed workloads.
Storage, along with computing and network is one of the core building blocks used to design and develop cloud native applications. Storing and accessing data is one of the most important characteristics of any system. As with any cloud service provider, Google Cloud storage performance will be a key factor in designing your system.
Regardless of the system you're planning—database, data analytics, virtual desktop infrastructure or processing media files—when architecting a solution, there are multiple aspects regarding storage to take into consideration. We usually begin by planning basic aspects such as the required capacity, location, and availability, but those are just the starting points. With the growing importance of storage, aspects such as compliance, data protection, and performance are crucial to take into account early on.
A poorly performing storage system or service impacts the overall system health and availability (e.g., a slow database), potentially causing system failures, incidents, and bad user experience. On the other hand, good storage performance can improve the entire system's health and save you money by decreasing the time required to process data, providing a greater user experience and lower computational costs.
To understand performance there are some key storage concepts that need to be considered first. Configuring storage resources properly can have an extreme impact on the overall performance. When using Cloud Volumes ONTAP for Google Cloud there are two main aspects to consider:
The write-through configuration, also known as fast write mode, can simplify the system design and significantly increase write speeds. In this case, the system can store the data first in-memory and quickly reply to the request before the data is committed to a persistent disk. While increasing the performance this method should be used only if enhanced write performance is required and if data loss can either be tolerated or handled by the application.
A write-back configuration, also known as normal write mode, implies that the cache and persistent disk are always in sync. While it is not as fast as the write-through method, it eliminates any chance of data loss if an unplanned outage occurs. Consequently, the system is more fault tolerant and reliable than write-through, allowing the application to avoid the kind of custom business logic required to handle those limitations.
There are several metrics that need to be taken into account while testing performance. Among these, three metrics are key to measure: IOPS (input/output operations per second), throughput (amount of data transferred), and latency (response time).
Cloud storage performance varies greatly depending on the running compute workload and configuration. When designing a cloud architecture and planning the required resources, it is important to measure performance under different configuration settings with a workload type that fits the business requirements.
NetApp measured the Google Cloud performance of Cloud Volumes ONTAP using multiple Compute Engine instances with Google Persistent Disk. The tests were based on real world examples: OLTP, streaming reads, streaming writes, and mixed/analytics workloads.
Online Transaction Processing, or simply OLTP, is a transactional type of workload commonly associated with data processing in relational databases (e.g.: MySQL, Oracle, SQL Server, and SAP).
In this scenario, we have numerous concurrent requests for both reading and modifying the data in a given database coming from several users over time. These modifications, usually small and random in nature, are called transactions. The OLTP test was made with the following parameters: 8KB block size, 80% reads, and 100% random access I/O.
In a streaming read type of workload, only read operations are performed. These are typically concurrent, large, and contiguous requests that are generated by media streaming applications, such as video-on-demand and virtual tape libraries. The streaming reads test was made with the following parameters: 64KB block size, 100% read, and 100% sequential access I/O.
Streaming writes workloads make concurrent, large, and continuous write requests. These workloads are typically generated by applications such as those for medical imaging, video surveillance, media capture, and virtual tape libraries. The streaming write test was made with the following parameters: 64KB block size, 100% writes, and 100% sequential access I/O.
There are many applications that generate an unpredictable mix of multiple read/write operations. In these cases, it is hard to define the percentage of reads versus write amounts, block size and random versus sequential percentage. Therefore, it is common to start measuring the performance with a mix of 50% reads and 50% writes. This workload can be found in a virtual desktop infrastructure (VDI) and business analytics. The test for the mixed/analytics workload was made using the following parameters: 16KB block size, 50% reads, and 100% random access I/O.
The results of testing Cloud Volumes ONTAP were quite good regardless of the workload type selected. The performance results were obtained using the same configuration, a single-node Cloud Volumes ONTAP system with fast write mode disabled.
With OLTP workloads, we were able to obtain a maximum of 45,000 and 11,000 read and write IOPS, respectively. The maximum throughput was 369.3 MBps for read operations and 92.4 MBps for write operations. The latency was 1.15 ms for read and 6.3 ms for write.
For the streaming types of workloads we were able to achieve 18,000 IOPS, a throughput of 1190 MBps, and a latency of 1.3 ms in the streaming reads tests and in the streaming writes measurements were 5,500 IOPS, a throughput of 360 MBps and a latency of 4.4 ms.
The performance results of the mixed types of workloads were quite balanced. Having split the test with 50% reads and 50% writes, we were able to obtain 15,000 IOPS and a throughput of 255 MBps for both. The latency was 0.85 ms for read and 6.8 ms for write operations.
As we saw, different types of workloads can yield very distinct results, yet they all showcase the great storage performance that can be achieved with NetApp Cloud Volumes ONTAP. Any system, regardless of the workload type, can benefit from a reliable and fast storage. The results obtained should serve as a mere indication, with the right combination of configuration, underlying infrastructure and services used, the performance metrics can be even greater.
While there are many storage aspects to take into account in any enterprise IT deployment on Google Cloud, performance is the one that can have the most operational impact on the system's health.
If you’re interested in high performance storage as part of your organization’s Google Cloud deployment, try Cloud Volumes ONTAP, the enterprise-grade data management platform from NetApp. In addition to the great performance and storage capabilities for Google Cloud, you also gain the advanced data management features such as space and cost-efficient storage snapshots and SnapMirror® replication, for data protection of your Google Cloud deployments, and cost cutting technologies to reduce the amount of Google Cloud storage you consume.
Try a 30-day free trial of Cloud Volumes ONTAP for Google Cloud today.