Riva Synchronization Platform: Overview and Scalability

Applies to Riva 2.4.42 or higher.

Contents:

• Overview of the Riva Synchronization Platform
  • Single-server configuration
  • Multiple-server configuration
• Services
  • Sync Service Node
  • Global Sync Configuration Service
  • User Gatherer
  • Global Calendar Management
  • Global Sync Destination Registry
  • List Service

Overview of the Riva Synchronization Platform

The Riva Synchronization Platform can scale from a single-server to a multiple-server configuration.

Single-server configuration:

The Riva Synchronization Platform, in its simplest deployment, consists of one Riva On-Premise instance on one virtual or physical host system. That server handles the entire synchronization process.

A single Riva instance can handle the synchronization of several thousand mailboxes. For deployments looking to ensure the configuration is fault-resilient with no single points of failure or if there is a need to scale the deployment in order to synchronize more than 10,000 mailboxes, a multi-deployment configuration is available and recommended.

Multiple-server configuration:

Some use cases require a multiple-server configuration:

• scaling beyond the capabilities of a single server,
• syncing with high availability, and/or
• having faster disaster recovery times.

Meeting those targets requires deploying additional services into a cluster of multiple virtual or physical host systems.

• The Riva instances assigned the synchronization role in an enterprise-level Riva Synchronization Platform are called synchronization nodes.
• The services that are shared among multiple synchronization nodes are called Riva Shared Services (RSS's).
• These shared services can be configured in high-availability configurations that allow fault-tolerance.
• Every RSS that is configured is critical to processing. The service levels of these shared services can directly impact synchronization performance, reliability, and availability. Each of these services should be classified as critical and should be deployed in a highly available configuration.

Services of the Riva Synchronization Platform

Services:

• Sync Service Nodes
• Global Sync Configuration Service (GSC)
• User Gatherer
• Global Calendar Management (GCM)
• Global Sync Destination Registry (GDR; also known as the Global Destination Entity Registry)
• List Service

Sync Service Node

This is a primary service that is responsible for the synchronization of data. This service is responsible for

• determining changes between the connection targets,
• transforming data between connection end-points,
• transferring data, and
• recording the transactional details about the transfer (transactions metadata).

Global Sync Configuration Service (GSC)

This service provides the command and control center for a multi-node deployment of Riva. This service is responsible for maintaining load distribution.

• When a user is added to the system, the GSC uses an algorithm to determine which sync service node the new user should be assigned to.
• After a user has been assigned to a node, the user’s assignment to the node is “sticky”. This means that if a user is removed from the policy and then re-added, the user remains assigned to the same node.
• Factors that can affect to which sync service node a user is assigned include the sync policy and the number of users already allocated to a sync service node.
• The events that change a user’s node assignment are called realignments. A realignment occurs when a sync node service is added to a multi-node configuration or removed from it.
• One of the primary purposes of the sticky behaviour is to allow the sync load to be distributed for deployments that are not replicating the transaction storage between the nodes. This also minimizes the opportunity for any replication faults or conflicts by ensuring that each set of user transactions is never being written to by multiple nodes.

Note: This is a passive service that does not need access to the synchronization connections or policies used by the sync service nodes. No "synchronization data" is sent to this service.

Configuration: Configure the Global Sync Configuration settings in the Configure Remote Management window.

Run-time management: Use remote management in the Riva CRM Service Monitor.

User Gatherer

This service is responsible for reading the configuration to determine which users or mailboxes should be synchronized. Specifically, the User Gatherer collects users from sync policies (static lists), from the CRM (CRM Gather) or mail groups (Mail Gather). After the users are detected as being active, they are registered with the GSC.

Configuration: In the Configure Remote Management window, configure a Client Global Sync Configuration node to be a Provider.

Global Calendar Management (GCM)

Used to share calendar entry registrations between many users.

• The GCM is a lookup service that manages the mapping between each target system. This service is critical to ensuring that a single entry is created in the target system, which can then be shared among many users whose attendance must be maintained.
• The GCM manages the links between appointment recurrences and each distributed instance.

Note: This is a passive service that does not need any synchronization connections or policies.

This service has also been known as Calendar Management, Global Management, Global ID, or Global Calendar.

Configuration: Configure the Calendar GlobalID Manager settings in the Configure Remote Management window.

Modify Start Dates: Configure the date range for GCM.

Global Sync Destination Registry (GDR)

This service is also known as the Global Destination Entity Registry.

A significant risk to the system's integrity is possible if an individual mailbox started to synchronize

• on two nodes simultaneously or
• on a node that does not have a copy of the user’s transaction data.

The GDR is used as a fail-safe component with the sole objective of preventing a mailbox from starting to synchronize on another node in the cluster because of misconfiguration or system failure.

Example scenario: if the GSC was lost or somehow corrupted, the GDR would prevent a user from synchronizing on a different node that may not have copies of the historical transactions.

Configuration: Configure the Global Sync Destination Registry settings in the Configure Remote Management window.

Tip: When the GDR has been activated, the detection of a misplaced transaction metadata folder can be used to prevent the sync. For more information, see Detect when transactions metadata has been misplaced.

List Service

Available in Riva 2.4.44 or higher, under every Riva Shared Service (RSS) node.

The List Service lists all of the instances of RSS's that are present on a RSS node, including the List Service itself.

Under the List Service folder, the Global Sync Configuration, Global Sync Destination Registry, or Global Calendar Management (GCM) can be selected to put it into maintenance mode, create a snapshot of its database, and put it back into production mode (by stopping maintenance mode). While in maintenance mode, the GCM database can also be cleaned up.

Configuration: The List Service requires no configuration.