The Directorate server is used to manage the communication with the agents and to provide an interface for administrators to interact with the application.
Primary vs. Secondary
A Directorate server can be setup as either a primary server, or one of many secondary servers for that primary. This is referred to as a Directorate region. The primary server holds the database and all secondary servers access that database on the primary. The database can also be kept separate on a server of its own if required.
The servers provide the following services.
| Service | Primary | Secondary |
|---|---|---|
| Web interface for administration | Yes | No |
| Web API for agent communication | Yes | Yes |
| Policy generation for agents | Yes | Yes |
| Inventory and performance data loading | Yes | Optional |
| Message loading | Yes | Optional |
| Target group processing for server side rules | Yes | No |
| Software package source | Yes | Yes |
| Replication to other regions | Yes | No |
| Database maintenance | Yes | No |
| Message rule processing | Yes | No |
Any secondary server can be promoted to be the primary, but there can be only one primary in a region at a time. This allows one to perform maintenance on the primary server without losing all services that it provides (assuming your database is kept on a separate server).
Replication and Scalability
(Not developed yet). Primary servers in different Directorate regions can replicate data between each other. Partnerships are setup by the administrator and can define exactly what types of data will be shared in either direction. There is no pyramid or top down design implied on the partnerships so complex environments can be setup.
The following types of data transfer between regions are provided:
- Pushing data to a partner region such as:
- computer details
- inventory data
- performance data
- event messages
- Pulling definitions for
- companies
- agent assignments
- target groups
- data collections
- software packages
- monitors
- message rules
- tools
- users and teams
- others
Each region can decide if it is going to store agent data itself, or simply pass it to the partner region. This allows you to build the top-down hierarchy if you wish. Local processing of event messages however can reduce the load on higher levels of the framework and importing of data is used by target group processing.
Each region can have its own definitions as well as those it downloads from a partner. The downloaded definitions will be locked from changes, but the local ones can be changed at any time. This allows you to have different groups of administrators in the case of a multi-company configuration.
Database Support
The database for a region can be either Microsoft SQL Server 2008 and later, or PostgreSQL 9.3 and later. The Express versions of SQL Server are supported but your environment must be very small to fit within the 10GB database limit.
For a free cost option, PostgreSQL can be used on either Windows or UNIX based systems. It has no database size limits other than the resources of the computer it is installed on and is known to handle databases in the terabyte sizes. PostgreSQL can be installed in under 5 minutes and comes with its own management tools. Directorate also takes care of making daily backups automatically if configured in the web interface. PostgreSQL can also be run on desktop versions of Windows, should you want to build a test install of Directorate.
It is always best to use the latest version of a database as possible as Systems Directorate does not use any special SQL that may be deprecated in future releases. Support for SQL Server 2008 may be removed as it does not support the more common SQL syntaxes now so 2012 is recommended if you follow the Microsoft route.
Regions do not have to use the same database type. All data being transferred between regions is in XML format and will be imported into the destination database, no matter which type.
Agent Assignments
A list of rules is used to help agents find the Directorate server that they need to communicate with. This allows an agent to move around your network or even out into the Internet and still know how to contact the framework when required.