This repository was archived by the owner on Feb 13, 2025. It is now read-only.
Raft-based cluster support #2472
Closed
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Cluster would only have one ‘leader’ at a time, all other nodes are followers (so this is an implementation of a model with with 1 master and multiple standby nodes). ‘Master’ node executes the checks and sends notifications, ‘follower’ nodes don’t do neither (they run with ‘no-checks’ and ‘quiet-mode’ options enabled). This also adds a new (optional) dependency raftdb to store state and perform leader election.
For now, we are looking to global variable that was initialized once we've started. If we want to have flexibility to restart scheduler (config api reload/clustering etc.) we should have it as time of scheduler's start
- check raft state within scheduler to prevent lose events - sync rules configuration between nodes within cluster - add snapshots/logs management within raft cluster
- redis latency/count/errors - notifications latency/count/errors - incident state change
This was referenced Apr 23, 2020
|
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
1 participant
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
Cluster implementation for bosun.
The goal of this change is to add high availability for bosun service. Currently, it’s possible to have only one active bosun node running checks and sending an alert. If this node goes down or becomes unavailable there’s a high chance that checks won’t run for some time, alerts are not fired, incidents aren’t created and notifications — delivered. It then takes some time for a sysadmin to switch all the checks to another node. So, in the end, we’re minimizing human intervention needed in failure scenarios and reducing possible downtime of service.
Changes overview
We've implemented the cluster for bosun.
Cluster would only have one ‘leader’ at a time, all other nodes are followers (so this is an implementation of a model with 1 master and multiple standby nodes).
‘Leader’ node executes the checks and sends notifications, ‘Follower’ nodes can response to web UI queries and API queries. 'Follower' node can send notifications but only generated from API/UI queries.
As replacement for #2345 and #2441
Fixes #2443
Type of change
From the following, please check the options that are relevant.
How has this been tested?
Checklist: