Hi Murali,
I am planning to take the QA job for this feature. Have reviewed the functional
spec and have the following questions
1. As per the FS, we are going to have a region and zone level flag for GSLB
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 network
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 table
to store the services GSLB offering? Do we have the list of services which 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 for
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
associated 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 / GSLB
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 vservers ?
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 balance
request across zones that goes to static NAT rule / PF rule?
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 such
usecases in this design?
11. Can you also add all the admin API changes?
Thanks,
SWAMY
-----Original Message-----
From: Chiradeep Vittal [mailto:[email protected]]
Sent: Thursday, January 17, 2013 2:32 AM
To: CloudStack DeveloperList
Subject: Re: [DISCUSS] Global Server Load Balancing (GSLB) FS & Design Document
Thanks. Can you add the actual API parameters? Otherwise, LGTM.
On 1/15/13 3:55 AM, "Murali Reddy" <[email protected]> wrote:
>I have update the FS [1] as per the review comments. Changes done are
>included in document history section.
>
>I would like to seek comments on one change added in FS. In CloudStak,
>at present there are no operations that require orchestration across zones.
>GSLB and EIP across zones [2] are two immediate features that require
>cross-zone orchestration. I would like to introduce notion of 'region'
>level services and corresponding service provider in to CloudStack.
>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" <[email protected]> wrote:
>
>>On 11/01/13 2:55 AM, "Chiradeep Vittal" <[email protected]>
>>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
>>>of VMs.
>>>GSLB providers do not do this.
>>
>>Thanks for the review Chiradeep. Sure, GSLB service, is indeed
>>cross-zone service, does not fit in to NetWorkElement model. I will
>>by-pass using NetWorkElement, and let GSLB orchestration send commands
>>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
>>>higher-level orchestration workflow that should not need to touch
>>>network elements or the network manager.
>>>You could even write this feature by orchestrating it using the
>>>end-user APIs.
>>
>>Agreed. GSLB orchestration need not be part of network manager, I will
>>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
>>>template but the template is just to make sure that vital information
>>>is not missed. What ends up happening is that there's a lot of
>>>information, but incoherently organized. Nice job.
>>>
>>>
>>>On 1/8/13 12:52 PM, "Murali Reddy" <[email protected]> wrote:
>>>
>>>>In continuation to my proposal [1], I am brining GSLB support
>>>>separately for discussion. I have put up functional specification
>>>>and design documentation at [2]. Please provide feedback, comments.
>>>>
>>>>Quick abstract of the feature:
>>>>
>>>>Today CloudStack supports load balancing traffic across the VM
>>>>instances with in a zone. In case of multi-zone clouds, users can
>>>>launch service across one or more zones for high availability and
>>>>disaster recovery.
>>>>GSLB
>>>>is set of technologies that are used to load balance traffic across
>>>>multiple location and also provides disaster recovery. With this
>>>>feature CloudStack would be able to orchestrate setting up load
>>>>balancing across multiple zones and also provide disaster recovery
>>>>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
>>>>
>>>
>>>
>>
>>
>>
>
>
