> Op 8 november 2017 om 14:59 schreef Pierre-Luc Dion <pd...@cloudops.com>: > > > Same challenge here too! > > Let's look at improving Load-balancing offering from cloudstack, I guest we > should do a feature spec draft soon.., from my perspective, doing SSL > offload on the VR could be problematic if the VR spec if too small, and the > default spec of the VR being 1vcpu@256MB, considering it can be the router > of a VPC, doing VPN termination, adding HTTPS is a bit ish... What would > be your thought about this ? > > I'd be curious to have a LB offering in ACS where it would deploy a > redundant traefik[1] beside the VR for doing http and https Load-balancing. > I think it would also be useful if the API of that traefik instance would > be available from within the VPC or LBnetwork so is API would be accessible > to other apps orchestration tools such as kubernetes or rancher. > > traefik or not, here is what I think is needed by cloudstack in the LB > improvement: > > - support http, https (X-Forwarded-For)
HAProxy also supports the PROXY protocol towards the backends. Apache 2.4.22 supports this natively and Varnish for example can also talk PROXY. It adds a littlebit of metadata to the connection so that the backend knows the original IP the connection came from for example: https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt Wido > - basic persistence tuning (API already exist) > - better backend monitoring, currently only a tcp connect validate if the > webserver is up. > - ssl offload > - metric collection, more stats, maybe just export the tool status page to > the private network. > - Container world support, right now if you have Rancher or kubernetes > cluster, you need to deploy your own LB solution behing mostlikely a static > nat., If cloudstack would deploy a traefik instance, Kub or Rancher could > reuse this instance and managed it to properly do LB between containers. > > > What would be your prefered LB tool: > haproxy, traefik or nginx? > > CloudStack already have to code to handle SSL certs per projects and > accounts if not mistaking because that code was added to support NetScaler > as Load-balancer in the past. so one less thing to think about :-) > > > [1] https://traefik.io/ > > > PL, > > > > On Mon, Nov 6, 2017 at 7:10 AM, Nux! <n...@li.nux.ro> wrote: > > > Thanks Andrija, > > > > LB outside of the VR sounds like a good idea. An appliance based on, say > > cloud-init + ansible and so on could do the trick; alas it'd need to be > > outside ACS. > > I guess as users we could maybe come up with a spec for an improvement, at > > least we'd have something the devs could look at whenever it is possible. > > > > Regards, > > Lucian > > > > -- > > Sent from the Delta quadrant using Borg technology! > > > > Nux! > > www.nux.ro > > > > ----- Original Message ----- > > > From: "Andrija Panic" <andrija.pa...@gmail.com> > > > To: "dev" <dev@cloudstack.apache.org> > > > Cc: "users" <us...@cloudstack.apache.org> > > > Sent: Thursday, 2 November, 2017 23:21:37 > > > Subject: Re: HTTPS LB and x-forwarded-for > > > > > We used to make some special stuff for one of the clients, where all LB > > > configuration work is done from outside of the ACS, i.e. python script to > > > feed/configure VR - install latest haproxy 1.5.x for transparent proxy, > > > since client insisted on SSL termination done on backend web SSL > > servers.... > > > Not good idea, that is all I can say (custom configuration thing) - but > > the > > > LB setup is actually good - transparent mode haproxy, works on TCP level, > > > so you can see "real client IP" on the backend servers (which must use VR > > > as the default gtw, as per default, so the whole setup works properly). > > > > > > I'm still looking forward to see some special support of LB inside VR via > > > ACS - proper LB setup inside VR via GUI/API - i.e. to enable LB > > > provisioning SCRIPT (bash, or whatever), where all needed > > > install+configure can be done from client side - otherwise covering all > > > user cases, with proper HTTP checks and similar....is impossible to do > > > IMHO. > > > > > > Some other clients, actually have internal FW appliance (i.e. multihomed > > > VM, acting as gtw for all VMs in all networks), and haproxy instaled on > > > this device (with NAT configured from VR to this internal FW/VM, so > > remote > > > IP can be seen properly) - this setup is fully under customer control, > > and > > > can provide any kind of special haproxy config... > > > > > > > > > > > > > > > > > > > > > On 31 October 2017 at 19:54, Nux! <n...@li.nux.ro> wrote: > > > > > >> Hello, > > >> > > >> Of the people running an LB (VR) with https backends, how do you deal > > with > > >> the lack of x-forwarded-for since for port 443 there's just simple TCP > > >> balancing? > > >> > > >> Has anyone thought of terminating SSL in the VR instead? Ideas? > > >> > > >> Cheers > > >> > > >> -- > > >> Sent from the Delta quadrant using Borg technology! > > >> > > >> Nux! > > >> www.nux.ro > > >> > > > > > > > > > > > > -- > > > > > > Andrija Panić > >
