Storage classes define how OpenShift and Portworx present storage behavior to workloads. In a FlashArray-backed environment, they are the main abstraction that determines performance, availability, replication behavior, snapshot handling, and backend placement. For virtualization administrators, they are the closest equivalent to combining a datastore selection with a storage policy.
Creating Storage Classes for Specific Use Cases
Storage classes should be designed around workload intent, not just around available storage capacity. A VM boot disk, a latency-sensitive database volume, a general-purpose application PVC, and a replicated DR-backed workload should not all be treated the same if the backend supports better policy alignment.
This task is used to:
create repeatable storage policies for common workload types
simplify workload placement for administrators and application teams
standardize protection and performance expectations
Designing StorageClasses
| Workload Category | Storage Class Consideration |
| VM boot disks | Consistent provisioning performance, predictable sizing, reclaim governance |
| VM data disks | Throughput and IOPS alignment, snapshot scheduling, expansion support |
| General-purpose application PVCs | Broad compatibility, safe defaults, manageable cost profile |
| High-availability workloads | Synchronous replication consideration, ActiveCluster candidate |
| DR-oriented workloads | Near-zero RPO, ActiveDR candidate, failover validation requirement |
| Snapshot-heavy workloads | Snapshot scheduling and retention integration, clone efficiency |
| Performance-sensitive workloads | Low-latency profile, backend array targeting, QoS consideration |
ActiveCluster Storage Class
An ActiveCluster-backed storage class is intended for workloads that require zero RPO across sites or arrays using synchronous replication. This class should be reserved for workloads whose business requirement justifies the operational overhead and backend design needed for synchronous behavior.
When to use ActiveCluster-backed storage
Use this storage class when:
the workload requires zero RPO
synchronous replication is part of the service objective
site-level resilience is required
the workload can tolerate the architecture and placement requirements of synchronous protection
ActiveDR Storage Class
An ActiveDR-backed storage class is designed for workloads that need near-zero RPO but do not require synchronous replication semantics. This can be appropriate for many enterprise workloads where very low data loss tolerance is required without the constraints of a full synchronous design.
ActiveDR-backed storage
Use this class when:
very low RPO is required
asynchronous protection is acceptable
DR readiness is more important than immediate cross-site active operation
Operational considerations and failover expectations
When using ActiveDR-backed storage, confirm:
the workload is placed on the intended class
administrators understand the difference between near-zero RPO and zero RPO
DR procedures are documented
periodic failover validation is scheduled
Standard Snapshot Tier Storage Class
A standard snapshot-oriented storage class is useful when point-in-time recovery, clone workflows, and operational rollback are more central to the workload than synchronous or DR replication behavior. This class is often appropriate for:
development and test workloads
rollback-sensitive application tiers
VM templates and golden images
workloads that depend heavily on cloning or point-in-time restore.
Targeting Specific Arrays
In some designs, allowing Portworx to place workloads automatically is sufficient. In others, administrators need tighter control over which backend FlashArray serves a workload. This may be driven by locality, performance isolation, regulatory boundaries, replication design, or service-level segmentation.
This task is used to:
Direct specific workloads to selected FlashArray backends
Separate workload classes by backend policy
Align workloads with physical or logical protection domains
Reduce unpredictable placement for high-priority services
Placement Strategy Considerations
When targeting specific arrays, define placement rules based on:
business criticality
site or array locality
protection model
latency sensitivity
Array targeting should be intentional and documented. It should not rely on tribal knowledge.
PVC Expansion
Expanding a PVC is a common Day 2 task as VM disks and application volumes grow over time. In a policy-driven environment, expansion should be routine, controlled, and validated.
Operational workflow for expanding PVCs
In the OpenShift web console, go to Storage > PersistentVolumeClaims.
Select the namespace containing the PVC.
Open the PVC details page.
Use the edit action to increase the requested size if the storage class supports expansion.
Save the change.
Monitor the PVC until the new size is reflected.
If the PVC backs a VM, verify the guest operating system recognizes the expanded capacity as expected.
Application and filesystem considerations
Storage expansion does not always complete entirely at the infrastructure layer. Some workloads and guest operating systems may also require in-guest or application-aware resize handling. Administrators should validate end-to-end, not just PVC size in the console.
Reclaim Policy Management
Reclaim policy determines what happens to backend storage assets when PVCs are deleted. This is one of the most important governance controls in a platform that supports both virtual machines and containerized workloads.
| Use Delete when: | Use Retain when: |
|
|