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 <[email protected]> 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" <[email protected]> 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 ● [email protected]
> >
> >
> > ----------------------------------------------------------------------
> > For LINUX-390 subscribe / signoff / archive access instructions,
> > send email to [email protected] 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 [email protected] 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 [email protected] 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/

Reply via email to