Chapter 10. Web User Interface
Scaling a CloudForms installation usually implies that many users will be accessing the WebUI components. It is therefore prudent to scale the WebUI capability along with the CFME infrastructure components and workers to ensure that responsiveness and connection reliability are maintained.
The "Operations" or "Classic" WebUI (as opposed to the Self-Service UI) uses an Apache web server as a reverse proxy front-end to a Puma application server. Each instance of a MiqUiWorker worker is a Puma process.
10.1. Scaling workers
Most but not all of the UI transactions are written to be asynchronous, but a very few of them are either still synchronous or perform other processing. This can sometimes cause the MiqUiWorker process to appear unresponsive to other user sessions. An example of this can be seen when executing a long-running automate task from simulation in one browser window. Other browser sessions connected to the same MiqUiWorker process may appear hung until the simulation has completed.
A solution to this is to increase the number of WebUI workers. The default number of UI workers per CFME appliance or "cloudforms" StatefulSet replica is 1, but this can be increased to a maximum of 9. When increasing workers, consideration should be given to the additional CPU and memory requirements placed on the appliance or pod (the maximum memory threshold for a UI worker is 1GByte).
WebUI transactions initiated by each MiqUiWorker process are written into the production.log file. This is often a useful source of information when troubleshooting WebUI problems.
10.2. Scaling Appliances
To allow for a degree of fault-tolerance in a large CloudForms installation, it is common to deploy several dedicated WebUI CFME appliances or "cloudforms" StatefulSet replicas in their own zone for general user session use. Each of the CFME appliances or StatefulSet replica should be configured with a minimal set of server roles, for example:
- Automation Engine (to process zone events)
- Provider Operations (if services catalogs are used)
- Reporting (if logged-on users will be running their own reports)
- User Interface
- Web Services
- Websocket
10.2.1. Load Balancers
Multiple CFME appliances or StatefulSet replicas in a WebUI zone are often placed behind a load balancer. The load balancer should be configured with sticky sessions enabled, which will force it to send requests to the same UI worker during a session.
The load balancer should also be configured to test for connectivity using the CloudForms ping response page at https://cfme_appliance/ping. The expected reply from the appliance is the text string “pong”. Using this URL is preferable to the standard login URL as it does not establish a connection to the database.
By default the CloudForms UI workers store session data in the local appliance’s memcache, or the 'memcached' pod. For VM-based CFME appliances operating behind a load balancer the UI workers should be configured to store session data in the database. This prevents a user from having to re-login if the load balancer redirects them to an alternative server if their original UI worker is unresponsive.
The location of the session store is defined in the Configuration → Advanced settings. The default value for session_store is as follows:
:server: ... :session_store: cache
This should be changed to:
:session_store: sql
The session store can be safely left as cache for the podified deployment of CloudForms as all pods share a single memcache.
Where did the comment section go?
Red Hat's documentation publication system recently went through an upgrade to enable speedier, more mobile-friendly content. We decided to re-evaluate our commenting platform to ensure that it meets your expectations and serves as an optimal feedback mechanism. During this redesign, we invite your input on providing feedback on Red Hat documentation via the discussion platform.