Page tree
Skip to end of metadata
Go to start of metadata

Your high-availability TrueSight Operations Management environment can include a high-availability setup of Atrium Single Sign-On, regardless of whether you use the embedded database or an external LDAP server in your deployment of Atrium Single Sign-On. 

Although BMC does not recommend using the embedded Atrium Single Sign-On database to authenticate users in an enterprise environment, no technical barriers exist to prevent you from doing so. However, when setting up Atrium Single Sign-On for high availability, BMC recommends that you use an external LDAP system.

Related topics

TrueSight Presentation Server high availability deployment

High availability deployment for TrueSight Operations Management

Installing Atrium Single Sign-On as a high-availability cluster

Using LDAP (Active Directory) for authentication

You must install and configure Atrium Single Sign-On for high availability before installing the TrueSight Presentation Server. Although Atrium Single Sign-On supports SAML and two-factor authentication, the TrueSight Presentation Server does not support these capabilities. To view the supported external authentication. see Atrium Single Sign-On system requirements.

Before you begin

Configuring high availability using the embedded Atrium Single Sign-On database

When you choose to implement Atrium Single Sign-On with its embedded database, BMC recommends that you set up two independent ASSO servers and manually keep them in sync.

For example, you would create a user on ASSO Server1 and create the same user on ASSO Server2.

You cannot copy configuration data from one Atrium Single Sign-On server to another if the host names are different, and Atrium Single Sign-On does not provide a mechanism to import and export, or copy from one ASSO server to another.

In the event of a failure, perform the following steps to re-register active Atrium Single Sign-On server with the Presentation Server: 

  1. Run the following command to re-register the active Atrium Single Sign-On server with TSPS: 
    tssh properties set bmc.sso.servername <new asso server>
  2. Run the following command to apply the changes:
    tssh properties reload

Configuring high availability for Atrium Single Sign-On using external LDAP authentication

When integrating Atrium Single Sign-On with your LDAP system, you can configure two ASSO servers and use a load balancer to connect to the TrueSight Presentation Server.

You can configure the ASSO servers as though they were Active/Active nodes; however, you must configure the load balancer as described in the following steps.

  • You must configure the load balancer to connect to one of the ASSO servers at all times. 
  • If the first ASSO server fails, load balancer must switch to the second ASSO server in a controlled manner. 

Atrium Single Sign-On keeps the passive node in sync using built-in Atrium Single Sign-On technology; therefore, you do not need to manually configure synchronization activities.

Typical high-availability deployment


assoHA_TSPS  

High-availability deployment notes

  • All traffic from the TrueSight Presentation Server, and other products, goes to the virtual IP address of the load balancer.
  • The built-in health monitors determine the state of the load-balancer pool members. You can also turn a pool member on or off by changing the content of a file on the target system. 
  • During normal operation, only one node is active in the load balancer (represented by the green box in the illustration). The other node is running, but is disabled in the load balancer.
  • To ensure that all administrative functions are available, install the Admin node on the primary node and leave the Admin node up.

Primary and elder Atrium Single Sign-On servers

When you configure an Atrium Single Sign-On cluster, one ASSO server member assumes the role of primary, and the other members are secondary members. Only the primary node can answer requests authoritatively. In some cases, the secondary nodes will forward their requests to the current primary node. The primary node selection process determines the elder node, which is the node that was started first in the cluster.

You can determine the current elder node in an Atrium Single Sign-On cluster by reviewing the ASSO HA page. To access the ASSO HA page, you must log on to the ASSO console and access the following URL (example): https://atssoY1.example.com/atriumsso/atsso/ha

Configuration

State

Initialized

True

Derby DB Enabled

True

Apache MQ Enabled

True

Boot Time

Time/Date

Host

atssoY1.example.com

Site ID

01

Elder Site Id

01

Elder Boot Time

Time/Date

Records Processed

76191

Meta Messages

983

DB Messages

9085

Site ID

Boot Time

Host

Last Update Received

01

Time/Date

attsoY1.example.com

Time/Date

02

Time/Date

attsoY2.example.com

Time/Date

In this example, the Site ID for atssoY1.example.com is 01, which is also the value of Elder Site Id.  Site ID 01 is typically assigned to the admin node, so both the admin node and the primary have the same site ID.

For an ideal configuration, ensure that atssoY1.example.com is reachable through the load balancer and that atssoY2.example.com is not.

Monitoring Atrium Single Sign-On

So that you know when to manually switch from the primary ASSO node to a secondary node in a controlled manner, you must monitor the primary node to ensure that it is alive or determine that its performance is degrading. To determine if the server is running, enter and bookmark the following URL: https://<AtriumSSO_serverName>:8443/atriumsso/isAlive.jsp.

Tuning Atrium Single Sign-On for large environments

Administrators responsible for large environments with a high user load can modify the settings in the setenv.sh and server.xml files. To ensure that that resources do not contribute to system instability, BMC oversized the the Atrium Single Sign-On nodes.

Note

These recommendations are suitable for environments with very high user loads and do not apply to most installations. Modify the recommended settings to suite your specific requirements.

In some cases, the Atrium Single Sign-On server would significantly increase thread count for a short time. Setting this value to 3000, as shown in the following example, addresses that problem. 

Example

  • Linux OS : 12Gb memory / 4vCPU
  • 3000 Threads
  • Java Heap – 4Gb min 6Gb max
  • JMX Enabled for tomcat monitoring
  • Max Sessions Per User : 5

Changes to setenv.sh (Tomcat/bin directory)

  • -Xms4096m \
  • -Xmx6144m \
  • -Dcom.sun.management.jmxremote \
  • -Dcom.sun.management.jmxremote.port=8086 \
  • -Dcom.sun.management.jmxremote.ssl=false \
  • -Dcom.sun.management.jmxremote.authenticate=false \

Changes to server.xml

maxThreads="3000" scheme="https" secure="true"

Restarting Atrium Single Sign-On in a high-availability environment

As a best practice, BMC recommends that you adhere to the following procedure when restarting the Atrium Single Sign-On nodes in a high-availability environment. BMC's testing has found that if you adhere to this process, you could successfully restart the system on a daily basis, if necessary. 

Restart process for Atrium Single Sign-On in a high-availability environment

PRIMARY NODE

SECONDARY NODE

 

Restart tomcat.

Wait until tomcat is ready on secondary node.

 

Enable the secondary node in the LB.

Wait 60 seconds for the LB to connect to the targeted active node.

Disable the primary node in the LB.

 

Wait 5 mins for the nodes to sync.

Reboot.

 

Wait until tomcat is ready on the primary node.

Enable the primary node in the LB.

 

Wait 60 seconds for LB to connect to the targeted active node.

 

Disable the secondary node in the LB.

Wait 5 mins for nodes to sync.

 

Reboot.

Additional configuration guidelines for a successful Atrium Single Sign-On implementation

Adhering to the following guidelines will further aid in the high-availability implementation of  Atrium Single Sign-On within a TrueSight installation:

Load balancer requirements and guidelines for high availability

  • As long as the load balancer can handle the active/passive load re-routing, you can use any type of load balancer with Atrium Single Sign-On.
  • Although you can configure the load balancer for HTTP communication, BMC strongly recommends that you configure it for HTTPS communication to enable secure communication with the TrueSight Presentation Server..
  • The load balancer should send traffic to only the active node (i.e., Node 1). When the active Node is down, the load balancer would then send traffic to Node 2.
  • You can use a couple of different options to configure SSL load balancing – Passthrough or SSL Offloading. Because Atrium Single Sign-On is installed in HTTPS mode, BMC recommends that you use Passthrough mode.
  • In a load-balanced environment, apply the Subject Alternate Names (SAN) certificate, which enables you to specify additional host names that will be protected by a single SSL certificate. The SAN attribute must include the values of the load balancer and each of the host names used for Atrium Single Sign-On.

Using a single ASSO server with multiple TrueSight Presentation Servers 

As long as the ASSO server has the required resources, you can point multiple TrueSight Presentation Servers or other products to a single Atrium Single Sign-On implementation. 

Disaster recovery configuration for Atrium Single Sign-On

Because Atrium Single Sign-On does not provide any export or import utilities, if you require a disaster recovery solution, you must install configure two independently-deployed ASSO servers. The two ASSO servers will have to be synchronized with manual reconciliation.

Where to go from here

You can perform either of the following tasks following configuration of high availability for Atrium Single Sign-On: