#Cluster Deployment Overview

The main concept of clustered Webswing is to divide the former Webswing Server into separate modules which handle web requests (Webswing Cluster Server) and application processing (Webswing Session Pool). In addition Admin console with its REST interface has been extracted into Admin Console Server module. With this setup you are able to deploy one Webswing cluster, handling multiple applications with:

• 1 .. N Webswing Cluster Servers
• 1 .. N Webswing Session Pools
• 0 .. 1 Webswing Admin Console Server

In a minimal setup you need 1 Cluster Server and 1 Session Pool. You can use multiple Cluster Servers for redundancy, but it should not be necessary to have more than 2 Cluster Servers in most cases. Session Pools can be scaled dynamically, depending on your needs of resources or connected users. Note that it is not possible to connect more than 1 Admin Console Server in the cluster.

You can deploy your cluster manually in a static way or you can use Docker images and Kubernetes with custom auto-scaling. For more information about Docker and Kubernetes deployment please contact support@webswing.org. Since 23.1 Webswing Cluster includes an Auto-scaling service.

#Installation

To install Webswing Cluster first unzip the distribution zip file. In the folder you will find webswing.war archive, which is used to start both Cluster Server and Session Pool. There is a separate startup script for each module. To simplify your deployment, you can make a copy of the unzipped distribution folder for each module (Cluster Server or Session Pool) you want to deploy and start the module accordingly, using webswing.sh/webswing.bat for Cluster Server or sessionpool.sh/sessionpool.bat for Session Pool.

If you are using a headless Linux with X virtual frame buffer (Xvfb), xvfb is needed only in case of Session Pool.

It is highly recommended that you do not share the configuration files between multiple modules. Every Cluster Server and every Session Pool should at least have its own *.config file. If you plan to have multiple Cluster Servers or Session Pools, create a separate installation folder for each of them. Also consider using Docker images which can easily contain your single module deployments.

#Migration of webswing.config

If you are migrating from version older than 20.2, you need to make some changes to your webswing.config file in order to use it in Webswing Cluster. First thing you should do is run Webswing Server 20.2 (non-cluster version) with your old webswing.config file. Once the server is started and the configuration is loaded, the config file automatically converts to a newer version and is stored. In version 20.2 some of the fields are moved from "swingConfig": {...} to app root (web config), e.g. "/webswing-demo": {}.

Having this webswing.config converted to a new version, you can create configuration files used in Cluster. Rename webswing.config to webswing-server.config and create new empty webswing-app.config file.

In webswing-app.config file create the structure of application paths like in this example:

{
    "/webswing-demo": {

    },
    "/javafx": {
    
    }
}

Now cut content from webswing-server.config from "swingConfig":

{
    "/webswing-demo": {
        "swingConfig": {
            <cut this>
        }
    }
}

and paste into the created structure in webswing-app.config:

{
    "/webswing-demo": {
        <paste here>
    }
}

Note that in webswing-app.config you do not provide any configuration for root path "/".

After you have cut and pasted all your application configurations into webswing-app.config, you can remove empty "swingConfig" fields from webswing-server.config. The configuration that is left in this file is your webswing-server.config.