AggreGate is one of a few device monitoring/management systems in the world that supports true distributed architecture. This architecture is designed to assure unlimited scalability by balancing all operations between AggreGate Server servers subdivided in multiple layers. Such common distributed architecture is expected to serve as a base for any modern and prospective management software.
Unlike nodes of AggreGate failover cluster, servers participating the distributed architecture are completely independent. Each server has its own database, local user accounts and associated permissions, etc.
Purpose of Distributed Operations
The primary objectives of distributed architecture are:
| • | Scalability. Lower-level servers may be heavily loaded by near-real-time control and extensive polling of devices. However, in practice the number of devices that can be managed by a single server is limited to several thousands. To scale the system for larger number of devices, it's reasonable to install multiple servers and join them into a distributed installation. |
| • | Load Balancing. Each server in a distributed installation solves its own task. Network management servers check availability and operability of IP network infrastructure, while physical access control servers are serving requests from door/turnstile controllers. In plus, the supervising operations (such as generating and emailing reports) can be performed by a central server. |
| • | Firewall Penetration. Secondary "probe" servers may be installed in remote locations and connect to the central server themselves. System operators connect to the central server only, so there is no need to setup VPNs and port forwarding to the secondary servers. |
| • | Centralization. Secondary servers may work in fully automated mode, while their overall operation may be supervised by a single human via primary server installed in the central control room. |
Example: Smart City Management
Here is an example of multi-tier AggreGate-based architecture for smart city management/monitoring:
| • | Layer 1: physical hardware (network routers, controllers, industrial equipment, etc.) |
| • | Layer 2: direct management servers (network monitoring server, access control server, building automation server, etc.) |
| • | Layer 3: building control center servers (one server per a building, consolidates information from all "specialized" Layer 2 servers in this building) |
| • | Layer 4: urban district servers (the final destination for escalated lower-level alerts, real-time monitoring by human operators, integration with CRM systems) |
| • | Layer 5: HQ server (supervision of area-wide servers, collection of overall reports and alerts) |
Any particular AggreGate server in the above schema may, indeed, be a multi-node failover cluster.
Distributed Architecture Concepts
All AggreGate Servers have common model of their internal data: the context tree. Each context in this tree is responsible for managing certain device or system resource, be it alert or report.
In the distributed architecture, each server can act as provider or consumer of data to/from other servers:
| • | Consumer gets a certain sub-tree of other server's context tree and connects its own context tree (i.e. imports contexts from other servers) |
| • | Provider allows other servers to use its contexts (i.e. exports its contexts to other servers) |
Once a consumer server has imported a context sub-tree from another server, the server's own contexts may interact with imported contexts. Here are several examples:
| • | If server B imports a device context from server A, it may declare an alert that checks certain metric of this device and fire an alert if threshold is exceeded. In this case, the physical device will be polled by server A, but the alert will be processed by server B. |
| • | If server B imports a user account context from server A, the system operators may fully control all devices and resources of this user by connecting to server B. However, all modifications will be redirected to server A and saved in its database. This may be useful if operators have no direct access to the server A, e.g. if it's installed in the private LAN. |
| • | Finally, server B may import the whole context tree from server A. In this case, any resource from server B may access all resources of server A, allowing any type of interaction. |
Communications Between Providers and Consumers
All communications between consumer and provider servers are performed via IP networks using SSL-secured connections. The communications are truly bidirectional:
| • | Consumers can connect to providers and accept incoming provider connections. |
| • | Similarly, providers can connect to consumers themselves and accept incoming consumer connections. |
The two-way communications eliminate any troubles may be caused by different network configurations and firewalls.
Any AggreGate Server can be consumer and provider simultaneously. Moreover, it can have multiple links, i.e. import contexts from several servers and export its own contexts to several other (or even the same) servers.
Distributed Architecture Plugin
The consumer/provider connectivity of AggreGate Server is enabled by Distributed Architecture plugin. The global configuration context of this plugin provides access to:
Permissions In Distributed Environment
Once connection between consumer server (CS) and provider server (PS) is established, the CS authenticates on the PS using certain PS user's credentials. Thus, CS gets the permissions of this user at the PS. All operations on the PS that are initiated by the CS (or human operators of the CS) are performed according these permissions.
Simply speaking, at the side of provider the consumer is nothing more than a Client that has connected and logged in.
However, if the operators of CS want to access contexts imported from PS, they must connect to the CS and authenticate as a certain CS user first.
Let's resume the above. Imagine that server B (the consumer) imports context "context123" from server A (the provider). The local path of this context at server B is "mount.context123" (according the provider configuration). The server B authenticates at server A as user "userA" (defined on server A). Human operator connects to server B and wants to perform an operation with imported context. He authenticates at server B as user "userB" (or course, defined on server B). Here are the required permissions:
| • | User "userB" on server B must have permissions to access the context "mount.context123" at server B. |
| • | User "userA" on server A must have permissions to access the context "context123" at server A. |