DataReel Cluster Manager
High-availability failover for Linux services, built on the DataReel C++ toolkit. Current release: DRCM 1.42.
Overview
Features
How It Works
Security Model
UDP and TCP Transports
Version 1.42
Supported Platforms
Get the Code
Build and Install
Setup and Migration Tools
Administrator Guide
License
Overview
What is the DataReel Cluster Manager?
The DataReel Cluster Manager (DRCM) is an open-source, multi-threaded high-availability (HA) cluster manager for Linux. It keeps services, floating IP addresses, filesystems, applications and cron jobs running by monitoring every node in a cluster and automatically failing resources over to a healthy node when a node stops responding. DRCM is written in C++ on top of the DataReel toolkit and uses its threading, socket, string, list, configuration and logging classes directly.
DRCM runs as a lightweight daemon on each node. Nodes exchange authenticated keep-alive messages on a schedule you control. When a node misses its keep-alive window, a surviving node takes over the failed node's resources by running small, auditable resource scripts — so what happens during a failover is transparent and easy to customize for your environment.
Why use DRCM?
DRCM is simple to reason about, has very few runtime dependencies, and gives the administrator full control over what a failover actually does. It is well suited to two-node active/standby pairs, witness-backed quorum clusters, and now — with the TCP + TLS transport — nodes that fail over across the public internet rather than only within one subnet.
Features
Cluster Management
- Multi-threaded HA daemon
- Active/standby failover
- Two-node clusters
- Witness-quorum clusters
- Per-node keep-alive monitoring
- Configurable dead-node timeout
- Primary/backup resource maps
- Live cluster status queries
- Per-node statistics
Managed Resources
- Floating IP addresses
- System services (systemd)
- Mounted filesystems (NFS)
- User applications
- Crontab installation
- Pluggable resource scripts
- AWS Elastic IP failover
- AWS route-table VIP failover
Security
- HMAC-SHA256 message authentication
- 2048-byte cluster auth key
- Sequence + nonce anti-replay
- Optional timestamp window
- TLS 1.2+ over TCP
- Mutual certificate auth
- Optional certificate pinning
- Hardened compiler flags
Operations
- Single config file (cm.cfg)
- systemd unit files
- Rotating log files
- Config migration script
- tkinter setup GUI
- RPM packaging
- Administrator guide
- Example two-node config
How It Works
Each node runs the drcm_server daemon, configured from a single cm.cfg file that describes the cluster, every node, and the resources each node owns. On a schedule, each node sends an authenticated keep-alive message to the other nodes it monitors.
- Healthy state. Keep-alives arrive on time and every node holds its assigned resources.
- Node failure. When a node misses
dead_node_countconsecutive keep-alive windows, a surviving node marks it dead and begins takeover. - Takeover. The surviving node runs the resource scripts for the dead node's floating IPs, services, filesystems, applications and crontabs, assuming its backup responsibilities.
- Recovery. When the failed node returns and re-establishes keep-alives, resources can be returned according to your configuration.
Resource actions are plain scripts in etc/resources/ (for example ipv4addr.sh, service.sh, nfs.sh, and the new aws_ipv4addr.sh), so a failover does exactly what you can read in those scripts — nothing hidden.
Security Model
DRCM treats the cluster control channel as a security boundary: a node must never be able to be tricked into failing resources over, and a network attacker must not be able to forge, replay or tamper with cluster messages. The current release hardens the protocol end to end.
- Authenticated messages. Every cluster frame carries an HMAC-SHA256 tag keyed with a 2048-byte per-cluster authentication key. A node silently drops any frame whose tag does not verify, so only holders of the cluster key can speak on the control channel.
- Anti-replay. Each frame includes a per-sender sequence number and a random 16-bit-safe nonce, checked against a recent-nonce cache, so a captured message cannot be replayed to re-trigger a failover. An optional timestamp window adds a time-based check for clusters with synchronized clocks.
- TLS over the internet. When nodes fail over across untrusted networks, the TCP transport wraps the control channel in TLS 1.2 or higher with mutual certificate authentication against a cluster CA, with optional certificate-fingerprint pinning for defense in depth.
- Hardened builds. The daemon is compiled with stack protection,
_FORTIFY_SOURCE, a position-independent executable and full RELRO, and has been exercised under AddressSanitizer and UndefinedBehaviorSanitizer with a dedicated attack-simulation test suite.
UDP and TCP Transports
DRCM supports two transports, selected with cluster_transport in cm.cfg:
- UDP (default) — lightweight datagrams for nodes on the same subnet. Authenticated with HMAC-SHA256 and protected by sequence + nonce anti-replay.
- TCP + TLS — for failover over the internet or any untrusted network. Adds TLS 1.2+ with mutual cluster-CA certificate authentication on top of the same authenticated frames.
Both the default self-signed cluster CA and externally-issued certificates (for example Let's Encrypt via acme.sh) are supported for the TLS transport — only the certificate, key and CA file paths matter to the daemon.
# cm.cfg -- select the TCP + TLS transport cluster_transport = tcp tls_ca_file = /etc/drcm/tls/ca.pem tls_cert_file = /etc/drcm/tls/node.pem tls_key_file = /etc/drcm/tls/node-key.pem tls_min_version = 1.2 # Witness quorum guards a two-node split brain quorum_required = 1 witness_endpoint = 10.0.0.9
Version 1.42
DRCM 1.42, 10/25/2026, tagged 1.42 in the repository, is a security release. Every cluster message is an authenticated v2 frame with anti-replay protection, and the release adds the TCP + TLS transport, witness quorum, the AWS floating IP script and the setup tools. 1.42 nodes do not talk to 1.41 or older nodes, so upgrade all cluster nodes together. See CHANGELOG.md in the source release for every change.
Supported Platforms
The current DRCM release is developed and tested on Red Hat Enterprise Linux 9 and 10. It builds on any modern Linux distribution with the GNU C++ compiler and OpenSSL.
- Supported: RHEL 10 and RHEL 9 (and compatible rebuilds such as AlmaLinux and Rocky Linux).
- Best-effort / legacy: RHEL 8 builds but is considered legacy and is not the primary test target.
- No longer supported: RHEL 6 and RHEL 7 are end-of-life and are no longer supported by this release.
Get the Code
The DataReel Cluster Manager has its own source releases on the DataReel website:
https://datareel.com/downloads/drcm/
> mkdir -pv ~/git > cd ~/git > wget https://datareel.com/downloads/drcm/ha-cluster-manager-<version>.tar.gz > tar xzf ha-cluster-manager-<version>.tar.gz > mv ha-cluster-manager-<version> ha-cluster-manager > cd ha-cluster-manager
DRCM links against the DataReel library. Extract both source releases side by side:
> cd ~/git > wget https://datareel.com/downloads/datareel/datareel-<version>.tar.gz > tar xzf datareel-<version>.tar.gz > mv datareel-<version> datareel > wget https://datareel.com/downloads/drcm/ha-cluster-manager-<version>.tar.gz > tar xzf ha-cluster-manager-<version>.tar.gz > mv ha-cluster-manager-<version> ha-cluster-manager
Build and Install
Build the DataReel library first (see the Linux Builds section of the Readme), then build the cluster daemon:
> cd ~/git/ha-cluster-manager > source env/gnu_env.sh > cd drcm_server > make -f makedrcm.mak
The daemon links OpenSSL (-lssl -lcrypto) for the HMAC authentication and the TLS transport, and is built with hardening flags enabled. systemd unit files are provided under systemd_init/, and an RPM spec under rpm_builder/.
Setup and Migration Tools
Two helper tools make it easy to stand up a new cluster or move an existing one to the current configuration format:
tools/migrate_cfg.py— an additive, idempotent migration script that upgrades a pre-existingcm.cfgto the current format. It leaves the cluster on UDP by default and can optionally scaffold the TCP + TLS and witness-quorum settings.tools/drcm_gui.py— a small tkinter GUI with a New cluster tab that generates a ready-to-editcm.cfg(UDP or TCP + TLS, with anti-replay and quorum options) and a Migrate tab that reuses the migration script. It runs headless with --selftest to print a sample config without a display.
# Migrate an existing config to the current format (prints to stdout)
> python3 tools/migrate_cfg.py /etc/drcm/cm.cfg
# Switch it to the TCP + TLS transport with a witness
> python3 tools/migrate_cfg.py /etc/drcm/cm.cfg \
--tcp --quorum --witness 10.0.0.9 -o cm.new.cfg
Administrator Guide
A full administrator guide ships with the source release under docs/. It covers the architecture, installation, the complete configuration reference, the security model, TCP + TLS and witness-quorum setup, floating-IP failover (including AWS Elastic IP and route-table modes), monitoring, a two-node walkthrough, and troubleshooting.
DRCM 1.42 Administrator Guide (plain text), and the online documentation. The same guide ships in the source release as docs/drcm.html and docs/drcm.txt.
License
The DataReel Cluster Manager is open source, copyrighted by DataReel Software Development, Copyright © 2001-2026. It is distributed under the GNU General Public License version 3 (GPL). The DataReel library it builds on is distributed under the LGPL. See the COPYING file in the source release for the full text.
DataReel Copyright © 2001-2026 DataReel Software Development