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

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

This procedure applies to the following clusters:

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 IBM 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 IBM Workload Automation components on Red Hat OpenShift.

Note: On-premises fault-tolerant agents cannot connect to an on-cloud master domain manager.

On-premises side operations

Ensure the following conditions are met for your on-premises master domain manager:

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.

Perform the following operations on the on-premises side:

Set the IBM® Workload Scheduler 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
```
1. In the secureaddr argument, define the port used to listen for incoming SSL connections, for example 31113 or another available port.
2. 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:
1. Browse to the TWA_DATA_DIR folder.
2. Edit the following properties in the localopts file. See the following example:
```
nm SSL full port      =0 
nm SSL port           =31113
SSL key               ="/install_dir/ssl/OpenSSL/TWSClient.key" 
SSL certificate       ="/install_dir/ssl/OpenSSL/TWSClient.cer" 
SSL key pwd           ="/install_dir/ssl/OpenSSL/password.sth" 
SSL CA certificate   ="/install_dir/ssl/OpenSSL/TWSTrustCertificates.cer" 
SSL random seed        ="/install_dir/ssl/OpenSSL/TWS.rnd" 
```
where:

nm SSL port

Is the port used to listen for incoming SSL connections, when full SSL is not configured, for example 31113.

For more information about the localopts file, see Setting local options.
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 IBM Workload Scheduler Batchman process by running this command:
```
conman stop
```
Stop IBM Workload Scheduler Netman process by running this command:
```
conman shut
```
Restart IBM Workload Scheduler 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

If you are using OpenShift, the connection between the on-premises master domain manager and the on-cloud backup master domain manager takes place through routes; therefore, it is recommended to use short names for namespaces, especially if the cluster name is long. This is because workstation host names cannot exceed 51 characters, therefore, the route must comply with this maximum character length.

Perform the following operations on the cloud side:

Download the latest product version. See
- If you are using Amazon EKS, see IBM Workload Automation for information about downloading images, installing, and configuring the product.
- If you are using OpenShift, see Deploying IBM Workload Automation components on Red Hat OpenShift.
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 IBM Workload Automation.
To deploy the new server instance in a cloud environment,  type:
```
helm install -f values.yaml workload_automation_release_name workload/ibm-workload-automation-prod -n workload_automation_namespace
```
where:

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 IBM 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

Final steps to switch domain manager capabilities permanently

To switch the event processor, run the following command either on the master domain manager or backup master domain manager:
```
switcheventprocessor [folder/]workstation
```
For more information about the command, see switcheventprocessor.
To switch domain management capabilities, run the following command either on the master domain manager or backup master domain manager:
```
switchmgr domain;newmgr
```
For more information about the command, see switchmgr.

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 DEFINITION


CPUNAME 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 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 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:
```
composer mod js your_xa#final@ full
```
where:

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.
Perform this operation for each on-premises dynamic agent in your environment.

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.