Setting up a Bizagi cluster

<< Click to Display Table of Contents >>

Navigation:  Automation Server > Automation Server configuration and administration guide > Initial project configuration > Deployment of processes and new versions > One-click Deployment > Production environment deployment >

Setting up a Bizagi cluster

Overview

The Management Console is the application in Automation Server whetre you administer production or test environments (to perform maintenance activities such as managing licenses and clustering in your Production environment).

To set up clusters in your Production environment through the Management Console, you must have employed One-Click Deployment for this environment.

The Management Console is installed with Automation Server in order to manage projects in Production environments, but, is also installed with Bizagi Studio in order to manage projects in the Development and Test environments.

 

 

Console_128

 

To open the Management Console, launch it from the shortcut access or from its installation path (by default at C:\Program Files\BizAgi\BizAgi Studio\MC\BizAgiMC.exe).

 

OpenMC

 

Servers Management

Among the administrative tools available in the Management Console is a Server Management module that lets you manage your Production environment's infrastructure (including setting up a Bizagi cluster if you used the One-Click Deployment feature).

Management options oriented to the infrastructure let you to configure a Bizagi server cluster, add or remove any number of nodes, or move your server to another location.

 

Your production environment will have a main node (initially listed among the Servers), referred to as the Master Node.

 

ServersMgm

 

Before you start

By default, Bizagi relies on the load balancing capabilities of the operating system (such as Network Load Balancing for Windows Servers), but using a specific Hardware Load balancer such as f5 is also supported and recommended for mission-critical applications.

 

To set a cluster in Bizagi, you need to:

 

1. Carry out the steps described in this section, using the Management Console.

Through this step you define in Bizagi which nodes are part of the cluster, and allow them to share an active license.

 

2. Ensure you have a load balancer and configure it to consider the nodes of the cluster.

Through this step you configure the load balancing for your nodes.

This step varies according to the Load balancer employed (this section will not get into this detail).

 

Prerequisites

To carry out any options described in the sections belowin the Management Console, ensure:

 

1. You have an authorized account for both the current and target servers involved in the procedure.

This means having an account which belongs to both the Bizagi and Administrators groups in the current and target servers.

 

WorkingRemote02_BizagiGroup

 

2. Moving licenses can be involved in some of the procedures below.

You should have at hand information related to your licenses to make sure they are correct (applies when moving a production server).

 

Additional considerations when involving licenses are:

The new server must not already have an existing Bizagi license.

The server where the operation is performed must have Internet connectivity (access to www.bizagi.com).

The new server must comply with Bizagi technical requirements for a production environment.

 

3. Set your documents upload path properly.

If you are setting up a cluster, you make sure that your Bizagi upload path (where attached documents are stored) is set in a shared file server (if you are not using ECM integration).

All your nodes need to access a single repository of uploaded documents (with proper access rights for the identity starting up Bizagi services).

 

FileServer_DocsPath

 

If you are moving a server, make sure that this path is accessible from the new server, and that this folder is the one with the documents previously uploaded.

 

Clustering options

For Bizagi projects with an expectation of a large number of concurrent users, and a high volume of requests in the Work Portal, Bizagi lets you configure a clustered environment.

This is a scaled-out measure which improves both availability and reliability for the complete system, while letting you set up any number of additional nodes in the cluster for load balancing and performance purposes.

 

note_pin

The Server Management option is visible only for production environments through the Management Console.

This module presents clustering options, some of which are available only if the current production environment was set up with the One-Click Deployment (in .NET platform projects).

 

For other scenarios (those using Advanced deployment), you can set up a clustered environment through another procedure, not with the assisted Management Console options.

 

Bizagi automatically manage your active licenses.

To configure a cluster,  you register additional nodes, while considering these ponts:

 

1. You have done a deployment to a production environment.

This means the target production server is already marked as the Master Node.

To view more information about a performing Bizagi deployments, refer to Deploying your Processes.

 

2. Add servers as nodes to the current production configuration.

Doing this per each cluster node is required.

 

At any time, you may also choose to remove a registered node in the clustered configuration.

 

Adding a Server

To add a new server, first make sure you have installed Automation Server in a machine which has network access to both the server that will be added as a cluster node, and the Master Node.

 

note_pin

You need to have installed Automation Server with the matching Bizagi version under which your production environment is running.

 

Open the Bizagi Management Console and select Open Existing Project in the Welcome to Bizagi window.

Select the local server from the first drop-down list, and then select the project's name in the second drop-down list.

Click Finish to open the project.

 

myLocalServer

 

For each node you want to add to the cluster configuration, follow these steps:

1. Use the Add New Server option.

Click the Add New Server button in the Servers Management module. You can also do this by right-clicking the Servers item and selecting the Add New Server option..

 

AddNew

 

A window displays the list of available servers in the network that have Bizagi installed.

 

2. Define the location of your additional server.

Select the new server to be included as a node in the cluster and click Next.

It may be possible that a server that can be accessed does not appear on the list.

If this is the case, select Click to type a new server, and enter the server's name.

 

note_pin

Inputting an IP address instead of a server name is supported, but make sure that the IP addresses is not dynamic.

IP addresses for servers involved in the configuration of a cluster must remain static and not change.

 

AddServer_serverlist2

 

To register a new server, you must have an authorized account which is member of the Bizagi and Administrators groups at that server (as described in the Prerequisites section).

 

deploytest_authentication

 

Acknowledge and agree to the concepts involved in adding a server.

 

newServer_confirmation

 

3. Specify if you wish to have an additional Scheduler service in the added node.

This is optional: you may choose to load balance the workload for your project's Scheduler if your Processes use a lot of background tasks such as jobs, batch processing, or other offline-scheduled tasks which can take a long time to execute.

We recommend you to install the Scheduler service to avoid single points of failure in your clustered environment. When installing an additional Scheduler service you need to follow the configuration described at Multiple Scheduler services configuration.

 

note_pin

Background tasks performed by the Scheduler mainly include executions for Asynchronous Activities, Replication synchronization, Custom Jobs, and LDAP synchronization.

 

newServer_chooseComponents

 

Click Next to continue.

 

4. Confirm your configuration

Finally, you will be shown with the summary of the Add New Server completion ("The Finally, you see a summary of the Add New Server completion ("The operation was completed successfully"). If any error occurred during the procedure, error message details appear.

 

OperationSuccessful

 

Click Finish to close the window.

A refreshed list of the registered servers (the Master Node, and any additional ones) appears.

 

2nodes

 

Removing a server

This option lets you to unregister a node server from the cluster configuration.

This is a useful option:

1. To stop using a server as a load-balanced node.

2. To move a server to a new location. In this case, you would need to use this option, move the server and then register the server at its new location, using the Add New Server option as specified in the previous section.

 

To move your main server (Master Node) to a new location, use the Moving a Master Node option.

This option works similarly to the Moving a Server option described below.

 

note_pin

Before removing a registered server from your cluster configuration, make sure you have installed Automation Server on a machine which has network access to both: the server that will be removed, and the Master Node.

You need to install Automation Server with the matching Bizagi version under which your production environment is running.

 

Open the Bizagi Management Console and select Open Existing Project from the Welcome to Bizagi window.

Select the local server from the first drop-down list, and the project's name in the second drop-down list.

Click Finish to open the project.

 

myLocalServer

 

For each node you want to remove from your cluster configuration, follow these steps:

 

1. Use the Remove Server option.

In the Server Management module, right-click the server you want to remove and choose the Remove Server option.

 

You can also do this by selecting Servers and then clicking the corresponding button on the ribbon.

Notice that this option deletes a Work Portal or Scheduler in a node. Therefore, if you want to remove both components (the Work Portal and the Scheduler), you need to do this for each component.

 

RemoveS

 

2. Double check you are doing what you intend, and confirm.

Confirm this action to remove the chosen node.

 

note_pin

This option will not delete files from the server.

Therefore, if this server is no longer part of the cluster, note that it will still have local files and prior configuration for the project.

 

Moving a Server (or Moving a Master Node)

This option allows you to move your current production environment to a new server.

Bizagi automatically creates your project's environment Work Portal and Scheduler in a different server, along with your activated license.  

 

note_pin

This option will not move your project's database.

If you need to move your database to a new Database Server, to do this manually using a backup and restore approach.

To view more information about Moving a database, refer to the following sections, according to your project's Database engine: SQL Server's backup and restore, or Oracle's Export and Import.

 

When you have a Bizagi cluster, this option is referred to as Move Master Node.

We recommend that you perform this procedure during non-working hours, because the services of the current environment are temporarily stopped.

To move your production environment to a new server, perform the following steps:

 

1. Install Automation Server on a machine having network access.

Install Automation Server on a machine which has network access to the involved servers (both to the current production server and the new server to which this environment will be moved).

If you are using a cluster, this would include access to the current cluster nodes.

 

note_pin

You need to install a version of the Automation Server that matches the Bizagi version under which your production environment is running.

 

2. Open the project from the Management Console.

Open the Bizagi Management Console in the recently installed machine. In the Welcome to Bizagi window, select Open Existing Project.

 

Select the project's current server from the first drop-down list. This displays the existing projects in that server, in the second drop-down list.

Select the project's name in the second drop-down list, and click Finish to open the project.

 

myLocalServer

 

3. Use the Move Server option.

When the project is open, go to the Server Management module. Click the Move Server button, or right-click directly in the Servers item and choose this option.

 

MoveServer

 

This procedure also moves your current production's activated license, and therefore Bizagi will show you the current activated license for the new server.

 

licensealready

 

Click Next to continue.

In the next window, Bizagi reminds you to move the license information as well.

 

AgreeLicenseMove

 

Select the I Agree checkbox and click Next.

 

4. Select the target server.

Select the target server from the list of available servers in the network having Bizagi installed.

Select the new server and click Next (similarly to the configuration presented when performing a first deployment).

 

It may be possible that even though the new server can be accessed, it does not appear under this list.

If this is the case, select the Click to type a new server, and enter the server's name.

 

note_pin

Providing an IP address instead of a server name is supported, but make sure that the IP address is not dynamic.

IP addresses for servers involved in the configuration of a deployment must not change.

MoveServer_Server

 

Remember that you need to have an authorized account which is a member of the Bizagi and Administrators groups at the target server (as described in the Prerequisites section).

 

deploytest_authentication

 

Once the procedure has finished: the activated license, the Work Portal, the Scheduler service, and the attachments of existing cases (files at the file server), will be removed from the original server.

They will be moved into the new server.

A summary of the license information is shown in the last window.

 

Close the summary by clicking Close.

 

Notifications using case links

When setting up a cluster or modifying your system's entry point for high availability (the load balancer's URL), consider the following configuration aspect for your process notifications.

 

To use case links from within e-mail notifications (hyperlinks that directly take end users to a given case's activity), make sure you specify your system's entry URL (corresponding to your load balancer).

 

Notifications_CaseLink

 

To do this, edit the configuration files of all the Bizagi Work portal instances of your cluster, and the Scheduler services in your project so that each can build the appropriate URL.

By default, each Work portal instance in Bizagi (or Scheduler service) will use its local URL instead of going through a load balancer.

 

To edit this configuration, modify each Work portal's web.config file (located by default at C:\Bizagi\Projects\[your_project]\WebApplication\) and each Scheduler's BizAgi.Scheduler.Services.exe.config file (located by default at C:\Bizagi\Projects\[your_project]\Scheduler\).

 

When editing each file, include the following lines inside of the <appSettings> element:

<add key="SERVER_NAME" value="YOUR_VALUE_HERE"/>

<add key="APP_NAME" value="YOUR_VALUE_HERE"/>

<add key="PROTOCOL" value="HTTPS"/>

 

Consider setting the value for Protocol as HTTPS, instead of HTTP, only when using SSL over HTTPS.

For value in SERVER_NAME,  specify the load balancer's virtual name (or IP address), and for the value in APP_NAME specify the load balancer's virtual web site.

 

In the end, confirm that your case links will be built as:
[PROTOCOL]://[SERVER_NAME]/[APP_NAME]/[FURTHER_CASE_LINK_PARAMETERS]

 

note_pin

When using a high availability Bizagi solution, it is also important to ensure that the UDP port number 11000 is allowed in all nodes of your cluster.

This UDP port is involved in the cache communication and synchronization used by Bizagi's components.