## Overview
One of the key advantages of distributed functionality is that load is taken away from the main Opsview Monitor system and is shared around other servers.
It should not be necessary for the majority of organisations to do this as the [Simple Automated Installation](🔗) sets up all components onto one server but if you have:
a large numbers of devices to monitor,
high-demand monitoring requirements
a greater need for resiliency against failures
then you can easily move necessary components to other locations.
## Opsview Monitor Packages
This is a list of all the available packages that comprise Opsview Monitor. For a server to perform specific functionality, only those required packages details on the sub-pages need to be installed.
**Note**: See also the numbers notes for some rows in this table.
| Component Name (according to Watchdog) | Alias (According to Web UI) | Distributed Status | Required |
| opsview-agent | Agent | Distributed | Yes |
| opsview-autodiscoverymanager | Autodiscovery Manager | Orchestrator only | Yes |
| opsview-bsm | BSM | Distributed | Yes [2](🔗) |
| opsview-datastore | DataStore | Distributed | Yes [2](🔗) |
| opsview-downtimemanager | Downtime Manager | Distributed | Yes [2](🔗) |
| opsview-executor | Executor | Distributed | Yes [2](🔗) |
| opsview-filesync | File Sync | Distributed | Yes [3](🔗) |
| opsview-freshnesschecker | Freshness Checker | Distributed | Yes [2](🔗) |
| opsview-licensemanager | License Manager | Orchestrator only | Yes |
| opsview-loadbalancer | Load Balancer | Distributed | Yes [5](🔗) |
| opsview-machinestats | Machine Stats | Distributed | Yes [4](🔗) |
| opsview-messagequeue | MessageQueue | Distributed | Yes [2](🔗) |
| opsview-notificationcenter | Notification Center | Distributed | Yes |
| opsview-orchestrator | Orchestrator | Orchestrator only | Yes |
| opsview-registry | Registry | Distributed | Yes [2](🔗) |
| opsview-resultsdispatcher | Results Dispatcher | Distributed | Yes [2](🔗) |
| opsview-resultsforwarder | Results Forwarder | Distributed | Yes [3](🔗) |
| opsview-resultslive | Results Live | Distributed | Yes [2](🔗) It is sharded (each resultslive node handles a specific subset of objects) |
| opsview-resultsperformance | Results Performance | Distributed | Yes [2](🔗) |
| opsview-resultsrecent | Results Recent | Distributed | Yes [2](🔗) |
| opsview-resultssender | Results Sender | Distributed | Yes [3](🔗) |
| opsview-scheduler | Scheduler | Distributed | Yes [3](🔗) |
| opsview-snmptraps | Snmp Traps Daemon | Distributed | No |
| opsview-snmptrapscollector | Snmp Traps Collector | Distributed | No |
| opsview-statechanges | State Changes | Distributed | Yes [2](🔗) |
| opsview-timeseries | TimeSeries | Distributed | Yes [2](🔗) It is sharded (each timeseries node handles a specific subset of objects) |
| opsview-timeseriesenqueuer | TimeSeries Enqueuer | Distributed | Yes [2](🔗) |
| opsview-timeseriesinfluxdbqueries | TimeSeries InfluxDB Queries | Distributed | Yes [1](🔗) |
| opsview-timeseriesinfluxdbupdates | TimeSeries InfluxDB Updates | Distributed | Yes [1](🔗) |
| opsview-timeseriesrrdqueries | TimeSeries RRD Queries | Distributed | Yes [1](🔗) |
| opsview-timeseriesrrdupdates | TimeSeries RRD Updates | Distributed | Yes [1](🔗) |
| opsview-watchdog | Watchdog | Distributed | Yes |
| opsview-web | Web | Orchestrator only | Yes |
| opsviewd | Daemon | Orchestrator only | Yes |
###### Footnote 1
RRD and InfluxDB could be used as alternatives - so either RRD Updates/Queries or InfluxDB Updates/Queries
###### Footnote 2
Distributed components - can be installed and run on multiple servers but only one will be in use any any time
###### Footnote 3
Collector components. One set will be installed on Orchestrator server - any extras are proper Collector Servers. Only Scheduler is actually required on Collector - everything else could be remote.
###### Footnote 4
Components that is installed on every box that uses Watchdog (with the exception of SSH Tunnels to avoid dependency on Registry)
###### Footnote 5
Could be installed anywhere and on multiple servers
## Components Servers
The below information is relevant if you are intending to run an advanced installation. Some example configuration files are provided with the opsview-deploy:
For more information, follow the instructions on [Advanced Automated Installation](🔗)
This is the list of Component servers:
#### Orchestrator Server
Purpose: Orchestrator Server manages configuration and provides UI
Load: High
Packages:
#### Orchestator MessageQueue Server
Purpose: Message Bus for communication between Result Processing Components
Load: High
Documentation:
Connected Components:
Packages:
#### Orchestator Datastore Server
Purpose: Persistent Datastore
Load: High
Connected Components:
Packages:
#### Orchestrator Database Server (remote)
Purpose: Configuration and results Database
Load: High
Connected Components:
Packages:
#### Collector Cluster MessageQueue Server
Purpose: Collector Cluster-wide Message Bus
Load: Mid-High (depending on Cluster size and amount of monitored objects)
Connected Components:
Packages:
#### Collector Cluster DataStore Server
Purpose: Persistent DataStore
Load: High
Connected Components:
Packages:
#### Results-Live Server
Purpose: Live objects status processing
Load: High
Packages:
#### Results-Recent Server
Purpose: Gathering results for objects
Load: High
Packages:
#### Results-Performance Server
Purpose: Preparing performance metrics to be send to TimeSeries
Load: Medium
Packages:
#### Results-Dispatcher Server
Purpose: Routing passive results to Collectors
Load: Varies (depends on the amount of passive results)
Packages:
#### State-Changes Server
Purpose: Tracking state changes and notifying Notification Centre
Load: Medium/High
Packages:
#### Periodic Components Server
Purpose: Periodic checks
Load: Medium
Packages:
#### Registry Server
Purpose: Service Discovery
Load: High
Packages:
#### TimeSeries Server
Purpose: Processing and storing performance metrics
Load: High
Packages:
#### Collector Server
Purpose: Hosts and services monitoring
Load: High
Packages: