Skip to main content
Version: 3.1

create-pvc-create-sharedv4-pvcs

This document describes how to use Portworx sharedv4 (ReadWriteMany) volumes in your cluster.

Portworx provides two types of sharedv4 features:

  • Sharedv4 volumes
  • Sharedv4 service volumes

Prerequisites​

  • Sharedv4 volumes must be enabled on your cluster. Portworx sharedv4 volumes are enabled by default.

Provision a sharedv4 Volume​

Sharedv4 volumes are useful when you want multiple PODs to access the same PVC (volume) at the same time. They can use the same volume even if they are running on different hosts. They provide a global namespace and the semantics are POSIX compliant.

To increase fault tolerance, you can enable sharedv4 service volumes by setting a value for sharedv4_svc_type. With this feature enabled, every sharedv4 volume has a Kubernetes service associated with it. Sharedv4 service volumes expose the volume via a Kubernetes service IP. If the sharedv4 (NFS) server goes offline for a sharedv4 service volume and the volume requires a failover, only application pods that were running on the 2 nodes involved in failover need to be restarted.

note

Notes about sharedv4 and sharedv4 service volumes:

  • A sharedv4 volume is created if and only if the PVC access mode is ReadWriteMany or ReadOnlyMany. The "sharedv4" setting in the storageClass does not matter. In other words, if an app expects a sharedv4 volume while using a ReadWriteOnce PVC, some of the pods may fail to start. The PVC will have to be modified to use ReadWriteMany or ReadOnlyMany access mode.
  • Sharedv4 service volumes are intended for use within your cluster where the volume resides.
  • Sharedv4 service volumes default to using NFSv version 4.0.
  • Sharedv4 (non-service) volumes default to using NFS version 3.
  • Sharedv4 service volumes are not supported on Portworx clusters using Metro DR.
  • On failover, applications may receive an error for non idempotent requests. For example, if an mkdir call is issued prior to failover, the client can resend it to the new server, which returns an EEXIST error if the directory was created by the first call.

Step 1: Create a StorageClass​

Step 2: Create a persistent volume claim​

Step 3: Create pods which use the persistent volume claim​

Convert a sharedv4 volume to a sharedv4 service volume​

Perform the following steps to convert a sharedv4 volume to use the new sharedv4 service feature:

  1. Detach the volume by scaling the application pods down to 0.
  2. Run the following pxctl command:
pxctl volume update --sharedv4_service_type=ClusterIP <volume>
  1. Scale the deployment back up to start the application.

Convert a sharedv4 service volume to a sharedv4 volume​

Perform the following steps to convert a sharedv4 service volume to a sharedv4 volume:

  1. Detach the volume by scaling the application pods down to 0.
  2. Run the following pxctl command:
pxctl volume update --sharedv4_service_type="" <volume>
  1. Scale the deployment back up to start the application.

Convert an existing sharedv4 service volume to prefer remote nodes only​

  1. Scale down the application pods.

  2. Run the following command to convert the volume to use preferRemoteNodeOnly:

    pxctl volume update --label stork.libopenstorage.org/preferRemoteNodeOnly="true" <volume>

  3. Scale the pods back up to start the application.

Convert an existing sharedv4 service volume to prefer local nodes​

  1. Scale down the application pods.

  2. Run the following pxctl command to convert the volume to use preferRemoteNode:

    pxctl volume update --label stork.libopenstorage.org/preferRemoteNode="false" <volume>

  3. Scale the pods back up to start the application.

Update a legacy shared volume to a sharedv4 volume​

You can convert an existing shared volume (deprecated) to a sharedv4 volume. Run the following command to update the volume setting:

pxctl volume update --sharedv4=on <volume>

Last updated on