zarusz / slimcluster Goto Github PK

In case of redeployments into Kubernetes the pod gets a signal to shut down, then new pods are created doubling the cluster size.
In this situation, the pods shutting down should block their voting mechanism to allow the cluster to converge quicker.

The user of the library should have a way to register an implementation of an interface that will get notified whenever the leader or other important cluster state changes.

Currently when a node leaves (the app is shutdown normally) it will multicast this to other members.

An improvement could be done for a shutting down Node to:

• Select N random members
• Send the leave message to them
• Shutdown gracefully

In such case the other nodes would get this gossip information and later disseminate it to other members in the cluster, thus avoiding the need for multicast or reliance on failure detection to detect an unavailable member.

Hi,

I trying to probe how much desire within the .NET community is it for this library to evolve further?

I had a need for distributed coordination within a distributed micro-service at one of m commercial projects I am part of.
We would benefit from having such a .NET library that would give us a good headstart on membership and coordination (consensus) to implement our business needs, and not have to spin our brains or time on solving the distributed problem (which this library meant to solve once it's said and done).

Back then I started the initial idea. Now, I wonder if this is still worth pursuing.

Currently, when a Node joins it multicast the join to let other members it had joined.
Other members then send a welcome message with the current list of members, so that the Node can catch up on the cluster membership fast.

However, we could also provide an option where the initial list of few members is provided upfront as a configuration (bootstrap node list). This could work in some scenarios and thus we could avoid the reliance on the multicast for the initial discovery.

Problem:
In some cases where the cluster nodes operate behind a load balancer (e.g. Kubernetes) and the client has no direct access to the internal network to address the leader node.

Solution:
We would like to be able to redirect an HTTP request made by the client to the leader node for handling.

That way clients hitting any node (leader or follower) will always have their request fulfilled by the leader.