Well, I've been a little busy these days and I had pending the algorithms
explanation.
With the ZLB v1 stable you have the following algorithm options to
configure for delivery requests to your real servers:
- roundrobin - persistence client-time: an equal balance of traffic to
all active real servers creating session persistence depending on client IP
Address. When a new request is received the load balancer core verify if
the client IP has been accessed before doing a check process over a hash
table. If the client has been accessed before, the connection is delivered
to the same real server. If a new client IP is requesting a connection, the
balancer assigns the next round robin real server and store this
association for future client requests. The time parameter is used to
stablish a time limit of "memory" for these IP clients.
- roundrobin - equal sharing: an equal balance of traffic to all active
real servers. This algorithm is like the algorithm explained before, but
without client IP "memory". All requests are processed through the round
robin algorithm. Every request is assigned to a different real server
equally.
- hash - sticky client: the Farm will create a hash string for each ip
client and send each connection from that hash to the same real server. A
hash table is created with the real servers and the requests are assigned
through the following algorithm: index = cli % nservers , where 'index' is
the index of the real server hash table, 'cli' is the integer
representation of the IP address and the 'nservers' is the number of real
servers avaliable. This algorithm is a way to create persistence through
the IP address, but it's valid if you've a variety of subnets clients
accessing to your service (for example, an international service).
- weight - connection linear dispatching by weight: balance connections
depending weight value, you have to edit this value for each real server.
The requests are delivered through an algorithm to calculate the load of
every server using the actual connections of them, and finally, to apply a
linear weight assignation.
- priority - connections to the highest priority avaliable: balance all
connections to the same highest priority server. If this server is down,
the connections switch to the next highest server. With this algorithm you
can build an active-pasive cluster service with several real servers.
Hope this information be understandable :)
Regards,
Laura.
On Tue, Oct 18, 2011 at 7:57 PM, Emilio Campos <
[email protected]> wrote:
> Hi Nick, Laura is going to send you some words about the algorithms.
>
> And about the version, we only are going to upgrade v1 if we detect
> important bugs, now all new features will be developed and added in v2rc.
>
> We would like follow with your help, tests, suggestions, etc on new
> versions.
>
> Regards!
>
>
>
> 2011/10/18 Nick Furnell <[email protected]>
>
>> Hi All
>>
>> Well a lot has changed in just a week. I dropped out of the ARP stuff, as
>> David was much more use then me, especially with the traces from the
>> routers. I will run the upgrade again on my live cluster and see what
>> version I end up with. Are you aiming for a v1.1 etc.. with a long term
>> goal of v2 in the future? I will keep testing and suggesting useful
>> changes, if that's ok.
>>
>> Laura/Emilio - if you can send me a little more background to the
>> algorithms, I will try to explain them better in the documentation?
>>
>> David, I am very interested in the VMware tweeks, if you share them I can
>> added the into my documentation and I am sure the guys will also appreciate
>> the extra input.
>>
>> I hope to be more use again this next week, if work get a little quieter.
>>
>> Thanks
>> Nick
>>
>> >>> <[email protected]> 18/10/2011
>> 16:50 >>>
>> Send Zenloadbalancer-support mailing list submissions to
>> [email protected]
>>
>> To subscribe or unsubscribe via the World Wide Web, visit
>> https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support
>> or, via email, send a message with subject or body 'help' to
>> [email protected]
>>
>> You can reach the person managing the list at
>> [email protected]
>>
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of Zenloadbalancer-support digest..."
>>
>>
>> Today's Topics:
>>
>> 1. Algorithms (David Martin (IT))
>> 2. Re: Algorithms (Emilio Campos)
>> 3. Re: Algorithms (David Martin (IT))
>>
>>
>> ----------------------------------------------------------------------
>>
>> Message: 1
>> Date: Tue, 18 Oct 2011 15:13:42 +0100
>> From: "David Martin \(IT\)" <[email protected]>
>> Subject: [Zenloadbalancer-support] Algorithms
>> To: <[email protected]>
>> Message-ID:
>> <425e07819ca12b4bb5eb0c7d8c55513203d87...@nth-exc-02s.jpress.co.uk>
>> Content-Type: text/plain; charset="us-ascii"
>>
>> Hi all,
>>
>>
>>
>> Now I have got a Zen cluster up-and-running successfully, I'm turning my
>> attention to the type of load balancing algorithm to use.
>>
>>
>>
>> I can see why Round-Robin with persistence is probably the best option
>> for things like http, every connection is fairly short lived and so the
>> balance remains good.
>>
>>
>>
>> Since I want to use Zen for RDP, I think this might not work so well.
>> Each session can last for anything from 15 minutes up to eight hours and
>> so by the end of the day a simple round-robin would leave an unevenly
>> distributed farm.
>>
>>
>>
>> On our current F5 boxes, we use an algorithm that always picks the
>> server with the fewest connections, but uses persistence to reconnect in
>> the event of a problem. Do any of the Zen or Pen modes allow for
>> something like this? I'm going to try with RR anyway to see if the
>> problem is big enough to worry about but it would be good to hear what
>> other people are doing for this kind of farm.
>>
>>
>>
>> Regards
>>
>>
>>
>> David
>>
>>
>>
>>
>> Johnston Press plc Registered in Scotland no. SC015382
>> Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS
>>
>> Opinions expressed in this email are those of the writer and not the
>> company.
>> E-mail traffic is monitored within Johnston Press and messages may be
>> viewed.
>> This e-mail and any files with it are solely for the use of the
>> addressee(s).
>> If you are not the intended recipient, you have received this e-mail in
>> error.
>> Please delete it or return it to the sender or notify us by email at
>> [email protected]
>>
>>
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>>
>> ------------------------------
>>
>> Message: 2
>> Date: Tue, 18 Oct 2011 16:42:33 +0200
>> From: Emilio Campos <[email protected]>
>> Subject: Re: [Zenloadbalancer-support] Algorithms
>> To: [email protected]
>> Message-ID:
>> <CAKWgN_oQo7R4hxKHH+TO7grL3pjDWk2J8QvQxfFgN4P5hQP5=w...@mail.gmail.com>
>> Content-Type: text/plain; charset="windows-1252"
>>
>> Hi David, which version of zen are you testing?, we are working on v2
>> version, the best thing is the new concept of profiles, we add profiles
>> for
>> http and https, with better perssitence session , better solution that the
>> actual.
>>
>> At the moment, and like you commented on your mail, now the best solution
>> is select rr with persistence session, but remember that this works
>> persistence is on client-ip.
>>
>> And about your Farm with RDP. Which algorithm are you using?, please try
>> with default algorithm (if you use v1rcX) or "roundrobin - persistence
>> client-time" (for v1stable), you can go to status view on a farm, and
>> you
>> should check that for the same client IP connects to the same server
>>
>> By other hand we recommend you enter on "Max number of real ip servers"
>> field (by default 10), the number of backend that you have, for obtain a
>> more quickly connection.
>>
>> We are waiting your feedback.
>>
>> 2011/10/18 David Martin (IT) <[email protected]>
>>
>> > Hi all,****
>> >
>> > ** **
>> >
>> > Now I have got a Zen cluster up-and-running successfully, I?m turning my
>> > attention to the type of load balancing algorithm to use. ****
>> >
>> > ** **
>> >
>> > I can see why Round-Robin with persistence is probably the best option
>> for
>> > things like http, every connection is fairly short lived and so the
>> balance
>> > remains good.****
>> >
>> > ** **
>> >
>> > Since I want to use Zen for RDP, I think this might not work so well.
>> Each
>> > session can last for anything from 15 minutes up to eight hours and so
>> by
>> > the end of the day a simple round-robin would leave an unevenly
>> distributed
>> > farm.****
>> >
>> > ** **
>> >
>> > On our current F5 boxes, we use an algorithm that always picks the
>> server
>> > with the fewest connections, but uses persistence to reconnect in the
>> event
>> > of a problem. Do any of the Zen or Pen modes allow for something like
>> this?
>> > I?m going to try with RR anyway to see if the problem is big enough to
>> worry
>> > about but it would be good to hear what other people are doing for this
>> kind
>> > of farm.****
>> >
>> > ** **
>> >
>> > Regards****
>> >
>> > ** **
>> >
>> > David**
>> >
>> > ** **
>> >
>> > Johnston Press plc Registered in Scotland no. SC015382
>> > Registered Office:108 Holyrood Road, Edinburgh, EH8 8AS
>> >
>> > Opinions expressed in this email are those of the writer and not the
>> company.
>> > E-mail traffic is monitored within Johnston Press and messages may be
>> viewed.
>> > This e-mail and any files with it are solely for the use of the
>> addressee(s).
>> > If you are not the intended recipient, you have received this e-mail in
>> error.
>> > Please delete it or return it to the sender or notify us by email
>> [email protected]
>> >
>> >
>> >
>> >
>> ------------------------------------------------------------------------------
>> > All the data continuously generated in your IT infrastructure contains a
>> > definitive record of customers, application performance, security
>> > threats, fraudulent activity and more. Splunk takes this data and makes
>> > sense of it. Business sense. IT sense. Common sense.
>> > http://p.sf.net/sfu/splunk-d2d-oct
>> > _______________________________________________
>> > Zenloadbalancer-support mailing list
>> > [email protected]
>> > https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support
>> >
>> >
>>
>>
>> --
>> Load balancer distribution - Open Source Project
>> http://www.zenloadbalancer.com
>> Distribution list (subscribe):
>> [email protected]
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>>
>> ------------------------------
>>
>> Message: 3
>> Date: Tue, 18 Oct 2011 16:50:29 +0100
>> From: "David Martin \(IT\)" <[email protected]>
>> Subject: Re: [Zenloadbalancer-support] Algorithms
>> To: <[email protected]>
>> Message-ID:
>> <425e07819ca12b4bb5eb0c7d8c55513203d87...@nth-exc-02s.jpress.co.uk>
>> Content-Type: text/plain; charset="us-ascii"
>>
>> Hi Emilio,
>>
>>
>>
>> I'm using version 1rc5, patched with the content3-3 fix that you
>> supplied and the GARP patch that Laura supplied. That combination gives
>> me working clustering and failover on remote LANs. I probably need to
>> wait for these patches to be included in the main release before I can
>> start playing around with different versions.
>>
>>
>>
>> I'm only just starting testing the working solution so I have not yet
>> picked an algorithm yet, although I will probably start with
>> RR+Persistence. "Default" is not an option in the list (see screenshot).
>>
>>
>> The nice thing about the simple algorithm is that it will always result
>> in the server with the lowest number of connections (and hence lowest
>> load) being picked first. Our terminal server farms are under quite
>> heavy pressure and an unequal loading is very noticeable (In the very
>> early days we used DNS round-robin which was awful. We then swapped to
>> NLB which was better but a real pain to set up (static ARP entries and
>> the like. Eventually we ended up using some old F5 equipment I had lying
>> around but I am worried about hardware failure).
>>
>>
>>
>> As I said before, I'm really grateful for this product and your
>> continued support. I'd be happy to contribute the results of my testing
>> once complete which might help other users. I've got some scripts for
>> vmware-based installations that take some of the pain out of making Zen
>> work nicely on VMWare if they are of any use.
>>
>> Thanks
>>
>>
>>
>> David
>>
>> From: Emilio Campos [mailto:[email protected]]
>> Sent: 18 October 2011 15:43
>> To: [email protected]
>> Subject: Re: [Zenloadbalancer-support] Algorithms
>>
>>
>>
>> Hi David, which version of zen are you testing?, we are working on v2
>> version, the best thing is the new concept of profiles, we add profiles
>> for http and https, with better perssitence session , better solution
>> that the actual.
>>
>> At the moment, and like you commented on your mail, now the best
>> solution is select rr with persistence session, but remember that this
>> works persistence is on client-ip.
>>
>> And about your Farm with RDP. Which algorithm are you using?, please try
>> with default algorithm (if you use v1rcX) or "roundrobin - persistence
>> client-time" (for v1stable), you can go to status view on a farm, and
>> you should check that for the same client IP connects to the same server
>>
>> By other hand we recommend you enter on "Max number of real ip servers"
>> field (by default 10), the number of backend that you have, for obtain
>> a more quickly connection.
>>
>> We are waiting your feedback.
>>
>> 2011/10/18 David Martin (IT) <[email protected]>
>>
>> Hi all,
>>
>>
>>
>> Now I have got a Zen cluster up-and-running successfully, I'm turning my
>> attention to the type of load balancing algorithm to use.
>>
>>
>>
>> I can see why Round-Robin with persistence is probably the best option
>> for things like http, every connection is fairly short lived and so the
>> balance remains good.
>>
>>
>>
>> Since I want to use Zen for RDP, I think this might not work so well.
>> Each session can last for anything from 15 minutes up to eight hours and
>> so by the end of the day a simple round-robin would leave an unevenly
>> distributed farm.
>>
>>
>>
>> On our current F5 boxes, we use an algorithm that always picks the
>> server with the fewest connections, but uses persistence to reconnect in
>> the event of a problem. Do any of the Zen or Pen modes allow for
>> something like this? I'm going to try with RR anyway to see if the
>> problem is big enough to worry about but it would be good to hear what
>> other people are doing for this kind of farm.
>>
>>
>>
>> Regards
>>
>>
>>
>> David
>>
>>
>>
>>
>>
>>
>> Transform Medical Group (CS) Limited.
>> Registered in England & Wales with Company Number: 3228476
>> Registered office: 192 Altrincham Road, Manchester M22 4RZ
>> <http://www.transforminglives.co.uk>
>> Transform Medical Group(CS) is registered in England and Wales, number
>> 3228476. The registered office is at 192 Altrincham Road, Manchester, M22
>> 4RZ. The information contained in this electronic message and any
>> attachments (the "Message") is intended for one or more specific
>> individuals or entities, and may be confidential, proprietary, privileged
>> or otherwise protected by law. If you are not the intended recipient,
>> please notify the sender immediately, delete this Message and do not
>> disclose, distribute, or copy it to any third party or otherwise use this
>> Message. Electronic messages are not secure or error free and can contain
>> viruses or may be delayed, and the sender is not liable for any of these
>> occurrences. The sender reserves the right to monitor, record and retain
>> electronic messages.
>>
>>
>>
>> ------------------------------------------------------------------------------
>> All the data continuously generated in your IT infrastructure contains a
>> definitive record of customers, application performance, security
>> threats, fraudulent activity and more. Splunk takes this data and makes
>> sense of it. Business sense. IT sense. Common sense.
>> http://p.sf.net/sfu/splunk-d2d-oct
>> _______________________________________________
>> Zenloadbalancer-support mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support
>>
>>
>
>
> --
> Load balancer distribution - Open Source Project
> http://www.zenloadbalancer.com
> Distribution list (subscribe):
> [email protected]
>
>
>
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure contains a
> definitive record of customers, application performance, security
> threats, fraudulent activity and more. Splunk takes this data and makes
> sense of it. Business sense. IT sense. Common sense.
> http://p.sf.net/sfu/splunk-d2d-oct
> _______________________________________________
> Zenloadbalancer-support mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support
>
>
------------------------------------------------------------------------------
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1
_______________________________________________
Zenloadbalancer-support mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support
