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.
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
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
We recommend you follow these steps when deploying:
Learn about the basics of deployment
Provision resources based on system requirements and sizing guidelines
Install MSS and create a cluster
Configure MSS load balancer
Install session servers
Configure session server load balancer
Verify deployment
Configure single sign-on (optional)
Configure Terminal ID Manager (optional)
You’ve learned about the basics of deployment, system requirements and sizing guidelines in previous sections.
Install three MSS servers and configure each of them for replication. There is documentation that can step you through the process:
Open ports on the firewall. Ports used by MSS and Host Access for the Cloud are listed here.
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.
Configure each server for replication.
On each MSS server, configure general settings, security settings, and other settings as required.
Additional resources:
As described in the Using Load Balancers section of this guide, use these values when configuring the MSS load balancer:
Load balancing algorithm: Least Connections (or something similar)
Session persistence: Enabled - use existing JSESSIONID cookie
Health check endpoint: https://<mss-server>/mss/
TLS: Configure TLS and install certificates as needed.
Install two or more session servers.
For each session server:
Open ports on the firewall. Ports used by MSS and Host Access for the Cloud are listed here
Install the session server. During installation, choose to use a remote MSS server, and enter the MSS load balancer address and port.
Import the session server certificate into each MSS server’s trust store: trustedascj.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.
Additional resources:
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
TLS: Configure TLS and install certificates as needed.
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.
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.
Restart the server for the new property values to take effect.
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.
Following are a few additional considerations when configuring single sign-on in an high availability deployment.
The MSS Administrator Guide has SAML Authentication instructions.
Import the MSS load balancer certificate into each MSS servletcontainer.bcfks as a trusted certificate.
Update the management.server.url in each MSS container.properties file to use the MSS load balancer 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.
Restart the MSS servers.
Log on to the Administrative Console of the active MSS server to configure the SAML Authentication.
The MSS Administrator Guide has X.509 Authentication instructions.
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.
Verify that the firewall on the MSS server allows HTTP traffic on the mutual authentication port; 8003 is the default.
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.
Import the certificate into each session server’s:
trustcerts.bcfks file as a trusted certificate.
Restart MSS and session servers.
Configure both the MSS and HA Cloud load balancers for TLS passthrough.
Configure X.509 authentication as documented here: How to Configure X.509 Authentication.