Chapter 2. Planning

This guide provides some general guidelines to planning a deployment on Red Hat CloudForms. This includes creating multiple regions containing Red Hat CloudForms appliances, CPU sizing recommendations, database sizing recommendations, and database configuration.

2.1. Regions

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.

7151

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.

Note
  • Replicating a parent region to a higher-level parent is not supported.
  • Parent regions can be configured after the child regions are online.

The following diagram provides a closer look at a region:

7150

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).

Note

CloudForms can be configured in a highly available setup. In this case, all PostgreSQL instances must be running on a server that is deployed from the CloudForms appliance. High availability is achieved by database replication between two or more database servers. For more information, see Configuring High Availability.

2.2. Roles

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.

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.

2.3. Centralized Administration

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:

  • Virtual machine provisioning
  • Service provisioning
  • Virtual machine power operations
  • Virtual machine retirement
  • Virtual machine reconfiguration

Centralized Administration Diagram

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.

Note

The operations initiated from the global region are subject to the role-based access control (RBAC) rules on the remote region. The user in the remote region which matches the logged-in user’s user ID will be used to enforce RBAC in the target region. The operation will fail on the remote system if the user does not have the required permissions.

For information on how to configure centralized administration via database replication, see the section on Configuring Database Replication and Centralized Administration in the General Configuration guide.

2.4. Tenancy

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.

Note

If you do not add any additional tenants, all resources and user accounts are contained in a single base tenant which is your CloudForms appliance itself. In CloudForms, is sometimes referred as tenant zero.

Tenancy Account Roles

In CloudForms, the following two account roles are associated with tenancy:

  • Tenant administrator
  • Tenant quota administrator

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

Important

Tenant administrator and tenant quota administrator roles are like administrator and super administrator. These roles are not limited to the tenant upon which they are acting and act across all tenants, and therefore should be considered privileged users. These are not roles inside a tenant.

Tenancy Models

The following two approaches exist for tenancy planning:

  • Tenantless - You can create a single large tenant, sometimes referred as tenant zero, and perform all your operations in there without any subdivision of resources or user accounts.
  • Enterprise model - A common scenario is to create a single tenant, and then subdivide it based on the structures or departments within your organization. Those departments are then able to further subdivide their resources into distinct projects. With this model, you have a single URL for user access, while still having the ability to divide resources into nested hierarchical tenants.

Tenancy Configuration

You can create and configure tenancy using the CloudForms user interface in the same place you set up users, groups and roles by selecting Configuration from the settings menu, and then clicking on the Access Control accordion. See the section on Access Control in the General Configuration guide for procedures on how to create tenants and projects, users, and groups.

Tenancy in Automation

One of the features of tenancy is that each tenant can have its own automate domain. Tenant-based domains can help in several use cases, such as if you have:

  • groups that need their own naming routines
  • varying types of approval needs
  • departments that use different end ticketing systems
  • a customer who is a holding company or centralized IT organization for managing different business units

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.

Tenancy Quota and Reporting

You can allocate and enforce quotas for the following attributes:

  • Virtual CPUs
  • Memory in GB
  • Storage in GB
  • Number of virtual machines
  • Number of templates

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.

Note

Currently, in tenant quota reports you will see all of the tenants but there is no nesting information available by parent and child tenants.

Example:

In the following example of a tenant quota report, DevOps Teams is a parent tenant and Team Alpha and Team Bravo are child tenants.

tenant quotas report

  • Total Quota: Total quota enforced per attribute for a tenant
  • In Use: Amount of quota currently in use by tenants
  • Allocated: Amount of quota given to all child tenants
  • Available: Total Quota minus (-) In Use minus (-) Allocated

Tenancy Chargeback

You have the ability to do tenancy in chargeback where you are able to assign rates and have a different rate for each tenant. You can make use of the default rate or create your own set of rates depending on the tenant. As well, there is an ability to create chargeback reports by tenant.

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.

Tenancy Service Catalogs

Similar to automate domains, you can have service catalogs at each level of tenancy. Once you add a service catalog at a particular level of tenancy, it is visible to that tenant and its children (unless you use tagging to exclude).

Tenancy Providers

Providers can be added at any level of tenancy. Once added, a provider is visible to any child or lower tenants, making it possible to easily separate resources that are owned or accessed by one group, and should not be available to other tenants.

2.5. Using a Load Balancer

Deploying several CloudForms appliances with a load balancer can be useful for performance.

However, running several appliances behind a load balancer can cause login issues from the Self Service user interface because memcached, the service storing the session in memory, is not shared between the appliances. To prevent this, configure your environment using the steps below to run the memcached service on one appliance and have it shared with the other appliances.

Important

When using this configuration, always start the appliance that owns memcached first, and ensure that memcached is running before starting the additional appliances. Starting another appliance before the memcached appliance may result in starting or login issues.

The following example shows configuration on two appliances, appliance1 and appliance2:

  1. On appliance1, open the 11211 port in the firewall: 

    # firewall-cmd --add-port=11211/tcp --permanent
# firewall-cmd --reload

  2. On appliance1, configure the server’s advanced settings by navigating to the settings menu, selecting Configuration, then the Advanced tab: 

    :session:
  :memcache_server: 127.0.0.1:11211
  :memcache_server_opts: "-l 0.0.0.0 -I 1M"

    This configures memcached to run on appliance1, but listen to all servers (-l 0.0.0.0). The memcache_server line, which specifies where it connects to, remains set as itself (127.0.0.1).

  3. Click Save.

  4. Restart appliance1: 

    # systemctl restart evmserverd

  5. Configure appliance2 to point to appliance1 by specifying the IP address for appliance1 in the memcache_server line. Configure this in the server’s advanced settings by navigating to the settings menu, selecting Configuration, then the Advanced tab: 

    :session:
  :memcache_server: <appliance1>:11211
  :memcache_server_opts: "-l 127.0.0.1 -I 1M"
  6. Click Save.

  7. Restart appliance2: 

    # systemctl restart evmserverd

You can then get an API token from appliance1, and use it to access the API from appliance2. See Using Authentication Tokens in the REST API guide for instructions.

The shared memcached service now runs only on appliance1, and any other appliance accesses memcached from that appliance. Configure additional appliances with the steps for appliance2.

CloudForms