Platform Cluster

Netgrif Platform supports a scalable solution suitable for small to large deployments. Since the Platform consists of several components, the entire unit can be called cluster (platform cluster). The components within the cluster have defined roles, functionalities and relations to one another. However, containers and Platform components are not the only elements that contribute to the Platform runtime, so it is important to define a common naming scheme and concepts. This article provides an explanation of basic terms and axioms of the Platform cluster.

The diagram below shows the architecture of the Netgrif Platform cluster and all its components. Databases are not considered part of the cluster, they are treated as external services. If you are deploying the platform on your own infrastructure, ensure that the databases are accessible over the network.

Concepts

• Cluster - An installation of the Netgrif Platform. One licence can be applied to only one cluster.

• Node - A component of the Netgrif Platform that can be installed within a cluster. The cluster is an amalgamation of all Nodes. There are several types of Nodes:

  • Admin - The administration web application for managing processes, users, license and other entities across the cluster. Exactly one instance is installed in the cluster. Required cluster component.
  • Search - Provides cluster-wide search across all deployed processes and their data. Each Search node instance is tied to a specific zone.
  • Gateway - A networking cluster component that routes incoming requests to the correct cluster component. Requests are sent to an Engine worker if a process context can be resolved; otherwise, they are forwarded to the Search node. Each gateway instance is tied to a zone.
  • Application Engine Worker - The Engine instance where processes are executed. It is the Application Engine Core enriched with additional modules. At least one worker is required in the cluster. One worker is designated to handle system and common processes and is usually the first worker started with node type ENGINE_ROOT.

• Zone - A set of nodes grouped according to infrastructure constraints (e.g., security or availability requirements). Zones do not affect process execution. There can be 1 to N Zones in a cluster. When starting a fresh cluster, at least one zone is created.

• Application - A set of 1 to N logically tightly coupled processes, together with frontend configuration and optional static assets (e.g., CSV files, email templates, pdf templates, etc.) used to express one functionality of the system. (e.g. mortgages in a banking system)

• Process - A Petriflow process. It is a base building block of an Application and, by extension, the entire system.

• Role - A process role is an aggregation of permissions defined for a process. It represents a mapping between a user (or group of users) and the permissions of that process.

• Workspace - A set of applications deployed in the cluster together with their runtime data. Processes within a Workspace can see each other and communicate through inter-process communication. One to N Workspaces can exist in a cluster. When the cluster starts, at leat a default Workspace is created.

• User - An actor in the system who can execute deployed processes according to assigned permissions.

• Group - A set of users. In some cases, user and group can be used interchangeably.

• Realm - A set of users and groups authenticated through a common authentication provider. A realm can have multiple authentication providers defined at the same time.

Cluster Axioms

To define relationships between cluster components, we introduce the following axioms:

1. Exactly one Admin node exists in a cluster.
2. A Process is executed on exactly one Worker.
3. A Process belongs to exactly one Application.
4. A Process can use or define permissions for 0-N Roles. If no Roles are defined, the default Role is applied.
5. An Application belongs to exactly one Workspace.
6. An Application is run on at least one Worker.
7. A Role belongs to exactly one Workspace.
8. A Worker belongs to exactly one Zone.
9. There is a Gateway for every Zone.
10. A Gateway knows only about Workers in the same Zone.
11. There is a Search Node for every Zone.
12. A Search Node knows only about data from Workers in the same Zone.
13. There is exactly one named Worker that belongs to every Zone. This Worker has the node type ENGINE_ROOT.
14. A User is defined in exactly one Realm.
15. A Group is defined in exactly one Realm.
16. A User belongs to 0-N Groups.
17. Realm entities can access at least one Workspace.
18. A User can be assigned to 1-N Roles. Every User has at least one default role.
19. A Group can be assigned to 0-N Roles.