Regions are used for centralizing data which is collected from public and private virtualization environments. A region is ultimately represented as a single database for the VMDB. Regions are particularly useful when multiple geographical locations need to be managed, as they enable all the data collection to happen at each particular location and avoid data collection traffic across slow links between networks.

When multiple regions are being used, each with their own unique ID, a master region can be created to centralize the data of all the children regions into a single master database. To do this, configure each child region to replicate its data to the master region database (Red Hat recommends use of region 99, though any number up to three digits will work). This parent and child region is a one-to-many relationship.

Regions can contain multiple zones, which in turn contain appliances. Zones are used for further segregating network traffic along with enabling failover configurations. Each appliance has the capability to be configured for a number of specialized server roles. These roles are limited to the zone containing the appliance they run on.

Only one failover type of each server role can run in a zone. If multiple appliances have the same failover role, the extras are used as backups that activate only if the primary appliance fails. Non-failover server roles can run on multiple appliances simultaneously in a zone, so resources can be adjusted according to the workload those roles are responsible for.

The following diagram demonstrates an example of the multiple regions working together in a Red Hat CloudForms environment.

The master appliance is located in Chicago and contains a master region and a subregion that manages the worker appliances. The Mahwah technology center contains a single subregion that manages two zones. Likewise, the San Diego technology center contains a single subregion managing a single zone.

The following diagram provides a closer look at a region:

In this region, we have several Red Hat CloudForms appliances acting as UI nodes and worker nodes. These worker nodes execute tasks on the providers in your environment. The region also uses a region database that reports to a master database on the main Red Hat CloudForms appliance. All appliances can connect to the authentication services (Active Directory, LDAP, Identity Management), outgoing mail (SMTP), and network services (SNMP).

Server roles define what a server can do. Assigning different server roles to appliances can allow them to focus on specific functions. When planning a deployment, consider which roles to assign to each appliance. Some server roles are enabled by default in CloudForms. Many server roles start worker processes.

Some roles are also dependent on other roles. For example, because the CloudForms user interface relies on the API for access, the Web Services role must be enabled with the User Interface role for users to log in to the appliance. See Server Roles in General Configuration for details on each server role and its function.

Red Hat CloudForms includes centralized administration capabilities, where operations can be initiated from the global region and processed and executed on the remote region. This includes the following life cycle management operations:

With centralized administration, the remote_queue_put leverages a new system-to-system REST API request to forward the original request to the remote region. This request is put in the local queue in the remote region, which is then delivered by a worker in the remote region as if it was queued there all along. As a result, a CloudForms operator in the global region can be seen as provisioning on behalf of a remote region.

In CloudForms 4.5 and above, configuring database replication automatically enables centralized administration, eliminating the need for further configuration. See the section on Configuring Database Replication and Centralized Administration in the General Configuration guide.

Red Hat CloudForms supports multitenancy. Tenants can be totally separate or they can be in a parent-child or peer relationship. Tenants in a relationship can share or inherit a certain configuration. You can subdivide and create child tenants and they, in turn, can have child tenants, and so on. The ability to have multi-level (nested) tenants in a hierarchy enables those at the bottom to inherit permissions from those above. This configuration allows for granular user permissions to be set on specific tenants.

A tenant can also contain a self-contained child tenant known as a project. A project cannot have a child tenant, but is useful for allocating resources to a small group or team within a larger organization.

See Account Roles and Descriptions in the General Configuration guide for more information about these roles.

Just like standard domains are nested, you can also add automate domains that are nested at the tenant level. For the procedure on how to create a new automate domain, see Scripting Actions in CloudForms.

See the section on Managing Tenant and Project Quotas in the General Configuration guide for procedures on how to create and manage quotas.

You can generate or schedule a report for Tenant Quotas similar to other reports. See Reports in the Monitoring, Alerts, and Reporting guide for procedures on how to view or schedule a report.

See Chargeback in the Monitoring Alerts, and Reporting guide for information on how to create and assign default or custom chargeback rates, and how CloudForms calculates chargeback costs.

Deploying multiple user interface worker appliances and placing them behind a third-party load balancer allows for redundancy and improved performance. This requires extra configuration in both the load balancer and in the CloudForms user interface worker appliances.