drbd-reactor is a daemon consisting of a core that does DRBD events processing and plugins that can react on
changes in a DRBD resource.
| Plugin | Purpose |
|---|---|
| debugger | Demo that prints state changes |
| promoter | Simple HA for resources |
| umh | User mode helper |
| prometheus | Prometheus endpoint |
| agentx | AgentX subagent for SNMP monitoring |
- debugger
- promoter
- umh (user defined filters)
- umh (replacement for kernel called helpers: Under active development)
- prometheus
This daemon is configured via a configuration file. The only command line option allowed is the path to the
configuration. The default location for the config is /etc/drbd-reactor.toml. The repository contains an example
drbd-reactor.toml. This file should act as the entry point only to specify a snippets
directory where one places one snippet per plugin instance. Users should use drbd-reactorctl to manage these
snippets.
In very dynamic environments it might be favorable to automatically reload the daemon whenever a configuration
snippet is added or removed. This can be done by using the drbd-reactor-reload systemd path unit that is shipped
in the example directory:
cp example/drbd-reactor-reload.{path,service} /etc/systemd/system/
systemctl enable --now drbd-reactor-reload.pathThis is a Rust application. If you have a Rust toolchain and cargo installed (via distribution packages or
rustup) you can build it via:
cargo buildThe core consists of 2 threads. The first one is responsible for actual drbdsetup events2 processing. It
sends update event structs on a channel to the main thread.
The main thread keeps track of the overall DRBD resource state by applying these updates to an internal map of
resource structs. Think of these as the output of drbdsetup status --json. The second purpose is to generate
PluginUpdate enums if important properties of a resource changed. For example one variant of the
PluginUpdate is ResourceRole, that is generated if the role of a resource changed. These variants follow
the same structure: They contain the event type, information that identifies the actual DRBD object (resource
name, peer ID, volume ID,...) and the old and new states. These old/new states contain the rest of
the relevant information within this event (e.g., the may_promote, and promotion_score). Think of old
and new structs as easy to consume diffs. A PluginUpdate also contains the current, complete state of the
resource.
Plugins are maintained in this repository. Every plugin is started as its own thread by the core.
Communication is done via channels where plugins only consume information.
The core expose a PluginUpdate channel, the plugin decides if it wants to use the diffs from old and
new, and/or the complete current state from resource.
Contributions are obviously always welcome! Please talk to us first before you start working on a new plugin. Please check the state of plugins at the beginning of the document, and don't work on plugins that are currently under development by somebody else.
We have to be a bit careful introducing new dependencies as we want to provide drbd-reactor via a
PPA. So please use only dependencies that
are packaged as librust- package in Ubuntu Focal. We might relax that, but that would need to be a very very
convincing argument. Again, talk to us early.
Currently plugins have to filter their PluginUpdate stream by themselves. This keeps the core simple, but
allowing some kind of filtered subscription could make sense. If we don't do that, and keep the "all plugins
get all events" semantic, we could switch to a broadcast channel, there are some crates out there.