Comments inline.

German

From: Susanne Balle [mailto:sleipnir...@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.miramon...@rackspace.com<mailto:jorge.miramon...@rackspace.com>> wrote:
Answers inlined. Thanks for the questions! They forced me to think about 
certain features.

Cheers,
--Jorge

From: Samuel Bercovici <samu...@radware.com<mailto:samu...@radware.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Date: Wednesday, April 9, 2014 6:10 AM
To: "OpenStack Development Mailing List 
(openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>)" 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@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@lists.openstack.org<mailto:OpenStack-dev@lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to