Hi Karl, It's glad to see your work!
But please try to keep the conversation in one thread... On Wed, Jan 15, 2014 at 12:57 PM, Karl Harris <karl.har...@sungard.com>wrote: > I started posting my initial comments in JIRA and was advised > dev@cloudstack.apache.org is the place to post/ask/communicate. > > Here is a set of threads which, from this time on, will be continued on > this mailing list: > > From JIRA: > > Karl Harris< > https://issues.apache.org/jira/secure/ViewProfile.jspa?name=karl.harris> > added > a comment - 31/Dec/13 15:47 - edited > > My colleagues and I have been tasked by our company, Sungard, to implement > and test the functionality of this JIRA. > > We have done some preliminary work and I will outline what we've found and > several questions we have. > > We will certainly have more questions/comments, but this is a good start. > > Please comment, correct or add to the statements and questions below: > > We have referenced: > > 1. > > http://blogs.clogeny.com/understanding-the-redundant-virtual-router-in-citrix-cloudplatform > 2. Cloudstack function spec for RvR > > https://cwiki.apache.org/confluence/display/CLOUDSTACK/Reundant+Virtual+Router+Functional+Spec > . > 3. Cloudstack function spec for new VPC features > > https://cwiki.apache.org/confluence/display/CLOUDSTACK/nTier+Apps+2.0+Functional+Spec > . > 4. Implemented code for RvR in VirtualNetworkApplianceManagerImpl, as > well as redundant_router directory of systemvm and in cloud-early-setup. > > What we know: > > 1. Redundant Virtual Routers (RvR's) are used in CloudStack public > clouds per item 4 above. > 2. The public RvRs are provisioned with the templates contained in > redundant_router directory of systemvm. 3. Keepalived and Conntrackd do most of the "heavy lifting" monitoring > and transitioning the current RvR's in public clouds. > 4. Keepalived and Contrackd are setup with templates by systemvm. > 5. The setup_router script calls the setup_redundant_router to provision > a redundant router pair for a vm. > 6. We will need to confirm each router of a redundant pair is > provisioned under a separate Hypervisor to allow for no single point of > failure. > We didn't test across hypervisor AFAIK, but if the routers are up, there would be the same as VRs from the same hypervisor. VRRP protocol is no difference, as well as contrackd protocol. But I don't think currently we allow a pair of RvR in the different hypervisor when planning deployment. > > Questions: > > 1. Are there any other references which might be helpful? > Basically that's all you can know now... Plus: http://tools.ietf.org/search/rfc3768 for more detail on VRRP. 2. It seems the VirtualNetworkApplianceManagerImpl and associated > classes should be useable for vpcRvR's are there any gotcha's we should > know about when using this class hierarchy ? > It's VpcVirtualNetworkAppliacenManagerImpl I suppose you meant. > 3. Are there any other single points of failure other than the unique > Hypervisor mentioned above? > No. (and it won't have problem in unique hypervisor case if you complete the deployment, which is not allowed now as I know). > 4. Can setting up a redundant router pair for a vpc be done by simply > adding a call to setup_redundant_router script in the setup_vpcrouter > routine for each vpcRouter marked as redundant? > No. There are tons of things need to be done. The biggest issue for VPC is the public nic is hot-plug able, and all current RvR code would assume in Isolated network, which has public nic as eth2 and beyond. The RvR script need to recover all the public nics, which can be any nic in the VPC router. > > <https://issues.apache.org/jira/browse/CLOUDSTACK-764#> > <https://issues.apache.org/jira/browse/CLOUDSTAC<https://issues.apache.org/jira/browse/CLOUDSTACK-764?focusedCommentId=13861692&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13861692> *http://en.wikipedia.org/wiki/Virtual_Router_Redundancy_Protocol > <http://en.wikipedia.org/wiki/Virtual_Router_Redundancy_Protocol>* K-764?focusedCommentId=13861692&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13861692<https://issues.apache.org/jira/browse/CLOUDSTACK-764?focusedCommentId=13861692&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13861692> > > > Karl Harris< > https://issues.apache.org/jira/secure/ViewProfile.jspa?name=karl.harris> > added > a comment - 03/Jan/14 17:29 > Another question: > > After re-reading: > > http://cloudstack.apache.org/docs/en-US/Apache_CloudStack/4.2.0/html/Admin_Guide/about-zones.html > I have a question about the VPC redundant routers. > > Should the Vpc RvR's take into account Zones with respect to not allowing a > redundant router pair to be in the same zone? > > The description: > A zone typically corresponds to a single datacenter, although it is > permissible to have multiple zones in a datacenter. The benefit of > organizing infrastructure into zones is to provide physical isolation and > redundancy. For example, each zone can have its own power supply and > network uplink, and the zones can be widely separated geographically > (though this is not required). > > seems to suggest router pairs should be in different zones. > Currently the deployment policy would be in the same zone, but across the pod/cluster/host/storage. The planner would try hard to put two routers as far as possible. The point is, no network can be created across zone, so all your VMs in the same network would be in the same zone. Then, how would an single router help if your own zone is down... --Sheng > > Comments? > <https://issues.apache.org/jira/browse/CLOUDSTACK-764#> > < > https://issues.apache.org/jira/browse/CLOUDSTACK-764?focusedCommentId=13862885&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13862885 > > > Daan Hoogland< > https://issues.apache.org/jira/secure/ViewProfile.jspa?name=dahn> > added > a comment - 06/Jan/14 09:56 > > The zone is one way of separating the instances of a rvr. Could in some > use-cases a different cluster/pod/host be enough, maybe? > <https://issues.apache.org/jira/browse/CLOUDSTACK-764#> > < > https://issues.apache.org/jira/browse/CLOUDSTACK-764?focusedCommentId=13862893&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13862893 > > > Daan Hoogland< > https://issues.apache.org/jira/secure/ViewProfile.jspa?name=dahn> > added > a comment - 06/Jan/14 10:04 > > Making sure that a redundant pair is at two different locations could be > done by giving it two system offerings. Not sure if this goes against the > present paradigm (for rvr or offerings) > <https://issues.apache.org/jira/browse/CLOUDSTACK-764#> > < > https://issues.apache.org/jira/browse/CLOUDSTACK-764?focusedCommentId=13862897&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13862897 > > > Daan Hoogland< > https://issues.apache.org/jira/secure/ViewProfile.jspa?name=dahn> > added > a comment - 06/Jan/14 10:10 > To be able to predict the assignment of interfaces a private gateway > interface must be reserved on the router-vm, even when not used-- > > > Some "offline" email exchanges will follow under a separate email see > subject line 2 of 2. > > Thanks for your patience. > > Karl > > > Karl O. Harris > Cloud Software Engineer > Sungard Availability Services >
