On 01/04/13 1:47 AM, "David Nalley" <da...@gnsa.us> wrote: >On Fri, Mar 29, 2013 at 2:04 AM, Murali Reddy <murali.re...@citrix.com> >wrote: >> On 26/03/13 8:10 PM, "Adam Grochowski" <adam.grochow...@sungard.com> >>wrote: >> >>>Hi, >>>So I'm curious - what is the proposed method to move a single IP >>>across zones (presuming these zones span regions). As Chiradeep >>>mentioned earlier, /24 is the largest block that will be advertised, >>>so it would necessitate moving (or advertising in two locations, and >>>back hauling back to one) an entire class C to accomplish this (or >>>some black magic like LISP). >> >> Adam, there is no proposed method to move IP across the zones. Having a >> native capability in CloudStack to move IP across the zones does not >>make >> sense. We will be just assuming CloudStack will have control to many >> infrastructure components (orchestrate route advertisements etc). >>Instead >> what is being proposed is, let the CloudStack raise an event when user >> moves IP across the zones, then let admin act up on the event and >>initiate >> the IP availability from new zone. There is no assumption or proposed >> method when and how admin to achieve this. Operator can opt for any >> solution that works in distributed data centre setup. > > >You don't have a proposed method for moving IPs between zones? >Is this all a theoretical solution?
No, its not theoretical solution. Point I am trying to make is, CloudStack need not have a native capability to move IP across zone. From the CloudStack core perspective, all we need is abstraction of moving IP (presented as NAT) across the zones. Then we can have specific intelligence in the plug-ins which are providing EIP service. For e.g.'Route Health Injection' is commonly used solution in distributed data centres for disaster recovery supported by multiple vendors [1][2][3][4]. My initial plan was to enhance NetScaler plug-in to integrate with NetScaler's RHI capability. But even to have such capability in plug-in means CloudStack will have to make several assumptions on operational aspects. So its better to off-load responsibility of IP advertisement to the operators. Let me know if you still have any confusion. May be I will add a reference deployment model/s once I progress with feature and test it. [1] http://www.cisco.com/en/US/docs/solutions/Enterprise/Data_Center/dcstslt.ht ml#wp53152 [2] http://www.nanog.org/meetings/nanog38/presentations/naseh.pdf [3] http://support.f5.com/kb/en-us/products/big-ip_ltm/manuals/product/tmos-ip- routing-administration-11-2-0/4.html [4] http://support.citrix.com/servlet/KbServlet/download/30572-102-692240/NS-Ne tworking-Guide.pdf > >--David >
