Configure the NFS Backend on Cinder-Backup¶

You can configure the cinder-backup service to use a remote external NFS server as backend.

Prerequisites

Ensure you have the following:

the openstack application already applied or uploaded to StarlingX OpenStack
the remote NFS server is up and running
the remote NFS server IP address or domain are known
the remote NFS server can be reached from inside the OpenStack cluster where StarlingX OpenStack is running

Follow these steps to perform the configuration.

Procedure

Create a Helm user override configuration file for Cinder.

The following is a sample configuration for NFS backend:

conf:
  cinder:
    DEFAULT:
      backup_driver: cinder.backup.drivers.nfs.NFSBackupDriver
      backup_mount_point_base: /backup/             # NFS volume mount point
      backup_share: 10.10.20.2:/exports/backup/     # NFS server IP address and exported directory
pod:
 mounts:
    cinder_backup:
      cinder_backup:
        volumeMounts:
        - mountPath: /backup
          name: nfs-backup
        volumes:
        - emptyDir: {}
          name: nfs-backup
  security_context:
      cinder_backup:
        container:
          cinder_backup:
            readOnlyRootFilesystem: false
            runAsGroup: 65534    # nogroup GID, must match the backup share group owner
            runAsUser: 42425     # cinder UID

For other options for configuring NFS backend on cinder-backup, see: NFS Backup Driver.

The following commands are used for updating the Cinder Helm Chart overrides for StarlingX OpenStack:
1. Update the Helm Chart overrides for Cinder:
```
~(keystone_admin)]$ system helm-override-update stx-openstack cinder openstack --values=<path/to/override/file>
```
2. Show the updated Helm Chart overrides for Cinder:
```
~(keystone_admin)$ system helm-override-show stx-openstack cinder openstack
```
The following commands are used to apply the updated Helm Chart overrides:
1. Apply updated Helm Chart overrides:
```
~(keystone_admin)$ system application-apply stx-openstack
```
2. Wait for the application apply to complete:
```
~(keystone_admin)$ watch system application-show stx-openstack
```
Verify that the Cinder services are up and running:
1. Set the CLI context to the StarlingX OpenStack Cloud Application and set up OpenStack admin credentials:
```
~(keystone_admin)]$ sed '/export OS_AUTH_URL/c\export OS_AUTH_URL=http://keystone.openstack.svc.cluster.local/v3' /etc/platform/openrc > ~/openrc.os
~(keystone_admin)]$ source ./openrc.os
```
2. Show the OpenStack volume service:
```
~(keystone_admin)]$ openstack volume service list
```
For more information on how to access the OpenStack CLI, see documentation at: Access StarlingX Openstack.

Note

The exported directory used for backups must grant write access to the UID or GID the cinder-backup container runs as, and it must do so before the first backup is attempted. Determine that identity with:

$ kubectl -n openstack exec deploy/cinder-backup -c cinder-backup -- id

Read the ownership and mode of the export root from a client mount, with numeric ids:

$ sudo mount -t nfs4 <NFS_SERVER>:/<EXPORT_PATH> /tmp/shared_volume
$ ls -lan /tmp/shared_volume/

Read it from a client mount rather than from inside the container. NFS identity mapping can make the mount root appear inside the container to be owned by the group the container runs as, while the server-side owner is different.

Configure the NFS Backend on Cinder-Backup

Configure the NFS Backend on Cinder-Backup¶

StarlingX