Hello Thanks for detailed explanation. I assume we will proceed to distributed lock as you've suggested.
One last question, do you think Zookeeper can play this role well ? Or we should consider only Consul / Etcd ? We're using Kafka internally, so we already having Zookeeper in place. середа, 28 грудня 2016 р. 15:06:08 UTC+2 користувач Rafał Krzewski написав: > > W dniu środa, 28 grudnia 2016 13:30:23 UTC+1 użytkownik Evgeny Shepelyuk > napisał: >> >> Hello, >> >> In Docker Swarm when service is created, it's assigned to Virtual IP. >> I.e. when I create several instances of *wallet-seed *they will get an >> single IP (10.0.0.2, for example), while each of container will have own IP >> (10.0.0.5, 10.0.0.6, 10.0.0.7 and so on) >> When *wallet-seed* address is resolved within Swarm cluster - it will >> initially resolves to service VIP (10.0.0.2) and then to the IP of >> particular container in round robin fashion. >> >> So if I put *wallet-seed * as a seed node address in my *wallet *service >> config, then 1st instance could resolve it to 10.0.0.5, second instance can >> resolve to 10.0.0.6 etc. >> >> As far as I understand this will lead to cluster partitioning, right ? >> > > No, I meant something else. First of all, Akka cluster is implemented on > top of Akka remoting. And for Akka remoting to work, each node needs to > know it's self address, which is the IP the other nodes will use to connect > to it. The node address becomes the part of remote ActorRefs. Any incoming > message that contains different address than the node's self address is > dropped. This is a good thing, because you could have actors with the same > local paths on different node clusters and the results of delivering > message to a wrong instance could potentially be disastrous. Because of > this, even if you create *wallet-seed* service with virtual IP 10.0.0.2 > you cannot use this IP as the address of the seed, because the containers > backing the service will expect to receive messages addressed to 10.0.0.5, > 10.0.0.6 and so on and will discard messages addressed to 10.0.0.2. > You could use docker-swarm service in a different way: to advertise the > proper IP address of the cluster seed, but you cannot use Akka remoting > protocol for that, for reason given above. Suppose you implement it the > following way: define a HTTP endpoint, say at port 5000 that will respond > to GET /seeds with a text/plain message containing IP address of cluster > seed. Each node upon startup will do the following: > - attempt a GET wallet-seed:5000/seed > - if it succeeds, join the cluster at received IP > - if it fails, this node is the first one and it should: > - bootstrap the cluster by joining itself > - publish a HTTP service at port 5000 advertising it's own address > The definition of wallet-seed service should include a health check > condition so that only containers publishing the HTTP at port 5000 would be > act as it's backend > That would work, but has a glaring problem: there is a race condition > between the seed nodes. More than one container can "elect itself" as the > seed. Then the other nodes would access different seeds through > *wallet-seed* in round-robin fashion and join their respective clusters. > Using a consistent store like consul or etcd provides a solution to the > race condition but also solves a second problem: it can be used to > advertise seed address without crafting a custom service. > > Cheers, > Rafał > -- >>>>>>>>>> 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+unsubscr...@googlegroups.com. To post to this group, send email to akka-user@googlegroups.com. Visit this group at https://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
