Clusters and server management

<< Click to Display Table of Contents >>

Navigation:  Bizagi Engine > Bizagi system administration > Bizagi server configuration > Bizagi Engine .NET platform configuration >

Clusters and server management

Overview

Bizagi Engine offers a Management Console to perform administrative tasks in any environment (Development, Production or Test).

 

Amongst these administrative tasks you will find a Server Management module which allows you to manage your Production environment's infrastructure.

Such management options oriented to the infrastructure allow you to configure a Bizagi server cluster, and to add or remove any number of nodes, or choose to move your server to another.

 

Your production environment will still have a main node (that one which is initially listed at the Servers), and this main node is referred to as the Master Node.

 

ServersMgm

 

 

 

Before you start

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

 

To set a cluster in Bizagi, you need to:

 

1. Carry out the steps described in this section by 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

In order to carry out any options described in the sections below which include the step #1 mentioned in the previous section, 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 licenses in order to review that these are correct (applies when moving a production server).

 

Additional considerations when involving licenses are:

The new server must not already have a different Bizagi license.

The server where the operation is performed must have Internet connection (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 will need to ensure that your Bizagi upload path (where attached documents are stored) is set in a shared file server (if you are not using ECM integration).

This is so because all your nodes will 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 only moving a server, then you will need to ensure both: that this path corresponds to the expected path accessible from the new server, and that this folder already has any documents previously uploaded.

 

 

Clustering options (Server management module)

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

This is a scale-out measure which helps improving both availability and reliability for the complete system, while allowing you to set up any number of additional nodes in the cluster (for load balancing and performance purposes as well).

 

 

note_pin

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

This module will present clustering options, and therefore some of these will be shown 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 may also set up a clustered environment but this is done through another procedure (not with the assisted Management Console options).

 

In this treatment, Bizagi will automatically manage your active licenses.

To configure a cluster,  we register additional nodes, while considering these premises:

 

1. Previously have done a Deployment to a production environment.

In this way, the target production server will be 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 ensure you have installed Bizagi Engine 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

Take into account that you require installing Bizagi Engine with the matching Bizagi version under which your production environment is running.

 

 

Open Bizagi Management Console and select the Open Existing Project option from 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 for the cluster configuration, follow these steps:

1. Use the Add New Server option.

Click on the Add New Server button at the Servers Management module. You may also do this by right-clicking on the Servers item and selecting the corresponding option.

 

AddNew

 

Similarly to the options presented in a Deployment configuration, a window is opened with the list of available servers in the network having 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 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

Inputting IP addresses instead of a Server name is supported, but take into account that while using IP addresses it is necessary to ensure that the IP addresses are not dynamic. In other words, IP address for servers involved in the configuration of a cluster remain static and not change.

 

 

AddServer_serverlist2

 

 

Remember that in order to perform the new server registration, it is necessary to have an authorized account which is member of the Bizagi and Administrators groups at that server (as described in the Prerequisites section link).

 

deploytest_authentication

 

 

Make sure you acknowledge and agree to the concepts involved in adding a new server.

 

newServer_confirmation

 

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

Notice this is optional, and therefore you may choose to load balance the workload for your project's Scheduler if your Processes strongly use background tasks such as jobs, batch processing, or other offline-scheduled tasks which can take long executing.

It is recommended to install the Scheduler service as well to avoid single points of failure in your clustered environment. However, consider that when installing an additional Scheduler service you would need to follow the configuration described at Multiple Scheduler services configuration.

 

note_pin

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

 

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 operation was added successfully"). If any error occurred during the procedure, the error message detail will be shown.

 

OperationSuccessful

 

Click Finish to close the window.

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

 

2nodes

 

 

Removing a Server

This option will allow you to unregister a node server in the cluster configuration.

This is a useful option in case you wish:

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

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

 

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

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

 

note_pin

To remove a registered server in your cluster configuration, first ensure you have installed Bizagi Engine in a machine which has network access to both: the server that will be removed, and the Master Node.

Take into account that you require installing Bizagi Engine with the matching Bizagi version under which your production environment is running.

 

 

Open Bizagi Management Console and select the Open Existing Project option from 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 remove in your cluster configuration, follow these steps:

1. Use the Remove Server option.

Select the server from the listed registered nodes, by right-clicking on it and choosing the Remove Server option at the Servers Management module.

 

You may also do this by selecting the Servers and then clicking on 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, take into account that it will still have local files and prior configuration for that project.

 

 

Moving a Server (or Moving a Master Node)

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

Through it, Bizagi will automatically create 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, you need to do this manually by 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 having a Bizagi cluster, this option is referred to as Move Master Node.

It is recommended that this procedure is done at non-working hours, mainly because the services of the current environment are temporarily stopped.

To move your production environment to a new server, the following steps are carried out:

 

 

1. Install Bizagi Engine in a machine having network access.

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

Note that while using a cluster, this would imply access to the current cluster nodes.

 

 

note_pin

Take into account that you require installing Bizagi Engine with the matching Bizagi version under which your production environment is running.

 

 

2. Open the project from the Management Console.

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

 

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

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

 

myLocalServer

 

 

3. Use the Move Server option.

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

 

MoveServer

 

Take into account that this procedure will also move your current production's activated license, and therefore Bizagi will show you the current activated license for that server.

 

 

licensealready

 

Click Next to continue.

In the next window, Bizagi will warn you about moving the license information as well.

 

AgreeLicenseMove

 

Mark 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

Inputting IP addresses instead of a Server name is supported, but take into account that this while using IP addresses it is necessary to ensure that the IP addresses are not dynamic.

In other words, IP address for servers involved in the configuration of a deployment must not change.

 

 

MoveServer_Server

 

 

Remember that in order to perform this option, it is necessary to have an authorized account which is member of the Bizagi and Administrators groups at the target server (as described in the Prerequisites section link).

 

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 erased at the prior server.

All of these will be moved unto the new server.

Notice that a summary of the license information is shown in the last window.

 

Close it 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), you will need to 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.

This is so because by default, each Work portal instance in Bizagi (or Scheduler service) will use its local URL instead of going over 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 of files, 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, only when using SSL over HTTPS instead of HTTP if that is your case (by default, HTTP is used).

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

 

In the end, acknowledge 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.