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
<akshaykumarsang...@gmail.com<mailto:akshaykumarsang...@gmail.com>>
Date: Tuesday, August 23, 2016 at 2:07 PM
To: Alec Hothan <ahot...@cisco.com<mailto:ahot...@cisco.com>>
Cc: "Yichen Wang (yicwang)" <yicw...@cisco.com<mailto:yicw...@cisco.com>>,
"OpenStack Development Mailing List (not for usage questions)"
<openstack-dev@lists.openstack.org<mailto:openstack-dev@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
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
