Skip to content

Replication

This document provides technical documentation for the Tenant Replication engine within the 12Port Privileged Access Management (PAM) solution. It outlines deployment topologies, data models, transport mechanisms, and configuration schemas required for system administrators to deploy and maintain multi-node synchronization.

For detailed information on the deployment scenarios supported by this architecture (including Disaster Recovery, Isolated Locations, Data Caching, and Session Relays), please refer to the Replication FAQ.

Functional Introduction

The 12Port PAM architecture supports stateful data replication between distributed application nodes. The core replication subsystem utilizes an asynchronous journaling engine that intercepts and records all Data Manipulation Language (DML) equivalent actions, specifically creates, updates, and deletes (CUD), executed against configuration parameters, management objects, and system logs.

Data synchronization across designated peer nodes is executed via stateless HTTP application layer transactions targeting the native application REST API.

Replication Architecture

The 12Port PAM architecture features a flexible, tenant-isolated data replication subsystem designed to maintain state consistency across distributed environments.

  • Transport & Agnosticism: Operating at the object-model layer via secure HTTPS REST APIs, the engine is entirely database-agnostic, allowing peer nodes to run completely mismatched backend database systems.
  • Data Classification: The engine categorizes synchronization traffic into Active Data (operational configurations and management objects) and Passive Data (system logs and reports).
  • Network Traversal: Traffic is orchestrated using complementary Push or Pull routing orientations, allowing administrators to easily bypass strict firewall or unidirectional network ACL constraints.
  • Performance Tuning: Operational impact is managed via targeted execution strategies. These range from near real-time, low-latency Active pushes to asynchronous, interval-based Scheduled or Background batch operations that prevent user interface lag.

For a deeper look into deployment topologies, performance tradeoffs, and advanced synchronization scenarios, please refer to our Replication FAQ.

Topology Filtering (Peers Network)

In complex topologies (such as a multi-spoke star network), a single hub node may ingest journal data originating from many different regional nodes. To prevent unintended loop replication or data leakage, the engine features metadata filtering. Administrators can restrict Push and Pull tasks to only process data that originated from specific source node IDs.

For example, a central Main node can be configured to push global policy configurations down to a branch peer node while automatically omitting data it ingested from other branch peers.

Authentication and Access Control

Because the replication transport layer utilizes standard HTTPS REST endpoints, node-to-node authentication requires a cryptographic API Token. Mutual authorization is achieved when a node explicitly defines an external system as an authorized peer within its internal replication configuration table.

Security Authorization Prerequisite: The user identity associated to the API Token must be explicitly granted the Site Role: Service permission. Lacking this assignment, incoming replication payloads will be dropped during API routing.

Configuration Schema

Replication profiles are established by building explicit peer-to-peer mapping configurations. For complex distributed meshes, a single node will maintain an array of multiple configuration blocks.

Parameter Reference

Every replication profile entry requires the following explicit parameters:

Parameter Field Data Type / Format Operational Definition
Name Alphanumeric String Unique administrative identifier for the replication mapping entry.
Push Nodes Comma-Separated String Filter array containing the source hostname(s) originating the data to be pushed. Matches the Host value visible on the system About interface (either local or previously ingested via upstream replication).
Push Tenant Alphanumeric String The specific source tenant context originating the data payload intended for outbound push.
Push Strategy Selectable Values Active | Background | Scheduled | Passive | None
Pull Nodes Comma-Separated String Filter array containing the hostname(s) originating the data to be pulled. Typically matches the remote peer's Host value visible on its About interface.
Pull Tenant Alphanumeric String The target tenant context on the remote peer from which data should be pulled.
Pull Strategy Selectable Values Background | None
URL Absolute URI String The fully qualified target endpoint address matching the syntax rule:
https://<host>:<port>/ztna/tenantName/siteName
Token Cryptographic String The functional REST API bearer token generated on the target node to authenticate incoming replication requests.

Note: The identity tied to this token must have the Site Role: Service assigned to it.
Enabled Boolean (True/False) Master toggle to activate or deactivate the individual replication worker threads.

Push and Pull Modes

To accommodate complex firewall and routing constraints, synchronization can be initiated from either side of the network boundary using two directional vectors:

  • Push Mode: The local node initiates an outbound connection to the remote peer API, transmitting serialized journal deltas to create, update, or erase objects on the target.
  • Pull Mode: The local node initiates an outbound connection to the remote peer API to request outstanding journal packages, applying those delta modifications locally.

Directional Rule: Directional modes are purely network-routing mechanisms determined by which node possesses outbound ACL permissions to establish a TCP handshake. Directional orientation does not dictate data lineage or master-slave hierarchy.

Push Replication Strategies

  • Active: Triggers immediate, low-latency API calls to the remote peer upon any local change to Active Data. If the target peer is unreachable, the engine immediately demotes the transmission execution to the Background strategy.

    Performance Note: This strategy runs synchronously with the administrative interface. It requires an unconstrained, high-speed network backbone to prevent user interface lag during commit phases.

  • Background: Executes an asynchronous, non-blocking background thread triggered immediately by data mutations. This isolates user interface performance from network latency. If connection timeouts occur consecutively, the execution sequence automatically demotes to the Scheduled strategy.
  • Scheduled: Utilizes a cron-like background task runner to process queued deltas at defined intervals. This is the only Push strategy that processes both Active and Passive data structures.
  • Passive: Suspension of active outbound transmission. The local node buffers all journal modifications internally, waiting for a remote peer node to retrieve them via a configured Pull operation.
  • None: Explicitly disables all outbound Push replication threads for the configuration instance.

Pull Replication Strategies

  • Background: Invokes an asynchronous background task runner at set periodic intervals to poll the remote peer API for new journal updates.
  • None: Explicitly disables all inbound Pull replication polling threads for the configuration instance.

Authorization Alignment Matrix

To ensure functional data synchronization and API authorization, administrators must deploy complementary configuration pairings across peers. The following combination examples represent valid operational states:

Local Node Configuration Target Peer Node Configuration
Pull Strategy Enabled (Background) Push Strategy set to Passive
Push Strategy set to Active Push & Pull Strategies both set to None

Example Configurations

The following examples demonstrate how to construct mapping profiles to achieve common directional and scheduling requirements between two nodes: pam-node-a and pam-node-b.

One-Way Active Push (Unidirectional)

In this scenario, pam-node-a immediately pushes its local changes to pam-node-b. No data originating on Node B is ever replicated back to Node A.

Configuration on pam-node-a:
This entry forces Node A to actively connect outwards to Node B whenever local data changes.

  • Name: One-Way Active (Push-to-Node-B)
  • Push Nodes: pam-node-a
  • Push Tenant: QuickStart
  • Push Strategy: Active
  • Pull Nodes: pam-node-b
  • Push Tenant: QuickStart

  • Pull Strategy: None

  • URL: https://pam-node-b:6443/ztna/QuickStart/root

  • Token: [API_Token_Generated_On_Node_B]

  • Enabled: True

One-Way Active Push Example from Node A Configuration

Configuration on pam-node-b:
Per the Authorization Alignment Matrix, Node B requires no corresponding active replication entry to receive these push transactions. Its default API endpoints will handle the incoming stream. Both strategies remain disabled (None).

  • Name: One-Way Active (Receiver-from-Node-A)
  • Push Nodes: pam-node-b
  • Push Tenant: QuickStart
  • Push Strategy: None
  • Pull Nodes: pam-node-a
  • Push Tenant: QuickStart

  • Pull Strategy: None

  • URL: https://pam-node-a:6443/ztna/QuickStart/root

  • Token: [API_Token_Generated_On_Node_A]

  • Enabled: True

One-Way Active Push Example from Node B Configuration

Two-Way Active Push (Bidirectional / Dual-Active)

This configuration expands on Example 1. If an asset or configuration is created, updated, or deleted on either pam-node-a or pam-node-b, the change is immediately mirrored to the peer node.

Configuration on pam-node-a:
Node A retains its active outbound configuration pushing to Node B.

  • Name: Two-Way Active (Push-to-Node-B)
  • Push Nodes: pam-node-a
  • Push Tenant: QuickStart
  • Push Strategy: Active
  • Pull Nodes: pam-node-b
  • Push Tenant: QuickStart

  • Pull Strategy: None

  • URL: https://pam-node-b:6443/ztna/QuickStart/root

  • Token: [API_Token_Generated_On_Node_B]

  • Enabled: True

Configuration on pam-node-b:
Node B matches Node A's behavior by establishing an active outbound push worker pointing back to Node A. To prevent loop replication, Push Nodes explicitly isolates local pam-node-b modifications.

  • Name: Two-Way Active (Push-to-Node-A)
  • Push Nodes: pam-node-b
  • Push Tenant: QuickStart
  • Push Strategy: Active
  • Pull Nodes: pam-node-a
  • Push Tenant: QuickStart

  • Pull Strategy: None

  • URL: https://pam-node-a:6443/ztna/QuickStart/root

  • Token: [API_Token_Generated_On_Node_A]

  • Enabled: True

One-Way Scheduled Push (Unidirectional Batching)

This layout mirrors the functional direction of Example 1 (pam-node-a to pam-node-b), but transitions execution from immediate low-latency replication to a timed, batched interval. This strategy processes both Active Data and Passive Data (such as transactional logs).

Configuration on pam-node-a:

  • Name: Scheduled-Push-to-Node-B
  • Push Nodes: pam-node-a
  • Push Tenant: QuickStart
  • Push Strategy: Scheduled
  • Pull Nodes: pam-node-b
  • Push Tenant: QuickStart

  • Pull Strategy: None

  • URL: https://pam-node-b:6443/ztna/QuickStart/root

  • Token: [API_Token_Generated_On_Node_B]

  • Enabled: True

Configuration on pam-node-b:

  • Name: Scheduled-Receiver-From-Node-A
  • Push Nodes: pam-node-a
  • Push Tenant: QuickStart
  • Push Strategy: None
  • Pull Nodes: pam-node-b
  • Push Tenant: QuickStart

  • Pull Strategy: None

  • URL: https://pam-node-a:6443/ztna/QuickStart/root

  • Token: [API_Token_Generated_On_Node_A]

  • Enabled: True


These structural baselines can be combined or adapted to meet more advanced topology demands, such as multi-spoke hub environments or disaster recovery targets.