Everpure Cloud Dedicated Release Notes v6.10.0

Overview

Everpure Cloud Dedicated for Azure NVMe backend
Everpure Cloud Dedicated for Azure V20 maximum capacity increased
New regions available for Azure Everpure Cloud Dedicated with Premium v2 SSDs
Other Purity Improvements

NVMe Backend on Azure Everpure Cloud Dedicated

NVMe-Based Backend Support in Everpure Cloud Dedicated for Azure

Prior to the 6.10.0 release, Everpure Cloud Dedicated for Azure used an SCSI-based backend to connect Managed Disks (both SSDs and NVRAM) to its controller VMs.

Starting with 6.10.0, Everpure Cloud Dedicated SKUs with Premium V2 SSDs will leverage NVMe-based access for Managed Disks. NVMe is a high-speed storage protocol that enables direct communication with storage devices over the PCIe bus. Compared to SCSI, NVMe brings improvements potentially resulting in lower latency, higher IOPS, and reduced CPU utilization.

How to switch to NVMe backend?

To begin using the NVMe backend, upgrade the array to Purity version 6.10.0. As part of this upgrade, the existing SCSI-based controller VM is automatically replaced with an equivalent NVMe-enabled VM.

This transition is fully automated and transparent, no manual steps or redeployment is required, and there are no changes to the user interface or management workflows. The cost of the array also remains unchanged.

Note: Starting with version 6.10.0, NVMe becomes the only supported backend protocol for Everpure Cloud Dedicated for Azure. Once the array has been moved to the NVMe backend, there is no option to revert back to SCSI.

Backend Performance Characteristics

In Everpure Cloud Dedicated deployments on Azure, the backend performance - meaning the IOPS and throughput between the controller VM and the attached managed disks - is primarily determined by the VM size. This is because Azure imposes VM-level caps on both backend IOPS and throughput. These limits apply regardless of the number of attached disks.

Primary Controller Behavior

The maximum achievable backend IOPS for the primary controller is based on the lower of:

The IOPS cap defined by Azure for the VM SKU
The combined IOPS of all attached SSDs (Azure Managed Disks)

Individual Everpure Cloud Dedicated SSD Managed Disk performance was selected and configured as to saturate the controller VM backend limits, i.e.: Maximum VM backend IOPS / # of SSD disks = each SSD IOPS

Azure also enforces a VM-level backend bandwidth limit, which is a combined cap across both read and write operations. This means that even with multiple high-throughput disks, the total achievable bandwidth cannot exceed what the VM SKU allows.

Secondary Controller Behavior

The secondary controller performs only minimal read-only operations. As a result, each attached disk is typically limited to 256 read IOPS on the secondary node and therefore does not necessarily benefit from this change.

What is changing?

With the switch to NVMe protocol, Azure increases the backend IOPS and bandwidth caps of compatible VMs. This includes the ones used as Everpure Cloud Dedicated Controllers (for MP2R2 SKUs)

VM Size	Backend type	Max Backend IOPS	Max Backend R/W Throughput (MBps)	Frontend Network Bandwidth (Mbps)
V10MP2R2	NVMe	88,400	2,300	12,500
V10MP2R2	SCSI	64,800	1,370	12,500
V20MP2R2	NVMe	174,200	4,800	16,000
V20MP2R2	SCSI	129,700	2,740	16,000

Source: https://learn.microsoft.com/en-us/azure/virtual-machines/ebdsv5-ebsv5-series

From the table above it is clear both IOPS and Bandwidth are seeing significant improvement, positively influencing certain workloads. Increase in backend IOPS is expected to bring benefits in a mixed read/write workload with small IO sizes. Increase in backend bandwidth can be beneficial for non-reducible mixed read/write workloads with high array utilization.

Note: Consider the Everpure Cloud Dedicated V20MP2R2 SKU as an illustrative example for bandwidth consumption. This SKU utilizes the Azure E32bds_v5 VM, which shows the following performance characteristics:

Frontend network bandwidth for Reads: 1.8 GBps (usable)
Backend bandwidth for connections to backend disks: 2.7 GBps (combined for both read and write operations)
Provisioned bandwidth on backend SSDs: 2.5 GBps
Provisioned bandwidth on the two NVRAM disks: 900 MBps

If a non-reducible mixed read/write workload demands 1.8 GBps for reads and 900 MBps for writes, the array experiences a bottleneck at the VM backend due to the following:

User requested reads consume 1.8 GBps from the 2.7 GBps backend bandwidth allocation.
That leaves 900 MBps available for NVRAM write operations, which would be sufficient. However, NVRAM data is eventually flushed to SSDs for persistent storage.
This process involves first reading data from NVRAM and then writing the data to SSDs. Each of these two operations consumes 900 MBps of bandwidth from the total backend allocation.
The total required backend bandwidth becomes 1.8 GBps (user-requested reads) + 900 MBps (user-requested writes) + 900 MBps (flush - reads from NVRAM) + 900 MBps (flush - writes to SSD), totaling 4.5 GBps.
This exceeds the 2.7 GBps of backend bandwidth available with SCSI.

Transitioning to the NVMe backend resolves this bottleneck by providing 4.8 GBps of backend bandwidth. Furthermore, it is important to note this example shows non-reducible workload. Workloads with even a conservative 2:1 data reduction rate become feasible under these conditions.

These NVMe performance gains are also supported by the fact that when NVRAM data is flushed to SSDs, the number of write operations is reduced because the data is coalesced. Furthermore, we have adjusted the backend IO rate limiter on Everpure Cloud Dedicated to account for the performance increase.

However, keep in mind the managed disk configuration (both SSD and NVRAM) remains the same. This ensures the overall cost remains unchanged with this switch. Also, while the NVMe backend may contribute to an increased storage performance capabilities, other limits (such as frontend network bandwidth and IOPS) still apply. For some workloads, these other constraints may be reached before the improvements from the NVMe backend can be fully utilized.

Increased maximum capacity of Everpure Cloud Dedicated V20MP2R2 on Azure

There is now a significant enhancement to the maximum raw capacity achievable with Everpure Cloud Dedicated for Azure V20 arrays utilizing Premium v2 SSDs (V20MP2R2).

Effective with Purity version 6.10.0 and later, the maximum raw capacity for Azure Everpure Cloud Dedicated V20 (V20MP2R2) deployments has been substantially increased from 168 TiB to 308 TiB. This expansion provides greater flexibility and scalability of cloud storage needs, allowing to manage larger datasets and more demanding workloads within a single array.

Important Considerations for Deployment:

New Deployments Only: It is crucial to note that this enhanced capacity is exclusively available for newly deployed arrays running Purity version 6.10.0 or higher. Existing Azure Everpure Cloud Dedicated V20 (V20MP2R2) arrays deployed with earlier Purity versions will not automatically inherit this increased capacity. Customers wishing to leverage the expanded capacity will need to deploy new arrays.

For a comprehensive understanding of the achievable capacity points across various configurations and array types, please refer to the detailed table below. This table provides essential information for planning and optimizing Azure CBS deployments.

Everpure Cloud Dedicated SKU	Purity Version	Type of Deployment	Maximum raw capacity
V10MP2R2	6.8.1 and below	Any	14
V10MP2R2	6.8.2 and above	Any	98
V20MP2R2	6.8.9 and below	New v20	168
		First deployed as a previous version v20
		Controller scaled up from a v10
	6.10.0	New v20	308
		First deployed as a previous version v10 or v20	224
		Controller scaled up from a new 6.10.0 v10	308

New regions available for Azure Everpure Cloud Dedicated with Premium v2 SSDs

This release expands Azure Everpure Cloud Dedicated deployment options to include several new regions supporting Premium v2 SSDs. For a comprehensive list of all available regions, please refer to this article.

Some of these newly added regions are designated as "No-zonal regions," meaning they operate with a single datacenter. Due to inherent architectural differences in these regions, Azure has indicated that Premium v2 SSD performance (throughput and latency) might be lower compared to regions with multiple availability zones.

Everpure's testing of Everpure Cloud Dedicated in No-Zone regions suggests that these regions are best suited for arrays not consistently operating at peak utilization. If utilization remains at or below 70%, the performance impact in no-zone regions is expected to be less severe.

Azure notifies customers about potential performance impacts when they deploy Everpure Cloud Dedicated in no-zone regions.

Newly added regions:

Region	Zones
canadaeast	no-zone
ukwest	no-zone
norwaywest	no-zone
northcentralus	no-zone
westcentraus	no-zone
westus	no-zone
indonesiacentral	2
newzealandnorth	2
polandcentral	3
spaincentral	3
mexicocentral	3

More Restrictive Managed Disks Policies

NetworkAccessPolicy and PublicNetworkAccessTwo Managed Disks policies are now explicitly set to the most restrictive values. There is no impact to customer experience, new settings are automatically applied by upgrading to Purity version 6.10.0 or higher.

Other Everpure Cloud Dedicated improvements

For Everpure Cloud Dedicated on AWS version 6.10.0, the Python version used by Lambda functions is upgraded from version 3.9 to 3.12.

A fix was introduced for Frontend write delay present in versions 6.8.6 and 6.8.7 of Everpure Cloud Dedicated on AWS. You can read more on the issue here.

Other Purity improvements

Please refer to the Purity//FA 6.10.0 Release Notes for detailed information on Purity security updates, improvements, and fixes available in this release.