<div dir="ltr">Hi Trevor,<div><br></div><div>Some of these use cases are mine, I will try to clarify the ones that are in-line:</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, May 1, 2014 at 9:20 AM, Trevor Vardeman <span dir="ltr"><<a href="mailto:trevor.vardeman@rackspace.com" target="_blank">trevor.vardeman@rackspace.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><br>Use-Case 10: I assumed this was referring to the source-IP that<br>
accesses the Load Balancer. As far as I know the X-Forwarded-For header<br>
includes this. To satisfy this use-case, was there some expectation to<br>
retrieve this information through an API request? Also, with the<br>
trusted-proxy evaluation, is that being handled by the pool member, or<br>
was this in reference to an "access list" so-to-speak defined on the<br>
load balancer?<br></blockquote><div><br></div><div>Actually, this would be the source IP of the load balancer itself. That is to say, any client on the internet can insert an X-Forwarded-For header which, with the right server configuration, may cause an application attribute their actions to some other IP on the internet. To solve this potential security problem, a lot of web application software will only trust the X-Forwarded-For header if the request comes from a trusted proxy. So, in order for the back-end application to know which IPs constitute this group of "trusted proxies" (and therefore, which requests it can trust the X-Forwarded-For header in), the application needs to have some way to know what IPs the trusted proxies will be using to originate requests. (More info on how this works is here: <a href="http://en.wikipedia.org/wiki/X-Forwarded-For">http://en.wikipedia.org/wiki/X-Forwarded-For</a> )</div>
<div><br></div><div>In the case of LBaaS, there are a couple ways to handle this problem:</div><div><ol><li>Provide an API interface that a user can use to get a list of the possible source IPs for a given load balancer configuration. This is somewhat problematic, because this list might change without notice, and therefore the back-end application is going to have to check this with some regularity.</li>
<li>Make sure that the load balancer also originates requests to the back-end from the VIP IP(s). This works pretty well for medium-sized deployments, but may break when moving to an active-active topology (ie. if each load balancer originating requests then needs to originate these requests from a unique IP.)</li>
</ol><div>Does that clear things up a bit?</div></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Use-Case 20: I do not believe much of this is handled within the LBaaS<br>
API, but with a different service that provides auto-scaling<br>
functionality. Especially the "on-the-fly" updating of properties.<br>
This also becomes incredibly difficult when considering TCP session<br>
persistence when the possible pool member could be removed at any<br>
automated time.<br></blockquote><div><br></div><div>This is an example of how one might handle SSH load balancing to an array of back-end servers. It's somewhat contrived in that these were the parameters that a potential client inquired about with us, but that we couldn't at that time deliver in our load balancing infrastructure.</div>
<div><br></div><div>Is anyone else doing this kind of (rather convoluted) load balancing? If not, obviously feel free to strike this one down as unnecessary in the up-coming survey. :)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Use-Case 25: I think this one is referring to the functionality of a<br>
"draining" status for a pool member; the pool member will not receive<br>
any new connections, and will not force any active connection closed.<br>
Is that the right way to understand that use-case?<br></blockquote><div><br></div><div>This was meant to be more of a "continuous deployment" or "rolling deployment" use case.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Use-Case 26: Is this functionally wanting something like an "error<br>
page" to come up during the maintenance window? Also, to accept only<br>
connections from a specific set of IPs only during the maintenance<br>
window, one would manually have to create an access list for the load<br>
balancer during the time for testing, and then either modify or remove<br>
it after maintenance is complete. Does this sound like an accurate<br>
understanding/solution?<br></blockquote><div><br></div><div>Correct-- we've seen this a number of times from our customers: They want a 'maintenance page' to show up for anyone connecting to the service except their own people during a maintenance window. Having the ability of their own people hitting the site is actually really important because they need to make sure that the deployment went well and the site is ready for production traffic before they open up the flood gates again. If they make the site generally accessible too early (ie. there was still a problem that could have been detected with testing if their people could have tested) this has the potential of introducing bad data into their database that's impossible to root out afterward.</div>
<div><br></div><div>Just denying connections to the general public (ie. dropping packets or returning 'connection refused' as a firewall would do) is not acceptable in these kinds of scenarios to these customers (ie. it's unprofessional to not show a maintenance page.)</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Use-Case 37: I'm not entirely sure what this one would mean. I know I<br>
included it in the section that sounded more like features, but I was<br>
still curious what this one referred to. Does this have to do with the<br>
desire for auto-scaling? When a pool member gains a certain threshold<br>
of connections another pool member is created or chosen to handle the<br>
next connection(s) as they come?<br></blockquote><div><br></div><div>Well, this one didn't come from me, but I think I know what it means: By 'backup servers' I think they're probably talking about how that terminology is used in haproxy. In haproxy, any member of a pool marked as a 'backup' will not be used unless all other members of the pool (which aren't marked backup) are unavailable. This could be used instead of showing an 'error 503' page, or to serve a reduced-functionality version of the site or whatever. In other words, this is an option to more gracefully handle site overload situations.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
Please feel free to correct me anywhere I've blundered here, and if my<br>
proposed "solution" is inaccurate or not easily understood, I'd be more<br>
than happy to explain in further detail. Thanks for any help you can<br>
offer!<br>
<span class=""><font color="#888888"><br>
-Trevor Vardeman<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</font></span></blockquote></div><br><br clear="all"><div><br></div>-- <br><span></span>Stephen Balukoff
<br>Blue Box Group, LLC
<br>(800)613-4305 x807
</div></div>