Applies to: BLAZE

Summary

BLAZE supports multi-server clustering, which allows up to 50 servers to operate as a single unified system. This article explains how the cluster architecture works.

Cluster Architecture

BLAZE clustering allows multiple servers to operate as a single unified system, providing redundancy and load distribution for connected cameras and devices.

A BLAZE cluster uses a Master/Standby architecture:

• Master Server — The designated coordinator of the cluster. Manages failover decisions and maintains system-wide configuration.
   
• Standby Servers — Servers that join the cluster and share device management responsibilities. Each standby server maintains a local copy of the cluster database.

When the current Master becomes unavailable, the system automatically promotes another standby server as the new Master. The candidate selected is the standby server with the oldest registration time in the cluster.

Server Requirements

• All servers in the cluster must be on the same Class C subnet (the first three octets of the IP address must match, e.g. 192.168.1.x).
   
• All servers must be able to communicate with each other over the network.
   
• All servers must be running the same version.

The system compares the first three octets of each server's IP address before allowing a new server to join the cluster.

How Servers Stay Connected

Each server sends a heartbeat signal every second to all other servers in the cluster. This heartbeat carries the server's current status.

Other servers monitor these heartbeats to determine whether a peer is healthy. If no heartbeat is received from a server for 10 seconds, and the connection is confirmed lost. The cluster treats that server as failed and initiates failover.

A 10-second startup grace period is applied when a server first connects. The timeout clock does not start until the first heartbeat is received, which prevents false failover alerts during initialization.

Servers automatically reconnect and resume normal operation once the connection is restored. No manual intervention is required for reconnection.

Server Status

Data Synchronization

When a configuration change is made on any server in the cluster (for example, adding a camera or updating a channel setting), that change is automatically propagated to all other cluster members.

• If a sync request to a peer fails (for example, due to a temporary network interruption), the system automatically retries after 1 second.
   
• If a server goes offline, any pending sync changes for that server are discarded. When the server comes back online and reconnects, it will receive a full database sync to catch up.
   
• If a server is running a different version, configuration sync to that server is automatically paused until the version mismatch is resolved.

Version Compatibility

All servers in a cluster must run the same version. The major, minor, and patch version numbers must match.

If the system detects a version mismatch, it moves the mismatched server to Isolated status and pauses configuration synchronization. The server automatically rejoins normal operation after all servers run the same version.

Do NOT add servers running different versions to a cluster. Update all servers to the same version during upgrade procedures.

Known Considerations

• Same Class C subnet is required 
  
  The first three octets of each server's IP address must match (e.g. 192.168.1.x). Clustering across different subnets is not supported.
   
• Sync delay under heavy load 
  
  Configuration changes are synced one at a time per server. A large number of changes in quick succession may take a moment to propagate to all cluster members.
   
• Isolated server falls out of date 
  
  A server in Isolated status will not receive configuration updates. Resolve version mismatches promptly.
   
• No manual Master selection 
  
  The Master server is promoted automatically based on registration order. There is no option to manually designate a Master server.