Let’s go one step further with the WA deployment in the Azure world; using a managed database mean you avoid all those annoying maintenance and administration duties related to database management such as, supervise installation, migration and upgrade of databases, identify and resolve the database issues related to performance and capacity, create and manage all disaster recovery procedures to ensure continuous availability and speedy recovery, to name a few.
Deploying WA to an Azure cluster means you can take advantage of the following Azure SQL solutions:
- SQL Managed instances
- SQL Databases
- SQL Virtual machines
In this blog article, we focus on the SQL Managed instances, that is, the most important solution from a customer point of view, because it enables data migration from the existing on-premises WA relational database instance to the Azure SQL instance.
Azure SQL Managed Instance Service guarantees high availability for every database and it ensures the uninterrupted flow of management traffic so you can forget about managing the WA database instances because Azure can do it for you!
Let’s discover how to use Azure SQL Managed Instance for a WA deployment without any need for existing basic SQL skills to get started.
Take an in-depth look at what you can do, to deploy the WA solution.
Deploy a WA solution in Azure with an SQL Managed Instance
Perform the following 2-step procedure:
- Create an Azure SQL DB instance
- Deploy the WA solution to Azure with an SQL Managed DB Instance
Step 1: Create Azure SQL DB instance
1. Log in to the Azure portal of your organization and type “azure SQL” in the search bar.
After the Azure SQL service appears on your screen, click Add to create a new Azure SQL resource that you will use later for the Workload Automation product deployment.
2. Now you can select one of the three different Azure SQL Database instance types:
- SQL Database
- SQL Managed Instances
- SQL Virtual Machine
Both HCL Workload Automation and IBM Workload Automation support the use of each of these Azure SQL Database instance types. You can choose the one that best fits with your needs!
In this example, we chose the SQL Managed Instance because, in our opinion, it is the most innovative and efficient solution among those offered by Azure.
3. In the SQL Managed Instance service, click Create and fill the required input parameters to initialize the “tws_managed_instance” WA database Instance.
When the “tws_managed_instance” instance is created, open the definition and take note of the Host parameter value that you will need to use later to establish a connection between the Workload Automation Server and Console with the Azure SQL Database.
Step 2: Deploy WA solution in Azure with an SQL Managed DB Instance
In this example, we set up a WA environment with the use of a Load Balancer network configuration for the server and console components.
For detailed information about the prerequisites, see the README file:
Once we have created a new Namespace, called hwa, for our WA environment in the Azure cluster, and we have added the WA chart to our Helm repository, the only step that separates us from having a WA environment deployed to Azure is the customization of the configurable parameters in the values.yaml file.
- As explained in the README file, access the packages from the HCL or IBM Entitled Registry and open the values.yaml file. This is a configuration file in which we can customize our WA deployment for the server, console, and agent. With just a few changes in this file, we can have a cloud-based environment making the most of a managed instance of MSSQL.
2. To configure the WA server component to connect to the Azure SQL instance, edit the parameters by replacing the DB hostname parameter value with the Host parameter value of the “tws_managed_instance” Azure SQL managed instance created earlier.
3. The Azure SQL Managed tablespace must be configured as “PRIMARY”, because the creation of different tablespaces is not supported by Azure SQL in this configuration.
4. Do the same for the console component.
5. To configure the deployment with a Load Balancer network service, set the exposeServiceType as LoadBalancer and uncomment the Azure Load Balancer annotation.
6. To deploy the Workload Automation configuration saved in the values.yaml file, from the directory where the file is located, run the following command:
helm install -f values.yaml hwa workload/hcl-workload-automation-prod -n hwa
Now, wait about 10 minutes, take a break, and get ready to start working with the Workload Automation console, server and agent on Azure AKS.
We hope this article is useful. It’s now your turn to try it out and then let us know. Feedback and comments are very helpful to us!
Do not hesitate to reach out to us to clarify any doubts or questions!
Pasquale Peluso, Workload Automation Software Engineer, HCL Technologies
Pasquale joined HCL in September 2019 in the Verification Test team. He works as verification tester for Workload Automation suite on distributed and cloud-native environments. He has a master’s degree in Automation Engineering.
Davide Malpassini, Workload Automation Technical Lead, HCL Technologies
Davide joined HCL in September 2019 as a Technical Leadworking on the IBM Workload Automation product suite. He has 14 years of experience in software development and he was responsible for the extension of the Workload Automation product from a Kubernetes native environment to OpenShift Container Platform and REST API for the Workload Automation engine. He has a Master’s in Computer Engineering.
Louisa, Developer, HCL Technologies
Louisa works as an Information Developer planning, designing, developing, and maintaining customer-facing technical documentation and multimedia assets. Louisa completed her Bachelodegree at University of Toronto, Canada, and currently lives in Rome, Italy.
Filippo Sorino, Software Developer, HCL Technologies
joined HCL in September 2019 as a Junior Software Developer and works as a Verification engineer for the IBM Workload Automation product suite. He has a Bachelor’s degree in Computer Engineering.
Federico Yusteenappar, Junior Software Developer, HCL Technologies
Federico joined HCL in September 2019 as a Junior Software Developer working as a Cloud Developer for the IBM Workload Automation product suite. His main focus has been the extension of the Workload Automation product from a Kubernetes native environment to OpenShift Container Platform. He has a Master’s degree in Computer Engineering.
Serena Girardini, Verification Test Manager, HCL Technologies
Serena is the Verification Test manager for the Workload Automation product in distributed environments. She joined IBM in 2000 as a Tivoli Workload Scheduler developer and she was involved in the product relocation from the San Jose Lab to the Rome Lab during a short-term assignment in San Jose (CA). For 14 years, Serena gained experience in Tivoli Workload Scheduler distributed product suite as a developer, customer support engineer, tester and information developer. She covered for a long time the role of L3 fix pack release Test Team Leader and, in this period, she was a facilitator during critical situations and upgrade scenarios at customer sites. In her last 4 years at IBM, she became IBM Cloud Resiliency and Chaos Engineering Test Team Leader. She joined HCL in April, 2019 as an expert Tester and she was recognized as Test Leader for the product porting to the most important Cloud offerings in the market. She has a Bachelor Degree in Mathematics.