Installation Scenarios for ARA

This chapter provides an overview on how you can set up AutomicAutomic Release Automation in your organization.

The user of Automic Release Automation uses the ARA Client with browser-based access to Web Application and user interfaces. One of the clients will be used for administrative purposes. Therefore database management tools will be installed on one of the clients additionally.

All components (see ARA Architecture) can either be installed on one server (one box installation) or on separate servers, even with different operating systems. The requirements for each component are described in the subsequent General Requirements for Automic Release Automation chapters. For a Proof of Concept installation we recommend using one server, based on the latest Microsoft Windows Servers.

The relationship between the various components depends on how you implement ARA in your organization:

All components run on one server.
All application components on one server, with a separate database server/cluster:
- With one database server/cluster.
- With two separate database servers.
Two servers with separate, local database servers.

For an illustration and explanation for each of these, see the sections that follow.

Before starting with the deployment of Automic Release Automation modules, we strongly recommend to get familiar with the structure and inter-dependencies (see ARA Architecture) of modules as well as General Requirements for Automic Release Automation. Additionally, you are requested to come to basic decisions on user & user groups, and to define authorization hierarchy and naming conventions.

ARA Implementation on One Server

The following illustration describes how the various systems, operating systems, agents, servers and databases interact when you implement everything on one server:

Click to expand

In this scenario the following applies:

ARA CLI can be installed on any Windows-machine
Agent-Setup is an example: Distribution of agents needs to be designed according to needs of specific IT architecture (network security, scalability). A typical setup includes one agent on the central server for all Database- and Webservices-related actions and local agents for all the other deployment targets. For application server management, there will be typically one agent on the administration server of a domain or cell (Weblogic, Websphere) or locally for standalone servers and for JBOSS, one local agent on any of the JBOSS instances in a farm is recommended. For IIS management, a local agent is required. For Apache Tomcat, a local agent is recommended.

ARA Implementation on One Server but with Separate Databases

You can install all components, except the database components, on one server and have the databases on a separate server or cluster. Two variations of this installation scenario are described here:

The ARA and the Automation Engine databases on the same server, separate from all the other components.
The ARA and the Automation Engine databases each on their own servers, and separate from the server for all the other components.

Illustrations of each of these scenarios for separate database servers follow.

All Databases on One Server Separate from All Other Components

The following illustration describes the relationship between the various components, web servers and databases, when the databases are located on a separate server.

Click to expand

The operating system interactions are excluded from this description, but they are still part of the overall processing. For a detailed view of all components in an ARA installation, see the scenario described in ARA Implementation on One Server.

Each Database on Its Own Server and Separate from All Other Components

The following illustration describes the relationship between the various CA Automic Release Automation components, web servers and databases, when the two databases are located on their own servers, separate from all other components.

Click to expand

ARA Implementation on Two Servers with Local Databases

You can install all the ARA components and the Automation Engine components on separate servers, as illustrated here:

Click to expand

Variations

Further feasible variations on the previous scenario would be:

Having the databases on additional, separate servers. This would be a combination of the previous illustration and the scenarios illustrated in ARA Implementation on One Server but with Separate Databases.
Installing AWI on the Automation Engine server or on a separate server altogether.

ARA Implementation with an Active/Active Configuration

You can install ARA with all its related components and run them in using and active/active configuration. In this case you will need to use a separate load balancing component to manage the traffic between components by detecting outages and dynamically re-routing traffic as needed.

If you choose to use an active/active configuration, be aware of the following:

Fail-over may take up to 15 seconds of downtime.
User sessions are not automatically transferred, so users will need to log in again.
Active/active mode can be used only for servers. Databases must be shared between all instances.
Sticky sessions must be supported. Like many Java webapps, ARA uses the JSESSIONID session cookie. You can configure your load balancer to use this cookie or add its own to route requests of the same session to the same server.
If you run ARA with websockets enabled, your load balancer must support them.
Please use the same path on your load balancer and the servlet containers. Example: If your servers are located on http://backend1/ara and http://backend2/ara, and your load balancer is located on the host publicatahost, configure your load balancer to serve ARA on http(s)://publicarahost/ara
The AWI instance and the ARA instance of an installation are bound together. Therefore, the AWI instance defined in the customer.config file and the ARA instance defined in the connection.properties file of the webui-plugin-bond folder must point to the corresponding AWI/ARA instances of the same installation.

The following illustration shows you the overall relationship between components when implementing ARA with an active/active configuration. The diagram below illustrates the active/active configuration with one server as a high level overview.

Running an ARA installation in active/active configuration with a single server scenario

In this scenario, frontend and backend components are installed on the same server (single-box installation).

Instead of connecting directly to a server, web client requests go through the load balancer. The load balancer is a traffic manager that distributes workloads across all available servers in order to prevent any of them from getting overloaded and users getting timeouts.

To do so, servers have to be defined as nodes and then added as members to a load balancing pool (which is in turn associated with a virtual server). The load balancing method used by the pool decides how to distribute requests coming in: send request to next server in line, to a server with a predefined ratio weight, to a server with the least number of current connections, etc...

ARA allows the first request to be dispatched according to the selected load balancing method. The subsequent requests, however, will be assigned to the same instance, regardless of the method configured in the pool.

E.g. An Import/Export request is executed from AWI to ARA (the request is executed on server ARA1). Right after a new request is sent to execute GetStatus and check the result on an ARA instance. This and the subsequent requests will always be executed on server ARA1, regardless of the method selected.