I agree with Rob here. From a performance point of view, it is likely better to just not use a load balancer.
Just for the sake of completeness, the haproxy does have some different aspects that make it interesting. We actually use it internally for several purposes: - it is used as the external entry for a number of websites. All of these have the same IP with different DNS records, and haproxy connects incoming requests to the correct server behind. - it is used to do the external SSL connection to all these servers. Internally, the private connection to the server can be run with or without SSL. We often do not require SSL internally. - It gives useful, or at least nice error pages when a service is down. - For stateless servers, you can have multiple servers and when one is down, haproxy just uses others to take over (HA feature). This is just the features we use, there is definitly more to it. If you want to have a load balancer, I also would recommend to have a closer look at latencies. I don't know if the Mainframe is the correct machine to perform this type of task. This would be something that Rob would be better to comment (well, he already told his opinion). Berthold On Fri, 13 Mar 2015 11:22:22 +0100 Rob van der Heij <rvdh...@velocitysoftware.com> wrote: > Also look at performance data and see whether it makes sense what you > want to do. I have seen installations that were spreading the load > over a dozen front-end servers all running on the same z/VM image, > with a lot of the requests just queue for the back-end database. You > can burn a lot of resources just to determine which server should > handle the request, and may achieve little when they share the > resources. > > In an architecture from the discrete world, it is not always obvious > which risks are mitigated by what part of the solution. When you > transpose that to a Linux on z/VM implementation, some of the > infrastructure failures do not apply or may not be covered by the > solution (eg "hardware fail" is not fixed by using another Linux > guest on the same z/VM LPAR). Using multiple members on different > machines in an SSI cluster covers differnet issues. > > Duplicating servers that hold no application data is fairly simple, > but things get hairy when you duplicate databases. Business may well > justify a HA setup, but remember this is not commodity hardware where > servers fail for trivial reasons. One of the reasons for using z > Systems is that you sometimes can avoid some of the complexity that > comes with redundancy on higher levels in the design. > > When possible, I want to drive the virtual machines at their most > efficient load. When a single server could do, it's not more > efficient to spread it over a dozen sharing the same resources. Do > some measurements to find the healthy load for your application, and > monitor usage for those values and add resources when needed. > > Rob van der Heij > http://www.velocitysoftware.com/ > > On 13 March 2015 at 08:52, Berthold Gunreben <b...@suse.de> wrote: > > > Hi, > > > > Starting with SLES12, there is haproxy included in the HA part of > > SLES. > > > > http://www.haproxy.org/ > > > > Berthold > > > > On Thu, 12 Mar 2015 19:10:07 +0000 > > "Stewart, Lee" <lstew...@visa.com> wrote: > > > > > Does anyone know of an IP “sprayer” for Linux on Z? (To send > > > arriving requests on to one of several servers, round robin or > > > load balanced.) > > > > > > Since this isn’t a WAS implementation, the DM with WAS isn’t a > > > choice…. > > > > > > Thanks, > > > Lee > > > > > > Lee Stewart ● VM System Support ● Visa ● Phone: 6(750)4601 - > > > +1-303-389-4601 ● lstew...@visa.com > > > > > > > > > ---------------------------------------------------------------------- > > > For LINUX-390 subscribe / signoff / archive access instructions, > > > send email to lists...@vm.marist.edu with the message: INFO > > > LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 > > > ---------------------------------------------------------------------- > > > For more information on Linux on System z, visit > > > http://wiki.linuxvm.org/ > > > > > > > > -- > > ---------------------------------------------------------------------- > > Berthold Gunreben Build Service > > Team http://www.suse.de/ > > Maxfeldstr. 5 SUSE LINUX GmbH D-90409 > > Nuernberg, Germany GF: Felix Imendörffer, Jane Smithard, Jennifer > > Guild, Dilip Upmanyu, Graham Norton HRB 21284 (AG Nürnberg) > > > > ---------------------------------------------------------------------- > > For LINUX-390 subscribe / signoff / archive access instructions, > > send email to lists...@vm.marist.edu with the message: INFO > > LINUX-390 or visit > > http://www.marist.edu/htbin/wlvindex?LINUX-390 > > ---------------------------------------------------------------------- > > For more information on Linux on System z, visit > > http://wiki.linuxvm.org/ > > > > ---------------------------------------------------------------------- > For LINUX-390 subscribe / signoff / archive access instructions, > send email to lists...@vm.marist.edu with the message: INFO LINUX-390 > or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 > ---------------------------------------------------------------------- > For more information on Linux on System z, visit > http://wiki.linuxvm.org/ -- ---------------------------------------------------------------------- Berthold Gunreben Build Service Team http://www.suse.de/ Maxfeldstr. 5 SUSE LINUX GmbH D-90409 Nuernberg, Germany GF: Felix Imendörffer, Jane Smithard, Jennifer Guild, Dilip Upmanyu, Graham Norton HRB 21284 (AG Nürnberg) ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 ---------------------------------------------------------------------- For more information on Linux on System z, visit http://wiki.linuxvm.org/
