High Availability of a web server on a distributed cloud

[Dave Cramer]

Yep, they've had 3 outages in about a year.

>
> Note that with a load balancer (nginx/wahtever) you don't need to reassign
> IPs since it's not a "master/slave" or stand-by solution; all servers are
> online with their own IP/DNS name and the LB distributes the load and if
> one goes down the node gets out of rotation (no traffic goes to it). It's
> much much better imho to not have different roles (master/slave), changing
> IPs, split brain and timeout/response time problems and just have the same
> single configuration in the same one server image that can be spun in a
> minute. Of course now the LB is a single point of failure.
>
>
Yes, it is the LB that is the problem, how do you deal with that ?



Dave

> Cheers,
>
> ---------------------
> Fernando Duran
> http://www.fduran.com
>
> >
> >Dave
> >
> >
> >Dave Cramer
> >
> >
> >On Mon, Jan 14, 2013 at 3:26 PM, Fernando Duran <liberosec-FFYn/CNdgSA at public.gmane.org>
> wrote:
> >
> >
> >>>________________________________
> >>> From: Dave Cramer <davecramer-Re5JQEeQqe8AvxtiuMwx3w at public.gmane.org>
> >>>To: tlug-lxSQFCZeNF4 at public.gmane.org
> >>>Sent: Monday, January 14, 2013 2:58:55 PM
> >>>Subject: Re: [TLUG]: High Availability of a web server on a distributed
> cloud
> >>
> >>>
> >>>
> >>>Well I don't want to use a single provider such as amazon. Which makes
> things more difficult.
> >>
> >>More difficult how? if it's because you're more dependent of
> a particular provider/solution I understand.
> >>
> >>
> >>Cheers,
> >>
> >>
> >>---------------------
> >>Fernando Duran
> >>http://www.fduran.com
> >>
> >>
> >>
> >>>
> >>>
> >>>So the problem is essentially how to duplicate their elastic ip's
> >>>
> >>>
> >>>
> >>>Dave Cramer
> >>>
> >>>
> >>>On Mon, Jan 14, 2013 at 2:51 PM, Fernando Duran <liberosec-FFYn/CNdgSA at public.gmane.org>
> wrote:
> >>>
> >>>If the application is HTTP a relatively simple solution is to use nginx
> as a load balancer
> http://blog.jsdelivr.com/2013/01/nginx-load-balancing-basics.html plus
> some hearbeat/monitoring to detect/alert when a node goes down.
> >>>>
> >>>>High availability is an excellent area to learn about
> networking/scripting/trade-off decisions etc but it's very hard to get
> right, esp. the first time. I think is very worth it using the cloud
> provider's solutions, like Amazon's (or Rackspace's) load balancers and
> autoscaling.
> >>>>
> >>>>---------------------
> >>>>Fernando Duran
> >>>>http://www.fduran.com
> >>>>
> >>>>
> >>>>>________________________________
> >>>>> From: Dave Cramer <davecramer-Re5JQEeQqe8AvxtiuMwx3w at public.gmane.org>
> >>>>>To: tlug-lxSQFCZeNF4 at public.gmane.org
> >>>>>Sent: Monday, January 14, 2013 8:57:39 AM
> >>>>>Subject: [TLUG]: High Availability of a web server on a distributed
> cloud
> >>>>
> >>>>>
> >>>>>
> >>>>>It is relatively simple to distribute an application to a number of
> servers and use haproxy to switch ip's. What I can't figure out is how to
> switch make sure that the IP that points to ha-proxy can be moved easily if
> that machine fails ?
> >>>>>
> >>>>>
> >>>>>DNS round robin doesn't exactly work. I have a very limited
> understanding of BGP is it possible to do without BGP ?
> >>>>>
> >>>>>
> >>>>>
> >>>>>Dave Cramer
> >>>>>
> >>>>>
> >>>>
> >>>>--
> >>>>The Toronto Linux Users Group.      Meetings: http://gtalug.org/
> >>>>TLUG requests: Linux topics, No HTML, wrap text below 80 columns
> >>>>How to UNSUBSCRIBE: http://gtalug.org/wiki/Mailing_lists
> >>>>
> >>>
> >>>
> >>>
> >>--
> >>The Toronto Linux Users Group.      Meetings: http://gtalug.org/
> >>TLUG requests: Linux topics, No HTML, wrap text below 80 columns
> >>How to UNSUBSCRIBE: http://gtalug.org/wiki/Mailing_lists
> >>
> >
> >
> >
> --
> The Toronto Linux Users Group.      Meetings: http://gtalug.org/
> TLUG requests: Linux topics, No HTML, wrap text below 80 columns
> How to UNSUBSCRIBE: http://gtalug.org/wiki/Mailing_lists
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://gtalug.org/pipermail/legacy/attachments/20130114/4caed391/attachment.html>