| Table of Contents | ||||||
|---|---|---|---|---|---|---|
|
Cluster Terminology
This topic introduces some of the concepts unique to the cluster creation and communication feature of A-Stack.
| Terminology | Description | Synonym Terms |
|---|---|---|
Network | A collection of A-Stack running instances that communicates (notifications) and keep persistent data store in sync. | Cluster, Clustering |
| Peer | A-Stack running instance that is participating in forming a Network | |
| Node | A-Stack running instance | Peer if participating in forming a network. |
| Group | Logical Name defined to make communication type between a collection of Nodes | |
| Advertise | Send Notifications to peer or group | |
| Replicate | Replication of data (TQL Storage) between nodes or a group of nodes |
...
| Transport | Broker Instance Type | Boroker Verison | Cluster Size | Cluster Relationship | Database |
|---|---|---|---|---|---|
| AMQP | AWS EC2 m1.medium | RabbitMQ 3.2.4 | 4 | AdvertiseTo | Remote Postgress RDS |
| WS | - | - | 4 | AdvertiseTo | Remote Postgress RDS |
...
- Transport Protocol Limitation: Only web socket protocol is supported for peer communications.
- No Auto / Mutual Discovery: There is no mutual discovery yet so each peer must be provided with the same network definition. For example, the exact same definition above can be deployed on three different engine instances, bound to ports 8080, 8082 and 8083 correspondently. Each instance will have one instance of SffNetworkFacet deployed with same fid-cluster. Each instance will figure out its own name/position in the network topology based on host, port and fid
- No inter-group communication: There is no inter-group communications yet, only along relationship links
- No detection of Virtual Peer: It is not yet smart enough to figure out a virtual peer deployed on the same engine so if you configure two related peers and deploy both on the same box, it will try to open a WS to itself instead of using internal communications
- No detecton of Duplex Links: It is not yet smart enough to figure out duplex links so each peer will open client WS to its target even if server WS is already open.
- Peer relationships are supported:
- AdvertizeTo sends data change notifications to the target peer. This is useful while working with a shared DB. This way subscribers will get notified about DB change even if they are connected to a different peer
- ReplicateTo sends data change requests to the target peer. This effectively replicates changes made to the source DB on the target. Only visible (by target) models/attributes will be updated so facet security is enforced. Multiple sources are allowed as well as local modifications on the target (but local modifications will currently NOT be propagated back to source). In case of multiple source-originated modifications, only the latest one will be applied. Timestamps and versions are used for collision disambiguation. In other words, version numbers work like Lamport clocks across the network. Local modifications follows the usual rules
- In other words, this cluster works like a tree structure where children can advertise/replicate local changes to the parent. Although possible and legal, it is NOT recommended to have the same instances on different sibling children to avoid any problems with consistency at least until we test it some more. If you need to move instance from one child to another then you need to explicitly delete instance on the first child (which should propagate to parent) and then re-create instance on another child (which is also propagated). This will allow versions on the parent to start from 1 again and should not result in any problems with further updates as versions will remain synchronized between child and parent.
Deploy, Manage and Monitor Cluster
In this section we discuss how to deploy, manage and monitor cluster. A-Stack support to deploy, manage and monitor cluster can described using following high level picture
High Level Architecture of Cluster Management
Managing Multiple Clusters
A-Stack offers following components to help deploy, manage and monitor array of clusters
| Component | Description |
|---|---|
| Configurator Daemon | A-Stack Runtime with configurator models to help signal cluster management on a given Cluster host |
| TQLConsole - ThingSpace Configurator | User Interface based deployment of a remote cluster |
| TQL Command Line Interface (Cluster Option) | Command line interface to create, start, stop, list a remote cluster |
| TQL Command Line Interface (MonitorDashboard Option) | Command line interface to provision alarms, notification options |
| Cluster Monitoring Dashboard | Read-onlty view of the cluster, alarms, and alerts |
Atomiton IT Infrastructure and Cluster Moniotring Dashboard
Cluster Monitoring Dashboard is utilitzed within Atomiton IT infrastrcuture as well. Below the current Cluster Configuration of Atomiton IT infrastructure.
