Sizing examples

As you design the architecture of your Tivoli Netcool/OMNIbus deployment, your sizing requirements can change. Use these examples, which show different types of Tivoli Netcool/OMNIbus system, to guide you. These examples consider the shared allocation of resources for components that are on the same host. These examples are based on the sizing guidelines in Sizing your deployment.

Small system

This system is designed for simple event capture, with high availability and visualization of events on web browsers. It consists of a failover pair of ObjectServers, connected by a bidirectional ObjectServer Gateway, which synchronizes the data between the ObjectServers, several TCP/IP probes on a remote host, which listen on the network for events and forward the events to the ObjectServer pair, and a Web GUI server, which is used to visualize the events in the ObjectServer pair.

This system is installed on four hosts, as follows:

  • Host A for the primary ObjectServer
  • Host B for the backup ObjectServer and bidirectional ObjectServer Gateway
  • Host C for the probes
  • Host D for the Web GUI

In this system, the primary ObjectServer, which takes the most system load during normal operations, is subject to the following operations:

  • Concurrent write operations from the probes
  • Read operations from the bidirectional ObjectServer Gateway
  • Read and write operations from the Web GUI connections

If only a few Web GUI clients are connected, the most load originates from the concurrent write operations by the probes. The following table lists the sizing guidelines for this system.

Table 1. Sizing guidelines for a small Tivoli Netcool/OMNIbus system
Host Sizing guidelines Explanation
A
Cores: 2
RAM: 4 GB
 If you expect only a few events in the primary ObjectServer, for example fewer than 50,000, you can consider capping the memory allocation. Otherwise, allow the memory to grow to the theoretical maximum of 4 GB.
B
Cores: 2
RAM: 4 GB
 Although two components run on this host, the backup ObjectServer is not subject to the same load as the primary ObjectServer, during normal operations. During a failover, the backup ObjectServer takes over full operations, but the gateway becomes redundant and no synchronization occurs between the ObjectServers. For this reason, the sizing guidelines for host A also apply to host B.
C
Cores: 2 for each probe
RAM: 2 GB for each probe
 Allocate 2 cores to each probe to reduce the risk of bottlenecks. If your expectations of network traffic indicate that both probes are unlikely to pick up events at the same time, reduce the number of cores. Allocate memory generously so that the probes can buffer, if required.
D
Cores: 2
RAM: 4 GB
 This guideline is suitable for 30 - 40 concurrent users. If you require more Web GUI users, increase the number of cores.

This system is not suitable if you expect high throughput of events. Because the system uses only a single ObjectServer and a single host for probes, this system is at risk of processor bottlenecks. If the probes are subject to an event storm, host A and host C are at risk. An event storm might be a burst of events that are picked by a probe over 30 seconds, at a rate greater than 400 per second. An event storm both increases the load on the processor and the number of events resident in the ObjectServer. The risk increases if multiple Web GUI users view pages that display high numbers of events because of the extra load placed on the ObjectServer.

Medium system

This system is designed for higher performance than a small system, with high availability and archiving functions for events, and visualization of events on web browsers. It consists of a collection ObjectServer to handle incoming events from probes, several TCP/IP probes that listen on the network for events, a unidirectional ObjectServer Gateway that forwards the events from the collection ObjectServer to the aggregation pair in a single connection, a SYSLOG probe that sends events over the network, a failover pair of aggregation ObjectServers that are connected by a bidirectional ObjectServer Gateway to synchronize the data between the ObjectServers, a remote third-party database, a unidirectional ObjectServer Gateway that archives events from the failover pair of ObjectServers and transfers the event to the database, and a Web GUI server that is used to visualize events in the ObjectServer pair.

This system is installed on six hosts, as follows:

  • Host A for the primary ObjectServer
  • Host B for the backup ObjectServer and the bidirectional ObjectServer Gateway
  • Host C for the listening probes, collection ObjectServer, and a unidirectional ObjectServer Gateway
  • Host D for the Web GUI server
  • Host E for the SYSLOG probe
  • Host F for the third-party database and the archiving unidirectional ObjectServer Gateway

In this system, the collection ObjectServer reduces load on the primary ObjectServer by handling the concurrent write operations from the probes. Events are passed as a single connection from the collection ObjectServer to the primary ObjectServer through a unidirectional gateway. Therefore, the concurrent write operations on the primary ObjectServer are minimal because the main load is read operations from the bidirectional gateway, the archiving unidirectional gateway and the Web GUI. The Web GUI causes some write operations as users modify events.

The following table lists the sizing guidelines for this system.

Table 2. Sizing guidelines for a medium Tivoli Netcool/OMNIbus system
Host Sizing guidelines Explanation
A
Cores: 2
RAM: 4 GB
 Consider more than 2 cores in the following circumstances:
  • The host has spare capacity.
  • You expect high numbers of events to reside in the primary ObjectServer, for example, greater than 50,000.
  • You expect high numbers of concurrent Web GUI users, for example, greater than 40.
B
Cores: 2
RAM: 4 GB
 Although two components run on this host, the backup ObjectServer is not subject to the same load as the primary ObjectServer, during normal operations. During a failover, the backup ObjectServer takes over full operations, but the gateway becomes redundant and no synchronization occurs between the ObjectServers. For this reason, the sizing guidelines for host A also apply to host B.
C
Cores: 6
RAM: 8 GB
 The cores are allocated as follows:
  • 2 for the ObjectServer
  • 4 shared between the unidirectional gateway and 2 probes
The RAM is allocated as follows:
  • 4 GB for the ObjectServer
  • 4 GB shared between the unidirectional gateway and 2 probes
Although four components are installed on this host, it is unlikely that all the components will have a high processing load at the same time. While 6 cores are sufficient, if you expect a low throughput of events, consider scaling back to four cores. Allocate memory generously so that the probes can buffer, if required.
D
Cores: 2
RAM: 4 GB
 This guideline is suitable for 30 - 40 concurrent users. If you require more Web GUI users, increase the number of cores.
E
Cores: 1 for each probe
RAM: 2 GB for each probe
 Probes that connect to a target or read from a log file use less CPU than listening probes. Leave capacity on the host for the application that the probe is monitoring.
F
Cores: 2
RAM: 4 GB
 Gateways that connect to databases use more memory that ObjectServer Gateways because they carry large amounts of data and because the connection method to the target database can be memory-intensive.

Large system

This system is designed for high-performance event capture, visualization of multiple sites, that is data sources, high availability functions at the collection layer and aggregation layer, archiving functions for events, and visualization of events on web browsers. The system can handle high throughput of events and large numbers of display clients. It consists of the following components:

  • Failover pair of collection ObjectServers that handle incoming events from probes
  • TCP/IP probes and SYSLOG probes
  • Failover pair of aggregation ObjectServers, that are connected by a bidirectional ObjectServer Gateway to synchronize the data between the ObjectServers
  • Unidirectional ObjectServer gateways to forward events from the collection pair to the aggregation pair
  • Display ObjectServer that handles the display clients, such as the Web GUI
  • Unidirectional gateway to forward events from the aggregation pair to the display ObjectServer
  • Remote third-party database and a unidirectional ObjectServer Gateway that archives events from the aggregation pair and transfers the event to the database
  • Web GUI server that is used to visualize events in the aggregation pair and to view events from a remote ObjectServer or pair of ObjectServers.

This system is installed on nine hosts, as follows:

  • Host A for the primary aggregation ObjectServer
  • Host B for the backup aggregation ObjectServer and the bidirectional ObjectServer Gateway
  • Host C for the primary collection ObjectServer and a unidirectional ObjectServer Gateway
  • Host D for the backup collection ObjectServer and a unidirectional ObjectServer Gateway
  • Host E for the display ObjectServer and a unidirectional ObjectServer Gateway
  • Host F for the Web GUI server
  • Host G for the listening probes
  • Host H for the SYSLOG probe
  • Host I for the third-party database and the archiving unidirectional ObjectServer Gateway

In this system, the primary collection ObjectServer handles the concurrent write operations from the probes to reduce load on the primary aggregation ObjectServer. The probes are configured to fail over to the backup collection ObjectServer if the primary collection ObjectServer fails. The main load on the primary aggregation ObjectServer is read operations from the bidirectional gateway, the archiving unidirectional gateway, and the unidirectional gateway to the display ObjectServer. The display ObjectServer handles the read and write operations from the display clients to reduce load on the primary aggregation ObjectServer. In this example, the display clients are Web GUI clients and desktop component clients. If dual-write mode is configured, event updates from the Web GUI clients are made in both the display ObjectServer and the primary aggregation ObjectServer. The Web GUI is configured to handle multiple data source so that it can handle events from the display ObjectServer and the remote ObjectServer in the same view.

Table 3. Sizing guidelines for a large Tivoli Netcool/OMNIbus system
Host Sizing guidelines Explanation
A
Cores: 4
RAM: 4 GB
 Because this system is larger than the previous examples, and supports greater numbers of events, more cores are needed. If you use fewer cores, the system is at risk during failover and failback operations.
B
Cores: 4
RAM: 4 GB
 Although two components run on this host, the backup ObjectServer is not subject to the same load as the primary ObjectServer, during normal operations. During a failover, the backup ObjectServer takes over full operations, but the gateway becomes redundant and no synchronization occurs between the ObjectServers. For this reason, the sizing guidelines for host A also apply to host B.
C
Cores: 3
RAM: 6 GB
 The cores are allocated as follows:
  • 2 for the primary collection ObjectServer
  • 1 for the unidirectional gateway
The RAM is allocated as follows:
  • 4 GB for the primary collection ObjectServer
  • 2 GB for the unidirectional gateway
Although two components are installed on this host, it is unlikely that all the components will have a high processing load at the same time.
D
Cores: 3
RAM: 6 GB
 The cores are allocated as follows:
  • 2 for the backup collection ObjectServer
  • 1 for the unidirectional gateway
The RAM is allocated as follows:
  • 4 GB for the primary collection ObjectServer
  • 2 GB for the unidirectional gateway
The sizing guideline for this host is the same as for host C.
E
Cores: 5
RAM: 6 GB
 The cores are allocated as follows:
  • 4 for the display ObjectServer
  • 1 for the unidirectional gateway
The RAM is allocated as follows:
  • 4 GB for the primary collection ObjectServer
  • 2 GB for the unidirectional gateway
Because this system is larger than the previous examples, and supports more display clients, more cores are needed. If only Web GUI clients connect to the display ObjectServer, that is, if no desktop clients connect, consider reducing the number of cores. Allocate memory generously.
F
Cores: 4
RAM: 4 GB
 This guideline is for large numbers of display clients, for example, over 40 Web GUI users.
G
Cores: 2 for each probe
RAM: 2 GB for each probe
 Allocate 2 cores to each probe to reduce the risk of bottlenecks. If your expectations of network traffic indicate that both probes are unlikely to pick up events at the same time, you can reduce the number of cores. Allocate memory generously so that the probes can buffer, if required.
H
Cores: 1 for each probe
RAM: 2 GB for each probe
 Probes that connect to a target or read from a log file use less CPU than listening probes. Leave capacity on the host for the application that the probe is monitoring.
I
Cores: 2
RAM: 4 GB
 Gateways that connect to databases use more memory that ObjectServer Gateways because they carry large amounts of data and because the connection method to the target database can be memory-intensive.

Extra large system

If the system needs to handle more than 100,000 standing alerts, closely monitor your system to ensure that it remains efficient. If you do see performance issues, consider data partitioning with another independent AGG pair. For more information, see the Omnibus Architecture Best Practices Guide: https://ibm.biz/nco_bps