Search for	Example	Results
A single word	`cat`	Topics that contain the word "cat". You will also find its grammatical variations, such as "cats".
A phrase. You can specify that the search results contain a specific phrase.	`"cat food"` (quotation marks)	Topics that contain the literal phrase "cat food" and all its grammatical variations. Without the quotation marks, the query is equivalent to specifying an OR operator, which finds topics with one of the individual words instead of the phrase.

Search for	Operator	Example
Two or more words in the same topic	`AND` `and` `+` (plus symbol) `&` (ampersand)	`cat AND dog` `"cat food"+milk` `"cat food"&"dog food"`
Either word in a topic	`OR` `or` `\|` (pipe)	`cat OR dog` `cat \| dog`
Topics that do not contain a specific word or phrase	`NOT` `not` `!` (exclamation point)	`NOT cat` `! dog`
Topics that contain one string and do not contain another	`^` (caret)	`cat ^ mouse`
A combination of search types	`( )` parentheses	`cat + (dog \| mouse)` `cat \| dog + (! mouse)`

Cloud Service Automation4.80

Administer > HA Configuration

HA Configuration

This section gives you information on how to configure a cluster for high availability using Apache web server and the Load Balancer.

Cluster configuration using an Apache web sever/a load balancer overview

HPE Cloud Service Automation (CSA) uses JBoss clustering technology to enable you to configure an active/active (high-availability) cluster. Clustering enables you to run CSA on several parallel servers called nodes. Cluster configuration improves performance on systems that handle high transaction volumes or large numbers of concurrent users. In addition to handling higher user loads and providing greater scalability, the cluster configuration supports server failover features.

Web requests to the CSA Controller or Marketplace Portal are load balanced among the nodes in the cluster. Increasing the number of nodes in the cluster will improve web request transaction throughput. Increasing the number of nodes in the cluster will also improve the response time by CSA fulfillment services to a high volume of concurrent deployment requests.

Because clustering distributes the workload across different nodes, if any node fails, CSA remains accessible through other nodes in the cluster. You can continue to improve CSA throughput by simply adding nodes to the cluster. If a node shuts down, activities such as email notifications that are scheduled to run on that node are automatically transferred to another available node. This server failover feature helps ensure that CSA remains operational.

Unsaved changes on a node that shuts down are lost and are not transferred to an available node. Users who log on to CSA after a node shuts down see only changes that were saved on that node.

Note In this document, path names beginning with the home directory such as CSA_HOME, apply to both Windows and Linux path names, even though they appear in Linux format.

Example cluster configuration

In the following diagram, the example cluster configuration consists of: seven different physical (or virtual) hosts:

Three hosts are running CSA in standalone mode
Three hosts are running the Marketplace Portal.
For load balancer:
- One host is running a load balancer that proxies web requests into the CSA/JBoss cluster or Node.js cluster (for the Marketplace Portal)
For Apache:
- One host is running an Apache Web server with the mod_proxy_balancer module (a software load balancer that is available from Apache and is configured on an Apache HTTP server so that web requests can be proxied into the CSA/JBoss cluster and a Node.js cluster for the Marketplace Portal).
- A host for Operations Orchestration and Database configuration.

Note Content on how to use a database cluster or Oracle RAC is beyond the scope of this document. However, configuring CSA to use a Microsoft SQL Server cluster is no different from configuring CSA to use a standalone Microsoft SQL Server. Install and configure the Microsoft SQL Server cluster according to the manufacturer’s documentation and follow the instructions to install CSA using a Microsoft SQL Server in the Cloud Service Automation Installation Guide.

For information about configuring CSA with Oracle RAC, see the Configuring CSA to Work with Oracle RAC whitepaper.

Example cluster configuration diagram

The cluster uses an Apache/a load balancer to distribute requests among any number of nodes. The Apache/load balancer (internal or external) listens for HTTP/S requests from standard interface clients and forwards them to one of the nodes. These nodes are transparent to users and users access only the URL to the Apache/ load balancer.

Request flow

The following diagrams show how a request (distributed from the Apache/load balancer) is processed in the clustered environment for the Cloud Service Management Console and Marketplace Portal.

Cloud Service Management Console request flow

Marketplace Portal request flow

About the examples

In this document, the following names are used to identify the hosts or nodes in the clustered environment:

Apache/Load_Balancer node: the load balancer that distributes requests among the nodes in the clustered environment
CSA_Node nodes: hosts CSA
MPP_Node nodes: hosts the Marketplace Portal

In this document, an item denoted in square brackets is a placeholder for the actual value that has been configured (for example, the hostname of the CSA_Node1 node is denoted as [CSA_NODE1_HOSTNAME]).

In the following diagram, items in parentheses are default or example values used in this document (for example, the default HTTP port used by the Cloud Service Management Console is 8081).

Example values for Example cluster configuration using a load balancer

To set up the nodes, you must have knowledge of or work with someone who has knowledge of CSA, Operations Orchestration, Apache/load balancers, JBoss, and resource providers that will be integrated with CSA.

General notes about configuring a clustered environment

The following information should be considered when configuring a clustered environment:

It is recommended that you install and configure the nodes in the order presented in this guide. There are some tasks that are dependent on this order (such as generating certificates and importing them).

Install and configure the Apache/load balancer node first. Follow the manufacturer's recommendations to install and configure the Apache/load balancer.
The system time among all nodes in the cluster must be synchronized. If the time is not synchronized, users may experience problems such as not being able to log in to the Marketplace Portal.
CSA must be installed in the same directory on all nodes. Some file locations are hardcoded in configuration files and, if these file locations do not match among nodes, CSA fails to start.
Note This is applicable only for Apache web server as a load balancer:

When using CSA to configure an organization, if you are using the Apache web server as a load balancer in a clustered environment (as described in this document), do not use a semicolon (;) or plus sign (+) in the organization's name. If one of these characters is present in the organization's name, you may not be able to log in to the Marketplace Portal.

JavaScript files are used to implement dynamic properties in CSA. All JavaScript files are stored in the CSA database. The JavaScript files are managed using the application UI and the changes apply to all nodes in a cluster. Managing the JavaScript directly on the server filesystem is no longer possible. For details about developing and using JavaScripts in CSA, see the Dynamic Options and Cascading Lists white paper.

Caution Use caution when deleting or modifying a script. In a clustered environment, the script will be removed or modified on all nodes.
JSP files can also be used to implement dynamic properties in CSA. However, the JSP files have been deprecated due to security and technical issues, so the way these files are used in a clustered environment is different from the way JavaScript files are used. The JSP files are also stored in the CSA database, but they cannot be run from the database. Because of that, CSA copies the JSP files from the database to the particular node filesystem from which they are being executed. It is possible to override a JSP in the database by placing a custom version of the same JSP on the node filesystem. Such a custom JSP is not propagated to the other nodes in a cluster however. For details about developing and using JSP scripts in CSA, see the Dynamic Options and Cascading Lists white paper.

Check for updates

Documentation may be updated periodically. To check for recent updates or to verify you are using the most recent edition of a document, click the "go" link to download the guide from the HPE Software Support portal. HPE Passport login is required.

Document	Link
Configuration Guide	go
Cluster Configuration Guide Using a Load Balancer	go
Cluster Configuration Guide Using an Apache Web Server	go
FIPS 140-2 Compliance Configuration Guide	go
FIPS 140-2 Compliance Statement	go

To configure the:

Apache load balancer node, see Configure the Apache load balancer node.
Load balancer node, see Configure the load balancer node

Send Help Center feedback