SIP Ecosystem

SIP Roles

To facilitate the distributed capabilities of the SIP software suite, FMOS provides tools for deploying multiple servers that communicate with one another. Each server can hold one or more roles, which define its responsibilities and the components of SIP that it runs.

  • Application Server (AS): Servers with this role run the SecMgr and Workflow services and expose their HTTP APIs to network consumers. These servers also expose the web-based user interface applications. An ecosystem must have at least one server with this role.

  • Certificate Authority (CA): FMOS uses TLS and IPsec to enable secure communication between SIP components, including the PostgreSQL database, the Elasticsearch index, SecMgr, the Data Collector, etc. These protocols use X.509 certificates to authenticate the communicating parties to one another. FMOS manages an X.509 Certificate Authority to issue and validate these certificates. Exactly one machine in the FMOS ecosystem must have this role. Under normal circumstances, the first machine created in the ecosystem will hold the CA role.

  • Database Server (DB): Servers with this role run the PostgreSQL database management engine, which houses the data used by FireMon Security Manager. Additionally, these servers store data, such as normalized configuration, in files on the filesystem, which can be shared with other servers in the ecosystem. An ecosystem can have exactly one server with this role.

  • Data Collector (DC): Servers with this role are responsible for communicating with devices managed by Security Manager, for example to retrieve configuration and process log messages. An ecosystem must have at least one server with this role.

  • Enterprise Search (ES): Servers with this role run Elasticsearch to provide high-performance search capability for FireMon Security Manager. There must be at least one machine with this role in the ecosystem. It is typically held by the same servers that hold the Database Server (DB) role.

A server may run a combination of roles as well. It is very common for a single server to hold all three roles. In medium-sized environments, it is likely that there will be one server that holds the AS and DB roles, and one or more separate servers with the DC role. Very large environments may have one server with the DB role, and many servers with each of the other roles.

Deployment Scenarios

FMOS supports several deployment scenarios, each with specific strengths. The size of the deployment will mostly depend on which features (modules) of SIP will be used, how many devices it will monitor, and many other factors. FMOS cannot make specific recommendations on which scenario is correct for any specific case. In general, however, the larger deployment scenarios tend to perform better than the smaller ones.

Single-Server

In a single-server deployment (also called an all-in-one or AIO deployment), a single machine holds all of the SIP roles. This is very easy to set up, and requires very little maintenance. It also performs extremely poorly in almost all cases, so its use should be limited to demonstration or evaluation purposes only.

Partially Distributed

A partially distributed deployment is one where one machine holds the AS, CA, DB, and ES roles, with one or more separate machines holding the DC role. This type of deployment is useful in small environments where the machine serving the HTTP API and Web UI is not able to directly communicate with the devices Security Manager monitors. Like the single-server deployment, performance in this type of scenario is generally poor, so its use is discouraged.

Fully Distributed

In a fully distributed deployment, each SIP role is held by a separate machine. Such a deployment requires at least three machines: 1 CA+DB+ES, 1 AS, and 1 DC. This type of deployment takes advantage of the horizontal scalability built into each component of SIP; performance of a component increases with the number of those components present in the ecosystem.

This type of deployment, while more difficult to deploy, is strongly encouraged for all use cases.

In a fully distributed ecosystem, FMOS requires a shared filesystem for AS machines to store non-relational data (such as normalized configuration files, etc.). In single-database mode, the machine holding the DB role shares its local filesystem with the AS machines using NFS. In multi-database mode, the DB machines form a clustered filesystem that replicates its contents to each DB machine. The AS machines access this cluster using NFS.

Multiple-Database Mode

By default, FMOS only allows a single machine in the ecosystem to hold the DB and ES roles. To facilitate rapid disaster recovery scenarios, FMOS can be configured for multi-database mode. In this mode, additional machines can hold these roles in a standby capacity. The original database machine operates as a primary server, replicating its changes to the standby machines. In the event of a failure, one of the standby machines can be promoted to become the primary.

Role Hierarchy

Machines in an FMOS ecosystem are organized hierarchically. The relationship between machines is described as superior or subordinate. In a typical ecosystem, the machine that holds the DB role is the superior of all of the machines with the AS role. Thus, the AS machines are subordinates of the DB machine. Similarly, machines that hold the DC role are subordinates of a machine with the AS role.

The figure below shows the relationship between roles in a fully distributed ecosystem. The arrows point to the superior server of each role.

Planning the Ecosystem

It is important when implementing a multi-server ecosystem to plan how many servers will be required and which roles each server will hold. Having this information available ahead of time will ease the deployment process significantly. The following questions can help identify exactly which steps need to be performed in order to correctly deploy the ecosystem:

  • Will the server holding the DB role be separate from the server holding the AS role?

  • How many servers will hold the AS role?

  • Will the servers holding the DC role be separate from the AS roles?

It is a good idea to list each server that will exist within the ecosystem, which roles it will hold, as well as its host name and network settings before beginning.

Which Ecosystem Deployment is Right for Your Organization?

These are only visual representations of potential deployment options. Your environment is unique.