Saurav, Not sure how this happens now, but it is definateluy something we want. For the static conf files it won't be much of a problem. The firewall/loadbalences won't be much of a problem, they are fire and forget configurations of the ms that can just be sent to both. The dhcp is a challange. I am not sure if it is solved for the plain rvr now but it should be solved for that as well.
On Fri, Jan 24, 2014 at 3:53 PM, Saurav Lahiri <saurav.lah...@sungard.com> wrote: > Daan, > I was wondering if you had not shared your thoughts, but looks like I had > missed your mail. > > I agree that redundant dhcp or dns would be good to have. What I meant was, > it appears that by just enabling RVR there is no way to auto sync > configuration between the master and slave nodes with regard to dhcp, > loadbalancer and firewall(specifically the dhcp lease file, haproxy,cfg and > iptables configuration). So just enabling RVR does not ensure high > availability for these services. Is there a way cloudstack autosyncs > configuration? > > For the routing portion this is not an issue as the participating routers > learn the route through known protocols. > > Thanks > Saurav > > > On Fri, Jan 17, 2014 at 2:37 AM, Daan Hoogland <daan.hoogl...@gmail.com>wrote: > >> Saurav, I don't see why you can't benefit from having other services >> redundant as well. Vpn might be a problem as the source ip of a >> redundant router pair on a vpn might give a problem (maybe there is an >> implementation) but why wouldn't you want redundant dhcp or dns >> services? As I understand it these are used at Schuberg Philis at the >> moment. will double check when I get a chance. >> >> regards, >> Daan >> >> >> >> On Thu, Jan 16, 2014 at 1:33 PM, Saurav Lahiri >> <saurav.lah...@sungard.com> wrote: >> > Daan, >> > So looking at what is available today for guest network, the Redundant VR >> > can be enabled only for the source nat service. I guess the mention of >> the >> > source nat router is in relation to that. I could be wrong though. It >> > appears that the other services like vpn, dhcp, dns do not benefit much >> > from the RVR capability. Can you clarify if thats correct? >> > >> > Thanks >> > Saurav >> > >> > >> > On Thu, Jan 16, 2014 at 2:27 AM, Karl Harris <karl.har...@sungard.com >> >wrote: >> > >> >> ---------- Forwarded message ---------- >> >> From: Daan Hoogland <daan.hoogl...@gmail.com> >> >> Date: Wed, Jan 15, 2014 at 2:51 PM >> >> Subject: Re: rvr4vpc >> >> To: Karl Harris <karl.har...@sungard.com> >> >> Cc: Christopher Litsinger <christopher.litsi...@sungard.com> >> >> >> >> >> >> H Karl, >> >> >> >> Thanks for sharing. I didn't want to initiate this but I encourage you >> >> to share this on the dev list (not in jira) as things are only >> >> considered 'discussed' if they passed by there. >> >> >> >> You speak of '1 Get configuration data on Source Nat Router', I don't >> >> understand why you call the router by this designation. 'Source Nat' >> >> is only one of it's many possible functions. >> >> >> >> Apart from the design principles I shared with you I have so far only >> >> a technical implementation detail so far. That is to reserve the >> >> (eth2) interface for the private gateway on the vpc (r)vr. This way >> >> the inteface to configure are somewhat predictable. >> >> >> >> As for the design principle to have a statefull router (reboot proof) >> >> the idea is to implement a configuration file that will be uploaded to >> >> the router after which a self-config command is send that will >> >> implement the details of configuring the interfaces, haproxy and >> >> keepalived and maybe more. I think your current assessment of the >> >> working of the RVRs is accurate but it will not be workable for an >> >> implementation for vpc's as they have an unpreditable number of >> >> interfaces. >> >> >> >> to bad you can't make it next thursday, >> >> Daan Hoogland >> >> >> >> >> >> On Wed, Jan 15, 2014 at 3:25 PM, Karl Harris <karl.har...@sungard.com> >> >> wrote: >> >> > Daan, >> >> > >> >> > Sorry for the delayed response but as Christopher mentioned to you in >> his >> >> > email I am getting my head around the CloudStack software. >> >> > Since I am new to CloudStack but "old" to enterprise level JAVA the >> task >> >> is >> >> > large but not impossible. I have no experience with running CloudStack >> >> but >> >> > considerable experience designing and maintaining large JAVA >> >> applications. >> >> > >> >> > I've created what I believe is a very high level abstract of how the >> >> current >> >> > guest VRR's are created for guest networks with the intent of making >> this >> >> > abstract >> >> > more detailed. >> >> > >> >> > 1 Get configuration data on Source Nat Router selected as a redundant >> >> > router >> >> > 1.1 Public and Guest network identified. >> >> > 2 Both routers are provisioned >> >> > 2.1 Software trys different, regions(?),zones,pods,clusters,hosts >> in >> >> > that order as the location of the router. Log maximum “distance” >> apart. >> >> > 3 Keepalived is configured >> >> > 4 Both routers are started >> >> > 5 Keepalived is started >> >> > >> >> > Obviously there is much more that is happening under each of the steps >> >> > above. My intent is to complete this detailed "as is" listing as much >> as >> >> we >> >> > can. Then using the "as is" description/sequence >> >> > make a "to-be" addition for VPC's. When I get a consensus on WHAT >> needs >> >> to >> >> > be implemented for the VRR in VPC then develop HOW best to implement >> the >> >> > "to-be" addition with the >> >> > existing JAVA code as well as what additional classes need to be >> >> > extended/implemented/created. >> >> > >> >> > Comments, critiques and changes to the above sequence are encouraged. >> >> > >> >> > I plan on posting this to the dev-list/Jira very soon. >> >> > >> >> > I have been using this functional spec as a guide, after discussing >> this >> >> > with our Systems Engineering people this spec meets our requirements. >> >> > >> >> > Do you have an implementation in mind? >> >> > >> >> > We have an internal Cloud Meeting with conflicts with the cloudstack >> >> "day" >> >> > next week so I will not be in attendence. >> >> > >> >> > Karl >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > On Tue, Jan 14, 2014 at 4:35 PM, Daan Hoogland < >> daan.hoogl...@gmail.com> >> >> > wrote: >> >> >> >> >> >> Hello overthere in the states, >> >> >> >> >> >> Tomorow I will start some experimenting with redundant vpc routers. >> >> >> This is to check up on any findings and requirements that you might >> >> >> have on this. Once again I would not like to waste work on this as it >> >> >> is really a globally usable feature that is probably universal. >> >> >> >> >> >> please let me know your status on this. >> >> >> >> >> >> If any of you are coming to the cloudstack day in London next week, >> >> >> let's meetup next thursday. >> >> >> >> >> >> kind regards, >> >> >> Daan Hoogland >> >> >> >> >> > >> >> > >> >> > >> >> > -- >> >> > Karl O. Harris >> >> > Cloud Software Engineer >> >> > Sungard Availability Services >> >> > >> >> >> >> >> >> >> >> >> >> -- >> >> Karl O. Harris >> >> Cloud Software Engineer >> >> Sungard Availability Services >> >> >> >>
