Openstack TripleO Storage Configuration

By /

In TripleO overcloud deployment, various storage options like Volume, Shared File system, Object storage can be provided with various ways. Check below some options:

1. Adding custom backend to Cinder (Volume Service)

Each backend is represented in cinder.conf with a stanza and a reference to it from the enabled_backends key. The keys valid in the backend stanza are dependent on the actual backend driver and unknown to Cinder. For example, to provision in Cinder one backends one could create a Heat environment file with the following contents:

parameter_defaults:
  ExtraConfig:
    cinder::config::cinder_config:
        netapp1/volume_driver:
                value: cinder.volume.drivers.netapp.common.NetAppDriver
        netapp1/netapp_storage_family:
                value: ontap_7mode
        netapp1/netapp_storage_protocol:
                value: iscsi
        netapp1/netapp_server_hostname:
                value: 1.1.1.1
        netapp1/netapp_server_port:
                value: 80
        netapp1/netapp_login:
                value: root
        netapp1/netapp_password:
                value: 123456
        netapp1/volume_backend_name:
                value: netapp_1


This will not interfere with the deployment of the other backends managed by TripleO, like Ceph or NFS. Finally use this env file to deploy:

openstack overcloud deploy [other overcloud deploy options] -e ~/netapp-backend.yaml

 

2. Deploying Ceph with TripleO

The provision of baremetal instances step outputs a YAML file describing the deployed baremetal, for example:

openstack overcloud node provision -o ~/deployed_metal.yaml

The deployed_metal.yaml file can be passed as input to the openstack overcloud ceph deploy command, which in turn outputs a YAML file describing the deployed Ceph cluster, for example:

openstack overcloud ceph deploy ~/deployed_metal.yaml -o ~/deployed_ceph.yaml

Both the deployed_metal.yaml and deployed_ceph.yaml files may then be passed as input to the step to “Create the overcloud Ephemeral Heat stack”, for example:

openstack overcloud deploy --templates -e ~/deployed_metal.yaml -e ~/deployed_ceph.yaml ...

While the overcloud is being deployed the data in the deployed_ceph.yaml file will be used to configure the OpenStack clients to connect to the Ceph cluster as well as configure the Ceph cluster to host OpenStack.

3. Deploying Manila in overcloud

Ceph deployed by TripleO can be used as a Manila share backend. Make sure that Ceph, Ceph MDS and Manila Ceph environment files are included when deploying the Overcloud:

openstack overcloud deploy --templates \
-e /usr/share/openstack-tripleo-heat-templates/environments/cephadm/cephadm.yaml \
-e /usr/share/openstack-tripleo-heat-templates/environments/cephadm/ceph-mds.yaml \
-e /usr/share/openstack-tripleo-heat-templates/environments/manila-cephfsnative-config.yaml

Please note, When mounting a ceph share from a user instance, the user instance needs access to the Ceph public network, which in TripleO maps to the Overcloud storage network. In an Overcloud which uses isolated networks the tenant network and storage network are isolated from one another so user instances cannot reach the Ceph public network unless the cloud administrator creates a provider network in neutron that maps to the storage network and exposes access to it.

Scroll to Top