cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Murali Reddy <Murali.Re...@citrix.com>
Subject Re: [PROPOSAL] EIP across zones
Date Fri, 22 Mar 2013 06:20:57 GMT
On 22/03/13 3:26 AM, "Chiradeep Vittal" <Chiradeep.Vittal@citrix.com>
wrote:

>
>
>On 3/20/13 8:31 PM, "Murali Reddy" <Murali.Reddy@citrix.com> wrote:
>>>are outside of our control scares me.
>>
>>David, yes this is a valid concern. So, initially I was planning to
>>leverage the ADC like NetScaler's routing capabilities to advertise
>>routes. When IP is transferred from zone to another zone, CloudStack will
>>orchestrate the route advertisements. But as you reasoned, this is not
>>the
>>best way to go. So what I am proposing is that, let CloudStack raise the
>>trigger (raise action event for eg.) when IP is transferred, on which
>>Admin/external tools can act up on.
>
>The document says "leverage Netscaler". I think the value of this is moot
>for someone not already using a Netscaler?

Sorry, I don't see any reference to leveraging NetScaler in FS for route
advertisement. I have put explicit assumption "It is assumed that when an
EIP is transferred from one zone to another, it is expected that admin
performs out-of-band operation that will ensure that traffic for EIP is
routed to the new zone." Also a requirement "Support for NetScaler as EIP
service provider but the design should be generic so any NAT provider can
be enhanced to act of EIP service provider". Since the proposal is only to
extend the NetScaler plug-in as EIP service provider, so value is only for
those already using NetScaler as of now. But one can extend VR or other
supported network appliances to be EIP service provider as well.

>
>>
>>>
>>>What exactly are we getting here that we couldn't obtain with things
>>>like having folks manage DNS much better, as I fear there are many
>>>dragons along this path.
>>
>>Good question. This is purely in-practice AWS EIP use case. With DNS
>>re-mapping there is huge failover recovery time (propagation of new DNS
>>mapping, client cache etc) in reflecting the DNS name to new public IP.
>>What is happening in this case is DNS name, public IP remain static, it
>>just the back end server that changes.
>>
>>I donĀ¹t see testing is big concern. In some sense CloudStack is dumb in
>>this context all its doing is just configuring NAT rule, intelligence to
>>advertise the IP or out side of CloudStack.
>
>Except for Netscaler? Should we leave this out for the same reason?

Not sure I get the question correctly. As mentioned above advertisement
has to be out-of-band, could be NetScaler or edge routers that is will
advertising the IP availability.


Mime
View raw message