Distributed Operations

Iotellect 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 Iotellect 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 Iotellect failover cluster, servers participating the distributed architecture are completely independent. Each server has its own database, local user accounts and associated permissions, etc.

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 addition, 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.

Distributed architecture is ideal for performing control and configuration operations in a large multi-server Iotellect installation. As for transferring data between system tiers or nodes of a horizontal cluster, the Local Agent driver should be used for that.

Here is an example of multi-tier Iotellect-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 Iotellect server in the above schema may, indeed, be a multi-node failover cluster.

Iotellect Network Manager system build atop of Iotellect is one of the most typical use cases for the distributed architecture. Large segmented networks of corporations and telecom operators cannot be monitored from a single location due to routing restrictions, security concerns and limited bandwidth between geographically separated segments.

Thus, the unified monitoring system is usually composed of several components:

• A primary or central server consolidating aggregated information from all network segments
• Secondary or probe servers that perform polling of devices in isolated segments
• Specialized servers, such as a traffic decomposition server that handles billions of NetFlow events per day

Secondary and specialized servers act as data providers for the primary server, exposing a part of their data model for the control center. This can be:

• The whole content of probe server's context tree, allowing full monitoring and configuration through the central server. In this case probe server is just used as a proxy for overcoming network segmentation issues.
• Alerts generated by probe servers. In this case 99% of jobs are performed remotely, but central server operators are immediately notified about issues raised in secondary segments.
• A custom set of probe server's data, such as certain mission-critical devices and important overview reports. The actual polling and report generation will be performed by the secondary server, allowing to properly balance system load

The consumer/provider connectivity of Iotellect Server is enabled by Distributed Architecture plugin. The global configuration context of this plugin provides access to:

• Providers configuration
• Consumers configuration
• Distributed server status

Was this page helpful?

Tell us more

Send

Thank you!