Cloud router

Setting up a cloud router.

A “Cloud Router” is a dbWatch Node that securely forwards messages. It must be in a network where both the client and server can reach it.

A Cloud Router setup requires a separate license.

For security reasons you do not want the cloud router to be a domain controller, and you do not want it to be part of the domain you want to connect to.
So, to set up a cloud router, you need a separate dbWatch domain that this router will be a part of.

Lets assume you have two domains “prod.acme.com” and “router.acme.com”.

“prod.acme.com” is your existing production environment with one or more dbWatch Servers.
“router.acme.com” is the router domain you want to set up.

Step one

Install a domain controller for the “router.acme.com” domain. This should be in a secure network location.

Step two

Install and configure the routing node.

For Windows servers, the default configuration location is:
C:\ProgramData\dbWatchControlCenter\config

This replaces /var/dbwatch-controlcenter/config used on Linux systems.
The directory layout and file names are otherwise identical.

Install the routing node package

Install the dbwatch-controlcenter package on the server that will act as the Cloud Router.
This node must be able to communicate with both the dbWatch domain controller and the client(s).

Scripts for configuring and tuning the Cloud Router is available from Github :
Github link

Verify and tune system parameters

The Cloud Router is intended to be lightweight and efficient.
Run the setup script (dbwatch_cloudRouter.sh) or verify manually that the following parameters are configured:

In /var/dbwatch-controlcenter/config/server/server_configuration.xml:
<scheduler-thread-pool-size>5</scheduler-thread-pool-size>
<thread-pool-size>100</thread-pool-size>

In /var/dbwatch-controlcenter/config/node/tuning.properties:
Scheduler.threads.count = 5
Scheduler.threads.sleep = 2

These values ensure the router limits resource usage and does not run unnecessary background tasks.
The setup script will prompt to correct these values if they are different.

Configure router.json

The router’s access and forwarding behavior is defined in:
/var/dbwatch-controlcenter/config/node/router.json

Example configuration:

{
    "discovery":"false",
    "forwarding":"true",
    "rules":[
        "ALLOW 127.0.0.1/32 0.0.0.0/0 100",
        "ALLOW 192.168.0.20/32 0.0.0.0/0 100",
        "DENY 0.0.0.0/0 0.0.0.0/0 -1"
    ]
}

“discovery” should normally be set to “false” to prevent the router from automatically advertising itself.
If it is “true”, the setup script will ask if you want to change it to “false”.

“forwarding” must be “true” to allow routing.
The setup script ensures this setting is correct.

“rules” define which hosts can establish connections through the router.
Each rule has the following format:

ALLOW/DENY FROM-HOST TO-HOST MAX-CONNECTIONS

TO-HOST and MAX-CONNECTIONS are currently informational only.

Configure services.json

The Cloud Router also requires a service definition file to register with the governing domain.
Check or create the following file:

/var/dbwatch-controlcenter/config/services.json

Example:

{
    "services:Entity": [
        "service.cloudrouter:router@domain:router.acme.com"
    ]
}

Configure governing domain

Each Cloud Router must know which domain controller governs it.
Check or create the following file on the Cloud Router:

/var/dbwatch-controlcenter/config/node/governingDomain.json

Example:

{
    "domain":"router.acme.com"
}

If this file does not exist or has the wrong domain name, run the setup script (dbwatch_cloudRouter.sh)
and enter the correct domain controller name when prompted.
This ensures the router correctly reports to its domain controller.

Note:
After adding the routing node, you might need to copy the PEM files from the router domain controller’s trustStore directory
to the Cloud Router’s trustStore directory located at: /var/dbwatch-controlcenter/config/node/trustStore

This ensures secure certificate-based communication between the router and the domain controller.

Add the routing node to the router domain

Add the routing node to the “router.acme.com” domain using dbWatch Control Center.
Confirm that the node appears in the domain configuration list.

Step three

Add a connection from one (or more) of the server(s) in the “prod.acme.com” domain to the Cloud Router.

To allow a dbWatch Monitor or Server to connect to “prod.acme.com” through the Cloud Router, you must define a Cloud Router access token.
This token is used to authenticate and authorize incoming routed requests to the production domain.

The access token is configured from within the dbWatch Control Center:

1. Open “Domain Configuration” for the prod.acme.com domain.
2. Select “Edit” in the Cloud Router Access section.
3. Click New Entry to create a new access token.
4. The token value will be displayed as dots for security reasons. If you manage multiple tokens, you can assign each a Hint to distinguish them.
5. Copy the token value for later use when configuring Cloud Router connections.

Once the access token is defined, proceed to add a connection between the production domain server(s) and the Cloud Router:

1. In “Domain Configuration”, right-click on a Server and select Edit Connections.
2. Click Add Connection and specify the host:port of the Cloud Router.
3. Paste or select the access token created earlier when prompted.

Step four

Connecting a Monitor through a Cloud Router

Connect the client to the Cloud Router. Adding the client to the “prod.acme.com” domain works the same as a direct server connection, except that you must also provide the Cloud Router access token.

Connecting an additional dbWatch Server through a Cloud Router

In a multi-server setup, an additional dbWatch Server can also be connected to an existing dbWatch domain through a Cloud Router.

Unlike connecting a Monitor, this requires some manual configuration on the dbWatch Server.

The following example assumes that the additional Server will join the existing “prod.acme.com” domain using the Cloud Router configured in the previous steps.

Configure the dbWatch Server

Install dbWatch Control Center on the additional Server.

The following configuration files must be checked or modified on the Server.

For Linux, the default configuration directory is:

/var/dbwatch-controlcenter/config/node/

For Windows:

C:\ProgramData\dbWatchControlCenter\config\node\

1. Configure trustStore

The trustStore directory must contain the certificates from the production domain controller.

Copy the certificate files from the Domain Controller, or from another node already connected to the same domain, into:

config/node/trustStore

These certificates are required to establish trusted communication with the domain.

2. Configure governingDomain.json

Check or create the following file:

config/node/governingDomain.json

The file must contain the name of the production domain.

Example:

{
    "domain":"prod.acme.com"
}

3. Configure node.connections

Edit the following file:

config/node/node.connections

The connectTo section must contain the host and port of the Cloud Router, or another node that can communicate with the Cloud Router.

Example:

{
    "versionCutoff":"",
    "nodeCost":"0",
    "listenTo":[
        "dbw://localhost:7100"
    ],
    "connectTo":[
        "dbw://10.10.10.10:7100"
    ]
}

Replace 10.10.10.10:7100 with the actual address and port of the Cloud Router.

The other settings, including listenTo, should normally be preserved from the existing Server configuration.

4. Configure domain_connections.json

Check or create the following file:

config/node/domain_connections.json

The domain_connections.json file uses the same format as the corresponding file on a dbWatch Monitor.

To obtain the required configuration, first configure a dbWatch Monitor on the same machine as the additional dbWatch Server and connect it to the production domain through the Cloud Router.

Once the Monitor has been successfully configured, copy its domain_connections.json file to the Server’s config/node/ directory.

Important: The user and password fields may contain credentials generated during the Monitor setup. These fields must be cleared when configuring an additional dbWatch Server in a multi-server setup.

Make sure both fields are empty:

"user":"",
"password":""

Also verify that the domain, token and urls values are correct.

Example:

{
    "domains":[
        {
            "domain":"prod.acme.com",
            "token":"<GENERATED_TOKEN>",
            "connect":"true",
            "user":"",
            "password":"",
            "urls":[
                "10.10.10.10:7100"
            ]
        }
    ]
}

The relevant parameters are:

Make sure the domain, token and URL are correct.

Note that the urls value does not include the dbw:// prefix used in node.connections.

5. Remove existing cryptographic configuration if required

If the Server (Hub) has previously been connected to a domain, its existing cryptographic configuration may need to be removed before connecting it to the new domain.

This is normally not required for a new installation.

Stop the dbWatch Server service before removing the old cryptographic configuration. Back up the relevant files first, and confirm the exact crypto files or directory before deleting anything.

Make sure the trustStore contains the required certificates from the production Domain Controller.

The Server’s cryptographic configuration will be regenerated after it has connected and been approved by the Domain Controller.

6. Start the Server and approve the node

Start the dbWatch Server service after completing the configuration.

Once the Server establishes communication through the Cloud Router, it should appear as a new node in the production domain.

In dbWatch Control Center:

  1. Open Domain Configuration for the “prod.acme.com” domain.
  2. Locate the newly registered Server in the node list.
  3. Select Approve to authorize the new node.

After approval, the required cryptographic configuration will be regenerated automatically, provided the trustStore contains the correct certificates.

Verify that the Server is connected and visible in the domain configuration.

The additional dbWatch Server should now be part of the existing multi-server domain, communicating through the Cloud Router.

Optional network optimization

Nodes in dbWatch have a network cost associated with them. This is used when routing messages to figure out the optimal route for messages to travel.
If you are setting up a network with redundancy (f.ex that there are multiple cloud routers connecting your networks) you might want to tweak the cost settings of the nodes in order to assure that a certain path is preferred.

By default, passing a message through a node has a cost of 128. So sending a message through two jump nodes will mean a cost of 256, in this way a shorter route will always have a lower cost, and thus be preferred.

In addition to the base cost of 128, a node will try to determine how powerful the underlying machine is and add a cost between 1 and 10 to reflect this. So a node running on a more powerful machine will tend to have a lower cost.

If you are not happy with the computed cost, there is an optional extra that can be added. This is defined in the “[dbWatch Work]/config/node/node.connections” file.

Example file:

{
	"versionCutoff":"",
	"nodeCost":"0",
	"listenTo":[
		"dbw://localhost:7101"
	]
,	"connectTo":[
		"dbw://192.168.8.12:7100"
	]
}

The “nodeCost” value can be adjusted to any number you want, this will be added to the base node cost. (This can also be a negative number, to subtract from the base cost).
Changing this setting is not currently dynamic, so the node must be restarted for changes to take effect.