Eureka Clustering

147 views
Skip to first unread message

ivar...@gmail.com

unread,
Feb 12, 2015, 8:07:06 AM2/12/15
to eureka_...@googlegroups.com
Hi,

I don't fully understand how the clustering model is supposed to work.
So far it is clear that the failover model is supported, where there exists a main Node and a backup node. The main node performs all duties and in case of trouble all clients migrate to backup node. The clients need to be provided with a full list of nodes (or through DNS).

I am trying to understand whether a load balanced mode is supported, a few clients to Node1 and a few to Node2.
With this model I find that partitions occur, meaning a client that talks to Server1 cannot find clients that talk to Server2. Is this the intended behaviour?

It seems that client and serer functionality inside an Eureka node are separate:
- server: PeerAwareInstanceRegistry.registry - holds clients that send hearbeats
- client: talks to a peer Eureka node and keeps everything in localRegionApps.
These 2 caches never seem to intersect. There is a moment at bootstrap where Eureka fetches all registerred clients from a peer Server Node, and this is the only moment when multiple Eureka Servers have the same view on the service network topology. But after a while nodes that do not send heartbeats are expired.

Thanks in advance,
Adrian

Tomasz Bak

unread,
Feb 12, 2015, 4:02:23 PM2/12/15
to eureka_...@googlegroups.com
There is no concept of main/backup node in Eureka. All Eureka nodes are equivalent, and client may connect to any of them. Usually, the one in the same availability zone will be preferred due to performance reason (network connectivity).
The replication mechanism is very simplistic where each client request is forwarded to all other nodes.

>I am trying to understand whether a load balanced mode is supported, a few clients to Node1 and a few to Node2.
If you have Eureka nodes and applications in different zones, they will partition naturally. Plus within a zone, the URLs from a service list (EurekaClientConfig.getEurekaServerServiceUrls(zoneId)), or resolved from DNS are randomized (using hash of client node hostname).



--
You received this message because you are subscribed to the Google Groups "eureka_netflix" group.
To unsubscribe from this group and stop receiving emails from it, send an email to eureka_netfli...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

ivar...@gmail.com

unread,
Feb 12, 2015, 5:43:21 PM2/12/15
to eureka_...@googlegroups.com
Thank you Tomasz.

It would be good that it works like this. Unfortunately my tests run on my local machine with a few servers and clients (NO DNS) show that clients always connect to the first server they get in the list of serviceUrl. If I specify a different order for the for a client, that client will be on a separate network "partition".

ivar...@gmail.com

unread,
Feb 12, 2015, 6:43:05 PM2/12/15
to eureka_...@googlegroups.com, ivar...@gmail.com
Tomasz, you pointed me in the right direction. The whole point is to have different hostnames when running on localhost.
Reply all
Reply to author
Forward
0 new messages