SkinnySnaps in OpenShift with FlashArray
Summary and Key concepts
Summary This article introduces Portworx SkinnySnaps, a feature that allows users to optimize storage performance by configuring the number of snapshot replicas independently from the number of volume replicas. The default snapshot behavior retains a high replication factor for snapshots, which can impact I/O performance during deletion. SkinnySnaps, on the other hand, reduce the number of snapshot replicas, leading to performance improvements but at the cost of high availability (HA). The article explains how to enable SkinnySnaps, configure the replication factor, and restore SkinnySnaps using in-place restores or cloning. Additionally, best practices for balancing performance and durability are discussed.
Kubernetes Concepts
- PersistentVolumeClaim (PVC): Portworx snapshots apply to PVCs, and the article shows how to manage snapshot replication factors in relation to these volumes.
- StorageClass: Users can configure SkinnySnaps behavior at the cluster level, which affects how snapshots are managed in relation to Kubernetes volumes.
Portworx Concepts
- pxctl Command: Used to enable and configure SkinnySnaps, such as setting the replication factor and managing cluster-wide options.
Portworx SkinnySnaps provide you with a mechanism for controlling how your cluster takes and stores volume snapshots. This allows you to optimize performance by configuring how many snapshot replicas your cluster stores independently from the number of volume replicas you have.
Default snapshot behavior
Regular snapshots take volume snapshots for each volume replica up to the retain limit.
Consider the following example:
- You're using a 3 node cluster
- You have a repl3 volume on that cluster with a retain of 3
This means that:
- You have one volume replica on each node
- each volume replica has all (3) accompanying snapshots
When Portworx reaches the limit of the snapshot retain policy, it replaces the oldest snapshot with the newest: