Plan to add sandbox branch

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

Plan to add sandbox branch

Jim Jagielski
In the coming week or so, I will be committing my load balance,
load determination and discovery work to a sandbox trunk. Many
people have asked for more info, so here we go.

Basically, this new feature uses nanomsg (nng) to implement the
SURVEY protocol between workers (nodes) and the front end server.
The proxy server will send out MEMBERSHIP and STATUS surveys, that
nodes can respond to; thus new nodes can automagically add themselves
as they come up as well as remove themselves when they restart or
shutdown via MEMBERSHIP. STATUS can be used to provide real-time
load on each node, which will be sent via a __packed__ struct,
ala NTP and other common usage patterns, in which 32bit fields are
converted from endian-ness to network and back. That STATUS info can
be used for "intelligent" load balancing and will provide some
typical server metrics such as memory, # of cpus, etc...
Reply | Threaded
Open this post in threaded view
|

Re: Plan to add sandbox branch

Daniel Ruggeri
Hi, Jim;
I'm coming up empty on a search against the Google-machine for SURVEY protocol. Any pointers you can share?

I'm also curious what your thoughts are about dealing with growth of the worker pool beyond the control of the proxy admin. For example, if I configure a balancer for 10 nodes, I have an idea of tuning parameters I might set differently than if the number of backends is in the tens of servers.
--
Daniel Ruggeri

On November 27, 2018 5:23:25 AM CST, Jim Jagielski <[hidden email]> wrote:
In the coming week or so, I will be committing my load balance,
load determination and discovery work to a sandbox trunk. Many
people have asked for more info, so here we go.

Basically, this new feature uses nanomsg (nng) to implement the
SURVEY protocol between workers (nodes) and the front end server.
The proxy server will send out MEMBERSHIP and STATUS surveys, that
nodes can respond to; thus new nodes can automagically add themselves
as they come up as well as remove themselves when they restart or
shutdown via MEMBERSHIP. STATUS can be used to provide real-time
load on each node, which will be sent via a __packed__ struct,
ala NTP and other common usage patterns, in which 32bit fields are
converted from endian-ness to network and back. That STATUS info can
be used for "intelligent" load balancing and will provide some
typical server metrics such as memory, # of cpus, etc...
Reply | Threaded
Open this post in threaded view
|

Re: Plan to add sandbox branch

Michal Karm
On 11/28/2018 02:33 AM, Daniel Ruggeri wrote:

> Hi, Jim;
> I'm coming up empty on a search against the Google-machine for SURVEY
> protocol. Any pointers you can share?
>
> I'm also curious what your thoughts are about dealing with growth of the
> worker pool beyond the control of the proxy admin. For example, if I configure
> a balancer for 10 nodes, I have an idea of tuning parameters I might set
> differently than if the number of backends is in the tens of servers.
> --
> Daniel Ruggeri

Mod_cluster solves this with configuration messages from worker nodes.
Httpd with mod_cluster configures balancers (as in mod_proxy balancer lingo)
according to CONFIG
messages from workers. So if you are spinning up a new batch of workers, you might
tell them to configure balancer differently, different timeout or retry values
for example.

Cheers
K.

>
> On November 27, 2018 5:23:25 AM CST, Jim Jagielski <[hidden email]> wrote:
>
>     In the coming week or so, I will be committing my load balance,
>     load determination and discovery work to a sandbox trunk. Many
>     people have asked for more info, so here we go.
>
>     Basically, this new feature uses nanomsg (nng) to implement the
>     SURVEY protocol between workers (nodes) and the front end server.
>     The proxy server will send out MEMBERSHIP and STATUS surveys, that
>     nodes can respond to; thus new nodes can automagically add themselves
>     as they come up as well as remove themselves when they restart or
>     shutdown via MEMBERSHIP. STATUS can be used to provide real-time
>     load on each node, which will be sent via a __packed__ struct,
>     ala NTP and other common usage patterns, in which 32bit fields are
>     converted from endian-ness to network and back. That STATUS info can
>     be used for "intelligent" load balancing and will provide some
>     typical server metrics such as memory, # of cpus, etc...
>


Michal Karm Babacek

--
Sent from my Hosaka Ono-Sendai Cyberspace 7

Reply | Threaded
Open this post in threaded view
|

Re: Plan to add sandbox branch

Jim Jagielski
In reply to this post by Daniel Ruggeri
https://nanomsg.org

On Nov 27, 2018, at 8:33 PM, Daniel Ruggeri <[hidden email]> wrote:

Hi, Jim;
I'm coming up empty on a search against the Google-machine for SURVEY protocol. Any pointers you can share?

I'm also curious what your thoughts are about dealing with growth of the worker pool beyond the control of the proxy admin. For example, if I configure a balancer for 10 nodes, I have an idea of tuning parameters I might set differently than if the number of backends is in the tens of servers.

Since nanomsg/nng will provide the communication between httpd and the backends, we could add something like a CONFIG survey that allows for the backends to "suggest" params.

--
Daniel Ruggeri

On November 27, 2018 5:23:25 AM CST, Jim Jagielski <[hidden email]> wrote:
In the coming week or so, I will be committing my load balance,
load determination and discovery work to a sandbox trunk. Many
people have asked for more info, so here we go.

Basically, this new feature uses nanomsg (nng) to implement the
SURVEY protocol between workers (nodes) and the front end server.
The proxy server will send out MEMBERSHIP and STATUS surveys, that
nodes can respond to; thus new nodes can automagically add themselves
as they come up as well as remove themselves when they restart or
shutdown via MEMBERSHIP. STATUS can be used to provide real-time
load on each node, which will be sent via a __packed__ struct,
ala NTP and other common usage patterns, in which 32bit fields are
converted from endian-ness to network and back. That STATUS info can
be used for "intelligent" load balancing and will provide some
typical server metrics such as memory, # of cpus, etc...

Reply | Threaded
Open this post in threaded view
|

Re: Plan to add sandbox branch

Alex Hautequest
In reply to this post by Jim Jagielski
How often are nodes updating themselves? Are they only updating their main proxy server or each other in a “multicast” fashion? How about if one of the nodes crash before sending back an update? Are you locking a session to a specific backend host, keep it tracked on the proxy/front end server and if so, for how long?

When I read your message, in particular the STATUS info statement, this plan of yours looked to me like how a regular load balancer product works, and if that is the intent, how different from and/or how integrated to ATS is this going to be?

Alex

On 2018/11/27 11:23:25, Jim Jagielski <[hidden email]> wrote:

> In the coming week or so, I will be committing my load balance,>
> load determination and discovery work to a sandbox trunk. Many>
> people have asked for more info, so here we go.>
>
> Basically, this new feature uses nanomsg (nng) to implement the>
> SURVEY protocol between workers (nodes) and the front end server.>
> The proxy server will send out MEMBERSHIP and STATUS surveys, that>
> nodes can respond to; thus new nodes can automagically add themselves>
> as they come up as well as remove themselves when they restart or>
> shutdown via MEMBERSHIP. STATUS can be used to provide real-time>
> load on each node, which will be sent via a __packed__ struct,>
> ala NTP and other common usage patterns, in which 32bit fields are>
> converted from endian-ness to network and back. That STATUS info can>
> be used for "intelligent" load balancing and will provide some>
> typical server metrics such as memory, # of cpus, etc...>
>

smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Plan to add sandbox branch

Christophe JAILLET
In reply to this post by Daniel Ruggeri
Le 28/11/2018 à 02:33, Daniel Ruggeri a écrit :
Hi, Jim;
I'm coming up empty on a search against the Google-machine for SURVEY protocol. Any pointers you can share?

Hi

Not sure if the answers already posted are what you are looking for.
Here are some links:
   https://nanomsg.org/gettingstarted/survey.html and other resources on https://nanomsg.org/


CJ

Reply | Threaded
Open this post in threaded view
|

Re: Plan to add sandbox branch

Jean-frederic Clere-3
On 29/11/2018 07:02, Christophe JAILLET wrote:

> Le 28/11/2018 à 02:33, Daniel Ruggeri a écrit :
>> Hi, Jim;
>> I'm coming up empty on a search against the Google-machine for SURVEY
>> protocol. Any pointers you can share?
>>
> Hi
>
> Not sure if the answers already posted are what you are looking for.
> Here are some links:
>    https://nanomsg.org/gettingstarted/survey.html and other resources on
> https://nanomsg.org/
>
>
> CJ
>

So as I am looking to proxy tomcat using httpd I need a 'pure" java
implementation for tomcat, it seems that it is missing for the moment,
correct?

--
Cheers

Jean-Frederic
Reply | Threaded
Open this post in threaded view
|

AW: Plan to add sandbox branch

Plüm, Rüdiger, Vodafone Group
In reply to this post by Christophe JAILLET

Just a quick and dirty idea and nothing beyond that worked out: How about to allow the balancer members to be configured via DNS SRV records? That should be very common in container environments.

 

Regards

 

Rüdiger

 

Von: Christophe JAILLET <[hidden email]>
Gesendet: Donnerstag, 29. November 2018 07:03
An: [hidden email]
Betreff: Re: Plan to add sandbox branch

 

Le 28/11/2018 à 02:33, Daniel Ruggeri a écrit :

Hi, Jim;
I'm coming up empty on a search against the Google-machine for SURVEY protocol. Any pointers you can share?

Hi

Not sure if the answers already posted are what you are looking for.
Here are some links:
   https://nanomsg.org/gettingstarted/survey.html and other resources on https://nanomsg.org/


CJ

Reply | Threaded
Open this post in threaded view
|

Re: Plan to add sandbox branch

Mladen Turk-3
In reply to this post by Jim Jagielski
On 27.11.2018. 12:23, Jim Jagielski wrote:
> In the coming week or so, I will be committing my load balance,
> load determination and discovery work to a sandbox trunk. Many
> people have asked for more info, so here we go.
>

Thanks for the info.
Like said, I'm for the idea for advertise/register/unregister
dynamic approach.
Having a basic working implementation, other could add more complex
features and implement additional strategies.
Thus ++1


Regards
--
^TM
Reply | Threaded
Open this post in threaded view
|

Re: Plan to add sandbox branch

Jim Jagielski
In reply to this post by Jean-frederic Clere-3
Yeah, I looked for something else, esp various pubsub implementations, but they really didn't fit in with what was needed.


> On Nov 29, 2018, at 3:02 AM, jean-frederic clere <[hidden email]> wrote:
>
> On 29/11/2018 07:02, Christophe JAILLET wrote:
>> Le 28/11/2018 à 02:33, Daniel Ruggeri a écrit :
>>> Hi, Jim;
>>> I'm coming up empty on a search against the Google-machine for SURVEY
>>> protocol. Any pointers you can share?
>>>
>> Hi
>>
>> Not sure if the answers already posted are what you are looking for.
>> Here are some links:
>>    https://nanomsg.org/gettingstarted/survey.html and other resources on
>> https://nanomsg.org/
>>
>>
>> CJ
>>
>
> So as I am looking to proxy tomcat using httpd I need a 'pure" java
> implementation for tomcat, it seems that it is missing for the moment,
> correct?
>
> --
> Cheers
>
> Jean-Frederic

Reply | Threaded
Open this post in threaded view
|

Re: Plan to add sandbox branch

Jim Jagielski
Hmmm... this has me thinking about maybe using the provider interface to implement the communication mechanism... let me mull this over.

> On Nov 30, 2018, at 8:27 AM, Jim Jagielski <[hidden email]> wrote:
>
> Yeah, I looked for something else, esp various pubsub implementations, but they really didn't fit in with what was needed.
>
>
>> On Nov 29, 2018, at 3:02 AM, jean-frederic clere <[hidden email]> wrote:
>>
>> On 29/11/2018 07:02, Christophe JAILLET wrote:
>>> Le 28/11/2018 à 02:33, Daniel Ruggeri a écrit :
>>>> Hi, Jim;
>>>> I'm coming up empty on a search against the Google-machine for SURVEY
>>>> protocol. Any pointers you can share?
>>>>
>>> Hi
>>>
>>> Not sure if the answers already posted are what you are looking for.
>>> Here are some links:
>>>   https://nanomsg.org/gettingstarted/survey.html and other resources on
>>> https://nanomsg.org/
>>>
>>>
>>> CJ
>>>
>>
>> So as I am looking to proxy tomcat using httpd I need a 'pure" java
>> implementation for tomcat, it seems that it is missing for the moment,
>> correct?
>>
>> --
>> Cheers
>>
>> Jean-Frederic
>