Trilio network considerations
Trilio integrates natively with Openstack. This includes that Trilio communicates completely through APIs using the Openstack Endpoints. Trilio is also generating its own Openstack endpoints. In addition, is the Trilio appliance and the compute nodes writing to and reading from the backup target. These points affect the network planning for the Trilio installation.
Existing endpoints in Openstack
Openstack knows 3 types of endpoints:
Public Endpoints
Internal Endpoints
Admin 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 Trilio
Trilio is communicating with all services of Openstack on a defined endpoint type. Which endpoint type Trilio is using to communicate with Openstack is decided during the configuration of the Trilio appliance.
There is one exception: The Trilio Appliance always requires access to the Keystone admin endpoint.
The following network requirement can be identified this way:
Trilio appliance needs access to the Keystone admin endpoint on the admin endpoint network
Trilio 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 Trilio appliance to follow the Openstack standards and best practices.
Trilio is generating its own endpoints as well. These endpoints are pointing towards the Trilio Appliance directly. This means that using those endpoints will not send the API calls towards the Openstack Controller nodes first, but directly to the Trilio VM.
Following the Openstack standards and best practices, it is therefore recommended to put the Trilio endpoints on the same networks as the already existing Openstack endpoints. This allows to extend the purpose of each endpoint type to the Trilio service:
The public endpoint to be used by Openstack users when using Trilio 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 Trilio
The Trilio solution is using backup target storage to securely place the backup data. Trilio is dividing its backup data into two parts:
Metadata
Volume Disk Data
The first type of data is generated by the Trilio appliance through communicating with the Openstack Endpoints. All metadata that is stored together with a backup is written by the Trilio Appliance to the backup target in the json format.
The second type of data is generated by the Trilio 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 Trilio appliance needs access to the backup target
Every compute node needs access to the backup target
Example of a typical Trilio network integration
Most Trilio 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:
Following the Openstack standards and Trilio's recommendation will the Trilio Appliance be placed on all those 3 networks. Further is the access to the backup target required by Trilio Appliance and Compute nodes. Here done by adding a 4th network.
The resulting network configuration would look like this:
It is of course possible to combine networks as necessary. As long as the required network access is available will Trilio work.
Other examples of Trilio 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 Trilio 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 Trilio 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 Trilio just as recommended.
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 Trilio
The third example is from a service company that was forced to treat Trilio 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 Trilio endpoints and firewall rules.
Last updated
