Return-Path: X-Original-To: apmail-incubator-cloudstack-dev-archive@minotaur.apache.org Delivered-To: apmail-incubator-cloudstack-dev-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 82119EB06 for ; Wed, 16 Jan 2013 21:02:35 +0000 (UTC) Received: (qmail 72430 invoked by uid 500); 16 Jan 2013 21:02:35 -0000 Delivered-To: apmail-incubator-cloudstack-dev-archive@incubator.apache.org Received: (qmail 72382 invoked by uid 500); 16 Jan 2013 21:02:35 -0000 Mailing-List: contact cloudstack-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: cloudstack-dev@incubator.apache.org Delivered-To: mailing list cloudstack-dev@incubator.apache.org Received: (qmail 72369 invoked by uid 99); 16 Jan 2013 21:02:35 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 16 Jan 2013 21:02:35 +0000 X-ASF-Spam-Status: No, hits=-5.0 required=5.0 tests=RCVD_IN_DNSWL_HI,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of Chiradeep.Vittal@citrix.com designates 66.165.176.89 as permitted sender) Received: from [66.165.176.89] (HELO SMTP.CITRIX.COM) (66.165.176.89) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 16 Jan 2013 21:02:29 +0000 X-IronPort-AV: E=Sophos;i="4.84,480,1355097600"; d="scan'208";a="3997779" Received: from sjcpmailmx01.citrite.net ([10.216.14.74]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 16 Jan 2013 21:02:07 +0000 Received: from SJCPMAILBOX01.citrite.net ([10.216.4.72]) by SJCPMAILMX01.citrite.net ([10.216.14.74]) with mapi; Wed, 16 Jan 2013 13:02:06 -0800 From: Chiradeep Vittal To: CloudStack DeveloperList Date: Wed, 16 Jan 2013 13:02:04 -0800 Subject: Re: [DISCUSS] Global Server Load Balancing (GSLB) FS & Design Document Thread-Topic: [DISCUSS] Global Server Load Balancing (GSLB) FS & Design Document Thread-Index: Ac30LL3vHmcUumwTRVGTyvJD6H2b7Q== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Virus-Checked: Checked by ClamAV on apache.org Thanks. Can you add the actual API parameters? Otherwise, LGTM. On 1/15/13 3:55 AM, "Murali Reddy" 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]=20 >https://cwiki.apache.org/confluence/display/CLOUDSTACK/GSLB+(Global+Server >+ >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" wrote: > >>On 11/01/13 2:55 AM, "Chiradeep Vittal" >>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" 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+%28Globa >>>>l >>>>+ >>>>S >>>>e >>>>rver+Load+Balancing%29+Functional+specification+and+Design+Document >>>> >>> >>> >> >> >> > >