Push vs Pull based approach for load balancing

182 views
Skip to first unread message

Teodor Pripoae

unread,
Oct 24, 2015, 6:28:31 AM10/24/15
to marathon-framework
Hi,

I can see you are recommending a pull based approach using HAProxy for load balancing marathon tasks which checks once per minute for updates. Also, there is the event bus which can be configured to write to etcd using a similar bridge and then update HAProxy using confd.

Why are you preferring the pull based approach instead of push based approach in the official documentation ? Are there any downsides for the second option ?

I created a Marathon-Vulcand bridge using etcd, I think it can be also used in a similar way using confd for updating HAProxy.

Cody Maloney

unread,
Oct 27, 2015, 12:09:23 AM10/27/15
to Teodor Pripoae, marathon-framework
I'd actually suggest a mix of push based and pull based. Use push based so that things probably show up quickly, then do a pull and global state reconcilliation every N seconds or few minutes in order to make sure things don't get too out of sync if a push gets lost for some reason (And help detect when modedls don't match up).

Service Router implements both pull based and push based (although currently they are mutually exclusive). The push based bits inside of it use push based around Marathon's older "event bus" rather than the newer "event stream" (http://mesosphere.github.io/marathon/docs/rest-api.html#event-stream), the event stream adds some simplicity in management (It uses bi-directional communication rather than requiring explicit registration + de-registration of a host which knows its own address / identity)

Push vs. pull is definitely a tradeoff, both in terms of latency of things showing up, as well as in the efficiency when operating at a large scale (Transferring 10,000 tasks json definition is much larger than sending a single "added task foo", "lost task bar"). Pulling is a bit easier to implement as a v1. With push you really need to be certain you reconcile periodically, since if your service has a different perspective than marathon (Do to implementation bugs in either, or inconsistencies which could occur due to various failures), things can get out of whack without noticing.

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

Teodor Pripoae

unread,
Oct 29, 2015, 1:26:26 AM10/29/15
to marathon-framework, teodor....@gmail.com
Thanks for the detailed informations, now I understand the tradeoffs.
Reply all
Reply to author
Forward
0 new messages