Moving your workload from an on-premises to a cloud environment
A quick procedure to move your workload from an on-premises to a cloud environment
About this task
Moving your workload from an on-premises to a cloud environment is a quick procedure which involves configuring SSL communication between your existing on-premises master domain manager and a new backup master domain manager on the cloud. You then switch permanently domain management capabilities from the on-premises master domain manager to the backup master domain manager on the cloud to shift your whole workload to the cloud. This procedure requires the on-premises master domain manager to be at Version 9.5 Fix Pack 3 or later.
At the end of the procedure, you will have switched your master domain manager to the cloud and set up your dynamic agents to work in SSL mode with the on-cloud master domain manager
- Amazon Elastic Kubernetes Service (EKS)
- For this cluster, you can use an ingress-type network or a load-balancer network. To specify which network type you want to use, set the relevant parameters in the values.yaml file. For detailed information, see the Network enablement section in HCL Workload Automation.
- OpenShift
- For this cluster, you can only use routes as network service. An OpenShift Container Platform route allows you to associate a service with an externally-reachable host name. This edge host name is then used to route traffic to the service. For more information, see the readmes available in Deploying HCL Workload Automation components on Red Hat OpenShift using helm charts.
On-premises side operations
Before you begin
- Version 9.5, Fix Pack 3 or later is installed.
- The port number used by the netman process to listen for communication from the dynamic domain manager (brnetmanport) is set to the default 41114 value.
- Ensure the SECURITYLEVEL attribute is set to force, or force_enabled. For more information about workstation definition parameters, see Workstation definition.
About this task
Perform the following operations on the on-premises side:
Procedure
-
Set the HCL Workload Automation
environment variables:
- In UNIX®:
-
. ./TWA_home/TWS/tws_env.sh
for Bourne and Korn shells. ./TWA_home/TWS/tws_env.csh
for C shells
- In Windows®:
-
TWA_home\TWS\tws_env.cmd
-
Configure your master domain manager for SSL
communication using the modify command:
composer modify ws your_master_domain_manager
- In the secureaddr argument, define the port used to listen for incoming SSL connections, for example 31113 or another available port.
- In the securitylevel argument, specify enabled to set the master domain manager to uses SSL authentication only if its domain manager workstation or another fault-tolerant agent below it in the domain hierarchy requires it.
See the following example:CPUNAME your_mdm_name DESCRIPTION "MANAGER CPU" OS UNIX NODE your_IP_address TCPADDR 31111 SECUREADDR 31113 DOMAIN MASTERDM FOR MAESTRO TYPE MANAGER AUTOLINK ON BEHINDFIREWALL OFF SECURITYLEVEL ENABLED FULLSTATUS ON END
For more information about the modify command, see modify. For more information about workstation properties, see Workstation definition. -
Modify the localopts file to enable SSL communication,
as follows:
where:
- nm SSL port
- Is the port used to listen for incoming SSL connections, when full SSL is not configured, for example 31113.
- If you have a dynamic domain manager in your environment, repeat steps 2 and 3 on the dynamic domain manager to have the dynamic domain manager function correctly with the on-cloud master domain manager. The dynamic domain manager stays in the on-premises environment.
- If you want to use custom SSL certificates, edit the paths in the localopts file specifying the paths to the custom certificates and using the same names as the default certificates. For more information about secure connections, see Connection security overview, and specifically Extending communication scenarios to other server components.
-
Stop HCL Workload Automation
Batchman process by running this command:
conman stop
-
Stop HCL Workload Automation
Netman process by running this command:
conman shut
-
Restart HCL Workload Automation
processes by running these commands:
StartUp
conman start
- You can optionally configure your on-premises fault-tolerant agents for communicating with the on-cloud master domain manager, by performing this procedure on each fault-tolerant agent.
Cloud-side operations
Before you begin
About this task
Perform the following operations on the cloud side:
Procedure
-
Download the latest product version. See
- If you are using Amazon EKS, see HCL Workload Automation for information about downloading images, installing, and configuring the product.
- If you are using OpenShift, see Deploying HCL Workload Automation components on Red Hat OpenShift using helm charts.
-
Open the values.yaml file to configure a new server
instance.
If you want to deploy only a new server without the Agent and Console applications, set the enableAgent and enableConsole parameters to false.
-
Set the following database parameters to have the new server instance point
the database of the on-premises master domain manager. These values
must match the values defined for the on-premises master domain manager.
db: adminUser: <admin_dbuser> hostname: <db_host> name: <db_name> port: <db_port> sslConnection: false tsName: null tsPath: null tsTempName: null tssbspace: null type: <db_type> usepartitioning: true user: <db_user>
This automatically configures the on-cloud server as a backup master domain manager for the on-premises master domain manager. - Set the server.enableSingleInstanceNetwork parameter to true to create an additional load balancer for each server pod. This is used to connect the backup master domain manager inside the cluster with master domain manager outside the cluster. For more information about parameters, see the Configuration Parameters section in HCL Workload Automation.
-
To deploy the new server instance in a cloud environment, type:
where:helm install -f values.yaml workload_automation_release_name workload/hcl-workload-automation-prod -n workload_automation_namespace
- workload_automation_release_name
-
is the name of the release, for example hwa.
When you deploy the backup master domain manager on the cloud, it is automatically configured as follows, in full SSL mode with the on-premises master domain manager:CPUNAME HWA-SERVER-0 DESCRIPTION "FTA CPU" OS UNIX NODE hwa-waserver-0.hwa-test TCPADDR 31111 SECUREADDR 443 DOMAIN MASTERDM FOR MAESTRO TYPE FTA AUTOLINK ON BEHINDFIREWALL OFF SECURITYLEVEL FORCE_ENABLED FULLSTATUS ON END
where- hwa-waserver-0.hwa-test
- Is the name of the ingress-type network being configured, if
you are using an ingress-type network for EKS.
If you are using a load-balancer network, the NODE parameter is automatically set to the IP address of the load balancer. For more information, see the Network enablement section in HCL Workload Automation.
If you are deploying on OpenShift, this parameter is automatically set to the OpenShift network route. For more information, see the readmes available in Deploying product components on Red Hat OpenShift, V4.x.
- SECURITYLEVEL
- Specifies the type of SSL authentication for the workstation. This parameter is automatically set to force_enabled, which means that the workstation uses SSL authentication for all of its connections to all target workstations which are set to this value. The workstation tries to establish a connection in FULLSSL mode and, if the attempt fails, it tries to establish an unsecure connection. For more information about workstation definition parameters, see Workstation definition.
In the same way, the localopts file of the backup master domain manager on the cloud is also automatically configured for SSL communication. See the following example:nm SSL full port =31113 # nm SSL port =0 # SSL key ="/home/wauser/wadata/FTAcert/TWSClient.key" SSL certificate ="/home/wauser/wadata/FTAcert/TWSClient.cer" SSL key pwd ="/home/wauser/wadata/FTAcert/password.sth" SSL CA certificate ="/home/wauser/wadata/FTAcert/TWSTrustCertificates.cer" SSL random seed ="/home/wauser/wadata/FTAcert/TWS.rnd"
-
To assign full control for all objects to the wauser, type the
following command:
composer mod acl @
The following example shows the modified access control list:ACCESSCONTROLLIST FOR ALLOBJECTS root FULLCONTROL twsuser FULLCONTROL wauser FULLCONTROL END
ACCESSCONTROLLIST FOLDER / root FULLCONTROL twsuser FULLCONTROL wauser FULLCONTROL END
Switching domain manager capabilities
About this task
Procedure
-
To switch the event processor, run the following command either on the
master domain manager or backup master domain manager:
For more information about the command, see switcheventprocessor.switcheventprocessor [folder/]workstation
-
To switch domain management capabilities, run the following command either
on the master domain manager or backup master domain manager:
For more information about the command, see switchmgr.switchmgr domain;newmgr
-
To make the switch permanent, edit from composer the definition of the
previous master domain manager. See the following example and notice how the
TYPE attribute changes from
MANAGER to FTA.
PREVIOUS DEFINITION
CPUNAME your_mdm_name DESCRIPTION "MANAGER CPU" OS UNIX NODE your_IP_address TCPADDR 31111 SECUREADDR 31113 DOMAIN MASTERDM FOR MAESTRO TYPE MANAGER AUTOLINK ON BEHINDFIREWALL OFF SECURITYLEVEL ENABLED FULLSTATUS ON END
NEW DEFINITIONCPUNAME your_mdm_name DESCRIPTION "MANAGER CPU" OS UNIX NODE your_IP_address TCPADDR 31111 SECUREADDR 31113 DOMAIN MASTERDM FOR MAESTRO TYPE FTA AUTOLINK ON BEHINDFIREWALL OFF SECURITYLEVEL ENABLED FULLSTATUS ON END
-
To make the switch permanent, edit from composer the definition of the
previous backup master domain manager. See the following example and notice how the TYPE
attribute changes from FTA to
MANAGER.
PREVIOUS DEFINITION
CPUNAME HWA-SERVER-0 DESCRIPTION "FTA CPU" OS UNIX NODE hwa-waserver-0.hwa-test TCPADDR 31111 SECUREADDR 443 DOMAIN MASTERDM FOR MAESTRO TYPE FTA AUTOLINK ON BEHINDFIREWALL OFF SECURITYLEVEL FORCE_ENABLED FULLSTATUS ON END
NEW DEFINITIONCPUNAME HWA-SERVER-0 DESCRIPTION "FTA CPU" OS UNIX NODE hwa-waserver-0.hwa-test TCPADDR 31111 SECUREADDR 443 DOMAIN MASTERDM FOR MAESTRO TYPE MANAGER AUTOLINK ON BEHINDFIREWALL OFF SECURITYLEVEL FORCE_ENABLED FULLSTATUS ON END
-
To make the changes effective, run the following command:
JnextPlan -for 0000
- Optionally, you can deploy a new backup master domain manager on the cloud by performing a scale-up of the components listed in the values.yaml file. To perform this operation, set the waserver.replicaCount parameter to a value higher than 1. You can now optionally uninstall your on-premises backup master domain manager.
-
To edit the FINAL and FINALPOSTREPORT job streams, type the following
command:
where:composer mod js your_xa#final@ full
- your_xa
- is the name of the extended agent workstation installed with the master domain manager.
Edit the following section:STREAMLOGON old_tws_user
as follows:STREAMLOGON wauser
-
Delete the FINAL and FINALPOSTREPORTS job streams from the plan, as
follows:
conman "canc your_xa#FINALPOSTREPORTS"
conman "canc your_xa#FINAL"
-
Submit first the FINAL, and then the FINALPOSTREPORTS job streams into the
current plan, as follows:
conman sbs your_xa#FINAL
conman sbs your_xa#FINALPOSTREPORTS
-
Reset the value of the limit job stream keyword for
the FINAL and FINALPOSTREPORTS job streams, both in the database and in the
plan, as follows:
conman "limit your_xa#FINAL ;10"
conman "limit your_xa#FINALPOSTREPORTS ;10"
-
To have your dynamic agents connect to
the on-cloud master domain manager, copy the certificates located in
/home/wauser/wadata/ITA/cpa/ita/cert/ and duplicate
them to /datadir/ITA/cpa/ita/cert. The certificates to
be duplicated are as follows:
- TWSClientKeyStore.crl
- TWSClientKeyStoreJKS.jks
- TWSClientKeyStoreJKS.sth
- TWSClientKeyStore.kdb
- TWSClientKeyStore.rdb
- TWSClientKeyStore.sth
You have now successfully switched your master domain manager to the cloud and set up your dynamic agents to work in SSL mode with the on-cloud master domain manager.