Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

The Mystery of Eureka's Self-Preservation

DZone's Guide to

The Mystery of Eureka's Self-Preservation

Here, we examine a quick overview of how Eureka's self-preservation mode works as well as a couple of traps to avoid, depending on your network.

· Cloud Zone
Free Resource

Make it happen: rapid app development on Kubernetes as a managed service.

When it comes to Eureka, self-preservation could be defined as "Eureka servers stop expiring clients from the registry when they do not receive heartbeats (from peers and client microservices) beyond a certain threshold."

Let's take a look at the diagram below.

Image title








Suppose EC2 used to invoke EC4 after discovering it from a Eureka registry. Due to a network partition, EC4 and EC5 lost connectivity with the servers. Suppose as per our threshold configuration, after two of the clients go down, Eureka servers enter self-preservation mode. From then onward, Eureka servers stop expiring the registry — EC3 has gone down, but it's still reflected in the registry.

The Rationale

  • Servers are not receiving heartbeats could be due to a poor network partition (i.e. does not necessarily mean the clients are down).

  • Even though the connectivity is lost between servers and a client, clients might have connectivity with each other

The Math

We can see the means of calculating the number of heartbeats per minute below. Netflix code assumes that the clients send heartbeats at 30-second intervals (default) for this calculation.

Suppose:

  • The number of registered application instances at some point in time = N

  • The configured heartbeat threshold (to turn on self-preservation) = 0.85 (default)

Number of heartbeats expected from one client instance/min

2

Number of heartbeats expected from N instances/min

2 * N

Minimum expected heartbeat threshold / min

2 * N * 0.85


Since N is a variable, 2 * N * 0.85 is calculated in every 15 minutes (default) by a scheduler.

Configurations (With Defaults)

eureka.instance.leaseRenewalIntervalInSeconds = 30 # hearbeat interval
eureka.server.renewalPercentThreshold = 0.85
eureka.server.renewalThresholdUpdateIntervalMs = 15 * 60 * 1000 # 15 mins 


Conclusions

  • Self-preservation incorrectly assumes few down microservice instances to be a poor network partition.

  • Self-preservation never expires, until and unless the down microservices are brought back (or the network glitch is resolved).

  • With self-preservation mode on, we cannot fine-tune the client heartbeat interval, since self-preservation assumes heartbeats are received at intervals of 30 seconds.

  • Unless these kinds of network glitches are common in your environment, self-preservation can be turned-off (even though most people recommend to keep it on).

Tutorial: WordPress as distributed microservices on Kubernetes.

Topics:
spring cloud ,eureka ,self-preservation ,cloud ,tutorial

Published at DZone with permission of Fahim Farook. See the original article here.

Opinions expressed by DZone contributors are their own.

THE DZONE NEWSLETTER

Dev Resources & Solutions Straight to Your Inbox

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.

X

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}