Development and production servers

Decision Server Insights can be configured in a number of ways. An optimal configuration must be adapted to meet your business and performance needs.

Configuring a Decision Server Insights topology can seem complicated, because there are so many options. However, it is not as complicated as it seems at first, because many of the options are not realistic in real world scenarios. There are five different server templates, database configuration, and the question of how many hosts to use. The best way to start is to make the choice between a highly and continuously available Insight Server and one that is not.

High Availability (HA) means that one server of the topology can go down unexpectedly, and it continues to operate normally. Continuous Availability (CA) is related, and means that the topology can remain operational during maintenance operations, such as a hardware upgrade or operating system update. In addition to hardware and operating system maintenance, Decision Server Insights can be continuously available during the installation of a fix pack, and some minor releases. Upgrading to a major release, however, requires that the whole topology is taken down before migration.

A development server is non-HA. It is faster and easier to use than a HA topology. You can, however, configure all the servers of a topology on the same host or on multiple hosts in a non-HA manner. For example, connectivity servers can be run on the same Liberty server as a runtime server or on another server on a single host.

Note: Other applications cannot be installed into the instance of Liberty that is hosting connectivity without separately licensing that Liberty instance.

To achieve HA, you create a topology to meet your availability needs and to ensure minimal downtime if an IT system disruption occurs (disaster recovery). You use the provided server templates to create the appropriate number of server types with synchronization and backup replicas. Availability and performance can be scaled up horizontally by adding more servers.

Single server (development)

You can create a development environment on a single computer by using the cisDev server template.

cisDev: In a single-server, the runtime environment and operations are centralized in a single data center. Inbound and outbound connectivity is hosted with the runtime server. HTTP features are enabled and JMS inbound and outbound features can be configured, if required. Persistence is turned off by default, and there is no disaster recovery facility.

Multiple server topology (production)

In a production environment, you use the provided mandatory server templates to configure a multiple server topology.

cisCatalog

Catalog servers distribute the physical storage of data when a runtime server joins or leaves the cluster. They monitor the health of the cluster and provide data location services to clients. One or more catalog servers coordinate work among themselves to provide the catalog services. When there is more than one catalog server, one of them has special responsibilities and it is known as the master or primary catalog server. The group of catalog servers, together with the group of runtime servers that they oversee, constitute a catalog service domain.

One catalog server is fine for non-HA topologies, but two are needed for HA and three are required for network HA. The catalog server must not be installed on the same host as a runtime server in any HA environment.

cisContainer: Runtime servers use catalog server cluster endpoints, which are included in the runtime server configuration, to establish a communication link with the catalog servers so they become part of the cluster. The number of required runtime servers depends on the number and type of solutions that you run on the cluster and the volume of events that they process. This number can grow or shrink, but typically there are a minimum of four runtime servers in a production environment.

cisInbound: Inbound connectivity servers are responsible for the event flow into the system, so there is likely to be some redundancy for these servers. A good starting point is to use two servers on two different computers. Two computers is the minimum requirement to avoid a single point of failure. There is no general guideline to determine the actual number of inbound servers that is required for a particular event throughput. Throughput depends on the size of the event data, the type of event transformations, the type of protocol used (HTTP, JMS), and whether event persistence is used. Start with two servers and monitor resource usage (CPU, memory). For high event rates, you can add servers to the same computer until the ideal resource consumption threshold is reached after which you can add new computers if required.

cisOutbound: Outbound connectivity servers are responsible for the event flow out of the system, so there is likely to be some redundancy for these servers. A good starting point is to use two servers on two different computers. Two computers is the minimum requirement to avoid a single point of failure. There is no general guideline to determine the actual number of outbound servers that is required for a particular event throughput. Throughput depends on the size of the event data, the type of event transformations, the type of protocol used (HTTP, JMS), and whether event persistence is used. Start with two servers and monitor resource usage (CPU, memory). For high event rates, you can add servers to the same computer until the ideal resource consumption threshold is reached after which you can add new computers if required.

Ordinarily, each type of mandatory server is configured for HA on a separate host. However, you can customize your configuration to meet your needs. For example, you might want to enable inbound and outbound connectivity on the same host, or create servers of the same or different type on a single host.