Enterprise Architecture

Key Components

Realm Object Server component services can scale independently, allowing for design elasticity between service demands and high availability with failover. In this section, we will summarize these core services and components which are involved in a typical enterprise deployment.

Example Deployment Diagram

Realm Core Services

Realm Core Services is a stateless node application that contains many of the Realm administrative functions, such as the proxy, authentication, and directory service. These services can be deployed independently, or all in the same process by editing the services: array of the ServerStart config. Because Realm Core Services is stateless and independent it can be deployed in many environments including common PaaS solutions. There can only be a single RealmDirectory service running at any time, but all other services can be run in parallel for load balancing purposes.

Realm Sync Workers

Realm Sync Workers is a stateful node application that stores the realms, serves the data to sync clients, and merges changes. These are deployed in clusters of three with a master, backup, and spare - master election is determined by Consul, which also detects failure and triggers failover. The sync worker group is configured with synchronous backup. Each change is written to both the master and the slave sync-worker before the sending an acknowledgement back to the realm-enabled mobile client.

Consul Cluster

Consul Cluster is a cluster of at least three Consul servers that acts as a distributed key-value store for consensus and service discovery in the ROS cluster. It has built-in failure detection which the ROS cluster continually checks. If a Sync Worker failure is detected, the ROS Core Services proxy module shifts the traffic to that cluster's slave, making it the master Sync Worker, and the spare becomes the new slave. In small deployments the Consul process can be run on the same server as the Sync Workers and Core Services, as shown below:

While it is not required, we recommend a fourth Consul agent instance be deployed on the same node as Core Services. That agent relays traffic between Core Services and the Consul cluster, so that Core Services doesn't need to be hard-coded to connect to a specific Consul server, but does not participate in Consul consensus.

In larger deployments with 10 or more ROS nodes, it is recommended to split out the Consul cluster into its own standalone cluster of at least three separate servers.

Public Load Balancer

This is typically a geo-distributed load balancer that is designed to forward any Realm traffic from remote connections to the Realm proxy. It must have a publicly accessible address. It is commonly deployed in a pool using a redundancy protocol like VRRP and must be automated and programmable in case the Realm Core Services proxy module DNS or IP changes or fails over.

Cluster Deployment

The following diagram shows the component pieces of the Realm Object Server deployed across a cluster. This also reiterates which of the components services are stateful vs stateless. Deployment mediums should be considered based on these properties.

Not what you were looking for? Leave Feedback