com.atlassian.confluence.content.render.xhtml.migration.exceptions.UnknownMacroMigrationException: The macro 'html' is unknown.

System Architecture

Owned by Omry Koschitzky
Last updated: Dec 23, 2021 by Haim Koschitzky
2 min read

This article discusses XpoLog's architecture and different deployment scenarios. The key parameters that helps deciding which deployment architecture are daily logs volumes, retention policy, number of monitors, number of dashboards, etc. for the required processing power and mainly number of concurrent users for the required WEB Interface nodes.

Clustering XpoLog has several key advantages for enterprises environments:

  • Multiple points of failure - all cluster nodes may function as alerting and processing nodes in cases of failures to avoid loss of data / loss of service.
  • Fast Disaster Recovery (DR) - XpoLog has automated procedures to maintain configuration backups that may be easily used to restore a system.
  • High Availability (HA) - Upon cluster node failure the cluster manager immediately identifies it and alerts. Until the failed node resumes, its processes are automatically assigned to another node to ensure all activities are performed.
  • Fault tolerance - During a cluster node failure or following an entire cluster failure, XpoLog recovers immediately and accurately to complete undigested data, reports and monitors.

 

It is recommended to consult with XpoLog support prior to setting up the clustered environment.

Deployments Architecture


Basic Installation

At its basic format, XpoLog installs as a single process. This process includes everything that is needed to run and use XpoLog including the WEB interface and data processing engines. XpoLog requires only a file system based storage to manage data and configurations. See more details at the installation guide.

The following diagram demonstrates XpoLog's single process main components:

 

 

XpoLog Single Machine Cluster

XpoLog scales easily by separating the web interface and back end processing engines. The XpoLog Center cluster is composed of several instances, using a common storage in order to share the system tasks load and users’ activity. Some of the instances function as processor nodes, taking care of back-end tasks (indexing, analysis, monitoring, and more), while the rest of the instances function as UI nodes. This architecture enables easy scaling of XpoLog Center in heavily loaded environments, without influencing the users’ front-end experience. See more details at the basic cluster installation guide. 

A basic cluster of XpoLog may be consisted of 2 such separated processes running on the same machine (commonly, this will be suitable for smaller environments as an initial clustered deployment):

 

 

XpoLog Multiple Machines Cluster

A more advanced clustering deployment would be usage of 1-N UI nodes and 1-M Processor nodes to support users load and high daily volumes while preserving excellent service. See more details at the cluster installation guide. 

The machines that runs XpoLog may be physical or virtual: