This section provides instructions on how to create and configure your Azure Load Balancer feature. From the What is Azure Load Balancer? Microsoft article:
With Azure Load Balancer you can scale your applications and create high availability for your services. Load Balancer supports inbound and outbound scenarios, provides low latency and high throughput, and scales up to millions of flows for all TCP and UDP applications.
Load Balancer distributes new inbound flows that arrive on the Load Balancer's frontend to backend pool instances, according to rules and health probes.
Additionally, a public Load Balancer can provide outbound connections for virtual machines (VMs) inside your virtual network by translating their private IP addresses to public IP addresses.
Create a Basic load balancer following the instructions on the Azure Quickstart page. Once you've completed the steps, you'll have:
A load balancer with its resources configured: a back-end address pool, a health probe, and a load balancer rule
Note: When creating the load balancer rule, you can configure the sticky-session from the Session persistence drop-down list. If the Session state is enabled in the web forms, the sticky-session is mandatory.
A virtual network
Two virtual machines with IIS installed on both
A network security group
Note: When creating the NGS rules, adding the RDP rule is recommended for testing only. For production, we recommend using a VPN or private connection. See the Creating the NSG rules Microsoft article for instructions.
The public IP address for the load balancer, which you can find on its overview page
Note: This public IP address will be used to access to WorkflowGen instances.
To create a Load Balancer and its components via the Azure CLI, first sign in to your Azure account with Azure CLI, then follow the steps below:
Create a load balancer with its resources (back-end address pool, health probe and a load balancer rule).
Note: You can configure the sticky-session by using the
--load-distribution parameter in the script. For more details about all parameters supported see the Manage load balancing rules Microsoft article. If Session State is enabled in the web forms, the sticky-session is mandatory (see the How to enable Session State in the WebForms application WorkflowGen Knowledge Base article for more information).
Create and configure the virtual network. Note: The network security group and its rules will be created when configuring the virtual network. It is recommended to add an RDP rule for testing purposes.
Create two virtual machines with IIS installed on both.
Note: Once WorkflowGen is installed, it is required to enable Anonymous Authentication for the WorkflowGen website. The
wfgen application and sub-applications may have different authentications enabled.
Make sure that both instances of WorkflowGen point to the same database. Your database can be:
An Azure SQL database OR
A classic MS SQL database instance on a dedicated server or on one of the virtual machines. Be sure to add inbound and outbound security rules (depending on your needs) for the SQL port in the network security group.
Create an Azure file share following the instructions in the Azure Files section, and copy the file share path.
Note: Make sure to replace the
ApplicationDataPath setting's value in the WorkflowGen
web.config file with the new file share path.
Open the WorkflowGen
web.config file and modify the value of the following setting:
<add key="ApplicationUrl" value="http[s]://<load balancer public IP address>/wfgen" />
For both WorkflowGen instances, replace
<load balancer public IP address> above with the load balancer's public IP address.
Configure your WorkflowGen in a web farm architecture following the instructions in the Web farm architecture section in the WorkflowGen Technical Guide. Once you've completed the instructions, you'll have:
A common WebForms folder
Both WorkflowGen Engine and Directory Synchronization services running on one of the WorkflowGen instances only.