3.4 High Availability Deployment Blueprint

The following is an example of how to deploy Host Access for the Cloud in a highly available, scalable, and secure manner. While the details of every deployment will differ, for example you may be deploying three or more session servers, the goal here is to provide a known good starting point and to answer common deployment questions.

3.4.1 Architecture

This deployment consists of:

  • Session server load balancer

  • Two or more session servers

  • MSS load balancer

  • Three or more MSS servers

  • Terminal ID Manager

  • LDAP or identity management server

  • Host/mainframe

Deployment benefits

With this example, you will see:

  • Capacity for up to three thousand host sessions and the ability to be scaled as needed

  • High availability of key services; minimizing single points of failure and distributing load by means of load balancers

  • The ability to handle the failure of one session server and one MSS simultaneously without a significant drop in the performance of the web client, due to built-in headroom

  • Authentication and authorization options for MSS

  • Secure communication through HTTPS

Steps when deploying

We recommend you follow these steps when deploying:

  1. Learn about the basics of deployment

  2. Provision resources based on system requirements and sizing guidelines

  3. Install MSS and create a cluster

  4. Configure MSS load balancer

  5. Install session servers

  6. Configure session server load balancer

  7. Verify deployment

  8. Configure single sign-on (optional)

  9. Configure Terminal ID Manager (optional)

You’ve learned about the basics of deployment, system requirements and sizing guidelines in previous sections.

Installing MSS

Install three MSS servers and configure each of them for clustering. There is documentation that can step you through the process:

  1. Open ports on the firewall. Ports used by MSS and Host Access for the Cloud are listed here.

  2. Install MSS and then the Host Access for the Cloud components for MSS by running the Host Access for the Cloud install program on each MSS server.

  3. Add each server to a cluster.

  4. On each MSS server, configure general settings, security settings, and other settings as required.

Additional resources:

Configuring a MSS load balancer

As described in the Using Load Balancers section of this guide, use these values when configuring the MSS load balancer for high availability:

  • Load balancing algorithm: Least Connections (or something similar)

  • Session persistence: Enabled - use existing JSESSIONID cookie

    • Because cookies are not stored in the session server when it is acting as a client to MSS, the MSS load balancer must use either the existing JSESSIONID cookie or source IP (or something similar) for persistence.

    • If you are using Single Sign-on through IIS, the MSS load balancer must also use the sessid URL parameter, in addition to the JSESSIONID cookie.

    • If you are using the Assigned Sessions list, see Configuring the Assigned Sessions list (optional) for additional information.

  • Health check endpoint: https://<mss-server>/mss/

  • TLS: Configure TLS and install certificates as needed.

Installing session servers

Install two or more session servers.

For each session server:

  1. Open ports on the firewall. Ports used by MSS and Host Access for the Cloud are listed here

  2. Install the session server. During installation, choose to use a remote MSS server, and enter the MSS load balancer address and port.

  3. Import the session server certificate into each MSS’s trusted subsystem trust store: system-trustcerts.bcfks.

    HINT:This is done automatically for you on the MSS server that the load balancer chose during installation, but must be done manually on the other servers. It is best practice to import or verify its presence on each MSS server.

  4. Install each MSS certificate into the session server's trust store: trustcerts.bcfks.

Additional resources:

Configuring session server load balancer

Use these values to configure the load balancer:

  • Load balancing algorithm: Least Connections (or something similar)

  • Session persistence: Enabled - use JSESSIONID or a new cookie. Unlike the MSS load balancer you are not required to use the existing JSESSIONID cookie.

  • Health check endpoint: https://<session-server>/actuator/health

    • For the session server in particular, be cautious when you are configuring how to determine a node has failed and what to do once it has failed. If there are users still connected to the instance, those users may lose their host connections. To avoid marking an instance as failed too early, consider increasing timeouts or retries. Some load balancers provide a “drain mode”, which allows existing users to stay connected, but will direct new users to other instances.

  • TLS: Configure TLS and install certificates as needed.

Configuring the MSS callback address

MSS provides a callback address to the session server each time it creates or edits a session. By default, it uses the address specified in management.server.url.

If the MSS server is behind a proxy and the session server cannot reach the address:

  • Set the management.server.callback.address property in each MSS container.properties file to an address that the session server, for a specific MSS, can reach.

    NOTE:If HTTP is used for the session server to connect to the MSS callback address, set the management.server.callback.address.http property to True in each session server’s container.properties file.

  • Restart the server for the new property values to take effect.

Verifying the installation

After installing and configuring all components, you’ll want to:

  • Log into the MSS Administrative Console (through the MSS load balancer).

  • Navigate to Manage Sessions > Add a New Session and create a test session.

  • Assign the test session to a test user.

  • Log into the session server as the test user, through the session server load balancer.

  • Verify that the assigned session is available, opens, and can connect.

Configuring Single Sign-on (optional)

Following are a few additional considerations when configuring single sign-on in an high availability deployment.

SAML (Security Assertion Markup Language)

  1. Import the MSS load balancer certificate into each MSS servletcontainer.bcfks as a trusted certificate.

  2. Update the management.server.url in each MSS container.properties file to use the MSS load balancer address.

  3. Set the management.server.callback.address property in each MSS container.properties file to an address that the session server, for a specific MSS, can reach.

  4. Restart the MSS servers.

  5. Log on to the Administrative Console of the active MSS server to configure the SAML Authentication.

    • Confirm that the MSS load balancer DNS is used in the Assertion consumer service prefix URL field and add the MSS load balancer and Host Access for the Cloud load balancer DNS to the SAML whitelist.

  6. Download and edit the service provider metadata to insert each MSS server address as AssertionConsumerService, and import the updated metadata into the SAML identity provider.

    For example:

    <md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://mss-loadbalancer:8443/mss/callback/SAML2Client" index="0"/>
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://mss-server-1:8443/mss/callback/SAML2Client" index="1"/>
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://mss-server-2:8443/mss/callback/SAML2Client" index="2"/>
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://mss-server-3:8443/mss/callback/SAML2Client" index="3"/

X.509

In each case the certificate used must have a Subject Alternative Name (SAN) that contains all MSS server DNS names, along with the load balancer DNS name.

  1. Verify that the firewall on the MSS server allows HTTP traffic on the mutual authentication port; 8003 is the default.

  2. In each MSS:

    • Replace the certificate of the servlet-engine entry in the servletcontainer.bcfks files.

    • Replace the certificate of the system entry in system-keystore.bcfks files.

  3. Import the certificate into each session server’s:

    • trustcerts.bcfks file as a trusted certificate.

  4. Restart MSS and session servers.

  5. Configure both the MSS and HACloud load balancers for TLS passthrough.

  6. Configure X.509 authentication as documented here: Configure X.509 Authentication.

Configuring the Assigned Sessions list (optional)

To use the Assigned Sessions list to launch new sessions, additional configuration is needed:

  • Configure the MSS load balancer to stick on first the SESSIONID and then the JSESSIONID cookies. It is important to configure the stickiness in that specific order.

  • Access to the Assigned Sessions list must be through the same MSS load balancer that the HACloud session server uses to connect to MSS.

For more information see: