(Source)
Introduction
Clustd is an open source cluster management provider. The goal is to provide automated failover systems for apps, whether the system is down for maintenance or an unexpected event. When the system is ready, it will deployed in production on @steemdunk to minimize any form of downtime for the bot and web services.
Disclaimer: This is not intended to be used in conjunction with a database, otherwise data will be out of sync. See your database manual for setting up clusters that will preserve the integrity of your database across multiple machines.
What does a cluster look like?
Each machine runs a clustd daemon. The daemon provides automatic consensus on deciding a new master if the master goes down. Drivers control what actions to perform when this happens.
Drivers
A driver is what controls the server when a specific machine becomes a master or is no longer a master. It does not provide its own server like a cluster daemon and connects directly to the cluster machine directly. It is expected to run alongside the cluster daemon on the same machine. Multiple drivers can connect to the cluster daemon to perform multiple actions specific to that driver.
There is now an API for driver implementations. clustd has been refactored and now has its own clustd-lib library.
A sample driver implementation
export class TestDriver extends DriverMachine {
constructor(dc: DriverClient, host: string) {
super(dc, host);
}
trigger(isMaster: boolean): void {
console.log('Master status:', isMaster);
}
}
Connecting to the cluster
(async () => {
const dc: DriverClient = {
secret: 'cluster communication secret',
id: 'driver-test-' + crypto.randomBytes(4).readUInt32BE(0),
}
const dm = new BashDriver(dc, 'ws://127.0.0.1:3001');
await dm.connect();
})();
Drivers will automatically reconnect to the cluster daemon if the daemon was taken offline. No further action is required in the implementation. The ID should always be unique in case multiple drivers of the same implementation is running. In the future this may done automatically or with a different approach and strategy.
This API is a work in progress but the initial framework is now here. This is a leap forward towards creating the bash driver.
Roadmap and ideas
The next part will have a functional bash driver. There could be additional drivers written to provide notifications, whether email or SMS. Providing a sort of monitoring framework of the cluster status and what happened.