1 of 6

Installing Trilio Components

Once the Trilio VM or the Cluster of Trilio VMs has been spun, the actual installation process can begin. This process contains of the following steps:

Install the Trilio dm-api service on the control plane
Install the Trilio datamover service on the compute plane
Install the Trilio Horizon plugin into the Horizon service

How these steps look in detail is depending on the Openstack distribution Trilio is installed in. Each supported Openstack distribution has its own deployment tools. Trilio is integrating into these deployment tools to provide a native integration from the beginning to the end.

Test text

Installing on RHOSP

The Red Hat Openstack Platform Director is the supported and recommended method to deploy and maintain any RHOSP installation.

Trilio is integrating natively into the RHOSP Director. Manual deployment methods are not supported for RHOSP.

1. Prepare for deployment

1.1] Select 'backup target' type

Backup target storage is used to store backup images taken by Trilio and details needed for configuration:

Following backup target types are supported by Trilio

a) NFS

Need NFS share path

b) Amazon S3

- S3 Access Key - Secret Key - Region - Bucket name

c) Other S3 compatible storage (Like, Ceph based S3)

- S3 Access Key - Secret Key - Region - Endpoint URL (Valid for S3 other than Amazon S3) - Bucket name

1.2] Clone triliovault-cfg-scripts repository

The following steps are to be done on 'undercloud' node on an already installed RHOSP environment. The overcloud-deploy command has to be run successfully already and the overcloud should be available.

All commands need to be run as user 'stack' on undercloud node

The following command clones the triliovault-cfg-scripts github repository.

Next access the Red Hat Director scripts according to the used RHOSP version.

RHOSP 13

RHOSP 16.1

RHOSP 16.2

RHOSP 17.0

The remaining documentation will use the following path for examples:

1.3] If backup target type is 'Ceph based S3' with SSL:

If your backup target is ceph S3 with SSL and SSL certificates are self signed or authorized by private CA, then user needs to provide CA chain certificate to validate the SSL requests. For that, user needs to rename his ca chain cert file to 's3-cert.pem' and copy it into directory - 'triliovault-cfg-scripts/redhat-director-scripts/redhat-director-scripts/<RHOSP_RELEASE___Directory/puppet/trilio/files'

2] Upload trilio puppet module

The following commands upload the Trilio puppet module to the overcloud registry. The actual upload happens upon the next deployment.

Trilio puppet module is uploaded to overcloud as a swift deploy artifact with heat resource name 'DeployArtifactURLs'. If you check trilio's puppet module artifact file it looks like following.

Note: If your overcloud deploy command using any other deploy artifact through a environment file, then you need to merge trilio deploy artifact url and your url in single file.

How to check if your overcloud deploy environment files using deploy artifacts? You need to check string 'DeployArtifactURLs' in your environment files (only those mentioned in overcloud deploy command with -e option). If you find it any such environment file that is mentioned in overcloud dpeloy command with '-e' option then your deploy command is using deploy artifact.
In that case you need to merge all deploy artifacts in single file. Refer following steps.

Let's say, your artifact file path is "/home/stack/templates/user-artifacts.yaml" then refer following steps to merge both urls in single file and pass that new file to overcloud deploy command with '-e' option.

3] Update overcloud roles data file to include Trilio services

Trilio contains multiple services. Add these services to your roles_data.yaml.

In the case of uncustomized roles_data.yaml can the default file be found on the undercloud at:

/usr/share/openstack-tripleo-heat-templates/roles_data.yaml

Add the following services to the roles_data.yaml

All commands need to be run as user 'stack'

3.1] Add Trilio Datamover Api Service to role data file

This service needs to share the same role as the keystone and database service. In case of the pre-defined roles will these services run on the role Controller. In case of custom defined roles, it is necessary to use the same role where 'OS::TripleO::Services::Keystone' service installed.

Add the following line to the identified role:

3.2] Add Trilio Datamover Service to role data file

This service needs to share the same role as the nova-compute service. In case of the pre-defined roles will the nova-compute service run on the role Compute. In case of custom defined roles, it is necessary to use the role the nova-compute service is using.

Add the following line to the identified role:

3.3] Add Trilio Horizon Service role data file

This service needs to share the same role as the OpenStack Horizon server. In case of the pre-defined roles will the Horizon service run on the role Controller. Add the following line to the identified role:

4] Prepare Trilio container images

All commands need to be run as user 'stack'

Trilio containers are pushed to 'RedHat Container Registry'. Registry URL: 'registry.connect.redhat.com'. Container pull URLs are given below.

Please note that using the hotfix containers requires that the Trilio Appliance is getting upgraded to the desired hotfix level as well.

Refer to the word <HOTFIX-TAG-VERSION> as 4.3.2 in the below sections

RHOSP 13

RHOSP 16.1

RHOSP 16.2

RHOSP 17.0

There are three registry methods available in RedHat Openstack Platform.

Remote Registry
Local Registry
Satellite Server

4.1] Remote Registry

Follow this section when 'Remote Registry' is used.

In this method, container images gets downloaded directly on overcloud nodes during overcloud deploy/update command execution. User can set remote registry to redhat registry or any other private registry that he wants to use. User needs to provide credentials of the registry in 'containers-prepare-parameter.yaml' file.

Make sure other openstack service images are also using the same method to pull container images. If it's not the case you can not use this method.
Populate 'containers-prepare-parameter.yaml' with content like following. Important parameters are 'push_destination: false', ContainerImageRegistryLogin: true and registry credentials. Trilio container images are published to registry 'registry.connect.redhat.com'. Credentials of registry 'registry.redhat.io' will work for 'registry.connect.redhat.com' registry too.

Note: This file -'containers-prepare-parameter.yaml'

Redhat document for remote registry method: \

Note: File 'containers-prepare-parameter.yaml' gets created as output of command 'openstack tripleo container image prepare'. Refer above document by RedHat

3. Make sure you have network connectivity to above registries from all overcloud nodes. Otherwise image pull operation will fail.

4. User need to manually populate the trilio_env.yaml file with Trilio container image URLs as given below:

trilio_env.yaml file path:

At this step, you have configured Trilio image urls in the necessary environment file.

4.2] Local Registry

Follow this section when 'local registry' is used on the undercloud.

In this case it is necessary to push the Trilio containers to the undercloud registry. Trilio provides shell scripts which will pull the containers from 'registry.connect.redhat.com' and push them to the undercloud and updates the trilio_env.yaml.

RHOSP13

RHOSP 16.1

RHOSP16.2

RHOSP17.0

At this step, you have downloaded triliovault container images and configured triliovault image urls in necessary environment file.

4.3] Red Hat Satellite Server

Follow this section when a Satellite Server is used for the container registry.

Pull the Trilio containers on the Red Hat Satellite using the given

Populate the trilio_env.yaml with container urls.

RHOSP 13

RHOSP 16.1

RHOSP16.2

RHOSP17.0

At this step, you have downloaded triliovault container images into RedHat sattelite server and configured triliovault image urls in necessary environment file.

5] Configure multi-IP NFS

This section is only required when the multi-IP feature for NFS is required.

This feature allows to set the IP to access the NFS Volume per datamover instead of globally.

On Undercloud node, change directory

Edit file 'triliovault_nfs_map_input.yml' in the current directory and provide compute host and NFS share/ip map.

Get the compute hostnames from the following command. Check ‘Name' column. Use exact hostnames in 'triliovault_nfs_map_input.yml' file.

Run this command on undercloud by sourcing 'stackrc'.

Edit input map file and fill all the details. Refer to the for details about the structure.

vi triliovault_nfs_map_input.yml

Update pyyaml on the undercloud node only

If pip isn't available please install pip on the undercloud.

Expand the map file to create a one-to-one mapping of the compute nodes and the nfs shares.

The result will be in file - 'triliovault_nfs_map_output.yml'

Validate output map file

Open file 'triliovault_nfs_map_output.yml

vi triliovault_nfs_map_output.yml

available in the current directory and validate that all compute nodes are covered with all the necessary NFS shares.

Append this output map file to 'triliovault-cfg-scripts/redhat-director-scripts/<RHOSP_RELEASE_DIRECTORY>/environments/trilio_nfs_map.yaml'

Validate the changes in file 'triliovault-cfg-scripts/redhat-director-scripts/<RHOSP_RELEASE_DIRECTORY>/environments/trilio_nfs_map.yaml'

Include the environment file (trilio_nfs_map.yaml) in overcloud deploy command with '-e' option as shown below.

Ensure that MultiIPNfsEnabled is set to true in trilio_env.yaml file and that nfs is used as backup target.

6] Provide environment details in trilio-env.yaml

Provide backup target details and other necessary details in the provided environment file. This environment file will be used in the overcloud deployment to configure Trilio components. Container image names have already been populated in the preparation of the container images. Still it is recommended to verify the container URLs.

The following information are required additionally:

Network for the datamover api
datamover password
Backup target type {nfs/s3}

NFS options for Cohesity NFS : nolock,soft,timeo=600,intr,lookupcache=none,nfsvers=3,retrans=10

In case of S3
- S3 type {amazon_s3/ceph_s3}
- S3 Access key

Use ceph_s3 for any non-aws S3 backup targets.

7] Advanced Settings/Configuration

7.1] Haproxy customized configuration for Trilio dmapi service __

The existing default haproxy configuration works fine with most of the environments. Only when timeout issues with the dmapi are observed or other reasons are known, change the configuration as described here.

Following is the haproxy conf file location on haproxy nodes of the overcloud. Trilio datamover api service haproxy configuration gets added to this file.

Trilio datamover haproxy default configuration from the above file looks as follows:

The user can change the following configuration parameter values.

To change these default values, you need to do the following steps. i) On the undercloud node, open the following file for edit (Edit <RHOSP_RELEASE> with your cloud's release information. Valid values are - rhosp13, rhosp16, rhosp16.1)

For RHOSP13

For RHOSP16.1

For RHOSP16.2

For RHOSP17.0

ii) Search the following entries and edit as required

iii) Save the changes.

7.2] Configure Custom Volume/Directory Mounts for the Trilio Datamover Service

If the user wants to add one or more extra volume/directory mounts to the Trilio Datamover Service container, they can use the following heat environment file. A variable named 'TrilioDatamoverOptVolumes' is available in this file.

This variable 'TrilioDatamoverOptVolumes' accepts list of volume/bind mounts.
User needs to edit this file and add their volume mounts in below format.
For example:

Next, User needs to pass this file to overcloud deploy command with '-e' option Like below.

8] Deploy overcloud with trilio environment

Use the following heat environment file and roles data file in overcloud deploy command:

trilio_env.yaml
roles_data.yaml
Use correct Trilio endpoint map file as per available Keystone endpoint configuration

To include new environment files use '-e' option and for roles data file use '-r' option. An example overcloud deploy command is shown below:

Post deployment for multipath enabled environment, log into respective datamover container and add uxsock_timeout with value as 60000 (i.e. 60 sec) in /etc/multipath.conf. Restart datamover container

9] Verify deployment

If the containers are in restarting state or not listed by the following command then your deployment is not done correctly. Please recheck if you followed the complete documentation.

9.1] On Controller node

Make sure Trilio dmapi and horizon containers are in a running state and no other Trilio container is deployed on controller nodes. When the role for these containers is not "controller" check on respective nodes according to configured roles_data.yaml.

Verify the haproxy configuration under:

9.2] On Compute node

Make sure Trilio datamover container is in running state and no other Trilio container is deployed on compute nodes.

9.3] On the node with Horizon service

Make sure horizon container is in running state. Please note that 'Horizon' container is replaced with Trilio Horizon container. This container will have latest OpenStack horizon + Trilio's horizon plugin.

If Trilio Horizon container is in restarted state on RHOSP 16.1.8/RHSOP 16.2.4 then use below workaroud

10] Troubleshooting for overcloud deployment failures

Trilio components will be deployed using puppet scripts.

oIn case of the overcloud deployment failing do the following command provide the list of errors. The following document also provides valuable insights:

Installing on Canonical OpenStack

Trilio and Canonical have started a partnership to ensure a native deployment of Trilio using JuJu Charms.

Those JuJu Charms are publicly available as Open Source Charms.

Trilio is providing the JuJu Charms to deploy Trilio 4.2 in Canonical OpenStack from Yoga release onwards only. JuJu Charms to deploy Trilio 4.2 in Canonical OpenStack up to wallaby release are developed and maintained by Canonical.

Canonical OpenStack doesn't require the Trilio Cluster. The required services are installed and managed via JuJu Charms.

The documentation of the charms can be found here:

Juju charms for OpenStack Yoga release onwards

Juju charms for other supported OpenStack releases upto wallaby

Prerequisite

Have a canonical OpenStack base setup deployed for a required release like Jammy Zed/Yoga, Focal yoga/Wallaby/Victoria/Ussuri, or Bionic Ussuri/Queens.

Steps to install the Trilio charms

Export the OpenStack base bundle

2. Create a Trilio overlay bundle as per the OpenStack setup release using the charms given above.

Some sample Trilio overlay bundles can be found .

NFS options for Cohesity NFS : nolock,soft,timeo=600,intr,lookupcache=none,nfsvers=3,retrans=10

Trilio File Search functionality requires that the Trilio Workload manager (trilio-wlm) be deployed as a virtual machine. File Search will not function if the Trilio Workload manager (trilio-wlm) is running as a lxd container(s).

3. If file search functionality is required, provision any additional node(s) that will be required for deploying the Trilio Workload manager (trilio-wlm) as a VM instead of lxd container(s).

4. Commission the additional node from MAAS UI.

5. Do a dry run to check if the Trilio bundle is working

6. Do the deployment

7. Wait till all the Trilio units are deployed successfully. Check the status via juju status command.

8. Once the deployment is complete, perform the below operations:

Create cloud admin trust

Add license

Note: Reach out to the Trilio support team for the license file.

For multipath enabled environments, perform the following actions

log into each nova compute node
add uxsock_timeout with value as 60000 (i.e. 60 sec) in /etc/multipath.conf
restart tvault-contego service

Sample Trilio overlay bundles

For bionic-queens openstack-origin parameter value for trilio-dm-api charm must be cloud:bionic-train

For the AWS S3 storage backend, we need to use `` as S3 end-point URL.

A few Sample overlay bundles for different OpenStack versions can be found .

Installing on Ansible Openstack

Please ensure that the Trilio Appliance has been updated to the latest hotfix before continuing the installation.

Change the nova user id on the Trilio Nodes

Installing on TripleO Train

1. Prepare for deployment

1.1] Select 'backup target' type

Backup target storage is used to store backup images taken by Trilio and details needed for configuration:

The following backup target types are supported by Trilio

a) NFS

Need NFS share path

b) Amazon S3

- S3 Access Key - Secret Key - Region - Bucket name

c) Other S3 compatible storage (Like, Ceph based S3)

- S3 Access Key - Secret Key - Region - Endpoint URL (Valid for S3 other than Amazon S3) - Bucket name

1.2] Clone triliovault-cfg-scripts repository

All commands need to be run as user 'stack' on undercloud node

TripleO CentOS8 is not supported anymore as CentOS Linux 8 has reached End of Life on December 31st,2021.

The following command clones the triliovault-cfg-scripts github repository.

Please note that the Trilio Appliance needs to get updated to the latest HF as well.

1.3] If the backup target type is 'Ceph based S3' with SSL:

If your backup target is ceph S3 with SSL and SSL certificates are self-signed or authorized by a private CA, then the user needs to provide a CA chain certificate to validate the SSL requests. For that, the user needs to rename his ca chain cert file to s3-cert.pem and copy it into the directory triliovault-cfg-scripts/redhat-director-scripts/redhat-director-scripts/<RHOSP_RELEASE_Directory/puppet/trilio/files

2] Upload Trilio puppet module

3] Update overcloud roles data file to include Trilio services

Trilio contains multiple services. Add these services to your roles_data.yaml.

In the case of uncustomized roles_data.yaml can the default file be found on the undercloud at:

/usr/share/openstack-tripleo-heat-templates/roles_data.yaml

Add the following services to the roles_data.yaml

All commands need to be run as user 'stack'

3.1] Add Trilio Datamover Api Service to role data file

This service needs to share the same role as the keystone and database service. In the case of the pre-defined roles will these services run on the role Controller. In the case of custom-defined roles, it is necessary to use the same role where OS::TripleO::Services::Keystone service is installed.

Add the following line to the identified role:

3.2] Add Trilio Datamover Service to role data file

This service needs to share the same role as the nova-compute service. In the case of the pre-defined roles will the nova-compute service run on the role Compute. In the case of custom-defined roles, it is necessary to use the role the nova-compute service is used.

Add the following line to the identified role:

3.3] Add Trilio Horizon Service role data file4] Prepare Trilio container images

This service needs to share the same role as the OpenStack Horizon server. In the case of the pre-defined roles, Horizon service runs on the role Controller. Add the following line to the identified role:

All commands need to be run as user 'stack'

Refer to the word <HOTFIX-TAG-VERSION> as 4.3.2 in the below sections

Trilio containers are pushed to 'Dockerhub'. Registry URL: 'docker.io'. Container pull URLs are given below.

CentOS7

There are two registry methods available in TripleO Openstack Platform.

Remote Registry
Local Registry

4.1] Remote Registry

Follow this section when 'Remote Registry' is used.

For this method, it is not necessary to pull the containers in advance. It is only necessary to populate the trilio_env.yaml file with the Trilio container URLs from the Dockerhub registry.

Populate the trilio_env.yaml with container URLs for:

Trilio Datamover container
Trilio Datamover api container
Trilio Horizon Plugin

trilio_env.yaml will be available in __triliovault-cfg-scripts/redhat-director-scripts/tripleo-train/environments

4.2] Local Registry

Follow this section when 'local registry' is used on the undercloud.

Run the following script. Script pulls the triliovault containers and updates the triliovault environment file with URLs.

The changes can be verified using the following commands.

5] Configure multi-IP NFS

This section is only required when the multi-IP feature for NFS is required.

This feature allows setting the IP to access the NFS Volume per datamover instead of globally.

On Undercloud node, change the directory

Edit file 'triliovault_nfs_map_input.yml' in the current directory and provide compute host and NFS share/IP map.

Get the compute hostnames from the following command. Check the 'Name' column. Use exact hostnames in 'triliovault_nfs_map_input.yml' file.

Run this command on undercloud by sourcing 'stackrc'.

Edit the input map file and fill in all the details. Refer to for details about the structure.

vi triliovault_nfs_map_input.yml

Update pyYAML on the undercloud node only

If pip isn't available please install pip on the undercloud.

Expand the map file to create a one-to-one mapping of the compute nodes and the NFS shares.

The result will be in file - 'triliovault_nfs_map_output.yml'

Validate output map file

Open file 'triliovault_nfs_map_output.yml

vi triliovault_nfs_map_output.yml

available in the current directory and validate that all compute nodes are covered with all the necessary NFS shares.

Append this output map file to 'triliovault-cfg-scripts/redhat-director-scripts/<RHOSP_RELEASE_DIRECTORY>/environments/trilio_nfs_map.yaml'

Validate the changes in file triliovault-cfg-scripts/redhat-director-scripts/<RHOSP_RELEASE_DIRECTORY>/environments/trilio_nfs_map.yaml

Include the environment file (trilio_nfs_map.yaml) in overcloud deploy command with '-e' option as shown below.

Ensure that MultiIPNfsEnabled is set to true in trilio_env.yaml file and that NFS is used as the backup target.

6] Fill in Trilio environment details

Fill Trilio details in the file /home/stack/triliovault-cfg-scripts/redhat-director-scripts/tripleo-train/environments/trilio_env.yaml, triliovault environment file is self-explanatory. Fill in details of the backup target, verify image URLs, and other details.

NFS options for Cohesity NFS : nolock,soft,timeo=600,intr,lookupcache=none,nfsvers=3,retrans=10

7] Install Trilio on Overcloud

Use the following heat environment file and roles data file in overcloud deploy command

trilio_env.yaml: This environment file contains Trilio backup target details and Trilio container image locations
roles_data.yaml: This file contains overcloud roles data with Trilio roles added.
Use the correct trilio endpoint map file as per your keystone endpoint configuration. - Instead of tls-endpoints-public-dns.yaml this file, use ‘environments/trilio_env_tls_endpoints_public_dns.yaml’ - Instead of tls-endpoints-public-ip.yaml

Deploy command with triliovault environment file looks like the following.

Post deployment for multipath enabled environment, log into respective datamover container and add uxsock_timeout with value as 60000 (i.e. 60 sec) in /etc/multipath.conf. Restart datamover container

8] Verify the deployment

If the containers are in restarting state or not listed by the following command then your deployment is not done correctly. Please recheck if you followed the complete documentation.

8.1] On the Controller node

Verify the haproxy configuration under:

8.2] On Compute node

Make sure Trilio datamover container is in running state and no other Trilio container is deployed on compute nodes.

8.3] On the node with Horizon service

Make sure horizon container is in running state. Please note that 'Horizon' container is replaced with Trilio Horizon container. This container will have the latest OpenStack horizon + Trilio's horizon plugin.

10] Troubleshooting for overcloud deployment failures

Trilio components will be deployed using puppet scripts.

In case of the overcloud deployment fails do the following command to provide the list of errors. The following document also provides valuable insights:

Installing on RHOSP

The Red Hat Openstack Platform Director is the supported and recommended method to deploy and maintain any RHOSP installation.

Trilio is integrating natively into the RHOSP Director. Manual deployment methods are not supported for RHOSP.

1. Prepare for deployment

1.1] Select 'backup target' type

Backup target storage is used to store backup images taken by Trilio and details needed for configuration:

Following backup target types are supported by Trilio

a) NFS

Need NFS share path

b) Amazon S3

- S3 Access Key - Secret Key - Region - Bucket name

c) Other S3 compatible storage (Like, Ceph based S3)

- S3 Access Key - Secret Key - Region - Endpoint URL (Valid for S3 other than Amazon S3) - Bucket name

1.2] Clone triliovault-cfg-scripts repository

All commands need to be run as user 'stack' on undercloud node

The following command clones the triliovault-cfg-scripts github repository.

Next access the Red Hat Director scripts according to the used RHOSP version.

RHOSP 13

RHOSP 16.1

RHOSP 16.2

RHOSP 17.0

The remaining documentation will use the following path for examples:

1.3] If backup target type is 'Ceph based S3' with SSL:

2] Upload trilio puppet module

The following commands upload the Trilio puppet module to the overcloud registry. The actual upload happens upon the next deployment.

Trilio puppet module is uploaded to overcloud as a swift deploy artifact with heat resource name 'DeployArtifactURLs'. If you check trilio's puppet module artifact file it looks like following.

Note: If your overcloud deploy command using any other deploy artifact through a environment file, then you need to merge trilio deploy artifact url and your url in single file.

How to check if your overcloud deploy environment files using deploy artifacts? You need to check string 'DeployArtifactURLs' in your environment files (only those mentioned in overcloud deploy command with -e option). If you find it any such environment file that is mentioned in overcloud dpeloy command with '-e' option then your deploy command is using deploy artifact.
In that case you need to merge all deploy artifacts in single file. Refer following steps.

3] Update overcloud roles data file to include Trilio services

Trilio contains multiple services. Add these services to your roles_data.yaml.

In the case of uncustomized roles_data.yaml can the default file be found on the undercloud at:

/usr/share/openstack-tripleo-heat-templates/roles_data.yaml

Add the following services to the roles_data.yaml

All commands need to be run as user 'stack'

3.1] Add Trilio Datamover Api Service to role data file

Add the following line to the identified role:

3.2] Add Trilio Datamover Service to role data file

Add the following line to the identified role:

3.3] Add Trilio Horizon Service role data file

4] Prepare Trilio container images

All commands need to be run as user 'stack'

Trilio containers are pushed to 'RedHat Container Registry'. Registry URL: 'registry.connect.redhat.com'. Container pull URLs are given below.

Please note that using the hotfix containers requires that the Trilio Appliance is getting upgraded to the desired hotfix level as well.

Refer to the word <HOTFIX-TAG-VERSION> as 4.3.2 in the below sections

RHOSP 13

RHOSP 16.1

RHOSP 16.2

RHOSP 17.0

There are three registry methods available in RedHat Openstack Platform.

Remote Registry
Local Registry
Satellite Server

4.1] Remote Registry

Follow this section when 'Remote Registry' is used.

Make sure other openstack service images are also using the same method to pull container images. If it's not the case you can not use this method.
Populate 'containers-prepare-parameter.yaml' with content like following. Important parameters are 'push_destination: false', ContainerImageRegistryLogin: true and registry credentials. Trilio container images are published to registry 'registry.connect.redhat.com'. Credentials of registry 'registry.redhat.io' will work for 'registry.connect.redhat.com' registry too.

Note: This file -'containers-prepare-parameter.yaml'

Redhat document for remote registry method: \

Note: File 'containers-prepare-parameter.yaml' gets created as output of command 'openstack tripleo container image prepare'. Refer above document by RedHat

3. Make sure you have network connectivity to above registries from all overcloud nodes. Otherwise image pull operation will fail.

4. User need to manually populate the trilio_env.yaml file with Trilio container image URLs as given below:

trilio_env.yaml file path:

At this step, you have configured Trilio image urls in the necessary environment file.

4.2] Local Registry

Follow this section when 'local registry' is used on the undercloud.

RHOSP13

RHOSP 16.1

RHOSP16.2

RHOSP17.0

At this step, you have downloaded triliovault container images and configured triliovault image urls in necessary environment file.

4.3] Red Hat Satellite Server

Follow this section when a Satellite Server is used for the container registry.

Pull the Trilio containers on the Red Hat Satellite using the given

Populate the trilio_env.yaml with container urls.

RHOSP 13

RHOSP 16.1

RHOSP16.2

RHOSP17.0

At this step, you have downloaded triliovault container images into RedHat sattelite server and configured triliovault image urls in necessary environment file.

5] Configure multi-IP NFS

This section is only required when the multi-IP feature for NFS is required.

This feature allows to set the IP to access the NFS Volume per datamover instead of globally.

On Undercloud node, change directory

Edit file 'triliovault_nfs_map_input.yml' in the current directory and provide compute host and NFS share/ip map.

Get the compute hostnames from the following command. Check ‘Name' column. Use exact hostnames in 'triliovault_nfs_map_input.yml' file.

Run this command on undercloud by sourcing 'stackrc'.

Edit input map file and fill all the details. Refer to the for details about the structure.

vi triliovault_nfs_map_input.yml

Update pyyaml on the undercloud node only

If pip isn't available please install pip on the undercloud.

Expand the map file to create a one-to-one mapping of the compute nodes and the nfs shares.

The result will be in file - 'triliovault_nfs_map_output.yml'

Validate output map file

Open file 'triliovault_nfs_map_output.yml

vi triliovault_nfs_map_output.yml

available in the current directory and validate that all compute nodes are covered with all the necessary NFS shares.

Append this output map file to 'triliovault-cfg-scripts/redhat-director-scripts/<RHOSP_RELEASE_DIRECTORY>/environments/trilio_nfs_map.yaml'

Validate the changes in file 'triliovault-cfg-scripts/redhat-director-scripts/<RHOSP_RELEASE_DIRECTORY>/environments/trilio_nfs_map.yaml'

Include the environment file (trilio_nfs_map.yaml) in overcloud deploy command with '-e' option as shown below.

Ensure that MultiIPNfsEnabled is set to true in trilio_env.yaml file and that nfs is used as backup target.

6] Provide environment details in trilio-env.yaml

The following information are required additionally:

Network for the datamover api
datamover password
Backup target type {nfs/s3}

NFS options for Cohesity NFS : nolock,soft,timeo=600,intr,lookupcache=none,nfsvers=3,retrans=10

In case of S3
- S3 type {amazon_s3/ceph_s3}
- S3 Access key

Use ceph_s3 for any non-aws S3 backup targets.

7] Advanced Settings/Configuration

7.1] Haproxy customized configuration for Trilio dmapi service __

Following is the haproxy conf file location on haproxy nodes of the overcloud. Trilio datamover api service haproxy configuration gets added to this file.

Trilio datamover haproxy default configuration from the above file looks as follows:

The user can change the following configuration parameter values.

For RHOSP13

For RHOSP16.1

For RHOSP16.2

For RHOSP17.0

ii) Search the following entries and edit as required

iii) Save the changes.

7.2] Configure Custom Volume/Directory Mounts for the Trilio Datamover Service

If the user wants to add one or more extra volume/directory mounts to the Trilio Datamover Service container, they can use the following heat environment file. A variable named 'TrilioDatamoverOptVolumes' is available in this file.

This variable 'TrilioDatamoverOptVolumes' accepts list of volume/bind mounts.
User needs to edit this file and add their volume mounts in below format.
For example:

Next, User needs to pass this file to overcloud deploy command with '-e' option Like below.

8] Deploy overcloud with trilio environment

Use the following heat environment file and roles data file in overcloud deploy command:

trilio_env.yaml
roles_data.yaml
Use correct Trilio endpoint map file as per available Keystone endpoint configuration

To include new environment files use '-e' option and for roles data file use '-r' option. An example overcloud deploy command is shown below:

Post deployment for multipath enabled environment, log into respective datamover container and add uxsock_timeout with value as 60000 (i.e. 60 sec) in /etc/multipath.conf. Restart datamover container

9] Verify deployment

If the containers are in restarting state or not listed by the following command then your deployment is not done correctly. Please recheck if you followed the complete documentation.

9.1] On Controller node

Verify the haproxy configuration under:

9.2] On Compute node

Make sure Trilio datamover container is in running state and no other Trilio container is deployed on compute nodes.

9.3] On the node with Horizon service

If Trilio Horizon container is in restarted state on RHOSP 16.1.8/RHSOP 16.2.4 then use below workaroud

10] Troubleshooting for overcloud deployment failures

Trilio components will be deployed using puppet scripts.

oIn case of the overcloud deployment failing do the following command provide the list of errors. The following document also provides valuable insights:

resource_registry: OS::TripleO::Services::TrilioDatamover: ../services/trilio-datamover.yaml OS::TripleO::Services::TrilioDatamoverApi: ../services/trilio-datamover-api.yaml OS::TripleO::Services::TrilioHorizon: ../services/trilio-horizon.yaml # NOTE: If there are addition customizations to the endpoint map (e.g. for # other integratiosn), this will need to be regenerated. OS::TripleO::EndpointMap: endpoint_map.yaml parameter_defaults: ## Enable Trilio's quota functionality on horizon ExtraConfig: horizon::customization_module: 'dashboards.overrides' ## Define network map for trilio datamover api service ServiceNetMap: TrilioDatamoverApiNetwork: internal_api ## Trilio Datamover Password for keystone and database TrilioDatamoverPassword: "test1234" ## Trilio container pull urls DockerTrilioDatamoverImage: devundercloud.ctlplane.localdomain:8787/trilio/trilio-datamover:<HOTFIX-TAG-VERSION>-rhosp16.1 DockerTrilioDmApiImage: devundercloud.ctlplane.localdomain:8787/trilio/trilio-datamover-api:<HOTFIX-TAG-VERSION>-rhosp16.1 ## If you do not want Trilio's horizon plugin to replace your horizon container, just comment following line. ContainerHorizonImage: devundercloud.ctlplane.localdomain:8787/trilio/trilio-horizon-plugin:<HOTFIX-TAG-VERSION>-rhosp16.1 ## Backup target type nfs/s3, used to store snapshots taken by triliovault BackupTargetType: 'nfs' ## If backup target NFS share support multiple IPs and you want to use those IPs(more than one) then ## set this parameter to True. Otherwise keep it False. MultiIPNfsEnabled: False ## For backup target 'nfs' NfsShares: '192.168.122.101:/opt/tvault' NfsOptions: 'nolock,soft,timeo=180,intr,lookupcache=none' ## For backup target 's3' ## S3 type: amazon_s3/ceph_s3 S3Type: 'amazon_s3' ## S3 access key S3AccessKey: '' ## S3 secret key S3SecretKey: '' ## S3 region, if your s3 does not have any region, just keep the parameter as it is S3RegionName: '' ## S3 bucket name S3Bucket: '' ## S3 endpoint url, not required for Amazon S3, keep it as it is S3EndpointUrl: '' ## S3 signature version S3SignatureVersion: 'default' ## S3 Auth version S3AuthVersion: 'DEFAULT' ## If S3 backend is not Amazon S3 and SSL is enabled on S3 endpoint url then change it to 'True', otherwise keep it as 'False' S3SslEnabled: False ## If S3 backend is not Amazon S3 and SSL is enabled on S3 endpoint URL and SSL certificates are self signed, then ## user need to set this parameter value to: '/etc/tvault-contego/s3-cert.pem', otherwise keep it's value as empty string. S3SslCert: '' ## Configure 'dmapi_workers' parameter of '/etc/dmapi/dmapi.conf' file ## This parameter value used to spawn the number of dmapi processes to handle the incoming api requests. ## If your dmapi node has ‘n' cpu cores, It is recommended, to set this parameter to '4*n’. ## If dmapi_workers field is not present in config file. The Default value will be equals to number of cores present on the node DmApiWorkers: 16 ## Don't edit following parameter EnablePackageInstall: True ## Load 'rbd' kernel module on all compute nodes ComputeParameters: ExtraKernelModules: rbd: {}

Installing on TripleO Train

1. Prepare for deployment

1.1] Select 'backup target' type

Backup target storage is used to store backup images taken by Trilio and details needed for configuration:

The following backup target types are supported by Trilio

a) NFS

Need NFS share path

b) Amazon S3

- S3 Access Key - Secret Key - Region - Bucket name

c) Other S3 compatible storage (Like, Ceph based S3)

- S3 Access Key - Secret Key - Region - Endpoint URL (Valid for S3 other than Amazon S3) - Bucket name

1.2] Clone triliovault-cfg-scripts repository

All commands need to be run as user 'stack' on undercloud node

TripleO CentOS8 is not supported anymore as CentOS Linux 8 has reached End of Life on December 31st,2021.

The following command clones the triliovault-cfg-scripts github repository.

Please note that the Trilio Appliance needs to get updated to the latest HF as well.

1.3] If the backup target type is 'Ceph based S3' with SSL:

2] Upload Trilio puppet module

3] Update overcloud roles data file to include Trilio services

Trilio contains multiple services. Add these services to your roles_data.yaml.

In the case of uncustomized roles_data.yaml can the default file be found on the undercloud at:

/usr/share/openstack-tripleo-heat-templates/roles_data.yaml

Add the following services to the roles_data.yaml

All commands need to be run as user 'stack'

3.1] Add Trilio Datamover Api Service to role data file

Add the following line to the identified role:

3.2] Add Trilio Datamover Service to role data file

Add the following line to the identified role:

3.3] Add Trilio Horizon Service role data file4] Prepare Trilio container images

All commands need to be run as user 'stack'

Refer to the word <HOTFIX-TAG-VERSION> as 4.3.2 in the below sections

Trilio containers are pushed to 'Dockerhub'. Registry URL: 'docker.io'. Container pull URLs are given below.

CentOS7

There are two registry methods available in TripleO Openstack Platform.

Remote Registry
Local Registry

4.1] Remote Registry

Follow this section when 'Remote Registry' is used.

For this method, it is not necessary to pull the containers in advance. It is only necessary to populate the trilio_env.yaml file with the Trilio container URLs from the Dockerhub registry.

Populate the trilio_env.yaml with container URLs for:

Trilio Datamover container
Trilio Datamover api container
Trilio Horizon Plugin

trilio_env.yaml will be available in __triliovault-cfg-scripts/redhat-director-scripts/tripleo-train/environments

4.2] Local Registry

Follow this section when 'local registry' is used on the undercloud.

Run the following script. Script pulls the triliovault containers and updates the triliovault environment file with URLs.

The changes can be verified using the following commands.

5] Configure multi-IP NFS

This section is only required when the multi-IP feature for NFS is required.

This feature allows setting the IP to access the NFS Volume per datamover instead of globally.

On Undercloud node, change the directory

Edit file 'triliovault_nfs_map_input.yml' in the current directory and provide compute host and NFS share/IP map.

Get the compute hostnames from the following command. Check the 'Name' column. Use exact hostnames in 'triliovault_nfs_map_input.yml' file.

Run this command on undercloud by sourcing 'stackrc'.

Edit the input map file and fill in all the details. Refer to for details about the structure.

vi triliovault_nfs_map_input.yml

Update pyYAML on the undercloud node only

If pip isn't available please install pip on the undercloud.

Expand the map file to create a one-to-one mapping of the compute nodes and the NFS shares.

The result will be in file - 'triliovault_nfs_map_output.yml'

Validate output map file

Open file 'triliovault_nfs_map_output.yml

vi triliovault_nfs_map_output.yml

available in the current directory and validate that all compute nodes are covered with all the necessary NFS shares.

Append this output map file to 'triliovault-cfg-scripts/redhat-director-scripts/<RHOSP_RELEASE_DIRECTORY>/environments/trilio_nfs_map.yaml'

Validate the changes in file triliovault-cfg-scripts/redhat-director-scripts/<RHOSP_RELEASE_DIRECTORY>/environments/trilio_nfs_map.yaml

Include the environment file (trilio_nfs_map.yaml) in overcloud deploy command with '-e' option as shown below.

Ensure that MultiIPNfsEnabled is set to true in trilio_env.yaml file and that NFS is used as the backup target.

6] Fill in Trilio environment details

NFS options for Cohesity NFS : nolock,soft,timeo=600,intr,lookupcache=none,nfsvers=3,retrans=10

7] Install Trilio on Overcloud

Use the following heat environment file and roles data file in overcloud deploy command

trilio_env.yaml: This environment file contains Trilio backup target details and Trilio container image locations
roles_data.yaml: This file contains overcloud roles data with Trilio roles added.
Use the correct trilio endpoint map file as per your keystone endpoint configuration. - Instead of tls-endpoints-public-dns.yaml this file, use ‘environments/trilio_env_tls_endpoints_public_dns.yaml’ - Instead of tls-endpoints-public-ip.yaml

Deploy command with triliovault environment file looks like the following.

Post deployment for multipath enabled environment, log into respective datamover container and add uxsock_timeout with value as 60000 (i.e. 60 sec) in /etc/multipath.conf. Restart datamover container

8] Verify the deployment

If the containers are in restarting state or not listed by the following command then your deployment is not done correctly. Please recheck if you followed the complete documentation.

8.1] On the Controller node

Verify the haproxy configuration under:

8.2] On Compute node

Make sure Trilio datamover container is in running state and no other Trilio container is deployed on compute nodes.

8.3] On the node with Horizon service

10] Troubleshooting for overcloud deployment failures

Trilio components will be deployed using puppet scripts.

In case of the overcloud deployment fails do the following command to provide the list of errors. The following document also provides valuable insights:

##common editable parameters required for installing tvault-horizon-plugin, tvault-contego and tvault-datamover-api #ip address of TVM IP_ADDRESS: sample_tvault_ip_address ##Time Zone TIME_ZONE: "Etc/UTC" ## Don't update or modify the value of TVAULT_PACKAGE_VERSION ## The default value of is '4.2.64' TVAULT_PACKAGE_VERSION: 4.2.64 # Update Openstack dist code name like ussuri etc. OPENSTACK_DIST: ussuri #Need to add the following statement in nova sudoers file #nova ALL = (root) NOPASSWD: /home/tvault/.virtenv/bin/privsep-helper * #These changes require for Datamover, Otherwise Datamover will not work #Are you sure? Please set variable to # UPDATE_NOVA_SUDOERS_FILE: proceed #other wise ansible tvault-contego installation will exit UPDATE_NOVA_SUDOERS_FILE: proceed ##### Select snapshot storage type ##### #Details for NFS as snapshot storage , NFS_SHARES should begin with "-". ##True/False NFS: False NFS_SHARES: - sample_nfs_server_ip1:sample_share_path - sample_nfs_server_ip2:sample_share_path #if NFS_OPTS is empty then default value will be "nolock,soft,timeo=180,intr,lookupcache=none" NFS_OPTS: "" ## Valid for 'nfs' backup target only. ## If backup target NFS share supports multiple endpoints/ips but in backend it's a single share then ## set 'multi_ip_nfs_enabled' parameter to 'True'. Otherwise it's value should be 'False' multi_ip_nfs_enabled: False #### Details for S3 as snapshot storage ##True/False S3: False VAULT_S3_ACCESS_KEY: sample_s3_access_key VAULT_S3_SECRET_ACCESS_KEY: sample_s3_secret_access_key VAULT_S3_REGION_NAME: sample_s3_region_name VAULT_S3_BUCKET: sample_s3_bucket VAULT_S3_SIGNATURE_VERSION: default #### S3 Specific Backend Configurations #### Provide one of follwoing two values in s3_type variable, string's case should be match #Amazon/Other_S3_Compatible s3_type: sample_s3_type #### Required field(s) for all S3 backends except Amazon VAULT_S3_ENDPOINT_URL: "" #True/False VAULT_S3_SECURE: True VAULT_S3_SSL_CERT: "" ###details of datamover API ##If SSL is enabled "DMAPI_ENABLED_SSL_APIS" value should be dmapi. #DMAPI_ENABLED_SSL_APIS: dmapi ##If SSL is disabled "DMAPI_ENABLED_SSL_APIS" value should be empty. DMAPI_ENABLED_SSL_APIS: "" DMAPI_SSL_CERT: "" DMAPI_SSL_KEY: "" ## Trilio dmapi_workers count ## Default value of dmapi_workers is 16 dmapi_workers: 16 #### Any service is using Ceph Backend then set ceph_backend_enabled value to True #True/False ceph_backend_enabled: False ## Provide Horizon Virtual Env path from Horizon_container ## e.g. '/openstack/venvs/horizon-23.1.0' horizon_virtual_env: '/openstack/venvs/horizon*' ## When More Than One Nova Virtual Env. On Compute Node(s) and ## User Wants To Specify Specific Nova Virtual Env. From Existing ## Then Only Uncomment the var nova_virtual_env and pass value like 'openstack/venvs/nova-23.2.0' #nova_virtual_env: 'openstack/venvs/nova-23.2.0' #Set verbosity level and run playbooks with -vvv option to display custom debug messages verbosity_level: 3 #****************************************************************************************************************************************************************** ###static fields for tvault contego extension ,Please Do not Edit Below Variables #****************************************************************************************************************************************************************** #SSL path DMAPI_SSL_CERT_DIR: /opt/config-certs/dmapi VAULT_S3_SSL_CERT_DIR: /opt/config-certs/s3 RABBITMQ_SSL_DIR: /opt/config-certs/rabbitmq DMAPI_SSL_CERT_PATH: /opt/config-certs/dmapi/dmapi-ca.pem DMAPI_SSL_KEY_PATH: /opt/config-certs/dmapi/dmapi.key VAULT_S3_SSL_CERT_PATH: /opt/config-certs/s3/ca_cert.pem RABBITMQ_SSL_CERT_PATH: /opt/config-certs/rabbitmq/rabbitmq.pem RABBITMQ_SSL_KEY_PATH: /opt/config-certs/rabbitmq/rabbitmq.key RABBITMQ_SSL_CA_CERT_PATH: /opt/config-certs/rabbitmq/rabbitmq-ca.pem PORT_NO: 8085 PYPI_PORT: 8081 DMAPI_USR: dmapi DMAPI_GRP: dmapi #tvault contego file path TVAULT_CONTEGO_CONF: /etc/tvault-contego/tvault-contego.conf TVAULT_OBJECT_STORE_CONF: /etc/tvault-object-store/tvault-object-store.conf NOVA_CONF_FILE: /etc/nova/nova.conf #Nova distribution specific configuration file path NOVA_DIST_CONF_FILE: /usr/share/nova/nova-dist.conf TVAULT_CONTEGO_EXT_USER: nova TVAULT_CONTEGO_EXT_GROUP: nova TVAULT_DATA_DIR_MODE: 0775 TVAULT_DATA_DIR_OLD: /var/triliovault TVAULT_DATA_DIR: /var/triliovault-mounts TVAULT_CONTEGO_VIRTENV: /home/tvault TVAULT_CONTEGO_VIRTENV_PATH: "{{TVAULT_CONTEGO_VIRTENV}}/.virtenv" TVAULT_CONTEGO_EXT_BIN: "{{TVAULT_CONTEGO_VIRTENV_PATH}}/bin/tvault-contego" TVAULT_CONTEGO_EXT_PYTHON: "{{TVAULT_CONTEGO_VIRTENV_PATH}}/bin/python" TVAULT_CONTEGO_EXT_OBJECT_STORE: "" TVAULT_CONTEGO_EXT_BACKEND_TYPE: "" TVAULT_CONTEGO_EXT_S3: "{{TVAULT_CONTEGO_VIRTENV_PATH}}/lib/python2.7/site-packages/contego/nova/extension/driver/s3vaultfuse.py" privsep_helper_file: /home/tvault/.virtenv/bin/privsep-helper pip_version: 7.1.2 virsh_version: "1.2.8" contego_service_file_path: /etc/systemd/system/tvault-contego.service contego_service_ulimits_count: 65536 contego_service_debian_path: /etc/init/tvault-contego.conf objstore_service_file_path: /etc/systemd/system/tvault-object-store.service objstore_service_debian_path: /etc/init/tvault-object-store.conf ubuntu: "Ubuntu" centos: "CentOS" redhat: "RedHat" Amazon: "Amazon" Other_S3_Compatible: "Other_S3_Compatible" tvault_datamover_api: tvault-datamover-api datamover_service_file_path: /etc/systemd/system/tvault-datamover-api.service datamover_service_debian_path: /etc/init/tvault-datamover.conf datamover_log_dir: /var/log/dmapi trilio_yum_repo_file_path: /etc/yum.repos.d/trilio.repo verbosity_level: 3

Installing on Kolla Openstack

This page lists all steps required to deploy Trilio components on Kolla-ansible deployed OpenStack cloud.

1] Plan for Deployment

Please ensure that the Trilio Appliance has been updated to the latest maintenance release before continuing the installation.

Refer to the below-mentioned acceptable values for the placeholders triliovault_tag and kolla_base_distro , in this document as per the Openstack environment:

Openstack Version

triliovault_tag

kolla_base_distro

1.1] Select backup target type

Backup target storage is used to store backup images taken by Trilio and details needed for configuration:

Following backup target types are supported by Trilio. Select one of them and get it ready before proceeding to the next step.

a) NFS

Need NFS share path

b) Amazon S3

- S3 Access Key - Secret Key - Region - Bucket name

c) Other S3 compatible storage (Like, Ceph based S3)

- S3 Access Key - Secret Key - Region - Endpoint URL (Valid for S3 other than Amazon S3) - Bucket name

2] Clone Trilio Deployment Scripts

Clone triliovault-cfg-scripts GitHub repository on Kolla ansible server at '/root' or any other directory of your preference. Afterwards, copy Trilio Ansible role into Kolla-ansible roles directory

3] Hook Trilio deployment scripts to Kolla-ansible deploy scripts

3.1] Add Trilio global variables to globals.yml

3.2] Add Trilio passwords to kolla passwords.yaml

Append triliovault_passwords.yml to /etc/kolla/passwords.yml. Passwords are empty. Set these passwords manually in the /etc/kolla/passwords.yml.

3.3] Append Trilio site.yml content to kolla ansible’s site.yml

3.4] Append triliovault_inventory.txt to your cloud’s kolla-ansible inventory file.

3.5] Configure multi-IP NFS

This step is only required when the multi-IP NFS feature is used to connect different datamovers to the same NFS volume through multiple IPs

On kolla-ansible server node, change directory

Edit file 'triliovault_nfs_map_input.yml' in the current directory and provide compute host and NFS share/ip map.

If IP addresses are used in the kolla-ansible inventory file then you should use same IP addresses in 'triliovault_nfs_map_input.yml' file too. If you used hostnames there then you need to use same hostnames here in nfs map input file.

Compute host names or IP addresses that you are using in nfs map input file here should match with kolla-ansible inventory file entries.

vi triliovault_nfs_map_input.yml

The triliovault_nfs_map_imput.yml is explained .

Update PyYAML on the kolla-ansible server node only

Expand the map file to create one to one mapping of compute and nfs share.

Result will be in file - 'triliovault_nfs_map_output.yml'

Validate output map file

Open file 'triliovault_nfs_map_output.yml

vi triliovault_nfs_map_output.yml

available in the current directory and validate that all compute nodes are covered with all necessary nfs shares.

Append this output map file to 'triliovault_globals.yml' File Path: '/home/stack/triliovault-cfg-scripts/kolla-ansible/ansible/triliovault_globals.yml’

Ensure to set multi_ip_nfs_enabled in __ triliovault_globals.yml file to yes

4] Edit globals.yml to set Trilio parameters

Edit /etc/kolla/globals.yml file to fill Trilio backup target and build details. You will find the Trilio related parameters at the end of globals.yml file. Details like Trilio build version, backup target type, backup target details, etc need to be filled out.

Following is the list of parameters that the usr needs to edit.

Parameter

Defaults/choices

comments

In the case of a different registry than docker hub, Trilio containers need to be pulled from docker.io and pushed to preferred registries.

Following are the triliovault container image URLs for 4.3 releases**.** Replace kolla_base_distro and triliovault_tag variables with their values.\

This {{ kolla_base_distro }} variable can be either 'centos' or 'ubuntu' depends on your base OpenStack distro

Trilio supports the Source-based containers from the OpenStack Yoga release **** onwards.

Below are the Source-based OpenStack deployment images

Below are the Binary-based OpenStack deployment images

5] Enable Trilio Snapshot mount feature

To enable Trilio's Snapshot mount feature it is necessary to make the Trilio Backup target available to the nova-compute and nova-libvirt containers.

Edit /usr/local/share/kolla-ansible/ansible/roles/nova-cell/defaults/main.yml and find nova_libvirt_default_volumes variables. Append the Trilio mount bind /var/trilio:/var/trilio:shared to the list of already existing volumes.

For a default Kolla installation, will the variable look as follows afterward:

Next, find the variable nova_compute_default_volumes in the same file and append the mount bind /var/trilio:/var/trilio:shared to the list.

After the change will the variable look for a default Kolla installation as follows:

In case of using Ironic compute nodes one more entry need to be adjusted in the same file. Find the variable nova_compute_ironic_default_volumes and append trilio mount /var/trilio:/var/trilio:shared to the list.

After the changes the variable will looks like the following:

6] Pull Trilio container images

Activate the login into dockerhub for Trilio tagged containers.

Please get the Dockerhub login credentials from Trilio Sales/Support team

Pull the Trilio container images from the dockerhub based on the existing inventory file. In the example is the inventory file named multinode.

7] Deploy Trilio

All that is left, is to run the deploy command using the existing inventory file. In the example is the inventory file named 'multinode'.

This is just an example command. You need to use your cloud deploy command.

Post deployment for multipath enabled environment, log into respective datamover container and add uxsock_timeout with value as 60000 (i.e. 60 sec) in /etc/multipath.conf. Restart datamover container

8] Verify Trilio deployment

Verify on the controller and compute nodes that the Trilio containers are in UP state.

Following is a sample output of commands from controller and compute nodes. triliovault_tag will have value as per the openstack release where deployment being done.

9] Troubleshooting Tips

9.1 ] Check Trilio containers and their startup logs

To see all TriloVault containers running on a specific node use the docker ps command.

To check the startup logs use the docker logs <container name> command.

9.2] Trilio Horizon tabs are not visible in Openstack

Verify that the Trilio Appliance is configured. The Horizon tabs are only shown, when a configured Trilio appliance is available.

Verify that the Trilio horizon container is installed and in a running state.

9.3] Trilio Service logs

Trilio datamover api service logs on datamover api node

Trilio datamover service logs on datamover node

10. Change the nova user id on the Trilio Nodes

Note: This step needs to be done on Trilio Appliance node. Not on OpenStack node.

Pre-requisite: You should have already launched Trilio appliance VM

In Kolla openstack distribution, 'nova' user id on nova-compute docker container is set to '42436'. The 'nova' user id on the Trilio nodes need to be set the same. Do the following steps on all Trilio nodes:

Download the shell script that will change the user id
Assign executable permissions
Execute the script

11. Advanced configurations - [Optional]

11.1] We are using cinder's ceph user for interacting with Ceph cinder storage. This user name is defined using parameter - 'ceph_cinder_user' in the file '/etc/kolla/globals.yaml'.

If user wants to edit this parameter value they can do it. Impact will be, cinder's ceph user and triliovault datamover's ceph user will be updated upon next kolla-ansible deploy command.

Installing Trilio Components

Installing on RHOSP

hashtag1. Prepare for deployment

hashtag1.1] Select 'backup target' type

hashtag1.2] Clone triliovault-cfg-scripts repository

hashtagRHOSP 13

hashtagRHOSP 16.1

hashtagRHOSP 16.2

hashtagRHOSP 17.0

hashtag1.3] If backup target type is 'Ceph based S3' with SSL:

hashtag2] Upload trilio puppet module

hashtag3] Update overcloud roles data file to include Trilio services

hashtag3.1] Add Trilio Datamover Api Service to role data file

hashtag3.2] Add Trilio Datamover Service to role data file

hashtag3.3] Add Trilio Horizon Service role data file

hashtag4] Prepare Trilio container images

hashtagRHOSP 13

hashtagRHOSP 16.1

hashtagRHOSP 16.2

hashtagRHOSP 17.0

hashtag4.1] Remote Registry

hashtag4.2] Local Registry

hashtagRHOSP13

hashtagRHOSP 16.1

hashtagRHOSP16.2

hashtagRHOSP17.0

hashtag4.3] Red Hat Satellite Server

hashtagRHOSP 13

hashtagRHOSP 16.1

hashtagRHOSP16.2

hashtagRHOSP17.0

hashtag5] Configure multi-IP NFS

hashtag6] Provide environment details in trilio-env.yaml

hashtag7] Advanced Settings/Configuration

hashtag7.1] Haproxy customized configuration for Trilio dmapi service __

hashtag7.2] Configure Custom Volume/Directory Mounts for the Trilio Datamover Service

hashtag8] Deploy overcloud with trilio environment

hashtag9] Verify deployment

hashtag9.1] On Controller node

hashtag9.2] On Compute node

hashtag9.3] On the node with Horizon service

hashtag10] Troubleshooting for overcloud deployment failures

Installing on Canonical OpenStack

hashtagJuju charms for OpenStack Yoga release onwards

hashtagJuju charms for other supported OpenStack releases upto wallaby

Installing on Ansible Openstack

hashtagChange the nova user id on the Trilio Nodes

Installing on TripleO Train

hashtag1. Prepare for deployment

hashtag1.1] Select 'backup target' type

hashtag1.2] Clone triliovault-cfg-scripts repository

hashtag1.3] If the backup target type is 'Ceph based S3' with SSL:

hashtag2] Upload Trilio puppet module

hashtag3] Update overcloud roles data file to include Trilio services

hashtag3.1] Add Trilio Datamover Api Service to role data file

hashtag3.2] Add Trilio Datamover Service to role data file

hashtag3.3] Add Trilio Horizon Service role data file4] Prepare Trilio container images

hashtagCentOS7

hashtag4.1] Remote Registry

hashtag4.2] Local Registry

hashtag5] Configure multi-IP NFS

hashtag6] Fill in Trilio environment details

hashtag7] Install Trilio on Overcloud

hashtag8] Verify the deployment

hashtag8.1] On the Controller node

hashtag8.2] On Compute node

hashtag8.3] On the node with Horizon service

hashtag10] Troubleshooting for overcloud deployment failures

Installing Trilio Components

Installing on RHOSP

hashtag1. Prepare for deployment

hashtag1.1] Select 'backup target' type

hashtag1.2] Clone triliovault-cfg-scripts repository

hashtagRHOSP 13

hashtagRHOSP 16.1

hashtagRHOSP 16.2

hashtagRHOSP 17.0

hashtag1.3] If backup target type is 'Ceph based S3' with SSL:

hashtag2] Upload trilio puppet module

hashtag3] Update overcloud roles data file to include Trilio services

1. Prepare for deployment

1.1] Select 'backup target' type

1.2] Clone triliovault-cfg-scripts repository

RHOSP 13

RHOSP 16.1

RHOSP 16.2

RHOSP 17.0

1.3] If backup target type is 'Ceph based S3' with SSL:

2] Upload trilio puppet module

3] Update overcloud roles data file to include Trilio services

3.1] Add Trilio Datamover Api Service to role data file

3.2] Add Trilio Datamover Service to role data file

3.3] Add Trilio Horizon Service role data file

4] Prepare Trilio container images

RHOSP 13

RHOSP 16.1

RHOSP 16.2

RHOSP 17.0

4.1] Remote Registry

4.2] Local Registry

RHOSP13

RHOSP 16.1

RHOSP16.2

RHOSP17.0

4.3] Red Hat Satellite Server

RHOSP 13

RHOSP 16.1

RHOSP16.2

RHOSP17.0

5] Configure multi-IP NFS

6] Provide environment details in trilio-env.yaml

7] Advanced Settings/Configuration

7.1] Haproxy customized configuration for Trilio dmapi service __

7.2] Configure Custom Volume/Directory Mounts for the Trilio Datamover Service

8] Deploy overcloud with trilio environment

9] Verify deployment

9.1] On Controller node

9.2] On Compute node

9.3] On the node with Horizon service

10] Troubleshooting for overcloud deployment failures

Juju charms for OpenStack Yoga release onwards

Juju charms for other supported OpenStack releases upto wallaby

Change the nova user id on the Trilio Nodes

1. Prepare for deployment

1.1] Select 'backup target' type

1.2] Clone triliovault-cfg-scripts repository

1.3] If the backup target type is 'Ceph based S3' with SSL:

2] Upload Trilio puppet module

3] Update overcloud roles data file to include Trilio services

3.1] Add Trilio Datamover Api Service to role data file

3.2] Add Trilio Datamover Service to role data file

3.3] Add Trilio Horizon Service role data file4] Prepare Trilio container images

CentOS7

4.1] Remote Registry

4.2] Local Registry

5] Configure multi-IP NFS

6] Fill in Trilio environment details

7] Install Trilio on Overcloud

8] Verify the deployment

8.1] On the Controller node

8.2] On Compute node

8.3] On the node with Horizon service

10] Troubleshooting for overcloud deployment failures

1. Prepare for deployment

1.1] Select 'backup target' type

1.2] Clone triliovault-cfg-scripts repository

RHOSP 13

RHOSP 16.1

RHOSP 16.2

RHOSP 17.0

1.3] If backup target type is 'Ceph based S3' with SSL:

2] Upload trilio puppet module

3] Update overcloud roles data file to include Trilio services

3.1] Add Trilio Datamover Api Service to role data file

3.2] Add Trilio Datamover Service to role data file

3.3] Add Trilio Horizon Service role data file

4] Prepare Trilio container images

RHOSP 13

RHOSP 16.1

RHOSP 16.2