Search…
TVO-4.1
Powered By GitBook
TrilioVault 4.1 Release Notes
TrilioVault release 4.1 introduces new features and capabilities including:
    Openstack Ussuri support
    New File Recovery Process
    Increased Openstack independency
    Installation Optimization for Kolla Ansible Openstack, Ansible Openstack, and Red Hat Openstack Platform
    Support for External MySQL/MariaDB databases
    Incremental Backup for nova booted instances
    Support of Openstack User Groups
    New Quota: Snapshots
    S3 Support for Kolla Ansible Openstack
    UI enhancement for selective Restore
TrilioVault 4.1.94 is the GA release of TrilioVault 4.1

Openstack Ussuri support

TrilioVault 4.1 continues to enable Openstack versions and Distributions, allowing TrilioVault customers to stay up to date with Openstack releases.
TrilioVault 4.1 introduces full support for Openstack Ussuri for Kolla Ansible Openstack, Ansible Openstack, and Canonical Openstack. In addition, Triliovault 4.1 does of course support the active long-term releases from Red Hat and Canonical. Openstack users of those releases can continue to use the latest TrilioVault functionalities.

New File Recovery Manager Process

Since TrilioVault was released for the first time was the File Recovery Manager instance in tandem with TrilioVault. The File Recovery Manager instance helped customers to easily and quickly fetch and restore files and folders directly from the backups.
Over the years did more and more customers request to have the File Recovery Manager on their own images or on a specific Linux distribution. We looked into the possibility to create multiple versions of the File Recovery Manager which was identified as not getting to the point of flexibility our customers need.
The result was a revamp of the File Recovery Manager which allows the installation on any CentOS-based or Ubuntu-based instance.

Increased Openstack independency

TrilioVault has the goal to become an integrated part of Openstack since its first draft on a whiteboard. Back then were the TrilioVault services defined as sub-services of Nova and TrilioVault tied deeply into the already existing nova services and became an integral part of it.
Over the years did the nova service change and possibilities that were once available have been taken out from nova. This plus the required lengthy qualification of all Openstack Versions and Distributions made it clear that a change is required.
TrilioVault 4.1 is now a complete stand-alone service, which is communicating with nova and other Openstack services through APIs only. The goal of this independence is to speed up future qualification and requalification cycles to provide a broader support matrix again.

Installation optimization for Kolla Ansible Openstack, Ansible Openstack, and Red Hat Openstack Platform

TrilioVault's integration into Openstack already starts with the installation process. This process required manual installation steps in the past, which were hard to automize and scale on bigger environments.
TrilioVault 4.1 is therefore introducing Ansible Playbooks for Kolla-Ansible and Ansible Openstack, while the integration with Red Hat Director has been deepened. Further, the TrilioVault configurator does now allow to set the backup target on the TrilioVault Appliance directly based on Distribution.

Support for external MySQL/MariaDB

The TrilioVault Appliance provides its own database. A database that suits the needs of 99% of Trilio's customers. Some customers do have higher requirements. Be it performance, security, or just the general design of the Openstack itself.
For these customers and everyone who wants to use it is TrilioVault 4.1 introducing the possibility to configure TrilioVault with an external database.

Incremental Backups for nova booted instance root volumes

Openstack provides the possibility to start an instance from a Cinder Volume or directly using the Glance Image and a nova volume.
TrilioVault always provided incremental forever backups for all cinder volumes. Root-Volumes from nova-booted instances were always taken as a full backup of the Glance image and the actual VM root volume.
TrilioVault 4.1 does introduce incremental backups for nova booted instance root volumes. This allows TrilioVault 4.1 to provide incremental backups to any type of root volume.

Support for Openstack User Groups

TrilioVault is using the Openstack Keystone service to authenticate any user and to verify that the right permissions are set. Openstack Keystone allows to group users and set the permissions to the group.
These Openstack User Groups are now fully supported.

New Quota: Snapshots

TrilioVault 4.0 introduced the Quota functionality, which allowed to set quotas for the number of workloads, number of VMs and amount of storage used by a single tenant.
Triliovault 4.1 extends this feature by the number of TrilioVault Snapshots that a Tenant is allowed to have.

S3 Support for Kolla Ansible Openstack

S3 is becoming the standard to transfer data to and from storage solutions. TrilioVault introduced S3 already in Version 3.0 but had to take it out for Kolla Ansible since Kolla Ansible has been added to the Support Matrix.
TrilioVault 4.1 is now closing that gap to other Openstack Distributions and provides full S3 support for Kolla Ansible Openstack Ussuri.

UI enhancement for the Selective Restore

The Selective Restore is the most powerful and complex restore TrilioVault has to offer. The UI needs to be easy to understand and help the user to fulfill its task.
Several points have been identified to improve this requirement of usability. The selective restore now allows to select or deselect all VMs at once. Further are the VMs now provided in an easy to overview list and the sub-controls can be expanded and collapsed as necessary.

Known Issues

This release contains the following known issues which are tracked for a future update.

Snapshots getting stuck in uploading stage on RHOSP13 with ISCSI based Volumes

Observation:
    Login into the iscsi device is getting rejected for the TrilioVault service
    Result is the Snapshot not moving forward until timing out

Workloadmgr Quota feature does not support RHOSP13 & Canonical Queens Horizon

The workloadmgr Quota feature is still fully supported through CLI.

[Openstack Ansible] snapshot mount failed with error 'Permission denied'

Observation:
    It has been observed that on non-kolla, non-rhosp setups, such as openstack ansible, nova user id is not same as we consider as default(162).
    Another observation is that, the id which is assigned to nova, was conflicting with id of system user in TVM, this created a situation where we had to redeploy Openstack.
Workaround:
    Update permissions of /var/triliovault-mounts to 755

[Volume Backup Exclude] Excluded Ceph Volume after restore not mountable or formattable

Observation:
    VM Volumes stored on Ceph are successfully excluded from backup if desired
    Restore does create empty Ceph Volume
    created empty Ceph Volume is not attachable or formattable

Restored VMs have blank metadata config_drive attached

Observation:
    For every restore will the metadata config_drive be set as blank value
    No impact on restored VMs known
Workaround
    delete metadata config_drive
    or set desired value

TVM reconfig fails when adding new TrilioVault VM to the cluster

Observation:
    TVault re-configuration while adding nodes to existing TVM cluster fails at "Configuring TrilioVault Cluster"
    Reason is that the prev mysql password was not working and mysql root access has be reset.
Workaround:
    remove /root/.my.cnf file on already configured TVM and reconfigure it

Database does not sync after TrilioVault cluster gets new nodes

Observation:
    After TVault re-configuration post addition of 2 more nodes to existing TVM cluster ("import workloads" was not seleted), the databases do not sync against already existing TVM.
    It is expected that while adding the 2 new nodes, the db on node1 should get synced up with 2 new nodes and the existing workloads should be available post the reconfig on the new 3 node TVM cluster.
Workaround:
    Run workload import from CLI

[exclude_boot_disk] Data on boot disk gets backed up despite exclusion

Observation:
    VM was set with metadata exclude_boot_disk_from_backup set to true
    Restored instance showed, that data was backed up and restored

After reinitialize and import Openstack certificates are missing

Observation:
    Reinitialize does not keep the already uploaded Openstack Certificates used to communicate with Openstack.
Workaround:
    Upload Certificates again

CLI import changes scheduler trust value to disabled

Observation:
    When the import functionality is used via CLI is the scheduler trust changed from enabled to disabled.
Workaround:
    Configure/re-configure TVO with import option from UI after reinitialize.

Unable to get node details after reinitializing the TrilioVault Appliance

Observation:
    After reinitializing was neither the UI nor CLI showing Node information
Workaround:
    Restart wlm-workloads and wlm-cron services on TrilioVault nodes
    systemctl restart wlm-workloads
    systemctl restart wlm-cron

Snapshots fails with "object is not subscriptable" for many workload jobs at the exact same time

Oberservation:
    Running more than 25 workloads at the exact same time leads to error
    dmapi service is not responding
    Snapshots fail with "object is not subscriptable"
Workaround:
Contact Trilio Support to implement a known workaround.

[Kolla Ansible] dmapi container stuck in restarting if storage backend changes

Observation:
    Just changing the backup target in the Kolla Ansible configuration files and redeploying leads to dmapi container stuck in restart
Workaround:

No operation is permitted in insecure way for ssl enabled Keystone URL

Observation:
    SSL enabled Openstack
    Backup and Restore jobs fail with with missing TLS CA certificate bundle error
Workaround:
    Configure the TrilioVault appliance with Openstack CA provided
    OR Provide Openstack CA to /etc/workloadmgr/ca-chain.pem
Last modified 7mo ago