Recent Discussions
Pure Storage Cloud Dedicated on Azure: An intro to Performance
Introduction With Pure Storage Cloud Dedicated on Microsoft Azure, performance is largely governed by three factors that need to be taken into consideration: front-end controller networking, controller back‑end connection to managed disks, and the Purity data path. This post explains how Azure building blocks and these factors influence overal performance. Disclaimer: This post requires basic understanding of PSC Dedicated architecture. Real-life Performance varies based on configuration and workload; examples here are illustrative. Architecture: the building blocks that shape performance Cloud performance often comes from how compute, storage, and networking are assembled. PSC Dedicated deploys two Azure VMs as storage controllers running the Purity operating environment and uses Azure Managed Disks as persistent media. Initiator VMs connect over the Azure Virtual Network using in‑guest iSCSI or NVMe/TCP. Features like inline data reduction, write coalescing through NVRAM, and an I/O rate limiter help keep the array stable and with predictable performance under saturation. Front-end performance: networking caps Azure limits the outbound (egress) bandwidth of Virtual Machines. Each Azure VM has a certain network egress cap assigned and cannot send out more data than what the limit allows. As PSC Dedicated controllers run on Azure VMs, this translates into the following: Network traffic going INTO the PSC Dedicated array - writes - not throttled by Azure outbound bandwidth limits Network traffic going OUT of the PSC Dedicated array - reads - limited User-requested reads (e.g. from an application) as well as any replication traffic leaving the controller share the same egress budget. Because of that, planning workloads with replication should be done carefully to avoid competing with client reads. Back-end performance: VM caps, NVMe, and the write path The Controller VM caps Similarly to frontend network read throughput, Azure enforces per‑VM limits on total backend IOPS and combined read/write throughput. The overall IOPS/throughput of a VM is therefore limited by the lower of: the controller VM's IOPS/throughput cap and the combined IOPS/throughput of all attached managed disks. To avoid unnecessary spend due to overprovisioning, managed disks of PSC Dedicated arrays are configured as to saturate the controller backend caps just right. NVMe backend raises the ceiling Recent PSC Dedicated releases adopt an NVMe backend on supported Azure Premium SSD v2 based SKUs, increasing the controller VM’s backend IOPS and bandwidth ceilings. The disk layout and economics remain the same while the array gains backend headroom. The write path Purity secures initiator writes to NVRAM (for fast acknowledgment) and later destages to data managed disks. For each logical write, the backend cap is therefore tapped multiple times: a write to NVRAM a read from NVRAM during flush and a write to the data managed disks Under mixed read/write non-reducible workloads this can exhaust the combined read/write backend bandwidth and IOPS of the controller VM. Raised caps of the NVMe backend help here. Workload characteristics: iSCSI sessions and data reducibility Block size and session count Increasing iSCSI session count between Initiator VMs and the array does not guarantee better performance; with large blocks, too many sessions can increase latency without improving throughput, especially when multiple initiators converge on the same controller. Establish at least one session per controller for resiliency, then tune based on measured throughput and latency. Data reduction helps extend backend headroom When data is reducible, PSC Dedicated writes fewer physical bytes to backend managed disks. That directly reduces backend write MBps for the same logical workload, delaying the point where Azure’s VM backend caps are reached. The effect is most pronounced for write‑heavy and mixed workloads. Conversely, non‑reducible data translates almost 1:1 to backend traffic, hitting limits sooner and raising latency at high load. Conclusion Predictable performance in the cloud is about aligning architecture and operations with the platform’s limits. For PSC Dedicated on Azure, that means selecting the right controller and initiator VM SKUs, co‑locating resources to minimise network distance, enabling accelerated networking, and tuning workloads (block size, sessions, protocol) to the caps that actually matter. Inline data reduction and NVMe backend extend headroom meaningfully (particularly for mixed workloads) while Purity’s design keeps the experience consistent. Hopefully, this post was able to shed light on at least some of the performance factors of PSC Dedicated on Azure.PSC Dedicated on Azure - 6.10.x so far
In this post, I though to do a quick look back at the 6.10.x PSC Dedicated on Azure, as we've seen quite a few interesting features be added. Let's start with NVMe-Based Backend. Prior to the 6.10.0 release, Pure Storage 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, PSC 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. 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. NVMe becomes the only supported backend protocol moving onward (6.10.0+), there is no option to revert back to SCSI. Let's also look at the backend Performance Characteristics to better understand the change here. 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. 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 PSC 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. With the switch to NVMe protocol, Azure increases these backend IOPS and bandwidth caps of compatible VMs are raised. This includes the ones used as PSC 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 utilisation. 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. To further extend the performance potential of PSC Dedicated outside of backend limits, in 6.10.2, we've seen an introduction of a brand new SKU, the Azure V50MP2R2. For the new SKU, Azure D128ds v6 virtual machines (VM) were used as controller VMs, along with Premium SSD v2 managed disks. VMs in this class provide up to 6.75 GBps of network egress for read/replication traffic and significantly higher back‑end IOPS and bandwidth for managed disk connectivity. The NVMe back‑end is used by default on the SKU and similarly to current V10 and V20 models, it supports both customer driven non-disruptive Purity upgrades and Controller Scaling (e.g. it is possible to non-disruptively scale to the V50MP2R2 from lower MP2R2 SKUs). At launch, the V50 is available in the following regions: Central US East US East US 2 South Central US Canada Central Canada East Last but not least, 6.10.3 aims to address Azure maintenance or brief infrastructure events, during which the array can experience short-lived increases in I/O latency to backend managed disks. These spikes may be transient yet noticeable by hosts and applications. To harden array behavior against these conditions, PSC Dedicated 6.10.3 on Azure comes with a newly configured set of array-level tunables. These adjust how controllers interpret delayed I/O, coordinate takeovers, and manage internal leases so the array prefers riding out transient backend conditions rather than initiating a controller failover.Using Azure Backup with SQL Server on Azure VM with PSC Dedicated volume
This post details a brief test of Azure Backup for SQL databases. The objective was to evaluate Azure's native backup solution when the SQL Server database, residing on an Azure Virtual Machine, had its data files stored on a Pure Storage Cloud (PSC) Dedicated volume. As a disclaimer, many variations of this test can be done and results may vary, intention here is only to record my recent experience with the technology. The setup I set-up the following environment for the test: PSC Dedicated V20MP2R2 deployed into West Europe region Azure VM Standard D8ds v5 (8 vcpus, 32 GiB memory) running Windows Server 2019 Datacenter gen 2 MS SQL 2019 evaluation edition installed manually on the VM A connection was made between PSC Dedicated and the SQL VM, with MPIO enabled on the VM and one iSCSI session established to each controller. On the PSC Dedicated, I mounted 1TB volume to the host, which I then formatted to NTFS with 64k allocation unit size and mounted as drive F: on the Windows OS. To populate the SQL server with test databases, I made an empty testDB and downloaded 2 sample databases from MS site (AdventureWorks and AdventureWorksLT). The PSC Dedicated volume (F:) was used as the Data Directory of the SQL Server. On the Azure side, Recovery Services Vault (via Backup and Site Recovery from the Marketplace) was created and the VM running the SQL server discovered. The service installs an agent on the VM, enabling it to discover SQL databases instances. Furthermore, an NT Service\AzureWLBackupPluginSvc account used for orchestration of the backup is created on the SQL Server side. The backup For the purpose of the test, I set only a basic policy for all our databases. All three were discovered without issues (along with default ones). Assigning backup policies to databases creates backup items. These can be reviewed on the Azure Portal. Similarly for backup jobs, navigating to the Vault resources allows to review the type of operation (configuration, type of backup etc.) and status. In this case, all completed as scheduled (including an additional manual backup created separately). Another place where it is possible to review the state of the backup is Azure Business Continuity Center. The Restore Testing the restore is a crucial part of any backup, as without that, all we have is a Schrodinger's backup - it might work or it might not. In the testDB I created a small sample table. This only contains a few names as examples. I ran a manual backup of the testDB to capture its current state. Then deleted an item. Bye Bob. Confirmed Bob is gone. Afterwards, I run the restore operation, selecting the manual backup created in the previous step. The restore operation was triggered. And after successful completion, Bob was back. The restore can also be confirmed in the Azure portal. The Summary The testing recorded above indicates the Azures Backup for SQL Server running on Azure VM can be used to discover databases within the SQL instance and help with setting up protection, even if the data resides on an external storage such as Pure Storage Cloud Dedicated. As mentioned in the disclaimer in the beginning of this post however, there may be scenarios that could show different results, so always run tests before committing any decision to production environments.Using Azure Resource Locks with Pure Storage Cloud Dedicated
In any cloud environment, human error is a significant risk to the stability of production systems. A mistaken click in the portal or a misconfigured script can lead to the accidental deletion of critical infrastructure, causing downtime and potential data loss. This is the exact problem that Azure Resource Locks are designed to solve. Think of them as a simple but powerful safety net for your most important Azure resources. When applied to a Pure Storage Cloud Dedicated (PSC Dedicated) managed application, these locks are an essential governance tool. A PSC Dedicated array isn't a single resource but rather a collection of virtual machines, managed disks, and network components working together. Accidentally deleting or altering any part of this managed application could compromise the entire storage array and the applications that rely on it. By applying a lock, you create an intentional barrier, forcing administrators to consciously remove it before making a destructive change. This simple step helps safeguard your mission-critical data, prevent service interruptions, and ensure the operational integrity of your storage environment. Understanding Azure Resource Locks A resource lock prevents users from accidentally deleting or modifying your Azure resources. Even users with the Owner role for a subscription cannot delete or modify a resource if it has a lock applied. There are two main types of resource locks: CanNotDelete (often shown as Delete in the Azure Portal): This lock means that authorized users can still read and modify a resource, but they can't delete it. This is the recommended lock level for the PSC Dedicated managed application. ReadOnly: This lock is more restrictive. Authorized users can only read a resource; they cannot modify or delete it. This lock is generally not recommended for PSC Dedicated, as it can interfere with normal management and scaling operations performed by the Pure Storage support team or by automated processes. Please refer to the Microsoft Learn documentation for more information. How to Apply a Lock to Your PSC Dedicated Managed Application While you can apply locks to individual resources, the best practice for PSC Dedicated is to apply the lock to the entire managed resource group. This ensures all components are protected. Method 1: Using the Azure Portal (The Easiest Way) Navigate to your PSC Dedicated Managed Application: In the Azure Portal, search for and select your Pure Storage Cloud Dedicated instance. Go to the Locks Blade: In the left-hand menu for your PSC Dedicated resource, find and click on Locks. Add a New Lock: Click the + Add button at the top of the Locks blade. Configure the Lock: Lock name: Give your lock a descriptive name (e.g., PSCDedicated-DoNotDelete-Lock). Lock type: Select Delete. Notes: It's a good practice to add a note explaining why the lock is in place. Save the Lock: Click OK to apply the lock to your managed application. Review the Lock is in place Try to delete the PSC Dedicated managed application See that an error message appears, confirming the Lock is in place and does prevent accidental deletion of the Managed application of the PSC Dedicated array Method 2: Using Azure PowerShell For those who prefer a command-line interface, Azure PowerShell provides a straightforward way to manage locks. To apply the lock using Azure PowerShell, use the New-AzResourceLock cmdlet. You will need the following information: New-AzResourceLock -LockName "PSCDedicatedLock" ` -LockLevel CanNotDelete ` -ResourceName "YourPSCDedicatedInstanceName" ` -ResourceType "Microsoft.Solutions/applications" ` -ResourceGroupName "YourApplicationResourceGroup" To remove the lock later, you can use the Remove-AzResourceLock command. Method 3: Using Azure CLI The Azure Command-Line Interface (CLI) is another popular method for managing Azure resources. The process here would be: az lock create --name "PSCDedicatedLock" \ --lock-type "CanNotDelete" \ --resource-group "YourApplicationResourceGroup" \ --resource-name "YourPSCDedicatedInstanceName" \ --resource-type "Microsoft.Solutions/applications" \ --notes "Prevent accidental deletion of PSC Dedicated Managed Application" To remove the lock, you would use the az lock delete command. Final Thoughts Applying an Azure Resource Lock is a simple, no-cost action that adds a powerful layer of protection to your Pure Storage Cloud Dedicated deployment. It's a fundamental step in good cloud governance that helps ensure your critical storage infrastructure remains secure and available. By taking a few moments to configure a CanNotDelete lock, you can prevent a costly mistake and maintain the operational integrity of your environment.Pure Cloud Block Store is now Pure Storage Cloud Dedicated (PSC Dedicated)
Pure Storage Cloud Dedicated: Name Change, Same Enterprise-Grade Experience Pure Storage Cloud is an enterprise-grade block storage delivered as a service in the public cloud. It extends the data services and evergreen architecture of the Purity operating system and can be deployed in: Azure as a fully managed native service or a customer-managed service integrated with Azure VMware Solution (AVS) AWS as a customer-managed service integrated with Elastic VMware Service (EVS) What’s New? Pure Cloud Block Store, the customer-managed service, is being renamed Pure Storage Cloud Dedicated (PSC Dedicated). This change reflects its integration into the Pure Storage Cloud family and alignment with the Enterprise Data Cloud strategy. What’s Not Changing? Everything That Matters Your experience, performance, and features remain the same. Pure Storage Cloud Dedicated continues to provide: Enterprise Data Services: Purity software in Azure and AWS, with data reduction, thin provisioning, and snapshots. Cost Efficiency: Optimized storage usage and reduced footprint through data reduction. Reliability & Resilience: Built-in redundancy, high availability, and cyber resilience. Hybrid & Multi-Cloud Mobility: Consistent APIs and replication across FlashArrays and PSC Dedicated for migration, DR, and data mobility. Disaster Recovery & Backup: Asynchronous and near-synchronous replication, plus snapshots for cost-effective backup and rapid recovery. VMware Workload Support: Enterprise-grade storage for VMware in AVS and EVS environments. Why This Matters The shift from Pure Cloud Block Store to Pure Storage Cloud Dedicated unifies offerings under the Pure Storage Cloud umbrella while advancing the broader Enterprise Data Cloud strategy.Accelerate Breakout Replay: Seamless VMware Workloads in AWS with Elastic VMware Service and Pure Cloud Block Store™
Discover how EVS & Pure Cloud Block Store™ bring VMware to the cloud with operational consistency and new workload opportunities. Speakers: Pavel Kovar Ron Wedel, AWS https://www.purestorage.com/video/webinars/seamless-vmware-workloads-in-aws-with-elastic/6375806872112.htmlAccelerate Breakout Replay: From Data Center to Azure: Seamless VMware Migrations Unleashed with Pure Storage Cloud
Learn how Pure Storage Azure-native service simplifies AVS migration with elastic storage, unified management, and FinOps-friendly scaling. Speakers: Vaclav Jirovsky Husam Hilal, MSFT Joe Ervolino, Dupaco https://www.purestorage.com/video/webinars/from-data-center-to-azure-seamless-vmware-migrations-unleashed/6375801044112.htmlPurely Cloud Podcast - CBS on Azure Technical Deep Dive
Together with vjirovsky we hosted a podcast episode where we discussed CBS on Azure architecture and best practices. Have a listen here: https://soundcloud.com/user-917746545/purely-cloud-guest-series-cbs-on-azure-technical-deep-dive-and-deployment-best-practicesUse CBS as persistent storage on AKS via Portworx CSI driver
Hi all, with the recent version of Portworx CSI driver (v25.4.0) you can mount a persistent block volume on CBS into your containers on Kubernetes and utilize all features and benefits of CBS. Sharing my recent blog post, how to set it up on Azure Kubernetes Service (AKS): https://blog.vjirovsky.cz/portworx-csi-with-aks-with-cbs/
