Mailing-List: contact cloudstack-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cloudstack-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of
 venkataswamybabu.budumuru@citrix.com designates 203.166.19.134 as permitted
 sender)
From: Venkata SwamyBabu Budumuru <venkataswamybabu.budumuru@citrix.com>
To: "cloudstack-dev@incubator.apache.org"
	<cloudstack-dev@incubator.apache.org>
Date: Fri, 18 Jan 2013 18:03:41 +0530
Subject: RE: [DISCUSS] Global Server Load Balancing (GSLB) FS & Design
 Document
Thread-Topic: [DISCUSS] Global Server Load Balancing (GSLB) FS & Design
 Document
Thread-Index: Ac30LL3vHmcUumwTRVGTyvJD6H2b7QBP9LKw
Message-ID: 
 <67EF18FDCA335F489B366120481AB6C5F6B54CC3B6@BANPMAILBOX01.citrite.net>
References: <CD1B3D74.2C4F2%murali.reddy@citrix.com>
 <CD1C5532.40E7C%chiradeep.vittal@citrix.com>
In-Reply-To: <CD1C5532.40E7C%chiradeep.vittal@citrix.com>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

Hi Murali,

I am planning to take the QA job for this feature. Have reviewed the functi=
onal spec and have the following questions


1. As per the FS, we are going to have a region and zone level flag for GSL=
B capability. Why do we need a flag to be set at zone level ?
As the cloud admin is going to enable GSLB service provider at physical net=
work level, can we use this info to decide whether this physical network is=
 enabled and used for GSLB rather at zone level

2. Are we going to use the same cloud. physical_network_service_providers t=
able to store the services GSLB offering? Do we have the list of services w=
hich GSLB is going to offer? Can we add those db changes to FS?

3. Is the createGlobalLoadBalacerRule takes the weight parameter along with=
 "lb algo"? can we update the same to "API Changes"?

4. "Functional Requirements" sections says "statistics shall be collected f=
or each of GSLB virtual server."

	a. What kind of statistics? Is it the statistics that give a picture about=
 which site has more hits, load etc.. so that user can adjust the weights a=
ssociated with virtual server to balance things?
	b. Are we also considering the traffic / bandwidth consumption resulted by=
 request redirection from one site to the other (due to proximity or weight=
 etc..)? are we recording those usage statistics  for billing ?

5. what is the health monitoring workflow? Like if SLB vserver is down / GS=
LB vserver down. Is the CloudStack aware of this and reacts to it?

6. Can the cloud admin use same device to host GSLB vservers and SLB vserve=
rs ?

7. Is the planned design going to accommodate multiple devices (NetScalers)=
 for hosting GSLB vservers in single physical network?

8. SLB provider can be anything right? It can be VR, VPC VR, VPX, etc..,?

9. Current design is considering requests going from GSLB virtual server to=
 SLB vserver and how about a use case where user want to use GSLB to load b=
alance request across zones that goes to  static NAT rule / PF rule?=20

10. Is it a requirement in public clouds where tenant would ask for / wants=
 to have his own domain name rather using *.xyztelco.com? did we consider s=
uch usecases in this design?

11. Can you also add all the admin API changes?
=09
Thanks,
SWAMY

-----Original Message-----
From: Chiradeep Vittal [mailto:Chiradeep.Vittal@citrix.com]=20
Sent: Thursday, January 17, 2013 2:32 AM
To: CloudStack DeveloperList
Subject: Re: [DISCUSS] Global Server Load Balancing (GSLB) FS & Design Docu=
ment

Thanks. Can you add the actual API parameters? Otherwise, LGTM.

On 1/15/13 3:55 AM, "Murali Reddy" <Murali.Reddy@citrix.com> wrote:

>I have update the FS [1] as per the review comments. Changes done are=20
>included in document history section.
>
>I would like to seek comments on one change added in FS. In CloudStak,=20
>at present there are no operations that require orchestration across zones=
.
>GSLB and EIP across zones [2] are two immediate features that require=20
>cross-zone orchestration. I would like to introduce notion of 'region'
>level services and corresponding service provider in to CloudStack.=20
>Please share your thoughts.
>
>[1]
>https://cwiki.apache.org/confluence/display/CLOUDSTACK/GSLB+(Global+Ser
>ver
>+
>Load+Balancing)+Functional+specification+and+Design+Document
>
>[2] https://issues.apache.org/jira/browse/CLOUDSTACK-652
>
>
>On 11/01/13 2:32 PM, "Murali Reddy" <Murali.Reddy@citrix.com> wrote:
>
>>On 11/01/13 2:55 AM, "Chiradeep Vittal" <Chiradeep.Vittal@citrix.com>
>>wrote:
>>
>>>Thanks for the detailed and enlightening write-up*.
>>>
>>>I feel that the GSLB service is not a NetworkElement.
>>>NetworkElements are those that participate in the L2/L3 orchestration=20
>>>of VMs.
>>>GSLB providers do not do this.
>>
>>Thanks for the review Chiradeep. Sure, GSLB service, is indeed=20
>>cross-zone service, does not fit in to NetWorkElement model. I will=20
>>by-pass using NetWorkElement, and let GSLB orchestration send commands=20
>>directly to agent representing the GSLB provider.
>>
>>>
>>>It does not even participate in the existing Loadbalancer workflow.
>>>
>>>In fact I would assert that this is a completely different=20
>>>higher-level orchestration workflow that should not need to touch=20
>>>network elements or the network manager.
>>>You could even write this feature by orchestrating it using the=20
>>>end-user APIs.
>>
>>Agreed. GSLB orchestration need not be part of network manager, I will=20
>>restrict it to service layer.
>>
>>I will update the spec and get back.
>>
>>>
>>>
>>>*A lot of folks strive to format the document according to the=20
>>>template but the template is just to make sure that vital information=20
>>>is not missed. What ends up happening is that there's a lot of=20
>>>information, but incoherently organized. Nice job.
>>>
>>>
>>>On 1/8/13 12:52 PM, "Murali Reddy" <Murali.Reddy@citrix.com> wrote:
>>>
>>>>In continuation to my proposal [1], I am brining GSLB support=20
>>>>separately for discussion. I have put up functional specification=20
>>>>and design documentation at [2]. Please provide feedback, comments.
>>>>
>>>>Quick abstract of the feature:
>>>>
>>>>Today CloudStack supports load balancing traffic across the VM=20
>>>>instances with in a zone. In case of multi-zone clouds, users can=20
>>>>launch service across one or more zones for high availability and=20
>>>>disaster recovery.
>>>>GSLB
>>>>is set of technologies that are used to load balance traffic across=20
>>>>multiple location and also provides disaster recovery. With this=20
>>>>feature CloudStack would be able to orchestrate setting up load=20
>>>>balancing across multiple zones and also provide disaster recovery=20
>>>>solution in case of multiple zone clouds.
>>>>
>>>>
>>>>[1] http://markmail.org/message/lx6tyikvmvd6wix4
>>>>
>>>>[2]https://cwiki.apache.org/confluence/display/CLOUDSTACK/GSLB+%28Gl
>>>>oba
>>>>l
>>>>+
>>>>S
>>>>e
>>>>rver+Load+Balancing%29+Functional+specification+and+Design+Document
>>>>
>>>
>>>
>>
>>
>>
>
>