The maximum throughput of a volume is limited and depends on several parameters.
CVS-Performance service type
The maximum throughput of a CVS-Performance service type volume is determined by the volume size and the selected service level.
The service levels—Standard, Premium, and Extreme, yield the following maximum throughput per GiB provisioned:
| Service Level | Maximum throughput per GiB provisioned |
|---|---|
| Standard | 16 KiB/s |
| Premium | 64 KiB/s |
| Extreme | 128 KiB/s |
For example, a premium volume with a size of 1500 GiB results in roughly 93.75 MiB/s (1500 GiB x 64 KiB/s/GiB / 1024 KiB/MiB).
You can change the size or service level of a volume. This process takes a few seconds and doesn't disrupt input and output (I/O) operations. After the volume changes, the throughput limit also changes. Volume throughput limits can increase up to a maximum limit. Past that point, increasing volume size no longer increases the throughput limit. See NetApp Cloud Volumes Service for Google Cloud: Benchmarks for volume limits.
CVS service type
In this service type, the storage pool aggregates capacity and performance for the volumes within the pool to be used. All volumes within a pool share the pool's performance capabilities. Each volume, independent of its size, can deliver up to the pool's maximum throughput. Volumes compete for the pool's performance. If you need performance isolation, create dedicated pools.
Storage pools deliver a maximum throughput of 128 KiB per GiB provisioned—totaling 128 MiB/s per each TiB of provisioned pool capacity. The maximum throughput capability of a pool is 1024 MiB/s for 100% large sequential reads and 350 MiB/s for 100% large sequential writes, which is reached at 8 TiB of provisioned capacity.
Beyond that amount, you can increase the pool's size but not its maximum throughput capability. While input/output operations per second (IOPS) and latency vary based on workload type, like block size and read and write ratio, CVS service type volumes can deliver up to 30,000 IOPS or more depending on size. Typical latencies are in the range of one to three microseconds.
The following sections provide more information about how you can test your workload to better understand the performance envelope with Cloud Volumes Service. You can also contact your NetApp account team to help you with testing.
Real-life performance
Workload real-life performance depends on multiple parameters—the ratio between read versus write versus metadata operations, blocksize, I/O concurrency, and service latency.
Latency is defined by the physical infrastructure, the network path between your clients and the Cloud Volumes Service volume. Remember, different zones within the same region might have different latencies. Learn how to measure volume performance.
Metadata operations are operations such as listing the contents of a folder, deleting a file, setting permissions, and a number of protocol-specific operations which make the protocol work. They are usually small and their performance is mostly limited on latency.
Read/write ratio, block size, and I/O concurrency are defined by your workload. Though the read/write ratio is usually static, block size can be changed in some cases by reconfiguring the application. The biggest improvements can be achieved by increasing I/O concurrency where more I/O operations are running in parallel without increasing overall runtime.
The following formulas explain how all these parameters connect to yield performance numbers:
IOPS = 1s/latency * concurrency
Throughput = IOPS * block size
For example, if you're using Windows Explorer to copy a large file from a local SSD to a Cloud Volumes Service volume and the Windows Explorer copy is a single thread (concurrency = 1) with a volume latency of 0.5 ms and a block size of 128 KiB, the formula would be written as shown below:
IOPS = 1 s/0.0005 s * 1 = 2000 IOPS
Throughput = 2000 IOPS * 128 KiB/IOPS = 256000 KiB/s = 250 MiB/s
If your latency is one microsecond, IOPS and throughput drop to 50%. Latency has a fundamental impact on single-threaded applications. Using multi-threaded applications that provide higher concurrency is the only way to drive this volume to its maximum performance potential.
Additional latency considerations
Very small volumes and pools have a negative impact on latency. The impact of volume and pool size is negligible for more than a few TiB. Latency has a dependency on block size. Reading or writing larger blocks takes longer because it takes more time to send the data over a network link with a given bandwidth. For volumes with a high I/O load, the observed I/O latency increases due to queuing effects, see Little’s law. As a consequence, it is misleading to measure latency with a maximum throughput test.
For information about Cloud Volumes Service benchmarks, see NetApp Cloud Volumes Service for Google Cloud: Benchmarks.
For more information about how to select the right service level and allocate capacity, see Service level and allocated capacity.
Understand space provisioning for a volume
Because space provisioning for a volume affects its capacity and performance, you should provision the right amount of capacity with the right service level to achieve your performance objectives.
For example, a volume of the CVS-Performance service type with 5 TiB of provisioned space and the Extreme service level provides a throughput of 5 * 128 MiB/s.
A volume of the CVS service type inherits the performance capacity of the storage pool to which it belongs.
For more information, see Select the appropriate service level and allocated capacity for NetApp Cloud Volumes Service.
Cloud Volumes Service supports dynamic increase and decrease of volume size. A volume is provisioned to allow writing data up to its allocated capacity.
Snapshot space requirements
Cloud Volumes Service provides advanced snapshot capabilities. For details, see Create and manage volume snapshots.
The logical used space in the volume is a combination of data in the active file system and deleted blocks retained by snapshots. Retained snapshot blocks are freed as soon as the last snapshot referencing the blocks is deleted.
You're charged for provisioned space. The logical space used—including any deleted data retained by snapshots—consumes provisioned space.
Space requirement example
A user provisions a 5 TiB volume and writes 3 TiB of data into the volume.
Result: The client sees 2 TiB of free space.
The client creates a snapshot and then deletes 1 TiB of data.
Result: The client still sees only 2 TiB of free space (5 TiB volume - 2 TiB user data - 1 TiB snapshot data). This is because the system needs to retain 1 TiB of deleted data that is referenced by the snapshot. That capacity is counted against the allocated capacity.
The snapshot is deleted.
Result: 1 TiB of snapshot data is freed, and the client sees 3 TiB of free space.
Billing for your volumes
You're charged for the provisioned (allocated) space of the volume for the CVS-Performance service type. You're charged for the provisioned (allocated) space of the pool for the CVS service type.
For example, if your volume has 2 TiB of provisioned space and you use only 1 TiB, then you are charged for 2 TiB.
For more information about billing calculations, see Pricing.
Monitor provisioned space
NetApp recommends that you monitor the usage of your volumes so that you can select an appropriate allocated capacity for your volumes and choose a new size as needed. Allocate sufficient capacity to meet the needs of your application and to prevent your volumes from running out of space at full utilization. NetApp recommends maintaining a provisioned space buffer of 20% above your expected volume utilization.
For more information about modifying the allocated capacity for a volume, see Create and manage NFS volumes and Create and manage SMB volumes.
Cloud Monitoring
Cloud Monitoring includes metrics for monitoring Cloud Volumes Service. The
volume_usage metric represents the actual usage of the volume, and
volume_size represents the allocated capacity of the volume.
You can view charts for individual metrics in Metrics Explorer, create a dashboard with multiple charts, add alerting, or retrieve metrics data with the Cloud Monitoring API.
For more information, see Monitoring cloud volumes.
View usage and allocated capacity in the Google Cloud console
You can view the usage and provisioned space for volumes on the Volumes page in the Google Cloud console.
In the Google Cloud console, go to the Volumes page.
To show the Usage column, click Column display options at the top of the volumes list, and select Usage.
Application-level monitoring
The monitoring that is closest to the application is from within the virtual machine on which the application is running. You can observe changes in behavior through capacity reporting from within the VM client operating system.
You can check the used and available capacity of a volume by using the client operating system features to query the network mapped drive properties:
Windows clients: Use the
dircommand at the command prompt, or use the Drive > Properties command in Windows Explorer.Linux clients: Use the
df -hcommand.