Configuring a multiple server topology for testing and production

You must create, customize, and configure the different servers to use in a topology. The number of servers in your topology depends on your requirements.

When you design a topology, consider how many servers of each type you require, and allocate unique names to them. Insight Server for production is normally configured with persistence for the data grid. If you use persistence, you must configure a backing database.

Important: Insight Server uses WebSphere® eXtreme Scale. The criteria for effective WebSphere eXtreme Scale usage apply to Decision Server Insights. If you plan to use virtual machines, see Virtual image topology.

Under certain circumstances, you can mix servers of different types on the same host. For example, it can be simpler to put the inbound and outbound connectivity servers on the same host as the runtime servers. If each runtime server requires large amounts of memory, it is possible to configure multiple runtime servers on the same host. However, in a high-availability (HA) cluster, you must make sure that you have enough hosts not to lose data if one host is lost.

The key advantage of a separate Liberty instance for connectivity is the ability to stop inbound servers separately from the runtime servers. The separation provides an easy and controlled way to stop the flow of events before you shut down the runtime servers and the outbound connectivity servers.

Before you configure a topology of servers, you must install Decision Server Insights on each computer that you plan to host a server. You then use the installed templates to create each server type. You can then adjust the server configuration to match your production topology.

When you create a production topology, you must provide a keystore and optionally, a truststore. It is not necessary for all of the servers to use the same keystore. The keystores or truststore must contain the certificates that are needed to establish trust. You must also provide a user registry configuration that defines which users are authorized to access the server. The user registry can also authorize the administrator to use the JMX and REST APIs, if necessary.

You can use the TODO comments in the template server.xml files, and uncomment elements.

Table 1. Server types
Server type	Description
Catalog (template name `cisCatalog`)	Catalog servers are a WebSphere eXtreme Scale component that coordinate partition placement across a cluster. Multiple catalog servers are required for HA. An HA cluster requires at least 2 catalog servers. A cluster can run with no catalog servers for a short period. During an interval where no catalog servers are available, new gateway clients cannot connect and runtime servers cannot be added to the cluster, but the cluster does continue to receive and process events. When the first catalog server is added back, the runtime servers initialize it with the current state.
Run-time (template name `cisContainer`)	Stores entities and system information, and runs agents and analytical jobs. Ideally, a production topology contains no fewer than 3 runtime servers. To help runtime servers process events at a regular speed, do not run loads other than Decision Server Insights on the hosts of runtime servers. If a catalog server is running on the same host as a runtime server, all catalog servers of the cluster must be configured with majority quorum.
Inbound (template name `cisInbound`)	Submits inbound events to the cluster either through the gateway API, through HTTP, or through JMS. A production topology contains at least a single inbound server.
Outbound (template name `cisOutbound`)	Emits outbound events through HTTP or through JMS. A production topology contains at least a single outbound server.

Insight Server can be configured for different purposes:

Non-HA cluster

If your scalability needs are minimal, you can use a single server in a non-HA topology. A single host is faster and easier than a cluster. In a non-HA cluster, you must create a catalog server; inbound and outbound connectivity servers are optional. If you still have capacity after you created the server types you need, you can configure the backing database on the same host.

Important: Write-behind persistence must not be used for a non-HA topology.

The following figure shows a non-HA topology with a runtime server on each host, inbound and outbound connectivity on one host each, and a catalog server on one host.

If you have only one host, then all of the servers are on the same computer. The following figure shows a non-HA topology on a single computer; the backing database is on a separate host.

Note: Insight Server for production is normally configured with persistence, which is used for disaster recovery and other features. When persistence is enabled, all data is persisted in a database, which can be on a separate computer or on a computer that hosts a server. If the backing database is on a computer that hosts a server, you must add more capacity.

HA cluster

In a HA cluster, use the following goals, and prioritize them to help you identify which of them are must-haves:

The cluster must be highly and continuously available in a normal operation mode.
The cluster must withstand the loss of one runtime server without any loss of data and without loss of access to data.
The cluster must tolerate the controlled shutdown of one runtime server at a time to apply a rolling update or any other maintenance activity.
The cluster can accept and use new runtime servers.
The cluster must be restartable if the entire cluster is shut down, for example in the case of a disaster.
Grid data must be recoverable without loss in the case of a controlled shutdown of the cluster.
The system can tolerate the failure of at least one inbound and one outbound connectivity server.

A typical HA topology has a minimum of three runtime servers. The following figure shows a HA topology with a runtime server on four hosts, inbound and outbound connectivity on each of these hosts, and two catalog servers on separate hosts.