DotNext.Net.Cluster.Consensus.Raft: Seed members and joining members?

[rogeralsing]

Is the DotNext.Net.Cluster.Consensus.Raft cluster capable of allowing non-specified members to join the cluster?
e.g. cluster boots with 3 seed nodes, then additional nodes join in against one of those, and the cluster become aware of the newly joined nodes?

Or is it purely capable of consensus between the pre-specified members?

In https://github.com/AsynkronIT/protoactor-dotnet , we have externalized all cluster management.
e.g. we use Consul or Kubernetes API to get the cluster topology.

I would very much like to give it a try to use dotNext Raft as an alternative cluster provider, as it wouldn't require users to have some specific infrastructure in place.

[sakno]

Hi @rogeralsing ,
Short answer is yes but it requires service discovery.

Long answer:
The current implementation need to know about the list of cluster members. It's needed for calculating quorum. Under the hood, the configuration of cluster members can be supplied via ASP.NET Core configuration infrastructure (in case of HTTP transport) or manually (in case of TCP/UDP transport). Configuration providers in ASP.NET Core can be extended. This gives a way to write custom provider and discover cluster nodes using 3rd-party mechanism such as Consul or Kubernetes. However, cluster members can be added and removed dynamically to live cluster. Raft implementation for ASP.NET Core (which is in DotNext.AspNetCore.Cluster library) tracks membership changes in the background using IOptionsMonitor. It's fully tested functionality. Moreover, there is a special interface for that: IExpandableCluster. If cluster engine implements it, the cluster can be re-configured dynamically. It's implemented for ASP.NET Core out-of-the-box but not for TCP/UDP transports.

Writing custom configuration providers for the purpose of service discovery may be challenging and redundant. Therefore, in version 3.1.0 (which is in development now) a new way of service discovery is introduced: IMemberDiscoveryService interface. It's much simpler than custom configuration provider. It allows to implement any custom discovery mechanism. Also I tried to write my own discovery mechanism for Kubernetes which is based on Service abstraction to verify the concept.

This interface is introduced because there are too many hosting infrastructures exist: Kubernetes, clouds, pure Docker, bare metal etc. As a result, I can't offer universal implementation. Instead, it's better to provide extensibility point to the developers.

In other words, service discovery is delegated to library consumers. From my point of view, it's not a goal of Raft implementation to provide built-in universal discovery mechanism. In case of bare metal deployment, some solutions such as Hazelcast IMDG use their own discovery mechanism based on UDP broadcast. .NET Framework has PRNP but it looks like dead (Windows-only, not ported to .NET Core). UDP broadcasting has many drawbacks and network engineers usually don't like this approach.

I think you're looking for some default service discovery mechanism. Raft is about building consistent and reliable clusters.