TrilioVault integrates natively with Openstack. This includes that Triliovault communicates completely through APIs using the Openstack Endpoints. TrilioVault is also generating its own Openstack endpoints. In addition, is the TrilioVault appliance and the compute nodes writing to and reading from the backup target. These points affect the network planning for the TrilioVault installation.
Existing endpoints in Openstack
Openstack knows 3 types of endpoints:
Each of these endpoint types is designed for a specific purpose. Public endpoints are meant to be used by the Openstack end-users to work with Openstack. Internal endpoints are meant to be used by the Openstack services to communicate with each other. Admin endpoints are meant to be used by Openstack administrators.
Out of those 3 endpoint types does only the admin endpoint sometimes contain APIs which are not available on any other endpoint type.
To learn more about Openstack endpoints please visit the official Openstack documentation.
Openstack endpoints required by TrilioVault
TrilioVault is communicating with all services of Openstack on a defined endpoint type. Which endpoint type TrilioVault is using to communicate with Openstack is decided during the configuration of the TrilioVault appliance.
There is one exception: The TrilioVault Appliance always requires access to the Keystone admin endpoint.
The following network requirement can be identified this way:
TrilioVault appliance needs access to the Keystone admin endpoint on the admin endpoint network
TrilioVault appliance needs access to all endpoints of one type
Recommendation: Provide access to all Openstack Endpoint types
Trilio is recommending providing full access to all Openstack endpoints to the TrilioVault appliance to follow the Openstack standards and best practices.
TrilioVault is generating its own endpoints as well. These endpoints are pointing towards the TrilioVault Appliance directly. This means that using those endpoints will not send the API calls towards the Openstack Controller nodes first, but directly to the TrilioVault VM.
Following the Openstack standards and best practices, it is therefore recommended to put the TrilioVault endpoints on the same networks as the already existing Openstack endpoints. This allows to extend the purpose of each endpoint type to the TrilioVault service:
The public endpoint to be used by Openstack users when using TrilioVault CLI or API
The internal endpoint to communicate with the Openstack services
The admin endpoint to use the required admin only APIs of Keystone
Backup target access required by TrilioVault
The TrilioVault solution is using backup target storage to securely place the backup data. TrilioVault is dividing its backup data into two parts:
Volume Disk Data
The first type of data is generated by the TrilioVault appliance through communicating with the Openstack Endpoints. All metadata that is stored together with a backup is written by the TrilioVault Appliance to the backup target in the json format.
The second type of data is generated by the TrilioVault Datamover service running on the compute nodes. The Datamover service is reading the Volume Data from the Cinder or Nova storage and transferring this data as qcow2 image to the backup target. Each Datamover service is hereby responsible for the VMs running on its compute node.
The network requirements are therefor:
The TrilioVault appliance needs access to the backup target
Every compute node needs access to the backup target
Example of a typical TrilioVault network integration
Most TrilioVault customers are following the Openstack standards and best practices to have the public, internal, and admin endpoints on separate networks. They also typically don't have any network yet, which can access the desired backup target.
The starting network configuration typically looks like this:
Typical Openstack Network configuration before TrilioVault gets installed
Following the Openstack standards and Trilio's recommendation will the TrilioVault Appliance be placed on all those 3 networks. Further is the access to the backup target required by TrilioVault Appliance and Compute nodes. Here done by adding a 4th network.
The resulting network configuration would look like this:
Typical Openstack network configuration with TrilioVault installed
It is of course possible to combine networks as necessary. As long as the required network access is available will TrilioVault work.
Other examples of TrilioVault network integrations
Each Openstack installation is different and so is the network configuration. There are endless possibilities of how to configure the Openstack network and how to implement the TrilioVault appliance into this network. The following three examples have been seen in production:
The first example is from a manufacturing company, which wanted to split the networks by function and decided to put the TrilioVault backup target on the internal network as the backup and recovery function was identified as an Openstack internal solution. This example looks complex but integrates TrilioVault just as recommended.
The split them all network example
The second example is from a financial institute that wanted to be sure that the Openstack Users have no direct uncontrolled network access to the Openstack infrastructure. Following this example requires additional work as the internal HA-Proxy needs to be configured to correctly translates the API calls towards the TrilioVault
The no trust network example
The third example is from a service company that was forced to treat TrilioVault as an external 3rd party solution, as we require a virtual machine running outside of Openstack. This kind of network configuration requires good planning on the TrilioVault endpoints and firewall rules.
TrilioVault as third party component network example