High Availability Configuration for XTAM Deployments

XTAM High Availability (HA) option is deployed using two or more XTAM nodes with the same software connected to a single database and balancing HTTP traffic using a Load Balancer or Virtual IP technologies. XTAM HA option allows the system to continue operating in case one of the nodes malfunctions. In addition to that, XTAM HA option when deployed using a load balancer scenario improves overall system performance by splitting the load across multiple nodes.

High Availability Option Concepts

Below is a basic network diagram that should provide a visual to the following content in this article. It demonstrates a load balanced instance of XTAM, using two XTAM nodes with a replicated external database and file share.

 

Diagram-2-NodeSample

High availability farm could be deployed to either a series of Unix or Windows servers, using load balancer to distribute traffic between nodes.

 

Server 1: Hosts Database server. Both XTAM nodes A and B will be configured to use this external Database instance as their database.

 

Server 2: Load Balancer. See considerations about selecting a load balancer below. SSL certificate will be deployed to Load Balancer for security. Read more about advanced network load balancer deployments in Front-End Server Architecture article.

 

Server 3: Hosts XTAM node A.

 

Server 4: Hosts XTAM node B.

 

The following describes the basic configuration of each server, not the order of operations in which they should be deployed. Database server should be setup before XTAM nodes A and B for example.

High Availability Option Setup

1. Database Server

Install or use an existing Database server database. The XTAM Internal Database is not supported for High Availability deployments. You must use one of the supported External Database options.

Both XTAM nodes will be configured with identical database parameters.

2. Load Balancer

Load Balancer could be used for HA configurations. In this case, Load Balancer has to support sticky sessions (session affinity) in any form (cookie based or IP based) because XTAM back end protocols (RDP, SSH) are stateful. XTAM has an option for WEB Sessions (users see RDP screens or SSH terminals in WEB Browser Window) or sessions using native clients (PuTTY, MS RDP, HTTP proxy, etc). If you plan to use native clients then the load balancer has to support TCP-level balancing (HTTP proxy sessions to WEB Portals run through non-HTTP protocol). WEB Sessions and WEB GUI could be supported by HTTP-only load balancer.

To illustrate this idea – some TCP level Load Balancers do not support sticky sessions for multi-zone balancing. To resolve it, some of our clients use both HTTP Load Balancer for WEB Browsing and WEB Sessions and TCP Load Balancer on different IP and QNAME for native clients while some other clients choose to host XTAM nodes in the same zone to use a single TCP LB. Some TCP Load Balancer (such as F5) do support sticky sessions for multi-zone hosting though. XTAM does not mandate any of these solutions – just be aware about the requirements and check with LB vendor if needed. Also, you can change LB some time later.

Single node XTAM deployment (such as for staging or test areas) could be operated without LB. XTAM can terminate SSL connection itself, switched to listen on default port 443 (if OS supports it) and serve both WEB GUI, WEB and native sessions.

Multi-node XTAM deployments could also operate in standby mode providing HA but not a load distribution. In this case two XTAM nodes could operate on different URLs or use Virtual-IP shifters such as MS NLB of Keealived.

3. XTAM node A

Install Windows Server and assign a static IP. Reference this IP when configuring the Server Farm in your load balancer.

Run XtamSetup.exe and choose the following options:

  • Directory Service
  • Application GUI
  • Job Engine
  • Session Manager
  • Federated Sign-In (optional)

When prompted for a database connection, enter the values for your Database server instance.

Configure your AD integration using AD server, user and password.

Complete installation and save your password information to a file.

4. XTAM node B

Install Windows Server and assign a static IP. Reference this IP when configuring the Server Farm in your load balancer.

Run XtamSetup.exe and choose the following options:

  • Directory Service
  • Application GUI
  • Job Engine
  • Session Manager
  • Federated Sign-In (optional)

When prompted for a database connection, enter the values for your Database server instance.

Configure your AD integration using AD server, user and password.

Complete installation and save your password information to a file.

Update the XTAM master password on node B with the one from node A by issuing the following command from the command line in $XTAM_HOME folder:

For Windows:

Copy
bin\PamDirectory SetMasterPassword web MASTER PASSWORD FROM NODE A

 

For Linux:

Copy
bin/PamDirectory.sh SetMasterPassword web MASTER PASSWORD FROM NODE A

 

Rather than entering the master password into the command, you can instead use a – (dash character). When this command is executed with a dash, you will prompted to enter the password.

bin\PamDirectory SetMasterPassword web –

bin/PamDirectory.sh SetMasterPassword web –

Synchronize keys for SSH, RDP and HTTP Proxies

 

$XTAM/content/keys/sshd.keypair

$XTAM/content/keys/certificate_rdp.cer

$XTAM/content/keys/keystore_rdp.p12

$XTAM/content/keys/certificate.cer

$XTAM/content/keys/keystore.p12

5. Setup Federated Sign-In Component in Multi-Node configuration

When using Federated Sign-In Component for the user authentication, synchronize this module on both nodes by copying the following parameters from $XTAM_HOME/web/conf/catalina.properties file from XTAM Node A to XTAM Node B and restart management service on the Node B

Copy
cas.ticket.registry.jpa.crypto.signing.key=VALUE
cas.ticket.registry.jpa.crypto.encryption.key=VALUE

cas.tgc.crypto.encryption.key=VALUE
cas.tgc.crypto.signing.key=VALUE

cas.webflow.crypto.signing.key=VALUE
cas.webflow.crypto.encryption.key=VALUE

6. Setup Local User Directory Replication

When using XTAM local users and groups, setup up replication between local user directory services on Nodes A and B.

  1. On XTAM Node A, open a command prompt and navigate to the XTAM installation directory
  2. Execute the following command replacing the values with those of XTAM Node B:

    • {ads.remote.server} : The host name or IP of XTAM Node B (make sure port(s) 10636 and 10389 are open)

    • {ads.remote.password} : The “Directory Password” of XTAM Node B that was generated during installation

    For Windows:

    Copy
    bin\PamDirectory.cmd ADSReplicate web {ads.remote.server} {ads.remote.password}

    For Linux:

    Copy
    bin/PamDirectory.sh ADSReplicate web {ads.remote.server} {ads.remote.password}
  3. On XTAM Node B, open a command prompt and navigate to the XTAM installation directory

  4. Execute the following command replacing the values with those of XTAM Node A:

    • {ads.remote.server} : The host name or IP of XTAM Node A (make sure port(s) 10636 and 10389 are open)

    • {ads.remote.password} : The “Directory Password” of XTAM Node A that was generated during installation

      For Windows:

      Copy
      bin\PamDirectory.cmd ADSReplicate web {ads.remote.server} {ads.remote.password}

      For Linux:

      Copy
      bin/PamDirectory.sh ADSReplicate web {ads.remote.server} {ads.remote.password}
  5. Wait a few minutes for the replication to complete, restart PamDirectory Service on XTAM Nodes A and B and then refresh your browser.