Configuring Insight Server for production

You must create, customize, and configure the different servers to use in a production 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. SmartCloud Analytics servers can be configured to process and analyze logs across your 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 there are 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 required for establishing 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`)	A catalog server is required for HA. A HA cluster requires at least 2 catalog servers. Properly configured for HA, each catalog server must run on different hardware, and not on the same hosts as the runtime servers.
Run-time (template name `cisContainer`)	Stores entities and system information, and runs agents and analytical jobs. Ideally, a production topology contains no fewer than 4 runtime servers. Configure runtime servers on different hosts than catalog servers.
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 three 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.

Use a minimum of four runtime servers so that transitions are smoother during shutdown of the hosts. You must also have one host that is not part of planned capacity, so that it can fail without impacting the cluster. For example, if your sizing calculations suggest that you need 120 GB of memory for your solution, configure four servers with 40 GB of memory. If one server is lost, you still have 120 GB to run the solution.

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.

You must balance the load of HTTP inbound connectivity across all hosts with a connectivity server.