Rechercher
SupportConsoleDéveloppeursCommencer un essaiContact

Ce contenu n'est pas disponible dans la langue sélectionnée.

Chapter 7. Configuring the Shared File Systems service (manila)

download PDF

When you deploy the Shared File Systems service (manila), you can choose one or more supported back ends, such as native CephFS, CephFS-NFS, NetApp, and others.

For a complete list of supported back-end appliances and drivers, see the Manila section of the Red Hat Knowledge Article, Component, Plug-In, and Driver Support in Red Hat OpenStack Platform.

Prerequisites

  • You have the oc command line tool installed on your workstation.
  • You are logged on to a workstation that has access to the RHOSO control plane as a user with cluster-admin privileges.
  • For native CephFS or CephFS-NFS, a CephFS file system must exist on the Red Hat Ceph Storage cluster. For more information, see Integrating Red Hat Ceph Storage.
  • For native CephFS or CephFS-NFS, a Ceph user must exist that has CephX capabilities (caps) to perform operations on the CephFS file system. For more information, see Integrating Red Hat Ceph Storage.
  • For CephFS-NFS only, a ceph nfs service must exist in the Ceph Storage cluster. For more information, see Integrating Red Hat Ceph Storage.
  • For back ends where driver_handles_share_servers=false, you configure the networking in advance rather than dynamically in the back end for the Shared File Systems service.
  • For a CephFS-NFS back end, you create an isolated StorageNFS network for NFS exports and a corresponding StorageNFS shared provider network in the Networking service (neutron). The StorageNFS shared provider network maps to the isolated StorageNFS network of the data center.

  • Ensure that the NFS service is isolated on a network that you can share with all Red Hat OpenStack Services on OpenShift (RHOSO) users. For more information about customizing the NFS service, see NFS cluster and export management in the Red Hat Ceph Storage File System Guide.

    Important

    When you deploy an NFS service for the Shared File Systems service, do not select a custom port to expose NFS. Only the default NFS port of 2049 is supported. You must enable the Red Hat Ceph Storage ingress service and set the ingress-mode to haproxy-protocol. Otherwise, you cannot use IP-based access rules with the Shared File Systems service. For security in production environments, Red Hat does not recommend providing access to 0.0.0.0/0 on shares to mount them on client machines.

7.1. Configuring a native CephFS back end

You can configure the Shared File Systems service (manila) with native CephFS as the storage back end.

Limitations

You can expose a native CephFS back end to trusted users, but take the following security measures:

  • Configure the storage network as a provider network.
  • Apply role-based access control (RBAC) policies to secure the storage provider network.
  • Create a private share type.

Prerequisites

  • An isolated storage network.
  • Ensure network connectivity between the storage back end, the Red Hat OpenShift cluster, and the Compute nodes.
  • You have created a Red Hat Ceph Storage secret. For more information, see Integrating Red Hat Ceph Storage

Procedure

  1. Open your OpenStackControlPlane CR file, openstack_control_plane.yaml, and add the extraMounts parameter in the spec section to present the Ceph configuration files: 

    apiVersion: core.openstack.org/v1beta1
kind: OpenStackControlPlane
spec:
  extraMounts:
    - name: v1
      region: r1
      extraVol:
        - propagation:
          - ManilaShare
          extraVolType: Ceph
          volumes:
          - name: ceph
            projected:
              sources:
              - secret:
                  name: <ceph-conf-files>
          mounts:
          - name: ceph
            mountPath: "/etc/ceph"
            readOnly: true

  2. Add the following parameters to the manila template to configure the native CephFS back end: 

    apiVersion: core.openstack.org/v1beta1
kind: OpenStackControlPlane
spec:
    ...
  manila:
    enabled: true
    template:
      manilaAPI:
        replicas: 3
        customServiceConfig: |
          [DEFAULT]
          debug = true
          enabled_share_protocols=cephfs
      manilaScheduler:
        replicas: 3
      manilaShares:
        cephfsnative:
          replicas: 1
          networkAttachments:
          - storage
          customServiceConfig: |
              [DEFAULT]
              enabled_share_backends=cephfs
              [cephfs]
              driver_handles_share_servers=False
              share_backend_name=cephfs
              share_driver=manila.share.drivers.cephfs.driver.CephFSDriver
              cephfs_conf_path=/etc/ceph/ceph.conf
              cephfs_auth_id=openstack
              cephfs_cluster_name=ceph
              cephfs_volume_mode=0755
              cephfs_protocol_helper_type=CEPHFS
...

  3. Update the control plane: 

    $ oc apply -f openstack_control_plane.yaml -n openstack

  4. Wait until RHOCP creates the resources related to the OpenStackControlPlane CR. Run the following command to check the status: 

    $ oc get openstackcontrolplane -n openstack

    The OpenStackControlPlane resources are created when the status is "Setup complete".

    Tip

    Append the -w option to the end of the get command to track deployment progress.

7.2. Configuring a CephFS-NFS back end

You can configure the Shared File Systems service (manila) with CephFS-NFS as the storage back end.

Prerequisites

  • The isolated storage network is configured on the share manager pod on OpenShift so that the Shared File Systems service can communicate with the Red Hat Ceph Storage cluster.
  • For NFS traffic, Red Hat recommends using an isolated NFS network. This network does not need to be available to the share manager pod for the Shared File Systems service on OpenShift, but it must be available to Compute instances owned by end users.
  • Ensure network connectivity between the storage back end, the Red Hat OpenShift cluster, and the Compute nodes.

Procedure

  1. Open your OpenStackControlPlane CR file, openstack_control_plane.yaml, and add the following parameters to the manila template: 

    apiVersion: core.openstack.org/v1beta1
kind: OpenStackControlPlane
spec:
    ...
  manila:
    enabled: true
    template:
      manilaAPI:
        replicas: 3
        customServiceConfig: |
          [DEFAULT]
          debug = true
          enabled_share_protocols=nfs
      manilaScheduler:
        replicas: 3
      manilaShares:
        share1:
          customServiceConfig: |
              [DEFAULT]
              enabled_share_backends=cephfsnfs
              [cephfsnfs]
              driver_handles_share_servers=False
              share_backend_name=cephfs
              share_driver=manila.share.drivers.cephfs.driver.CephFSDriver
              cephfs_auth_id=openstack
              cephfs_cluster_name=ceph
              cephfs_nfs_cluster_id=cephfs
              cephfs_protocol_helper_type=NFS
...

  2. Update the control plane: 

    $ oc apply -f openstack_control_plane.yaml -n openstack

  3. Wait until RHOCP creates the resources related to the OpenStackControlPlane CR. Run the following command to check the status: 

    $ oc get openstackcontrolplane -n openstack

    The OpenStackControlPlane resources are created when the status is "Setup complete".

    Tip

    Append the -w option to the end of the get command to track deployment progress.

7.3. Configuring alternative back ends

To configure the Shared File Systems service (manila) with an alternative back end, for example, NetApp or Pure Storage, complete the following high level tasks:

  1. Create the server connection secret.
  2. Configure the OpenStackControlPlane CR to use the alternative storage system as the back end for the Shared File Systems service.

Prerequisites

  • You have prepared the alternative storage system for consumption by Red OpenStack Services on OpenShift (RHOSO).
  • Network connectivity between the Red Hat OpenShift cluster, the Compute nodes, and the alternative storage system.

7.3.1. Creating the server connection secret

Create a server connection secret for an alternative back end to prevent placing server connection information directly in the OpenStackControlPlane CR.

Procedure

  1. Create a configuration file that contains the server connection information for your alternative back end. In this example, you are creating the secret for a NetApp back end.

    The following is an example of the contents of a configuration file: 

    [netapp]
netapp_server_hostname = <netapp_ip>
netapp_login = <netapp_user>
netapp_password = <netapp_password>
netapp_vserver = <netappvserver>
    • Replace <netapp_ip> with the IP address of the server.
    • Replace <netapp_user> with the login user name.
    • Replace <netapp_password> with the login password.
    • Replace <netappvserver> with the vserver name. You do not need this option if configuring the driver_handles_share_servers=True mode.
  2. Save the configuration file.

  3. Create the secret based on the configuration file:

    $ oc create secret generic <secret_name> --from-file=<configuration_file_name>

    • Replace <secret_name> with the name you want to assign to the secret.
    • Replace <configuration_file_name> with the name of the configuration file you created.
  4. Delete the configuration file.

7.3.2. Configuring an alternative back end

You can configure the Shared File Systems service (manila) with an alternative storage back end, for example, a NetApp back end.

Prerequisites

  • Ensure network connectivity between the storage back end, the Red Hat OpenShift cluster, and the Compute nodes.

Procedure

  1. Open your OpenStackControlPlane CR file, openstack_control_plane.yaml, and add the following parameters to the manila template: 

    apiVersion: core.openstack.org/v1beta1
kind: OpenStackControlPlane
spec:
    ...
    manila:
    enabled: true
    template:
      manilaAPI:
        replicas: 3
        customServiceConfig: |
          [DEFAULT]
          debug = true
          enabled_share_protocols=cifs
      manilaScheduler:
        replicas: 3
      manilaShares:
        share1:
          networkAttachments:
          - storage
          customServiceConfigSecrets:
          - manila_netapp_secret
          customServiceConfig: |
            [DEFAULT]
            debug = true
            enabled_share_backends=netapp
            [netapp]
       driver_handles_share_servers=False
            share_backend_name=netapp
            share_driver=manila.share.drivers.netapp.common.NetAppDriver
            netapp_storage_family=ontap_cluster
...

  2. Update the control plane: 

    $ oc apply -f openstack_control_plane.yaml -n openstack

  3. Wait until RHOCP creates the resources related to the OpenStackControlPlane CR. Run the following command to check the status: 

    $ oc get openstackcontrolplane -n openstack

    The OpenStackControlPlane resources are created when the status is "Setup complete".

    Tip

    Append the -w option to the end of the get command to track deployment progress.

7.3.3. Custom configuration files

When you configure an alternative back end for the Shared File Systems service (manila), you might need to use additional configuration files. You can use the extraMounts parameter in your OpenStackControlPlane CR file to present these configuration files as OpenShift configMap or secret objects in the relevant share manager pod.

Example: 

apiVersion: core.openstack.org/v1beta1
kind: OpenStackControlPlane
spec:
...
  extraMounts:
    - name: v1
      region: r1
      extraVol:
        - propagation:
          - sharepod1
          extraVolType: Undefined
          volumes:
          - name: backendconfig
            projected:
              sources:
              - secret:
                  name: manila-sharepod1-secrets
          mounts:
          - name: backendconfig
            mountPath: /etc/manila/drivers
            readOnly: true
...

7.3.4. Custom storage driver images

When you configure an alternative back end for the Shared File Systems service (manila), you might need to use a custom manilaShares container image from the vendor on the Red Hat Ecosystem Catalog. You can add the path to the container image to your OpenStackControlPlane CR file to use it in the relevant share manager pod.

Example: 

apiVersion: core.openstack.org/v1beta1
kind: OpenStackControlPlane
spec:
  manila:
    template:
      manilaShares:
        pure-storage:
          networkAttachments:
          - storage
          containerImage: image-registry.openshift-image-registry.svc:5000/openshift/manila-share-pure:oso18
...

7.4. Configuring multiple back ends

You can deploy multiple back ends for the Shared File Systems service (manila), for example, a CephFS-NFS back end, a native CephFS back end, and a third-party back end. Add one back end only per pod.

Prerequisites

  • When you use a back-end driver from a storage vendor that requires external software components, you must override the standard container image for the Shared File Systems service during deployment. You can find custom container images, for example, the Dell EMC Unity container image for a Dell EMC Unity storage system, at Red Hat Ecosystem Catalog.
  • Ensure network connectivity between the storage back end, the Red Hat OpenShift cluster, and the Compute nodes.

Procedure

  1. Open your OpenStackControlPlane CR file, openstack_control_plane.yaml, and add the following parameters to the manila template to configure the back ends. In this example, there is a CephFS-NFS back end, a native CephFS back end, and a Pure Storage back end: 

    apiVersion: core.openstack.org/v1beta1
kind: OpenStackControlPlane
spec:
    ...
      manila:
            enabled: true
            template:
              manilaAPI:
                replicas: 3
                customServiceConfig: |
                  [DEFAULT]
                  debug = true
                  enabled_share_protocols=nfs,cephfs,cifs
              manilaScheduler:
                replicas: 3
...

  2. Add the configuration for each back end you want to use:

    • Add the configuration for the CephFS-NFS back end: 

          ...
        customServiceConfig: |
        ...
        manilaShares:
          cephfsnfs:
            networkAttachments:
            - storage
            customServiceConfig: |
                [DEFAULT]
                enabled_share_backends=cephfsnfs
                [cephfsnfs]
                driver_handles_share_servers=False
                share_backend_name=cephfs
                share_driver=manila.share.drivers.cephfs.driver.CephFSDriver
                cephfs_auth_id=openstack
                cephfs_cluster_name=ceph
                cephfs_nfs_cluster_id=cephfs
                cephfs_protocol_helper_type=NFS
            replicas: 1
     ...

    • Add the configuration for the native CephFS back end: 

          ...
        customServiceConfig: |
        ...
        manilaShares:
          cephfsnfs:
          ...
          cephfs:
            networkAttachments:
            - storage
            customServiceConfig: |
                [DEFAULT]
                enabled_share_backends=cephfs
                [cephfs]
                driver_handles_share_servers=False
                share_backend_name=cephfs
                share_driver=manila.share.drivers.cephfs.driver.CephFSDriver
                cephfs_conf_path=/etc/ceph/ceph.conf
                cephfs_auth_id=openstack
                cephfs_protocol_helper_type=CEPHFS
            replicas: 1
      ...

    • Add the configuration for the Pure Storage back end: 

          ...
        customServiceConfig: |
        ...
        manilaShares:
          cephfsnfs:
          ...
          cephfs:
          ...
          pure:
            containerImage: image-registry.openshift-image-registry.svc:5000/openshift/manila-share-pure:oso18
            networkAttachments:
            - storage
            customServiceConfigSecret: |
            - manila-pure-secret
            customServiceConfig: |
              [DEFAULT]
              debug = true
              enabled_share_backends=pure
              [pure]
              driver_handles_share_servers=False
              share_backend_name=pure
              share_driver=manila.share.drivers.purestorage.flashblade.FlashBladeShareDriver
  ...

  3. Update the control plane: 

    $ oc apply -f openstack_control_plane.yaml -n openstack

  4. Wait until RHOCP creates the resources related to the OpenStackControlPlane CR. Run the following command to check the status: 

    $ oc get openstackcontrolplane -n openstack

    The OpenStackControlPlane resources are created when the status is "Setup complete".

    Tip

    Append the -w option to the end of the get command to track deployment progress.

7.5. Confirming deployment of multiple back ends

Use the openstack share service list command to verify that the storage back ends for the Shared File Systems service (manila) deployed successfully. If you use a health check on multiple back ends, a ping test returns a response even if one of the back ends is unresponsive, so this is not a reliable way to verify your deployment.

Procedure

  1. Access the remote shell for the OpenStackClient pod from your workstation: 

    $ oc rsh -n openstack openstackclient

  2. Confirm the list of Shared File Systems service back ends: 

    $ openstack share service list

    The status of each successfully deployed back end shows as enabled and the state shows as up.

  3. Exit the openstackclient pod: 

    $ exit

7.6. Creating availability zones for back ends

You can create availability zones (AZs) for Shared File Systems service back ends to group cloud infrastructure and services logically for users. Map the AZs to failure domains and compute resources for high availability, fault tolerance, and resource scheduling. For example, you can create an AZ of Compute nodes that have specific hardware that users can specify when they create an instance that requires that hardware.

Post deployment, use the availability_zones share type extra specification to limit share types to one or more AZs. Users can create a share directly in an AZ as long as the share type does not restrict them.

Procedure

The following example deploys two back ends where CephFS is zone 1 and NetApp is zone 2.

  1. Open your OpenStackControlPlane CR file, openstack_control_plane.yaml, and add the following parameters to the manila template: 

    apiVersion: core.openstack.org/v1beta1
kind: OpenStackControlPlane
spec:
    ...
  manila:
    enabled: true
    template:
      manilaShares:
        cephfs:
          customServiceConfig: |
            [cephfs]
            backend_availability_zone = zone_1
          ...
        netapp:
          customServiceConfig: |
            [netapp]
            backend_availability_zone = zone_2
          ...

  2. Update the control plane: 

    $ oc apply -f openstack_control_plane.yaml -n openstack

  3. Wait until RHOCP creates the resources related to the OpenStackControlPlane CR. Run the following command to check the status: 

    $ oc get openstackcontrolplane -n openstack

    The OpenStackControlPlane resources are created when the status is "Setup complete".

    Tip

    Append the -w option to the end of the get command to track deployment progress.

7.7. Changing the allowed NAS protocols

You can use the Shared File Systems service (manila) to export shares in the NFS, CephFS, or CIFS network attached storage (NAS) protocols. By default, the Shared File Systems service enables NFS and CIFS, and this may not be supported by the back ends in your deployment.

You can change the enabled_share_protocols parameter and list only the protocols that you want to allow in your cloud. For example, if back ends in your deployment support both NFS and CIFS, you can change the default value and enable only one protocol. The NAS protocols that you assign must be supported by the back ends in your Shared File Systems service deployment.

Not all storage back-end drivers support the CIFS protocol. For information about which certified storage systems support CIFS, see the Red Hat Ecosystem Catalog.

Procedure

  1. Open your OpenStackControlPlane CR file, openstack_control_plane.yaml, and add the following parameters to the manila template. In this example, you enable the NFS protocol: 

    apiVersion: core.openstack.org/v1beta1
kind: OpenStackControlPlane
spec:
    ...
      manila:
        enabled: true
        template:
          manilaAPI:
            customServiceConfig: |
              [DEFAULT]
              enabled_share_protocols = NFS
          ...

  2. Update the control plane: 

    $ oc apply -f openstack_control_plane.yaml -n openstack

  3. Wait until RHOCP creates the resources related to the OpenStackControlPlane CR. Run the following command to check the status: 

    $ oc get openstackcontrolplane -n openstack

    The OpenStackControlPlane resources are created when the status is "Setup complete".

    Tip

    Append the -w option to the end of the get command to track deployment progress.

7.8. Viewing back-end storage capacity

The scheduler component of the Shared File Systems service (manila) makes intelligent placement decisions based on several factors such as capacity, provisioning configuration, placement hints, and the capabilities that the back-end storage system driver detects and exposes. You can use share types and extra specifications to modify placement decisions.

Procedure

  1. Access the remote shell for the OpenStackClient pod from your workstation: 

    $ oc rsh -n openstack openstackclient

  2. Run the following command to view the available back-end storage capacity: 

    $ openstack share pool list --detail

  3. Exit the openstackclient pod: 

    $ exit

7.9. Configuring automatic database cleanup

The Block Storage (cinder) and Shared File Systems (manila) services automatically purge database entries marked for deletion for a set number of days. By default, records are marked for deletion for 30 days. You can configure a different record age and schedule for purge jobs.

Note

The Image service (glance) also purges database entries automatically but this functionality is not currently user configurable.

Procedure

  1. Open your openstack_control_plane.yaml file to edit the OpenStackControlPlane CR.

  2. Add the dbPurge parameter to the cinder or manila template to configure database cleanup depending on the service you want to configure.

    The following is an example of using the dbPurge parameter to configure the Block Storage service: 

    apiVersion: core.openstack.org/v1beta1
kind: OpenStackControlPlane
metadata:
  name: openstack
spec:
  cinder:
    template:
      dbPurge:
        age: 20 1
        schedule: 1 0 * * 0 2
    1
    The number of days a record has been marked for deletion before it is purged. The default value is 30 days. The minimum value is 1 day.
    2
    The schedule of when to run the job in a crontab format. The default value is 1 0 * * *. This default value is equivalent to 00:01 daily.

  3. Update the control plane: 

    $ oc apply -f openstack_control_plane.yaml
Red Hat logoGithubRedditYoutubeTwitter

Apprendre

Essayez, achetez et vendez

Communautés

À propos de la documentation Red Hat

Nous aidons les utilisateurs de Red Hat à innover et à atteindre leurs objectifs grâce à nos produits et services avec un contenu auquel ils peuvent faire confiance.

Rendre l’open source plus inclusif

Red Hat s'engage à remplacer le langage problématique dans notre code, notre documentation et nos propriétés Web. Pour plus de détails, consultez leBlog Red Hat.

À propos de Red Hat

Nous proposons des solutions renforcées qui facilitent le travail des entreprises sur plusieurs plates-formes et environnements, du centre de données central à la périphérie du réseau.

© 2024 Red Hat, Inc.