Plan your Semaphore installation

Architecture planning and partitioning for Semaphore

When designing architecture for Semaphore, one of the most important considerations is resource usage of the Semaphore components. The demand components have on resources largely determine how the components are partitioned and the required specifications of their servers. It's worth noting that resource demand can be influenced by a number of factors, such as the number of documents processed and how often documents are created or modified. These factors should be considered when planning your architecture.

The following is the resource usage by component for a typical implementation:

• Semaphore Studio: Large amounts of RAM but low CPU (on average)

• Classification and Language Service (CLS): RAM and CPU activity is generally very high. As a result of the high resource demand, we recommend that you isolate this component as much as possible from other components.

• Semantic Enhancement Service (SES): Only used as requested by users so only uses resources as needed, however, performance is critical as this is, generally, the interface by which users other than Information Scientists directly access the Semaphore information.

Semaphore components can be installed on separate servers (See Network firewall configuration for firewall considerations). By installing on multiple servers, the architecture can be designed in such a way to ensure that component execution does not interfere with other components installed on the same machine. For example, with three servers, an implementation for an average size implementation would take the following structure:

• Server A: Hosts Semaphore Studio, including Knowledge Model Management with the Publisher

• Server B: Hosts Semantic Enhancement Server

• Server C: Hosts Classification Server

This design ensures that the high activity of Classification Server does not interfere with the serving of Semantic Enhancement Server information. Maintaining the performance of the Semantic Enhancement Server is critical because its information is delivered to the end user.

A few things to note when designing the architecture for your Semaphore implementation:

• For implementations that handle large numbers of documents, deploying the Classification Server on multiple servers is highly recommended.

• Although using load balancers is possible for a number of Semaphore components, they should not be used for Semaphore Studio or any of its sub-components, as the connection by clients to this application must be persisted.

• Progress Semaphore can assist in the design of any architecture required for a particular implementation. Contact Progress for more information.

Linux services created and used by Semaphore

During installation, the following services are created on the target server:

• semaphore: A service that controls Semaphore Studio, KMM, and DA.

• semaphore-ai: The AI Model Builder sub-component of the Studio component.

• semaphore-alert: The Alerting Service sub-component of the Studio component.

• semaphore-cm: The Concepts Server Manager sub-component of the Studio component.

• semaphore-concepts: The Concepts Server.

• semaphore-cs: The Classification Service.

• semaphore-da: The Document Analyzer sub-component of the Studio component.

• semaphore-kmm: The Knowledge Model Manager and Knowledge Review Tool sub-component of the Studio component.

• semaphore-pr: The Precision and Recall Server.

• semaphore-rm: The Rulenet Manager sub-component of the Studio component.

• semaphore-rs: The Reconciliation Server.

• semaphore-ses: The Semantic Enhancement Service.

• semaphore-sm: The SES Manager sub-component of the Studio component.

• semaphore-studio: The front end to the Semaphore User Interface.

You can start or stop these services, as with all Linux services, using the following commands below.

• To start the service:
  Copy

  systemctl start \<service-name>
  

• To stop the service:
  Copy

  systemctl stop <service-name>
  

• To check the status of the service:
  Copy

  systemctl status <service-name>
  

Network firewall configuration

Any network configuration and firewall software should allow communication between the relevant external systems (for example, a CMS you may be using) and the Semaphore installation server. The following are the default TCP/IP ports used by the Semaphore components (note that all port numbers are configurable):

* Ports marked as Inter-Product, allow communication between Semaphore components; ports marked External provide services to external-facing applications, such as any product integrating with Semaphore; and ports marked Local are for sub-components within a single installed Semaphore component and on the same physical machine, so network/firewall configuration is not required.

Note: If Semaphore components are installed on multiple servers, then ensure that the relevant External or Inter-Product TCP/IP ports are open.

External triplestore products supported

Knowledge Model Management has built-in support that uses a Jena TDB triplestore, but it also supports the use of the following external triplestore products: Marklogic 8.04 (or later)

Next steps

Requirements