Multi-Region Deployments
This document discusses OpenStack multi-region deployments and how Trilio (or T4O, which stands for Trilio For OpenStack) can be deployed in multi-region OpenStack clouds.
Last updated
Was this helpful?
T4O-5.x
This document discusses OpenStack multi-region deployments and how Trilio (or T4O, which stands for Trilio For OpenStack) can be deployed in multi-region OpenStack clouds.
Last updated
Was this helpful?
OpenStack is designed to be scalable. To manage scale, OpenStack supports various resource segregation constructs: Regions, cells, and availability zones to manage OpenStack resources. Resource segregation is essential to define fault domains and localize network traffic.
From an end user's perspective, OpenStack regions are equivalent to regions in Amazon Web Services. Regions live in separate data centers, often named after their location. If your organization has a data center in Chicago and one in Boston, you'll have at least a CHG and a BOS region. Users who want to disperse their workloads geographically will place some in CHG and some in BOS. Regions have separate API endpoints for all services except for Keystone. Users, Tenants, and Domains are shaped across regions through a single Keystone deployment.
Availability Zones are an end-user visible logical abstraction for partitioning a cloud without knowing the physical infrastructure. Availability zones can partition a cloud on arbitrary factors, such as location (country, data center, rack), network layout, and power source. Because of the flexibility, the names and purposes of availability zones can vary massively between clouds.
In addition, other services, such as the and the , also provide an availability zone feature. However, the implementation of these features differs vastly between these different services. Please look at the documentation for these other services for more information on their implementation of this feature.
Cells functionality enables OpenStack to scale the compute in a more distributed fashion without using complicated technologies like database and message queue clustering. It supports vast deployments.
Cloud architects can partition OpenStack Compute Cloud into groups called cells. Cells are configured as a tree. The top-level cell should have a host that runs a nova-api service but no nova-compute services. Each child cell should run all the typical nova-* services in a regular Compute cloud except for nova-api. You can think of cells as a regular Compute deployment in that each cell has its database server and message queue broker.
This document discusses OpenStack multi-region deployments and how Trilio can be deployed in multi-region OpenStack clouds.
OpenStack offers lots of flexibility with multi-region deployments, and each organization architects the OpenStack that meets their business needs. OpenStack only suggests that the Keystone service is shared between regions, and the rest of the service endpoints differ for different regions. RabbitMQ and MySQL databases can be shared or deployed independently.
The following code section is a snippet of OpenStack services endpoints in two regions.
Trilio backup and recovery service is architecturally similar to OpenStack services. It has an API endpoint, a scheduler service, and workload services. Cloud architects must deploy Trilio similarly to Nova or Cinder service with an instance of Trilio in each region, as shown below. Trilio deployment must support any OpenStack multi-region deployments compatible with OpenInfra recommendations.
Trilio services endpoints in a multi-region OpenStack deployment are shown below.
Deployment of Trilio on the Kolla multi-region cloud is straightforward. We need to deploy Trilio in every region of the Kolla OpenStack cloud using the Kolla-ansible deploy command.
Please take a look at the Trilio install document for Kolla.
For example, the Kolla OpenStack cloud has three regions.
RegionOne
RegionTwo
RegionThree
To deploy Multi-Region Trilio on this cloud, we need to install Trilio in each region.
Please follow the below steps:
Identify the kolla ansible inventory file for each region.
Identify the kolla-ansible deploy command that was used for OpenStack deployment for each region(Most probably, this is the same for all regions)
The customer might have used a separate “/etc/kolla/globals.yml“ file for each region deployment. Please check those details.
Now, for the following region deployment (RegionTwo), you can identify an ansible inventory file and the '/etc/kolla/globals.yml' file for that region. Also, could you identify the kolla-ansible deploy command used for that region?
Populate all Trilio config parameters in the ‘/etc/kolla/globals.yml’ file of RegionTwo. Or you can copy them from RegionOne’s '/etc/kolla/globals.yml' file.
Append Trilio inventory to the RegionTwo inventory file. Please take a look at section 3.4 of the Trilio install document.
If you use separate Kolla Ansible servers for each region, you must perform all the steps mentioned in the Trilio install document for Kolla again for RegionTwo. Using the same Kolla Ansible server for all region deployments, you can skip this for RegionTwo and all subsequent regions.
Review the Trilio install document, and if any other standard config file(like /etc/kolla/passwords.yml) is defined separately for each region, we need to check that Trilio uses that config file and perform any related steps from the Trilio install document.
Run the Kolla-ansible deploy command, which will deploy Trilio on RegionTwo.
Reference Document:
Deploy Trilio for the first region ( In our example, ‘RegionOne' ). Use it’s globals.yml. Follow the Trilio for Kolla-ansible. No other configuration changes are needed for this deployment.
Append the appropriate Trilio globals yml file to the/etc/kolla/globals.yml file; refer to section 3.1 from the Trilio install .
Repeat (Pull Trilio container images) from the Trilio install document for RegionTwo.
