[openstack-dev] [Neutron][LBaaS]Clarification in regards to https://docs.google.com/a/mirantis.com/spreadsheet/ccc?key=0Ar1FuMFYRhgadDVXZ25NM2NfbGtLTkR0TDFNUWJQUWc#gid=1

Eichberger, German german.eichberger at hp.com
Wed Apr 9 22:57:36 UTC 2014


Comments inline.

German

From: Susanne Balle [mailto:sleipnir012 at gmail.com]
Sent: Wednesday, April 09, 2014 2:54 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS]Clarification in regards to https://docs.google.com/a/mirantis.com/spreadsheet/ccc?key=0Ar1FuMFYRhgadDVXZ25NM2NfbGtLTkR0TDFNUWJQUWc#gid=1

See inline, Susanne

On Wed, Apr 9, 2014 at 4:49 PM, Jorge Miramontes <jorge.miramontes at rackspace.com<mailto:jorge.miramontes at rackspace.com>> wrote:
Answers inlined. Thanks for the questions! They forced me to think about certain features.

Cheers,
--Jorge

From: Samuel Bercovici <SamuelB at Radware.com<mailto:SamuelB at Radware.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>
Date: Wednesday, April 9, 2014 6:10 AM
To: "OpenStack Development Mailing List (openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>)" <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>
Subject: [openstack-dev] [Neutron][LBaaS]Clarification in regards to https://docs.google.com/a/mirantis.com/spreadsheet/ccc?key=0Ar1FuMFYRhgadDVXZ25NM2NfbGtLTkR0TDFNUWJQUWc#gid=1

Hi,

I have looked at https://docs.google.com/a/mirantis.com/spreadsheet/ccc?key=0Ar1FuMFYRhgadDVXZ25NM2NfbGtLTkR0TDFNUWJQUWc#gid=1 and have a few questions:

1.       Monitoring Tab:

a.       Are there users that use load balancing who do not monitor members? Can you share the use cases where this makes sense?
This is a good question. In our case we supply static ip addresses so some users have only one backend node. With one node it isn't necessary. Another case I can think of is lbs that are being used for non-critical environments (i.e. dev or testing environment). For the most part it would make sense to have monitoring.

b.      Does it make sense to define the different type of monitors (ex: TCP, HTTP HTTPS)?
Yes it does. Http monitoring, for example, allows you to monitor specific URI's. I just put total utilization for all three to get some data out.

c.       Does any existing cloud service besides the current implementation of the LBaaS API supports using multiple monitors on the same pool? Is this a required feature?
I would think multiple monitors wouldn't make sense as they could potentially conflict. How would a decision be made in such a case?

2.       Logging Tab:

a.       What is logging use for?
This is specifically connection logging. It allows the user to see all of the requests that went through the load balancer. It is mostly used for big data and troubleshooting.

b.      How does the tenant consume the logs?
For our offering, we send their logs in a compressed format to swift. However, I am open to discussion on how to handle this in a more flexible manner.

[Susanne] in our case logs are forwarded to a centralized logging system e.g. Logstash/Elastic Search/Kibana/etc.
[German] The internal operator logs get to kibana as Susanne described. We also offer a way for customers to get their logs uploaded to Swift.

3.       SSL Tab:

a.       Please explain if SSL means passing SSL traffic through the load balancer or using the load balancer to terminate certificates.
SSL termination. I updated the tab.

b.      Does it make sense to separate those (SSL termination and non HTTPS terminated traffic) as different rows?
Blue Box added a few extra rows. I identified lbs that terminate only secure traffic and lbs that allow both secure and insecure traffic.

c.       Can anyone explain the use cases for SSL_MIXED?
A lot of web sites have mixed content. The lb terminates the secure traffic. The insecure traffic passes through normally.

4.       HA Tab:

a.       Is this a tenant facing option or is it the way the operator chose to implement the service
For us, this is operator implementation. However, since most lbs are considered mission critical almost all production users require HA. I could see this being a toggable feature from the tenant side if they wanted to use a lb for testing or something non mission critical.

[Susanne] Same for us. It is very important for use as service provider  that the LB be resilient so the user doesn't have a choice. It is resilient by default.

5.       Content Caching Tab:

a.       Is this a load balancer feature or a CDN like feature.
This is a lb feature. However, depending on the amount of content you'd like to cache using a CDN may be overkill. Here is a link that may shed some light: http://www.rackspace.com/knowledge_center/article/content-caching-for-cloud-load-balancers

6.       L7

a.       Does any cloud provider support L7 switching and L7 content modifications?
We currently do not.
[German] We currently do not have this feature though some customers have written small programs which simulate L7 monitoring by reporting the result on an arbitrary TCP port on the node. Our LB can monitor any port for system health BTW.

[Susanne] we do not have that feature either.

b.      If so can you please add a tab noting how much such features are used?
N/A - Delegating to someone who actually has data.

c.       If not, can anyone attest to whether this feature was requested by customers?
Good question. I can see the use cases but operator data on this would be nice for those that have it. We have had a few requests but not enough that would warrant development effort at this time. Hence, I would mark this priority low unless we can back it up with data.
 [German] I know of customers requesting this feature - but we haven't made it a priority since there is a workaround.
Thanks!
                -Sam.


_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140409/432d5d9a/attachment-0001.html>


More information about the OpenStack-dev mailing list