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

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 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.
Note: On-premises fault-tolerant agents cannot connect to an on-cloud master domain manager.

On-premises side operations

Before you begin

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.

About this task

Perform the following operations on the on-premises side:

Procedure

  1. 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
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. Stop HCL Workload Automation Batchman process by running this command:
    conman stop
  7. Stop HCL Workload Automation Netman process by running this command:
    conman shut
  8. Restart HCL Workload Automation processes by running these commands:
    StartUp
    conman start
  9. 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

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.

About this task

Perform the following operations on the cloud side:

Procedure

  1. Download the latest product version. See
  2. 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.

  3. 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.
  4. 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.
  5. To deploy the new server instance in a cloud environment,  type:
    helm install -f values.yaml workload_automation_release_name workload/hcl-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 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" 
  6. 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

Final steps to switch domain manager capabilities permanently

Procedure

  1. 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.
  2. 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.
  3. 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
  4. 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
    
  5. To make the changes effective, run the following command:
    JnextPlan -for 0000
  6. 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.
  7. 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
  8. Delete the FINAL and FINALPOSTREPORTS job streams from the plan, as follows:
    conman "canc your_xa#FINALPOSTREPORTS"
    conman "canc your_xa#FINAL"
  9. 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
  10. 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"
  11. 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
    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.