Dedicated seed nodes for akka cluster

[Christian Hoffmeister]

Hello,

I am just starting to dive into akka-cluster and have a question regarding the seed nodes:

My test project consists of 4 projects so far:

* PROTOCOL contains messaging case classes

* API contains cluster node, that also exposes a rest api (akka-cluster + akka-http)

* AUTH contains cluster node for auth stuff (akka-cluster)

* USERS contains cluster node to manage user data (akka-cluster)

At the moment I just set one API and one AUTH instance as seed nodes (could also have been some other nodes). Is it good practice to have another special project (called SEED), that does not do anything in particular,

except for joining the cluster, to act as seed node?

From my first thoughts, this might be a good idea, since this nodes would have to be restarted less often then other nodes (that have business logic). Basically only when updating infrastructure like host machine or akka.

Am I getting something wrong here?

Greetings

Christian

[Rafał Krzewski]

There are ways to boot up Akka cluster without dedicated seed node: whichever node comes up first becomes the seed of the cluster and lets in the other nodes. An external KV is used to perform the initial coordination.

Take a look at: https://github.com/hseeberger/constructr and https://github.com/rkrzewski/akka-cluster-etcd

Cheers,
Rafał

[Christian Hoffmeister]

So basically the known seed nodes are replaces with a known etcd cluster for the information sharing, if I understand this right?

Somewhat like this?

* A joins, no one is there, so it puts inself into etcd and starts a single node cluster

* B joins, finds A in etcd and joins A

* C joins, finds A....

* A gets shut down

* After a timeout, B or C are put into etcd as new seed node

* D joins, finds B or C....

In the examples (https://github.com/rkrzewski/akka-cluster-etcd/blob/master/examples/cluster-monitor/src/main/resources/application.conf) I found that auto-downing is used. What happens in case of temporory network separation? For example:

* A is in etcd as seed node

* A/B (can access each other, but neither etcd nor C/D)

* C/D (can access each other, but not A/B)

What happens now? And what happen when network is fully up again and A/B/C/D/etcd can communicate again. Do the two isle recombine into a single cluster?

Greetings

/c

[Patrik Nordwall]

If you use auto-downing and that triggers because of a network partition there will be two separate clusters and they will not recombine automatically. That's why we recommend against using auto-downing and instead recommend something like the Split Brain Resolver http://doc.akka.io/docs/akka/rp-16s01p03/scala/split-brain-resolver.html

/Patrik

--
>>>>>>>>>> Read the docs: http://akka.io/docs/
>>>>>>>>>> Check the FAQ: http://doc.akka.io/docs/akka/current/additional/faq.html
>>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user
---
You received this message because you are subscribed to the Google Groups "Akka User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+...@googlegroups.com.
To post to this group, send email to akka...@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

[Paul Cleary]

Is there a recommendation (beyond using the split brain resolver which looks like you need a subscription?) for manual downing or managing split brain?

[Paul Cleary]

This looks interesting, has any work been done to use consul kv by any chance?

Does this solution avoid the split brain?

[loe...@posteo.de]

There is Consul support for ConstructR, for details please join the ConstructR channel on Gitter.

ConstructR is for bootstrapping an Akka cluster, not for dealing with downing of unreachable nodes. Well, it could help with that as a side-effect, because by default if a node can’t refresh because it can’t reach the coordination service, it terminates, but the topologies of the coordination cluster and Akka cluster are most probably different and hence the expected behavior is sort of random.

Heiko

--

Heiko Seeberger

Home: heikoseeberger.de

Twitter: @hseeberger

Public key: keybase.io/hseeberger