Open Stack

Hi Akshay,

I suppose you're talking about LBAAS v2?

Adding support for lbaas in kloudbuster will require some amount of work which can be kept to a minimum if done properly, this addition would be a pretty good way to test lbaas at scale.
The tricky part is to modify the staging code without breaking the other features (multicast and storage) since this staging is specific to HTTP scale test.
The current staging for HTTP scale is based on the following template (I show the server side only):

[Router---------[HTTP server VM]*]*

The natural extension for supporting LBAAS is to replace each HTTP server with a LB group + N HTTP servers:

[Router----------[LB-------[HTTP server VM]*]*]*

Implementing this would require the following modifications (just a rough description of the tasks):

  *   add an additional config option to specify the number of server VMs per LB group (defaults to none/no LB) <easy>
  *   if LB is configured, the current config server count would become a LB group count
  *   the staging code for the HTTP servers needs to be modified to handle the case of LB: <medium difficulty - need to know the LBAAS python APIs>
     *   instead of creating as many HTTP servers as the server count argument, create as many LB groups
     *   for each LB group, create the requested HTTP server VMs per group and add them to the group
  *   floating IP if requested need to apply to the LB port instead of the HTTP servers <easy>
  *   naturally the teardown code will have to also support cleaning up LB resources <easy>

  *   HTTP clients will need to connect to the LB VIP address (instead of the HTTP server IP address) <easy>

I can help you go through these individual tasks in detail in the code if you feel you can handle that, it's just python coding.


The VMs running the HTTP traffic generators are currently always associated 1:1 to a server VM. With the above template extension you will end up with as many HTTP client VMs as LB groups:

(removed the router for better clarity):

[HTTP client VM-------[LB-------[HTTP server VM]*]*]*

This is not ideal because each HTTP traffic generator can only support a relatively low number of connections (in the few thousands) while an HTTP server instance can easily support many times this load especially for light HTTP traffic (i.e. replies that are very short).

So another improvement (which we had on our roadmap) would be to support N:1 mapping:

[[HTTP client VM]*--------LB-------[HTTP server VM]*]*]*

this could be a separate extension.
Let me know if you'd like to do this and we can help navigate the code.

Thanks

   Alec



From: Akshay Kumar Sanghai <akshaykumarsanghai at gmail.com<mailto:akshaykumarsanghai at gmail.com>>
Date: Tuesday, August 23, 2016 at 2:07 PM
To: Alec Hothan <ahothan at cisco.com<mailto:ahothan at cisco.com>>
Cc: "Yichen Wang (yicwang)" <yicwang at cisco.com<mailto:yicwang at cisco.com>>, "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>
Subject: Re: [openstack-dev] [kloudbuster] authorization failed problem

Hi Yichen, Alec,

The kloudbuster project worked perfectly fine for me. Now I want to integrate lbaas for scale testing. Can you guys help in how do i achieve that? Please include me for any contribution.

Thanks
Akshay Sanghai


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160824/5cf736a1/attachment.html>